O que é Fine-Tuning de IA: Quando Usar (e Quando RAG é Melhor) [2026]

Fine-tuning é uma das palavras mais mal usadas do mercado de IA. Toda semana aparece alguém dizendo que "fez fine-tuning no ChatGPT" quando, na verdade, escreveu um prompt de sistema caprichado. Então vale começar do começo: o que é fine-tuning de verdade? É o processo de pegar um modelo de IA já treinado, como GPT-4o mini ou Llama, e continuar o treinamento dele com seus próprios exemplos, ajustando os pesos internos do modelo para que ele se comporte do jeito que você precisa.

Na Marfin, passamos os últimos dois anos construindo produtos e automações com IA generativa, e a pergunta "devo fazer fine-tuning ou usar RAG?" aparece em praticamente todo projeto que envolve dados próprios. A resposta errada custa caro: já vimos empresa gastar semanas montando dataset de treino para um problema que um bom prompt resolvia em uma tarde, e também vimos o contrário, gente empilhando gambiarras de prompt para algo que pedia um modelo customizado.

Neste guia, explicamos o que é fine-tuning na prática, como ele funciona por baixo do capô, quanto custa em 2026, e o critério que usamos para decidir entre fine-tuning, RAG e prompt engineering. Spoiler honesto: na maioria dos casos que atendemos, RAG ganha. Mas existem cenários em que o fine-tuning é imbatível, e saber diferenciar os dois é o que separa um projeto de IA que escala de um que vira dívida técnica.

O que é fine-tuning e como ele funciona na prática

Todo modelo de linguagem grande, um LLM, nasce de um pré-treinamento: a fase em que ele consome trilhões de tokens de texto da internet e aprende padrões de linguagem, raciocínio e conhecimento geral. Esse processo custa dezenas ou centenas de milhões de dólares e só faz sentido para empresas como Anthropic, OpenAI, Google e Meta. O fine-tuning entra depois. Ele pega esse modelo pronto e roda mais algumas rodadas de treinamento, agora com um dataset pequeno e específico, tipicamente entre algumas centenas e algumas dezenas de milhares de exemplos, para especializar o comportamento.

A analogia que usamos com clientes: o pré-treinamento forma um profissional com faculdade e anos de mercado. O fine-tuning é o onboarding na sua empresa, aquelas semanas em que ele aprende o seu jeito de escrever e-mail, o seu padrão de resposta, o seu formato de relatório. Depois do onboarding, você para de explicar tudo em cada tarefa, porque o comportamento já está internalizado. É exatamente isso que o fine-tuning faz com o modelo: internaliza padrões que antes você precisava descrever no prompt toda santa vez.

Tecnicamente, cada exemplo do dataset é um par de entrada e saída desejada. O modelo processa a entrada, compara a resposta dele com a resposta esperada, calcula o erro e ajusta os pesos para errar menos na próxima. Repita isso por algumas épocas de treinamento e os pesos do modelo se deslocam na direção do comportamento que os exemplos demonstram. O resultado é um modelo novo, seu, que responde do jeito treinado sem precisar de instruções longas.

Full fine-tuning, LoRA e QLoRA

Existem três formas principais de fazer isso, e a diferença entre elas é basicamente custo computacional. O full fine-tuning atualiza todos os pesos do modelo, bilhões de parâmetros. É o método mais potente e também o mais caro: exige GPUs de ponta, muita memória e um dataset robusto. Em 2026, quase ninguém fora de laboratórios e empresas grandes faz full fine-tuning de modelos acima de 8 bilhões de parâmetros.

O LoRA, sigla para Low-Rank Adaptation, mudou esse jogo. Em vez de mexer em todos os pesos, ele congela o modelo original e treina apenas pequenas matrizes adicionais, os chamados adapters, que representam menos de 1% dos parâmetros totais. O resultado chega perto do full fine-tuning para a maioria dos casos práticos, com uma fração do custo. O QLoRA vai além: quantiza o modelo base para 4 bits antes de treinar os adapters, o que permite fazer fine-tuning de um Llama de 8 bilhões de parâmetros numa única GPU alugada por uns dois dólares a hora.

Se você usa APIs gerenciadas, como a da OpenAI ou o Gemini via AI Studio, nem precisa pensar nisso: você sobe um arquivo JSONL com seus exemplos, a plataforma treina (quase sempre com alguma variação de LoRA por trás) e te devolve um endpoint do modelo customizado. Nós montamos os scripts de preparação e validação desses datasets com o Claude Code, que é a ferramenta de programação com IA que mais usamos na Marfin, e o pipeline inteiro de um fine-tuning gerenciado fica pronto em um dia de trabalho.

O que o fine-tuning muda de verdade no modelo

Aqui mora o mal-entendido mais caro do mercado. Fine-tuning é excelente para ensinar comportamento: tom de voz, formato de saída, estilo de resposta, vocabulário de domínio, padrões de classificação. E é uma péssima ferramenta para injetar conhecimento factual novo. Se você treinar um modelo com 500 exemplos sobre seus produtos, ele vai aprender a falar como sua marca fala sobre produtos, mas vai continuar alucinando preço, estoque e especificação, porque fatos pontuais se diluem nos pesos em vez de ficarem armazenados como registro consultável.

Pense assim: os pesos de um LLM guardam padrões estatísticos, e padrões são ótimos para reproduzir estilo e estrutura. Fatos específicos, que mudam com o tempo e precisam estar exatos, pedem uma fonte externa que o modelo consulta na hora da resposta. E é exatamente essa a proposta do RAG, que a gente detalha a seguir.

O que é fine-tuning comparado com RAG: a decisão que define seu projeto

RAG, ou Retrieval-Augmented Generation, resolve o problema do conhecimento por outro caminho: em vez de mexer no modelo, ele busca os documentos relevantes numa base externa no momento da pergunta e injeta esses trechos no contexto do prompt. O modelo continua genérico, mas responde com base nos seus dados, atualizados e citáveis. Já publicamos um guia completo sobre o que é RAG e como implementar, então aqui vamos direto ao contraste.

A diferença conceitual cabe numa frase: fine-tuning muda como o modelo responde, RAG muda com base em quê ele responde. São ferramentas para problemas diferentes, e boa parte da confusão do mercado vem de tratá-las como concorrentes diretas. Quando alguém nos pergunta "fine-tuning ou RAG?", nossa primeira resposta costuma ser outra pergunta: o seu problema é de comportamento ou de conhecimento?

Problema de comportamento: "o modelo não segue meu formato", "as respostas não têm o tom da marca", "ele erra a classificação de tickets mesmo com instruções detalhadas". Isso aponta para fine-tuning, depois de esgotar o prompt. Problema de conhecimento: "o modelo não sabe nada sobre meus produtos", "as respostas estão desatualizadas", "preciso que ele cite a política interna correta". Isso aponta para RAG, quase sempre.

E existe um terceiro cenário, cada vez mais comum em 2026: os dois juntos. Um chatbot de atendimento sofisticado pode usar RAG para buscar a resposta certa na base de conhecimento e um modelo com fine-tuning para entregar essa resposta no tom exato da marca, no formato exato do canal. Quem está montando um projeto assim deve começar pelo nosso guia de chatbot com IA para atendimento, porque a arquitetura de recuperação vem antes da customização do modelo.

Quando usar fine-tuning: os casos em que ele ganha

O primeiro caso clássico é consistência de formato e estilo em escala. Se você gera milhares de saídas por dia que precisam seguir uma estrutura rígida, um JSON específico, um padrão de laudo, uma taxonomia de classificação, o fine-tuning entrega uma consistência que prompt nenhum alcança. Modelos customizados erram menos o formato porque o padrão está nos pesos, e você ainda economiza os milhares de tokens de instrução que repetiria em cada chamada.

O segundo caso é destilação: usar um modelo grande e caro para gerar exemplos de alta qualidade e treinar um modelo pequeno e barato para reproduzir aquele comportamento específico. Em 2026, essa é provavelmente a aplicação de fine-tuning com melhor retorno financeiro. Uma tarefa estreita que rodava no GPT-4o pode migrar para um GPT-4o mini com fine-tuning, custando uma fração por chamada e respondendo mais rápido. Para automações de alto volume, como enriquecimento de leads ou moderação de conteúdo, a conta fecha rapidinho. Quem quiser entender onde isso se encaixa numa operação, nosso guia de IA generativa para negócios mapeia os casos de uso por área.

O terceiro caso é vocabulário e convenção de domínio. Áreas como jurídico, saúde e engenharia têm jargões e estruturas de documento que os modelos genéricos até conhecem, mas reproduzem de forma irregular. Um fine-tuning com bons exemplos do domínio deixa a saída consistentemente nativa daquele universo, sem soar como um generalista imitando especialista.

O quarto caso, menos falado, é a redução de latência e custo de prompt. Instruções de sistema com 3 mil tokens, repetidas em cada uma das 100 mil chamadas mensais, somam 300 milhões de tokens só de instrução. O fine-tuning internaliza essas instruções e o prompt encolhe para uma fração disso. Em operações grandes, essa economia paga o projeto de treino em poucas semanas.

O que todos esses casos têm em comum: comportamento estável, tarefa estreita, volume alto. Se o seu caso não tem pelo menos duas dessas três características, desconfie de quem está te vendendo fine-tuning.

Quando RAG é melhor (e por que ele vence na maioria dos projetos)

RAG ganha sempre que a matéria-prima da resposta é conhecimento que muda. Catálogo de produtos, políticas internas, documentação técnica, histórico de tickets, base jurídica, tabela de preços: tudo isso é atualizado toda semana, às vezes todo dia. Com RAG, atualizar o conhecimento do sistema é atualizar um documento na base. Com fine-tuning, seria retreinar o modelo, redistribuir, revalidar. Ninguém sério mantém conhecimento dinâmico dentro de pesos de modelo.

RAG também ganha quando você precisa de rastreabilidade. Um sistema RAG bem construído responde e mostra a fonte: "segundo a política de reembolso, seção 4.2". Isso muda tudo em setores regulados e em qualquer aplicação onde o usuário precisa confiar na resposta. Modelo com fine-tuning responde com convicção, mas sem recibo, e auditar de onde saiu uma afirmação é praticamente impossível.

O terceiro ponto é o custo de entrada. Um RAG funcional exige uma base vetorial, um pipeline de indexação e uma busca decente. Com Supabase e pgvector, que é o backend padrão dos nossos projetos, dá para ter um protótipo honesto no ar em um fim de semana. Já um fine-tuning decente exige centenas de exemplos de qualidade, e montar esse dataset é trabalho manual de gente que entende do domínio. A regra que repetimos: o gargalo do RAG é engenharia, o gargalo do fine-tuning é curadoria de dados. Engenharia escala melhor.

Tem ainda o fator aprisionamento. Um modelo com fine-tuning na OpenAI vive na OpenAI. Se em seis meses o Claude ou o Gemini lançarem um modelo melhor para o seu caso, e em 2026 isso acontece a cada trimestre, como mostra nosso comparativo Claude vs ChatGPT vs Gemini, migrar significa refazer o treino do zero. Uma base RAG é agnóstica: troca o modelo por trás e o conhecimento continua lá, intacto.

Por tudo isso, nossa recomendação padrão para quem está começando com dados próprios é RAG. O fine-tuning entra depois, quando os números do RAG em produção mostrarem um problema de comportamento que prompt não conserta.

Fine-tuning vs RAG vs prompt engineering: o comparativo direto

Antes de qualquer uma das duas técnicas, existe a mais barata de todas: prompt engineering. Um prompt de sistema bem escrito, com exemplos few-shot e formato de saída definido, resolve uma quantidade constrangedora dos casos que chegam até nós pedindo fine-tuning. Nosso guia completo de prompt engineering cobre as técnicas que testamos no dia a dia, e ele é leitura obrigatória antes de gastar um centavo com treino de modelo.

Critério	Prompt engineering	RAG	Fine-tuning
Custo de implementação	Quase zero	Baixo a médio	Médio a alto
Tempo até produção	Horas	Dias	Semanas
Conhecimento atualizável	Limitado ao contexto	Excelente, em tempo real	Ruim, exige retreino
Consistência de formato e tom	Boa	Boa	Excelente
Rastreabilidade das respostas	Baixa	Alta, com citação de fonte	Nenhuma
Custo por chamada	Alto em prompts longos	Médio	Baixo após o treino
Portabilidade entre modelos	Total	Total	Nenhuma
Dados necessários	Alguns exemplos	Seus documentos	Centenas a milhares de pares

A leitura prática da tabela é uma escada. Degrau um: prompt engineering, sempre, porque custa horas e valida se o problema é real. Degrau dois: RAG, quando o modelo precisa de conhecimento que não tem. Degrau três: fine-tuning, quando comportamento e formato continuam inconsistentes mesmo com prompt bom e contexto certo, ou quando a conta de tokens em escala justifica destilar para um modelo menor. Pular degraus é a receita mais comum de projeto de IA caro e frustrado.

Preços e planos: quanto custa fine-tuning em 2026

Na OpenAI, o fine-tuning do GPT-4o mini custa US$ 3,00 por milhão de tokens de treinamento. Um dataset típico de 1.000 exemplos com 500 tokens cada, treinado por 3 épocas, consome 1,5 milhão de tokens: US$ 4,50 de treino. É quase de graça. O detalhe que pega os desavisados é a inferência: o modelo customizado custa US$ 0,30 por milhão de tokens de entrada e US$ 1,20 na saída, o dobro do GPT-4o mini base. Para o GPT-4o cheio, o treino sobe para US$ 25,00 por milhão de tokens e a inferência para US$ 3,75 de entrada e US$ 15,00 de saída por milhão.

No Google, o tuning do Gemini via AI Studio tem uma vantagem agressiva: o treinamento em si sai de graça nos modelos Flash, e a inferência do modelo ajustado custa o mesmo que a do modelo base. Para experimentos e casos de volume médio, é a porta de entrada mais barata do mercado. A Anthropic segue sem fine-tuning aberto via API própria; a customização de Claude Haiku existe pela Amazon Bedrock, voltada a contratos enterprise.

No mundo open source, um QLoRA de Llama 3.1 8B roda numa GPU A100 alugada por US$ 1,50 a US$ 2,50 por hora, e um treino típico leva de 2 a 6 horas: menos de US$ 15 pelo experimento. O custo real aparece depois, em servir o modelo: manter uma GPU de inferência no ar 24 horas por dia custa a partir de uns US$ 300 mensais, o que só se justifica com volume alto ou exigência de privacidade total dos dados.

Do lado do RAG, para comparação: Supabase no plano Pro custa US$ 25 por mês com pgvector incluído, e a conta de embeddings é ridícula, na casa dos centavos por milhão de tokens indexados. É por isso que insistimos: para conhecimento próprio, o RAG quase sempre vence também no bolso.

Em todos os cenários, o item mais caro não aparece em nenhuma tabela de preço: o dataset. Contar 40 a 80 horas de trabalho qualificado para montar, limpar e validar mil exemplos bons é uma estimativa realista. Dataset ruim gera modelo ruim, e retreinar não conserta exemplo mal feito.

7 dicas para decidir entre fine-tuning e RAG

1. Esgote o prompt antes de qualquer treino. Escreva um prompt de sistema sério, com persona, regras, formato de saída e 3 a 5 exemplos few-shot. Se isso resolver 90% dos casos, você acabou de economizar semanas de projeto.

2. Classifique seu problema: comportamento ou conhecimento. Formato, tom e padrão de resposta são problemas de comportamento, território de fine-tuning. Fatos, documentos e dados atualizáveis são problemas de conhecimento, território de RAG. Essa pergunta sozinha resolve 80% das decisões.

3. Nunca use fine-tuning para injetar fatos. O modelo vai aprender o estilo dos seus fatos e continuar inventando o conteúdo deles. Alucinação com sotaque de marca é pior que alucinação genérica, porque engana melhor.

4. Comece o dataset com 100 exemplos, e só depois escale. Treine com uma amostra pequena e meça. Se 100 exemplos bons não movem o ponteiro na direção certa, 10 mil exemplos medianos também não vão mover.

5. Monte um conjunto de avaliação antes de treinar. Separe 50 a 100 casos de teste que o modelo nunca viu e defina o que é resposta boa. Sem isso, você não tem como saber se o fine-tuning melhorou algo ou só mudou o jeito de errar.

6. Considere a arquitetura híbrida em produtos maduros. RAG para buscar o conhecimento certo, modelo com fine-tuning para entregar no formato e tom exatos. É a arquitetura dos melhores assistentes de 2026, mas só chegue nela depois que o RAG sozinho estiver rodando bem.

7. Recalcule a decisão a cada geração de modelos. Modelos base ficam melhores a cada trimestre, e um fine-tuning feito sobre o modelo de ontem pode perder para o prompt simples no modelo de hoje. Trate modelo customizado como ativo depreciável, com data de revisão marcada.

O resumo da nossa experiência: fine-tuning é uma ferramenta de especialização, potente e cada vez mais barata de treinar, mas cara de alimentar e de manter. RAG é uma ferramenta de conhecimento, flexível, auditável e portátil. Prompt engineering é o degrau zero que valida tudo antes. Quem domina os três, e sabe a ordem certa de aplicá-los, constrói produtos de IA que melhoram junto com os modelos em vez de envelhecer com eles.

Na Marfin, essa escada guia todos os nossos projetos com dados próprios, dos chatbots de atendimento às automações de marketing. E se você está montando seu primeiro projeto do tipo, comece pelo degrau mais barato: um prompt bem escrito hoje ensina mais sobre o seu problema do que um mês de preparação de dataset.

Leia também:

TL;DR