RAG vs fine-tuning: quando cada um cabe

RAG e fine-tuning resolvem problemas diferentes, e a confusão entre os dois é onde projeto de IA queima orçamento. RAG entrega conhecimento atualizável e auditável; fine-tuning entrega comportamento, estilo ou formato que prompt sozinho não consegue induzir. Empresa que decide investir em fine-tuning antes de esgotar prompt + RAG geralmente está resolvendo o problema errado, com a ferramenta cara. Esse texto entrega critério estruturado de decisão.

O que cada um faz

RAG é arquitetura. O sistema busca documentos relevantes na base interna via embedding + vector database, entrega como contexto pro modelo, e o modelo gera resposta condicionada. O conhecimento fica na base; o modelo não muda. Atualizar é reindexar; reverter é tirar do índice.

Fine-tuning é treinamento adicional. A empresa pega modelo pré-treinado, alimenta com dataset específico, ajusta os pesos. O conhecimento fica nos pesos do modelo; a empresa precisa cuidar do modelo customizado. Atualizar é re-treinar; reverter é manter modelo anterior.

A diferença operacional é estrutural. RAG é "modelo lê documento"; fine-tuning é "modelo aprende a fazer X de jeito Y". Confundir leva a investir em fine-tuning quando o problema era recuperar informação, ou em RAG quando o problema era estilo da saída.

Trade-offs lado a lado

A leitura cruzada da tabela já dá o veredicto na maioria dos casos: pra problemas de "preciso que o modelo saiba X que está nos meus documentos", RAG é claramente melhor. Pra problemas de "preciso que o modelo escreva exatamente do jeito Y que prompt não consegue", fine-tuning começa a fazer sentido.

Quando RAG cabe

Cinco cenários típicos onde RAG é a escolha certa.

Conhecimento que muda com frequência. Política de RH, catálogo de produto, regulamentação setorial, FAQ corporativo. Atualização precisa propagar em horas, não em ciclo de re-treino.

Auditoria e citação obrigatórias. Setor regulado (financeiro, saúde, jurídico) que exige rastreabilidade da fonte de cada afirmação. RAG entrega isso por design; fine-tuning não.

Volume de dado proprietário sem dataset rotulado. Empresa com 10.000 documentos internos, sem ninguém pra rotular pares pergunta-resposta. RAG cabe direto; fine-tuning exigiria curadoria humana cara.

Domínio coberto por modelo geral. Pergunta sobre conhecimento corporativo cuja linguagem é português corrente. Modelo geral (Claude, GPT, Gemini) já entende a língua; só precisa do contexto. RAG fornece o contexto.

Time pequeno sem expertise em ML. Implementar RAG exige engenharia de software (parser, chunker, integração). Implementar fine-tuning exige engenharia de ML (dataset, training loop, evaluation, deployment). Empresa típica tem o primeiro time, não o segundo.

Quando fine-tuning cabe

Três cenários raros onde fine-tuning entrega o que RAG não entrega.

Estilo proprietário consistente. Empresa precisa que toda saída do modelo siga voz de marca específica, formato de relatório regulado ou estrutura padronizada. Prompt + few-shot resolve em parte; fine-tuning garante consistência em volume.

Domínio com vocabulário muito específico. Medicina especializada, química industrial, jurídico técnico de nicho. Modelo geral pode não capturar nuance entre termos próximos. Fine-tuning ajusta o entendimento. Antes disso, vale tentar fine-tune do embedding do RAG, que é mais barato.

Latência ou custo inviáveis com modelo grande. Caso de uso em alta escala onde modelo grande sai caro ou lento. Fine-tunar modelo pequeno (LLaMA 8B, Mistral 7B) pra tarefa específica pode entregar performance equivalente com fração do custo. Pesquisa da Anthropic e da OpenAI confirma esse pattern em casos de uso bem delimitados.

Em todos os três, a regra prática: tentar prompt sofisticado + RAG primeiro, medir gap em eval com casos representativos, e só investir em fine-tuning depois de comprovar que o gap não fecha sem ele.

Quando combinar (RAFT e RAG + fine-tuning)

Combinar RAG e fine-tuning é abordagem avançada com retorno comprovado em casos específicos. Paper RAFT (Retrieval Augmented Fine-Tuning, 2024) mostrou ganho de até 35% em domínios especializados (medicina, finanças) ao fine-tunar o modelo pra usar o contexto recuperado de forma mais robusta. A combinação faz sentido quando:

• O domínio tem vocabulário muito específico (justifica fine-tuning) E o conhecimento muda (justifica RAG).
• O modelo precisa aprender a tratar contexto com ruído ou contradição (RAFT ensina a discriminar).

Não vale a pena pra maioria das empresas. Custo somado dos dois é alto, e ganho marginal frequentemente cabe em prompt mais elaborado.

Decisão arquitetural em 5 passos

Sequência prática pra equipe técnica decidir sem queimar orçamento.

1. Esgotar prompt engineering primeiro. Few-shot, chain-of-thought, structured output, tool use. Uma fração significativa dos casos resolve aqui sem precisar de RAG.

2. Avaliar se o problema é de conhecimento. Se o modelo precisa saber algo que está nos seus documentos, RAG é o caminho. Implementar pipeline básico (parser + chunker + embedder + vector DB) e medir eval.

3. Otimizar o RAG antes de pular pra fine-tuning. Hybrid search, reranking, query rewriting, melhor parser. A maior parte do gap residual fecha em otimização do RAG, não em fine-tuning.

4. Se o gap é de estilo, formato ou vocabulário específico, considerar fine-tuning de embedding (mais barato que fine-tuning de modelo de geração).

5. Fine-tuning de modelo de geração só depois de provar que (1) (2) (3) (4) não fecham o gap. Provar com eval objetiva, não com sensação. A maior parte dos projetos para antes desse passo, e está certa.

Custo na prática: ordens de grandeza com fontes

Custos absolutos variam muito por contexto da empresa. Em vez de inventar tabela em reais, vale citar dados públicos que ancoram a magnitude.

A leitura cruzada da tabela: o custo de operação de RAG com caching fica em ordem de grandeza menor que sem caching, e fine-tuning agrega tanto custo de treinamento quanto inference 3x mais cara. Pra empresa brasileira, multiplique a base em USD pelo câmbio do dia, adicione customização local e considere os hidden costs que inflam TCO sobre o que o vendor cotou.

Estimativa específica pra projeto da sua empresa exige cotação direta com vendor sobre carga real, em vez de tabela genérica. Como argumento em Como medir ROI de projeto de IA, custo de oportunidade também entra na conta: o time que está fazendo fine-tuning não está fazendo outro projeto.

A pergunta que define a decisão

Antes de aprovar fine-tuning, três perguntas:

1. Esgotamos prompt engineering com few-shot, chain-of-thought e structured output, com eval que mede o gap?
2. Implementamos RAG otimizado (hybrid search, reranking, parser bom) e medimos o que falta?
3. O gap residual é claramente de estilo, formato ou vocabulário específico que documento como contexto não resolve?

Se as três respostas são sim, fine-tuning faz sentido. Se qualquer uma é "ainda não fizemos", o investimento em fine-tuning vai resolver o problema errado. Aprofundamento de cada estágio em O que é RAG e no glossário em fine-tuning.

Referências

• Lewis, P. et al (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• Zhang, T. et al (2024). RAFT: Adapting Language Model to Domain Specific RAG.
• OpenAI (2024). Fine-tuning best practices.
• Anthropic (2024). Building effective agents.
• Finout.io (2026). Anthropic API Pricing in 2026: Complete Guide.
• USM Systems (2025). AI Software Cost: 2025 Enterprise Pricing Benchmarks.