Evals de LLM na prática: como testar recursos de IA antes dos usuários
A primeira falha constrangedora de um recurso de IA raramente parece uma falha de benchmark. Parece um bot de suporte aplicando a política errada, um assistente de código alterando um arquivo proibido ou um copiloto de vendas inventando um detalhe porque o CRM estava vazio. A demo funcionou. O prompt parecia bom. Então um usuário real encontrou o caso que ninguém testou.
Evals de LLM servem para isso: não para rankings, mas para transformar expectativas de produto em testes repetíveis, gates de regressão e revisão humana.
Por que evals de LLM não são QA comum
QA tradicional verifica uma saída esperada para uma entrada conhecida. Em produtos com LLM, várias respostas podem ser aceitáveis. A rubrica precisa seguir o risco: consistência factual, completude, tom, recusas, escolha de ferramentas, permissões, recuperação e quando parar. Nosso artigo sobre confiabilidade de agentes de IA reforça a mesma ideia: o produto não é só o output, mas os controles ao redor.
Crie um golden dataset antes de mudar o prompt
Um golden dataset reúne casos realistas com comportamento esperado, notas de avaliação e metadados. Comece com 50 a 200 exemplos: tarefas comuns, falhas caras e edge cases. Para suporte, inclua tickets irritados, idiomas, informações incompletas e escalonamento. Para ferramentas de desenvolvimento, inclua pequenos bugs, refactors ambíguos, testes quebrados e limites de permissão.
Guarde tipo de tarefa, risco, fontes necessárias, ações permitidas e justificativa de aprovação. O artigo de Hamel Husain sobre LLM evals é útil porque prioriza exemplos do produto e julgamento humano em vez de benchmarks abstratos.
Compare prompts e modelos como experimentos de produto
Rode o mesmo dataset no prompt de produção, no prompt candidato e no modelo candidato. Analise por tarefa, idioma, risco e segmento, não só pela média. ChainForge ajuda a comparar prompts e saídas, Vellum oferece fluxos de prompt, evals e deploy, e DeepEval é um framework open source para testar aplicações LLM.
Registre versão do prompt, modelo, retrieval, schema de ferramentas, temperatura e instruções de sistema. Isso é essencial em fluxos multi-modelo como os do nosso artigo sobre desenvolvimento de software com LLMs.
Leve gates de regressão para CI/CD
Coloque um smoke set pequeno no CI/CD: conselhos perigosos, JSON quebrado, chamadas de ferramenta proibidas, alucinações graves e casos que exigem escalonamento. Todo PR que muda prompt, modelo, retrieval, schema ou roteamento deve executar essas evals. Falhas de alto risco bloqueiam; mudanças menores avisam.
Comece com checks determinísticos: schema válido, citações necessárias, ações proibidas, recusas e escolha simples de ferramentas. Depois adicione rubricas ou LLM-as-judge para tom, utilidade e completude. Para agentes, use padrões de MCP em produção e automação web estilo Operator: logs de ferramentas, erros classificados, schemas versionados e testes de caminhos de falha.
Revisão humana transforma falhas em testes melhores
Evals envelhecem. Revise outputs, reclamações, escalonamentos e quase-incidentes. Marque tipos de falha: contexto ausente, ferramenta errada, afirmação sem fonte, tom ruim, ação insegura, fonte antiga, excesso de recusa ou falta de recusa. Promova os melhores exemplos ao golden dataset.
PMs e especialistas de domínio devem participar, especialmente em áreas de risco. Se você já usa dashboards de agentes, conecte falhas de eval a esse funil; nosso funil de operações de agentes mostra uma forma prática.
Quando evals abertas em mundos de jogo ajudam
A maioria dos times deve começar com golden datasets e gates. Ambientes abertos valem a pena quando o produto exige planejamento longo, recuperação e muitos passos com ferramentas. O Factorio Learning Environment usa Factorio para avaliar agentes que planejam, coletam recursos, constroem e se adaptam. É demais para um FAQ bot, mas pode ajudar em agentes de navegador, coding ou operações.
Boas evals não tornam um recurso de IA perfeito. Elas tornam os trade-offs visíveis antes dos usuários. Times maduros sabem quais falhas importam, detectam regressões cedo e mantêm humanos no loop onde julgamento e responsabilidade continuam necessários.