Fine-tuning de LLMs: o que muda em 2026

O fine-tuning de modelos de linguagem deixou de ser um ritual de laboratório para se tornar mais uma peça do stack de produto. O que há dois anos exigia GPUs dedicadas e semanas de trabalho, hoje se resolve com técnicas de baixo rank, dados sintéticos e APIs gerenciadas. Mas o panorama mudou tanto que muitas receitas que circulam continuam ancoradas em práticas já obsoletas. Esta revisão se concentra no que está movimentando o terreno agora mesmo, sem prometer milagres.

O que mudou no ciclo de ajuste fino

O fluxo clássico —coletar pares instrução-resposta, treinar todos os pesos e avaliar a olho— se fragmentou. As equipes que trabalham com modelos abertos adotaram variantes que reduzem custo e risco:

• LoRA e seus derivados (QLoRA, DoRA): treina-se uma fração mínima de parâmetros e mantém-se o modelo base congelado. A documentação oficial das principais bibliotecas de treinamento já os apresenta como a opção padrão para ajustes com menos de um milhão de exemplos.
• Alinhamento preferencial: em vez de imitar respostas, otimiza-se com pares de preferência (DPO e variantes). Segundo estudos do setor, essa via reduz o número de exemplos necessários em relação ao RLHF tradicional e evita treinar um modelo de recompensa separado.
• Destilação a partir de modelos grandes: gerar dados com um modelo maior e ajustar um menor tornou-se uma prática comum. O detalhe importante: a qualidade do professor marca o teto do aluno, e os dados sintéticos sem filtro carregam vieses e alucinações.

Um fluxo realista, passo a passo, com as armadilhas sinalizadas

1. Definir o comportamento alvo antes de tocar nos dados

O erro mais repetido que vejo em equipes que começam: lançar o treinamento sem uma especificação escrita do que o modelo deve fazer e, sobretudo, do que não deve fazer. Sem esse contrato, a avaliação posterior é interpretação livre. Convém redigir entre 10 e 20 casos de uso com exemplos de entrada e saída esperada, incluindo casos limite (pedidos ambíguos, fora de domínio, tentativas de manipulação).

2. Curar o conjunto de dados com mais rigor do que entusiasmo

A proporção habitual em projetos que funcionam gira em torno de algumas centenas a alguns milhares de exemplos bem rotulados. Mais volume com ruído piora o resultado. Três verificações que costumam ser ignoradas:

• Deduplicação semântica: respostas quase idênticas com ligeiras variações inflam o conjunto e enviesam o ajuste.
• Consistência de formato: se 80% das respostas usa um estilo e 20% usa outro, o modelo aprende ambos e oscila.
• Revisão de vieses de anotação: quem rotula deixa marca. Dois anotadores distintos produzem distribuições distintas mesmo seguindo o mesmo guia.

3. Escolher base e método conforme o orçamento real

Nem tudo exige um modelo de 70B. Para tarefas de classificação, extração de entidades ou respostas com formato fixo, um modelo de 7-8B ajustado com QLoRA costuma bastar e é servido em uma única GPU. Para raciocínio complexo, o ajuste fino raramente compensa frente a um modelo maior com bom prompting; aí o custo de servir o modelo supera o benefício.

Um detalhe prático que aparece na documentação de várias plataformas: se o objetivo é ensinar conhecimento novo (normativa interna, catálogo de produto), o ajuste fino é uma ferramenta medíocre. Para isso funciona melhor a recuperação aumentada. O fine-tuning brilha quando se quer mudar a forma de responder: tom, formato, política de recusa, estrutura de saída.

4. Treinar com validação separada desde o primeiro minuto

Reservar entre 10% e 20% dos dados para validação não é opcional. O sobreajuste em modelos pequenos é rápido e silencioso: a perda de treinamento baixa enquanto as respostas se tornam rígidas e repetitivas. Detectar isso requer olhar métricas de geração, não apenas a perda.

5. Avaliar com rubricas, não com impressões

É aqui que mais projetos naufragam. Uma avaliação honesta combina:

• Testes automáticos de formato e restrições (respeita o esquema JSON?, cita a fonte?, recusa o que deve recusar?).
• Avaliação humana cega sobre uma amostra pequena, comparando modelo base e ajustado com o mesmo prompt.
• Um conjunto de regressão que não muda entre iterações, para medir deriva.

Segundo a documentação oficial de vários provedores de avaliação, as métricas automáticas do tipo BLEU ou ROUGE correlacionam mal com a utilidade percebida em tarefas abertas. Servem para formato, não para qualidade.

O caso que quase ninguém conta: o ajuste que piorou o produto

Uma equipe ajustou um modelo de 8B para que respondesse a consultas de suporte com um tom muito controlado. Os resultados no conjunto de validação eram excelentes. Em produção, o modelo começou a recusar perguntas legítimas que se pareciam superficialmente com as que haviam sido marcadas como fora de escopo. O problema não era o treinamento: era que o conjunto de dados incluía muitos exemplos de recusa e muito poucos de perguntas ambíguas que sim deveriam ser respondidas. A lição: a distribuição do conjunto de dados define o comportamento tanto quanto o conteúdo. Um ajuste fino não ensina nuances que não estão representadas nos dados.

Tendências que estão redefinindo o terreno

Modelos pequenos especializados frente a monolitos

A curva de custo de inferência empurra para modelos de 3-8B ajustados para uma tarefa concreta. Vários provedores de infraestrutura já oferecem implantações de baixo rank com latência competitiva. O detalhe: a especialização tem um teto. Um modelo pequeno ajustado para atendimento ao cliente não se transforma em um assistente geral por muito que se treine.

Ajuste com dados sintéticos filtrados

Gerar dados com um modelo maior e filtrar por qualidade antes de treinar é hoje uma prática difundida. O risco conhecido: os modelos treinados sobre dados sintéticos sem verificação tendem a amplificar erros do gerador. A recomendação que aparece em fóruns técnicos e documentação de bibliotecas é misturar dados reais com sintéticos e manter uma auditoria manual sobre uma amostra.

Avaliação como serviço e rastreabilidade

A pressão regulatória em alguns setores tem impulsionado a documentar o processo de ajuste: quais dados, qual método, qual avaliação, quais limitações conhecidas. Isso não é burocracia: é o que permite decidir quando retirar um modelo ajustado porque o comportamento derivou.

O que o fine-tuning não resolve

Convém dizer sem rodeios. O ajuste fino não corrige um problema de dados, não substitui uma boa engenharia de prompts em tarefas simples e não garante que o modelo deixe de alucinar. Também não é a via para manter conhecimento atualizado: cada mudança de política interna exigiria retreinar, algo que a recuperação aumentada evita. E em modelos muito grandes, o custo de servir um ajuste próprio pode superar o de usar uma API gerenciada com prompting cuidadoso.

A decisão sensata passa por uma pergunta prévia: preciso mudar como o modelo responde ou preciso que ele saiba algo que não sabe? A primeira pergunta justifica o ajuste. A segunda, quase nunca.