Blog

Nossas últimas novidades

Tempo de Leitura

min

Testes de regressão para prompts e RAG: como evitar que a IA piore a cada mudança

Aprenda a criar uma suíte de testes para IA generativa: dataset de casos, critérios de avaliação, LLM-as-judge com cautela, comparação com baseline e como rodar em CI.

02 de março de 2026

Em IA generativa, “um ajuste pequeno no prompt” pode quebrar 10 coisas sem ninguém ver.
Teste de regressão é o freio de mão.

Regressões em IA acontecem por motivos que não existem em software tradicional:

trocou o modelo (ou a versão)
mudou o prompt (mesmo uma frase)
mudou o chunking/embeddings no RAG
entrou conteúdo novo na base
adicionou uma ferramenta (tool calling)

Sem um conjunto de testes, você descobre o problema quando o usuário reclama — e aí é tarde.

O que você vai aprender

O que testar em prompts, RAG, modelos e tools
Como montar um dataset de casos (sem expor dados sensíveis)
Como definir critérios objetivos (e quando usar LLM‑as‑judge)
Como comparar com baseline e bloquear regressões
Checklist final + referências

A visão geral (pipeline de regressão)

Pense nisso como um CI para IA: se a mudança piorar além do limite aceitável, não sobe.

1) Comece com um dataset pequeno e realista

Um dataset “bom o bastante” já funciona com 30–100 casos, desde que seja representativo:

perguntas frequentes de suporte
casos críticos (financeiro, segurança, privacidade)
perguntas que costumam dar alucinação
casos onde a resposta precisa citar fonte (RAG)

Dica: colete casos de logs, mas redija PII (ou gere casos sintéticos com a mesma estrutura).

Se o seu sistema tem RAG, inclua no caso:

pergunta do usuário
contexto esperado (categoria, produto, tenant)
quais fontes deveriam ser recuperadas (quando fizer sentido)

2) Defina “o que é bom” com critérios claros

Evite critérios subjetivos demais (“ficou melhor”).

Critérios úteis:

correto / incorreto (quando dá para ter gabarito)
completude (respondeu o que foi pedido?)
formato (JSON válido? lista? até X linhas?)
segurança (não vazou dado, não ignorou política)
em RAG: citou fonte? a fonte é relevante?

Um modelo de caso (simplificado):

id: "faq-012"
input: "Como faço para redefinir minha senha?"
expected:
  must_include:
    - "passo"
    - "e-mail"
  must_not_include:
    - "senha atual do usuário"
  rag:
    should_cite: true
    expected_sources_any:
      - "central-ajuda/reset-senha"

3) Escolha avaliadores (regras + humano + LLM)

Você pode combinar:

regras de código (regex, JSON schema, presença/ausência de termos)
revisão humana (amostra pequena e frequente)
LLM‑as‑judge (um modelo avaliando outro), com cuidado

LLM‑as‑judge funciona bem para:

comparar duas respostas (A vs B)
pontuar critérios simples com rubric
avaliar estilo e completude

Mas ele tem riscos:

pode ser instável entre runs
pode se influenciar por “texto bonito”
pode errar factualidade

Por isso, use como sinal, não como juiz único. E mantenha uma amostra humana.

4) Compare com baseline (a parte que evita “achismo”)

O padrão que funciona:

escolha uma versão baseline (prompt/modelo/config)
rode o dataset
rode a nova versão
compare scores e diffs
aprove/reprove com thresholds

Exemplos de gates:

“não pode aumentar alucinação em mais de 2%”
“resposta com fonte em RAG deve ficar ≥ 90%”
“JSON inválido deve ser 0%”
“p95 de latência não pode piorar > 15%”

5) Rode isso no CI e versiona tudo

Versione:

prompt (e templates)
configuração do RAG (chunking, top‑k, rerank)
modelo e parâmetros (temperature, max tokens)
dataset de testes

E rode em:

PRs que mexem em prompt/RAG/tools
upgrades de modelo
mudanças de dados relevantes (reindexação grande)

Isso vira parte do LLMOps: LLMOps: métricas, logs e evals.

Erros comuns em testes de IA

Dataset “bonitinho” demais (só casos fáceis)
Resultado: passa no teste e quebra no mundo real.
Não testar segurança/privacidade
Resultado: regressão silenciosa de vazamento.
Usar só LLM‑as‑judge sem validação
Resultado: falsa sensação de qualidade.
Não versionar dados/configs
Resultado: não dá para reproduzir o que aconteceu.