Autor
Lucas Rego · Engenharia · Capim
Estávamos rodando em círculos tentando melhorar um de nossos agentes de IA. É um agente do tipo que conversa diretamente com nossos clientes e precisa decidir quando deve transbordar um ticket para um analista humano.
Tentamos várias abordagens para resolver o problema — incluindo LLM-as-a-Judge — mas elas supercomplicavam a situação de um agente em seus passos iniciais.
Neste post, vou mostrar como dobramos a acurácia do agente (de 40% para 95%) em duas semanas usando apenas análise de erros e anotação manual de conversas.
O problema
No início deste ano percebemos que um de nossos agentes parecia escalar tickets para humanos com mais frequência do que gostaríamos.
Ao analisar algumas conversas manualmente, percebemos dois tipos de erro:
- O agente poderia resolver o problema, mas escalava para um humano.
- O agente deveria escalar, mas tentava resolver sozinho.
Ou seja, o problema estava nos dois lados da decisão.
Observabilidade
Nosso primeiro instinto foi tentar medir o tamanho do problema.
Com alguns agentes rodando há algum tempo, já havíamos aprendido uma lição importante: sem observabilidade, melhorar agentes é praticamente impossível. Estamos usando o Langfuse, que tem funcionado muito bem para este fim. Antes disso, analisar conversas significava escrever queries SQL complexas em estruturas de dados pouco amigáveis.
O que não deu certo
Antes de explicar o que funcionou, vale contar rapidamente duas tentativas que não deram certo.
Tentativa 1: muitas métricas + LLM-as-a-Judge
Nossa primeira tentativa foi criar um conjunto grande de métricas para monitorar o agente. Dividimos as métricas em dois tipos. Na tabela abaixo temos alguns exemplos:
| Tipo | Exemplo | Como medir |
|---|---|---|
| Determinística | % de tickets escalados | Código |
| Determinística | Tempo de resposta | Código |
| Subjetiva | Alucinação | LLM-as-a-Judge |
| Subjetiva | Qualidade da resposta | LLM-as-a-Judge |
Criamos cerca de 15 métricas, sendo 5 com LLM-as-a-Judge, e o problema apareceu rapidamente.
Uma LLM-as-a-Judge é mais uma IA gerando informação que precisamos aprender a confiar. Antes de usar uma métrica deste tipo, precisaríamos validar se a avaliação estava correta, se o prompt do judge funcionava em vários use cases, se a classificação era consistente ao longo do tempo, etc.
Na prática, estávamos criando outro projeto de IA para validar o primeiro.
No fim, só confiávamos nas métricas determinísticas. Estas são extremamente importantes, pois explicam muito bem o que aconteceu, mas muito pouco por que aconteceu.
Tentativa 2: validar um judge por vez
Nossa segunda tentativa foi mais cuidadosa. A ideia era:
- criar um LLM-as-a-Judge
- deixar ele classificar as conversas
- fazer labelling manual das classificações em certo/errado
- corrigir o prompt do judge
- iterar até confiar nele
O problema foi simples: enquanto validávamos o judge, não estávamos resolvendo o problema original. Estávamos apenas empurrando o problema para frente.
O aprendizado mais importante: human annotation
Um aprendizado muito importante dessas tentativas foi o valor do labelling manual.
No Langfuse, eles chamam de Human Annotation e consiste em: olhar uma interação do agente com um cliente e classificar ela segundo algum critério.
Por exemplo, você pode pegar 30 interações por dia e classificar manualmente se o agente alucinou ou não. Depois de uma semana já tem uma boa amostragem do problema e, além disso, pode aproveitar para identificar tipos/causas de alucinação.
O que funcionou
Após as tentativas anteriores, resolvemos dar um passo para trás, esquecer LLM-as-a-Judge por um tempo e focar no problema a ser resolvido.
A ideia foi: se for para ter que fazer human annotations/labelling, é melhor ir direto ao problema em questão. No nosso caso era simples:
O agente deveria ter escalado essa conversa? → sim/não
Este critério de classificação foi bastante discutido, pois inicialmente a gente estava pensando em classificar os transbordos em certo ou errado. Logo logo explico porque isso não funcionaria — por ora, vamos entender qual o passo a passo da nossa análise de erros e posterior otimização de prompt.
Processo de análise
- Selecionar uma amostra de ~50 conversas
- Classificar manualmente se deveria escalar ou não (human annotation)
- Comparar com o comportamento real do agente
- Construir uma matriz de confusão e calcular a acurácia
| Deveria transbordar | Não deveria transbordar | |
|---|---|---|
| Agente transbordou | Verdadeiro Positivo | Falso Positivo |
| Agente não transbordou | Falso Negativo | Verdadeiro Negativo |
Acurácia = (Verdadeiro Positivo + Verdadeiro Negativo) / Tamanho da amostra
- Ajustar o prompt
- Rodar o novo prompt na mesma amostra (backtest)
- Recalcular a matriz de confusão
Isso nos permite calcular métricas como acurácia e acompanhar a evolução do prompt. Esse processo é muito parecido com o que se faz em Machine Learning tradicional. Na prática, estamos fazendo um backtest do prompt.
Iteramos esse processo durante cerca de duas semanas. A cada rodada:
- analisávamos novos erros
- ajustávamos o prompt
- rodávamos o backtest novamente
A acurácia foi evoluindo de 40% até 95% ao longo das iterações! Neste ponto, consideramos o prompt bom o suficiente para seguir para o próximo problema do agente.
Por que não classificamos “transbordo certo ou errado”?
Inicialmente pensamos em classificar apenas: “o agente escalou corretamente?” Mas isso gera um problema.
Se fizermos isso, o novo prompt só pode ser avaliado nos casos onde o prompt antigo escalou. Isso ignora completamente os casos onde o agente deveria escalar mas não escalou. Ou seja, metade do problema desaparece da análise.
Por isso classificamos apenas o comportamento esperado, independente do que o agente fez.
Por que gostamos dessa abordagem
Alguns motivos:
- Fomos direto ao problema — cortamos esforços de validação de LLM-as-a-Judge e fomos direto resolver a nossa dor
- Conseguimos medir evolução
- Usamos interações reais com humanos — comprovamos que o novo prompt teria feito melhor do que o prompt antigo
- Aprendemos muito sobre o comportamento do agente — revisar conversas manualmente revela como de fato os problemas surgem
Então LLM-as-a-Judge não serve?
Serve sim! O nosso principal aprendizado foi que eles não devem ser a primeira opção, exigem bastante esforço e uma certa maturidade no estágio de desenvolvimento do agente.
Hoje vejo eles mais como uma ferramenta de monitoramento. Uma vez implementados e validados, eles podem ser extremamente úteis para mensurar o tamanho de um problema e identificar casos para análise.
Mas se é possível buscar conversas que contêm o problema que você quer resolver, é melhor ir direto para uma análise de erro e melhoria de prompt.
No nosso caso, a estratégia ideal seria:
- Melhorar o prompt via análise de erros
- Criar um LLM-as-a-Judge para monitorar o problema
- Usar isso como alerta de regressão
Notas de implementação
Usamos o Langfuse para:
- observabilidade
- anotação humana
- experimentos de prompt
Também identificamos a necessidade de adicionar informações extras aos traces para facilitar análise ao longo do processo.
As matrizes de confusão foram calculadas em planilhas simples, exportando os dados do Langfuse.
Links úteis
- Hamel Husain — excelente conteúdo sobre evaluation de LLMs
- Confusion Matrix — Wikipédia