Otimizando a precisão de LLMs

Como maximizar a correção das respostas e a consistência do comportamento ao trabalhar com LLMs

Otimizar LLMs é difícil.

Trabalhamos com muitos desenvolvedores, tanto de startups quanto de grandes empresas, e as dificuldades de otimização se resumem, de forma recorrente, a estes pontos:

• Saber por onde começar a otimizar a precisão
• Quando usar cada método de otimização
• Qual nível de precisão é bom o suficiente para produção

Este artigo apresenta um modelo mental para otimizar a precisão e o comportamento de LLMs. Vamos explorar métodos como engenharia de prompt, geração aumentada por recuperação (RAG) e ajuste fino. Também mostraremos como e quando usar cada técnica, além de apontar algumas armadilhas.

Durante a leitura, é importante relacionar esses princípios ao que precisão significa para seu caso de uso específico. Pode parecer óbvio, mas há uma diferença entre produzir um texto ruim que uma pessoa precisa corrigir e reembolsar um cliente em $1000 em vez de $100. Antes de qualquer discussão sobre a precisão de LLMs, você deve ter uma ideia aproximada de quanto uma falha do LLM custa e de quanto um acerto economiza ou gera de receita. Retomaremos esse ponto no final, quando abordarmos qual nível de precisão é “bom o suficiente” para produção.

Contexto da otimização de LLMs

Muitos guias práticos de otimização a apresentam como um fluxo linear simples: você começa com engenharia de prompt, passa para geração aumentada por recuperação e, depois, para ajuste fino. No entanto, muitas vezes não é assim que funciona. Cada método resolve problemas diferentes, e otimizar na direção certa exige escolher o método adequado.

É útil pensar na otimização de LLMs como uma matriz:

Uma tarefa típica com LLMs começa no canto inferior esquerdo, com engenharia de prompt, em que testamos, aprendemos e avaliamos para estabelecer uma referência inicial. Depois de revisar esses exemplos iniciais e analisar por que estão incorretos, podemos escolher uma das frentes de otimização:

• Otimização de contexto: Você precisa otimizar o contexto quando 1) o modelo não tem o conhecimento contextual necessário porque ele não estava no conjunto de treinamento, 2) seu conhecimento está desatualizado ou 3) ele precisa conhecer informações proprietárias. Esse eixo maximiza a precisão das respostas.
• Otimização do LLM: Você precisa otimizar o LLM quando 1) o modelo produz resultados inconsistentes com formatação incorreta, 2) o tom ou o estilo de linguagem não é adequado ou 3) o raciocínio não é seguido de forma consistente. Esse eixo maximiza a consistência do comportamento.

Na prática, isso se transforma em uma sequência de etapas de otimização: avaliamos, formulamos uma hipótese de como otimizar, aplicamos a mudança, avaliamos o resultado e reconsideramos o próximo passo. Veja um exemplo de um fluxo de otimização bastante comum:

Neste exemplo, fazemos o seguinte:

• Começamos com um prompt e avaliamos seu desempenho
• Adicionamos exemplos few-shot estáticos, o que deve melhorar a consistência dos resultados
• Adicionamos uma etapa de recuperação para trazer exemplos few-shot dinamicamente com base na pergunta. Isso melhora o desempenho ao garantir um contexto relevante para cada entrada
• Preparamos um conjunto de dados com 50 ou mais exemplos e fazemos o ajuste fino de um modelo para aumentar a consistência
• Ajustamos a recuperação e adicionamos uma etapa de verificação de fatos para identificar alucinações e alcançar maior precisão
• Treinamos novamente o modelo que passou por ajuste fino com os novos exemplos de treinamento, que incluem nossas entradas de RAG aprimoradas

Esse é um pipeline de otimização bastante comum para um problema de negócio difícil. Ele nos ajuda a decidir se precisamos de um contexto mais relevante ou de um comportamento mais consistente do modelo. Depois dessa decisão, sabemos qual método usar como primeiro passo da otimização.

Agora que temos um modelo mental, vamos explorar os métodos para atuar em cada uma dessas áreas. Começaremos no canto inferior esquerdo, com engenharia de prompt.

Engenharia de prompt

A engenharia de prompt costuma ser o melhor ponto de partida**. Muitas vezes, é o único método necessário para casos de uso como resumo, tradução e geração de código, nos quais uma abordagem zero-shot pode alcançar níveis de precisão e consistência adequados para produção.

Isso acontece porque ela exige que você defina o que precisão significa para seu caso de uso. Você começa pelo nível mais básico, fornecendo uma entrada, então precisa conseguir avaliar se a saída corresponde às suas expectativas. Se o resultado não for o desejado, entender por quê indicará quais recursos usar nas próximas otimizações.

Para isso, comece sempre com um prompt simples e uma saída esperada em mente. Depois, otimize o prompt adicionando contexto, instruções ou exemplos até obter o resultado desejado.

Otimização

Para otimizar seus prompts, vou me basear principalmente nas estratégias do guia de engenharia de prompt da documentação da API da OpenAI. Cada estratégia ajuda a ajustar o contexto, o LLM ou ambos:

Essas estratégias podem ser um pouco difíceis de visualizar, então vamos testá-las em um exemplo prático. Usaremos o gpt-4-turbo para corrigir frases em islandês e ver como isso funciona.

SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.

# Examples
USER: "Stofnendurnir séu margir og eru fulltrúar hennar frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."
ASSISTANT: "Hann segir að stofnendur leynireglunnar séu margir og að fulltrúar hennar séu frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

USER: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstormar (fræðiheiti: Polychatete)."
ASSISTANT: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstaormar (fræðiheiti: Polychatete)."

USER: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjótsti."
ASSISTANT: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjósti."

USER: [input user query here]

Vimos que a engenharia de prompt é um ótimo ponto de partida e que, com os métodos de ajuste certos, podemos melhorar bastante o desempenho.

No entanto, o maior problema da engenharia de prompt é que muitas vezes ela não escala. Ou precisamos fornecer contexto dinâmico para permitir que o modelo lide com uma variedade maior de problemas do que conseguimos resolver apenas adicionando conteúdo ao contexto, ou precisamos de um comportamento mais consistente do que conseguimos obter com exemplos few-shot.

Então, até onde você pode chegar com a engenharia de prompt? A resposta é que depende, e você toma essa decisão por meio de avaliações.

Avaliação

Por isso, um bom prompt acompanhado de um conjunto de avaliação com perguntas e respostas de referência é o melhor resultado desta etapa. Se temos um conjunto de 20 ou mais perguntas e respostas, analisamos as falhas em detalhe e formulamos uma hipótese sobre suas causas, temos a base adequada para avançar para métodos de otimização mais sofisticados.

Antes de avançar para métodos de otimização mais sofisticados, também vale considerar como automatizar essa avaliação para acelerar suas iterações. Algumas práticas comuns que vimos funcionar bem são:

• Usar abordagens como ROUGE ou BERTScore para obter uma avaliação aproximada. Ela não tem uma correlação tão forte com as avaliações humanas, mas pode fornecer uma medida rápida e eficaz de quanto uma iteração alterou as saídas do modelo.
• Usar o GPT-4 como avaliador, conforme descrito no artigo sobre G-Eval, fornecendo ao LLM uma ficha com critérios de pontuação para avaliar a saída da forma mais objetiva possível.

Para se aprofundar nessas abordagens, confira este cookbook, que apresenta todas elas na prática.

Entenda as ferramentas

Você já aplicou engenharia de prompt e tem um conjunto de avaliação, mas seu modelo ainda não faz o que você precisa. O próximo passo mais importante é diagnosticar onde ele está falhando e qual ferramenta funciona melhor para corrigir essas falhas.

Veja uma estrutura básica para fazer isso:

Você pode classificar cada pergunta respondida incorretamente na avaliação como um problema de memória em contexto ou aprendida . Como analogia, imagine que você está fazendo uma prova. Há duas formas de garantir que você chegue à resposta certa:

• Você frequentou as aulas nos últimos 6 meses e viu muitos exemplos repetidos de como um determinado conceito funciona. Isso é memória aprendida . Nos LLMs, você resolve esse problema mostrando exemplos do prompt e da resposta esperada para que o modelo aprenda com eles.
• Você está com o livro didático e pode consultar as informações certas para responder à pergunta. Isso é memória em contexto . Nos LLMs, resolvemos esse problema inserindo informações relevantes na janela de contexto, seja de forma estática com engenharia de prompt, seja em escala com RAG.

Esses dois métodos de otimização se complementam, não se excluem . Eles podem ser combinados, e alguns casos de uso exigirão que você use ambos para obter o melhor desempenho.

Vamos supor que estamos diante de um problema de memória de curto prazo. Para resolvê-lo, usaremos RAG.

Geração aumentada por recuperação (RAG)

RAG é o processo de Recuperar conteúdo para Ampliar o prompt do LLM antes de Gerar uma resposta. Ele é usado para dar ao modelo acesso a contexto específico de um domínio para resolver uma tarefa.

RAG é uma ferramenta extremamente valiosa para aumentar a acurácia e a consistência de um LLM. Muitas das maiores implantações de nossos clientes na OpenAI foram feitas usando apenas engenharia de prompt e RAG.

Neste exemplo, geramos embeddings de uma base de conhecimento de estatísticas. Quando o usuário faz uma pergunta, geramos um embedding dessa pergunta e recuperamos o conteúdo mais relevante da nossa base de conhecimento. Esse conteúdo é apresentado ao modelo, que responde à pergunta.

Aplicações RAG introduzem um novo eixo de otimização: a recuperação. Para que nosso RAG funcione, precisamos fornecer o contexto certo ao modelo e depois avaliar se ele está respondendo corretamente. Vou organizar esses aspectos em uma matriz para mostrar uma forma simples de pensar na avaliação com RAG:

Sua aplicação RAG pode falhar em duas áreas:

A principal conclusão aqui é que o princípio continua o mesmo do modelo mental apresentado no início: você avalia para descobrir o que deu errado e realiza uma etapa de otimização para corrigir o problema. A única diferença com RAG é que agora você também precisa considerar o eixo da recuperação.

Embora útil, RAG só resolve nossos problemas de aprendizado em contexto. Em muitos casos de uso, o desafio é garantir que o LLM aprenda uma tarefa para executá-la de forma consistente e confiável. Para esse problema, recorremos ao ajuste fino.

Ajuste fino

Para resolver um problema de memória aprendida, muitos desenvolvedores dão continuidade ao treinamento do LLM com um conjunto de dados menor e específico de um domínio, a fim de otimizá-lo para a tarefa em questão. Esse processo é conhecido como ajuste fino.

O ajuste fino costuma ser realizado por um de dois motivos:

• Melhorar a acurácia do modelo em uma tarefa específica: treinar o modelo com dados específicos da tarefa para resolver um problema de memória aprendida, mostrando muitos exemplos de execução correta dessa tarefa.
• Melhorar a eficiência do modelo: alcançar a mesma acurácia com menos tokens ou usando um modelo menor.

O processo de ajuste fino começa com a preparação de um conjunto de dados com exemplos de treinamento. Essa é a etapa mais importante, pois os exemplos de ajuste fino devem representar exatamente o que o modelo encontrará no mundo real.

Com esse conjunto limpo em mãos, você pode treinar um modelo com ajuste fino por meio de uma execução de treinamento . Dependendo da plataforma ou do framework usado, pode haver hiperparâmetros que você pode ajustar, assim como em qualquer outro modelo de aprendizado de máquina. Sempre recomendamos manter um conjunto separado para avaliação após o treinamento, a fim de detectar sobreajuste. Para obter dicas sobre como montar um bom conjunto de treinamento, consulte as orientações na nossa documentação de ajuste fino. Quando o treinamento termina, o novo modelo com ajuste fino fica disponível para inferência.

Para otimizar o ajuste fino, vamos nos concentrar nas práticas recomendadas que observamos nas soluções de personalização de modelos da OpenAI, mas esses princípios também devem se aplicar a outros provedores e soluções de código aberto. As principais práticas a seguir são:

• Comece pela engenharia de prompt: tenha um conjunto de avaliação sólido, desenvolvido durante a engenharia de prompt, que possa servir como referência. Isso permite uma abordagem de baixo investimento até que você tenha confiança no seu prompt base.
• Comece com pouco e foque na qualidade: a qualidade dos dados de treinamento é mais importante que a quantidade ao realizar ajuste fino em um modelo de base. Comece com 50 ou mais exemplos, avalie e aumente o conjunto de treinamento se ainda não tiver atingido a acurácia necessária e se os problemas que causam respostas incorretas forem de consistência/comportamento, e não de contexto.
• Garanta que seus exemplos sejam representativos: um dos problemas mais comuns que vemos é o uso de dados de treinamento não representativos, em que os exemplos de ajuste fino diferem sutilmente, na formatação ou na forma, do que o LLM encontra em produção. Por exemplo, se você tem uma aplicação RAG, faça o ajuste fino do modelo com exemplos de RAG, para que ele não precise aprender a usar o contexto de forma zero-shot.

Todas as abordagens acima

Essas técnicas podem ser combinadas. Se suas primeiras avaliações mostrarem problemas tanto de contexto quanto de comportamento, é provável que você acabe usando ajuste fino + RAG na solução em produção. Não há problema nisso: a combinação compensa as limitações de ambas as abordagens. Alguns dos principais benefícios são:

• Usar ajuste fino para minimizar o número de tokens usados na engenharia de prompt, substituindo instruções e exemplos few-shot por muitos exemplos de treinamento para consolidar um comportamento consistente no modelo.
• Ensinar comportamentos complexos por meio de ajuste fino extensivo
• Usar RAG para inserir contexto, conteúdo mais recente ou qualquer outro contexto especializado necessário para seus casos de uso

# One training example
SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.
USER: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum í heiminum."
ASSISTANT: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum heims."

Agora você deve entender melhor RAG e ajuste fino e quando cada um é adequado. O último ponto a entender sobre essas ferramentas é que adotá-las tem um custo para a velocidade de iteração:

• Com RAG, você precisa otimizar tanto a recuperação quanto o comportamento do LLM
• Com ajuste fino, você precisa repetir o processo e gerenciar os conjuntos de treinamento e validação sempre que fizer novas otimizações.

Ambos os processos podem ser demorados e complexos, além de introduzir regressões à medida que seu aplicativo com LLM se torna mais complexo. Se você guardar uma única lição deste artigo, que seja esta: obtenha o máximo de acurácia possível com métodos básicos antes de recorrer a RAG ou ajuste fino, que são mais complexos. Seu objetivo deve ser atingir a meta de acurácia, e não adotar RAG + FT só porque são vistos como os métodos mais sofisticados.

Qual nível de acurácia é “bom o suficiente” para produção

Otimizar a acurácia de LLMs pode ser uma batalha sem fim: é improvável que eles cheguem a 99,999% de acurácia com métodos prontos para uso. Esta seção trata de decidir quando a acurácia é suficiente: como ganhar confiança para colocar um LLM em produção e como gerenciar os riscos da solução disponibilizada.

Acho útil pensar nisso tanto pela perspectiva de negócio quanto pela técnica . Vou descrever, em linhas gerais, as abordagens para lidar com ambas e usar um caso de uso de central de atendimento ao cliente para ilustrar como gerenciamos os riscos nos dois casos.

Negócio

Para a empresa, pode ser difícil confiar em LLMs depois de se acostumar à previsibilidade relativamente maior dos sistemas baseados em regras, dos sistemas tradicionais de aprendizado de máquina ou até mesmo dos seres humanos! É difícil lidar com um sistema cujas falhas podem assumir formas imprevisíveis e sem limites bem definidos.

Uma abordagem que vi funcionar foi aplicada a um caso de uso de atendimento ao cliente. Fizemos o seguinte:

Primeiro, identificamos os principais cenários de sucesso e falha e atribuímos um custo estimado a cada um. Isso nos dá uma visão clara da provável economia ou do provável custo da solução com base no desempenho do piloto.

• Por exemplo, um caso resolvido por uma IA que antes era resolvido por uma pessoa pode gerar uma economia de $20.
• Encaminhar alguém desnecessariamente para um atendente humano pode custar $40
• No pior cenário, um cliente fica tão frustrado com a IA que deixa de ser cliente, gerando um custo de $1000 para nós. Presumimos que isso aconteça em 5% dos casos.

Também coletamos estatísticas empíricas do processo para ajudar a medir o impacto geral da solução. Ainda no exemplo de atendimento ao cliente, elas poderiam incluir:

• A pontuação CSAT de interações exclusivamente humanas em comparação com interações com IA
• A taxa de acerto das decisões em casos revisados retrospectivamente, comparando humanos e IA
• O tempo de resolução, comparando humanos e IA

No exemplo de atendimento ao cliente, isso nos ajudou a tomar duas decisões importantes após alguns projetos-piloto para obter dados claros:

1. Mesmo que nossa solução com LLM encaminhasse mais casos para humanos do que gostaríamos, ela ainda gerava uma enorme economia nos custos operacionais em relação à solução existente. Isso significava que até uma taxa de acerto de 85% poderia ser aceitável, se os 15% restantes fossem principalmente encaminhamentos antecipados.
2. Quando o custo de uma falha era muito alto, como em um caso de fraude resolvido incorretamente, decidimos que o humano ficaria no comando e a IA atuaria como assistente. Nesse caso, a taxa de acerto das decisões nos ajudou a concluir que não nos sentíamos seguros em conceder autonomia total à IA.

Aspectos técnicos

Do lado técnico, a situação é mais clara: agora que a equipe de negócios sabe qual valor espera obter e quanto pode custar o que der errado, seu papel é criar uma solução que lide bem com as falhas, sem prejudicar a experiência do usuário.

Vamos usar mais uma vez o exemplo de atendimento ao cliente para ilustrar isso e supor que temos um modelo com uma taxa de acerto de 85% na identificação da intenção. Como equipe técnica, podemos minimizar o impacto dos 15% de erros de algumas maneiras:

• Podemos usar engenharia de prompt para orientar o modelo a pedir mais informações ao cliente quando não tiver confiança suficiente. Assim, nossa taxa de acerto na primeira tentativa pode cair, mas podemos obter uma taxa maior com 2 tentativas para identificar a intenção.
• Podemos dar ao assistente de segunda linha a opção de retornar à etapa de identificação da intenção, mais uma vez permitindo que a experiência do usuário se recupere de falhas, ao custo de um pouco mais de latência para o usuário.
• Podemos usar engenharia de prompt para orientar o modelo a transferir o atendimento para um humano quando a intenção não estiver clara. Isso reduz parte da economia operacional no curto prazo, mas pode compensar o risco de perda de clientes no longo prazo.

Essas decisões se refletem na experiência do usuário, que fica mais lenta em troca de uma taxa de acerto maior, ou geram mais intervenções humanas, que entram no modelo de custos abordado na seção de negócios acima.

Agora você tem uma abordagem para analisar as decisões técnicas e de negócios envolvidas na definição de uma meta de acerto fundamentada na realidade do negócio.

Próximos passos

Este é um modelo mental geral para pensar em como maximizar a taxa de acerto dos LLMs, quais ferramentas usar para isso e como decidir qual nível é suficiente para produção. Você tem a estrutura e as ferramentas necessárias para chegar à produção de forma consistente. Se quiser se inspirar no que outras empresas alcançaram com esses métodos, confira nossas histórias de clientes: casos de uso como os da Morgan Stanley e da Klarna mostram o que você pode alcançar com essas técnicas.

Boa sorte! Estamos animados para ver o que você vai criar com isso!