Haiku 3 + RAG (11,8) venceu Sonnet 4 puro (5,3): o experimento que provou que contexto vale mais que modelo

Rodei a mesma bateria de tarefas duas vezes: primeiro com Claude Haiku 3 apoiado por RAG bem construído, depois com Claude Sonnet 4 sozinho, sem contexto extra. Pontuação final: 11,8 para o Haiku com RAG contra 5,3 para o Sonnet cru. O modelo doze vezes mais barato abriu 123% de vantagem.

Já tinha esse número no meu livro de Context Engineering, então minha propensão era acreditar nele mesmo. Só que refiz a conta em BRL com a tabela oficial da Anthropic de 2026 e o custo ficou pior do que eu lembrava. Daí este post.

Abaixo: o experimento, os números crus, a decisão de arquitetura que salva o Haiku e os casos em que a conta desmorona.

Onde a régua “modelo maior é melhor” quebrou

A avaliação usa quatro eixos: Factual Accuracy, Hallucination (invertido), Specificity e Honesty. Cada um vai de 0 a 5. O total é a soma menos as penalidades de alucinação e desonestidade.

Configuração	Factual	Halluc	Specif	Honesty	Total
Sonnet 4 puro (Zero Context)	0,0	3,5	1,7	3,7	5,3
Sonnet 4 + RAG	4,6	0,8	4,5	0,3	10,2
Haiku 3 puro (Zero Context)	0,0	0,7	0,3	2,7	3,7
Haiku 3 + RAG	4,8	1,7	4,0	1,3	11,8

Antes de julgar o resultado, dois detalhes.

Primeiro: o Sonnet puro tira zero em Factual Accuracy. Burrice não tem nada a ver. O que acontece é que ele responde com confiança sobre coisas que ele não pode saber: documentação interna, política corporativa, dados de negócio específicos. Isso derruba tudo.

Segundo: a Honesty do Haiku + RAG caiu de 2,7 para 1,3. Parece contra-intuitivo, mas não é. Com RAG na mesa, o modelo deixa de dizer “não sei” porque agora ele efetivamente sabe. Essa queda em Honesty é o carimbo de que o RAG entregou conhecimento real.

O detalhe cruel: Haiku + RAG (11,8) também bateu Sonnet + RAG (10,2). Traduzindo, o modelo pequeno com o contexto certo derrotou o modelo grande com o mesmo contexto. Não estamos comparando modelo pequeno contra modelo grande cru, e isso muda a leitura do resultado.

A tabela de preços que joga a régua fora

Preços atuais da Anthropic para os dois modelos, na cotação USD-BRL de julho de 2026 (5,45 BRL/USD, aproximado):

Modelo	Input (1M tok)	Output (1M tok)	Média (1 )	Média BRL
Claude Haiku 3	US$ 0,25	US$ 1,25	US$ 0,75	R$ 4,09
Claude Sonnet 4	US$ 3,00	US$ 15,00	US$ 9,00	R$ 49,05

Sonnet é 12x mais caro que Haiku. Somando o custo operacional de RAG (embeddings + vector DB + tokens extras de contexto recuperado), o Haiku + RAG fica em torno de US$ 1,125 por 1M tokens. Ainda é 1/8 do preço do Sonnet puro.

A conta de ROI (pontuação / custo):

• Haiku + RAG: 11,8 / 1,125 = 10,49
• Sonnet puro: 5,3 / 9,00 = 0,59

O ROI do Haiku + RAG chega a 17,8x o do Sonnet Zero Context. Isso não cabe em conversa de percentual, é ordem de grandeza. Quem paga Sonnet puro para tarefas de conhecimento interno está literalmente empilhando notas para queimar 17 de cada 18 reais.

Cabe o disclaimer honesto: essa conta assume razão input/output de 1

, o que é otimista para chatbot de verdade. Cenário com muito output (relatórios longos) empurra o Haiku ainda mais para a frente. Cenário com muito input (context stuffing sem RAG) derruba a vantagem do RAG, porque você acaba gastando em contexto vazio o dinheiro que economizou no modelo.

Por que exatamente o RAG salva o Haiku

“RAG” aqui não significa jogar mais texto no prompt. Isso é context stuffing, e piora tudo. RAG bem construído tem cinco passos:

1. Query — pergunta do usuário
2. Embed — converter a pergunta em vetor
3. Search — buscar chunks relevantes no vector DB
4. Retrieve — pegar os top-K trechos (K = 3 a 5, não 20)
5. Generate — o LLM responde com os trechos como contexto

O que salva o Haiku é o combo 3+4: filtrar antes de gerar. Em “pegar informação de um contexto pequeno e responder direto”, o Haiku empata com o Sonnet. Onde ele perde terreno é em “raciocinar através de ambiguidade sem apoio externo”. RAG dissolve essa ambiguidade antes de o modelo sequer ver a pergunta.

Isso conecta com o que a Anthropic publicou em setembro de 2024 sobre Contextual Retrieval: adicionar contexto explicativo a cada chunk antes de gerar o embedding melhora a recuperação em cerca de 35%. Dentro do próprio guarda-chuva “RAG” já existe uma técnica-sobre-a-técnica empurrando o teto para cima. Composição desse tipo é o que faz um modelo pequeno virar competitivo.

Uma armadilha frequente: passar 20 documentos porque “mais é melhor”. Chama-se inflação de contexto. Filtre por score de relevância acima de 0,7 e corte o resto. O RAG que ganha do Sonnet puro se parece com 3-5 chunks bem escolhidos, não com 20 chunks empilhados. E dá para medir isso na sua bateria: chunk a mais só acrescenta ruído.

Onde a conta desmorona

Antes de migrar tudo para Haiku + RAG, três cenários em que o resultado inverte:

Raciocínio em cadeia longa sem apoio externo. Tarefa tipo “dado esse problema matemático, resolva em 12 passos” continua com o Sonnet 4 na frente. RAG não ajuda porque não há “documento certo” para recuperar, e o Haiku alucina lá pelo passo 7.

Código não-trivial. Para gerar código com múltiplas dependências (não CRUD, e sim lógica de negócio de verdade), o Sonnet 4 segura a vantagem mesmo com RAG. Refatoração grande exige profundidade de raciocínio que o Haiku não tem. Aqui em casa uso Haiku para “explique este código” e Sonnet para “escreva este código”.

Latência crítica com prompt cache quente. Chatbot de suporte com o mesmo system prompt de 8k tokens em cache muda a matemática: Sonnet com cache hit sai por uns US$ 0,30 por consulta e a economia versus Haiku deixa de ser dramática. Some a isso a latência de retrieval do RAG (100-300 ms), que às vezes é o gargalo real.

Esses três casos não anulam o resultado geral, só delimitam o domínio onde ele vale. Q&A sobre conhecimento interno, atendimento com base documental, resumos de fontes específicas: aqui Haiku + RAG domina. Raciocínio puro, código complexo, latência sub-100ms: aqui Sonnet ainda faz sentido.

O que fazer segunda-feira de manhã

Quer testar no seu ambiente? Um experimento de 3 horas:

1. Pegue 20 perguntas reais do seu produto (log de suporte, tickets, o que estiver à mão). Não invente.
2. Rode cada pergunta no Sonnet 4 puro. Anote a resposta.
3. Monte um RAG mínimo: pip install anthropic chromadb sentence-transformers, chunk seus docs internos em 500 tokens, embed com multilingual-e5-large.
4. Rode as mesmas 20 perguntas no Haiku 3 + RAG top-3.
5. Um humano avalia às cegas (esconda qual é qual) nos 4 eixos.

Se a sua bateria repetir o meu resultado (Haiku + RAG > Sonnet puro), você acabou de encontrar 80% de redução de custo na infra de LLM. Se der o oposto, descobriu qual dos três casos acima é o seu, e essa descoberta vale mais do que qualquer benchmark genérico que você leia por aí.

Tenho um livro sobre Context Engineering em PT-BR que expande a metodologia do experimento. Sinceramente, rode as 20 perguntas primeiro. O livro fica para depois, quando você quiser entender por que funcionou.

Resumo

• Claude Haiku 3 + RAG (11,8) bateu Claude Sonnet 4 puro (5,3) por 123% e Claude Sonnet 4 + RAG (10,2) por 15%.
• O ROI do Haiku + RAG é 17,8x o do Sonnet Zero Context em preços de julho de 2026.
• RAG funciona porque dissolve ambiguidade antes de o modelo ver a pergunta; não porque “adiciona mais texto”.
• Três domínios ainda favorecem o Sonnet: raciocínio em cadeia longa, código complexo, latência sub-100ms.
• Teste com 20 perguntas reais do seu produto antes de acreditar em qualquer benchmark, inclusive esse.

Leituras relacionadas

• Conectei o Claude a 4 servidores MCP: 27k tokens só no handshake — o outro lado da conta de contexto
• MCP 27k vs KG 8x: qual ganha na revisão de código? — comparação análoga com knowledge graph
• Agente IA 24 horas: incidentes de segurança — quando o modelo pequeno + contexto errado vira pesadelo

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews