Fine-tuning ou RAG: quando ajustar um modelo de IA na empresa

Fine-tuning ou RAG: quando ajustar um modelo de IA na empresa

Na maioria dos casos de empresa, comece pelo RAG (geração aumentada por recuperação): ele entrega ao modelo o conhecimento certo na hora da pergunta, a partir de documentos que você controla e atualiza. O fine-tuning vale quando o problema não é falta de informação, e sim o jeito de responder: formato, tom, classificação ou uma tarefa repetitiva que instruções bem escritas não sustentam. Os dois podem ser combinados, mas nesta ordem de prioridade: primeiro instruções e recuperação, depois ajuste.

Principais pontos

• RAG ensina o que o modelo deve consultar. Fine-tuning altera como o modelo se comporta. Confundir os dois é a causa mais comum de projeto caro e pouco útil.
• Conhecimento que muda (preços, prazos, políticas, estoque, contratos) pertence à recuperação, porque atualizar um documento é mais simples do que treinar de novo.
• Fine-tuning compensa quando existe uma tarefa estreita, repetida, com exemplos corretos suficientes e uma forma objetiva de medir se melhorou.
• Antes de qualquer ajuste, é preciso ter uma avaliação com casos reais. Sem ela, ninguém sabe se o modelo ajustado é melhor ou apenas diferente.
• O custo real está na manutenção: curar dados, reavaliar a cada mudança de modelo base e tratar dados pessoais sob a LGPD.

Qual a diferença prática entre RAG e fine-tuning?

No RAG, o modelo não muda. Quando chega uma pergunta, o sistema busca trechos relevantes em uma base de documentos e os coloca no contexto da resposta. O modelo lê esses trechos e responde com base neles. Se o documento mudar amanhã, a resposta de amanhã já muda.

No fine-tuning, o modelo é treinado de novo, em escala menor, com exemplos de entrada e saída desejada. Isso altera o comportamento interno dele. O resultado fica embutido no modelo ajustado: você não consegue apontar para um parágrafo e dizer de onde veio a resposta, e corrigir um fato errado exige novo ciclo de treino.

Uma analogia útil: o RAG é dar ao funcionário o manual atualizado e deixá-lo consultar. O fine-tuning é treinar esse funcionário durante semanas para que ele fale e decida de um jeito específico. Se o problema é que ele não sabe o preço de hoje, o manual resolve. Se o problema é que ele responde sempre com o formato errado, talvez o treino ajude.

A documentação da AWS sobre opções de RAG compara justamente esses dois caminhos e vale a leitura como referência técnica. O que está neste artigo combina essa base oficial com critérios de decisão para operação em empresas, e alguns pontos são hipóteses de trabalho que você deve validar no seu caso.

Quando o RAG é a escolha certa

O RAG é o ponto de partida quando a resposta depende de informação específica da empresa e essa informação muda com frequência. Alguns sinais claros:

• A base de conhecimento é composta por documentos: manuais, políticas, FAQs, propostas, contratos, tabelas de produtos.
• Você precisa mostrar a fonte da resposta, para que uma pessoa confira ou para que o cliente confie.
• Há regras de acesso: nem todo usuário pode ver todos os documentos, e a busca precisa respeitar isso.
• O conteúdo muda por semana, por mês ou por campanha.
• Você quer poder apagar ou corrigir uma informação com rapidez, inclusive por pedido de um titular de dados.

O RAG também tem limites. A qualidade da resposta depende da qualidade da busca: se o trecho certo não for recuperado, o modelo responde sem ele ou inventa. Documentos mal organizados, duplicados ou contraditórios produzem respostas confusas. E a quantidade de texto que entra no contexto tem teto e custo, o que conecta o tema à janela de contexto em IA.

Por isso, o trabalho de um bom RAG é mais de curadoria do que de modelo: dividir documentos em trechos coerentes, manter datas e responsáveis, remover versões antigas e testar a busca com perguntas reais. A arquitetura de referência do Google Cloud para RAG descreve bem as peças envolvidas, como ingestão, indexação, recuperação e geração.

Quando o fine-tuning faz sentido

O ajuste compensa quando o desafio é comportamental e repetitivo. Exemplos de situações em que ele costuma ser considerado:

• Classificar mensagens recebidas em categorias fixas, com um formato de saída rígido que será lido por outro sistema.
• Manter um tom de voz muito específico em grande volume de textos, quando descrever o tom em instruções não basta.
• Extrair campos de documentos com um padrão próprio da empresa, depois de provar que modelos gerais erram de forma consistente.
• Reduzir o tamanho do prompt: uma tarefa que exigia muitas instruções e exemplos pode, em alguns casos, ser feita por um modelo ajustado com instruções curtas.
• Usar um modelo pequeno para uma tarefa estreita, ajustado para ficar bom o bastante naquilo que importa.

Repare no que está ausente da lista: ensinar o catálogo, a política de troca ou o preço do mês. Fine-tuning é um mecanismo ruim para memorizar fatos que mudam. O modelo pode absorver o fato de forma imprecisa, misturar versões e responder com confiança algo que já não vale. Se o conteúdo precisa estar correto e atualizado, ele deve ser consultado, não decorado.

Antes de pensar em ajuste, esgote o que é mais barato: instruções claras, exemplos dentro do prompt, saída estruturada e validações. O artigo sobre como escrever instruções para atendimento com IA mostra como chegar longe sem treinar nada.

Quais dados cada caminho exige?

Os dois caminhos exigem dados, mas de naturezas diferentes.

Para o RAG, você precisa de documentos confiáveis e organizados: uma fonte oficial para cada assunto, com data, responsável e status (vigente ou substituído). Também precisa de um conjunto de perguntas reais para testar se a busca devolve o trecho certo.

Para o fine-tuning, você precisa de exemplos de entrada e saída corretos, revisados por quem entende do negócio. Isso é mais difícil do que parece. Conversas antigas de atendimento, por exemplo, trazem respostas boas e ruins misturadas, erros de digitação, informações desatualizadas e dados pessoais. Usá-las sem curadoria ensina ao modelo os vícios da operação atual.

Há ainda a dimensão da LGPD. Dados pessoais usados em treinamento ficam, de certa forma, incorporados ao modelo ajustado, o que dificulta atender pedidos de eliminação ou correção. No RAG, o dado está em uma base que você consegue localizar e apagar. Qualquer que seja o caminho, vale definir a finalidade, minimizar o que entra e mascarar identificadores quando possível. Se o provedor processa dados fora do país, leia também sobre transferência internacional de dados com IA e a LGPD. Para orientação oficial, a página da ANPD é a referência.

Como comparar custo e manutenção?

Os custos de cada abordagem aparecem em lugares diferentes, e comparar apenas o preço de uma chamada ao modelo engana.

No RAG, os custos recorrentes estão na infraestrutura de busca, no processamento dos documentos, no volume de texto enviado ao modelo a cada pergunta e na curadoria contínua da base. O custo inicial costuma ser menor e o ciclo de correção é curto: corrigiu o documento, corrigiu a resposta.

No fine-tuning, há o trabalho de preparar e revisar exemplos, executar o treino, avaliar o resultado e repetir. Depois vem o custo escondido: quando o provedor lança um modelo base novo ou descontinua o antigo, o ajuste pode precisar ser refeito e reavaliado. Quando o conhecimento do negócio muda, o conjunto de exemplos também precisa mudar.

Uma forma de organizar a comparação é perguntar, para cada opção:

• Quem atualiza o quê quando a empresa mudar uma regra?
• Quanto tempo leva para uma correção chegar ao usuário?
• O que acontece se trocarmos de provedor ou de modelo?
• Como provamos, com casos reais, que a versão nova não piorou nada?
• Quem responde por um erro e como ele é rastreado até a origem?

A quinta pergunta favorece o RAG, porque a resposta pode citar o trecho usado. A terceira pede cuidado com o fine-tuning, que tende a prender o comportamento a um modelo específico. Para entender como o volume de texto afeta o custo de qualquer abordagem, veja também o material sobre tokens, e para medir a evolução use o guia de avaliações (evals) da OpenAI como referência de método.

Guia de decisão em passos

Use esta sequência antes de contratar qualquer ajuste de modelo:

• Descreva o problema em uma frase: falta informação, ou o modelo responde de um jeito errado? Informação faltando aponta para RAG. Jeito errado pode apontar para instruções ou ajuste.
• Monte um conjunto de casos reais, com a resposta esperada em cada um, revisados por quem conhece a operação. Esse conjunto é a régua de todo o projeto.
• Teste com instruções melhores, exemplos no prompt e saída estruturada. Registre o resultado.
• Se faltar conhecimento, adicione recuperação sobre fontes oficiais e meça de novo, separando erros de busca de erros de resposta.
• Só considere fine-tuning se o erro restante for de comportamento, repetitivo e estreito, e se houver exemplos corretos em quantidade e qualidade suficientes.
• Compare o modelo ajustado com a linha de base nos mesmos casos, inclusive nos casos difíceis e nos que devem ser recusados ou encaminhados a uma pessoa.
• Defina quem mantém a base de exemplos, quando ela é revisada e qual é o gatilho para reavaliar (troca de modelo, mudança de política, queda de qualidade).

Se você chegou ao quinto passo sem ter feito os anteriores, é provável que o projeto esteja começando pelo lado mais caro.

Cenário ilustrativo e como aplicamos o método

Cenário ilustrativo: uma distribuidora fictícia de materiais elétricos quer atender dúvidas de clientes no WhatsApp. As perguntas se dividem em dois grupos. O primeiro trata de produtos, prazos, política de troca e condições comerciais, que mudam com frequência. O segundo é a triagem das mensagens recebidas em categorias fixas (orçamento, segunda via, troca, reclamação), com o resultado lido por outro sistema.

Para o primeiro grupo, a escolha natural é RAG sobre o catálogo e as políticas vigentes, com a fonte registrada em cada resposta e encaminhamento para uma pessoa quando a busca não encontra nada confiável. Para o segundo, a empresa testa primeiro instruções claras e exemplos no prompt. Só se, nos casos reais, ainda houver erro consistente de classificação, avalia um ajuste, com exemplos revisados e sem dados pessoais desnecessários. Nada disso é resultado de cliente: é apenas um raciocínio de decisão.

O método que aplicamos segue quatro movimentos. Mapear: entender o processo atual, o volume de casos e a linha de base de qualidade. Limitar: definir quais dados entram, quais fontes valem e quais ações o sistema pode executar. Pilotar: rodar um fluxo real, com registros e uma métrica de sucesso combinada antes. Transferir: entregar a documentação, os casos de teste e o plano de manutenção, e decidir em conjunto se o projeto expande, ajusta ou para. Nesse desenho, o ajuste de modelo é uma decisão tomada com evidência do piloto, não um ponto de partida.

Perguntas frequentes

Fine-tuning ensina o modelo a conhecer os documentos da minha empresa? Não de forma confiável. O ajuste muda o comportamento e pode absorver parte do conteúdo, mas de modo impreciso e difícil de corrigir. Para conhecimento que precisa estar certo e atualizado, o caminho indicado é consultar os documentos na hora da resposta, com RAG.

Posso usar RAG e fine-tuning juntos? Sim, e há casos em que isso faz sentido: o RAG fornece os fatos e o modelo ajustado cuida do formato ou do tom. A recomendação é chegar a essa combinação por etapas, medindo cada uma contra os mesmos casos reais, para saber o que cada peça realmente melhorou.

Fine-tuning resolve respostas inventadas? Não por si só. Respostas inventadas costumam vir de ausência de fonte, busca ruim ou instruções frouxas. Recuperação com fontes oficiais, regras de recusa e guardrails de validação atacam esse problema de forma mais direta, e o ajuste só entra se sobrar um erro de comportamento.

O que eu preciso ter pronto antes de decidir? Um conjunto de casos reais com respostas esperadas, uma fonte oficial para cada assunto, clareza sobre quais dados pessoais estão envolvidos e uma pessoa responsável por manter tudo isso. Com esses itens, a escolha entre recuperar e ajustar deixa de ser opinião e passa a ser resultado de teste.

Fontes

• AWS: comparing retrieval and fine-tuning
• Google Cloud: retrieval-augmented generation architecture
• OpenAI: evals guide
• ANPD: Autoridade Nacional de Proteção de Dados