RAG vs. Fine-Tuning: quando usar cada um e quando usar os dois

O falso dilema

RAG versus fine-tuning é uma das decisões mais pesquisadas e debatidas no uso aplicado de LLMs — e a maior parte do debate acontece no nível errado. Ela costuma ser tratada como uma escolha “ou um ou outro”, quando o quadro honesto em 2026 é que cerca de 60% dos sistemas de produção usam os dois juntos. Não porque as equipes não souberam decidir, mas porque cada técnica resolve um problema genuinamente diferente — e a maioria dos projetos reais de adaptação de domínio tem os dois problemas ao mesmo tempo.

O que RAG é (e não é)

RAG não toca no modelo. Os pesos nunca mudam; o que muda é o que o modelo vê na janela de contexto no instante da pergunta. Uma etapa de busca pesquisa uma base de conhecimento, recupera os documentos mais relevantes e os entrega junto da consulta — o modelo responde com um “briefing” na frente dele, não de memória.

Esse mecanismo torna o RAG bom em exatamente uma categoria de problema: informação grande, que muda, ou ambas. O que o RAG não conserta é o comportamento do modelo. Se o tom é inconsistente, se ele não segue um formato de saída rígido ou usa o vocabulário da sua indústria de forma errada, jogar mais documentos nele na hora da inferência não resolve nada — porque o problema nunca foi falta de informação.

O que fine-tuning é (e não é)

Fine-tuning faz o oposto: muda o modelo, treinando os pesos com exemplos reais do comportamento de entrada/saída desejado até que ele vire o padrão. Com LoRA e QLoRA, treina-se um adaptador pequeno — muitas vezes menos de 1% dos parâmetros do modelo base — em vez do modelo inteiro, reduzindo o custo para algumas centenas de dólares e algumas horas.

O ponto que vale cravar, porque é o mal-entendido mais comum de todo esse debate: fine-tuning não adiciona conhecimento factual de forma confiável. Um modelo ajustado com uma pilha de literatura médica não “sabe” os fatos dessa literatura como um sistema de busca realmente sabe — ele ajusta estilo, estrutura e reconhecimento de padrões. A recordação factual de dados de treino é pouco confiável, especialmente para fatos granulares. Em resumo: fine-tuning é uma ferramenta de comportamento, não de conhecimento.

O framework de decisão

Exemplo prático de RAG

O cenário clássico: uma equipe interna quer fazer perguntas em linguagem natural sobre runbooks de incidentes e postmortems — documentos que mudam toda semana. Isso é um problema de RAG de manual: o conhecimento muda constantemente e cada resposta precisa ser rastreável.

Um pipeline mínimo em três partes: os documentos, o índice de recuperação e a geração. Para a recuperação, dá para usar TF-IDF com similaridade de cosseno — um método totalmente local, sem download de modelo ou chamada de API:

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

class RetrievalIndex:
    def __init__(self, chunks):
        self.chunks = chunks
        self.vectorizer = TfidfVectorizer()
        self.vectors = self.vectorizer.fit_transform([c.text for c in chunks])

    def search(self, query, top_k=3):
        qv = self.vectorizer.transform([query])
        scores = cosine_similarity(qv, self.vectors)[0]
        ranked = sorted(zip(self.chunks, scores), key=lambda p: p[1], reverse=True)
        return ranked[:top_k]

Na etapa de geração, o prompt de sistema proíbe responder fora das fontes e exige citação de cada afirmação — é isso que torna a resposta de RAG auditável: dá para rastrear cada afirmação até o documento original.

Exemplo prático de fine-tuning

O cenário oposto: uma financeira precisa classificar reclamações em uma taxonomia interna rígida (BILLING_DISPUTE, UNAUTHORIZED_TRANSACTION, ACCOUNT_ACCESS…) com saída estruturada idêntica em toda chamada. O modelo não precisa de fatos novos — precisa aprender o vocabulário da empresa e um contrato de saída do qual o sistema depende.

from transformers import AutoModelForCausalLM
from peft import LoraConfig, get_peft_model, TaskType

model = AutoModelForCausalLM.from_pretrained(
    "seu-modelo-base", load_in_4bit=True, device_map="auto"
)

lora = LoraConfig(
    r=8, lora_alpha=16, lora_dropout=0.1,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    task_type=TaskType.CAUSAL_LM,
)
peft_model = get_peft_model(model, lora)

O load_in_4bit=True exige GPU real. O mecanismo por trás do custo baixo é justamente este: treina-se um adaptador pequeno e focado sobre um modelo base congelado — não o modelo inteiro.

Custo comparativo

Troubleshooting

• ❌ Respostas de RAG alucinando fora das fontes → o prompt de sistema está permitindo responder sem citação; reforce a regra de “responda apenas com as fontes” e exija ID de fonte por afirmação.
• ❌ RAG retornando trechos irrelevantes → chunking ruim (corte no meio de uma frase). Divida por fronteiras de sentença, não por contagem fixa de caracteres.
• ❌ Fine-tuning não melhorou o formato de saída → poucos exemplos por categoria; um rótulo errado num conjunto pequeno é uma fração significativa do sinal de treino daquela classe.
• ❌ Modelo “esqueceu” fatos após fine-tuning → esperado; fine-tuning não é ferramenta de conhecimento. Reintroduza fatos via RAG.
• ❌ Latência alta com RAG em produção → a etapa de busca virou gargalo; considere fine-tuning para casos de formato fixo ou cache de consultas frequentes.

Perguntas frequentes

Preciso escolher um só? Não. A regra prática é começar com RAG — quase sempre é o caminho mais rápido para algo funcionando — e adicionar fine-tuning apenas onde houver um problema específico e persistente de comportamento que prompt e busca melhores não resolveram.

Fine-tuning adiciona conhecimento? Não de forma confiável. Ele ajusta comportamento (tom, formato, vocabulário), não fatos. Conhecimento granular deve vir de recuperação.

Quanto custa um fine-tuning? Com LoRA/QLoRA, na casa de centenas de dólares e algumas horas, em vez de um retreinamento completo.

Posso usar RAG sem modelo de embeddings pago? Sim. TF-IDF com similaridade de cosseno é um método legítimo e totalmente local para bases menores.

O que é mais barato por consulta em alto volume? Um modelo aberto menor e fine-tuned tende a sair bem mais barato por consulta que uma API de fronteira.

A regra final

Despojando o jargão: RAG cuida do que o modelo precisa saber; fine-tuning cuida de como o modelo precisa se comportar. Tratar isso como escolha única é a forma mais confiável de gastar meses construindo a coisa errada primeiro.