Avaliação contínua de LLMs: datasets de regressão que sobrevivem à troca de modelo

Toda equipe que coloca um LLM em produção descobre a mesma verdade, cedo ou tarde: o modelo que passou no teste manual da semana passada não é o mesmo que está respondendo hoje. Provedor atualiza o modelo, alguém ajusta um prompt "só um pouco", e a qualidade despenca sem aviso. Sem um dataset de regressão e gates automatizados, cada mudança é uma aposta.

Este artigo descreve como construir essa rede de segurança: de onde tirar os casos, quais métricas medir, como calibrar um LLM-as-judge e como plugar tudo isso no pipeline de CI.

Por que testes manuais não escalam

Revisão manual funciona para validar uma feature nova. Ela não funciona como guarda-corrado contínuo porque:

• é lenta demais para rodar a cada pull request;
• é inconsistente entre revisores e ao longo do tempo;
• não captura regressões sutis (uma resposta 5% pior, não claramente errada).

O substituto é um dataset versionado de casos reais, avaliado automaticamente, com humanos entrando apenas para calibrar o avaliador — não para revisar cada execução.

Montando o dataset a partir de casos reais

Datasets sintéticos enviesam para o que o time imaginou que aconteceria. Casos reais capturam o que de fato acontece.

1. 1.Coleta: extraia interações de produção (com consentimento e anonimização quando aplicável), priorizando casos com feedback negativo do usuário, escalonamento para humano, ou baixa confiança do modelo.
2. 2.Curadoria: remova duplicatas e casos triviais; mantenha uma distribuição representativa de intents, não só os "difíceis".
3. 3.Rotulagem: cada caso recebe uma resposta de referência (gold) ou critérios de aceitação, revisados por um especialista de domínio — não pelo próprio engenheiro que escreveu o prompt.
4. 4.Versionamento: trate o dataset como código. Cada adição de caso é um commit, com justificativa (bug encontrado, edge case novo, mudança de política).

Um dataset de regressão saudável cresce continuamente: todo incidente de produção vira um caso novo, para que o mesmo erro nunca escape duas vezes.

Métricas que importam

Uma única métrica de "qualidade" esconde mais do que revela. Separe em dimensões:

Formato, latência e custo são baratos de checar e devem rodar como testes determinísticos, sem envolver julgamento de qualidade. Reserve o LLM-as-judge para exatidão factual e aderência à fonte, que exigem interpretação.

LLM-as-judge calibrado por revisão humana

Usar um LLM para avaliar outro LLM é prático, mas só é confiável se calibrado:

1. 1.Rode o judge contra uma amostra do dataset (50–100 casos) e colete o score dele.
2. 2.Peça a especialistas humanos que avaliem os mesmos casos, cegos ao score do judge.
3. 3.Calcule a concordância (Cohen's kappa ou correlação simples). Abaixo de ~0.7 de concordância, o prompt do judge precisa de ajuste — geralmente falta especificidade nos critérios ou exemplos de calibração (few-shot) no próprio prompt de avaliação.
4. 4.Repita a calibração sempre que trocar o modelo do judge, não só do sistema avaliado.

Um erro comum é usar o mesmo modelo como sistema e como juiz sem checar viés de auto-preferência: modelos tendem a dar notas mais altas para respostas com o próprio "estilo". Prefira um judge de família diferente do modelo avaliado, ou pelo menos documente o viés e ajuste o threshold.

Gates em CI

Com métricas e judge calibrado, o pipeline fica direto:

PR abre mudança de prompt/modelo
   │
   ▼
Roda dataset de regressão completo
   │
   ├─ Testes determinísticos (formato, schema) → falha bloqueia merge
   ├─ Latência/custo → falha se acima do threshold acordado
   └─ LLM-as-judge (exatidão, aderência) → falha se score cair abaixo do baseline
   │
   ▼
Merge permitido apenas se todos os gates passarem

Defina thresholds como diferença relativa ao baseline, não como valor absoluto fixo — isso evita que o gate fique obsoleto quando o produto evolui legitimamente. Por exemplo: "score de exatidão não pode cair mais que 2 pontos percentuais em relação ao commit anterior na branch principal".

Detecção de drift ao trocar de modelo ou prompt

Regressão automatizada cobre PRs, mas drift também acontece fora de mudanças explícitas de código: quando o provedor atualiza um modelo "por trás", ou quando o comportamento muda com o tempo por ajustes do fornecedor.

• Rode o dataset de regressão em cadência fixa (diária ou semanal) contra o modelo em produção, não só em CI de PR.
• Alerte quando o score cair além do threshold mesmo sem deploy novo — é o sinal de que o provedor mudou algo.
• Congele a versão do modelo (quando a API permitir) para releases críticos, e trate upgrades de modelo como uma mudança deliberada, passando pelo mesmo gate de regressão.
• Mantenha um snapshot de outputs por versão de modelo, para diffs manuais quando o judge sinalizar queda mas a causa não for óbvia.

O que fazer na segunda-feira

• Exporte 30 a 50 interações reais de produção, priorizando reclamações e escalonamentos, e monte a primeira versão do dataset de regressão.
• Separe as métricas em determinísticas (formato, latência, custo) e as que exigem judge (exatidão, aderência), e escreva testes automatizados para as primeiras hoje mesmo.
• Rode uma calibração inicial do LLM-as-judge contra 20 casos revisados por um humano do time, e registre a concordância como baseline.
• Adicione um gate simples no CI: bloquear merge se o score de exatidão cair mais que um valor combinado com o time.

Leitura complementar

Trilha executiva:

• Prompt engineering não morreu. Subiu uma camada. — a leitura de negócio deste mesmo tema.