1

Isso é exatamente o coração da coisa — você nomeou o risco mais sutil: a saída continua válida no schema mas a intenção derrapou. Schema válido não é intenção correta.

E sim, montei. A suíte tem três tipos de caso, e o teu ponto do "passar no validador" é justamente o que ela protege:

  • replay/golden — entradas reais com a saída certa congelada. Se muda, tem que ser de propósito.
  • malformado — entrada quebrada que o sistema tem que rejeitar.
  • adversarial — a pegadinha que deveria ser barrada.

A regra de ouro que sigo: nunca regravar o golden só pra ficar verde. Se um caso adversarial quebra, não é o teste que está errado — é o sistema que deixou passar lixo. Regravar pra aceitar é ensinar o agente a colar na prova.

Sobre versionar o contrato junto: total. schema_version + motivo de rejeição estruturado é o que deixa você responder "melhorou de verdade ou só aprendeu a passar?" com dado, não com achismo.

Aliás você tocou tão em cheio no tema que virou meu próximo post — sobre o eval harness e as 5 peças que fazem isso rodar. Vou marcar você quando sair. 🙏

Carregando publicação patrocinada...
1

Muito bom. Essa distinção entre “schema válido” e “intenção correta” era exatamente o ponto que eu estava tentando formular.

Gostei especialmente da regra de não regravar o golden só para deixar verde. Em sistemas com LLM, esse tipo de disciplina parece mais importante do que em teste tradicional, porque é fácil confundir melhoria real com adaptação ao teste.

Uma coisa que fiquei pensando: você versiona esses casos por mudança de prompt/modelo também, ou mantém a suíte mais ligada ao comportamento esperado do produto?