RAG, fine-tuning ou prompt: qual problema cada um resolve

"Vamos fazer fine-tuning para o modelo aprender sobre a nossa empresa." Essa frase inicia um projeto de semanas que quase sempre poderia ter sido uma tarde de trabalho, porque parte de um diagnóstico errado.

As três técnicas resolvem problemas diferentes, e a confusão entre elas é a causa mais comum de esforço desperdiçado em projetos de IA. Antes de escolher, vale identificar qual falha você está tentando corrigir.

O diagnóstico vem antes da escolha

Faça uma pergunta que o sistema erra hoje e classifique o erro:

A distinção mais importante é a primeira linha contra a última. Conhecimento é RAG. Comportamento é fine-tuning. Confundir os dois é o erro caro.

Se o modelo não sabe qual é a sua política de cancelamento, treiná-lo não é a solução: ele vai aprender o estilo dos seus documentos e continuar inventando o conteúdo, agora com mais convicção. E na semana seguinte a política muda, e o treino inteiro fica desatualizado.

Prompt: a técnica subestimada

Boa parte do que se atribui a limitação do modelo é instrução mal escrita. Antes de qualquer coisa mais elaborada, vale esgotar o que um prompt bem construído entrega.

Quatro elementos costumam faltar:

• Papel e contexto. Quem o modelo é, para quem responde, o que pode e o que não pode.
• Formato explícito da saída. Se você quer JSON com três campos, diga os campos e o tipo de cada um. Descrever o formato em prosa produz variação.
• Autorização para não saber. "Se a informação não estiver no material fornecido, responda que não consta." Sem isso, o modelo preenche a lacuna.
• Restrições negativas. O que não fazer costuma ser mais eficaz que uma descrição do que fazer.

O custo dessa etapa é uma tarde. O ganho é frequentemente suficiente para encerrar o projeto ali — e mesmo quando não é, você chega às técnicas seguintes com um prompt decente, o que muda o resultado delas também.

Uma técnica intermediária, entre prompt e treino, é o few-shot: incluir três a cinco exemplos de entrada e saída correta no próprio prompt. É notavelmente eficaz para padronizar formato e tom, custa apenas os tokens dos exemplos, e leva minutos para ajustar. Muita coisa que se atribui a necessidade de fine-tuning se resolve com cinco exemplos bem escolhidos.

RAG: quando o problema é conhecimento

Se a falha é o modelo não saber algo que está nos seus documentos, a resposta é recuperar o trecho relevante e entregá-lo junto com a pergunta.

RAG é a escolha certa quando:

• A informação muda. Preço, política, catálogo, procedimento. Atualizar é reindexar um documento, não retreinar.
• A resposta precisa citar a fonte. É verificável, e verificabilidade costuma ser requisito.
• O acesso é diferenciado por usuário. O filtro acontece na recuperação; um modelo treinado não tem como esquecer seletivamente.
• O volume de conhecimento é grande. Nenhum contexto comporta a base inteira.

O que RAG não resolve: ele não ensina o modelo a escrever no seu tom, não corrige formato de saída, e não faz o modelo entender terminologia que ele desconhece. Também não conserta um modelo que ignora a instrução — se ele inventa mesmo com o trecho correto na frente, o problema é de prompt.

A qualidade de um sistema RAG depende muito mais da recuperação que do modelo. Se o trecho certo não é encontrado, nenhum modelo compensa. O artigo sobre infraestrutura para RAG cobre o pipeline, e a escolha do banco vetorial costuma ser a parte menos crítica dele.

Fine-tuning: quando é mesmo o caminho

Fine-tuning ajusta os pesos do modelo com exemplos seus. Ele ensina como se comportar, não o que saber.

Os casos legítimos são mais estreitos do que se imagina:

• Formato rígido e repetitivo. Extrair sempre a mesma estrutura, com milhares de chamadas por dia. Treinar um modelo pequeno para isso sai mais barato e mais rápido que instruir um grande a cada chamada.
• Tom e estilo muito específicos, que exemplos no prompt não capturam de forma consistente.
• Vocabulário de domínio fechado — jurídico, médico, técnico regulado — em que o modelo base erra terminologia com frequência.
• Redução de custo. Um modelo pequeno afinado numa tarefa estreita pode igualar um grande genérico, com uma fração do custo por chamada.

O que ele exige: centenas a milhares de exemplos de qualidade, tempo de preparação do conjunto de dados — que é a maior parte do trabalho, não o treino em si —, capacidade de avaliar se melhorou, e o compromisso de refazer quando o comportamento desejado mudar.

E uma consequência importante: o conjunto de treino vira parte da sua infraestrutura. Precisa ser versionado, ter procedência documentada e respeitar as regras de uso do dado que o compõe — assunto que merece atenção própria, porque usar dado de cliente para treinar tem requisitos que não existem no uso comum.

Elas se combinam

Na prática, sistemas maduros usam as três em camadas, e nessa ordem de adoção:

• Prompt define comportamento, formato e limites. Sempre presente.
• RAG injeta o conhecimento atualizado. Presente sempre que houver base própria.
• Fine-tuning entra por último, quando as duas anteriores já foram esgotadas e ainda existe uma lacuna mensurável.

A ordem importa porque o custo cresce muito em cada degrau. Prompt custa horas. RAG custa dias e uma infraestrutura modesta. Fine-tuning custa semanas, exige conjunto de dados e cria uma dependência de manutenção permanente.

O custo real de cada caminho

Colocar os três lado a lado, com o que consomem antes de entregar resultado:

A coluna que engana é a terceira. Fine-tuning tem o menor custo por chamada, o que o faz parecer economicamente superior — e é verdade em volume muito alto. Em volume comum, o custo de manutenção domina, e ele nunca aparece na comparação inicial.

Vale ser específico sobre esse custo de manutenção, porque é o que costuma surpreender. Um modelo afinado precisa ser refeito quando o comportamento desejado muda, quando o modelo base é descontinuado pelo fornecedor, e quando o conjunto de dados original precisa ser corrigido. Cada um desses eventos é um miniprojeto, e todos acontecem — o segundo com frequência maior do que se imagina, porque o ciclo de vida dos modelos base é curto.

RAG tem manutenção também, mas de natureza diferente: reindexar é uma rotina automatizável, não um projeto. É uma distinção que pesa bastante para equipe pequena.

Um roteiro para não errar

• Escreva vinte perguntas reais que o sistema precisa acertar, com a resposta correta ao lado. Este é o seu conjunto de avaliação, e sem ele nada abaixo faz sentido.
• Meça o modelo base, com um prompt simples. Quantas das vinte ele acerta?
• Melhore o prompt e meça de novo. Adicione few-shot e meça de novo.
• Adicione RAG se as falhas restantes forem de conhecimento. Meça.
• Só então considere fine-tuning, e apenas se as falhas restantes forem de comportamento e o volume justificar o esforço.

Cada etapa precisa da medição, senão você não sabe se melhorou — e a sensação de melhora é notoriamente enganosa nesse tema. Como montar essa avaliação sem transformá-la em projeto é o assunto do artigo sobre saber se a sua IA piorou.

Na maior parte dos casos, o processo termina no terceiro passo. Isso não é fracasso do método — é o método funcionando, e economizando as semanas que teriam sido gastas no caminho errado.

Vale guardar uma última observação, porque ela contraria a intuição de quem está começando: quando um sistema de IA vai mal, a causa quase nunca é a escolha da técnica. É recuperação que devolve o trecho errado, instrução ambígua, ou ausência de qualquer medição que permitisse perceber o problema antes. Trocar de técnica é a resposta mais visível e raramente é a correta.