O que é fine tuning? Guia prático e quando NÃO usar

Todo mundo acha que precisa de fine tuning. Quase ninguém precisa.

Essa é a frase que resume 90% das conversas sobre o assunto. O dev bate o olho num problema — o modelo não responde do jeito que ele quer, erra o formato, não sabe o jargão da empresa — e o primeiro instinto é "vou treinar um modelo meu". Na maioria dos casos, isso é resolver com bisturi o que um esparadrapo resolvia.

Este post é a definição direta de o que é fine tuning para quem constrói com LLM, sem enrolação de paper e sem hype de thread do Twitter. E, mais importante que a definição: o critério honesto de quando ele compensa — e quando RAG ou um contexto bem montado resolvem o mesmo problema por uma fração do custo.

TL;DR

O que é: treinar um modelo já pronto com seus próprios exemplos, ajustando os pesos dele para uma tarefa específica.
Para que serve: ensinar comportamento — estilo, formato, tom, consistência numa tarefa. Não serve para ensinar fato.
Quando usar: depois de esgotar prompt e RAG, quando você precisa de comportamento consistente em volume alto.
Custo/acesso: requer dataset rotulado (50+ exemplos bons), pipeline de treino e avaliação, e some inferência mais cara. Não é um botão.
Alternativas antes dele: engenharia de contexto (prompt + few-shot) e RAG.

O que é fine tuning, de verdade

Fine tuning é pegar um modelo que já foi pré-treinado em trilhões de tokens — um Claude, um GPT, um Llama — e continuar treinando ele um pouco mais, com um conjunto de exemplos seus. Tecnicamente, você está ajustando os pesos do modelo: os números internos que definem como ele transforma uma entrada em saída mudam de valor para se aproximar do padrão dos seus exemplos.

É diferente de tudo que acontece em runtime. Quando você escreve um prompt bom ou injeta documentos via RAG, o modelo continua exatamente o mesmo — você só muda o que ele vê antes de responder. No fine tuning, o modelo em si sai diferente. O aprendizado fica gravado no peso, não no prompt.

Na prática moderna, quase ninguém retreina o modelo inteiro. Isso seria caro e desnecessário. O padrão é PEFT (parameter-efficient fine-tuning), e o método mais comum é o LoRA: em vez de mexer em todos os bilhões de parâmetros, você congela os pesos originais e treina umas matrizes pequenas de baixo posto acopladas a cada camada — o famoso ΔW = BA, onde B e A são muito menores que a matriz original (Hu et al., 2021). Resultado: treino mais barato, adapter modular que você pluga e despluga, e nenhuma latência extra na inferência.

O impacto em produto é esse: fine tuning bem-feito te dá um modelo que faz uma coisa específica de forma consistente — classificar ticket no seu esquema, escrever no tom da sua marca, gerar JSON no seu formato — sem você precisar gastar 2 mil tokens de instrução em todo request.

O erro número um: achar que fine tuning ensina fato

Aqui mora a confusão que faz gente queimar dinheiro.

Fine tuning ensina padrão, não conhecimento. Ele mostra ao modelo como fazer uma tarefa repetindo exemplos dela sendo feita certo. Ele não injeta uma base de fatos confiável na cabeça do modelo.

A documentação da OpenAI é explícita: fine tuning serve para quando o modelo "produz resultados inconsistentes, formato errado, tom incorreto ou não segue o raciocínio de forma consistente" — e não para ensinar conhecimento novo, que é trabalho de RAG (Optimizing LLM Accuracy, OpenAI). Traduzindo o clichê que já virou regra na área: fine tuning teaches patterns, not facts.

Duas consequências que doem em produção:

Fine tuning não corrige alucinação. Se o modelo inventa dado, treinar ele com mais exemplos não conserta — pode até piorar, porque ele aprende a inventar com mais confiança e no formato certo.
Fine tuning envelhece. Você fine-tunou com os dados de hoje. Amanhã a política mudou, o produto mudou, o preço mudou. Um sistema de RAG você atualiza jogando um documento novo no índice. Um modelo fine-tunado você retreina.

Se o seu problema é o modelo não saber algo, fine tuning é a ferramenta errada. Se o problema é o modelo não se comportar do jeito certo, aí ele entra na conversa.

Fine tuning vs RAG vs contexto: o critério honesto

Existe uma ordem. Ela não é dogma, é economia: você sobe de degrau só quando o de baixo não resolve. Se você quer o mapa de decisão completo, com os critérios de volatilidade do dado, custo e rastreabilidade, já escrevi ele em quando usar RAG, fine-tuning ou contexto — aqui vai o resumo aplicado ao fine tuning.

Degrau 1 — Engenharia de contexto (prompt + few-shot). Comece aqui, sempre. Modelo base bom com instrução clara e três a cinco exemplos no prompt resolve uma fatia enorme dos casos que se fine-tunava dois anos atrás. Classificação, extração, saída estruturada, tom — muita coisa fecha só com few-shot. É o mais rápido e o mais barato de iterar: você muda o texto e testa em segundos.

Degrau 2 — RAG. Suba quando o problema é conhecimento: o modelo precisa de dado que ele não tem, dado proprietário, ou dado que muda. RAG conecta a resposta a uma fonte de verdade que você controla e atualiza sem retreinar nada. É o certo para base de conhecimento, documentação, dados de cliente, qualquer coisa que precise estar correta e atual.

Degrau 3 — Fine tuning. Suba quando o problema é comportamento e você já provou que contexto e RAG não bastam: você precisa de consistência absoluta numa tarefa, em volume alto, e o custo de repetir instrução gigante em todo request começou a pesar. Fine tuning aqui compensa porque troca tokens de prompt (que você paga sempre) por comportamento embutido no peso (que você paga uma vez, no treino).

Um dado que dá dimensão do quão raramente o degrau 3 é o primeiro passo certo: relatos de quem roda deployments de Claude em empresa apontam que, em anos de projetos, prompt e RAG bem-feitos resolveram quase tudo, e o padrão em domínios críticos — jurídico, saúde, finanças — acabou sendo RAG + fine tuning juntos, não fine tuning sozinho (análise sobre Claude 4). Os dois resolvem problemas diferentes: RAG traz o fato, fine tuning fixa o comportamento. Empilhados, cobrem a fraqueza um do outro.

O critério em uma frase: o modelo precisa saber mais? RAG. O modelo precisa se comportar melhor? Fine tuning. O modelo só precisa de instrução melhor? Contexto — e é aqui que a maioria para.

Como um fine tuning funciona na prática

Se você chegou no degrau 3 com razão, o fluxo é esse:

1. O dataset é 90% do trabalho

Fine tuning é tão bom quanto os exemplos que você dá. A OpenAI recomenda qualidade acima de quantidade: comece com 50+ exemplos bem-feitos, avalie, e só aumente o dataset se ainda não bateu a acurácia que você precisa (OpenAI). O formato é sempre par entrada → saída ideal:

{"messages": [{"role": "system", "content": "Classifique o ticket."}, {"role": "user", "content": "Não consigo logar desde ontem"}, {"role": "assistant", "content": "{\"categoria\": \"acesso\", \"prioridade\": \"alta\"}"}]}
{"messages": [{"role": "system", "content": "Classifique o ticket."}, {"role": "user", "content": "Como troco meu plano?"}, {"role": "assistant", "content": "{\"categoria\": \"billing\", \"prioridade\": \"baixa\"}"}]}

Cada linha é uma demonstração do comportamento certo. Lixo entra, lixo sai — e no fine tuning o lixo fica gravado no peso.

2. O treino em si é quase commodity

Com o dataset pronto, disparar o job é a parte fácil. Numa API gerenciada é literalmente um upload e uma chamada:

from openai import OpenAI
client = OpenAI()

file = client.files.create(file=open("dataset.jsonl", "rb"), purpose="fine-tune")
job = client.fine_tuning.jobs.create(
    training_file=file.id,
    model="gpt-4.1-mini-2025-04-14",
)

Se você roda modelo aberto (Llama, Mistral) na sua infra, o LoRA que citei lá em cima é o caminho — bibliotecas como peft da Hugging Face fazem o trabalho pesado, e você treina um adapter numa GPU só.

3. Avaliação, senão você está no escuro

Sem um conjunto de avaliação, você não sabe se o fine tuning ajudou ou piorou. Separe exemplos que o modelo não viu no treino e meça acurácia antes e depois. Fine tuning que não é medido é fé, não engenharia.

Quando NÃO usar fine tuning

O título prometeu isso, então aqui está a lista de red flags. Se você marcar qualquer uma, pare e volte um degrau:

"Quero que o modelo saiba sobre os nossos produtos." Isso é conhecimento. É RAG.
"O modelo tá alucinando, vou fine-tunar pra parar." Não para. Alucinação se combate com RAG, com grounding e com guardrail — não com peso.
"Ainda não testei direito o prompt." Então você não tem o direito de fine-tunar. 60% a 70% do que se fine-tunava é hoje resolvido só com prompt em modelo bom.
"Meus dados mudam toda semana." Fine tuning vira dívida técnica: cada mudança pede um retreino. RAG absorve mudança de graça.
"Tenho 12 exemplos." Pouco e ruim. Junte dado de qualidade primeiro, ou aceite que few-shot com esses 12 no prompt provavelmente entrega mais.

A regra de bolso: fine tuning é otimização, não fundação. Você fine-tuna para deixar mais barato e mais consistente algo que já funciona com prompt e RAG. Se ainda não funciona, fine tuning só vai gravar o seu problema no peso do modelo.

FAQ rápido

Fine tuning deixa o modelo mais inteligente? Não. Deixa ele mais consistente numa tarefa específica. Ele não fica melhor em raciocínio geral — na verdade, fine tuning muito agressivo pode até piorar capacidades gerais (o chamado esquecimento catastrófico). É especialização, não elevação de QI.

Quanto custa? Varia com o modelo e o volume, mas o custo real não é o treino — é o dataset (horas de curadoria) e a inferência, que costuma sair mais cara num modelo fine-tunado do que no base. Some a isso o custo de manter: cada mudança de requisito pede retreino.

Fine tuning ou RAG para o chatbot da minha empresa? Quase certamente RAG. Chatbot precisa saber fatos sobre a sua empresa e esses fatos mudam. Fine tuning entraria só depois, e só para ajustar o jeito de responder, se o prompt não der conta.

Dá pra usar os dois juntos? Dá, e em domínio crítico é o padrão: RAG traz o fato atualizado, fine tuning garante o comportamento consistente. Mas empilhar os dois é o último estágio, não o primeiro — só faz sentido quando cada um sozinho já não fecha. Já destrinchei essa arquitetura híbrida, com benchmark, em RAG + fine-tuning juntos.

Conclusão

Fine tuning não é o boss final da engenharia de IA. É uma ferramenta de otimização com um uso estreito e específico: fixar comportamento consistente numa tarefa, depois que prompt e RAG já fizeram o trabalho pesado. Ensinar fato, corrigir alucinação, dar conhecimento novo — nada disso é trabalho dele.

Saber em qual degrau você está — contexto, RAG ou fine tuning — é o que separa quem lê sobre IA de quem constrói com IA. E esse tipo de critério não sai de tutorial: sai de errar em produção com alguém do lado revisando a decisão antes de você queimar uma semana treinando um modelo que não precisava existir. É exatamente esse julgamento que a gente treina toda semana, ao vivo, no Clã Beer and Code — a maior comunidade de engenharia de IA do Brasil, com a turma construindo agente em produção junto.

Da próxima vez que o instinto disser "vou fine-tunar", faz a pergunta antes: o modelo precisa saber mais, ou precisa se comportar melhor? A resposta quase sempre te manda de volta pro prompt — e é aí que estava a economia.