Fine-tuning, RAG ou prompt: qual dos três o seu problema pede

"Vamos treinar um modelo nosso."

Já ouvi essa frase em reunião de arquitetura mais vezes do que consigo contar. E quase sempre a pergunta seguinte mata a ideia: me diz o que você tenta ensinar que um bom contexto não resolveria por 3% do preço.

Não é implicância. É que fine tuning virou o reflexo errado. Quando o modelo erra, o instinto de muita equipe é treinar. Só que na maioria dos casos o problema não está nos pesos do modelo, está no que você colocou (ou deixou de colocar) dentro da janela de contexto.

Este post é um framework de decisão, não uma explicação de conceitos. Você sai daqui com quatro perguntas objetivas pra escolher entre prompt, RAG e fine-tuning, o custo real de cada caminho com números, os três casos raros em que treinar realmente ganha, e o diagnóstico de uma linha que separa problema de conhecimento de problema de recuperação.

TL;DR

• A ordem correta é: prompt → RAG → evals → fine-tuning. Nessa sequência, e só avança quando o passo anterior provou que bateu no teto.
• A briga RAG vs fine tuning é mal formulada: fine-tuning muda COMO o modelo responde, RAG muda O QUE ele sabe. Confundir os dois é o erro que custa caro.
• Custo real: prompt com caching corta a conta de inferência em ~62% e não cobra nada de setup. Fine-tuning custa milhares de dólares antes da primeira resposta útil e ainda encarece a inferência em até 50% para sempre.
• Notícia que muda a conta em 2026: a OpenAI está encerrando a plataforma de fine-tuning. Clientes ativos param de criar jobs em 6 de janeiro de 2027.
• Evidência científica: treinar conhecimento novo aumenta alucinação de forma linear. Não é opinião, é paper de EMNLP.

O que cada um realmente muda no comportamento

Os três atuam em camadas diferentes do sistema. Essa é a distinção que resolve metade das decisões sozinha.

Prompt muda a instrução. Você reconfigura o comportamento a cada request. Custo marginal de mudança: zero. Tempo de iteração: segundos. Reversível com um git revert.

RAG muda o contexto. Você injeta fatos na hora da pergunta e o modelo continua exatamente o mesmo. Se você ainda está no começo dessa parte, já detalhei o que é RAG e onde ele termina e o pipeline de chunking, embeddings e busca em posts dedicados. Aqui vou tratar RAG como caixa fechada e falar só de decisão e custo.

Fine-tuning muda os pesos. Você altera a distribuição de probabilidade do próximo token. É permanente, caro de reverter, e exige um ciclo novo de treino a cada ajuste de comportamento.

Agora a frase que vale o post inteiro:

Prompt e RAG operam em runtime. Fine-tuning opera em build time.

Toda informação que muda depois do deploy tem que entrar em runtime. Se você treinou o modelo com a tabela de preços de agosto, em setembro você tem um modelo que mente com convicção sobre preço. Não tem prompt que conserte isso, porque o erro está nos pesos.

Esse é literalmente o primeiro módulo do AI Engineering Lab 3ª Edição: antes de tool calling, memória ou tracing, decidir em qual camada o comportamento do seu sistema é configurado. São dois dias ao vivo, 19 e 20 de setembro, das 9h às 13h, no Meet, montando arquitetura de agente em produção.

A árvore de decisão em 4 perguntas

Se você só quer saber quando usar fine tuning, a resposta honesta está nestas quatro perguntas. Rode na ordem: a primeira que fechar, fechou.

1. O dado que falta muda com o tempo?

Se a resposta correta hoje é diferente da de três meses atrás, fine-tuning está fora. Não há discussão aqui. Preço, estoque, política interna, documentação de API, status de pedido: tudo isso é runtime. Vai de RAG ou de tool call.

Fine-tuning congela. E dado congelado em produção não é um modelo desatualizado, é um modelo confiante e errado, que é bem pior.

2. O modelo erra o FATO ou erra a FORMA?

Essa é a pergunta que mais gente pula.

• Erra o fato (inventa um número, cita uma cláusula que não existe, atribui uma feature ao produto errado) → problema de recuperação. RAG.
• Erra a forma (devolve JSON quebrado, ignora a instrução de tom, escreve três parágrafos quando você pediu uma linha, escolhe a rota errada) → problema de comportamento. Prompt primeiro. Fine-tuning só se o prompt provar que não chega lá.

A OpenAI diz a mesma coisa no guia oficial de otimização: fine-tuning serve pra classificação, formato, tom e falha de instruction-following. Nenhum desses é conhecimento.

3. Você tem eval?

Se você não tem um dataset de avaliação com nota, você não tem como saber se treinar melhorou alguma coisa. Vai trocar impressão por impressão, com um custo de quatro dígitos no meio.

Fine-tuning sem eval não é engenharia, é fé. E o teste é honesto: se você não consegue dizer "hoje estou em 71% de acerto nos meus 120 casos", você não está pronto pra treinar. Está pronto pra montar o eval. Já mostrei como montar esse pipeline no CI.

4. Você realmente esgotou o prompt?

Na prática, quase ninguém esgotou. Antes de treinar, você já:

• colocou 5 a 10 few-shots reais, tirados de casos que falharam?
• forçou structured output / JSON schema em vez de pedir formato por texto?
• quebrou a tarefa em duas chamadas em vez de uma chamada heroica?
• testou o modelo maior por uma semana pra ver onde fica o teto?
• arrumou o retrieval, em vez de culpar o gerador? (as causas reais estão aqui)

Se qualquer item ficou sem marcar, você não terminou o caminho barato.

Quanto custa cada caminho, com números

Vamos ancorar num cenário concreto: um agente de suporte técnico, 100 mil requests por mês, prompt de sistema com instruções e few-shots somando 6.000 tokens fixos, pergunta do usuário com 200 tokens, resposta com 400 tokens. Preços de Claude Sonnet 4.6 (US$ 3 por 1M de input, US$ 15 por 1M de output).

Caminho 1: prompt

Sem caching, os 6.000 tokens fixos são cobrados 100 mil vezes:

input:  6.200 tok × 100.000 = 620M × $3/M  = $1.860
output:   400 tok × 100.000 =  40M × $15/M =   $600
                                     total = $2.460/mês

Com prompt caching, cache read custa 0.1x o input e cache write de 5 minutos custa 1.25x. Assumindo 95% de hit no bloco fixo:

cache read:   6.000 × 95.000 = 570M × $0,30/M = $171,00
cache write:  6.000 ×  5.000 =  30M × $3,75/M = $112,50
input novo:     200 × 100.000 =  20M × $3,00/M =  $60,00
output:                          40M × $15,00/M = $600,00
                                        total = $943,50/mês

62% de economia com uma mudança de três linhas no código. Setup: zero de infra nova, dias de engenharia. Esse é o número que a maioria das equipes nunca vai buscar antes de propor treinar um modelo.

Caminho 2: RAG

O custo de embeddings assusta muita gente e é a parte mais barata da conta. 50 mil documentos de 800 tokens dão 40M de tokens: com text-embedding-3-small a US$ 0,02 por 1M, são US$ 0,80 uma vez. As queries do mês custam centavos.

O custo real do RAG está em outro lugar:

• Infra de vetor (Postgres com pgvector, instância dedicada): US$ 50 a 200/mês.
• Reranker gerenciado, a ~US$ 2 por 1.000 buscas: US$ 200/mês nas 100 mil buscas.
• Tokens de contexto recuperado, que é o item que dói: 3.000 tokens por request que mudam a cada pergunta e por isso não cacheiam. São 300M de tokens a US$ 3/M = US$ 900/mês.

Incremental de ~US$ 1.150/mês sobre o caminho 1. Engenharia: 2 a 6 semanas até virar algo confiável em produção.

Caminho 3: fine-tuning

Aqui a conta muda de natureza, porque o custo dominante não é de API.

Treino, usando o preço da OpenAI de US$ 25 por 1M de tokens de treino no gpt-4.1: um dataset de 5.000 exemplos de 1.200 tokens dá 6M por época, 18M em três épocas. US$ 450 por rodada. E ninguém acerta na primeira: de 5 a 10 rodadas até um checkpoint aceitável, ou seja, US$ 2.250 a 4.500.

Curadoria do dataset, que é o custo que ninguém coloca no slide: 5.000 exemplos revisados por gente que entende do domínio, a 60 exemplos por hora, dão 83 horas de trabalho. A R$ 150/h isso é R$ 12.450. Esse é o item mais caro da lista inteira, e ele não aparece em nenhuma calculadora de token.

Inferência mais cara para sempre: o gpt-4o fine-tunado custa US$ 3,75 de input contra US$ 2,50 do base, e US$ 15 de output contra US$ 10. 50% de sobretaxa em cada request, todo mês, enquanto o modelo viver.

E o custo de manutenção: cada mudança de comportamento é dataset novo, treino novo, validação nova. Não é git revert, é sprint.

A tabela

Olha a coluna "reverter". Ela é a mais importante e a que menos gente considera na hora de decidir.

Os 3 casos raros em que fine tuning ganha

Não é nunca. É raro. E os três casos têm a mesma assinatura: o que você ensina é comportamento, não fato, e o objetivo é quase sempre cortar custo, não subir o teto de qualidade.

1. Destilação para rodar barato em escala

Você tem um prompt gigante rodando num modelo grande e funcionando bem. Usa esse modelo pra gerar 20 mil exemplos de alta qualidade e treina um modelo pequeno pra imitar o comportamento.

O ganho aqui é custo e latência, não inteligência. Você troca US$ 15 de output por US$ 5, e 4 segundos de resposta por 800ms. Se seu volume não justifica esse delta, o caso não é seu.

2. Domínio com linguagem que o pré-treino viu pouco

Laudo médico com abreviação de hospital, peça jurídica de um nicho específico, uma DSL interna da sua empresa que existe em três repositórios privados. O modelo não tem os padrões, e nenhuma quantidade de few-shot compensa.

Repare que mesmo aqui o ganho é sobre como falar, não sobre o que saber. Os fatos continuam vindo de recuperação.

3. Classificação de altíssimo volume com rótulo estável

Moderação de conteúdo, roteamento de ticket, triagem de intenção. O conjunto de rótulos não muda há um ano, o volume é de milhões por mês e a latência importa.

Um modelo pequeno treinado bate prompt em modelo grande com uma folga absurda em custo por chamada. Esse é o caso mais legítimo dos três e, por acaso, é justamente pra ele que a OpenAI ainda aponta o fine-tuning no guia oficial.

O aviso de 2026

Antes de arquitetar em cima disso, olha o calendário. A OpenAI está encerrando a plataforma de fine-tuning:

• 7 de maio de 2026: organizações que nunca treinaram não podem mais criar jobs.
• 2 de julho de 2026: bloqueio também para quem não rodou inferência em modelo fine-tunado nos últimos 60 dias.
• 6 de janeiro de 2027: clientes ativos deixam de criar novos jobs.

Inferência nos modelos já treinados continua até o modelo base ser descontinuado. A justificativa da própria OpenAI foi direta: os modelos novos ficaram capazes o bastante pra tornar boa parte do fine-tuning desnecessário.

Isso não mata o fine-tuning (open weights com LoRA seguem vivos, e é pra lá que esse caso migra). Mas mata a ideia de que fine-tuning gerenciado é a escolha default e segura pro longo prazo.

O erro clássico: treinar pra resolver problema de recuperação

Esse é o erro que fecha o post porque é o mais caro de todos: a equipe quer que o modelo "saiba" a base de conhecimento da empresa, então joga a documentação inteira num dataset de treino.

Não funciona. E existe literatura em cima disso.

O paper Fine-Tuning or Retrieval? (EMNLP 2024) comparou os dois métodos pra injetar conhecimento. Na tarefa de eventos atuais, RAG tirou 0,875 contra 0,504 do fine-tuning no Mistral. Mais que o dobro, com o modelo base intacto.

O FineTuneBench foi mais fundo e mediu as APIs comerciais: 37% de acurácia de generalização pra absorver informação nova, e 19% pra atualizar conhecimento que o modelo já tinha. Gemini 1.5 Flash e Pro simplesmente não aprenderam.

E o mais grave, do Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?: exemplos com conhecimento novo são aprendidos mais devagar e, à medida que são aprendidos, aumentam de forma linear a tendência do modelo a alucinar. Você não só falha em ensinar o fato: você degrada a capacidade do modelo de usar o que ele já sabia.

Traduzindo pra produção: você gastou R$ 15 mil pra ficar com um modelo que erra mais.

O diagnóstico de uma linha

Tem um teste que resolve essa dúvida em cinco minutos, e ele é constrangedoramente simples. Pega o caso que falhou e cola o documento certo direto no prompt, na mão:

Contexto:
<cola aqui, na unha, o trecho do documento que contém a resposta>

Pergunta:
<a pergunta que o modelo errou em produção>

Roda. E lê o resultado assim:

• Acertou com o documento colado → você tem um problema de recuperação. O modelo é capaz, ele só não recebeu o texto. Conserte busca, chunking ou reranker. Treinar aqui é queimar dinheiro pra resolver um bug de SELECT.
• Errou mesmo com o documento na frente → aí sim é problema de comportamento ou capacidade. Aí a conversa sobre prompt melhor, modelo maior ou fine-tuning começa a fazer sentido.

Na minha experiência, esse teste manda a esmagadora maioria dos "precisamos treinar um modelo" de volta pro backlog de retrieval. É o motivo de o reranker ser, quase sempre, o melhor retorno por real investido antes de qualquer coisa mais sofisticada.

FAQ rápido

Dá pra usar RAG e fine-tuning juntos? Dá, e em sistemas maduros é comum: o fine-tuning controla formato e raciocínio, o RAG controla os fatos. Mas isso é otimização de quem já tem os dois funcionando separados, não ponto de partida. Detalhei a arquitetura híbrida aqui.

Quantos exemplos preciso pra fine-tuning valer a pena? O mínimo técnico da OpenAI é 10, e a recomendação é começar com 50 bem feitos. Mas para mudança de comportamento consistente em produção, a faixa realista é de 1.000 a 10.000 exemplos curados. Se você tem 200 exemplos, o lugar deles é no prompt como few-shot, não num job de treino.

Prompt caching funciona com contexto recuperado do RAG? Só na parte estável. O bloco fixo (instruções, schema, few-shots) cacheia bem; os trechos recuperados mudam a cada pergunta e não aproveitam cache. Por isso vale ordenar o prompt do mais estático para o mais dinâmico, com o conteúdo do RAG no fim.

E se eu quiser rodar fine-tuning em modelo open weight? Aí o jogo é outro: LoRA num modelo aberto tira o custo de API da conta e devolve controle. Continua valendo a árvore de decisão inteira, principalmente a pergunta 1. Modelo aberto treinado com dado volátil erra igual.

Conclusão

O framework cabe em uma linha: prompt até bater no teto, RAG quando faltar fato, fine-tuning quando faltar comportamento e o volume justificar a conta.

E antes de qualquer uma das três, um eval. Sem eval você não está escolhendo arquitetura, está escolhendo com base em sensação.

Fine-tuning não morreu. Mas em 2026 ele deixou de ser a resposta default e virou uma otimização de custo pra caso maduro, com dataset curado e métrica no lugar. O caminho que quase sempre paga mais rápido continua sendo o mais chato: arrumar o retrieval e escrever um prompt melhor.

Se você quer aprofundar o critério de escolha por outro ângulo (volatilidade do dado, rastreabilidade e tamanho do corpus), o post sobre quando usar RAG, fine-tuning ou contexto fecha bem com este aqui.

Agora vai lá e roda o teste do documento colado no seu caso que falhou. Aposto no retrieval.