Quando usar RAG (e quando fine-tuning ou contexto resolvem melhor)

"Joga um RAG nisso." Virou o reflexo padrão de 2026. Cliente quer que o chatbot saiba das políticas internas? RAG. Quer que o modelo responda no tom da empresa? RAG. Quer que ele lembre de um PDF de 12 páginas? RAG de novo.

E na metade das vezes, um bom contexto ou um fine-tuning resolvia melhor, mais barato e com menos peça pra quebrar em produção.

O problema não é o RAG. RAG é uma arquitetura excelente pro problema certo. O problema é tratar RAG como resposta universal — montar um pipeline de embeddings, vector DB, reranker e chunking pra um caso que cabia inteiro numa janela de contexto, ou que era na verdade um problema de comportamento, não de conhecimento. Então vamos resolver isso de uma vez: quando usar RAG, quando partir pra fine-tuning e quando simplesmente colocar a informação no contexto resolve melhor. Tudo baseado nos quatro critérios que de fato decidem: volatilidade do dado, custo, rastreabilidade e tamanho.

TL;DR

• O que é: o guia de quando usar RAG, quando fine-tuning e quando só jogar a informação no contexto resolve melhor.
• A regra de ouro: RAG muda o que o modelo enxerga agora. Fine-tuning muda como o modelo se comporta sempre. Contexto é a opção que você ignora porque parece simples demais.
• Critérios de decisão: volatilidade do dado, custo total, rastreabilidade (audit trail) e tamanho do conhecimento.
• A verdade chata: em produção, ~60% dos sistemas usam mais de uma abordagem. A pergunta não é "qual delas", é "onde mora cada parte da inteligência".

A regra de ouro: três coisas diferentes pra três problemas diferentes

Antes de decidir, entenda que essas três opções não competem pelo mesmo problema. Elas resolvem coisas diferentes, e é por isso que escolher errado dói tanto.

Contexto (full-context prompting) é você colocar a informação direto no prompt. O manual, o documento, os exemplos — tudo dentro da janela. O modelo lê e responde. Zero infraestrutura.

RAG (Retrieval-Augmented Generation) é você guardar uma base grande fora do modelo e, a cada pergunta, buscar só os pedaços relevantes e injetar no prompt. O modelo nunca vê a base inteira — vê o que a busca recuperou.

Fine-tuning é você re-treinar os pesos do modelo com seus dados pra mudar o comportamento dele de forma permanente. Não é conhecimento que entra: é jeito de responder.

A frase que resume e que você devia colar no monitor:

RAG muda o que o modelo pode ver agora. Fine-tuning muda como o modelo tende a se comportar toda vez.

Conhecimento que muda → RAG ou contexto. Comportamento que precisa ser consistente → fine-tuning. Misturar esses dois eixos é a origem de quase todo projeto de IA que vira um Frankenstein caro.

Critério 1: volatilidade do dado

Essa é a primeira pergunta, e ela mata metade das discussões sozinha.

Seu dado muda toda semana? Toda hora? É diferente por usuário? Então fine-tuning está fora. Ponto. Re-treinar o modelo cada vez que uma política muda é absurdo — caro, lento e você acaba com dez versões do modelo que ninguém sabe qual está em produção. Pra dado volátil, a escolha é entre RAG e contexto.

A literatura é consistente nisso: RAG performa melhor quando o dado é dinâmico ou diverso. Fine-tuning brilha quando o conhecimento é estável e o que você quer mudar é a forma da resposta, não o conteúdo dela.

Regra prática:

• Dado muda em minutos/horas (estoque, preço, status de pedido): contexto ou RAG, com a fonte sendo consultada na hora — e às vezes nem é RAG, é busca ao vivo na web.
• Dado muda em semanas/meses (documentação, base de conhecimento): RAG.
• Dado é praticamente fixo (tom de voz, formato de saída, protocolo de decisão da empresa): fine-tuning é candidato — mas leia o critério 3 antes.

Se você se pegar pensando "vou ter que re-treinar o modelo sempre que isso mudar", pare. Esse é o sinal de que você está usando a ferramenta errada.

Critério 2: tamanho do conhecimento

Aqui mora o erro mais comum de 2026: montar RAG pra um problema que cabia inteiro no contexto.

As janelas de contexto explodiram. 200K tokens é commodity, 1M existe. Se toda a sua base de conhecimento cabe confortavelmente na janela — digamos, abaixo de uns 200K tokens — você provavelmente não precisa de RAG. Joga tudo no contexto, ativa prompt caching, e pronto. Sem vector DB, sem chunking, sem reranker, sem uma camada inteira de bugs de recuperação.

E o prompt caching é o que torna isso barato de verdade. Na Anthropic, leitura de tokens cacheados custa 10% do preço normal — 90% de desconto — e a OpenAI cacheia automaticamente prefixos acima de 1.024 tokens com 50% de desconto. Aquele manual de 80K tokens que você ia "ragar" pode ficar fixo no prompt, cacheado, respondendo rápido e barato.

"Mas e quando não cabe?" Aí o RAG ganha — e ganha feio. Acima de uns 400K tokens em modelos que não sejam o Gemini, RAG sobre um conjunto focado de chunks quase sempre bate o contexto longo ingênuo pro mesmo orçamento. Uma requisição de 1M tokens chega a rodar 30 a 60 vezes mais lento que um pipeline de RAG, a um custo por query absurdamente maior.

E tem uma armadilha que quase ninguém mede: contexto longo parece funcionar e falha calado. Os scores de "needle in a haystack" — achar uma agulha no palheiro — são lindos: 99% de recall com um fato escondido em 1M de tokens. Só que produção é multi-needle: você precisa de vários fatos ao mesmo tempo. E aí o recall médio despenca pra perto de 60%. O teste de uma agulha só infla o número real em 15 a 40 pontos. Traduzindo: seu protótipo com contexto longo vai parecer perfeito na demo e errar 4 em 10 perguntas reais.

Critério 3: rastreabilidade

Se o seu sistema responde sobre coisa séria — jurídico, saúde, financeiro, suporte que vira processo — essa pergunta sozinha decide.

Você precisa provar de onde veio a resposta?

RAG nasce com isso de graça. Como ele recupera documentos antes de responder, você consegue rastrear cada resposta até a fonte exata: "isso veio do parágrafo 3 da política X, versão de maio". É audit trail, é citação, é o que salva sua pele numa auditoria.

Fine-tuning é o oposto. O conhecimento vira peso dentro do modelo. Quando ele responde, não dá pra apontar a fonte — a informação foi dissolvida no treinamento. Pra ambiente regulado, isso geralmente é um veto.

Então: precisa citar fonte, mostrar evidência, passar auditoria? RAG (ou contexto com a fonte explícita no prompt, que também dá pra citar). Fine-tuning entra só na camada de comportamento, nunca como guardião de fato que você vai ter que justificar depois.

Critério 4: custo (o total, não o de hoje)

Custo é onde a conta engana. Não compare o preço da primeira chamada — compare o custo de manter aquilo vivo por um ano.

• Fine-tuning: caro pra montar (dados rotulados, treino, avaliação), barato por query depois (sem retrieval, resposta direta e mais rápida). E caro pra manter: cada mudança relevante no comportamento desejado é um novo ciclo de treino.
• RAG: barato pra começar, mas o custo escala com volume de dado e frequência de query. Você paga vector DB, reembedding quando o dado muda, e a latência extra da busca em toda requisição. Mais peças, mais coisa pra monitorar.
• Contexto: o mais barato de construir (não constrói nada), e com prompt caching o custo por query cai junto. O limite é tamanho, não dinheiro.

Repare no padrão: fine-tuning empurra o custo pra frente (build), RAG dilui no operacional (run), contexto quase zera o build mas tem teto de tamanho. A pergunta certa não é "qual é mais barato", é "onde eu aguento pagar — uma vez lá no começo, ou um pouco toda vez?".

O mapa: quando usar RAG, fine-tuning ou contexto

Junta os quatro critérios e vira um fluxograma mental que você roda em trinta segundos:

1. Meu conhecimento cabe na janela de contexto (< ~200K tokens)?
   SIM → joga no contexto + prompt caching. Pare aqui. Sério.
   NÃO → siga.

2. O dado é grande, muda com frequência, ou preciso citar a fonte?
   SIM → RAG. (volátil, grande, ou auditável = RAG ganha)
   NÃO → siga.

3. O que eu quero mudar é COMPORTAMENTO (tom, formato, protocolo),
   não conhecimento?
   SIM → fine-tuning.
   NÃO → revise o problema. Provavelmente é contexto ou RAG.

E o segredo sujo de produção: muito sistema bom faz os três. Cerca de 60% dos projetos em produção combinam abordagens. Fine-tuna pra fixar comportamento (voz da marca, formato de saída, protocolo de decisão), usa RAG pra alimentar o fato fresco e citável, e deixa no contexto o que for pequeno e estável. Não são rivais. São camadas — e a gente já destrinchou essa combinação no post sobre RAG + fine-tuning juntos na arquitetura híbrida.

Onde você vai se queimar

Os erros que mais aparecem — e que nenhum tutorial de RAG conta:

• RAG pra problema de comportamento. Você quer que o modelo responda mais formal e monta um pipeline de recuperação. Não vai resolver: recuperar texto não muda o jeito de escrever. Isso era fine-tuning ou um system prompt bem feito.
• RAG pra base pequena. 50 páginas de manual viram um projeto de vector DB. Cabia no contexto, cacheado, com metade do código e zero bug de chunking.
• Confiar no contexto longo sem medir multi-needle. Demo linda, produção furada. Se a resposta depende de juntar vários fatos espalhados, teste isso explicitamente antes de prometer.
• Fine-tuning pra dado volátil. Você treina, o dado muda na semana seguinte, e o modelo agora mente com confiança. Conhecimento que muda nunca devia ter entrado nos pesos.
• Ignorar o custo de manutenção. A POC funciona. Seis meses depois, o reembedding, o monitoramento de retrieval e os ciclos de re-treino comem o time. Decida olhando o custo de um ano, não o da primeira chamada.

FAQ rápido

RAG ou fine-tuning, se eu só puder escolher um? Depende do que dói mais. Se a dor é conhecimento que muda e precisa ser citável, RAG. Se a dor é o modelo não responder no formato/tom certo de jeito nenhum, fine-tuning. O benchmark LaRA, com 2.326 casos de teste, foi categórico: não existe bala de prata — a escolha depende da tarefa, do modelo e do tipo de dado.

Contexto longo não tornou o RAG obsoleto? Não. Tornou o RAG desnecessário pra bases pequenas, que é diferente. Pra corpus grande, multi-fato e que muda, RAG continua mais rápido, mais barato por query e mais preciso que enfiar tudo numa janela de 1M.

Dá pra rastrear a fonte usando só contexto? Dá, se a fonte está explícita no prompt e você pede a citação. A diferença é escala: contexto cita o que coube; RAG cita de uma base que não cabe. Fine-tuning puro não cita nada.

Fine-tuning não ficou barato com LoRA e afins? O treino ficou mais acessível, sim. Mas o custo que mata não é o da GPU — é o de gerar dados bons e re-treinar toda vez que o comportamento desejado muda. Isso o LoRA não resolve.

Conclusão

RAG não é a resposta. É uma resposta, ótima pro problema certo: conhecimento grande, volátil e que precisa de rastreabilidade. Quando a base é pequena, contexto com prompt caching ganha em simplicidade e custo. Quando o que você quer mudar é comportamento e não fato, fine-tuning é o caminho — e nenhuma quantidade de embeddings vai substituir isso.

A decisão não é ideológica. São quatro perguntas: cabe no contexto? muda muito? precisa citar? quanto custa manter? Responde elas com honestidade e o "joga um RAG nisso" perde a graça — porque você passa a desenhar onde cada parte da inteligência mora, em vez de aplicar o mesmo martelo em todo prego.

E é exatamente esse tipo de decisão de arquitetura — onde mora o dado, onde mora o comportamento, o que vale a pena construir e o que era complexidade desnecessária — que a gente coloca na mesa, com código rodando, no Workshop Arquitetando Soluções de IA: um dia prático montando soluções com agentes de IA sem o teatro de slide. Porque construir produto real com IA começa quando você para de escolher a ferramenta no piloto automático e passa a escolher pelo problema.