RAG ou ajuste fino? O que projetos reais com clientes nos ensinaram sobre como escolher

Quase toda conversa sobre IA empresarial de que participo chega à mesma encruzilhada na primeira hora. O cliente tem um modelo de linguagem grande que impressiona em uma demonstração, mas não conhece seus produtos, suas políticas nem seu estilo de escrita. Alguém na sala pergunta: devemos ajustar o modelo com nossos dados ou criar uma solução de geração aumentada por recuperação (RAG) em torno dele?

A resposta sincera é que, em geral, a pergunta está mal formulada. RAG e ajuste fino resolvem problemas diferentes. Equipes que os tratam como opções concorrentes tendem a passar meses e gastar muito do orçamento de GPU tentando resolver o problema errado. Veja como decidimos na prática e o que vimos dar certo e errado.

Comece identificando o que falta ao modelo

Quando um modelo dá uma resposta ruim para uma tarefa empresarial, está faltando uma de duas coisas.

Falta conhecimento. Ele não conhece sua tabela de preços mais recente, a cláusula do seu contrato com fornecedores de 2025 ou as etapas de solução de problemas de um produto lançado no mês passado. Esse é um problema de fatos.

Falta comportamento. Ele sabe o suficiente, mas não responde da maneira de que você precisa. Ignora o formato de saída, escreve no tom errado, interpreta mal seus códigos internos ou não consegue executar uma tarefa específica e repetitiva, como classificar tíquetes em suas 40 categorias. Esse é um problema de habilidades.

RAG é a ferramenta para o primeiro problema. O ajuste fino é a ferramenta para o segundo. Grande parte da confusão que vejo vem de tentativas de usar o ajuste fino para ensinar fatos.

Por que o ajuste fino é uma maneira ruim de acrescentar conhecimento

É tentador pensar que, se você treinar um modelo com seus documentos, ele vai «conhecê-los». Na prática, ele aprende o estilo desses documentos com muito mais confiabilidade do que os fatos contidos neles. Pesquisadores da Microsoft compararam diretamente as duas abordagens em perguntas que exigem muito conhecimento e constataram que o RAG superou consistentemente o ajuste fino não supervisionado, tanto para fatos que o modelo havia visto durante o treinamento quanto para fatos totalmente novos.

Também há problemas práticos. Os fatos mudam. Sempre que sua política ou seu catálogo muda, um modelo ajustado fica desatualizado até ser treinado novamente. Você também perde a rastreabilidade: quando um modelo ajustado apresenta um valor, não é possível indicar o documento de onde ele veio. Para clientes de setores regulamentados, como seguros e saúde, só isso costuma encerrar a discussão.

O RAG, descrito pela primeira vez no artigo de 2020 de Lewis e colaboradores, mantém o conhecimento fora do modelo. No momento da pergunta, você recupera os trechos relevantes e os fornece ao modelo como contexto. Para atualizar o conhecimento, basta atualizar um índice, sem retreinar o modelo. Além disso, cada resposta pode citar sua fonte.

Um cliente nosso do setor de logística é um bom exemplo. Seus clientes queriam respostas instantâneas sobre a localização de suas remessas e os documentos que estavam faltando. Essas informações mudam a cada poucos minutos. Nenhum treinamento teria mantido um modelo atualizado; por isso, o assistente que criamos responde com base em dados de rastreamento em tempo real e dados de IoT no momento da pergunta, em vez de recorrer à memória. A recuperação era a única solução que poderia funcionar.

Em que situações o ajuste fino se justifica

O ajuste fino não está morto. É apenas mais restrito do que as pessoas imaginam. Recorremos a ele em três situações:

• Formatos de saída rígidos e repetitivos. Quando um modelo precisa produzir a mesma saída estruturada milhares de vezes por dia, como extrair campos de faturas para um esquema JSON fixo, um modelo pequeno ajustado costuma ser mais confiável e muito mais barato do que usar prompts com um modelo grande.
• Linguagem especializada. Em algumas áreas, há abreviações que o modelo-base interpreta mal. Códigos de status de logística, abreviações clínicas e códigos internos de produtos são exemplos comuns. Um ajuste fino modesto pode resolver o problema.
• Custo e latência em grande escala. Quando uma tarefa está bem definida, um modelo pequeno ajustado pode substituir um modelo geral grande. Métodos como LoRA tornam isso acessível, pois treinam um pequeno conjunto de pesos adicionais em vez do modelo inteiro.

Observe que nenhuma dessas situações envolve fatos. Elas dizem respeito a ensinar um modelo a se comportar de determinada maneira em uma tarefa que você já conhece bem.

A maioria das falhas de RAG é, na verdade, falha de recuperação

Quando alguém de uma equipe me diz «tentamos usar RAG e não funcionou», raramente o problema está no modelo. Está na etapa de recuperação. A qualidade do modelo não pode superar a dos trechos que recebe.

As correções não são glamorosas, mas funcionam:

• Divida por significado, não por número de caracteres. Dividir um contrato a cada 500 caracteres corta cláusulas ao meio. Dividi-lo por seção e título mantém o contexto intacto.
• Acrescente contexto a cada fragmento. Um fragmento que diz «o limite é de 30 dias» é inútil sem que se saiba a qual política ele pertence. A Anthropic relatou que acrescentar um breve contexto documental a cada fragmento antes de indexá-lo — abordagem que chama de recuperação contextual — reduziu as falhas de recuperação em 49%, e em 67% quando combinada com reclassificação.
• Combine a busca por palavras-chave com a busca vetorial. A busca vetorial é boa para identificar significados, mas não é tão eficaz com termos exatos, como números de peças. A busca híbrida abrange os dois.
• Teste a recuperação separadamente. Crie um conjunto de perguntas reais com passagens de origem corretas conhecidas e avalie se a passagem certa aparece entre os primeiros resultados antes de julgar as respostas finais.

Quando usar ambos

Em produção, os sistemas mais robustos costumam combinar os dois. O RAG fornece os fatos. Um modelo levemente ajustado por fine-tuning cuida do formato, do tom e da linguagem específica do domínio. A pesquisa segue a mesma direção: a abordagem RAFT da UC Berkeley ajusta um modelo especificamente para aproveitar melhor os documentos recuperados e ignorar os irrelevantes.

Mas a ordem importa. Quase sempre começamos pelo RAG, medimos onde ele deixa a desejar e só então decidimos se vale a pena fazer fine-tuning. Começar pelo fine-tuning significa pagar pelo treinamento antes de saber qual é a lacuna real.

Uma lista simples para ajudar na decisão

1. A tarefa depende de fatos que mudam mais de uma vez por trimestre? Use RAG.
2. Os usuários ou auditores precisam saber de onde veio uma resposta? Use RAG.
3. O problema está no formato, no tom ou no vocabulário das respostas, e não nos fatos? Considere o fine-tuning.
4. É uma tarefa específica, executada em alto volume, em que o custo ou a velocidade importa? Considere fazer fine-tuning de um modelo menor.
5. Você já mediu a qualidade da recuperação separadamente? Se não, faça isso antes de qualquer outra coisa.

Conclusão

RAG e fine-tuning não são concorrentes. Um fornece as informações corretas ao modelo; o outro molda seu comportamento. Identifique com clareza qual problema você realmente tem, corrija a recuperação antes de culpar o modelo e trate o fine-tuning como uma otimização que só se justifica depois que o sistema estiver funcionando, não como um atalho para fazê-lo funcionar.