Fine-Tuning, RAG ou Prompt? Análise Técnica de Quando Usar Cada Um

“Devo fazer fine-tuning?” é uma das perguntas mais comuns — e quase sempre é a pergunta errada feita cedo demais. As três abordagens (prompt, RAG, fine-tuning) não competem; elas resolvem problemas diferentes. Confundi-las custa caro: gente faz fine-tuning de R$ milhares para um problema que um bom prompt resolveria de graça.

Este texto é o critério técnico para escolher.

O diagnóstico antes da solução

A escolha depende de qual é o problema de verdade:

• O modelo não está se comportando como você quer (formato, tom, estilo)? → começa por prompt.
• O modelo não conhece a informação (seus dados, fatos recentes)? → RAG.
• O modelo precisa de um comportamento ou formato muito específico e consistente que prompt não segura, ou você quer reduzir custo/latência de prompts gigantes? → fine-tuning.

A regra de ouro: escale na ordem prompt → RAG → fine-tuning, e só avance quando o anterior comprovadamente não resolve.

Prompt: quando basta (e é mais do que você pensa)

Prompt engineering resolve a maioria dos casos. Se o problema é o modelo não entender bem a tarefa, não seguir o formato ou não usar o tom certo, prompt (com few-shot e structured output) costuma bastar. Custo zero de setup, iteração em segundos, nenhuma infra nova.

Comece sempre aqui. Muita “necessidade de fine-tuning” some quando alguém escreve um prompt decente com 3 exemplos.

RAG: quando o problema é conhecimento

Se o modelo erra porque não tem a informação — responde sobre seus produtos errado, não sabe da política interna, inventa dados de cliente — o problema não é comportamento, é conhecimento. Fine-tuning aqui é a ferramenta errada (e cara): você não quer ensinar o modelo a “ser” diferente, quer dar a ele o dado certo na hora.

RAG também é a única das três que lida bem com informação que muda: atualizar a base é reindexar documentos, não retreinar modelo.

Fine-tuning: quando o problema é comportamento ou formato

Fine-tuning faz sentido quando:

• Você precisa de um formato/estilo muito consistente que nem few-shot garante (ex.: sempre responder num schema rígido, num tom de marca específico).
• Você tem muitos exemplos de qualidade (centenas a milhares) do comportamento desejado.
• Você quer encurtar o prompt: em vez de mandar 10 exemplos a cada chamada (caro, lento), você “assa” esse padrão no modelo e manda prompts curtos.
• Latência e custo por chamada são críticos em alto volume.

O que fine-tuning não faz: ensinar fatos novos de forma confiável. Ele molda comportamento, não é um banco de dados. Tentar usar fine-tuning para “ensinar” conhecimento factual costuma resultar em um modelo que erra com mais confiança.

Comparação direta

Critério	Prompt	RAG	Fine-tuning
Resolve	comportamento/tarefa	conhecimento	comportamento/formato consistente
Esforço de setup	mínimo	médio	alto
Custo inicial	zero	médio (infra de retrieval)	alto (dados + treino)
Custo por chamada	baixo a médio	médio (mais tokens de contexto)	baixo (prompt curto)
Atualizar informação	reescrever prompt	reindexar (fácil)	retreinar (caro)
Latência	baixa	média (busca + geração)	baixa
Risco de alucinação	médio	baixo (ancorado)	médio

As combinações são a regra, não a exceção

Na prática de produção, raramente é uma só. As combinações mais comuns:

• Prompt + RAG: o caso mais frequente. Bom prompt sobre conhecimento recuperado.
• RAG + fine-tuning: fine-tuning ensina o modelo a usar o contexto recuperado no formato certo; o RAG fornece a informação atualizada. Você combina comportamento consistente com conhecimento fresco.

Árvore de decisão

O modelo já tem a informação que precisa?
├── NÃO  -> o problema é conhecimento  -> RAG
└── SIM
     └── O comportamento/formato está bom com prompt + few-shot?
          ├── SIM -> fica no PROMPT (não complique)
          └── NÃO
               └── Você tem centenas de exemplos de qualidade
                   e volume que justifique o custo?
                    ├── SIM -> FINE-TUNING
                    └── NÃO -> volte a investir no PROMPT / eval

Conclusão

Prompt, RAG e fine-tuning não são níveis de “avançado” — são respostas a perguntas diferentes. O erro caro é pular para fine-tuning por status, quando o problema era conhecimento (RAG) ou só um prompt mal escrito. Diagnostique primeiro qual é a falha — comportamento ou conhecimento — e escale na ordem prompt → RAG → fine-tuning. A solução mais sofisticada raramente é a certa; a certa é a mais simples que resolve o problema que você realmente tem.