RAG ou Fine-tuning: como escolher a abordagem certa

Quem já entende o que é [RAG](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona) e o que é [fine-tuning](/artigo/fine-tuning-llms-o-que-e-como-funciona-quando-usar) esbarra na pergunta seguinte: qual das duas técnicas usar no projeto? A resposta curta é que elas resolvem problemas diferentes, e a resposta prática depende de três perguntas: seus dados mudam com que frequência, o que precisa mudar é o conhecimento do modelo ou o comportamento dele, e quanto você pode gastar em infraestrutura de treinamento.

A diferença que decide tudo

RAG não altera uma única camada do modelo. Ele busca documentos relevantes em uma base externa (normalmente um [banco de dados vetorial](/artigo/banco-de-dados-vetorial-o-que-e-como-funciona) sobre [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia)) e injeta esse conteúdo no prompt antes de gerar a resposta. O modelo continua o mesmo; muda apenas o que ele enxerga em tempo de inferência.

Fine-tuning faz o oposto: ajusta os pesos do modelo a partir de exemplos rotulados, mudando como ele responde, não o que ele sabe sobre um fato específico do seu negócio. Na literatura técnica essa distinção aparece como conhecimento paramétrico (o que está guardado nos pesos) versus conhecimento não paramétrico (o que é buscado fora do modelo a cada chamada) — é essa diferença, mais do que qualquer benchmark, que deveria orientar a escolha.

Quando faz sentido usar RAG

• Os dados mudam com frequência — catálogo de produtos, manuais internos, base de tickets, regulamentação. Atualizar o índice é reindexar documentos; não exige retreinar nada.
• Você precisa de rastreabilidade: como o RAG recupera documentos reais, dá para mostrar a fonte junto da resposta — algo que o fine-tuning não oferece, porque a informação fica diluída nos pesos.
• O orçamento é limitado: não há custo de treinamento nem necessidade de GPU dedicada para ajustar o modelo.
• O risco de informação desatualizada é alto e inaceitável para o caso de uso (ex.: suporte técnico, jurídico, compliance).

Quando faz sentido usar fine-tuning

• O que precisa mudar é comportamento, tom ou formato — respostas mais curtas, um estilo de marca, uma estrutura de saída específica (JSON, um determinado padrão de laudo, etc.).
• O domínio usa terminologia muito específica (jurídico, médico, técnico de nicho) e o modelo precisa reconhecer e produzir esses termos de forma consistente, não apenas recuperá-los de um documento.
• O conhecimento a incorporar é estável — não muda toda semana — porque cada atualização relevante implica um novo ciclo de treinamento.
• Você já tentou prompt engineering e RAG e o modelo ainda erra de forma sistemática no comportamento esperado, não apenas no conteúdo.

Sobre volume de dados: a documentação da OpenAI para fine-tuning via API descreve um mínimo técnico de poucas dezenas de exemplos, mas recomenda a casa das centenas para resultados consistentes — quantidade menor tende a funcionar apenas em tarefas muito restritas. Fornecedores diferentes usam parâmetros próprios, então trate isso como ordem de grandeza, não como número fixo para qualquer plataforma.

Onde cada abordagem falha

RAG só é tão bom quanto a recuperação. Indexação ruim, chunking mal feito ou uma base de conhecimento desatualizada produzem [alucinação](/artigo/alucinacao-em-ia-por-que-modelos-erram-como-reduzir) mesmo com um modelo excelente — o problema não é o modelo, é o que ele recebeu como contexto. É por isso que [segurança e qualidade do pipeline de RAG](/artigo/seguranca-em-rag-riscos-como-proteger) importam tanto quanto a escolha do modelo.

Fine-tuning carrega um risco menos intuitivo: o esquecimento catastrófico (catastrophic forgetting). Ao especializar o modelo em um domínio, pesos que sustentavam capacidades gerais podem se deteriorar, e o modelo fica pior em tarefas fora do escopo do treinamento. Há também o risco de memorização forçada — quando o modelo é treinado para repetir fatos específicos, ele pode confabular detalhes parecidos quando não tem certeza, um tipo de alucinação induzida pelo próprio ajuste fino. Nenhuma das duas falhas se resolve com mais poder computacional; exigem dataset mais limpo e avaliação contínua.

A abordagem híbrida: fine-tuning para formato, RAG para conhecimento

Pesquisa da UC Berkeley (o estudo RAFT — Retrieval-Augmented Fine-Tuning) e relatos de times de engenharia convergem num padrão prático: usar fine-tuning para fixar o comportamento — formato de resposta, tom, raciocínio dentro do domínio — e deixar o RAG responsável por trazer o conhecimento que muda com o tempo. Nos benchmarks avaliados por essa linha de pesquisa, sistemas híbridos superam RAG puro e fine-tuning puro isoladamente. A prática mais citada por equipes que adotam essa combinação é resumida como "fine-tune para formato, RAG para conhecimento".

Checklist rápido de decisão

• Meus dados mudam toda semana? → RAG.
• Preciso citar a fonte da resposta? → RAG.
• O problema é tom, formato ou estilo, não fato? → fine-tuning.
• O domínio tem jargão muito específico que o modelo precisa produzir, não só reconhecer? → fine-tuning.
• Já tentei prompt engineering e RAG e o comportamento ainda está errado? → considere fine-tuning.
• Preciso das duas coisas ao mesmo tempo — comportamento consistente e conhecimento atualizado? → arquitetura híbrida.

Nenhuma das duas técnicas substitui a outra por completo, e a escolha errada custa caro nos dois sentidos: um RAG mal indexado gera respostas incorretas com aparência de fonte confiável, e um fine-tuning fora de hora custa tempo de treinamento para resolver um problema que uma boa recuperação de contexto já resolveria de graça.