Fine-tuning vs RAG: a árvore de decisão honesta

90% dos casos resolve com RAG. Os outros 10% justificam fine-tuning. O problema é separar os dois grupos antes de gastar.

Quando uma empresa percebe que LLM genérico não responde direito sobre o domínio dela, surge a pergunta recorrente: "precisamos fazer fine-tuning". Quase sempre a resposta é não. Quase sempre o que resolve é RAG bem feito. Quase sempre a empresa só descobre isso depois de gastar R$ 30-100 mil em uma tentativa de fine-tuning que não trouxe ganho mensurável.

Este texto é a árvore de decisão que ajuda a evitar esse caminho. E quando fine-tuning é a resposta certa, deixa claro por quê.

O que cada técnica resolve

RAG (Retrieval-Augmented Generation)

Resolve o problema de conhecimento: o modelo não sabe sobre seus dados, então você busca em uma base vetorial e injeta no contexto. O modelo continua o mesmo; o que muda é o que ele recebe.

• Atualiza em tempo real (mudou o documento, reembedou, pronto)
• Auditável (você sabe qual chunk virou qual resposta)
• Custo previsível (tokens de contexto + chamada da API)
• Não exige GPU nem time especializado

Fine-tuning

Resolve o problema de comportamento: o modelo não responde no estilo, formato, tom ou vocabulário específico que você precisa. Você ajusta os pesos do modelo (ou um subconjunto via LoRA) para internalizar o padrão.

• Custo inicial alto (dataset + treinamento)
• Pesos congelam o conhecimento no momento do treino
• Atualizar exige novo treinamento
• Auditabilidade menor (o modelo "decorou", não busca)
• Pode reduzir latência e custo por chamada em produção

A regra geral que funciona

Se o problema é "o modelo não sabe X", use RAG. Se o problema é "o modelo não fala/escreve do jeito Y", considere fine-tuning. Se for os dois, comece por RAG.

A maioria dos casos corporativos é o primeiro: a empresa quer um chatbot que responda sobre os manuais internos, sobre o produto, sobre a política interna. Isso é conhecimento. RAG.

Quando fine-tuning realmente faz sentido

1. Estilo e tom muito específicos

Você precisa que o modelo escreva em um voz/tom muito particular que não dá pra descrever bem em prompt. Exemplos reais: gerar copy publicitário no estilo de uma marca específica, escrever no estilo de um autor, manter o vocabulário interno (jargões corporativos profundos).

Sinal de que esse é seu caso: você tentou prompt com 20 exemplos few-shot e ainda não chegou no resultado. Aí faz sentido pegar 500-2000 exemplos e fine-tunar.

2. Domain-specific tokens / linguagem técnica densa

Modelos gerais têm cobertura limitada de tokens em domínios muito específicos (química medicinal, jurídico brasileiro, terminologia médica em português, código em linguagens raras). Fine-tuning melhora compreensão e geração nesses contextos.

3. Latência crítica ou custo em escala massiva

Se você faz 50 milhões de chamadas/mês, e cada chamada poderia ser respondida por modelo menor após fine-tuning, a economia justifica o investimento. Aqui o cálculo importa: você precisa fechar o ROI considerando custo de treino, serving e manutenção.

4. Output muito estruturado e repetitivo

Tarefas como classificação, NER (Named Entity Recognition), extração estruturada em alto volume podem ser feitas por modelo menor fine-tunado com 1000-5000 exemplos, gastando 1/20 do custo de chamar GPT-4o pra mesma coisa.

5. Dados que não podem sair da sua infraestrutura

Compliance exige rodar tudo local? Aí você está fine-tunando Llama, Mistral ou Qwen. Não é fine-tuning por desempenho — é fine-tuning por arquitetura de risco.

Custos comparados em 2026

Custo de implementar RAG do zero

• Tempo de engenharia: 2-4 semanas para versão sólida
• Infra mensal: $50-300 (vector store + embeddings + storage)
• Por interação: $0.001 a $0.01 dependendo do modelo
• Atualização da base: incremental, ~horas de engenharia/mês

Custo de fine-tuning GPT-4o-mini (OpenAI)

• Dataset: 500-5000 exemplos curados (a parte cara — pode levar semanas de trabalho humano)
• Treinamento: $25 a $300 dependendo do tamanho do dataset
• Hospedagem: gratuita na OpenAI, paga só pelo uso
• Por chamada: ~50% mais caro que o modelo base

Custo de fine-tuning Llama 3.3 70B com LoRA

• Dataset: idem ao caso anterior
• GPU para treino: 4-8 H100s por 6-24h, ~$200-1.500
• Engenharia: 1-3 semanas com pessoa que sabe (raríssimo no mercado BR)
• Serving: $0.50-2 por hora de GPU para produção (você precisa de uma rodando 24/7)
• Custo total mensal de serving: $400-1.500 fixos

Note: para a maioria das empresas brasileiras médias, o custo de serving próprio mata o caso de Llama fine-tuned. RAG sobre API hospedada ganha em custo total de propriedade.

O caminho errado mais comum

1. Empresa tem manual técnico de 500 páginas
2. Quer chatbot que responda sobre o manual
3. Alguém diz: "vamos fine-tunar GPT-4 no manual"
4. Gastam 3 meses preparando dataset (transformando texto em pares pergunta-resposta)
5. Fine-tunam, resultado é decepcionante
6. Manual atualiza, todo o investimento perde valor

O que deveria ter sido feito: 2 semanas montando RAG sobre o PDF, com bom chunking e reranking. Mesmo problema resolvido por 1/10 do custo, com atualização contínua de graça.

A árvore de decisão

1. O modelo está errando porque não sabe o conteúdo? → RAG.
2. Está errando o formato/estilo? → Tente prompt + few-shot primeiro. Se 20 exemplos não resolvem, fine-tuning.
3. Volume é gigante e o custo está dominando? → Considere fine-tunar um modelo menor para o caso de uso. Calcule ROI antes.
4. Tem requisito de soberania de dados? → Fine-tuning de modelo open-source pode ser obrigatório, não opcional.
5. Combinação: RAG + fine-tuning pode coexistir. Fine-tuning ajusta estilo, RAG fornece conhecimento. Vale o custo extra apenas se nenhuma das duas técnicas isoladas resolve.

Sinais de que você está prestes a tomar a decisão errada

• Alguém disse "fine-tuning" antes de testar RAG seriamente
• O dataset de fine-tuning ainda não existe e a empresa não tem ninguém pra construí-lo
• Os documentos atualizam mensalmente (fine-tuning vira retrabalho contínuo)
• Ninguém calculou o custo de serving se for modelo próprio
• "Vai economizar token" sem ter dimensionado o cenário

Conclusão prática

Em 2026, a decisão técnica certa para a esmagadora maioria de casos corporativos de IA é: comece com RAG sólido. Quando RAG bem feito não resolve, examine se o problema é conhecimento (refinar chunking, melhorar reranking, expandir base) ou comportamento. Só se for comportamento, e depois de esgotar prompt + few-shot, fine-tuning entra na conversa. Quando entra, faça o cálculo de custo total de propriedade — incluindo serving, manutenção e retreino. Muitas empresas que partiram pra fine-tuning sem essa conta voltaram pra RAG seis meses depois, com prejuízo. A escolha não é técnica apenas — é econômica. E na maioria das vezes, RAG ganha nos dois eixos.