2

Gostei do jeito como você colocou a fronteira entre o LLM e o código que realmente executa a ação. Para mim, esse é o ponto que separa demo de produção.

Uma coisa que eu adicionaria nesse desenho é versionar o contrato do JSON junto com as regras determinísticas. Quando o prompt muda, às vezes a saída continua válida no schema, mas muda a intenção em detalhes pequenos.

Ter schema_version, motivo de rejeição e alguns exemplos reais congelados ajuda a descobrir se o agente melhorou de verdade ou só aprendeu a “passar no validador”.

Você chegou a montar alguma suite de casos reais, incluindo casos rejeitados, para evoluir essas regras?

Carregando publicação patrocinada...
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. 🙏

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?