Testes de regressão automatizados para LLMs customizados em 2026

Notas do Ciclo de Release — Parte 7

Sexta-feira, 16h47, você publicou um ajuste de prompt de um único caractere. O score agregado da avaliação saiu de 0,873 para 0,871 — bem dentro do ruído. Segunda de manhã sua fila de suporte está em chamas por causa de uma classe de queries que você parou de olhar há seis meses porque estavam estáveis.

Nada no modelo regrediu. O modelo é o mesmo modelo. A avaliação é que driftou debaixo dos seus pés. Seis meses de crescimento lento em um segmento de cliente nunca entraram no golden dataset, o prompt do juiz foi calibrado pela última vez contra humanos em outubro, e o índice de retrieval se reconstruiu silenciosamente na quarta passada com um modelo de embedding atualizado.

Isso é o que o post 6 sinalizou — o modelo é a resposta certa em aproximadamente um alerta em cada sete. O que significa que sua suíte de regressão precisa detectar drift em si mesma, não só no modelo. Este post é essa suíte.

O que é, na prática, testar regressão em um LLM customizado?

Testes de regressão de software fazem output == expected para entradas fixas. Funcionam porque a função é determinística.

Um modelo de linguagem não é uma função no mesmo sentido. O mesmo prompt em temperatura > 0 produz uma distribuição de completions válidas, e “válido” é multi-dimensional: respondeu a pergunta, a resposta está embasada no contexto recuperado, ficou dentro do envelope de segurança, voltou dentro do budget de latência. Então testar regressão de um LLM customizado significa medir a distribuição de comportamento contra uma distribuição baseline congelada — através dos slices que importam para você, com juízes que foram calibrados contra humanos, em inputs que se parecem com seu tráfego de produção.

Três coisas precisam estar no lugar antes de qualquer disso fazer sentido:

1. Um golden dataset que se assemelha à produção no nível de slice, não no agregado.
2. Um juiz calibrado — não “usamos GPT-5 como juiz”, mas “medimos Spearman ρ ≥ 0,7 contra três avaliadores humanos, refrescado pela última vez na semana passada”.
3. Um manifesto de baseline — os pesos exatos do modelo, template de prompt, índice de retrieval e versão do juiz que pontuaram o que pontuaram. Sem isso você não consegue dizer se o score se moveu porque o modelo mudou ou porque a régua mudou.

A Divinci roda os três como objetos de primeira classe, encadeados por hash, pontuados em cada commit. O resto deste post é como montá-los.

Por que a maioria das suítes de regressão de LLM falha em capturar regressões reais

O modo de falha dominante em 2026 para LLMs customizados é o que o time Sigma Inference do Tianpan batizou de Semver Lie no postmortem de abril de 2026^[1]: uma métrica agregada fica estável ou melhora, enquanto um ou dois slices de produção regridem silenciosamente. O slice estava abaixo de 5% do tráfego quando o teste foi desenhado, então nunca entrou no golden dataset; seis meses depois é 12% do tráfego, o modelo degradou nele, e o número agregado nunca ia perceber.

Analisamos todo postmortem público de release de LLM dos últimos dezoito meses e o padrão se repete: a suíte ficou verde porque pontuou a coisa errada. Especificamente:

• O golden dataset foi escrito à mão pelo time no lançamento e nunca re-estratificado contra distribuições de tráfego deslocadas.
• O prompt do LLM-as-judge foi definido uma vez e nunca recalibrado contra labels humanos. A concordância do juiz decaiu silenciosamente^[2].
• Os scores baseline foram armazenados como números crus, não como tuplas (model_sha, prompt_sha, judge_sha, dataset_sha, score) — então quando algo regrediu, ninguém conseguia dizer qual dos quatro tinha se movido.

Uma suíte de regressão que não resolve os três é apenas um passo de CI que fica verde no deploy e te dá falsa confiança. A correção não é “mais casos”. A correção é medição consciente de slice, ancorada em versão, com juiz calibrado, a cada release.

Construa um golden dataset que sobrevive à análise por slice

A composição de quatro baldes que entregamos por padrão — 60% amostras de produção, 15% adversarial, 15% edge cases curados por especialistas, 10% replays de falhas — é um ponto de partida razoável. O que faz ela efetivamente pegar regressões são os metadados de slice anexados a cada caso.

Cada entrada no dataset carrega: input, comportamento esperado (rubrica, não string exata), contexto de retrieval (se houver), e uma tag slice — domínio, segmento de usuário, intenção da query, idioma, faixa de comprimento, qualquer decomposição que importe para seu produto. A suíte pontua por slice, e qualquer slice que cai abaixo do seu threshold bloqueia o release, mesmo se o score agregado subiu.

Duas regras operacionais que aprendemos a impor:

Reamostragem trimestral. Distribuições de tráfego de produção mudam mais rápido do que a maioria dos times mede. Re-estratificamos o balde de amostra de produção contra os últimos 90 dias de tráfego a cada trimestre; se algum slice cresceu acima de 5% do tráfego e estava abaixo de 2% do golden dataset, ele é backfilled antes do próximo release sair.

Todo postmortem adiciona um caso. Uma regressão que chegou à produção e não foi pega é um caso que faltava no dataset. Adicionamos ao balde de replays em até 48 horas do postmortem e marcamos com o slice que a evidenciou.

Como você detecta drift antes dos usuários?

Existem quatro tipos distintos de drift, e uma suíte de regressão que só observa o último é uma suíte que perde a maioria das regressões.

Drift de qualidade é o que a maioria das suítes mede; os outros três são onde regressões de sexta à tarde geralmente se escondem. A Divinci rastreia os quatro contra o manifesto de baseline, com o breakdown de score por slice exposto em cada PR e um job semanal de calibração do juiz que sinaliza drift antes de acumular.

Avaliação multi-dimensional — pontue quatro coisas ao mesmo tempo, por slice

Um único score composto é um sinal pior do que quatro scores escalares. Fazemos o gate em quatro dimensões:

• Conclusão da tarefa — a resposta efetivamente respondeu a pergunta, pontuada por um juiz calibrado contra uma rubrica. Consciente de slice.
• Fidelidade — para qualquer resposta que referenciou contexto recuperado, cada afirmação está embasada nesse contexto. Alucinação aparece aqui primeiro.
• Segurança — corretude na recusa, resistência a jailbreak, exposição de PII / política. Quase sempre tem gate em taxa de aprovação ≥ 0,99; segurança é parede dura, não trade-off suave.
• Budget de latência — p95 dentro do SLA do slice. Uma mudança de prompt que dobrou tokens-por-resposta é uma regressão mesmo se a qualidade subiu.

Cada dimensão tem seu próprio baseline por slice e seu próprio threshold por slice. Nunca combinamos elas em um único escalar ponderado na hora do gate; expomos como quatro scores por slice e bloqueamos no que se moveu primeiro além do seu threshold. Um modelo que ganhou 4 pontos de conclusão de tarefa ao custo de 1 ponto de fidelidade no slice médico ainda é uma regressão.

Quais gates devem bloquear o deploy de um LLM customizado?

Rodamos uma arquitetura de três camadas, cada camada fazendo gate de um estágio diferente do pipeline (veja o post 1 para a taxonomia de estágios).

Camada 1 — Smoke (a cada commit, ~90 segundos). Vinte a trinta casos críticos sacados dos slices de maior impacto. Pega regressões catastróficas antes que a suíte completa gaste compute. Se o smoke falha, o resto não roda.

Camada 2 — Suíte completa (a cada PR, ~12 minutos). O golden dataset completo, pontuado por slice em todas as quatro dimensões. Spearman ρ por slice contra o manifesto de baseline. Quebra de threshold bloqueia o merge. O comentário do PR lista exatamente qual slice em qual dimensão se moveu e por quanto, com cinco casos de falha de exemplo.

Camada 3 — Comparação contra baseline (release candidates, ~25 minutos). O modelo candidato é re-executado contra os últimos 14 dias de traces de produção — o replay de traces de produção em loop fechado que entregamos no post 1. O mesmo juiz calibrado que pontua o golden dataset também pontua as saídas do replay. Qualquer slice cujos scores de replay divirjam dos scores offline por mais do que seu threshold bloqueia o release. Esta camada é o que pega drift que o golden dataset ainda não conhece.

Calibre seu juiz antes de confiar em um único score que ele produz

LLM-as-judge é o que faz qualquer disso escalar acima de algumas centenas de casos. É também onde uma suíte de regressão silenciosamente para de funcionar, porque o juiz não tem obrigação de permanecer calibrado conforme é atualizado ou conforme sua distribuição de dados se move.

Calibramos cada prompt de juiz contra um audit set congelado, rotulado por humanos, de pelo menos 100 casos estratificados nos mesmos slices do golden dataset, e re-rodamos a calibração semanalmente. A barra que entregamos é Spearman ρ ≥ 0,7 contra a mediana dos avaliadores humanos, com Cohen’s κ ≥ 0,6 em julgamentos binários de segurança. Os dois estão acima do threshold em que juízes no estilo MT-Bench foram mostrados acompanhando avaliadores humanos no nível de concordância inter-humana^[2].

Quando a calibração semanal cai abaixo do threshold, o juiz é automaticamente aposentado e o engenheiro de eval de plantão é paginado. O pipeline de release segura candidatos em aberto em vez de fazer gate em um juiz que não está mais medindo o que costumava medir.

# Roda o job semanal de calibração do juiz
curl -X POST https://api.divinci.ai/v1/regression/judges/calibrate \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "judge_id":     "rubric-v7",
    "audit_set":    "human-labels-2026-04",
    "min_spearman": 0.70,
    "min_kappa":    0.60,
    "on_fail":      "retire_judge_and_page"
  }'

O diferencial da Divinci — replay de traces de produção em loop fechado

O gate da Camada 3 é a parte que a maioria das suítes de regressão não tem. O fluxo é o mesmo que entregamos no post 1, com uma especialização para teste de regressão: cada release candidate tem seu score no golden dataset offline comparado, slice a slice, ao seu score em uma janela de 14 dias de traces de produção re-executados. O golden dataset mede o que esperávamos que o modelo fizesse. O replay mede o que o modelo efetivamente teria feito na semana passada.

Quando esses dois scores divergem por mais do que o budget de gap por slice, o release é bloqueado. A divergência é o sinal: ou o golden dataset não é mais representativo (drift de cobertura), ou o candidato se comporta de forma diferente em traces moldados por preprocessamento e retrieval de produção (drift de produção). De qualquer forma, você descobre antes dos usuários.

O juiz que pontua a execução offline é o mesmo juiz que pontua a execução de replay. O audit log registra ambos os conjuntos de scores, ambas as versões do juiz, os IDs de trace que foram re-executados e o gap que disparou o bloqueio. O próprio gap é o sinal diagnóstico mais útil que temos, e é o que é entregue a quem pega a árvore diagnóstica do post 6 em seguida.

Ancore o golden dataset com um vindex receipt

Cada score na suíte é sem sentido se você não consegue reproduzi-lo depois. Fazemos hash do golden dataset em cada release e encadeamos esse hash em um vindex receipt junto com o SHA do modelo, SHA do prompt, SHA do juiz e o registro de calibração. O receipt é externamente ancorável — auditores podem re-executar nossa execução exata de regressão seis meses depois e verificar os scores que afirmamos.

{
  "release_id": "rel_3f1a-2026-05-26",
  "model": { "sha": "0c1f9…", "weights_uri": "r2://models/custom-v7.2", "open_weights": true },
  "prompt": { "sha": "c4a8e…", "template_id": "support-v3.4" },
  "retrieval": { "index_sha": "b21f0…", "embedder": "e5-mistral-7b-instruct" },
  "judge": { "sha": "d8e21…", "rubric_id": "rubric-v7", "spearman_vs_humans": 0.74 },
  "dataset": { "sha": "a90b1…", "n": 512, "slices": 17, "stratified_at": "2026-04-30" },
  "scores": { "aggregate": 0.872, "by_slice": { "/* … */": "/* per-slice scalars */" } },
  "replay": { "trace_window_days": 14, "n_traces": 8430, "max_gap": 0.018 },
  "vindex_anchor": "sha256:f0bfd2…",
  "verifiable_at": "https://vindex.divinci.ai/rel_3f1a-2026-05-26"
}

Ressalva sobre open-weights. O receipt acima carrega proveniência de pesos apenas quando o modelo é open-weights — o vindex ancora os bytes reais dos pesos. Para backings de modelo de API fechada (modelos gerenciados da OpenAI / Anthropic / Google), o receipt ainda carrega a cadeia de decisão — cada score de gate, cada resultado do juiz, o registro de calibração — mas o campo de pesos fica vazio, e você não pode verificar o artefato do modelo independentemente. Dizemos isso no receipt e na documentação de compliance para que auditores não fiquem com uma impressão falsa. Os releases que mais se beneficiam de uma cadeia vindex completa são aqueles em que você controla os pesos.

Um cronograma de implementação em quatro fases que efetivamente entregamos

Times que tentam entregar a arquitetura completa na semana um travam em ferramental. A ordem abaixo é a ordem que funciona.

Fase 1 — Baseline (semana 1). Pegue uma amostra estratificada dos últimos 30 dias de traces de produção. Faça dois engenheiros rotularem manualmente a conclusão de tarefa em 100 casos cada. Calcule a concordância inter-avaliadores (meta Cohen’s κ ≥ 0,6). O número que você obtiver é seu baseline humano inicial; todo o resto é calibrado contra isso.

Fase 2 — Harness (semanas 2–3). Suba o harness de avaliação no dataset de 100 casos. Adicione um juiz calibrado contra seus labels humanos. Verifique se o harness reproduz os scores humanos dentro de ρ ≥ 0,7. A maioria dos times descobre que seu primeiro prompt de juiz falha nisso e o reescreve duas vezes — isso é normal.

Fase 3 — Gates (semanas 3–4). Conecte o harness no CI como aviso, não como bloqueio. Observe por duas semanas. Os thresholds que você descobre observando taxas de falso positivo são os únicos thresholds que sobrevivem. Promova para bloqueio só quando a taxa de falso positivo estiver abaixo de 5%.

Fase 4 — Loop de replay (contínuo). Uma vez que os gates estejam bloqueando confiavelmente, habilite a camada de replay de traces de produção. É onde o gap de cobertura de slice aparece, e onde cada postmortem começa a adicionar casos de volta ao golden dataset.

O que isso não resolve

Três limitações honestas, do mesmo jeito que enquadramos a cada post desta série.

1. Drift de suíte é trabalho sem fim. Teste de regressão é infraestrutura, não projeto. O golden dataset precisa ser re-estratificado a cada trimestre, o juiz recalibrado toda semana, os budgets de threshold re-ajustados a cada postmortem. Não existe versão disso onde você entrega uma suíte e vai embora.
2. Um juiz perfeitamente calibrado ainda é um modelo. Spearman ρ = 0,74 contra avaliadores humanos significa que aproximadamente um quarto das chamadas do juiz discordam da mediana humana. Essa discordância residual é o piso de ruído em cada score. Expomos isso explicitamente em cada relatório de release; times que esquecem que ela está lá vão ser surpreendidos por ela eventualmente.
3. Backings de API fechada limitam quanto você pode verificar. Com um modelo de API fechada, a suíte de regressão mede comportamento mas não pode verificar proveniência de pesos. Se você precisa de reprodutibilidade completa — indústrias reguladas, deploys auditados — o trade-off é na escolha do modelo, não na suíte.

Próximo

O post 8, o último desta série, fecha o loop por dentro do CI. Enquanto este post e o post 5 foram sobre o que roda nos gates, o próximo é sobre a camada de CI que produz os candidatos que os gates pontuam em primeiro lugar — avaliação pre-merge, contract tests para templates de prompt, e como dimensionar a frota de CI para uma suíte de eval de 12 minutos sem quebrar o orçamento. É a camada de engenharia debaixo de tudo sobre o que escrevemos até agora.

FAQ

Qual é a diferença entre avaliação de LLM e teste de regressão de LLM?

Avaliação mede se um modelo atinge uma barra de qualidade em um ponto no tempo, contra uma rubrica absoluta. Teste de regressão mede se um candidato se comporta da mesma forma que um baseline congelado, por slice, através de múltiplas dimensões. O baseline é o que faz dele teste de regressão — a Divinci entrega ambos, e o modo de regressão pinpoints (model_sha, prompt_sha, judge_sha, dataset_sha) de forma que um score que se moveu identifica qual input se moveu.

Quantos casos um golden dataset deve ter?

Menos do que você imagina, estratificado melhor do que você imagina. Já entregamos cobertura útil de regressão com 200 casos em cinco slices bem definidos e vimos datasets de 5.000 casos que perderam tudo que importava porque não eram estratificados. Comece com 200, estratificado, depois cresça o balde de replay caso-a-caso a partir de postmortems.

Devo usar revisores humanos ou LLM-as-judge?

Os dois, com humanos calibrando o juiz. Humanos não dão conta do volume que um gate de CI de release-cycle precisa pontuar. O juiz preenche o volume, os humanos calibram o juiz — medido semanalmente com Spearman ρ ≥ 0,7. Qualquer um sozinho é modo de falha.

Como testar saídas não-determinísticas?

Pontue a distribuição, não a string. Pontue com uma rubrica que o juiz consegue aplicar através de fraseados, e rode cada input três a cinco vezes em temperatura > 0 para que o score por slice seja sobre uma distribuição de completions em vez de uma amostra única. Aperte a temperatura apenas para casos que genuinamente precisam de saída determinística (tool calls de structured-output, classificação).

Quais métricas eu devo priorizar no primeiro gate de qualidade no CI?

Conclusão de tarefa e um gate de segurança. Ambos por slice. Adicionar mais dimensões antes que as duas primeiras estejam calibradas produz ruído; times que entregam mais geralmente acabam fazendo gate no ruído. Adicione fidelidade em seguida quando ligar retrieval; adicione latência quando as duas primeiras estiverem estáveis.

References

1. Pan, Tianpan. "The Semver Lie: how a minor LLM update broke production." 29 April 2026. The named 2026 failure mode for slice-aware regression analysis; aggregate scores hold flat while a low-volume slice silently regresses.
2. Zheng et al. "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685. Empirical evidence that strong LLM judges agree with human raters at roughly inter-human-agreement levels (≈ 80%) on open-ended tasks, with reported failure modes that calibrate-against-humans audits are designed to detect.
3. Kirkpatrick et al. "Overcoming catastrophic forgetting in neural networks." PNAS / arXiv:1612.00796. The foundational result on catastrophic forgetting in fine-tuned neural networks — why a fine-tuned custom LLM has to be regression-tested for general capability loss, not just gain on the target task.
4. Amazon Web Services. "SageMaker Deployment Guardrails — blue/green deployments and canary monitoring." The closed-API contrast: gates on infrastructure metrics (latency, errors, CPU) rather than on per-slice semantic quality.
5. Spearman, C. "The proof and measurement of association between two things." American Journal of Psychology, 15(1):72–101, 1904. The rank-correlation coefficient that anchors the slice-aware gate — robust to scoring-scale drift in the judge, which is the property we needed.
6. DORA / Google Cloud. "Accelerate State of DevOps — change-failure-rate and time-to-restore-service metrics." The cross-industry baseline for "how often deploys cause incidents" and "how fast you recover." Regression suites that block at the gate move the first metric down; instant rollback ([post 5](/pt/blog/automated-llm-ci-cd-pipelines-with-instant-rollback/)) moves the second.