RAG vs Fine-Tuning: Quando Usar Cada Um (Com Números Reais)

RAG vs Fine-Tuning: Quando Usar Cada Um (Com Números Reais)

A maioria dos conselhos sobre rag vs fine tuning ignora o único experimento que mediu os dois na mesma tarefa. Balaguer et al., no arXiv:2401.08406 (citado 162 vezes), passaram um conjunto de QA agrícola pelos dois: o fine-tuning comprou mais de 6 pontos de precisão, e o RAG empilhou outros 5 por cima disso. A Tabela 18 deles coloca o GPT-4 em 75% puro, 81% com fine-tuning, 86% com fine-tuning e recuperação. Então por que ainda dizemos à maioria das equipes para começar com RAG? Porque frescor, citações e a matemática de custo abaixo decidem mais projetos do que uma diferença de 1 ponto de precisão.

Principais Conclusões

• O RAG é o padrão quando o conhecimento muda com frequência ou as respostas precisam citar fontes; o fine-tuning vence em formato consistente e latência.
• Os custos do fine-tuning chegam de imediato (treinamento); os custos do RAG chegam por consulta (embeddings mais tokens de entrada extras).
• Evidência publicada na mesma tarefa: o fine-tuning somou 6 pontos de precisão, o RAG mais 5 por cima, e o híbrido superou os dois isolados.
• Rode as cinco verificações (frescor dos dados, exemplos rotulados, latência, citações, habilidade da equipe) antes de escrever qualquer código de treinamento.

Quando Você Deve Usar RAG vs Fine-Tuning? (Veredito Rápido)

Escolha RAG se o seu conhecimento muda com frequência ou se as suas respostas precisam carregar citações. Escolha fine-tuning se você precisa de formato de saída consistente e baixa latência, e tem exemplos rotulados às centenas. Use os dois quando um deployment amadurece. O RAG edita o contexto que o modelo lê; o fine-tuning edita o próprio modelo. A maioria das equipes precisa do primeiro, não do segundo.

Uma linha para guardar: o RAG muda o que o modelo lê; o fine-tuning muda o que o modelo é. Escolha com base naquele que a sua tarefa realmente precisa.

O glossário de RAG da NVIDIA define o lado da recuperação de forma limpa se você quer a versão didática. Mas definições não escolhem a sua arquitetura. A evidência escolhe, então comece por aí.

O Que a Evidência Mostra? Uma Tarefa, Ambas as Abordagens, Medidas

A única comparação medida na mesma tarefa que aparece no top cinco do Google para esta consulta é Balaguer et al. 2024, um estudo da Microsoft Research citado 162 vezes. A equipe passou uma tarefa de QA agrícola por um pipeline RAG, um modelo com fine-tuning e um híbrido dos dois, depois pediu ao GPT-4 para pontuar as respostas. No setup deles, o fine-tuning sozinho superou o RAG sozinho por pouco, e empilhar os dois venceu qualquer um dos dois por uma margem maior.

O estudo de caso agrícola (arXiv:2401.08406)

O estudo, submetido em janeiro de 2024 por Angels Balaguer e 15 coautores, pergunta o que é preciso para dar a agricultores insights específicos da localização. O pipeline deles extrai informação de PDFs, gera pares de pergunta-resposta a partir deles e avalia o Llama2-13B, o GPT-3.5 e o GPT-4 com e sem recuperação.

Balaguer et al. relatam um aumento de precisão de mais de 6 pontos percentuais com o fine-tuning, cumulativo com o RAG, que somou outros 5 pontos por cima. O pipeline híbrido superou qualquer abordagem isolada. A Tabela 18 deles mostra a ordem para o GPT-4: 75% sem ajuda, 80% com RAG, 81% com fine-tuning, 86% com fine-tuning mais RAG. Note como 80% e 81% estão próximos; a diferença entre o RAG sozinho e o fine-tuning sozinho é de um ponto, enquanto o híbrido está cinco pontos à frente de ambos. Em um experimento, o modelo com fine-tuning recorreu a conhecimento de outras geografias para responder perguntas específicas de uma região, elevando a similaridade das respostas de 47% para 72%.

A evidência econômica

O estudo publicado da Snorkel AI (novembro de 2022) cobre o lado do custo. Em um benchmark de classificação jurídica de 100 classes (LEDGAR, 80.000 cláusulas contratuais), um modelo RoBERTa com fine-tuning igualou um GPT-3 com fine-tuning sendo 1.400× menor, usando menos de 1% dos rótulos ground-truth e rodando a 0,1% do custo de inferência em produção do modelo GPT-3 com fine-tuning, cerca de um milésimo. Construção total: US$ 1.915 com rotulagem programática contra US$ 7.418 para anotação manual mais fine-tuning do GPT-3. Uma ressalva: isso é classificação, não QA generativo, então trate as proporções como indicativas.

Nossa leitura

Nossa interpretação: o setup deles é o caso mais favorável que o fine-tuning já enfrenta, e ainda assim só venceu por um ponto. Balaguer et al. treinaram em um corpus de PDF fixo e avaliaram contra esse mesmo corpus congelado, então nada do que os pesos aprenderam teve chance de ficar obsoleto no meio do experimento. A maioria das bases de conhecimento em produção não fica parada assim. Um bot de suporte respondendo perguntas sobre o release da semana passada reconquista os 6 pontos a cada ciclo de retreino, enquanto o índice que alimenta o RAG se atualiza na mesma tarde. É por isso que lemos uma vantagem de 1 ponto de precisão como o insumo mais fraco desta decisão, e o frescor como o mais forte. Onde a evidência não se generaliza: o resultado da Snorkel é um benchmark de classificação, e nenhum dos dois estudos testa controle de tom ou formato, que continua sendo o caso mais forte do fine-tuning.

O fine-tuning é a resposta certa com menos frequência do que as equipes pensam; a maioria dos projetos que diz "fine-tune" na verdade quer dizer "recuperar".

Como o RAG Funciona, e Quando Ele Vence?

O RAG (geração aumentada por recuperação) responde a partir de documentos que você controla, em vez do que quer que o modelo tenha memorizado durante o treinamento. Proposto pela primeira vez por Lewis et al. em 2020, tornou-se o padrão para trabalho com conhecimento porque o conhecimento vive fora do modelo: atualize o índice, e toda resposta muda amanhã sem retreino.

O pipeline tem quatro passos:

1. Ingestão. Faça o parse dos seus documentos (PDFs, wikis, tickets) em um corpus.
2. Chunk e embed. Divida em chunks de algumas centenas de tokens e converta cada um em um vetor com um modelo de embedding.
3. Recupere. No momento da consulta, encontre os top-K chunks mais similares, mais correspondências de palavra-chave para strings exatas como SKUs e códigos de erro.
4. Aumente e gere. Coloque esses chunks no prompt e deixe o LLM responder com as fontes anexadas.

O RAG vence em três eixos: frescor (reindexar em vez de retreinar), citações (toda resposta aponta para o chunk de onde veio) e controle de dados (dados de clientes nunca entram em um treino). Se você quer o passo a passo completo de construção, veja como construir uma aplicação RAG passo a passo.

Um aviso sobre qualidade de recuperação: o pipeline é tão bom quanto a sua combinação de embedding e recuperação. O Contextual Retrieval da Anthropic mediu uma taxa de falha de recuperação top-20 de 5,7% em setups simples, caindo para 2,9% com embeddings contextuais mais BM25, e para 1,9% quando um reranker foi adicionado. Se consultas de correspondência exata continuam falhando, a busca híbrida (BM25 vs vetor) é a solução.

Quando o Fine-Tuning Vence? (E O Que É PEFT?)

O fine-tuning vence quando o problema é como o modelo responde, não o que ele sabe: formato de saída consistente, tom de marca ou um orçamento de latência rígido sem ida e volta de recuperação. Ele também é a alavanca para a economia de modelos pequenos. O resultado da Snorkel de qualidade-GPT-3-a-0,1%-do-custo acima só existe porque alguém fez fine-tuning de um modelo pequeno em vez de servir um grande.

Fine-tuning completo vs PEFT (LoRA / QLoRA)

O fine-tuning completo atualiza todos os pesos do modelo. É caro, lento e raro fora de grandes laboratórios. Quase todo mundo entrega PEFT (fine-tuning eficiente em parâmetros). O LoRA (Hu et al. 2021) congela os pesos base e treina um pequeno adaptador de baixo posto, tipicamente 0,1-1% da contagem de parâmetros. O QLoRA adiciona quantização de 4 bits por cima, então um modelo de 13B cabe em uma GPU de consumo. Um termo relacionado que vale conhecer: pré-treinamento contínuo, em que um modelo continua o pré-treinamento em um corpus bruto de domínio (não supervisionado) antes do fine-tuning supervisionado em exemplos rotulados.

Uma configuração mínima de LoRA, segundo os docs de PEFT da Hugging Face:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Para preparação de dataset, contagem de épocas e avaliação, veja nosso guia de fine-tuning passo a passo.

Os riscos são reais: overfitting em datasets pequenos (algumas centenas de exemplos podem memorizar em vez de aprender), obsolescência (os pesos congelam o seu conhecimento no corte do treinamento) e sem atribuição de fonte (um modelo com fine-tuning não consegue mostrar os recibos). Se qualquer um desses três é um impeditivo, você acabou de se convencer a voltar para o RAG.

RAG vs Fine-Tuning vs Engenharia de Prompt: Onde os Outros Se Encaixam?

Os três são uma escada, não rivais. A engenharia de prompt muda as instruções, o RAG muda o contexto que o modelo lê e o fine-tuning muda os pesos. O próprio guia de fine-tuning da OpenAI coloca o fine-tuning por último no ciclo: evals primeiro, prompts em segundo, treinamento só quando o prompt deixa de ser suficiente. Duas opções mais novas completam o kit.

Uma confusão que vale nomear: servidores MCP e frameworks de agentes são orquestração, não customização. Eles decidem quais ferramentas e fontes o modelo alcança; eles não mudam como o modelo responde. Você pode rodar um pipeline RAG dentro de um agente e fazer fine-tuning do modelo por baixo dele, e muitos sistemas em produção fazem os dois. As guerras de autocomplete ("vs mcp", "vs agents") são erros de categoria.

O RAG É Mais Barato Que o Fine-Tuning? O Modelo de Custo Real

Resposta curta: em volumes de consulta realistas, sim. A conta do fine-tuning chega de imediato (dados rotulados mais treinamento), enquanto a conta do RAG chega por consulta (embeddings mais tokens de entrada extras). Os docs de fine-tuning da OpenAI cobram o treinamento por token, mas as taxas de token são troco perto do custo humano dos exemplos rotulados. Aqui está a matemática sobre preços públicos de tabela.

A pergunta do break-even: quantas consultas até o imposto cumulativo por consulta do RAG igualar o investimento em fine-tuning?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

A 50.000 consultas por mês, isso é mais de dez anos. Para a maioria dos produtos, o investimento em fine-tuning nunca se paga só com a economia de tokens; você faz fine-tuning para formato e latência, não para vencer o RAG no custo. A matemática vira acima de milhões de consultas por mês ou com contextos recuperados muito grandes. E note a assimetria: a conta do fine-tuning renova toda vez que a deriva de dados força um retreino, enquanto o RAG escala linearmente com o volume vezes o tamanho do chunk. Se o gasto por consulta é a preocupação real, comece por reduzir custos de LLM por consulta; se você for seguir o caminho do treinamento, compare as ferramentas de fine-tuning antes de assinar o cheque.

Uma nota de frescor: em julho de 2026, os docs de fine-tuning da OpenAI afirmam que a plataforma hospedada está sendo descontinuada para novos usuários, com os usuários existentes mantendo acesso ao treinamento pelos próximos meses. É mais uma razão para as equipes penderem para PEFT em modelos abertos ou RAG simples.

5 Verificações Antes de Escolher

Rode estas cinco verificações de sim-ou-não antes de escrever qualquer código de treinamento; o padrão de respostas aponta para RAG, fine-tuning ou híbrido com mais confiança do que qualquer benchmark. Responda com honestidade, depois conte.

1. O conhecimento muda mais rápido do que você consegue retreinar? Sim → RAG. Um retreino por atualização de documento não é um plano de operações.
2. Você tem algumas centenas de exemplos rotulados? Não → RAG ou engenharia de prompt. Fine-tuning em 40 exemplos memoriza; não aprende.
3. Existe um orçamento de latência rígido? Apertado → pende para fine-tuning. Pular a ida e volta de recuperação economiza 50-200ms.
4. As respostas precisam carregar citações ou uma trilha de auditoria? Sim → RAG. Modelos com fine-tuning não conseguem apontar para o chunk de origem.
5. A equipe tem habilidade de ML mais orçamento de GPU ou API para treinamento? Não → RAG. Um índice que você pode reconstruir vence pesos que você não consegue retreinar.

Maioria sim em 1, 4, 5 → RAG. Maioria sim em 2 e 3 com um domínio estável → fine-tuning. Respostas divididas, ou um produto maduro com tráfego real → híbrido (próxima seção). O objetivo do checklist é decidir por evidência, não pela técnica que está em alta no seu feed este mês.

Dá Para Usar RAG e Fine-Tuning Juntos?

Sim, e para deployments maduros o padrão híbrido é a norma, não a exceção. Faça fine-tuning para fluência de domínio e formato de saída (o como), recupere para fatos no momento da inferência (o quê). Balaguer et al. relatam exatamente isso na tarefa agrícola deles: o pipeline híbrido superou qualquer abordagem isolada, com o ganho de 5 pontos do RAG empilhando sobre os 6 do fine-tuning.

O caminho de maturidade que recomendamos: comece com engenharia de prompt, adicione RAG no momento em que as respostas precisarem de dados privados ou novos, e adicione fine-tuning só quando inconsistências de formato ou latência começarem a doer em produção. Pule direto para o fine-tuning e você paga o imposto de treinamento antes de saber se a recuperação já resolveu o problema.

O padrão híbrido não é um meio-termo; para deployments maduros ele é o padrão, fine-tuning para formato, recuperação para fatos.

Como Você Avalia o Seu Vencedor?

Escolha o vencedor do jeito que você escolheria um banco de dados: meça na sua carga de trabalho, não na intuição. A receita cabe em um parágrafo e cobre os quatro números que realmente decidem.

• Conjunto de perguntas reservado. 100-300 perguntas reais de usuários. Não sintéticas, nunca nada visto durante o treinamento ou indexação.
• Fidelidade e correção da resposta. A fidelidade pergunta se a resposta está fundamentada no contexto recuperado; a correção da resposta pergunta se ela está realmente certa. A dupla, popularizada pelo RAGAS, pega tanto alucinação quanto falhas de recuperação.
• Latência no p95, não a média. A recuperação adiciona uma ida e volta; meça a cauda.
• Custo por 1.000 consultas, tokens mais infra, medido em vez de estimado.
• Rode de novo na deriva. Novos documentos, novo snapshot de modelo, novo trimestre: rode o conjunto de novo.

O detalhamento completo das métricas, incluindo ferramentas, está no nosso guia de avaliação de LLM.

Sobre o Autor

Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a stack de ferramentas de LLM que a equipe da Techsy realmente usa em produção. Conecte-se no LinkedIn.

Perguntas Frequentes

Dá para usar RAG e fine-tuning juntos?

Sim. Faça fine-tuning para formato de saída e fluência de domínio, e mantenha a recuperação para fatos no momento da inferência. Balaguer et al. mediram esse híbrido em uma tarefa de QA agrícola e descobriram que ele superou qualquer abordagem isolada, com os ganhos de precisão se somando. A maioria dos sistemas maduros em produção acaba aqui: pesos para o como, recuperação para o quê.

Quando não usar fine-tuning?

Pule o fine-tuning quando o seu conhecimento muda mais rápido do que você consegue retreinar, quando você tem menos de algumas centenas de exemplos rotulados, quando as respostas precisam carregar citações ou trilhas de auditoria, ou quando não há orçamento para retreinar conforme os dados derivam. Essas quatro condições descrevem a maioria dos produtos em estágio inicial, e é por isso que o RAG costuma ser a primeira jogada certa.

O fine-tuning foi desmistificado?

Não, mas o território dele encolheu. Janelas de contexto longas e RAG barato absorveram casos de uso que exigiam fine-tuning em 2023. O que resta é real: formato de saída estrito, tom de marca, orçamentos de latência sem ida e volta de recuperação e economia de modelos pequenos. Se o seu problema é como o modelo responde, e não o que ele sabe, o fine-tuning ainda é a ferramenta.

Quando você usaria RAG vs fine-tuning?

Use RAG quando as respostas dependem de conhecimento privado ou atualizado com frequência, ou quando você precisa de citações. Use fine-tuning quando você precisa de formato, tom ou latência consistentes e tem exemplos rotulados suficientes. Use os dois quando o produto amadurecer. Na dúvida, comece com RAG: é mais barato de desfazer do que um treino.

O RAG é mais barato que o fine-tuning?

De imediato, sim. O custo do RAG é por consulta (embeddings mais tokens de entrada extras), enquanto o fine-tuning cobra uma vez pelo treinamento e dados rotulados, depois renova a cada retreino. Nos preços públicos de tabela, o break-even fica em torno de 6,4 milhões de consultas no nosso exemplo trabalhado, então em volumes típicos o RAG continua mais barato durante toda a vida do produto.

O RAG é melhor que o fine-tuning para alucinações?

Geralmente, mas não de graça. O RAG fundamenta as respostas em chunks recuperados, então você pode citar fontes e auditar falhas. Mas uma recuperação ruim envenena a resposta: a Anthropic mediu uma taxa de falha de recuperação top-20 de 5,7% em setups simples, cortada para 1,9% com recuperação contextual mais reranking. O fine-tuning, por sua vez, pode gravar erros nos pesos sem nenhuma forma de rastreá-los.

RAG vs fine-tuning vs engenharia de prompt: qual é a diferença?

A engenharia de prompt muda as instruções que você envia. O RAG muda o contexto que o modelo lê no momento da consulta. O fine-tuning muda os pesos do modelo. Cada um é uma intervenção maior que o anterior: tente prompts primeiro, adicione recuperação quando o conhecimento for o gargalo e treine só quando formato, tom ou latência ainda doerem.

Como você avalia o desempenho de RAG vs fine-tuning?

Monte um conjunto reservado de 100-300 perguntas reais de usuários e pontue as duas abordagens nele: fidelidade (está fundamentada?), correção da resposta (está certa?), latência no p95 e custo por 1.000 consultas. Rode o conjunto de novo sempre que os seus documentos ou snapshot de modelo mudar. Perguntas sintéticas lisonjeiam os dois sistemas; as reais os separam.

Fine-tuning vs RAG para perguntas multi-hop em conhecimento novo?

RAG, com recuperação melhor. O mecanismo decide esta: um modelo com fine-tuning só consegue raciocinar sobre o que os pesos dele absorveram, então o conhecimento que ele nunca viu é inalcançável, não importa quão bem ele foi treinado. A recuperação entrega a ele as peças que faltam no momento da consulta. A pegadinha é que uma passada de recuperação raramente coleta cada hop, então planeje decomposição de consulta ou recuperação iterativa mais um reranker, não uma única busca top-K.

Conclusão

O resumo, sem rodeios:

• O RAG é o padrão para conhecimento mutável e respostas citadas. O fine-tuning é o especialista para formato, tom e latência.
• A evidência na mesma tarefa (Balaguer et al.) dá ao fine-tuning +6 p.p. e ao RAG mais +5 p.p. por cima, com o híbrido o melhor dos três. Nosso conselho de começar com RAG se apoia em frescor, citações e custo, não nesse placar.
• A matemática de custo pende a favor do RAG em volumes realistas: o break-even ficou em torno de 6,4 milhões de consultas no nosso exemplo trabalhado.
• Decida com as cinco verificações, não com o hábito.

Escolheu o RAG? Veja nossa lista ranqueada de ferramentas RAG para a stack ao redor do pipeline.