Evals no CI: testando o que não é determinístico

Um time que coloca LLM em produção descobre cedo um problema desconfortável: a suíte de testes que garantiu qualidade por anos não serve para a feature nova. Asserção de igualdade não funciona quando a saída correta pode ser escrita de dez maneiras diferentes.

Por que o teste determinístico não cobre

Teste tradicional compara saída com valor esperado. Saída de LLM varia entre execuções, é sensível a mudanças mínimas de prompt e pode estar certa com palavras completamente diferentes das que você escreveu no gabarito.

O reflexo comum é desistir de testar e passar a validar na mão antes de cada release. Isso funciona até a terceira mudança de prompt, quando ninguém mais lembra qual comportamento era intencional e qual foi regressão.

A saída não é abandonar o teste, é trocar a pergunta. Em vez de "a resposta é exatamente esta?", pergunte "a resposta satisfaz estas propriedades?".

Três camadas, do barato ao caro

Camada 1, asserções determinísticas sobre a saída. Mais coisa cabe aqui do que parece: o JSON é válido e bate com o schema, a resposta cita ao menos uma fonte, não excede N caracteres, não contém PII, a chamada de ferramenta usou os parâmetros certos. É rápido, é estável e pega a maior parte das regressões de integração.

Camada 2, conjunto dourado com verificação programática. Trinta a cem casos reais com propriedades verificáveis: contém o número correto, classifica na categoria certa, recusa quando deveria recusar. Roda em segundos e detecta a maioria das quebras de qualidade.

Camada 3, LLM como juiz. Para o que sobra: tom, completude, utilidade. É a camada mais cara e a menos confiável, e por isso deve ser a menor.

O juiz tem vieses conhecidos

Usar um modelo para avaliar outro funciona melhor do que a intuição sugere. O trabalho que popularizou a prática mediu concordância acima de 80% entre juízes LLM fortes e preferência humana, patamar comparável à concordância entre dois humanos.

O mesmo trabalho documentou os vieses, e ignorá-los invalida o resultado:

• Posição. O juiz tende a preferir a primeira resposta apresentada. Mitigação: alternar a ordem e rodar duas vezes.
• Verbosidade. Respostas mais longas ganham nota melhor mesmo sem conteúdo adicional. Mitigação: critério explícito penalizando redundância.
• Autopreferência. O modelo tende a favorecer texto com o próprio estilo. Mitigação: usar família de modelo diferente da que gerou.

Juiz sem rubrica explícita mede estilo. Com rubrica de três a cinco critérios objetivos e escala curta, ele vira um sinal utilizável.

O que roda no CI e o que roda fora

A tentação é rodar tudo em todo push. Não faça: chamada de modelo custa dinheiro e tempo, e uma suíte de dez minutos deixa de ser executada na prática.

Um recorte que funciona: camadas 1 e 2 em todo pull request, com modelo pequeno e temperatura zero, alvo de menos de dois minutos. Camada 3 no merge para a branch principal e antes de release, em amostra. O resultado vira artefato versionado, para você comparar releases.

Trate variação como sinal, não como ruído: rode os casos críticos algumas vezes e registre a dispersão. Uma feature que oscila entre 70% e 95% no mesmo conjunto não está pronta, mesmo que a média pareça boa.

Avaliação holística, não uma nota só

Iniciativas como o HELM consolidaram uma ideia que vale para produto também: avaliar em múltiplas dimensões e cenários, em vez de reduzir tudo a um número. Precisão média alta pode esconder falha sistemática numa categoria que representa 5% do volume e 80% do risco.

Na prática, quebre o conjunto por cenário de uso e olhe o pior, não a média.

O que isso significa para o seu time

Comece hoje pela camada 1: schema, formato, presença de citação, ausência de PII. Não precisa de framework e já impede a classe de regressão mais comum.

Construa o conjunto dourado a partir de tráfego real, não de casos inventados. Toda vez que aparecer um bug em produção, o caso entra no conjunto. Em três meses você tem uma régua que reflete o seu problema, e não um benchmark genérico.

Só então adicione o juiz, com rubrica escrita e ordem alternada. E versione os resultados: sem histórico, você não consegue afirmar se a troca de modelo melhorou ou piorou a sua aplicação.