Claude Haiku como revisor: dá para usar o modelo leve para checar a saída de outro modelo?

Colocar um modelo barato pra conferir a resposta do modelo caro virou padrão de arquitetura

E no papel faz todo sentido: a camada de verificação roda em TODA chamada, então ela precisa ser rápida e barata, senão você dobra a conta só pra ter uma segunda opinião

Só que tem um detalhe cruel aí

Um revisor ruim não é neutro, ele é pior que revisor nenhum: ele carimba lixo com selo de aprovado e ainda te dá a sensação gostosa de que o pipeline está validado 😀

Então bora separar duas coisas que vivem misturadas nessa conversa: o que um modelo leve checa com critério objetivo, e o que ele simplesmente não tem como julgar

O que um modelo leve consegue checar e o que ele erra

A pergunta certa não é "o Haiku é inteligente o suficiente?"

A pergunta é: o critério dessa checagem é objetivo ou é opinião?

Critério objetivo é aquele que tem resposta verificável olhando pro material: o campo existe ou não existe, a resposta cita o trecho ou não cita, a instrução dizia 3 itens e vieram 3

Critério vago é "a resposta está boa?"

Se liga na divisão:

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Repara na primeira linha, porque ela derruba metade dos revisores que a galera monta por aí

A documentação da Anthropic é explícita: se você precisa que o Claude sempre produza JSON válido conforme um schema específico, use Structured Outputs em vez de técnicas de engenharia de prompt, porque elas oferecem conformidade garantida com o schema

E Structured Outputs está em disponibilidade geral na Claude API, incluindo o Claude Haiku 4.5 (a lista cobre também Claude Mythos Preview, Opus 4.7, Opus 4.6, Sonnet 4.6, Sonnet 4.5 e Opus 4.5)

São dois modos: saída JSON pelo campo output_format, ou uso estrito de ferramenta com strict: true, que garante validação de schema no nome e nos inputs da tool

E tem mais: os SDKs de Python e TypeScript transformam o schema, validam a resposta automaticamente e integram com Pydantic e Zod

O método parse() já te devolve o parsed_output validado

Ou seja: checagem de schema saiu da mão do revisor LLM

Isso é ÓTIMO pro seu bolso, porque sobra pro modelo leve só a parte que é de fato semântica

Quando a revisão por modelo leve compensa (e como montar o prompt do revisor)

A camada barata rende em quatro cenários bem específicos:

1. Alto volume de saídas repetitivas, onde o mesmo prompt de sistema roda milhares de vezes e o custo por chamada é o que decide se a arquitetura existe ou não
2. Pipelines com schema fixo, onde o formato já está garantido e o revisor só olha conteúdo
3. Checagem de ancoragem, o caso mais confortável: você deu um texto, a resposta precisa estar naquele texto, e o revisor confere trecho por trecho
4. Triagem, onde o leve não dá o veredito final, ele só separa o que é caso duvidoso e manda pro modelo forte

Esse quarto item é o que mais faz diferença na conta, e é a mesma lógica de escolher o modelo certo por tarefa: quem decide não precisa ser quem filtra

Como montar o prompt do revisor:

A Anthropic tem recomendações públicas pra reduzir alucinação que caem como uma luva na camada de checagem

Primeira: permita explicitamente que o modelo diga que não sabe

Parece bobo, mas revisor sem essa saída inventa um veredito, porque você pediu um veredito

Segunda: em textos longos (acima de 20 mil tokens), peça citações literais do documento ANTES da tarefa

A citação vem primeiro, o julgamento vem depois, apoiado nela

Terceira: use mecanismos de checagem de fatos e citações que ancorem a resposta no material fornecido

Na prática, o critério do revisor tem que virar uma lista fechada de perguntas verificáveis, tipo assim:

Você é um verificador. Não reescreva a resposta, não melhore nada.

Material de referência:
<documento>{{DOCUMENTO}}</documento>

Resposta a verificar:
<resposta>{{RESPOSTA}}</resposta>

Para cada pergunta abaixo, cite primeiro o trecho LITERAL do documento que
sustenta a sua conclusão. Se não existir trecho, responda "NAO_SEI".

1. Toda afirmação numérica da resposta aparece no documento? (sim / nao / NAO_SEI)
2. A resposta ficou dentro do limite de itens pedido na instrução? (sim / nao)
3. Existe alguma afirmação na resposta que NÃO tem apoio no documento?
   Liste cada uma.

Veredito: APROVADO apenas se 1=sim, 2=sim e 3 estiver vazio.

Repara no que esse prompt faz: ele não pergunta se a resposta está boa

Ele pergunta coisas que têm resposta checável, e amarra o veredito numa regra mecânica no fim

Tome cuidado com o oposto disso!

Critério vago vira aprovação automática

Se você escreve "avalie se a resposta é útil e precisa", o que você montou não é um revisor, é um gerador de "sim" com custo de API 🙂

Haiku 4.5, Sonnet 5 e Opus 5: custo e velocidade na camada de verificação

O Claude Haiku 4.5 é o modelo pequeno mais recente da família Claude e está disponível para todos os usuários

A conta da camada de verificação começa aqui:

No caso do Sonnet 5, esse valor foi anunciado como introdutório e virou o preço padrão

Agora os números medidos do Haiku 4.5, que é onde ele brilha de verdade numa camada que roda o tempo todo:

No anúncio do modelo, a Anthropic afirma que o Haiku 4.5 entrega desempenho de código parecido com o do Sonnet 4 por um terço do custo e com mais que o dobro da velocidade

E tem a parte que muda a conta de quem roda revisão em volume: até 90% de economia com prompt caching e 50% com processamento em lote (Batch)

Isso importa MUITO aqui, porque o revisor repete o mesmo prompt de sistema em toda chamada

É literalmente o cenário desenhado pro cache

Se o teu caso ainda está no protótipo e tu só quer comparar saídas na mão antes de plugar API, dá pra testar o Sonnet 5 sem assinar nada e sentir a diferença de julgamento entre os modelos

Veredito: onde o Haiku como revisor quebra e o que fazer antes de confiar nele

Agora a parte que ninguém coloca no post de arquitetura bonitinha

Problema 1: viés de concordância

O estudo Beyond Consensus mede a taxa de verdadeiro negativo (TNR) de validadores de ponta abaixo de 25%

Traduzindo: o validador é ruim justamente em dizer "está errado"

E isso superestima a precisão do gerador, que é exatamente o contrário do que você queria com a camada de revisão

O experimento usou 366 programas incorretos de ensino médio

O ensemble chamado Minority Veto mitiga mais que a votação por maioria, mas a acurácia continua limitada pela TNR baixa dos modelos individuais

Ou seja: juntar vários juízes ruins não fabrica um juiz bom

Problema 2: as master keys

O artigo One Token to Fool LLM-as-a-Judge identifica "master keys": símbolos como : ou . e aberturas genéricas como Thought process: ou Let's solve this problem step by step. que geram recompensa falsa positiva

Ataques simples levam a taxas de falso positivo de até 80%, atingindo modelos de ponta como GPT-o1 e Claude-4

Lê de novo: o juiz aprova um token solto como se fosse resposta correta 😛

Os autores propõem uma mitigação por data augmentation, usando saídas truncadas como exemplos negativos adversariais, o que gerou os Master Reward Models (Master-RMs), robustos a esses ataques

Problema 3: o tamanho do juiz

Depender de modelos menores, apesar de econômico, pode introduzir inconsistências e desalinhamento com julgamentos humanos, além de classificação incorreta de respostas

Obter avaliação confiável de modelos menores, mais rápidos e baratos, é uma fronteira ATIVA de pesquisa, não um problema resolvido

Então o veredito honesto é esse: Claude Haiku como revisor é uma boa peça de engenharia quando você dá pra ele um critério fechado e um material pra ancorar, e é uma armadilha quando você pede julgamento de correção

O que fazer ANTES de confiar nele, na ordem:

1. Restrinja o revisor a critério objetivo e ancorado, com lista fechada de perguntas e a saída "NAO_SEI" liberada
2. Deixe formato e schema com o Structured Outputs, nunca com o juiz
3. Valide o juiz antes de plugar: a recomendação metodológica é reportar resultados de pelo menos DOIS benchmarks, escolhidos pra cobrir o eixo preferência versus correção, em vez de depender da discriminação de um único dataset
4. Guarde julgamento de correção pro modelo forte, ensemble ou humano

Um juiz que você nunca mediu não é um guardrail, é decoração

Conclusão

A divisão de trabalho que sobra depois de tudo isso é bem clara

Formato vai pro Structured Outputs, com validação no SDK, sem LLM revisor no meio

Checagem objetiva e ancorada vai pro modelo leve: campo vazio, instrução descumprida, afirmação sem apoio no documento fornecido

Julgamento de correção continua exigindo modelo forte ou revisão humana, e não adianta querer economizar justo aí

O próximo passo prático é chato e é o que separa pipeline sério de pipeline de fé:

1. Escreva cada critério do revisor em forma de pergunta verificável (se a resposta pode ser "depende", o critério ainda está vago)
2. Monte um conjunto de casos com erros CONHECIDOS, que você mesmo plantou
3. Meça quantos desses o revisor reprova, e só depois decida se confia na camada

Se ele aprovar os casos quebrados, você não perdeu tempo, você descobriu antes de produção descobrir por você…

Até o próximo post! =)