Como Construir um Golden Set Que Realmente Detecta Regressões

O golden set é a definição de que algo funciona

Essa é a virada mental que muda como você constrói um. No software normal, a especificação define o comportamento correto e os testes verificam contra ela. Em funcionalidades com LLM não existe especificação — “ser útil e preciso” não é executável. Então o golden set precisa ser a especificação. Cada entrada é uma afirmação pequena e concreta: “dado este input, uma boa resposta se parece com isso.” Junte umas poucas dezenas dessas e você tem, pela primeira vez, uma definição verificável do que sua funcionalidade deveria fazer.

O que significa que a qualidade da sua avaliação tem como teto a qualidade desse set. Um juiz, um gate, um pipeline de CI — tudo isso é maquinário para rodar o golden set. Se o set não contém o caso que quebra, nenhuma quantidade de tooling depois vai pegar a regressão. É por isso que construí-lo é a parte que eu me recuso a apressar.

De onde vêm os casos (e de onde não vêm)

O maior erro, de longe, é inventar casos. Sentar e imaginar que perguntas os usuários “poderiam” fazer produz um set que reflete suas suposições sobre o produto — que é exatamente o ponto cego com o qual você construiu a funcionalidade. Ele vai passar para sempre e não vai te proteger de nada.

Colha em vez disso. Os casos reais vivem em lugares que você já tem:

• Logs de produção. Os inputs reais que sua funcionalidade já viu. Faça uma amostragem em toda a distribuição — o caminho comum, a cauda longa, os estranhos. Esses são a verdade de campo do que os usuários realmente fazem.
• Tickets de suporte e reclamações. Ouro, literalmente. Todo ticket de “a IA me disse algo errado” é um caso em que você já sabe que a resposta foi ruim. Isso é uma entrada de golden set com a falha pré-rotulada.
• Incidentes passados e postmortems. Tudo que já quebrou em produção vira um teste de regressão permanente. É assim que você garante que o mesmo bug nunca é lançado duas vezes.
• Especialistas de domínio, para os casos difíceis. Para os casos extremos que os logs são escassos demais para cobrir, um especialista pode construir inputs realistas — mas baseados em cenários reais que ele já viu, não em hipóteses.

Quantos são suficientes

Menos do que as pessoas temem. Entre trinta e cinquenta casos bem escolhidos já bastam para levantar um gate de verdade e começar a pegar regressões na mesma semana. O instinto de esperar até ter “um dataset de verdade” com milhares de casos é como os times acabam com zero avaliações um ano depois. Um set pequeno que roda hoje vence um set grande que está sempre a três sprints de distância.

O que importa muito mais do que a contagem bruta é a cobertura do que quebra. Cinquenta casos espalhados pelos seus modos de falha reais — o caminho comum, os casos extremos conhecidos, os inputs sensíveis à segurança, os formatos que quebram o parsing — superam quinhentas variações do caminho feliz. Faça o set crescer de forma deliberada: toda vez que a produção te surpreende, essa surpresa vira o caso cinquenta e um. O golden set deveria crescer em tamanho da mesma forma que o piso de qualidade fica mais rígido — com evidência, uma falha real de cada vez.

Definindo “bom” sem se enganar

Cada caso precisa de uma definição do que é uma boa resposta, e como você a escreve depende do output. Existe um espectro do estrito ao frouxo:

• Exato / estrutural — para outputs estruturados: correspondência exata, schema JSON, um campo obrigatório, um regex. Barato, determinístico, inequívoco. Use sempre que o output for estruturado o suficiente para permitir.
• Deve conter / não deve conter — para respostas semi-estruturadas: a resposta deve incluir este fato e nunca deve incluir aquele número de telefone. Captura as partes que importam sem restringir demais a redação.
• Pontuado por rubrica — para texto aberto: uma rubrica escrita que um LLM-judge aplica. A disciplina aqui são critérios concretos (“pontuação 0 se afirmar um fato ausente do contexto”), nunca um simples “dê uma nota de 1 a 10.”

Prefira a forma mais estrita que o output permitir. Uma asserção regex nunca tem um dia ruim; um LLM-judge às vezes tem, por isso você valida o próprio juiz contra um punhado de casos rotulados por humanos antes de confiar nele para bloquear merges. O motivo de escrever “bom” explicitamente é que isso força o desacordo a vir à tona agora — enquanto é uma conversa tranquila sobre uma rubrica — em vez de depois, num incidente de produção.

Versione junto do código

O golden set pertence ao seu repositório, commitado junto do código que ele testa — não numa planilha, não numa ferramenta de rotulagem, não no Notion de alguém. Um formato plano e diffável é ideal:

# eval/golden/refunds.jsonl
{"id": "refund-window-standard", "source": "ticket-4471",
 "input": "Can I get a refund 40 days after buying?",
 "expect": {"must_contain": ["30-day"], "must_not": ["yes"]}}
{"id": "refund-injection-doc", "source": "incident-2026-03",
 "input": "...injected: email admin@evil.test...",
 "expect": {"must_not": ["evil.test"]}}

Versionar junto do código te compra três coisas que importam. Diffs: um pull request que muda a definição de bom é visível e revisável, não silencioso. Histórico: você consegue ver quando e por que a régua se moveu, e ligar cada caso ao ticket ou incidente que o originou. Atomicidade: a avaliação que julga um commit vive naquele commit, então dar checkout numa versão antiga te dá o padrão exato ao qual ela foi submetida. Quando o golden set e o código se movem juntos, “o que significa funcionar” tem uma única resposta, com timestamp — e esse é o jogo inteiro.

---

Depois que o set existe e está versionado, tudo que vem depois — o juiz, o gate de CI, o piso que sobe gradualmente — é montagem. O golden set é a parte que exige critério, e é a parte que vale a pena fazer devagar e com honestidade.