O ruído em torno do fine-tuning
Poucas técnicas de inteligência artificial acumularam tantas expectativas desproporcionadas como o ajuste fino de modelos de linguagem. Ele é frequentemente apresentado como uma varinha mágica que transforma um modelo genérico em um assistente especialista apenas com o upload de um CSV de exemplos. A realidade é bem mais prosaica: o fine-tuning é uma ferramenta cirúrgica com um custo real, limitações claras e, em muitos casos, alternativas mais baratas que funcionam melhor.
Este artigo não é um tutorial de comandos, mas um contraste entre o que se diz nos fóruns e o que acontece quando o processo é executado com dados reais. Se você procura uma receita infalível, não vai encontrá-la aqui. Se quer saber quando vale a pena e quando você está jogando dinheiro fora, continue lendo.
Mito 1: «Com 100 exemplos você já tem um modelo especialista»
É provavelmente a afirmação mais repetida em tópicos de discussão. A documentação oficial dos principais provedores de modelos ajustáveis costuma recomendar conjuntos de dados que vão de várias centenas a milhares de exemplos de alta qualidade, dependendo da complexidade da tarefa. Cem exemplos podem funcionar para uma classificação binária muito específica, mas não para um assistente que precise raciocinar sobre normas internas.
Há um detalhe que quase nunca é mencionado: a qualidade pesa mais que a quantidade, mas não de forma linear. Um dataset de 500 exemplos revisados por uma pessoa criteriosa pode superar um de 5.000 gerados automaticamente com o próprio modelo. O fenômeno é conhecido como model collapse quando se treina de forma iterativa com dados sintéticos sem filtro humano.
Um caso concreto que ilustra o problema
Em um projeto de classificação de tickets de suporte, uma equipe gerou 3.000 exemplos rotulados com um modelo grande e ajustou um modelo pequeno. A precisão inicial parecia excelente na validação, mas ao implantá-lo em produção as categorias ambíguas (reclamações que misturavam faturamento e suporte técnico) se degradaram. A causa: o rotulador automático herdou seus próprios vieses e o modelo ajustado aprendeu a imitar esses erros com grande confiança. A solução não foi mais dados, mas revisar manualmente 200 casos ambíguos e adicionar regras explícitas no prompt do sistema.
Mito 2: «O fine-tuning substitui o RAG»
Essa confusão aparece constantemente. São técnicas distintas que resolvem problemas distintos:
- Fine-tuning: modifica o comportamento do modelo (estilo, formato, tom, critérios de decisão). É útil quando você quer que o modelo responda sempre de uma forma específica.
- RAG (Retrieval-Augmented Generation): injeta conhecimento externo no momento da inferência. É útil quando a informação muda com frequência ou é extensa demais para caber no treinamento.
Se o seu problema é que o modelo não conhece seu catálogo de produtos atualizado toda semana, o fine-tuning é uma má escolha: você teria que retreinar toda vez. Se o seu problema é que o modelo responde com um tom informal demais para atendimento ao cliente, o RAG não vai resolver. Segundo a documentação oficial de plataformas como OpenAI ou Anthropic, a recomendação habitual é começar por prompting avançado, depois RAG, e só então considerar o fine-tuning.
Mito 3: «É barato e rápido»
O custo visível do treinamento caiu, mas o custo total não. Há três itens que costumam ser ignorados:
- Preparação dos dados: limpeza, deduplicação, revisão de rótulos e formato. Na prática, consome mais tempo que o próprio treinamento.
- Avaliação: você precisa de um conjunto de validação independente e métricas que reflitam o uso real. Sem isso, você está voando às cegas.
- Manutenção: sempre que o domínio muda (nova norma, novo produto, nova política), o modelo ajustado pode ficar desatualizado e é preciso repetir o ciclo.
Em muitos casos, um bom prompt com exemplos (few-shot) e uma temperatura baixa oferece 80% do benefício com 5% do esforço. O fine-tuning se justifica quando esses 20% restantes são críticos para o negócio.
Realidade: quando o fine-tuning faz a diferença
Há cenários em que o ajuste fino é claramente superior:
- Redução de latência e custo por token: um modelo pequeno ajustado pode substituir um grande em tarefas muito delimitadas, com menor latência e menor custo de inferência.
- Formatos estritos: quando a saída deve seguir um esquema JSON complexo ou um formato de relatório interno, o fine-tuning reduz a necessidade de validações posteriores.
- Domínio muito específico com jargão próprio: por exemplo, classificação de incidentes em um setor regulado onde o vocabulário não aparece no corpus geral.
- Estilo consistente de marca: quando o tom é parte do produto e não pode ser delegado a instruções que o modelo às vezes ignora.
Fora desses casos, convém perguntar-se se o problema é realmente de comportamento do modelo ou de dados de entrada.
O passo a passo que realmente importa (e que costuma não ser contado)
Além de executar um script de treinamento, o processo real tem fases que determinam o resultado:
1. Definir o critério de sucesso antes de tocar nos dados
Não é a mesma coisa «que responda bem» que «que reduza em 20% as escaladas para humano em tickets de faturamento». Sem uma métrica operacional, qualquer melhoria é anedótica.
2. Construir um conjunto de avaliação independente
Deve sair da mesma distribuição que os dados de produção, mas nunca do mesmo lote de treinamento. Um erro frequente é avaliar com exemplos que o modelo já viu, o que infla os resultados.
3. Formatar os dados conforme o provedor
Cada plataforma espera um formato diferente (pares instrução-resposta, conversas com papéis, etc.). Um formato incorreto pode passar despercebido e produzir um modelo que ignora as instruções.
4. Treinar com um modelo base adequado
Nem todos os modelos admitem fine-tuning, e os que admitem têm limites de tamanho e de tokens. Escolher um modelo pequeno demais para uma tarefa complexa leva a um ajuste que não generaliza.
5. Avaliar com métricas e com revisão humana
As métricas automáticas (acurácia, F1, BLEU) não capturam nuances de utilidade. Uma revisão cega por parte de alguém que não participou da rotulagem detecta problemas que as métricas escondem.
6. Implantar com monitoramento
O modelo ajustado pode se degradar se a distribuição de entrada mudar. Sem monitoramento de deriva, o problema é detectado quando os usuários reclamam.
Limitações que convém assumir
O fine-tuning não elimina as alucinações. Um modelo ajustado com dados corretos pode continuar inventando informações quando lhe é perguntado algo fora de sua distribuição. Também não garante o cumprimento de políticas: se o dataset contém exemplos ambíguos, o modelo aprenderá essa ambiguidade.
Outro limite prático: o esquecimento catastrófico. Ao ajustar um modelo para uma tarefa específica, ele pode perder capacidades gerais que antes tinha. Se você precisa de um assistente versátil, o ajuste fino agressivo pode piorar o desempenho em tarefas não previstas.
E um aviso de transparência: não existe uma fórmula que garanta que o fine-tuning melhorará o seu caso. A decisão deve se basear em um teste controlado com métricas claras, não em promessas de terceiros.
Alternativas que às vezes vencem
Antes de ajustar, vale a pena explorar:
- Prompt engineering com exemplos dinâmicos: selecionar os exemplos mais relevantes para cada consulta no momento da inferência.
- RAG com bons embeddings: para conhecimento factual e atualizado.
- Ferramentas externas: delegar cálculos ou consultas a APIs em vez de esperar que o modelo as faça de memória.
- Modelos já ajustados pelo provedor: em alguns casos, um modelo especializado disponível comercialmente cobre a necessidade sem treinamento próprio.
A combinação de várias técnicas costuma dar melhores resultados do que apostar tudo no fine-tuning.
Conclusão sem promessas
O fine-tuning de LLMs é uma técnica poderosa, mas não é um atalho. Funciona quando o problema é de comportamento e há dados de qualidade suficiente para defini-lo. Falha quando é usado para injetar conhecimento cambiante, quando os dados são ruidosos ou quando se espera que um modelo pequeno iguale um grande em raciocínio complexo. A diferença entre um projeto bem-sucedido e um que fica na gaveta está menos no treinamento e mais na definição do problema, na avaliação honesta e na disposição de aceitar que, às vezes, a resposta correta é não ajustar nada.