Fine-tuning vs RAG: qual escolher para o seu caso de uso ?

#Por que essa pergunta se repete sem parar

Você instalou o Ollama, escolheu um modelo de 7B ou 14B e agora quer que ele “conheça” sua área: sua documentação interna, o vocabulário da área, suas decisões jurisprudenciais, seus tickets de suporte. Dois caminhos se abrem — fine-tuning ou RAG — e a comunidade costuma falar deles como se fossem alternativas intercambiáveis. Elas não são.

A armadilha: o fine-tuning tem uma aura de “IA de verdade”, e imaginamos um modelo que se torna especialista. O RAG parece uma solução improvisada, um “copiar e colar” automatizado. Na prática industrial, ocorre o contrário — o RAG se tornou o padrão para 80% dos casos de uso empresariais, e o fine-tuning fica reservado a problemas específicos em que oferece o que o RAG não consegue oferecer.

#As duas abordagens em 1 minuto

#RAG (Geração Aumentada por Recuperação)

O RAG indexa seus documentos (PDF, Markdown, banco de dados, código) em uma base vetorial (Chroma, Qdrant, Weaviate). Quando uma pergunta é feita, o sistema encontra os trechos relevantes por similaridade semântica, os inclui no prompt e o LLM gera sua resposta com base nesses trechos. O modelo permanece genérico; é o contexto que se torna especializado.

O que muda

O modelo pode citar seus dados, indicar as fontes de suas respostas e acessar conhecimentos que não possuía durante o treinamento.

O que não muda

Estilo da resposta, tom, capacidade de raciocinar em um formato específico, vocabulário técnico muito especializado.

Custo marginal de adicionar um documento

Alguns segundos: basta indexar o novo documento, só isso.

#Ajuste fino (LoRA / QLoRA / completo)

O fine-tuning treina novamente o modelo (ou uma parte de seus pesos, via LoRA) com um conjunto de dados de pares entrada/saída representativos do que você deseja que ele faça. O conhecimento e o comportamento são absorvidos nos pesos do modelo.

O que muda

O comportamento padrão: estilo, formato de saída, convenções, vocabulário especializado da área de atuação, raciocínio implícito.

O que isso não muda (bem)

Acesso a informações factuais atualizadas — um modelo ajustado por fine-tuning em março com base nos seus procedimentos não saberá nada sobre os procedimentos escritos em abril.

Custo marginal de adicionar um documento

Um novo treinamento completo a cada atualização significativa no dataset.

#Matriz de decisão

Em vez de um "depende", aqui estão os critérios que realmente definem a escolha, linha por linha.

Conhecimento factual que muda com frequência

RAG. O fine-tuning fica obsoleto assim que o conjunto de dados é atualizado. Documentação de produto, bases de tickets, FAQs e jurisprudência se enquadram nessa categoria.

Estilo, tom e formato de saída específico

Fine-tuning. Nenhuma quantidade de exemplos em um prompt substitui 500 pares de treinamento bem construídos para consolidar um formato JSON estrito, um tom corporativo ou uma estrutura de relatório.

Vocabulário profissional extremamente especializado

Fine-tuning, especialmente se o idioma for pouco contemplado no pré-treinamento (linguagem jurídica em francês, linguagem médica, dialetos). O RAG não basta se o modelo não entende os termos desde o início.

Rastreabilidade e citação de fontes

RAG. Você pode exibir "de acordo com o documento X, parágrafo Y". Com um modelo fine-tuned, impossível comprovar de onde vem uma afirmação.

Dados ultraconfidenciais, nunca em RAM compartilhada

Fine-tuning com pesos armazenados localmente. O RAG implica injetar os trechos no contexto em cada requisição — em infraestrutura compartilhada, isso pode causar problemas.

Resposta rápida em menos de 200ms (chatbot, agente inline)

Fine-tuning. O RAG adiciona de 100 a 500 ms para a recuperação, além de um contexto mais longo a processar. Quando o tempo real é crítico, isso pesa.

Volume de conhecimento enorme (> 100k páginas)

RAG. Não é viável fazer o ajuste fino com 100 mil documentos — e, mesmo que você fizesse isso, o modelo alucinaria nos detalhes.

Dataset de treinamento de qualidade disponível

Se você não tiver pelo menos 500 a 1000 pares de entrada/saída limpos, o fine-tuning vai mais prejudicar o modelo do que ajudar. Comece com RAG.

#5 casos de uso típicos

#1. Chatbot de suporte baseado na documentação do produto

Veredito

RAG, sem hesitar.

Por quê

A documentação muda constantemente (novas funcionalidades, correções, recursos marcados como obsoletos). Um fine-tune ficaria obsoleto em 3 semanas, e o cliente quer uma resposta com fonte ("ver a seção X do manual"), não uma afirmação sem transparência sobre sua origem.

Stack típico

Ollama (Qwen 3.5 9B para caber em 8 GB, ou Mistral Small 24B em 16 GB para um francês mais refinado) + Qdrant/Chroma + nomic-embed-text + Open WebUI ou AnythingLLM.

#2. Extrator de informações estruturadas (faturas, currículos, contratos)

Veredito

Fine-tuning, ou prompting avançado com modo JSON.

Por quê

O formato de saída deve ser rigorosamente o mesmo a cada vez (mesmos campos, mesma tipagem, mesmos valores padrão). Mesmo um prompt bem escrito diverge em 5% dos casos, o que quebra um pipeline. Um LoRA com 800 exemplos anotados resolve isso definitivamente.

Stack típico

Unsloth ou Axolotl para treinar, exportação em GGUF, implantação no Ollama. Se a base de "conhecimento" sobre os tipos de documentos evoluir, é possível combinar com um RAG leve.

#3. Assistente jurídico sobre jurisprudência francesa

Veredito

Híbrido — RAG primeiro, fine-tune depois se o vocabulário permanecer fraco.

Por quê

O corpus de jurisprudência é gigantesco e muda todos os meses (o RAG é obrigatório para manter as decisões atualizadas). Mas o vocabulário jurídico francês é pouco contemplado pela maioria dos modelos de pesos abertos, e um fine-tuning leve (LoRA com 2.000 a 3.000 exemplos de perguntas e respostas jurídicas) melhora significativamente a compreensão dos termos antes que o RAG entre em ação.

Stack típico

Légifrance/Doctrine como fonte → Qdrant + reranker BGE → LLM 14B ajustado com LoRA para o jargão jurídico francês.

#4. Gerador de código adaptado a uma base de código interna

Veredito

RAG (leitura de arquivos do repositório), sem fine-tuning a não ser em casos muito particulares.

Por quê

Uma base de código evolui todos os dias. Um fine-tune ficaria obsoleto a cada sprint. Os melhores assistentes de código (Continue.dev, Aider) leem dinamicamente os arquivos envolvidos por meio de RAG com AST ou embeddings de código.

Stack típico

Continue.dev + Qwen3-Coder 30B-A3B (qwen3-coder:30b, MoE 256k ctx, 3B ativos, portanto rápido) ou Devstral 24B via Ollama, recuperação integrada ao plugin.

#5. Estilo editorial interno (newsletter, relatórios, fichas de produto)

Veredito

Fine-tuning puro.

Por quê

O conteúdo é novo a cada vez (não há nada para 'recuperar'), mas o tom, a estrutura, o ritmo das frases, o uso de 'você' e dos subtítulos devem ser absolutamente coerentes. É exatamente isso que o fine-tuning codifica bem.

Stack típico

200-500 artigos bem redigidos → formato Alpaca ou ChatML → QLoRA em Qwen 3.5 9B com Unsloth → exportação para GGUF, modelfile Ollama com prompt de sistema complementar.

#Os custos ocultos das duas abordagens

Comparativos públicos limitam-se muitas vezes a "preço de uma GPU para 4h de treinamento". A realidade operacional é mais difícil de ambos os lados.

#Custos ocultos do RAG

Qualidade do chunking

A divisão dos documentos em trechos determina tudo. Quando é mal feita, a recuperação traz trechos fora de contexto, o LLM alucina e ninguém entende por quê. Raramente basta "colocar os PDFs no Chroma": muitas vezes é necessário dividir o conteúdo por seção e, às vezes, fazer um pré-processamento com OCR nos documentos digitalizados.

Latência acumulada

Embedding da consulta + busca vetorial + (opcional) reranker + contexto ampliado para o LLM. Em uma configuração mal otimizada, a latência pode passar de 400 ms (apenas o LLM) para 2–3 s (RAG completo). Prever esse tempo no orçamento de latência desde a concepção.

Manutenção da base

Quando um documento é excluído ou atualizado, é preciso removê-lo ou reindexá-lo. Para fontes externas (web, API), prever uma tarefa de atualização periódica. Quanto mais a stack muda, mais trabalho isso gera.

Qualidade do modelo de embeddings

Para o francês, os embeddings padrão (como text-embedding-ada) são fracos. nomic-embed-text, BGE-M3 ou Solon fazem a diferença — mas isso significa conhecer as opções.

#Custos ocultos do fine-tuning

Preparação do conjunto de dados

É 80% do trabalho. Coletar, limpar, formatar em pares instrução/resposta, remover duplicatas, equilibrar as classes. Em 4 semanas de projeto de fine-tuning, considere 3 semanas de preparação de dados e 1 semana de treinamento.

Risco de regressão

Um fine-tune mal calibrado degrada o modelo em suas capacidades gerais (o "esquecimento catastrófico"). O modelo se torna bom na sua tarefa e ruim no resto. É necessário testar em um benchmark genérico antes e depois.

Retreinamento a cada atualização

O dataset se enriquece ao longo do tempo. Cada nova versão exige executar novamente de 2 a 12 horas de processamento na GPU, revalidar e implantar novamente. Versionar os datasets e os checkpoints se torna obrigatório.

Hardware de treinamento

Executar a inferência de um 7B Q4 exige 5 GB de VRAM, mas treiná-lo (mesmo com QLoRA) exige pelo menos 12-16 GB. O fine-tuning tem requisitos mínimos de hardware mais altos que a inferência.

#Abordagem híbrida: RAG + fine-tuning

As arquiteturas mais eficientes não escolhem — elas combinam. O fine-tuning define como o modelo fala sobre seu domínio, o RAG dá acesso ao que ele precisa saber no momento T.

Fine-tuning voltado ao estilo e ao formato

200 a 1000 exemplos que fixam o tom (corporativo, técnico, jurídico), o formato da resposta (JSON, Markdown estruturado) e a postura (sempre citar a fonte, nunca inventar).

RAG sobre conhecimento factual

Documentação, base de tickets, jurisprudência, base de código — tudo o que muda e precisa ser localizável e citável.

Salvaguardas no prompt de sistema

O prompt de sistema lembra ao modelo que deve se recusar a responder se o contexto RAG estiver vazio ou contraditório. Essencial para limitar as alucinações.

#Decisão rápida em 3 perguntas

1. 01
   Pergunta 1 — Seus dados mudam mais de uma vez por mês?

   Se sim: RAG obrigatório. O fine-tune não consegue acompanhar o ritmo sem se tornar um caos operacional.
2. 02
   Pergunta 2 — Você tem pelo menos 500 pares entrada/saída de qualidade, verificados manualmente?

   Se não: comece com RAG. O fine-tuning com 100 exemplos improvisados degrada o modelo. Se você pretende acumular exemplos, implemente o RAG primeiro e aproveite seus logs para construir o dataset.
3. 03
   Pergunta 3 — O problema é "saber algo" ou "responder de uma certa forma"?

   Saber → RAG. Responder de uma forma específica → fine-tuning. Os dois → híbrido. É o critério de decisão mais simples e funciona em 9 de cada 10 casos.

#Erros comuns para evitar

"Fazer fine-tuning para aprender fatos"

Erro mais comum. Um fine-tune não é uma base de conhecimento — ele interpola com base nos exemplos vistos, mas alucina sobre detalhes precisos (números, datas, referências) muito mais do que um RAG.

“RAG sem reranker” em corpora com > 10k chunks

A busca vetorial, sozinha, recupera muitos resultados, mas nem sempre os mais relevantes. Um reranker baseado em cross-encoder (BGE, mxbai), aplicado aos 20 primeiros resultados, transforma a qualidade, com um custo adicional de 50–100 ms.

Confundir RAG com contexto longo

"Vou só colocar o documento inteiro no prompt". Acima de 8k tokens úteis, a qualidade cai drasticamente (perda no meio, "lost in the middle"). Um RAG com boa divisão em blocos supera o uso ingênuo de um contexto longo a partir de certo volume.

Fazer fine-tuning de um modelo já alinhado com um conjunto de dados não alinhado

Se você fizer fine-tuning de um modelo "instruct" com exemplos que não têm a mesma estrutura de prompt, você quebra o alinhamento e o modelo fica estranho. Sempre respeitar o template do modelo (ChatML, Alpaca, Mistral, Llama-3 chat).

Querer um benchmark público para decidir

Nenhum benchmark genérico dirá se RAG ou fine-tune funciona melhor para O SEU caso. Prepare uma avaliação interna com 30 a 50 perguntas representativas e faça medições antes de colocar em produção em escala.

#Para se aprofundar

Uma vez tomada a decisão, os guias correspondentes abordam a implementação prática, com as armadilhas e as otimizações.

Implementação do RAG sem codificar

Open WebUI ou AnythingLLM permitem montar um RAG documental em algumas horas, sem escrever Python — útil para validar a abordagem antes de industrializar.

Ajuste fino local com LoRA / QLoRA

O guia dedicado aborda o Unsloth, o formato do conjunto de dados, a escolha entre LoRA e QLoRA e a exportação em GGUF para o Ollama. Uma RTX 3090 é suficiente para um modelo de 7B.

Otimizar um RAG existente

Reranker, pesquisa híbrida BM25 + vetorial, estratégias de chunking — três eixos que transformam um RAG "que funciona" em um RAG de produção.