Pular para conteúdo

Capítulo 7.6 — Fine-tuning, distillation e alignment em produção

🎯 Objetivo

Tratar fine-tuning como disciplina de engenharia, com critério de quando usar, quando não usar e quais são as obrigações operacionais mínimas. O capítulo conversa diretamente com Cap. 2.2 (quantização + LoRA/QLoRA) e com Cap. 2.10 (RAG vs FT vs prompt).

🧠 Para que serve fine-tuning de verdade

Fine-tuning é bom para alterar:

  • Formato (estrutura de saída recorrente que prompt + structured output ainda não estabilizam suficientemente).
  • Estilo / voz (tom da empresa, terminologia específica, linguagem técnica de domínio).
  • Comportamento em tool calling com schemas bem definidos e dataset estável.
  • Domínio especializado com vocabulário muito fora da distribuição de treino.

Fine-tuning é ruim para:

  • Conhecimento factual mutável -> use RAG.
  • Regras de negócio -> use policy-as-code.
  • "Garantir" comportamento de segurança -> use autorização + policy.

🧠 Quando usar cada técnica

Técnica Para que Custo Risco principal
Full fine-tuning Mudança ampla; reorganizar comportamento Alto (compute, dados, eval) Regressão em tarefas não vistas
LoRA Adapters de baixo posto sobre camadas selecionadas Médio Qualidade depende de hiperparâmetros e cobertura do dataset
QLoRA LoRA sobre base 4-bit (NF4) Médio-baixo (GPU única) Variação numérica; teste com cuidado
Distillation Reduzir custo de inferência mantendo comportamento Alto upfront, paga em serving Student diverge do teacher ao longo do tempo
Instruction tuning / SFT Ensinar a seguir instruções estruturadas Médio Overfit a estilo
Preference tuning (DPO/KTO/ORPO) Alinhar a preferências Alto + delicado Regressão em capacidades não cobertas; fora do escopo deste livro

🧠 Diferença entre comportamento, formato, estilo e conhecimento

Em uma conversa típica de planejamento:

  • Se a frustração é "o modelo não responde no formato X" -> use structured outputs, prompt e function calling. Fine-tuning só quando o problema persistir em larga escala.
  • Se a frustração é "o modelo não fala como a gente" -> use fine-tuning leve (LoRA) para estilo, mantendo conhecimento em RAG.
  • Se a frustração é "o modelo não sabe X" -> use RAG ou tools. Não fine-tuning.
  • Se a frustração é "o modelo às vezes ignora a política" -> use policy-as-code e HITL. Não fine-tuning.

🛡️ Obrigações operacionais mínimas

  • Eval pré e pós FT em golden + adversarial + regression. Comparar com baseline em todas as dimensões relevantes, não só na que motivou o FT.
  • Versão imutável + alias móvel. Modelo fine-tuned é artefato versionado; vive no registry.
  • Rollback definido. Qual modelo volta? Em quanto tempo?
  • Métricas de regressão monitoradas em produção. FT pode resolver A e quebrar B em silêncio.
  • Documentação do dataset (datasheet/dataset card): origem, licença, viés conhecido, base legal.

🚨 Modos de falha

  • FT em dataset com PII não tratada -> vazamento via memorização.
  • FT com dataset pequeno e barulhento -> overfitting catastrófico.
  • FT para fatos -> conhecimento "envelhece"; volta a errar em semanas.
  • Mistura de adapters QLoRA treinados em versões diferentes da base 4-bit.
  • Promoção de modelo FT sem eval comparativo.

⚠️ Sobre RLHF / DPO no escopo deste livro

RLHF, DPO, KTO e ORPO são técnicas de alinhamento por preferência. São relevantes para times que treinam o modelo base inteiro. Para a imensa maioria de equipes enterprise que consome modelo pronto e faz FT leve, essas técnicas são fora do escopo operacional - citadas para que o vocabulário não fique ausente, mas sem aprofundar técnicas específicas.

📚 Referências