Fine-tuning quase nunca é a primeira resposta

Quando um modelo não entrega o resultado esperado, a primeira ideia costuma ser "vamos treinar com nossos dados". Na maior parte das vezes, é a última coisa que deveria ser tentada — e não por preciosismo técnico, mas porque quase sempre existe um caminho mais barato, mais rápido e mais fácil de manter que resolve o mesmo problema.

O engano nasce da intuição errada sobre o que está falhando. "O modelo não sabe fazer isso, então preciso ensinar." Só que "ensinar" tem vários significados, e fine-tuning atende só a um deles. Confundir os casos é o que faz equipes gastarem semanas montando dataset para um problema que se resolvia com três frases a mais no prompt.

A ordem que costuma resolver

Antes de mexer nos pesos do modelo, existe uma escada. Cada degrau é mais barato que o próximo, e você só sobe quando o de baixo comprovadamente não deu conta.

Prompt melhor / instrução clara. A maioria dos problemas é de comunicação, não de capacidade. O modelo consegue fazer a tarefa — só não entendeu qual era a tarefa. Instrução vaga, critério implícito, formato subentendido: tudo isso vira erro que parece incompetência do modelo e é, na verdade, falta de especificação.
Exemplos no prompt (few-shot). Quando descrever o que você quer é difícil, mostrar é mais fácil. Dois a cinco exemplos do par entrada-saída certo dentro do próprio prompt ancoram o comportamento sem treino nenhum. É a diferença entre explicar um formato por escrito e simplesmente colar um caso pronto.
RAG / contexto para o conhecimento que falta. Se o problema é que o modelo não tem uma informação — política interna, catálogo, documentação, dado atualizado —, a resposta é dar essa informação no momento da pergunta, buscando o trecho relevante e injetando no prompt. É o assunto do post sobre RAG aqui do blog: conhecimento vive em documento recuperável, não dentro dos pesos.
Fine-tuning. Só depois de esgotar os três primeiros, e mesmo assim para um conjunto específico de problemas que os anteriores genuinamente não resolvem.

O detalhe importante: os degraus não competem, eles se somam. Um sistema com fine-tuning ainda precisa de bom prompt e, quase sempre, de contexto. Fine-tuning não substitui os outros — ele entra por cima quando eles chegam ao limite.

Para que fine-tuning serve de verdade

Fine-tuning ajusta os pesos do modelo a partir dos seus exemplos. O que isso muda bem é comportamento, não conhecimento:

Formato de saída rígido e consistente. Quando você precisa que toda resposta saia numa estrutura muito específica, sempre, sem escorregar.
Estilo e tom. Uma voz de marca particular, um jeito de escrever que é trabalhoso descrever em instrução mas fácil de demonstrar em centenas de exemplos.
Vocabulário e convenções de domínio. Termos que o modelo erra de forma sistemática, categorias internas que ele não tem como adivinhar, um padrão de classificação próprio da sua operação.
Encurtar prompt gigante. Se você depende de um prompt enorme repetido a cada chamada, fine-tuning pode "internalizar" parte dessas instruções e reduzir o custo por chamada na escala.

O que ele não faz bem é ensinar fatos novos. Fato vive em documento, não em peso de rede neural. Se a informação muda, o modelo treinado não se atualiza sozinho — ele repete com confiança o que aprendeu, mesmo desatualizado. E ele não sabe citar a fonte do que respondeu, porque o conhecimento virou uma média difusa espalhada pelos parâmetros. Para qualquer coisa que precise ser correta, rastreável e atual, contexto ganha de fine-tuning todas as vezes.

Resumindo a régua: se o sistema erra porque não sabe algo, o problema é de contexto. Se erra porque não entendeu o que você quer, é de instrução. Se acerta o conteúdo mas escorrega no jeito — formato, tom, consistência —, aí sim talvez seja caso de treinar.

O custo que ninguém coloca na conta

O treino em si não é a parte cara. A conta real vem depois, e tem três frentes.

Dados. Fine-tuning bom exige exemplos bons: centenas a milhares de pares entrada-saída corretos, revisados por alguém que entende do assunto. Montar e curar esse conjunto é trabalho humano de verdade. E dados ruins produzem um modelo pior que o original — com o agravante de que agora o erro está congelado nos pesos, difícil de rastrear e impossível de corrigir editando um prompt.
Manutenção. Um prompt você muda em segundos. Um modelo treinado é um artefato: versionado, avaliado, implantado. Quando o comportamento desejado muda, não basta reescrever uma frase — é preciso ajustar o dataset e retreinar.
Retreino quando a base muda. Este é o custo mais subestimado. Modelos base evoluem. Quando surge uma versão melhor, quem está no prompt simplesmente troca e colhe o ganho. Quem fez fine-tuning sobre a versão antiga tem uma decisão: ficar preso a um modelo que vai envelhecendo, ou refazer todo o trabalho de treino sobre a base nova. O fine-tuning te acopla a um ponto no tempo, e o campo se move rápido.

Nada disso torna fine-tuning ruim. Torna ele um compromisso de manutenção contínua, não um ajuste pontual. E é exatamente isso que precisa entrar na decisão.

Quando fine-tuning faz sentido

Alguns sinais, e de preferência mais de um ao mesmo tempo:

Você já esgotou o prompt de verdade. Instrução clara, few-shot, contexto no lugar — e ainda sobra um erro consistente, no mesmo tipo de caso, que nenhum desses ajustes elimina.
O padrão é estável. O comportamento que você quer não muda toda semana. Vale congelar algo que vai durar, não uma regra que você ainda está descobrindo.
O volume justifica. O prompt necessário ficou tão longo que o custo por chamada, multiplicado pela escala, passa a pesar mais que o custo de treinar e manter um modelo ajustado.
Você tem dados de qualidade. Exemplos suficientes, corretos e revisados. Sem isso, nada mais na lista importa.

Quando é armadilha

Usar fine-tuning para injetar conhecimento. O caso mais comum e o mais caro. Você quer que o modelo "saiba" seus documentos e vai treinar para isso. Não funciona bem, não atualiza e não cita fonte. É RAG disfarçado de treino.
Pular a escada. Ir direto ao fine-tuning sem ter testado prompt e contexto. Muitas vezes o problema real era trivial, e o dataset caro resolveu o que uma instrução melhor resolveria de graça.
Requisito ainda em movimento. Treinar sobre uma regra que ainda está mudando garante retreino atrás de retreino. Estabilize primeiro, congele depois.
Dados insuficientes ou sujos. Poucos exemplos, ou exemplos inconsistentes, produzem um modelo que erra com confiança — e agora o erro está nos pesos, longe do alcance de um ajuste rápido.

O ponto prático

Fine-tuning é otimização, não conserto. Ele afina um sistema que já funciona; não salva um que está errado pelo motivo errado.

Na prática: comece pela instrução, escrita como se fosse para uma pessoa nova na equipe. Se não bastar, mostre exemplos dentro do prompt. Se faltar conhecimento, traga o contexto por RAG. E meça tudo num conjunto fixo de casos, antes e depois de cada mudança — sem isso você não sabe se melhorou, só sente que melhorou. Só quando esse caminho comprovadamente empaca, e o padrão é estável e vale o custo de manter, aí vale mexer nos pesos. Nessa ordem, fine-tuning deixa de ser a primeira reação e vira o que ele realmente é: o último recurso, para os poucos casos que só ele resolve.