O problema
Um pipeline extrai dados financeiros de contratos e devolve um JSON perfeitamente formatado: chaves certas, tipos certos, nenhum erro de schema. O time libera o pipeline em produção porque "a saída está validando". Três semanas depois descobrem que o campo valor_total estava sistematicamente errado em contratos com cláusulas de reajuste — o JSON sempre foi válido, só que o número dentro dele estava errado desde o primeiro dia.
O pipeline validou a forma da resposta e nunca validou o conteúdo dela. São dois problemas diferentes, e confundir os dois é o erro mais caro desta lição.
Formato correto não é a mesma coisa que conteúdo correto
Existem dois tipos de falha completamente independentes:
- Falha de forma: a saída não segue o schema esperado — falta um campo, o tipo está errado, o JSON não fecha. Isso é detectável automaticamente por um validador de schema, sem precisar entender o domínio.
- Falha de conteúdo: a saída segue o schema perfeitamente, mas a informação dentro dela está errada, incompleta ou inventada. Detectar isso exige conhecimento do domínio — nenhum validador de schema genérico pega um valor numérico plausível mas incorreto.
Um pipeline que só valida schema está cego para o segundo tipo de falha, que costuma ser o mais caro: ele passa despercebido justamente porque a saída "parece certa".
Quando um resultado exige revisão humana
Nem toda saída precisa de revisão humana antes de ser usada — exigir isso para tudo mata a economia de automatizar qualquer coisa. A pergunta certa não é "isso pode estar errado?" (quase tudo pode), é: o erro, se acontecer, é caro o suficiente e a evidência de que está certo é fraca o suficiente para justificar revisão?
Dois fatores decidem isso:
- Custo do erro: uma sugestão de rascunho revisada por um editor humano depois tem custo de erro baixo. Uma alegação factual publicada como se fosse verificada, ou uma ação irreversível disparada automaticamente, tem custo de erro alto.
- Força da evidência: uma extração de um número que aparece verbatim no documento fonte tem evidência forte. Uma inferência que o modelo fez juntando fatos de partes diferentes do documento tem evidência mais fraca, mesmo que soe convincente.
Alto custo de erro combinado com evidência fraca é exatamente o caso que precisa de revisão humana antes de seguir adiante. Baixo custo de erro com evidência forte pode seguir direto. O erro comum é decidir isso com base em "o quão confiante o texto da resposta soa" — um modelo pode escrever uma alegação errada com o mesmo tom de confiança de uma correta. Confiança percebida no texto não é evidência de corretude.
Registrar erros de um jeito que a causa raiz sobrevive
Quando uma saída é marcada como errada — seja por revisão humana, seja por um teste automatizado — o que fica registrado importa tanto quanto o fato de ter sido pego. Um log que só guarda "essa resposta estava errada" é quase inútil seis meses depois: ninguém lembra por que estava errada, e o mesmo erro se repete.
Um registro útil de erro guarda pelo menos: qual restrição foi violada (não só "estava errado", mas "ignorou a cláusula de reajuste"), o que tornou a alternativa errada atraente o suficiente para ser escolhida, e qual regra ou verificação evitaria o mesmo erro numa próxima vez. Esse terceiro item é o que transforma um log de erro em uma melhoria real do sistema, em vez de uma lista de incidentes que se acumula sem nunca virar aprendizado.
Onde a intuição erra
- "Se o JSON validou contra o schema, a extração está correta." Confunde forma com conteúdo — são verificações independentes, e passar na primeira não diz nada sobre a segunda.
- "Uma resposta que soa confiante provavelmente está certa." O tom de um texto gerado não é evidência de corretude; a força da evidência vem da fonte do fato, não de como a frase foi escrita.
- "Revisão humana em tudo é sempre mais seguro." Ignora o custo de revisar tudo — a decisão certa é proporcional ao custo do erro e à força da evidência, não uma política de "sempre" ou "nunca".
Coloque em prática
No laboratório desta lição você vai implementar um validador de duas camadas — uma que checa forma (schema) e outra que checa sinais de conteúdo (evidência da fonte) — e uma função que decide, a partir de custo de erro e força de evidência, se uma saída pode seguir automaticamente ou precisa de revisão humana.