O que aprendi construindo com LLMs durante um ano

• Estamos em um momento empolgante para o desenvolvimento com grandes modelos de linguagem (LLMs)
  • No último ano, os LLMs chegaram a um nível "bom o suficiente" para aplicações reais e, a cada ano, estão ficando melhores e mais baratos
  • Junto com as demos nas redes sociais, estima-se que cerca de US$ 200 bilhões serão investidos em IA até 2025
  • As APIs dos fornecedores tornaram os LLMs mais acessíveis, permitindo que não apenas engenheiros e cientistas de ML, mas todos, possam incorporar inteligência a produtos
• Embora a barreira de entrada para construir com IA tenha diminuído, ainda é difícil criar produtos e sistemas eficazes que vão além de demos
• Nós temos construído ao longo do último ano e, nesse processo, encontramos muitas dificuldades
  • Queremos compartilhar o que aprendemos para que você possa evitar nossos erros e iterar mais rápido
• Este artigo é composto por três partes:
  1. Tactical (tático): algumas práticas para prompting, RAG, engenharia de workflow, avaliação e monitoramento
     • Escrito para profissionais que constroem com LLMs ou para quem toca projetos de fim de semana
  2. Operational (operacional): as preocupações organizacionais e cotidianas do lançamento de produtos e como montar equipes eficazes
     • Voltado a líderes de produto/tecnologia que querem implantar de forma sustentável e confiável
  3. Strategic (estratégico): perspectivas de longo prazo e de visão ampla, como "sem GPU antes do PMF" e "foque no sistema, não no modelo", além de como iterar
     • Escrito tendo fundadores e executivos em mente
• Este guia tem como objetivo ser um manual prático para criar produtos bem-sucedidos usando LLMs
  • Ele nasce da nossa própria experiência e apresenta exemplos de toda a indústria

[Tática: o essencial do uso de LLMs]

• Nesta seção, compartilhamos boas práticas sobre os componentes centrais da nova stack de LLMs
  • Isso inclui dicas de prompting para melhorar qualidade e confiabilidade, estratégias para avaliar saídas e ideias de geração aumentada por recuperação para melhorar grounding
  • Também vamos explorar como projetar workflows com human-in-the-loop

Tática 1. Prompting

• Ao desenvolver uma nova aplicação, recomendamos começar por prompting
  • É fácil subestimar ou superestimar a importância do prompting
  • Ele tende a ser subestimado porque, usando corretamente as técnicas certas de prompting, é possível ir muito longe
  • E tende a ser superestimado porque, para uma aplicação baseada em prompts funcionar de verdade, ainda é necessária uma engenharia considerável ao redor do prompt

Foque em tirar o máximo das técnicas básicas de prompting

• Existem algumas técnicas de prompting que ajudam consistentemente a melhorar o desempenho em vários modelos e tarefas
  • Entre elas estão prompt N-shot + aprendizado em contexto, Chain-of-Thought e fornecimento de recursos relevantes
• Prompt N-shot e aprendizado em contexto
  • A ideia do aprendizado em contexto com prompt N-shot é demonstrar a tarefa ao LLM e fornecer alguns exemplos para alinhar a saída às expectativas
  • Se N for muito baixo, o modelo pode ficar excessivamente preso àqueles exemplos específicos, prejudicando a capacidade de generalização
  • Empiricamente, mire em N ≥ 5 e não tenha medo de usar várias dezenas
  • Os exemplos devem representar a distribuição de entrada esperada
  • Não é necessário fornecer pares completos de entrada e saída; em muitos casos, exemplos da saída desejada já bastam
  • Se você estiver usando um LLM com suporte ao uso de ferramentas, os exemplos N-shot também devem usar as ferramentas que você quer que o agente use
• Prompting com Chain-of-Thought (CoT)
  • No prompting com CoT, incentiva-se o LLM a explicar seu processo de raciocínio antes de retornar a resposta final
  • Você pode pensar nisso como dar ao LLM um bloco de rascunho para que ele não precise fazer tudo apenas na memória
  • A abordagem original era simplesmente adicionar a frase "vamos pensar passo a passo" como parte da instrução, mas descobrimos que ajuda tornar o CoT mais específico
  • Acrescentar especificidade em 1 ou 2 frases muitas vezes reduz significativamente a taxa de alucinação
  • Recentemente, surgiram dúvidas sobre se essa técnica é tão poderosa quanto se acredita
  • Também há bastante debate sobre o que exatamente acontece durante a inferência quando o CoT é usado
  • Ainda assim, é uma técnica que vale a pena experimentar quando possível
• Fornecimento de recursos relevantes
  • Fornecer recursos relevantes é um mecanismo poderoso para expandir a base de conhecimento do modelo, reduzir alucinações e aumentar a confiança do usuário
  • Isso costuma ser feito por meio de Retrieval Augmented Generation (RAG)
  • Fornecer ao modelo trechos de texto que ele possa usar diretamente na resposta é uma técnica essencial
  • Ao fornecer recursos relevantes, não basta apenas incluí-los
    • Não se esqueça de instruir o modelo a priorizar o uso desses recursos, referenciá-los diretamente e, às vezes, mencionar quando eles não forem suficientes
  • Essas práticas ajudam a fazer o grounding das respostas do agente no corpus de recursos

Estruture entradas e saídas

• Entradas e saídas estruturadas ajudam o modelo a compreender melhor a entrada e a retornar saídas que possam ser integradas com confiabilidade aos sistemas downstream
  • Adicionar um formato de serialização à entrada pode ajudar nas relações entre tokens do contexto, em metadados extras sobre tokens específicos (como tipo) ou em relacionar a solicitação a exemplos semelhantes nos dados de treinamento do modelo
  • Por exemplo, muitas perguntas na internet sobre escrever SQL começam especificando o esquema SQL
    • Portanto, um prompting eficaz para Text-to-SQL deve incluir definições estruturadas de esquema
• Saídas estruturadas cumprem um propósito semelhante, mas simplificam a integração com componentes downstream do sistema
  • Instructor e Outlines funcionam bem para saídas estruturadas
    • (use Instructor se estiver importando um SDK de API de LLM; use Outlines se estiver importando Huggingface para um modelo self-hosted)
  • Entradas estruturadas aumentam a chance de saídas melhores por expressarem a tarefa com clareza e serem semelhantes aos formatos dos dados de treinamento
• Ao usar entradas estruturadas, vale observar que cada família de LLM tem sua forma preferida
  • Claude prefere <xml>, enquanto GPT prefere Markdown e JSON
  • Ao usar XML, você também pode pré-preencher a resposta do Claude fornecendo uma tag <response>

Crie prompts pequenos e que façam bem uma única coisa

• Um antipadrão/code smell comum em software é o "God Object", uma única classe ou função que faz de tudo
  • O mesmo se aplica a prompts
• Prompts geralmente começam simples
  • Você pode começar com algumas frases de instrução e alguns exemplos
  • Mas, à medida que tenta melhorar o desempenho e cobrir mais edge cases, a complexidade aumenta
    • Mais instruções, raciocínio em múltiplas etapas, dezenas de exemplos etc. são adicionados
  • No fim, o prompt que era simples no começo vira um Frankenstein de 2.000 tokens
    • E, além disso, o desempenho em entradas mais gerais e intuitivas acaba piorando
    • A GoDaddy classificou esse problema como a lição nº 1 aprendida ao construir com LLMs
• Assim como tentamos manter o sistema e o código simples, o mesmo deve valer para prompts
  • Em vez de usar um único prompt faz-tudo para um resumidor de transcrições de reuniões, é possível dividi-lo em etapas como:
    • extrair as principais decisões, itens de ação e responsáveis em um formato estruturado
    • verificar a consistência dos detalhes extraídos em relação à transcrição original
    • gerar um resumo conciso a partir dos detalhes estruturados
• Como resultado, um único prompt é dividido em vários prompts simples, focados e fáceis de entender
  • Com essa divisão, agora é possível iterar e avaliar cada prompt individualmente

Criação de tokens de contexto

• É preciso repensar e questionar as suposições sobre a quantidade de contexto que realmente precisa ser enviada ao agente
  • Em vez de esculpir uma estátua de contexto como Michelangelo, é preciso remover o material desnecessário para revelar a escultura
  • RAG é um método amplamente usado para reunir todos os blocos de mármore potencialmente relevantes, mas o que está sendo feito para extrair o que é necessário?
• Descobriu-se que, para repensar o contexto, ajuda pegar o prompt final enviado ao modelo, colocá-lo em uma página em branco junto com toda a composição do contexto, meta-prompting e resultados de RAG, e lê-lo
  • Com esse método, é possível encontrar redundâncias, linguagem autocontraditória e partes mal formatadas
• Outra otimização central é a estrutura do contexto
  • Como a representação bag-of-docs não ajuda humanos, não se deve presumir que ela seja boa para agentes
  • É preciso considerar cuidadosamente como estruturar o contexto para destacar as relações entre cada parte e tornar a extração o mais simples possível

Tática 2. Recuperação de informação / RAG

• Além de prompting, outra forma eficaz de ajustar um LLM é fornecer conhecimento como parte do prompt
  • Isso ancora o LLM no contexto fornecido, o que é usado para aprendizado em contexto
  • Isso é chamado de Retrieval-Augmented Generation (RAG)
  • Profissionais descobriram que RAG é eficaz para fornecer conhecimento e melhorar a saída, exigindo muito menos esforço e custo do que fine-tuning
  • RAG só é tão bom quanto a relevância, a densidade e o nível de detalhe dos documentos recuperados

A qualidade da saída de RAG depende da qualidade dos documentos recuperados, e alguns fatores podem ser considerados

• A primeira e mais óbvia métrica é a "relevância"
  • Isso geralmente é quantificado por métricas de ranking como Mean Reciprocal Rank (MRR) ou Normalized Discounted Cumulative Gain (NDCG)
  • O MRR avalia quão bem o sistema posiciona o primeiro resultado relevante na lista ranqueada, enquanto o NDCG considera a relevância e a posição de todos os resultados
  • Elas medem o desempenho do sistema em ranquear documentos relevantes mais acima e documentos irrelevantes mais abaixo
  • Por exemplo, ao recuperar resenhas de usuários para gerar um resumo de críticas de um filme, é melhor ranquear mais acima as resenhas do filme específico e excluir resenhas de outros filmes
  • Assim como em sistemas de recomendação tradicionais, a classificação dos itens recuperados afeta significativamente a forma como o LLM executa a tarefa downstream
  • Para medir esse impacto, experimente executar a tarefa baseada em RAG com os itens recuperados embaralhados e veja como a saída do RAG se comporta
• Em segundo lugar, a "densidade de informação"
  • Se dois documentos forem igualmente relevantes, deve-se preferir o mais conciso e com menos detalhes irrelevantes
  • Voltando ao exemplo do filme, o roteiro do filme e todas as resenhas de usuários podem ser considerados relevantes em um sentido amplo
  • Ainda assim, resenhas com notas altas e resenhas editoriais provavelmente terão maior densidade de informação
• Por fim, considere o "nível de detalhe" fornecido no documento
  • Imagine que você está construindo um sistema RAG para gerar consultas SQL a partir de linguagem natural
    • Fornecer apenas o schema da tabela com os nomes das colunas como contexto pode ser suficiente
    • Mas e se você incluir descrições das colunas e alguns valores representativos?
  • Detalhes adicionais podem ajudar o LLM a entender melhor o significado da tabela e gerar SQL mais preciso

Não se esqueça da busca por palavras-chave e use-a para baseline e busca híbrida

• Como demos de RAG baseadas em embedding se espalharam amplamente, é fácil esquecer ou ignorar décadas de pesquisa e soluções na área de recuperação de informação
  • Ainda assim, embora embeddings sejam sem dúvida uma ferramenta poderosa, não são solução para tudo
• Vantagens da busca baseada em palavras-chave
  • Primeiro, embeddings são excelentes para capturar similaridade semântica em alto nível, mas podem ter dificuldade com consultas mais específicas e baseadas em palavras-chave, como quando o usuário busca um nome (ex.: Ilya), uma sigla (ex.: RAG) ou um ID (ex.: claude-3-sonnet)
    • A busca baseada em palavras-chave, como BM25, foi projetada explicitamente para isso
    • Como os usuários usam busca por palavras-chave há muito tempo, é provável que a considerem algo natural e fiquem frustrados se o documento que querem encontrar não for retornado
  • Segundo, é mais intuitivo entender por que um documento foi recuperado via busca por palavras-chave
    • Porque é possível verificar as palavras-chave que correspondem à consulta
    • Já a busca baseada em embeddings é menos interpretável
  • Terceiro, graças a sistemas como Lucene e OpenSearch, que foram otimizados e validados em produção ao longo de décadas, a busca por palavras-chave geralmente é mais eficiente em termos computacionais
• Na maioria dos casos, uma abordagem híbrida é a mais eficaz
  • Use correspondência por palavras-chave para matches óbvios, e embeddings para sinônimos, hiperônimos, erros ortográficos e multimodalidade (ex.: imagem e texto)
  • A Shortwave já compartilhou como construiu seu pipeline de RAG, incluindo reescrita de consultas, busca por palavras-chave + embeddings, ranking etc.

Para conhecimento novo, prefira RAG a fine-tuning

• Tanto RAG quanto fine-tuning podem ser usados para integrar novas informações ao LLM e melhorar o desempenho em tarefas específicas
  • Então, qual deles deve ser testado primeiro?
• Vantagens do RAG
  • Pesquisas recentes sugerem que RAG pode ser superior
  • Um estudo comparou RAG e fine-tuning não supervisionado (também chamado de pré-treinamento contínuo), avaliando-os em subconjuntos do MMLU e de atualidades
    • O RAG apresentou desempenho consistentemente melhor do que o fine-tuning tanto para conhecimento visto durante o treinamento quanto para conhecimento totalmente novo
  • Outro artigo comparou RAG e fine-tuning supervisionado em um conjunto de dados agrícolas
    • Da mesma forma, o ganho de desempenho do RAG foi maior do que o do fine-tuning, especialmente no GPT-4 (veja a tabela 20 do artigo)
  • Além da melhora de desempenho, o RAG tem várias vantagens práticas
    • Primeiro, é mais fácil e barato manter um índice de busca atualizado do que fazer pré-treinamento contínuo ou fine-tuning
    • Segundo, se houver documentos problemáticos no índice de busca contendo conteúdo nocivo ou enviesado, é fácil removê-los ou corrigi-los
  • Além disso, o R de RAG oferece um controle mais granular sobre como recuperar documentos
    • Por exemplo, se você hospeda um sistema RAG para várias organizações, pode particionar o índice de busca para que cada organização só possa recuperar documentos do seu próprio índice
    • Isso ajuda a evitar que informações de uma organização sejam expostas por engano a outra

Modelos com contexto longo não tornarão o RAG inútil

• Com o Gemini 1.5 oferecendo uma janela de contexto de até 10 milhões de tokens, alguns começaram a questionar o futuro do RAG
  • Uma janela de contexto de 10 milhões de tokens torna desnecessária boa parte dos frameworks tradicionais de RAG
    • Basta colocar os dados no contexto e conversar com o modelo como de costume
  • Imagine o impacto disso em startups, agentes e projetos com LangChain, nos quais a maior parte do esforço de engenharia é investida em RAG
    • Em uma frase: um contexto de 10 milhões mataria o RAG
• A necessidade contínua de RAG
  • Embora seja verdade que contexto longo pode ser um divisor de águas para casos de uso como análise de vários documentos ou chat com PDFs, os rumores sobre o fim do RAG são muito exagerados
    • Primeiro, mesmo com uma janela de contexto de 10 milhões de tokens, ainda é necessário algum método para selecionar quais informações inserir no modelo
    • Segundo, fora de avaliações muito estreitas do tipo “agulha no palheiro”, ainda não vi dados convincentes de que os modelos consigam raciocinar de forma eficaz sobre contextos tão grandes
    • Portanto, sem uma boa busca (e ranking), há o risco de sobrecarregar o modelo com informações que distraem ou até de preencher toda a janela de contexto com conteúdo completamente irrelevante
• Por fim, há a questão do custo
  • O custo de inferência de Transformers cresce quadraticamente com o comprimento do contexto (ou linearmente tanto em espaço quanto em tempo)
  • Só porque existe um modelo capaz de ler todo o conteúdo do Google Drive de uma organização, isso não significa que seja uma boa ideia fazer isso antes de responder a cada pergunta
  • Considere uma analogia com a forma como usamos RAM
    • Existem instâncias de computação com dezenas de terabytes de RAM, mas ainda assim continuamos lendo e gravando em disco
• Portanto, ainda não jogue o RAG no lixo
  • Esse padrão continuará sendo útil mesmo à medida que as janelas de contexto aumentarem

Tática 3. Ajuste e otimização de workflow

• Dar um prompt a um LLM é apenas o começo
  • Para aproveitar ao máximo um LLM, é preciso ir além de um único prompt e adotar workflows
  • Por exemplo, como dividir uma tarefa única complexa em várias tarefas mais simples?
  • Em que momento fine-tuning ou cache ajudam a melhorar o desempenho e reduzir latência/custo?
• Nesta seção, são compartilhadas estratégias comprovadas e casos práticos para ajudar a otimizar e construir workflows com LLMs

Flows passo a passo e de múltiplos turnos podem oferecer grandes ganhos de desempenho

• Já sabemos que é possível obter resultados melhores decompondo um grande prompt em vários prompts menores
  • AlphaCodium é um exemplo disso
    • Ao mudar de um único prompt para um workflow em múltiplas etapas, elevou a precisão do GPT-4 (pass@5) no CodeContests de 19% para 44%
  • O workflow inclui
    • reflexão sobre o problema
    • raciocínio sobre os testes públicos
    • geração de soluções possíveis
    • ranqueamento das soluções possíveis
    • geração de testes sintéticos
    • iteração das soluções com base em testes públicos e sintéticos
• Tarefas pequenas com objetivos claros produzem os melhores prompts de agente ou de flow
  • Nem todo prompt de agente precisa solicitar saída estruturada, mas saídas estruturadas ajudam bastante na interface com o sistema que coordena a interação do agente com seu ambiente
• Coisas que vale testar
  • Uma etapa explícita de planejamento especificada da forma mais rigorosa possível
    • Considere escolher entre planos predefinidos
  • Reescrever o prompt original do usuário como um prompt de agente
    • Tenha cuidado, pois esse processo pode causar perda de informação
  • Comportamento do agente como cadeia linear, DAG e máquina de estados
    • Diferentes dependências e relações lógicas podem ser mais ou menos adequadas para diferentes escalas
    • Será que dá para extrair otimizações de desempenho de diferentes arquiteturas de tarefas?
  • Validação do plano
    • O plano pode incluir instruções sobre como avaliar as respostas de outros agentes para garantir que o resultado final funcione bem
  • Prompt engineering com estado upstream fixo
    • Certifique-se de que o prompt do agente seja avaliado em relação às diversas variações possíveis que podem ocorrer antes dele

Por enquanto, priorize workflows determinísticos

• Agentes de IA podem reagir dinamicamente às solicitações do usuário e ao ambiente, mas sua natureza não determinística dificulta a implantação
  • Cada etapa executada pelo agente pode falhar, e a chance de se recuperar do erro é baixa
  • Portanto, a probabilidade de um agente concluir com sucesso uma tarefa de múltiplas etapas cai exponencialmente à medida que o número de etapas aumenta
  • Como resultado, equipes que constroem agentes têm dificuldade para colocar em produção agentes confiáveis
• Uma abordagem promissora é ter um sistema de agentes que gere um plano determinístico e o execute de maneira estruturada e reproduzível
  • Na primeira etapa, dado um objetivo de alto nível ou um prompt, o agente gera um plano
  • Em seguida, o plano é executado de forma determinística
  • Isso permite tornar cada etapa mais previsível e confiável
  • Vantagens
    • O plano gerado pode ser usado como amostra few-shot para fazer prompt no agente ou para fine-tuning
    • A execução determinística torna o sistema mais confiável, facilitando testes e depuração. Além disso, as falhas podem ser rastreadas até etapas específicas do plano
    • O plano gerado pode ser representado como um grafo acíclico direcionado (DAG), sendo mais fácil de entender e adaptar a novas situações do que um prompt estático
• Os construtores de agentes mais bem-sucedidos talvez sejam pessoas com forte experiência em gerenciar engenheiros juniores
  • Isso porque o processo de geração de planos é parecido com a forma de orientar e gerenciar profissionais juniores
  • Assim como se dá a um júnior metas claras e planos concretos, em vez de direções vagas e abertas, o mesmo deve ser feito com agentes
• No fim, o núcleo de agentes confiáveis e que realmente funcionem provavelmente será encontrado em
  • adotar uma abordagem mais estruturada e determinística, e
  • coletar dados para melhorar prompts e fazer fine-tuning dos modelos
• Sem isso, você acabará construindo agentes que às vezes funcionam muito bem, mas que em média decepcionam os usuários e acabam tendo baixa retenção

Obtendo variedade nas saídas para além do parâmetro de temperatura

• Suponha que exista uma tarefa em que você precise de diversidade nas saídas do LLM
  • Você pode estar escrevendo um pipeline com LLM para sugerir produtos de um catálogo, considerando a lista de itens que o usuário já comprou anteriormente
  • Ao executar o prompt várias vezes, pode perceber que as recomendações resultantes são parecidas demais
  • Por isso, pode aumentar o parâmetro Temperature (temperatura) na requisição ao LLM
• Ao aumentar o parâmetro de temperatura, as respostas do LLM se tornam mais diversas
  • Durante a amostragem, a distribuição de probabilidade do próximo token fica mais achatada, fazendo com que tokens normalmente menos prováveis sejam escolhidos com mais frequência
• No entanto, ao elevar a temperatura, podem surgir alguns modos de falha relacionados à diversidade das saídas
  • Por exemplo, alguns produtos do catálogo podem ser adequados, mas não aparecerem na saída do LLM
  • Se o LLM tiver alta tendência a seguir o que aprendeu no treinamento, o mesmo pequeno conjunto de produtos pode acabar super-representado nas saídas
  • Se a temperatura ficar alta demais, podem ser geradas saídas que fazem referência a produtos inexistentes (ou a conteúdo sem sentido)
• Aumentar a temperatura não garante que o LLM vá amostrar saídas a partir da distribuição de probabilidade esperada por você (por exemplo, uniforme aleatória)
• Ainda assim, existem outros truques para aumentar a diversidade das saídas
  • O mais simples é ajustar elementos dentro do prompt
    • Por exemplo, se o template do prompt incluir uma lista de itens como histórico de compras, embaralhar a ordem desses itens cada vez que eles forem inseridos no prompt pode fazer uma diferença considerável
  • Manter também uma lista curta de saídas recentes ajuda a evitar duplicação
    • No exemplo de recomendação de produtos, é possível instruir o LLM a evitar sugerir itens que estejam nessa lista recente, ou diversificar ainda mais a resposta rejeitando saídas semelhantes às sugestões recentes e fazendo nova amostragem
  • Outra estratégia eficaz é variar a formulação usada no prompt
    • Por exemplo, incorporar frases como “selecionar itens que o usuário gostaria de usar regularmente” ou “selecionar produtos que o usuário provavelmente recomendaria a um amigo” pode mudar o foco e influenciar a diversidade dos produtos recomendados

Cache é subestimado

• O cache reduz custos ao eliminar a necessidade de recalcular respostas para a mesma entrada e remove a latência de geração
  • Além disso, se a resposta já tiver passado por guardrails anteriormente, é possível entregar essa resposta validada, reduzindo o risco de fornecer conteúdo nocivo ou inadequado
• Uma abordagem simples para cache é usar um ID único para o item que está sendo processado, como ao resumir uma nova matéria ou avaliação de produto
  • Quando uma solicitação chega, é possível verificar se o resumo já existe no cache
    • Se existir, ele pode ser retornado imediatamente; caso contrário, pode ser gerado, passar por guardrails e ser entregue, sendo então armazenado no cache para solicitações futuras
• Para consultas mais abertas, é possível aproveitar o cache mesmo para entradas abertas, tomando emprestadas técnicas da área de busca
  • Recursos como preenchimento automático e correção ortográfica ajudam a normalizar a entrada do usuário para aumentar a taxa de acerto do cache

Quando o finetune é necessário

• Pode haver tarefas para as quais até o prompt mais inteligentemente projetado ainda seja insuficiente
  • Por exemplo, mesmo após um esforço considerável de engenharia de prompt, o sistema ainda pode estar longe de retornar saídas confiáveis e de alta qualidade
  • Nesse caso, talvez seja necessário fazer finetuning do modelo para uma tarefa específica
• Casos de sucesso de fine-tuning
  • Natural Language Query Assistant, da Honeycomb
    • No início, um "manual de programação" era fornecido no prompt junto com exemplos n-shot para aprendizado em contexto
    • Isso funcionava adequadamente, mas ao fazer fine-tuning do modelo é possível obter saídas melhores sobre a sintaxe e as regras da linguagem específica do domínio
  • Lucy, da Rechat
    • O LLM precisava gerar respostas em um formato muito específico, combinando dados estruturados e não estruturados para que o frontend os renderizasse corretamente
    • O fine-tuning foi essencial para fazer isso funcionar de forma consistente
• Embora o fine-tuning possa ser eficaz, ele envolve custos significativos
  • É preciso anotar os dados de fine-tuning, ajustar e avaliar o modelo e, no fim, fazer self-hosting
  • Portanto, é preciso considerar se o custo inicial mais alto realmente vale a pena
• Se for possível chegar a 90% apenas com prompting, talvez não valha a pena investir em fine-tuning
  • Porém, se decidir seguir com fine-tuning, é possível gerar e ajustar com dados sintéticos ou fazer bootstrap com dados open source para reduzir o custo de coletar dados anotados por humanos

Tática 4. Avaliação e monitoramento

• A avaliação de LLMs pode ser um campo minado
  • As entradas e saídas de LLMs são texto arbitrário, e as tarefas que se definem para eles também variam
  • Ainda assim, uma avaliação rigorosa e cuidadosa é importante
    • Não é por acaso que líderes técnicos da OpenAI participam das avaliações e dão feedback sobre avaliações individuais
• A avaliação de aplicações com LLM exige várias definições e reduções
  • Pode ser simplesmente teste unitário, algo mais parecido com observabilidade ou apenas ciência de dados
  • Descobrimos que todas essas perspectivas são úteis
• Nesta seção, apresentamos lições aprendidas sobre o que é importante ao construir um pipeline de avaliação e monitoramento

Gere alguns testes unitários baseados em assertions a partir de amostras reais de entrada e saída

• Crie testes unitários com amostras de entrada e saída da produção (ou seja, assertions) e defina expectativas para a saída com base em pelo menos 3 critérios
  • Três critérios podem parecer arbitrários, mas é um número prático para começar
    • Se houver menos que isso, a tarefa pode não estar suficientemente definida ou pode ser aberta demais, como um chatbot genérico
  • Esses testes unitários ou assertions devem ser acionados por mudanças no pipeline, como edição de prompt, adição de novo contexto via RAG ou outras modificações
• Considere começar com assertions que especifiquem frases ou ideias que devem ser incluídas ou excluídas em todas as respostas
  • Considere também verificações para confirmar se a contagem de palavras, itens ou frases está dentro de uma faixa
  • Para outros tipos de geração, as assertions podem ter outra forma
    • Por exemplo, em avaliação por execução, uma forma robusta de avaliar geração de código, o código gerado é executado e verifica-se se o estado de runtime atende suficientemente à solicitação do usuário
• Por exemplo, se o usuário pedir uma nova função chamada foo, deve ser possível chamar foo após executar o código gerado pelo agente
• Um desafio da avaliação por execução é que o código do agente muitas vezes deixa o runtime em uma forma ligeiramente diferente do código-alvo
  • Pode ser eficaz "afrouxar" a assertion para a hipótese mais fraca que ainda satisfaça qualquer resposta válida
• Usar o produto da maneira pretendida para os clientes (ou seja, fazer "dogfooding") pode trazer insights sobre modos de falha com dados reais
  • Essa abordagem não apenas ajuda a identificar fraquezas potenciais, como também fornece uma fonte útil de amostras de produção que podem ser convertidas em avaliações

LLM-as-Judge pode funcionar (até certo ponto), mas não é uma solução universal

• LLM-as-Judge é uma abordagem que usa um LLM poderoso para avaliar a saída de outro LLM, o que é visto com ceticismo por algumas pessoas
• Ainda assim, quando bem implementado, o LLM-as-Judge pode alcançar uma correlação significativa com o julgamento humano e, pelo menos, ajudar a construir sinais prévios sobre como novos prompts ou técnicas podem se comportar
  • Em especial, em comparações pareadas (por exemplo, grupo de controle vs. grupo de tratamento), o LLM-as-Judge geralmente aponta a direção correta, embora a magnitude da vitória/derrota possa ser ruidosa
• Sugestões para aproveitar melhor o LLM-as-Judge
  • Usar comparações pareadas
    • Em vez de pedir ao LLM para avaliar uma única saída em uma escala de Likert, apresente duas opções e peça que ele escolha a melhor
    • Isso tende a produzir resultados mais estáveis
  • Controlar o viés de posição
    • A ordem das opções apresentadas pode enviesar a decisão do LLM
    • Para mitigar isso, execute cada comparação pareada duas vezes e inverta a ordem do par em cada uma
    • Depois da troca, a vitória deve ser atribuída à opção correta
  • Permitir empate
    • Em alguns casos, as duas opções podem ser igualmente boas
    • Portanto, permita que o LLM declare empate, para que ele não precise escolher um vencedor de forma arbitrária
  • Usar Chain-of-Thought
    • Pedir ao LLM para explicar sua decisão antes de apresentar a preferência final pode melhorar a confiabilidade da avaliação
    • Como bônus, isso permite usar um LLM mais fraco, porém mais rápido, e ainda assim obter resultados semelhantes
    • Como essa parte do pipeline costuma ficar em modo batch, a latência extra causada por CoT não é um problema
  • Controlar o tamanho da resposta
    • LLMs tendem a favorecer respostas mais longas
    • Para mitigar isso, verifique se o tamanho do par de respostas é semelhante
• Uma aplicação particularmente poderosa de LLM-as-Judge é verificar regressões em novas estratégias de prompt
  • Se você tiver acompanhado um conjunto de resultados de produção, às vezes é possível executar novamente esses exemplos com uma nova estratégia de prompt e usar LLM-as-Judge para avaliar rapidamente onde a nova estratégia pode ter dificuldades
• Exemplo de uma abordagem simples, mas eficaz, de LLM-as-Judge
  • Basta registrar a resposta do LLM, a crítica do juiz (ou seja, o CoT) e o resultado final
  • Em seguida, revisar isso com as partes interessadas para identificar áreas de melhoria
  • Após 3 iterações, a concordância entre humanos e LLM melhorou de 68% para 94%
• No entanto, LLM-as-Judge não é uma solução universal
  • Mesmo os modelos mais poderosos têm dificuldade em avaliar com confiabilidade aspectos linguísticos sutis
• Também descobrimos que classificadores tradicionais e reward models podem alcançar maior precisão do que LLM-as-Judge, com menor custo e latência
  • No caso de geração de código, LLM-as-Judge pode ser inferior a estratégias de avaliação mais diretas, como avaliação por execução

Teste do estagiário para avaliar resultados gerados

• Ao avaliar resultados gerados, é bom usar o seguinte “teste do estagiário”
  • Se você pegasse a entrada exata para o modelo de linguagem, incluindo o contexto, e a desse como tarefa a um estudante universitário mediano da área relevante, ele conseguiria ter sucesso?
  • Quanto tempo levaria?
• Se a resposta for não
  • Se for porque falta ao LLM o conhecimento necessário, considere formas de enriquecer o contexto
  • Se isso não puder ser resolvido nem com melhorias no contexto, pode ser uma tarefa difícil demais para os LLMs atuais
• Se a resposta for sim, mas demorar
  • Você pode tentar reduzir a complexidade da tarefa
    • Dá para decompor?
    • Quais aspectos da tarefa podem ser mais padronizados?
• Se a resposta for sim e puder ser feito rapidamente
  • Ao investigar os dados
    • Em que o modelo está errando?
    • Dá para encontrar padrões de falha?
  • Tente pedir ao modelo para se explicar antes ou depois da resposta

Dar peso excessivo a uma avaliação específica pode prejudicar o desempenho geral

“Quando uma métrica vira meta, ela deixa de ser uma boa métrica.” — Lei de Goodhart

• Um exemplo disso é a avaliação Needle-in-a-Haystack (NIAH)
  • A avaliação original ajudava a quantificar o recall do modelo à medida que o tamanho do contexto aumentava e a verificar como a posição da agulha afetava esse recall
  • Porém, ela acabou recebendo ênfase excessiva, a ponto de aparecer como Figure 1 no relatório do Gemini 1.5
  • Essa avaliação consiste em inserir uma frase específica (“The special magic {city} number is: {number}”) em um documento longo com repetição de ensaios de Paul Graham e depois pedir ao modelo para lembrar o número mágico
• Alguns modelos atingem recall quase perfeito, mas é questionável se o NIAH realmente reflete as capacidades de raciocínio e recall necessárias em aplicações reais
• Considere cenários mais práticos
  • Dada a transcrição de uma reunião de 1 hora, o LLM consegue resumir as decisões principais e os próximos passos, atribuindo corretamente cada item ao responsável relevante?
  • Essa tarefa é mais realista porque vai além da simples memorização e também considera a capacidade de compreender discussões complexas, identificar informações relevantes e sintetizar um resumo
• Exemplo de avaliação NIAH prática
  • Usar a transcrição de uma videochamada entre médico e paciente para fazer perguntas ao LLM sobre a medicação do paciente
  • Incluir também um NIAH mais desafiador, como inserir frases sobre ingredientes aleatórios necessários para coberturas de pizza, como tâmaras embebidas em espresso, limão e queijo de cabra
  • No trabalho sobre medicação, o recall ficou em cerca de 80%; no trabalho sobre pizza, em 30%
• Dar ênfase excessiva à avaliação NIAH pode reduzir o desempenho em tarefas de extração e resumo
  • Como esses LLMs são ajustados finamente para prestar atenção a todas as frases, eles podem começar a tratar detalhes irrelevantes e distrações como se fossem importantes
  • Isso pode acabar entrando na saída final (mesmo quando não deveria!)
• Isso também pode se aplicar a outras avaliações e casos de uso
  • Por exemplo, em resumo
    • Enfatizar a consistência factual pode gerar resumos menos específicos e, portanto, com menor chance de contrariar os fatos, mas também menos relevantes
    • Por outro lado, enfatizar estilo de escrita e eloquência pode gerar uma linguagem mais floreada, do tipo marketing, que pode causar inconsistências factuais

Simplifique a anotação para tarefas binárias ou comparações em pares

• Dar feedback aberto sobre a saída do modelo ou avaliá-la em uma escala Likert é cognitivamente exigente
  • Como resultado, os dados coletados tendem a ser mais ruidosos devido à variação entre avaliadores humanos e, portanto, menos úteis
• Uma abordagem mais eficaz é simplificar a tarefa e reduzir a carga cognitiva dos anotadores
  • Duas tarefas que funcionam bem são a classificação binária e a comparação em pares
• Na classificação binária, pede-se ao anotador que faça um julgamento simples de sim/não sobre a saída do modelo
  • Você pode perguntar se o resumo gerado é factualmente consistente com o documento-fonte, se a resposta proposta é relevante, se contém conteúdo nocivo etc.
  • Em comparação com a escala Likert, decisões binárias são mais precisas, têm maior consistência entre avaliadores e maior taxa de processamento
  • Como o DoorDash configurou uma fila de rotulagem para etiquetar itens de menu por meio de uma série de perguntas de sim/não
• Na comparação em pares (Pairwise Comparison), o anotador recebe um par de respostas do modelo e é perguntado qual delas é melhor
  • Como é mais fácil para humanos dizer “A é melhor que B” do que dar uma nota individual para A ou B, isso leva a anotações mais rápidas e confiáveis (do que em escala Likert)
• Em um meetup do Llama2, Thomas Scialom, um dos autores do artigo do Llama2, confirmou que comparações em pares são mais rápidas e baratas do que coletar dados de ajuste fino supervisionado, como respostas escritas
  • A primeira custa $3.5 por unidade e a segunda $25 por unidade

Avaliações sem referência (Reference-free) e guardrails podem ser usados de forma intercambiável

• Guardrails ajudam a barrar conteúdo inadequado ou nocivo, enquanto avaliações ajudam a medir a qualidade e a precisão das saídas do modelo
  • No caso de avaliações sem referência, elas podem ser vistas como dois lados da mesma moeda
    • Uma avaliação sem referência é uma avaliação capaz de julgar a qualidade da saída usando apenas o prompt de entrada e a resposta do modelo, sem depender de uma referência “golden”, como uma resposta escrita por humanos
• Exemplo de avaliação sem referência: avaliação de resumo
  • Basta considerar o documento de entrada para avaliar a consistência factual e a relevância do resumo
  • Se o resumo tiver pontuação baixa nessas métricas, você pode optar por não mostrá-lo ao usuário, usando a avaliação efetivamente como guardrail
• Avaliação “de tradução” sem referência:
  • É possível avaliar a qualidade da tradução sem uma referência traduzida por humanos e, novamente, usá-la como guardrail

LLMs retornam saída mesmo quando não deveriam

• Um dos principais desafios ao trabalhar com LLMs é que eles frequentemente geram saída mesmo quando não deveriam
  • Isso pode levar a respostas inofensivas, porém sem sentido, ou a falhas mais graves, como conteúdo nocivo ou perigoso
  • Por exemplo, ao receber a solicitação de extrair um atributo ou metadado específico de um documento, o LLM pode retornar com confiança um valor mesmo quando ele na verdade não existe
  • Ou o modelo pode responder em um idioma diferente do inglês porque foi fornecido contexto com um documento em outro idioma
• Você pode instruir o LLM, via prompt, a retornar respostas como “não aplicável” ou “não sei”, mas isso não é perfeito
  • Mesmo quando é possível usar log probabilities, elas são um indicador ruim da qualidade da saída
    • Log probabilities indicam a probabilidade de tokens aparecerem na saída, mas não refletem a exatidão do texto gerado
  • Além disso, no caso de modelos instruction-tuned treinados para responder a consultas e gerar respostas coerentes, as log probabilities podem não estar bem calibradas
    • Portanto, log probabilities altas podem indicar que a saída é fluida e coerente, mas não significam que ela seja precisa ou relevante
• Uma engenharia de prompt cuidadosa pode ajudar até certo ponto, mas deve ser complementada por guardrails robustos para detectar e filtrar/regenerar saídas indesejadas
  • Por exemplo, a OpenAI oferece uma API de moderação de conteúdo capaz de identificar respostas inseguras, como discurso de ódio, automutilação ou saídas sexuais
  • Da mesma forma, existem inúmeros pacotes para detectar informações de identificação pessoal (PII)
• Uma vantagem dos guardrails é que eles são amplamente independentes do caso de uso e, portanto, podem ser aplicados de forma ampla a qualquer saída em um idioma específico
  • Além disso, com recuperação de alta precisão, se não houver documentos relevantes, o sistema pode responder de forma definitiva “não sei”
• LLMs também podem falhar em gerar saída quando se espera uma
  • Isso pode acontecer por vários motivos, desde problemas simples como alta latência do provedor de API até problemas mais complexos, como a saída ser bloqueada por filtros de moderação de conteúdo
• Portanto, é importante registrar de forma consistente as entradas e, potencialmente, a ausência de saídas para fins de depuração e monitoramento

Alucinação (Hallucination) é um problema persistente

• Falhas de segurança de conteúdo ou de PII recebem tanta atenção que quase não ocorrem, enquanto inconsistências factuais persistem de forma teimosa e são mais difíceis de detectar
  • Elas ocorrem com mais frequência, com taxa-base de 5–10%, e, pelo que aprendemos com fornecedores de LLM, pode ser difícil reduzi-las para menos de 2% mesmo em tarefas simples como sumarização
• Para resolver isso, é possível combinar engenharia de prompt (upstream da geração) com guardrails de inconsistência factual (downstream da geração)
  • No caso da engenharia de prompt, técnicas como CoT ajudam a reduzir alucinações ao fazer com que o LLM explique seu raciocínio antes de retornar a saída final
  • Em seguida, é possível aplicar guardrails de inconsistência factual para avaliar a fidelidade do resumo e filtrar ou regenerar alucinações
• Em alguns casos, alucinações podem ser detectadas de forma determinística
  • Ao usar recursos de recuperação de RAG, se a saída estiver estruturada e você souber quais são os recursos, deve ser possível verificar manualmente se ela foi de fato extraída do contexto de entrada

[Operações: questões do dia a dia e organizacionais ]

Operações 1. Dados

• Assim como a qualidade dos ingredientes determina o sabor de um prato, a qualidade dos dados de entrada limita o desempenho de um sistema de machine learning
• Além disso, os dados de saída são a única forma de saber se o produto está funcionando
• Todos os autores examinam cuidadosamente entradas e saídas por algumas horas toda semana para entender melhor a distribuição dos dados (modos, casos de borda, limitações do modelo)

Verificar desvio entre desenvolvimento e produção

• Em pipelines tradicionais de machine learning, uma causa comum de erro é o desvio entre treinamento e serviço
  • Isso acontece quando os dados usados no treinamento diferem dos dados que o modelo encontra em produção
• Como é possível usar LLMs sem treinamento ou fine-tuning, não existe conjunto de treinamento, mas surge um problema semelhante: o desvio entre dados de desenvolvimento e produção
  • Em essência, os dados usados para testar o sistema durante o desenvolvimento devem refletir os dados que o sistema enfrentará em produção
    • Caso contrário, a precisão em produção pode cair
• O desvio entre desenvolvimento e produção em LLMs pode ser classificado em dois tipos: desvio estrutural e desvio baseado em conteúdo
  • O desvio estrutural inclui problemas como incompatibilidade de formato, por exemplo diferenças entre dicionários JSON com valores em lista e listas JSON, capitalização inconsistente e erros como typos ou fragmentos de frase
    • Esses erros podem levar a um desempenho imprevisível do modelo, porque diferentes LLMs são treinados com formatos específicos de dados e os prompts podem ser muito sensíveis a mudanças triviais
  • O desvio baseado em conteúdo, ou "semântico", refere-se a diferenças de significado ou contexto nos dados
• Assim como no ML tradicional, é útil medir periodicamente o desvio entre pares de entrada e saída de LLMs
  • Métricas simples, como comprimento de entrada e saída ou exigências específicas de formato (por exemplo, JSON ou XML), são uma forma simples de acompanhar mudanças
• Para detectar desvios mais "avançados", considere agrupar embeddings de pares de entrada e saída para identificar desvios semânticos, como mudanças nos tópicos discutidos pelos usuários, que podem indicar que eles estão explorando áreas às quais o modelo não foi exposto anteriormente
• Ao testar mudanças como engenharia de prompt, confirme que o conjunto de dados holdout está atualizado e reflete os tipos mais recentes de interação dos usuários
  • Por exemplo, se typos são comuns nas entradas em produção, eles também devem estar presentes nos dados holdout
• Além de simplesmente medir o desvio com números, é benéfico realizar avaliações qualitativas das saídas
  • Revisar regularmente as saídas do modelo — prática conhecida informalmente como "vibe check" — ajuda a garantir que os resultados estejam de acordo com as expectativas e continuem relevantes para as necessidades dos usuários
• Também é útil incorporar não determinismo à verificação de desvio
  • Ao executar o pipeline várias vezes para cada entrada do conjunto de teste e analisar todas as saídas, aumenta-se a chance de capturar anomalias que podem ocorrer apenas ocasionalmente

Verificar diariamente amostras de entradas e saídas de LLMs

• Os LLMs são dinâmicos e estão em constante evolução
  • Apesar da impressionante capacidade zero-shot e de saídas frequentemente agradáveis, os modos de falha dos LLMs são muito imprevisíveis
• Para tarefas personalizadas, revisar regularmente amostras de dados é essencial para desenvolver uma compreensão intuitiva do desempenho do LLM
  • Os pares de entrada e saída em produção são o "objeto real, no lugar real" (genchi genbutsu) das aplicações com LLM e não têm substituto
• Pesquisas recentes destacam que, quanto mais os desenvolvedores interagem com dados, mais sua percepção do que é uma saída "boa" e uma saída "ruim" muda (ou seja, desvio de critério)
  • Os desenvolvedores podem definir previamente alguns critérios para avaliar saídas de LLMs, mas esses critérios predefinidos costumam ser incompletos
• Por exemplo, durante o desenvolvimento, pode-se atualizar o prompt para aumentar a probabilidade de boas respostas e reduzir a probabilidade de respostas ruins
  • Esse processo iterativo de avaliação, reavaliação e atualização de critérios é necessário porque é difícil prever o comportamento do LLM ou as preferências humanas sem observar diretamente as saídas
• Para gerenciar isso com eficácia, é preciso registrar as entradas e saídas do LLM
  • Inspecionar diariamente amostras desses logs permite identificar e se adaptar rapidamente a novos padrões ou modos de falha
  • Ao descobrir um novo problema, você pode imediatamente escrever uma assertion ou eval para ele
• Da mesma forma, qualquer atualização na definição de modos de falha deve ser refletida nos critérios de avaliação
  • Esses "vibe checks" são sinais de saídas incorretas, e o código e as assertions operacionalizam isso
• Por fim, essa postura deve ser socializada
  • Por exemplo, adicionando revisão ou anotação de entradas e saídas à rotação de on-call

Operações 2. Trabalhar com modelos

• Ao usar APIs de LLM, você pode depender da inteligência de um pequeno número de fornecedores
  • Isso é positivo, mas essa dependência envolve trade-offs em termos de desempenho, latência, throughput e custo
• Além disso, como ao longo do último ano modelos mais novos e melhores foram lançados quase todos os meses, é preciso estar pronto para atualizar o produto ao descontinuar modelos antigos e migrar para novos
  • Esta seção compartilha lições aprendidas ao usar uma tecnologia sobre a qual você não tem controle total, isto é, uma tecnologia cujo modelo você não pode hospedar nem gerenciar por conta própria
• Na maioria dos casos de uso reais, a saída do LLM será consumida por aplicações downstream por meio de algum tipo de formato legível por máquina
  • Por exemplo, o ReChat, um CRM imobiliário, exige respostas estruturadas para renderizar widgets no frontend
  • Da mesma forma, o Boba, uma ferramenta de geração de ideias de estratégia de produto, requer saída estruturada com campos de título, resumo, pontuação de viabilidade e horizonte de tempo
  • Por fim, o LinkedIn compartilhou como restringiu um LLM para gerar YAML, usado para decidir qual técnica utilizar e fornecer os parâmetros para chamar essa técnica
• Esse padrão de aplicação é uma versão extrema da lei de Postel
  • Seja liberal no que aceita (linguagem natural arbitrária) e conservador no que envia (objetos tipados e legíveis por máquina)
  • Portanto, espera-se que isso seja muito durável
• Atualmente, Instructor e Outlines são os padrões de facto para extrair saídas estruturadas de LLMs
  • Se você usa APIs de LLM (por exemplo, Anthropic, OpenAI), use Instructor; se usa modelos hospedados por conta própria (por exemplo, Huggingface), use Outlines

Migrar prompts entre modelos é doloroso

• Às vezes, um prompt cuidadosamente elaborado funciona muito bem em um modelo, mas não funciona direito em outro
  • Isso pode acontecer não só ao trocar entre diferentes provedores de modelos, mas também ao atualizar entre versões do mesmo modelo
• Por exemplo, a Voiceflow descobriu que, ao migrar de gpt-3.5-turbo-0301 para gpt-3.5-turbo-1106, houve uma queda de 10% no desempenho em tarefas de classificação de intenção
  • (Felizmente, eles tinham avaliações!)
• De forma semelhante, a GoDaddy observou uma tendência positiva ao atualizar para a versão 1106, com a redução da diferença de desempenho entre gpt-3.5-turbo e gpt-4
  • (Ou, se você é do tipo que vê o copo meio cheio, talvez fique decepcionado ao ver a vantagem do gpt-4 diminuir com a nova atualização)
• Portanto, se você precisar migrar prompts entre modelos, deve esperar que isso leve mais tempo do que simplesmente trocar o endpoint da API
  • Não assuma que conectar o mesmo prompt levará a resultados semelhantes ou melhores
• Além disso, avaliações confiáveis e automatizadas ajudam a medir o desempenho da tarefa antes e depois da migração e reduzem o esforço necessário para a validação manual

Versionamento e fixação de modelos

• Em qualquer pipeline de machine learning, "se você mudar qualquer coisa, tudo muda"
  • Isso é especialmente relevante quando dependemos de componentes como grandes modelos de linguagem (LLMs), que não treinamos nós mesmos e que podem mudar sem o nosso conhecimento
• Felizmente, muitos provedores de modelos oferecem a opção de "fixar" uma versão específica do modelo, como gpt-4-turbo-1106
  • Isso permite usar uma versão específica dos pesos do modelo para que ela não mude
• Fixar a versão do modelo em produção pode evitar mudanças inesperadas no comportamento do modelo
  • Isso pode ajudar a evitar reclamações de clientes sobre problemas como saídas excessivamente prolixas ou outros modos de falha inesperados que podem surgir quando o modelo é substituído
• Também vale considerar manter um "pipeline sombra" que espelhe a configuração de produção, mas use a versão mais recente do modelo
  • Isso permite experimentação e testes seguros com novos lançamentos
• Depois de validar a estabilidade e a qualidade das saídas nesses novos modelos, você pode atualizar com confiança a versão do modelo em produção

Escolher o menor modelo capaz de concluir a tarefa

• Ao trabalhar em uma nova aplicação, é tentador usar o maior e mais poderoso modelo disponível
  • No entanto, depois que fica confirmado que a tarefa é tecnicamente viável, vale a pena experimentar se é possível obter resultados semelhantes com um modelo menor
• As vantagens dos modelos menores são menor latência e menor custo
  • Eles podem ser mais fracos, mas técnicas como Chain-of-Thought, prompts n-shot e aprendizado em contexto podem ajudar modelos menores a ir além da sua capacidade aparente
• Além das APIs de LLM, o fine-tuning para tarefas específicas também pode ajudar a melhorar o desempenho
• Em conjunto, um fluxo de trabalho cuidadosamente projetado com modelos menores pode ser mais rápido e barato, ao mesmo tempo em que iguala ou até supera a qualidade de saída de um único modelo grande
  • Por exemplo, este tuíte compartilha um relato sobre como Haiku + prompt 10-shot supera Opus em zero-shot e GPT-4
• No longo prazo, espera-se que surjam mais casos de engenharia de fluxo com modelos menores, buscando o melhor equilíbrio entre qualidade de saída, latência e custo
• Outro exemplo é a humilde tarefa de classificação
  • Modelos leves como DistilBERT (67 milhões de parâmetros) são uma baseline surpreendentemente forte
  • DistilBART, com 400 milhões de parâmetros, é outra excelente opção
    • Quando ajustado com fine-tuning em dados open source, ele pode identificar alucinações com ROC-AUC de 0,84, superando a maioria dos LLMs com menos de 5% da latência e do custo
• A lição é que modelos pequenos não devem ser ignorados
  • É fácil aplicar modelos gigantes a todo problema, mas com um pouco de criatividade e experimentação muitas vezes conseguimos encontrar soluções mais eficientes

Operações 3. Produto

• Novas tecnologias trazem novas possibilidades, mas os princípios para criar grandes produtos são atemporais
  • Portanto, mesmo que estejamos resolvendo um problema novo pela primeira vez, não há necessidade de reinventar a roda no design de produto
• Há muito a ganhar ao basear o desenvolvimento de aplicações com LLM em fundamentos sólidos de produto
  • Isso nos permite entregar valor real às pessoas que atendemos

Envolver o design desde o início

• Ter designers faz com que entendamos e pensemos profundamente sobre como construir o produto e apresentá-lo aos usuários
  • Às vezes existe o estereótipo de que designers são apenas pessoas que deixam as coisas bonitas
  • Mas eles repensam não só a interface do usuário, como também como melhorar a experiência do usuário, mesmo que isso signifique romper regras e paradigmas existentes
• Designers têm um talento especial para reformular as necessidades dos usuários em diferentes formas
  • Algumas dessas formas são mais fáceis de resolver do que outras, o que pode criar mais ou menos oportunidades para soluções com IA
• Como acontece com muitos outros produtos, construir produtos de IA deve girar em torno do trabalho a ser realizado, e não da tecnologia que move o produto
• Foque em fazer a si mesmo perguntas como
  • "Qual é o trabalho que os usuários pedem a este produto para fazer? Isso é algo em que um chatbot seria bom? E autocompletar? Talvez seja outra coisa!"
• Considere padrões de design existentes e como eles se relacionam com o trabalho a ser feito
  • Esses são ativos valiosos que os designers agregam às capacidades da equipe

Projetar UX para human-in-the-loop

• Uma forma de obter anotações de alta qualidade é integrar Human-in-the-Loop (HITL) à experiência do usuário (UX)
  • Ao permitir que os usuários forneçam feedback e correções com facilidade, é possível melhorar a saída imediata e coletar dados úteis para aprimorar o modelo
• Imagine uma plataforma de e-commerce em que os usuários enviam e classificam produtos
  • Há várias formas de projetar a UX
    1. O usuário seleciona manualmente a categoria correta do produto, e o LLM verifica periodicamente os novos produtos e corrige classificações incorretas no backend
    2. O usuário não seleciona categoria nenhuma, e o LLM classifica periodicamente os produtos no backend (com possíveis erros)
    3. O LLM sugere a categoria do produto em tempo real, e o usuário pode validar e atualizar quando necessário
• As três abordagens incluem um LLM, mas oferecem UXs muito diferentes
  • A primeira abordagem transfere a carga inicial para o usuário, e o LLM atua como uma verificação posterior
  • A segunda abordagem não exige nenhum esforço do usuário, mas não oferece transparência nem controle
  • A terceira abordagem mantém um equilíbrio adequado
    • Ao sugerir categorias antecipadamente, o LLM reduz a carga cognitiva do usuário, que não precisa aprender nossa taxonomia para classificar produtos
    • Ao mesmo tempo, ao permitir que o usuário revise e edite as sugestões, a decisão final sobre como o produto será classificado permanece firmemente nas mãos dele
  • Como bônus, a terceira abordagem cria um loop de feedback natural para melhorar o modelo
    • Boas sugestões são aceitas (rótulo positivo) e sugestões ruins são atualizadas (rótulo negativo seguido de positivo)
• Esse padrão de sugestão, validação pelo usuário e coleta de dados aparece com frequência em vários aplicativos
  • Assistentes de programação: o usuário pode aceitar a sugestão (positivo forte), aceitar e ajustar (positivo) ou ignorar (negativo)
  • Midjourney: o usuário pode fazer upscale e baixar a imagem (positivo forte), alterar a imagem (positivo) ou gerar um novo conjunto de imagens (negativo)
  • Chatbots: o usuário pode dar curtir (positivo) ou não curtir (negativo) para uma resposta, ou optar por regenerá-la se ela for realmente ruim (negativo forte)
• O feedback pode ser explícito ou implícito
  • Feedback explícito é a informação fornecida pelo usuário em resposta a uma solicitação do produto
  • Feedback implícito é a informação aprendida a partir da interação do usuário sem que ele precise fornecer feedback intencionalmente
• Assistentes de programação e Midjourney são exemplos de feedback implícito, e curtidas e não curtidas são feedback explícito
  • Se a UX for bem projetada, como nos assistentes de programação e no Midjourney, é possível coletar muito feedback implícito para melhorar o produto e o modelo

Priorizar sem piedade a hierarquia de requisitos

• Ao pensar em colocar uma demo em produção, é preciso considerar requisitos sobre o seguinte
  • Confiabilidade: 99,9% de uptime, conformidade com saída estruturada
  • Inofensividade: não gerar conteúdo ofensivo, NSFW ou outros conteúdos nocivos
  • Consistência factual: manter fidelidade ao contexto fornecido e não distorcer fatos
  • Utilidade: ser relevante para as necessidades e solicitações do usuário
  • Escalabilidade: SLA de latência, volume de processamento suportado
  • Custo: porque o orçamento não é ilimitado
  • Outros: segurança, privacidade, equidade, GDPR, DMA etc.
• Se você tentar resolver todos esses requisitos de uma vez, não conseguirá lançar nada
  • Por isso, é preciso priorizar. Sem piedade.
• Isso significa deixar claro o que é inegociável, aquilo sem o qual o produto pode não funcionar ou não ser viável (por exemplo, confiabilidade, inofensividade)
  • É importante identificar um produto MVP (Minimum Lovable Product)
• É preciso aceitar que a primeira versão não será perfeita, lançar e iterar

Ajustar o nível de tolerância a risco de acordo com o caso de uso

• Ao decidir o nível de revisão de modelos de linguagem e aplicações, é preciso considerar o caso de uso e o público-alvo
  • No caso de um chatbot voltado ao cliente que fornece aconselhamento médico ou financeiro, é necessário um padrão muito elevado de segurança e precisão
    • Erros ou saídas incorretas podem causar danos reais e levar à perda de confiança
  • Já em aplicações menos críticas, como sistemas de recomendação, ou aplicações internas, como classificação de conteúdo ou sumarização, requisitos excessivamente rigorosos só atrasam o progresso sem agregar muito valor
• Isso está alinhado com um relatório recente da a16z, segundo o qual muitas empresas estão avançando mais rápido com aplicações internas de LLM do que com aplicações externas
  • Ao experimentar IA para produtividade interna, as organizações podem começar a capturar valor enquanto aprendem a gerenciar riscos em um ambiente mais controlado
  • Depois, quando ganharem confiança, podem expandir para casos de uso voltados ao cliente

Operações 4. Equipes e papéis (Roles)

• Nenhum cargo é fácil de definir, mas escrever uma descrição de cargo para esse novo campo é ainda mais difícil do que em outras áreas
  • Vou deixar de lado diagramas de Venn de cargos sobrepostos ou sugestões de descrições de cargo
  • No entanto, vou reconhecer a existência do novo papel de engenheiro de IA e discutir esse papel
• O importante é discutir como o restante da equipe e as responsabilidades devem ser distribuídos

Foco no processo, não nas ferramentas

• Diante de novos paradigmas como os LLMs, engenheiros de software tendem a preferir ferramentas
  • Como resultado, acabam ignorando os problemas e processos que essas ferramentas estavam tentando resolver
  • Ao fazer isso, muitos engenheiros assumem uma complexidade acidental, o que gera consequências negativas para a produtividade de longo prazo da equipe
• Por exemplo, este artigo explica como determinadas ferramentas podem gerar prompts automaticamente para grandes modelos de linguagem
  • Ele argumenta que engenheiros que usam essas ferramentas sem antes entender a metodologia ou o processo de resolução do problema acabam criando dívida técnica desnecessária (na minha opinião, com razão)
• Além da complexidade acidental, as ferramentas muitas vezes são insuficientemente especificadas
  • Por exemplo, está crescendo uma indústria de ferramentas de avaliação de LLM que oferece uma “caixa de ferramentas de avaliação de LLM” com avaliadores genéricos para nocividade, concisão, tom etc.
  • Vejo muitas equipes adotando essas ferramentas sem pensar criticamente sobre os modos de falha específicos de seus próprios domínios
• Em contraste, o EvalGen se concentra em ensinar ao usuário o processo de criação de avaliações específicas de domínio, envolvendo-o profundamente em cada etapa, como definição de critérios, rotulagem de dados e verificação da avaliação
  • O software orienta o usuário por um fluxo de trabalho como o seguinte
• Boas práticas de criação de avaliações de LLM orientadas pelo EvalGen
  1. Definir testes específicos de domínio (inicializados automaticamente a partir dos prompts)
     • Definidos como assertions em código ou com LLM-as-a-Judge
  2. A importância de alinhar os testes ao julgamento humano para que o usuário possa verificar se eles capturam os critérios especificados
  3. Iterar os testes conforme o sistema (prompts etc.) muda
• O EvalGen fornece aos desenvolvedores um modelo mental do processo de construção de avaliações, mas não os prende a uma ferramenta específica
  • Depois de dar esse contexto a engenheiros de IA, muitas vezes descobrimos que eles optam por ferramentas mais simples ou decidem construir as próprias
• Além de escrita de prompts e avaliação, há tantos componentes em LLMs que não dá para listar todos aqui
  • Ainda assim, é importante que engenheiros de IA procurem entender o processo antes de adotar ferramentas

Sempre experimentar

• Produtos de ML estão profundamente ligados à experimentação
  • Isso significa não apenas testes A/B e ensaios controlados aleatórios, mas também tentativas frequentes de modificar o menor componente possível do sistema e realizar avaliações offline
  • O motivo de todo mundo ser obcecado por avaliação não é, na prática, confiabilidade e confiança, e sim viabilizar a experimentação!
    • Quanto melhor a avaliação, mais rápido é possível iterar nos experimentos e, portanto, mais rápido o sistema converge para sua melhor versão
• Como os experimentos ficaram muito baratos, é comum tentar várias abordagens para resolver o mesmo problema
  • O alto custo de coleta de dados e treinamento de modelos foi minimizado
    • O custo de engenharia de prompt é pouco mais do que tempo humano
  • Estruture a equipe para que todos possam aprender o básico de engenharia de prompt
    • Isso incentiva todos a experimentar e leva a uma diversidade de ideias em toda a organização
• Não use experimentos apenas para exploração; use-os também para aproveitamento!
  • Você já tem uma versão funcional de uma nova tarefa?
    • Vale considerar que outra pessoa da equipe a aborde de uma forma diferente
  • Tente de outro jeito que possa ser mais rápido
  • Pesquise técnicas de prompt como Chain-of-Thought e Few-Shot para aumentar a qualidade
  • Não deixe que as ferramentas atrapalhem os experimentos
    • Se isso acontecer, compre algo que possa substituir ou melhorar o que foi reconstruído
• Durante o planejamento de produto/projeto, reserve tempo específico para construir avaliações e realizar vários experimentos
  • Pense nas especificações do produto para um produto de engenharia e adicione a elas critérios claros de avaliação
• Ao montar o roadmap, não subestime o tempo necessário para experimentação
  • Espere várias iterações de desenvolvimento e avaliação antes de receber aprovação para produção

Capacite todos a usar novas tecnologias de AI

• À medida que a adoção de AI generativa cresce, você vai querer que não apenas especialistas, mas a equipe inteira sinta que entende e consegue usar essa nova tecnologia
  • Não há maneira melhor de desenvolver intuição sobre como LLMs funcionam (por exemplo, latência, modos de falha, UX)
  • LLMs são relativamente acessíveis
    • Não é preciso saber programar para contribuir com a melhoria de desempenho de um pipeline; todos podem contribuir por meio de engenharia de prompt e avaliação
• Grande parte disso é educação
  • É possível começar pelos fundamentos de engenharia de prompt, como técnicas de n-shot prompting e CoT, que ajudam a condicionar o modelo na direção do output desejado
• Pessoas com conhecimento também podem ensinar aspectos mais técnicos, como o fato de LLMs serem inerentemente autorregressivos
  • Ou seja, os tokens de entrada são processados em paralelo, mas os tokens de saída são gerados sequencialmente
  • Portanto, a latência é função do comprimento da saída, e não do comprimento da entrada
    • Isso é uma consideração central ao projetar UX e definir expectativas de desempenho
• Você também pode oferecer oportunidades práticas de experimentação e exploração
  • Que tal hackathons?
    • Pode parecer caro fazer a equipe inteira passar alguns dias hackeando projetos especulativos, mas os resultados podem surpreender
  • Houve equipe que praticamente concluiu um roadmap de 3 anos em 1 ano por meio de hackathons
    • Outra equipe chegou, por meio de hackathons, a uma UX que mudou de paradigma e que agora se tornou possível graças aos LLMs, e isso virou prioridade para este ano e além

Não caia na armadilha de achar que "engenharia de AI é tudo"

• Quando surge um novo cargo, no início há uma tendência de superestimar as capacidades associadas a esse papel
  • Isso frequentemente leva a correções dolorosas à medida que o escopo real desse trabalho fica mais claro
  • Novatos na área e gestores de contratação podem fazer afirmações exageradas ou criar expectativas excessivas
• Alguns exemplos marcantes dos últimos 10 anos são os seguintes
  • Cientista de dados: "alguém melhor em estatística do que qualquer engenheiro de software e melhor em engenharia de software do que qualquer estatístico"
  • Engenheiro de machine learning (MLE): uma visão centrada em engenharia de software aplicada a machine learning
• No início, muita gente supunha que bastavam cientistas de dados para projetos orientados por dados
  • Mas ficou claro que cientistas de dados precisam colaborar com engenheiros de software e de dados para desenvolver e implantar produtos de dados de forma eficaz
• Esse mal-entendido reapareceu com o novo papel de engenheiro de AI, e algumas equipes acreditam que engenheiros de AI são tudo de que precisam
  • Na prática, construir produtos de machine learning ou AI exige uma ampla gama de papéis especializados
• Consultamos mais de 12 empresas sobre produtos de AI e observamos de forma consistente que elas caem na armadilha de acreditar que "engenharia de AI é tudo de que precisam"
  • Como resultado, os produtos muitas vezes têm dificuldade para evoluir além de demos, enquanto aspectos críticos necessários para construir o produto acabam sendo ignorados
• Por exemplo, avaliação e mensuração são cruciais para expandir um produto para além de um mero Vibe check
  • As habilidades necessárias para avaliações eficazes coincidem com alguns dos pontos fortes tradicionalmente vistos em engenheiros de machine learning
    • Uma equipe composta apenas por engenheiros de AI provavelmente carecerá dessas habilidades
• O coautor Hamel Husain explica a importância dessas habilidades em trabalhos recentes relacionados à detecção de viés em dados e ao desenho de avaliações específicas de domínio
• Tipos de papéis necessários e quando eles são necessários na jornada de construção de produtos de AI
  1. Primeiro, foque em construir o produto
  • Isso pode incluir engenheiros de AI, mas eles não são obrigatórios
  • Engenheiros de AI são úteis para prototipar o produto (UX, plumbing etc.) e iterar rapidamente
  2. Em seguida, instrumente o sistema e colete dados para criar a base correta
  • Dependendo do tipo e da escala dos dados, você pode precisar de engenheiros de plataforma e/ou de dados
  • Também é preciso ter sistemas para consultar e analisar esses dados a fim de depurar problemas
  3. Depois, otimize o sistema de AI
  • Isso não necessariamente inclui treinar modelos
  • O básico inclui etapas como desenhar métricas, construir sistemas de avaliação, executar experimentos, otimizar recuperação em RAG e depurar sistemas probabilísticos
  • MLEs são muito bons nessa área (embora engenheiros de AI também possam aprender)
  • Se as etapas anteriores não tiverem sido concluídas, normalmente não faz sentido contratar um MLE
• Além disso, especialistas de domínio são sempre necessários
  • Em empresas pequenas, idealmente a equipe fundadora deve cumprir esse papel; em empresas grandes, um gerente de produto pode fazê-lo
• É importante reconhecer a progressão e o timing dos papéis
  • Contratar pessoas no momento errado (por exemplo, contratar um MLE cedo demais) ou construir na ordem errada desperdiça tempo e dinheiro e causa rotatividade
• Também ajuda fazer check-ins regulares com um MLE nas etapas 1 e 2 (sem contratá-lo em tempo integral) para que a empresa construa a base correta

[Estratégia: como não ficar para trás ao construir com LLMs]

• Para desenvolver produtos com sucesso, é preciso planejamento cuidadoso e definição de prioridades, em vez de simplesmente criar protótipos a esmo ou seguir o modelo ou tendência mais recente
• Ao desenvolver produtos de AI, é preciso revisar trade-offs importantes, como desenvolver internamente ou comprar
• Apresenta um "playbook" para o desenvolvimento inicial de aplicações com LLM

Estratégia 1: sem GPU antes do PMF

• Para se tornar um ótimo produto, ele precisa ser mais do que apenas um embrulho fino em torno da API de outra pessoa
• Mas errar na direção oposta pode gerar um custo ainda maior
  • No último ano, enormes quantias de capital de risco foram gastas em treinamento e customização de modelos sem uma visão clara de produto ou mercado-alvo
  • Houve até empresa que recebeu impressionantes US$ 6 bilhões em uma rodada Series A
• Esta seção explica por que é um erro começar imediatamente a treinar seu próprio modelo e considera o papel do self-hosting

Retreinar (quase) do zero desde o início não faz sentido

• Para a maioria das organizações, pré-treinar um LLM do zero desde o início é algo irrealista e fora do escopo do desenvolvimento de produto
  • Desenvolver e manter infraestrutura de machine learning consome muitos recursos
    • Isso inclui coleta de dados, treinamento e avaliação do modelo, além de implantação
  • Se a equipe ainda está na fase de validar o product-market fit, esse esforço desvia recursos do desenvolvimento do produto principal
  • Mesmo com recursos computacionais, dados e capacidade técnica, um LLM pré-treinado pode se tornar obsoleto em poucos meses
• O caso do BloombergGPT
  • O BloombergGPT, um LLM especializado em tarefas financeiras, foi pré-treinado com 363B tokens
  • Houve um enorme esforço de 9 funcionários em tempo integral, incluindo 4 engenheiros de IA e 5 pessoas de produto e pesquisa em ML
  • Mesmo assim, em menos de um ano ele ficou atrás de gpt-3.5-turbo e gpt-4 nessa tarefa
• Esses casos sugerem que, para a maioria das aplicações reais, pré-treinar um LLM do zero não é o melhor uso de recursos
  • Em vez disso, é melhor que a equipe faça fine-tuning do modelo open source mais poderoso disponível para atender aos requisitos específicos
• Claro, há exceções
  • O modelo de código da Replit é um ótimo exemplo de pré-treinamento especializado em geração e compreensão de código
  • Com o pré-treinamento, ele apresentou desempenho superior ao de modelos maiores, como o CodeLlama7b
  • Porém, à medida que modelos mais poderosos foram lançados, foi necessário investimento contínuo para manter sua utilidade

Não faça fine-tuning até confirmar que ele é necessário

• Na maioria das organizações, o fine-tuning é guiado por FOMO (Fear Of Missing Out, medo de ficar de fora), e não por pensamento estratégico
  • As organizações investem cedo demais em fine-tuning para evitar a crítica de serem apenas um "wrapper simples"
  • Na prática, o fine-tuning é como maquinário pesado que só deve ser colocado em produção depois de reunir muitas evidências de que outras abordagens não são suficientes
• Há um ano, muitas equipes demonstravam entusiasmo com fine-tuning, mas poucas encontraram product-market fit, e a maioria se arrependeu da decisão
  • Se você vai fazer fine-tuning, precisa estar preparado para repeti-lo sempre que o modelo base melhorar
    • Veja abaixo "O modelo não é o produto" e "Construir LLMOps"
• Casos em que o fine-tuning pode realmente ser a escolha certa
  • Quando você precisa de dados que não estão disponíveis na maioria dos datasets abertos em escala web usados no treinamento de modelos existentes
  • Quando você já construiu um MVP que demonstra que os modelos existentes não são suficientes
  • Mas atenção: se os criadores de modelos não conseguem obter facilmente bons dados de treinamento, de onde você vai obtê-los?
• Aplicações baseadas em LLM não são projetos de feira de ciências
  • O investimento deve ser proporcional à contribuição para os objetivos estratégicos e a diferenciação competitiva

Comece com APIs de inferência, mas não tenha medo de self-hosting

• Ao usar APIs de LLM, startups conseguem adotar e integrar facilmente capacidades de modelagem de linguagem sem precisar treinar seus próprios modelos desde o início
  • Fornecedores como Anthropic e OpenAI oferecem APIs gerais que adicionam inteligência ao produto com apenas algumas linhas de código
  • Usar esses serviços reduz o esforço e permite focar em gerar valor para os clientes, validar ideias e iterar rumo ao product-market fit com mais rapidez
• Porém, assim como bancos de dados, serviços gerenciados não servem para todos os casos de uso à medida que escala e requisitos aumentam
  • Na prática, self-hosting pode ser a única forma de usar modelos sem enviar dados confidenciais ou pessoais para fora da rede, como exigem setores regulados como saúde e finanças, ou obrigações contratuais e requisitos de confidencialidade
• Além disso, self-hosting evita restrições impostas por provedores de inferência, como rate limits, descontinuação de modelos e limites de uso
  • Self-hosting oferece controle total sobre o modelo, facilitando a construção de sistemas diferenciados e de alta qualidade
• Por fim, self-hosting, especialmente com fine-tuning, pode reduzir custos em escala
  • Por exemplo, a Buzzfeed compartilhou um caso em que reduziu custos em 80% ao fazer fine-tuning de um LLM open source

Estratégia 2: iterar em direção a algo melhor

• Para manter vantagem competitiva no longo prazo, é preciso pensar em elementos que diferenciem o produto para além do modelo
• Velocidade de execução importa, mas não deve ser a única vantagem

O modelo não é o produto; o produto é o sistema ao redor dele

• Para equipes que não constroem o próprio modelo, o ritmo acelerado de inovação é uma bênção
  • Porque elas podem migrar para os modelos mais recentes em busca de melhorias em tamanho de contexto, capacidade de raciocínio e custo-benefício, criando produtos melhores
  • Esses avanços são empolgantes justamente por serem previsíveis
  • Em conjunto, isso indica que o modelo provavelmente é o componente menos durável do sistema
• Em vez disso, o esforço deve se concentrar nas partes capazes de gerar valor duradouro
  • Evals: para medir com confiabilidade o desempenho da tarefa em diferentes modelos
  • Guardrails: para evitar saídas indesejadas independentemente do modelo
  • Caching: para reduzir latência e custo evitando completamente o modelo quando possível
  • Data flywheel: para impulsionar a melhoria iterativa de tudo isso
  • Esses componentes criam um moat de qualidade de produto mais robusto do que as capacidades brutas do modelo
• Porém, isso não significa que construir na camada de aplicação não tenha riscos
  • Se OpenAI ou outro provedor de modelos puder oferecer software corporativo viável, não corte onde eles já podem cortar por você
• Por exemplo, algumas equipes investiram em criar ferramentas customizadas para validar saídas estruturadas de modelos proprietários
  • Um investimento mínimo nisso é importante, mas investir profundamente não é um bom uso do tempo
  • A OpenAI deve garantir que, ao solicitar function calling, você receba chamadas de função válidas, porque todos os clientes querem isso
  • Aplique aqui o "adiamento estratégico": construa apenas o estritamente necessário e espere a ampliação de funcionalidades do fornecedor

Comece pequeno e conquiste confiança

• Criar um produto que tenta ser tudo para todos é uma receita para a mediocridade
• Para criar um produto convincente, empresas precisam se especializar em construir experiências aderentes, que façam os usuários voltar
• Considere um sistema RAG genérico que tenta responder a toda pergunta do usuário
  • A falta de especialização significa que o sistema não consegue priorizar informações recentes, interpretar formatos específicos de domínio nem entender as nuances de tarefas específicas
  • Como resultado, os usuários têm uma experiência superficial e pouco confiável, que não atende às necessidades e leva ao abandono
• Para resolver isso, é preciso focar em domínios e casos de uso específicos
  • É necessário restringir o escopo, adicionando profundidade em vez de amplitude
  • Assim, torna-se possível criar ferramentas especializadas por domínio que realmente ressoem com os usuários
• A especialização também permite comunicar com honestidade as capacidades e limitações do sistema
  • Ser transparente sobre o que o sistema pode e não pode fazer demonstra autoconsciência, ajuda o usuário a entender onde ele pode agregar mais valor e, no fim, constrói confiança e segurança nos resultados

Construa LLMOps, mas tenha os motivos certos: iteração rápida

• DevOps não se resume, no fundo, a workflows reprodutíveis, shift-left ou a dar autonomia a equipes de duas pizzas. E muito menos a escrever arquivos YAML
• DevOps consiste em encurtar o ciclo de feedback entre o trabalho e seu resultado, para que melhorias se acumulem em vez de erros
  • Suas raízes remontam à manufatura enxuta e ao Sistema Toyota de Produção, por meio do movimento lean startup, com ênfase em single-minute die exchange e kaizen
• MLOps aplicou a forma do DevOps ao ML
  • Há suítes de ferramentas all-in-one com experimentos reproduzíveis e autonomia para que quem constrói modelos também possa fazer deploy. E muitos arquivos YAML também
• Porém, como setor, o MLOps não adotou a função do DevOps. Não reduziu a lacuna de feedback entre o modelo e a inferência e as interações em produção
• Felizmente, a área de LLMOps está mudando de direção, saindo de problemas triviais como gestão de prompts e avançando para melhoria contínua, conectada a problemas difíceis que bloqueiam a iteração: monitoramento em produção e avaliação
• Já existem arenas conversacionais para avaliação neutra e crowdsourced de modelos de chat e de código. É o loop externo de melhoria coletiva e iterativa
  • Ferramentas como LangSmith, Log10, LangFuse, W&B Weave e HoneyHive prometem não apenas coletar e organizar dados sobre os resultados do sistema em produção, mas também integrá-los profundamente ao desenvolvimento para melhorar esse sistema. Adote essas ferramentas ou construa as suas

Não crie capacidades de LLM que você pode comprar

• A maioria dos negócios bem-sucedidos não é um negócio de LLM. Ao mesmo tempo, a maioria dos negócios tem oportunidades de melhoria com LLMs
• Essas duas observações muitas vezes induzem líderes ao erro, levando-os a reformar sistemas às pressas com LLMs, aumentando custos e piorando a qualidade, para lançar recursos de “IA” artificiais e vaidosos. O ícone brilhante que agora todos temem está completo
• Há uma forma melhor: foque em aplicações de LLM que realmente se alinhem aos objetivos do produto e fortaleçam as operações centrais
• Considere algumas tentativas equivocadas que desperdiçam o tempo da equipe
  • construir uma funcionalidade personalizada de text-to-SQL para o negócio
  • construir um chatbot com o qual se possa conversar sobre documentos
  • integrar a base de conhecimento da empresa a um chatbot de suporte ao cliente
• Embora os itens acima sejam o “hello world” das aplicações de LLM, não faz sentido que uma empresa de produto os construa por conta própria
  • São problemas genéricos comuns a muitos negócios, com uma grande distância entre demos promissoras e componentes confiáveis, e pertencem ao território convencional das empresas de software
  • É desperdício investir recursos valiosos de P&D em problemas genéricos que as turmas atuais da Y Combinator já estão resolvendo em escala
• Se isso soa como conselho de negócios batido, é porque, no entusiasmo agitado da onda atual de hype, é fácil confundir “LLM” com algo de ponta e verdadeiramente diferenciado, e deixar passar aplicações que já viraram commodity

Coloque a IA no loop e mantenha o ser humano no centro

• As aplicações atuais baseadas em LLM são frágeis. Exigem uma enorme quantidade de proteções e engenharia defensiva, mas ainda assim são difíceis de prever. Ao mesmo tempo, quando seu escopo é bem delimitado, essas aplicações podem ser extremamente úteis. Isso significa que LLMs são ótimas ferramentas para acelerar o workflow do usuário
• Pode ser tentador imaginar aplicações baseadas em LLM substituindo completamente workflows ou assumindo funções de trabalho, mas o paradigma mais eficaz hoje é o centauro humano-computador (Centaur chess)
  • Quando um humano competente se combina com capacidades de LLM ajustadas para seu uso rápido, a produtividade e a satisfação ao realizar o trabalho podem aumentar muito
  • GitHub CoPilot, uma das aplicações emblemáticas de LLM, demonstrou o poder desse workflow
    • “No geral, os desenvolvedores disseram sentir que o código ficou mais fácil de escrever, com menos erros, mais legível, mais reutilizável, mais conciso, mais fácil de manter e mais resiliente ao usar GitHub Copilot e GitHub Copilot Chat.” - Mario Rodriguez, GitHub
• Pessoas que trabalham com ML há muito tempo podem chegar rapidamente à ideia de “human-in-the-loop”, mas não vá tão rápido
  • HITL em machine learning é um paradigma baseado em especialistas humanos para garantir que modelos de ML se comportem como previsto
  • O que se propõe aqui é algo relacionado, mas mais sutil. Hoje, sistemas baseados em LLM não deveriam ser a força motriz principal da maioria dos workflows; deveriam ser apenas um recurso
• Manter o ser humano no centro e perguntar como o LLM pode apoiar o workflow leva a implicações bem diferentes para decisões de produto e design
  • No fim, isso fará com que você crie um produto diferente dos concorrentes que correm para terceirizar toda a responsabilidade para o LLM: um produto melhor, mais útil e menos arriscado

Estratégia 3. Comece com prompting, evals e coleta de dados

• Na seção anterior, despejamos uma grande potência de fogo em tecnologia e conselhos. É muita coisa para absorver. Vamos considerar o conjunto mínimo de conselhos úteis.
  • Se uma equipe quer construir um produto com LLM, por onde deve começar?
• No último ano, vimos o suficiente para ter convicção de que aplicações de LLM bem-sucedidas seguem uma trajetória consistente. Nesta seção, veremos esse playbook básico de “como começar”
• A ideia central é começar de forma simples e adicionar complexidade conforme necessário
  • Rule of Thumb: cada nível de sofisticação normalmente exige pelo menos uma ordem de magnitude a mais de esforço do que a etapa anterior. Com isso em mente...

Engenharia de prompts vem em primeiro lugar

• Comece pela engenharia de prompts
  • Use todas as técnicas discutidas anteriormente na seção tática
  • Chain-of-thought, exemplos n-shot e entrada/saída estruturadas quase sempre são boas ideias
  • Faça protótipos com o modelo de melhor desempenho antes de tentar extrair performance de um modelo mais fraco
• Só considere fine-tuning se não for possível atingir o nível de desempenho desejado com engenharia de prompts
  • Isso tende a acontecer com mais frequência quando há requisitos não funcionais que impedem o uso de modelos proprietários e exigem self-hosting, como privacidade de dados, controle total ou custo
  • Tome cuidado para que os mesmos requisitos de privacidade não impeçam o uso de dados dos usuários para fine-tuning

Crie avaliações e inicie o data flywheel

• Mesmo equipes que estão começando precisam de evals. Caso contrário, não há como saber se a engenharia de prompts é suficiente ou se um modelo com fine-tuning está pronto para substituir o modelo-base
• Avaliações eficazes são específicas da tarefa e refletem o caso de uso pretendido
  • O primeiro nível de avaliação que recomendamos são testes unitários
  • Essas asserções simples ajudam a detectar modos de falha conhecidos ou hipotéticos e a tomar decisões iniciais de design
  • Consulte também outras avaliações específicas por tarefa para classificação, sumarização etc.
• Testes unitários e avaliações baseadas em modelo são úteis, mas não substituem a necessidade de avaliação humana
  • Faça com que pessoas usem o modelo/produto e forneçam feedback
  • Isso cumpre um duplo objetivo: medir desempenho real e taxa de defeitos, ao mesmo tempo em que coleta dados anotados de alta qualidade que podem ser usados para fine-tuning de modelos futuros
  • Isso cria um loop de feedback positivo, ou data flywheel, que gera efeitos compostos ao longo do tempo
    • avaliação humana para medir o desempenho do modelo ou encontrar defeitos
    • usar os dados anotados para fazer fine-tuning do modelo ou atualizar os prompts
    • repetir
• Por exemplo, ao auditar defeitos em resumos gerados por LLM, você pode atribuir rótulos de feedback detalhados a cada frase para identificar inconsistência factual, irrelevância ou estilo ruim
  • Depois, é possível usar essas anotações de inconsistência factual para treinar um classificador de alucinações, ou as anotações de relevância para treinar um modelo de recompensa de relevância
• O LinkedIn compartilhou um caso de sucesso usando avaliadores baseados em modelo para estimar alucinações, violações de IA responsável, coerência etc.
• Ao criar um ativo cujo valor aumenta com o tempo, você transforma a construção de evals de um simples custo operacional em um investimento estratégico, enquanto constrói o data flywheel no processo

Estratégia 4. A tendência de alto nível da cognição de baixo custo (The high-level trend of low-cost cognition)

• Em 1971, pesquisadores do Xerox PARC previram o mundo de computadores pessoais conectados em rede em que vivemos hoje
  • Eles contribuíram para dar origem a esse futuro ao desempenhar um papel central na invenção das tecnologias que o tornaram possível, como Ethernet, renderização gráfica, mouse e janelas
• Eles também fizeram um exercício simples
  • Examinaram aplicações muito úteis, mas ainda não econômicas, como displays de vídeo, em que a RAM suficiente para acioná-los custava milhares de dólares
  • Depois, analisaram a tendência histórica de preços daquela tecnologia, semelhante à Lei de Moore, e previram quando ela se tornaria economicamente viável
• Podemos fazer o mesmo com a tecnologia de LLMs, embora não seja tão limpo quanto o número de transistores por dólar
  • Escolha benchmarks populares usados há muito tempo, como o conjunto de dados Massively-Multitask Language Understanding, e uma abordagem de entrada consistente, como prompting 5-shot
  • Em seguida, compare ao longo do tempo o custo de executar modelos de linguagem com diferentes níveis de desempenho nesse benchmark
• Para um custo fixo, a capacidade está aumentando rapidamente. Para um nível fixo de capacidade, o custo está caindo rapidamente
  • Nos quatro anos desde que o modelo davinci da OpenAI foi lançado como API, o custo para executar, na escala de 1 milhão de tokens, um modelo com desempenho comparável naquela tarefa caiu de US$ 20 para menos de 10 centavos. A meia-vida foi de apenas 6 meses
  • Da mesma forma, em maio de 2024, o custo de executar o LLaMA 3 8B da Meta, seja por meio de provedores de API ou por conta própria, era de apenas 20 centavos por 1 milhão de tokens, com desempenho semelhante ao text-davinci-003 da OpenAI, o modelo que viabilizou o ChatGPT
  • Quando esse modelo foi lançado, no fim de novembro de 2023, ele ainda custava cerca de US$ 20 por 1 milhão de tokens. Uma diferença de duas casas decimais em apenas 18 meses, o mesmo período em que a Lei de Moore preveria um simples aumento de duas vezes
• Agora considere aplicações de LLM muito úteis, mas ainda não econômicas, como controlar personagens generativos de videogame, como em Park et al, cujo custo estimado é de US$ 625 por hora
  • Desde que esse artigo foi publicado, em agosto de 2023, o custo já caiu cerca de uma ordem de grandeza, para aproximadamente US$ 62,50 por hora
  • Nove meses depois, podemos esperar que caia para US$ 6,25 por hora
• Enquanto isso, quando Pac-Man foi lançado em 1980, com o equivalente a US$ 1 em valores de hoje era possível comprar créditos para jogar por alguns minutos ou algumas dezenas de minutos. Vamos chamar isso de 6 partidas por hora, ou US$ 6 por hora
  • Esse cálculo de guardanapo sugere que experiências de jogo atraentes aprimoradas por LLM se tornarão economicamente viáveis por volta de 2025
• Essas tendências são novas e têm apenas poucos anos. Mas há pouca razão para esperar que esse processo desacelere nos próximos anos
  • Mesmo esgotando frutos mais fáceis em algoritmos e conjuntos de dados, como escalar além da “proporção Chinchilla” de ~20 tokens por parâmetro, inovações e investimentos mais profundos dentro dos data centers e na camada de silício preencherão essa lacuna
• E esse talvez seja o fato estratégico mais importante
  • Demonstrações de palco ou artigos de pesquisa que hoje são completamente inviáveis se tornarão recursos premium em alguns anos e, logo depois, commodities
  • É preciso construir sistemas e organizações com isso em mente

[Demonstrações de 0 para 1 agora já bastam. Agora é hora de criar produtos que vão de 1 a N]

• Criar demos com LLM é realmente divertido. Algumas linhas de código, um banco de dados vetorial e prompts cuidadosamente escritos produzem “mágica”
• No último ano, essa mágica foi comparada à internet, aos smartphones e até à prensa tipográfica
• Infelizmente, como sabe qualquer pessoa que já trabalhou no lançamento de software real, há uma enorme diferença entre uma demo que funciona em um ambiente controlado e um produto que funciona de forma confiável em larga escala
• É fácil imaginar e criar demos, mas há muitos problemas que são muito difíceis de transformar em produto
  • Por exemplo, direção autônoma: é fácil demonstrar um carro dirigindo de forma autônoma por um quarteirão, mas transformá-lo em produto leva 10 anos - Andrej Karpathy
• Vamos usar carros autônomos como exemplo
  • Em 1988, surgiu o primeiro carro dirigido por uma rede neural
  • 25 anos depois, Andrej Karpathy fez a primeira viagem de demonstração na Waymo
  • Dez anos depois disso, a empresa recebeu autorização para operação sem motorista
  • Foram 35 anos de engenharia rigorosa, testes, melhorias e navegação regulatória para ir do protótipo ao produto comercial
• Observamos ao longo do último ano, na indústria e na academia, seus altos e baixos: o primeiro ano de N das aplicações de LLM (Year 1 of N for LLM applications)
  • Esperamos que as lições que aprendemos — desde táticas como avaliação, engenharia de prompts e guardrails até perspectivas estratégicas como técnicas operacionais, formação de equipes e a escolha do que desenvolver internamente — sejam úteis no segundo ano e além
  • Estamos ansiosos para continuar avançando juntos nessa nova tecnologia tão empolgante

[inthelife]

Como o conteúdo é bom, resolvi transformá-lo em um mind map para guardar e consultar depois ^^;

https://drive.google.com/file/d/…

[hheungsu]

Texto excelente!! Do começo ao fim, há muitas ideias úteis para refletir com calma. Obrigado por traduzir e publicar um texto tão precioso!!

[nutella]

Neste momento, isso está sendo realmente muito útil.

[komanabi]

A MegaStudy acabou, o Ômega 3 está chegando!!!

[ssifood]

Agora a Skynet acabou, a MegaStudy está chegando.

[my0075425]

Agora a humanidade acabou, a Skynet está chegando!!

[zihado]

A carreira do autor do texto original também foi interessante.
https://pt.news.hada.io/topic?id=1626

[eungook]

Uau.. isso é extremamente inspirador.. obrigado pela apresentação

[humblebee]

Que texto excelente — dá para sentir vividamente os insights e a experiência! Acho que será de grande ajuda para mim e para a minha equipe. Li com muito gosto. Obrigado ☺️