Neste artigo
Spoiler: a maioria das equipes que coloca um LLM em produção não tem como saber se ele está funcionando bem. Não porque são descuidadas, mas porque nunca definiram o que “funcionar bem” significa em termos mensuráveis. Tem painel de latência, às vezes de custo, mas nenhuma métrica que diga se a resposta gerada foi boa ou ruim para o usuário.
Esse artigo resolve isso. Não de forma teórica. Com rubrica, dataset e teste de regressão que você consegue implementar antes do próximo deploy.
O problema com “parece bom”
Quando você testa um LLM manualmente, o cérebro humano é excelente em reconhecer respostas plausíveis como boas. O modelo responde de forma fluente, coerente, com tom correto, e você pensa “tá ótimo”. O problema é que fluência e correção são coisas diferentes. E coerência não é o mesmo que precisão.
Na prática, “parece bom” não escala. Você não consegue rever mil respostas por dia manualmente. E quando muda o modelo, o prompt ou a temperatura, não tem como saber se melhorou ou piorou sem alguma estrutura de comparação.
O negócio é: sem avaliação estruturada, você está operando no escuro. Projetos de IA que operam no escuro costumam ter um momento desagradável de descoberta, geralmente em produção, geralmente com usuário real afetado.
Antes de avaliar, define o que você está avaliando
Antes de montar qualquer rubrica, você precisa responder a uma pergunta simples: qual é a tarefa que o modelo executa?
Parece óbvio, mas na prática a maioria das equipes pula essa etapa. O modelo faz “geração de texto”, “responde perguntas”, “resume documentos”. Essas descrições são largas demais para criar critérios de avaliação úteis.
Na minha experiência, a versão mais dolorosa desse erro foi um modelo que “ajudava clientes a entender extratos”. Rodou por três meses em produção sem métrica nenhuma de qualidade. Quando finalmente foram avaliar, descobriram que o modelo dava respostas tecnicamente corretas mas que não respondiam a pergunta real do cliente em cerca de 40% dos casos. Três meses de dado ruim, sem ninguém perceber.
Então, antes de tudo: descreve a tarefa de forma específica. “O modelo recebe uma pergunta de cliente sobre extrato bancário e deve responder com a informação correta, no formato X, sem adicionar informações não solicitadas.” Isso já dá material para construir critérios.
Como construir uma rubrica de avaliação
Uma rubrica é um conjunto de critérios com escala definida. Não é uma nota geral de 1 a 10. Isso é achismo quantificado. É uma lista de dimensões específicas, cada uma com critérios claros para cada nível da escala.
Dimensões comuns para tarefas de LLM
Para tarefas de LLM em produção, as dimensões mais úteis são:
- Correção factual: a resposta contém informações corretas? Escala sugerida: correto, parcialmente correto, incorreto.
- Relevância: a resposta endereça o que foi perguntado? Escala: totalmente relevante, parcialmente relevante, fora do escopo.
- Completude: a resposta cobre tudo que deveria dado o contexto disponível? Escala: completa, incompleta, mínima.
- Formato: a resposta segue o formato esperado pelo sistema? Escala: conforme, desvio menor, desvio maior.
- Tom e segurança: a resposta tem tom adequado, sem informações perigosas ou fora de política? Escala: adequado, atenção, reprovado.
Detalhe importante: nem toda tarefa precisa de todas as dimensões. Se o modelo só classifica texto em categorias, você provavelmente só precisa de correção. A rubrica deve ser enxuta o suficiente para ser aplicada de forma consistente por pessoas diferentes sem calibração longa.
Para cada dimensão, documenta exemplos concretos de respostas em cada nível. Sem exemplos, avaliadores diferentes vão calibrar diferente e suas notas não são comparáveis entre si. Isso invalida qualquer análise de tendência.
Montando o dataset de avaliação
A rubrica define os critérios. O dataset define os casos. Sem dataset fixo, você avalia sempre os mesmos exemplos que vieram à cabeça, que tendem a ser os casos fáceis e os casos que você já sabe que funcionam.
Um bom dataset de avaliação para LLM em produção tem pelo menos três tipos de entrada:
- Casos representativos: inputs que refletem o uso real do sistema. A melhor fonte é log de produção anonimizado. Se não tem ainda, simula com base no que você sabe sobre os usuários reais.
- Casos de borda: inputs ambíguos, perguntas mal formuladas, idiomas misturados, inputs muito longos ou muito curtos. O modelo vai encontrar esses casos em produção, então o dataset precisa cobrir.
- Casos adversariais: inputs que tentam fazer o modelo sair do escopo, revelar instruções do sistema ou gerar conteúdo inadequado. Se você opera em contexto regulatório ou com dados sensíveis, isso não é opcional.
Tamanho mínimo razoável: 100 exemplos anotados. Para começar, 50 já é melhor do que nada. O importante é que cada exemplo tenha a resposta esperada, ou os critérios claros de avaliação, documentada antes de rodar o modelo.
Não usa as respostas do próprio modelo para criar o gabarito. Isso é circular e invalida o teste inteiro.
Testes de regressão: como detectar degradação
Com rubrica e dataset, você tem o que precisa para rodar testes de regressão sempre que mudar algo: modelo, versão, prompt, temperatura, contexto de sistema.
O fluxo é direto:
- Roda o modelo atual no dataset completo e registra as notas por dimensão.
- Faz a mudança que quer testar.
- Roda novamente no mesmo dataset, sem alterar os exemplos.
- Compara dimensão por dimensão, não só a nota agregada.
Isso te dá a resposta para a pergunta que importa: essa mudança melhorou ou piorou o modelo? E em qual dimensão especificamente?
Vale dizer: regressão não é só sobre detectar piora. É sobre entender trade-offs. Uma mudança de prompt pode melhorar completude mas piorar formato. Sem as dimensões separadas, você vê apenas a nota agregada e perde exatamente essa informação.
Na prática, automatiza isso. Um script Python que roda o dataset, chama o modelo, aplica a rubrica e gera um relatório comparativo. Não precisa ser sofisticado. Precisa ser executável em menos de cinco minutos para você realmente rodar antes de cada deploy, não só quando lembrar.
LLM-as-judge: prático, mas com ressalvas sérias
Uma abordagem comum para automatizar a avaliação é usar outro LLM como avaliador. Você manda a pergunta, a resposta gerada e a rubrica para um modelo mais capaz e pede que ele atribua notas por dimensão.
Funciona razoavelmente bem para dimensões como relevância e tom. Tem limitações sérias para correção factual, especialmente em domínios específicos onde o modelo avaliador pode não ter conhecimento suficiente ou atualizado.
O que eu recomendo: usa LLM-as-judge para triagem, não como critério definitivo. Ele identifica os casos que merecem revisão humana. A revisão humana confirma ou corrige. Com o tempo, você calibra o avaliador automático com base nos casos onde ele errou e vai refinando a abordagem.
Mas atenção: nunca usa o mesmo modelo como juiz de si mesmo. O viés de auto-preferência é documentado na literatura e real o suficiente para invalidar seus resultados.
Como saber se funcionou de verdade
A métrica técnica é o score médio por dimensão no dataset. Mas isso ainda é proxy. A métrica de negócio que precisa se mover depende do seu produto.
Alguns exemplos concretos de como conectar avaliação técnica com impacto real:
- Se o LLM responde dúvidas de suporte: taxa de resolução no primeiro contato, ou volume de escalações para atendimento humano.
- Se o LLM classifica documentos: concordância com classificação manual em amostra periódica.
- Se o LLM gera rascunhos: taxa de aprovação sem edição significativa pelo usuário.
O objetivo é ter uma linha de rastreabilidade entre a nota técnica no dataset e o indicador de negócio. Se você melhora o score técnico mas a métrica de negócio não move, ou a rubrica está errada, ou o dataset não representa o uso real. Esse desalinhamento é uma informação valiosa, não um fracasso do processo.
Começa simples. Dataset de 50 casos, rubrica com três dimensões, script de comparação que roda em CI antes de todo deploy de prompt ou modelo. Isso já é infinitamente melhor do que “testamos manualmente e pareceu bom”. Com o tempo, você calibra conforme aprende onde o modelo erra mais e o que o dado de produção revela.
O ponto não é ter um sistema de avaliação perfeito. É ter um sistema que você consegue confiar mais do que a intuição de quem testou na sexta à tarde antes do deploy de segunda.
