Fine-tuning de LLMs: quando e como ajustar um modelo

Existe uma ordem natural para resolver problemas com IA, e fine-tuning quase nunca é o primeiro passo. Ajustar um modelo nos seus próprios dados é poderoso, mas também é a opção mais cara e mais fácil de errar. Este guia esclarece quando o ajuste fino faz sentido, como ele se diferencia de prompting e RAG, quais técnicas existem e o que envolve fazê-lo bem na prática — sem queimar orçamento de computação com um experimento que três linhas de prompt resolveriam.

O que é fine-tuning

Fine-tuning é o processo de continuar o treinamento de um modelo já pré-treinado usando um conjunto de exemplos seus, ajustando seus pesos para que ele se comporte de uma forma mais alinhada à sua tarefa. Em vez de partir do zero — algo inviável em custo —, você pega um LLM (Large Language Model) que já aprendeu linguagem e o especializa.

Para entender onde o fine-tuning se encaixa, ajuda lembrar as fases pelas quais um modelo passa, detalhadas em Como os LLMs são treinados: pré-treino, fine-tuning e RLHF:

1. Pré-treino: o modelo aprende linguagem geral a partir de enormes volumes de texto.
2. Fine-tuning supervisionado: ele é ajustado em pares de entrada/saída de qualidade para uma tarefa ou estilo.
3. Alinhamento (RLHF): ele é refinado com feedback humano para ser útil e seguro.

O fine-tuning que você fará como dev é tipicamente o segundo tipo: pegar um modelo aberto ou via API e ajustá-lo a partir dos seus exemplos. É importante separar bem os conceitos, porque "treinar um modelo" virou um termo guarda-chuva que esconde decisões muito diferentes em custo e risco.

Pré-treino versus fine-tuning: a diferença de magnitude

Vale dimensionar a diferença. O pré-treino de um modelo de fronteira consome trilhões de tokens e milhões de dólares em computação — é o que cria a competência linguística bruta. O fine-tuning opera sobre essa base já formada e costuma usar de algumas centenas a alguns milhares de exemplos, rodando em horas e custando uma fração ínfima. Você não está ensinando o modelo a falar; está reorientando um comportamento que ele já é capaz de exibir. Essa distinção explica por que fine-tuning é ótimo para moldar forma e fraco para inserir fatos novos: a forma é uma tendência estatística que poucos exemplos conseguem reforçar, enquanto fatos são informações pontuais que se diluem nos bilhões de pesos.

As três alavancas: prompting, RAG e fine-tuning

Antes de pensar em treinar qualquer coisa, é essencial entender que existem três formas distintas de moldar o comportamento de um modelo, e elas resolvem problemas diferentes.

• Prompting (engenharia de prompt): você ajusta as instruções. Rápido, barato, iterável em segundos. Resolve a maioria dos casos.
• RAG (Retrieval-Augmented Generation): você injeta conhecimento externo no contexto em tempo de execução. Ideal quando o problema é falta de informação atualizada ou específica. Veja O que é RAG (Retrieval-Augmented Generation)?.
• Fine-tuning: você altera os pesos do modelo. Ideal quando o problema é comportamento, formato ou estilo consistentes que prompting não consegue garantir.

A confusão mais comum no mercado é tentar resolver com fine-tuning um problema que é de conhecimento — e isso quase sempre falha.

Uma tabela mental de decisão

Para fixar, pense em três perguntas:

• "O modelo não sabe uma informação que muda com frequência?" → o problema é conhecimento dinâmico → RAG.
• "O modelo sabe o que precisa, mas responde de um jeito que eu não controlo?" → o problema é forma → fine-tuning.
• "Eu ainda não tentei descrever bem o que quero?" → o problema é instrução → prompting (comece sempre aqui).

Essas alavancas não são mutuamente exclusivas. Sistemas maduros frequentemente combinam um modelo ajustado para o tom e o formato com RAG para trazer conhecimento fresco, tudo orquestrado por um bom prompt de sistema.

O erro clássico: fine-tuning não ensina fatos novos de forma confiável

Uma intuição errada e cara: "vou fazer fine-tuning para o modelo saber sobre a minha empresa". O problema é que fine-tuning molda comportamento muito melhor do que injeta conhecimento factual recuperável. Fatos enfiados nos pesos por ajuste fino tendem a sair distorcidos, desatualizam rápido e aumentam o risco de invenções — o que conecta diretamente com o tema de O que é alucinação em IA e como reduzi-la.

A regra prática que economiza tempo e dinheiro:

• Problema de conhecimento ("o modelo não sabe X") → RAG.
• Problema de comportamento ("o modelo não responde do jeito X") → fine-tuning.

Quando você precisa que o modelo conheça sua documentação, seus produtos ou dados que mudam, RAG é a resposta. Fine-tuning entra quando o conhecimento já está coberto, mas o jeito de responder não está.

Há ainda um efeito colateral perigoso de tentar "decorar fatos" por fine-tuning: o esquecimento catastrófico. Ao empurrar com força um conjunto estreito de exemplos, o modelo pode degradar competências gerais que tinha antes. Você ganha uma resposta decorada e perde robustez em tudo o que está fora daquele recorte.

Quando o fine-tuning realmente vale a pena

Há cenários em que ajustar o modelo é a escolha certa e às vezes a única que funciona bem:

• Formato de saída rígido e consistente. Você precisa de JSON, um schema específico ou uma estrutura que prompting respeita "quase sempre", mas você precisa de "sempre".
• Tom e estilo de marca. Um modelo que escreve sempre na voz da sua empresa, sem repetir instruções gigantes a cada chamada.
• Tarefas especializadas e repetitivas. Classificação de tickets, extração de campos, etiquetagem — onde você tem muitos exemplos rotulados.
• Redução de custo e latência. Um modelo menor, ajustado para uma tarefa, pode igualar um modelo grande com prompt enorme — gastando menos tokens e respondendo mais rápido.
• Conhecimento muito implícito. Padrões difíceis de descrever em palavras, mas fáceis de demonstrar com muitos exemplos.

Repare no padrão: fine-tuning brilha quando você tem exemplos do comportamento desejado e precisa de consistência.

O argumento econômico que costuma ser decisivo

Em produção, o motivo que mais justifica fine-tuning não é qualidade, é custo unitário. Imagine uma tarefa de extração que hoje você resolve com um modelo grande e um prompt de 1.500 tokens cheio de exemplos few-shot. A cada chamada você paga por esses 1.500 tokens de entrada. Ajustando um modelo menor com esses mesmos exemplos "absorvidos" nos pesos, o prompt encolhe para algumas dezenas de tokens. Em volume — milhões de chamadas por mês — a diferença de tokens e a queda de latência pagam o esforço de treino rapidamente. Esse cálculo de custo por chamada é, na prática, o que move a maioria dos projetos de ajuste fino bem-sucedidos.

A regra de ouro: comece pelo mais simples

A sequência recomendada, do mais barato ao mais caro, é quase sempre esta:

1. Tente prompting. Refine instruções, dê exemplos no prompt (few-shot), estruture bem o pedido. Resolva o máximo aqui.
2. Adicione RAG se o problema for falta de conhecimento.
3. Considere fine-tuning só quando prompting e RAG não entregarem a consistência necessária.

Pular etapas custa caro. Fine-tuning prematuro consome tempo de engenharia, exige dados, e muitas vezes resolve algo que três linhas de prompt resolveriam. A própria linha de pesquisa de alinhamento de Ouyang, Wu, Jiang, Almeida et al. (2022) mostra como dados de demonstração de qualidade — e não volume bruto — são o que faz o ajuste valer a pena.

As técnicas: full fine-tuning, LoRA e QLoRA

Decidido que faz sentido ajustar, a próxima escolha é como ajustar. Existem três abordagens principais, em ordem crescente de eficiência.

Full fine-tuning. Você atualiza todos os pesos do modelo. Entrega o máximo de capacidade de adaptação, mas exige memória para guardar pesos, gradientes e estados do otimizador — frequentemente várias vezes o tamanho do modelo. Para modelos grandes, isso significa clusters caros. Raramente é a primeira opção para um time pequeno.

LoRA (Low-Rank Adaptation). Em vez de mexer nos pesos originais, você congela o modelo e treina pequenas matrizes de baixo posto que se somam às camadas. Hu, Shen, Wallis, Allen-Zhu, Li, Wang, Wang e Chen (2022) mostraram que dá para obter qualidade comparável treinando uma fração mínima dos pesos. O resultado é um "adaptador" leve — alguns megabytes — que você carrega sobre o modelo base. Isso permite manter vários adaptadores para tarefas diferentes sobre o mesmo modelo.

QLoRA. Combina LoRA com quantização do modelo base (por exemplo, para 4 bits), reduzindo drasticamente a memória necessária. Na prática, viabiliza ajustar modelos de bilhões de parâmetros em uma única GPU de consumo. É a porta de entrada mais acessível para experimentar fine-tuning sem infraestrutura cara.

A escolha entre elas é um trade-off de capacidade versus custo. Para a grande maioria dos casos de comportamento e formato, LoRA ou QLoRA entregam resultado equivalente ao full fine-tuning a uma fração do custo — por isso dominam a prática atual.

Como conduzir um fine-tuning na prática

O processo tem etapas bem definidas.

1. Montar o conjunto de dados. Esta é a parte que decide tudo. Você precisa de exemplos no formato de pares entrada → saída ideal. Qualidade supera quantidade: algumas centenas de exemplos excelentes batem milhares de exemplos ruidosos.

{"messages": [
  {"role": "user", "content": "Resuma este ticket: cliente não consegue logar após troca de senha."},
  {"role": "assistant", "content": "Categoria: Acesso | Severidade: Alta | Resumo: Falha de login pós-reset de senha."}
]}

Garanta consistência nos rótulos: se metade dos exemplos usa "Severidade: Alta" e a outra "severidade alta", você ensina ambiguidade. Inclua também a diversidade real do problema — casos de borda, entradas curtas e longas, formatos inesperados — para o modelo generalizar em vez de decorar o caminho fácil.

2. Separar treino e validação. Reserve uma parte dos dados para avaliar, nunca avalie nos mesmos exemplos do treino. Uma divisão comum é reservar de 10% a 20% para validação, garantindo que nenhum exemplo "vaze" entre os conjuntos.

3. Escolher a técnica e os hiperparâmetros. Como vimos, na prática a maioria usa métodos eficientes como o LoRA, que ajustam pouquíssimos parâmetros e cabem em hardware modesto. Dois hiperparâmetros merecem atenção:

• Épocas (epochs): quantas vezes o modelo passa por todo o dataset. Poucas épocas podem subajustar; muitas levam a memorização. Começar com 1 a 3 e observar é uma boa regra.
• Taxa de aprendizado (learning rate): controla o tamanho de cada ajuste. Alta demais desestabiliza; baixa demais não aprende. Comece pelos valores recomendados da ferramenta antes de otimizar.

4. Treinar e monitorar. Acompanhe a perda (loss) de treino e validação. Se a validação começa a piorar enquanto o treino melhora, você está superajustando (overfitting) — o modelo decorou os exemplos em vez de generalizar.

Época 1: loss_treino=0.84  loss_val=0.81   (saudável: ambas caindo)
Época 2: loss_treino=0.52  loss_val=0.55   (ainda ok)
Época 3: loss_treino=0.31  loss_val=0.63   (alerta: val subindo → overfitting)

No exemplo acima, a terceira época já piora a validação: o ponto de parar foi a época 2.

5. Avaliar de verdade. Loss baixa não significa modelo bom. É preciso medir com um conjunto de avaliação que represente o uso real, tema de Como avaliar aplicações de LLM (LLM evals). Compare sempre o modelo ajustado contra uma linha de base — o modelo original com um bom prompt. Se o ganho for marginal, talvez prompting já bastasse.

Os custos e armadilhas que ninguém avisa

Fine-tuning tem custos além da conta de computação:

• Curadoria de dados é trabalho pesado. Montar e limpar exemplos de qualidade costuma ser o maior esforço do projeto.
• Modelos ajustados envelhecem. Quando você troca o modelo base por uma versão melhor, seu ajuste pode precisar ser refeito.
• Overfitting é traiçoeiro. Com poucos dados, o modelo memoriza em vez de aprender o padrão.
• Manutenção contínua. Cada novo comportamento desejado pode exigir novos dados e novo treino.
• Perda de generalidade. Especializar demais pode degradar o desempenho do modelo em tarefas fora do escopo do ajuste.
• Risco de vazamento de dados. Se seu dataset contém informação sensível, ela pode ser exposta em respostas. Anonimize antes de treinar.

Por isso a recomendação se repete: ajuste fino é um compromisso de longo prazo, não um experimento de fim de tarde.

Um fluxo de trabalho de ponta a ponta

Para amarrar tudo, vale ver como um projeto real de ajuste fino costuma se desenrolar, do problema à produção.

Passo 1 — Defina o comportamento-alvo em uma frase. Antes de qualquer dado, escreva o que você quer: "extrair categoria, severidade e resumo de tickets, sempre no formato Categoria: X | Severidade: Y | Resumo: Z". Se você não consegue descrever o alvo com precisão, ainda não está pronto para treinar.

Passo 2 — Construa a linha de base com prompting. Tente resolver com um bom prompt e exemplos few-shot. Meça a taxa de acerto. Esse número é o que o fine-tuning precisa superar para justificar o esforço.

Passo 3 — Colete e rotule. Reúna entradas reais e produza a saída ideal para cada uma. Onde possível, aproveite os próprios acertos da linha de base (revisados por humano) como ponto de partida — é mais rápido corrigir do que escrever do zero.

Passo 4 — Limpe e padronize. Uniformize rótulos, remova duplicatas e exemplos ambíguos, e separe validação. Esta etapa, tediosa, é a que mais impacta o resultado.

Passo 5 — Treine com LoRA/QLoRA. Comece com poucas épocas e os hiperparâmetros padrão. Não otimize cedo demais.

Passo 6 — Avalie contra a linha de base. Use o conjunto de validação e métricas que reflitam o uso real. Se o ganho não for claro, investigue os dados antes de mexer no treino.

Passo 7 — Implante e monitore. Em produção, acompanhe a qualidade ao longo do tempo. Distribuições de entrada mudam (data drift), e um modelo ótimo hoje pode degradar amanhã, exigindo novo ciclo de dados e treino.

Linha de base (prompt few-shot):     78% de acerto
Modelo ajustado (LoRA, 2 épocas):    93% de acerto, prompt 10x menor
→ ganho de qualidade + queda de custo por chamada = ajuste justificado

Esse fluxo deixa explícito por que o fine-tuning é um compromisso contínuo: ele tem um começo claro, mas não um fim — é um ciclo de manutenção.

Sinais de que você ajustou cedo demais

Alguns sintomas indicam que o fine-tuning foi prematuro e que prompting ou RAG resolveriam melhor:

• O ganho sobre a linha de base com prompt é pequeno (poucos pontos percentuais).
• Você precisa retreinar a cada pequena mudança de requisito.
• As falhas do modelo são de conhecimento (informação errada ou desatualizada), não de forma — sinal claro de que o caso é de RAG.
• O dataset tem menos de algumas dezenas de exemplos realmente bons — pouco para treinar, suficiente para few-shot.

Reconhecer esses sinais cedo economiza semanas de trabalho mal direcionado.

Perguntas frequentes

De quantos exemplos eu preciso? Não há número mágico, mas para tarefas de formato e estilo, algumas centenas de exemplos de alta qualidade já costumam mostrar efeito. Para tarefas mais complexas, alguns milhares. Comece pequeno, avalie e só aumente se a curva de qualidade ainda estiver subindo.

Fine-tuning substitui o RAG? Não. Eles resolvem problemas diferentes e frequentemente convivem: o ajuste cuida da forma, o RAG traz o conhecimento atualizado.

Posso ajustar um modelo fechado via API? Sim, vários provedores oferecem fine-tuning gerenciado: você envia o dataset e recebe um modelo customizado. É mais simples, mas menos flexível e mais opaco que ajustar um modelo aberto com LoRA por conta própria.

Quanto tempo demora? A parte de treino, com LoRA/QLoRA, costuma levar de minutos a algumas horas. O gargalo real quase sempre é a preparação dos dados, não o treino em si.

Conclusão

Fine-tuning é uma ferramenta legítima e poderosa, mas é a última alavanca, não a primeira. Ele molda comportamento, formato e estilo com uma consistência que prompting sozinho não alcança — e é a escolha errada quando o problema real é falta de conhecimento, caso em que RAG resolve melhor e mais barato. A disciplina vencedora é a ordem: esgote prompting, adicione RAG quando necessário e só então considere treinar, sempre apoiado em dados de qualidade, técnicas eficientes como LoRA e QLoRA, e avaliação séria contra uma linha de base. Quem respeita essa sequência gasta menos, erra menos e chega a sistemas mais robustos.

Referências

• Hu, E., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., Chen, W. (2022). LoRA: Low-Rank Adaptation of Large Language Models. ICLR.
• Ouyang, L., Wu, J., Jiang, X., Almeida, D., et al. (2022). Training Language Models to Follow Instructions with Human Feedback. NeurIPS.
• Dettmers, T., Pagnoni, A., Holtzman, A., & Zettlemoyer, L. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS.