1.1 A escada de customização

1. Prompt engineering — instruções claras, papel, restrições, formato. Grátis, instantâneo, reversível.
2. Few-shot — 2–8 exemplos no prompt. Ensina formato e estilo sem treinar.
3. RAG — dar ao modelo os documentos certos em tempo de execução. É assim que se "adiciona conhecimento" (ver IA Generativa & RAG).
4. Fine-tuning — ajustar os pesos com exemplos da sua tarefa. Muda comportamento de forma persistente.
5. Continued pre-training / treinar do zero — raro; caríssimo; para domínios muito distintos ou fundações próprias.

Suba a escada só quando o degrau anterior não resolve. A maioria dos "problemas de modelo" some com prompt melhor, few-shot ou RAG.

1.2 O que o fine-tuning muda

• Formato e estrutura: sempre responder no seu JSON/schema, no seu template, sem preâmbulo.
• Estilo e tom: a "voz" da sua marca, um nível de formalidade, concisão.
• Uma tarefa estreita: classificar/extrair/rotear/reescrever naquele domínio, melhor e mais barato que um modelo genérico grande.
• Aderência a instruções complexas que o modelo "esquece" no meio de prompts longos.
• Reduzir o prompt: o que era 2 mil tokens de instruções e exemplos vira comportamento embutido — mais barato por chamada, mais rápido.
• Linguagem/domínio: melhorar num idioma ou jargão sub-representado (com dados de continued pre-training).

1.3 O que o fine-tuning NÃO muda de forma confiável

• Não "ensina fatos" de forma confiável: jogar a sua base de conhecimento num fine-tune faz o modelo às vezes lembrar e às vezes alucinar por cima. Fatos = RAG.
• Não conserta raciocínio fraco de um modelo pequeno demais para a tarefa.
• Não é atualização: fatos que mudam (preços, políticas) não podem viver num peso congelado.

Um projeto pode combinar: continued pre-training (domínio) → SFT (tarefa/formato) → DPO (polir preferências). A maioria dos casos práticos é só SFT com LoRA.

3.1 Quantidade × qualidade

• Para SFT com LoRA numa tarefa estreita: dezenas a poucos milhares de exemplos bons costumam bastar. Formato/estilo puro pode render com 50–200.
• Qualidade > quantidade, sempre. 200 exemplos impecáveis batem 5 mil ruidosos. Um exemplo errado "ensina" o erro.
• Diversidade cobrindo os casos reais (incluindo os difíceis e as bordas) importa mais que volume.
• Continued pre-training e treinar do zero são outra escala (bilhões de tokens) — fora do escopo prático da maioria.

3.2 Formatos

// SFT — formato de chat (JSONL, uma linha por exemplo)
{"messages": [
  {"role": "system", "content": "Você é um extrator. Responda só com JSON."},
  {"role": "user", "content": "Fatura: ...texto..."},
  {"role": "assistant", "content": "{\"numero\": \"123\", \"total\": 19990}"}
]}

// Preference (DPO) — chosen vs rejected para o mesmo prompt
{"prompt": "...", "chosen": "resposta melhor", "rejected": "resposta pior"}

3.3 Fontes de dados

• Logs de produção + correção humana: o ouro. Onde os usuários editaram/rejeitaram a saída, você tem o par (entrada → resposta certa). Instrumente isso (ver Design de Produtos com IA e LLMOps & Avaliação). Com consentimento e privacidade.
• Dados sintéticos: um modelo forte gera exemplos (distillation, aumento de dados). Rápido e barato; risco de propagar o viés e os erros do professor — filtre e revise.
• Anotação humana: especialistas escrevem/rotulam. Caro, alta qualidade; use para os casos que os outros não cobrem.
• Datasets públicos: para tarefas genéricas; cheque licença e adequação ao seu caso.

3.4 Higiene dos dados

• Limpeza: remover exemplos incorretos, incompletos, contraditórios; normalizar o formato.
• Deduplicação: exemplos repetidos enviesam o treino.
• Contaminação com o eval: se um exemplo do conjunto de treino também está no de avaliação, seus números mentem. Separe antes e cheque sobreposição.
• Viés: o modelo aprende os vieses dos dados; audite representação e casos sensíveis.
• Balanceamento: se 95% dos exemplos são de uma categoria, o modelo vira "sempre essa categoria".
• Consistência: se dois exemplos parecidos têm respostas em estilos diferentes, o modelo fica confuso — padronize.

3.5 Licença e consentimento

• Você tem direito de treinar com esses dados? (dados de usuários — consentimento/base legal; dados de terceiros — licença; conteúdo protegido).
• Algumas licenças de modelo/serviço proíbem usar as saídas para treinar outro modelo — leia (ver IA Local & SLMs, Módulo 2).
• Remova PII que não é necessária para a tarefa.

4.1 O conceito

Full fine-tuning atualiza todos os pesos — precisa de muita VRAM (o modelo + gradientes + estados do otimizador) e produz uma cópia inteira do modelo por tarefa. PEFT (parameter-efficient fine-tuning) treina só uma fração minúscula:

• LoRA (Low-Rank Adaptation): para cada matriz de peso que você escolhe adaptar, congela a original e treina um par de matrizes de baixo rank (A e B, com ΔW = B·A). São ~0.1–2% dos parâmetros. Na inferência, W + ΔW.
• QLoRA: carrega o modelo base quantizado em 4-bit (NF4) e treina os adapters LoRA por cima, em precisão maior. Permite afinar um 13B numa GPU de 24 GB, ou um 70B em ~48 GB.
• DoRA, rsLoRA, LoRA+: variações que melhoram a qualidade/estabilidade.

PEFT venceu para a maioria dos casos: mais barato, mais rápido, os adapters são pequenos (MBs), dá para ter muitos e trocá-los.

4.2 Os hiperparâmetros que importam

4.3 VRAM

• LoRA (base em 16-bit): ~2–3× o tamanho do modelo em 16-bit. Um 7B → ~20–24 GB.
• QLoRA (base 4-bit): bem menos — 7B em ~8–10 GB, 13B em ~16 GB, 70B em ~48 GB. É o que democratiza o fine-tune.
• Serviços gerenciados (dos provedores de modelo, ou plataformas) escondem tudo isso — você manda o JSONL e recebe o modelo/adapter.

4.4 Adapters

• O resultado de um LoRA é um adapter de poucos MB. Você pode: guardar vários (um por tarefa/cliente), trocar em runtime, e — se quiser — fazer merge no modelo base (gera um modelo completo, útil para servir sem overhead de adapter).
• Servir múltiplos adapters sobre um base compartilhado (vLLM suporta) é a base de multi-tenant barato (Módulo 9).
• Compor adapters (somar dois) funciona às vezes, com cuidado.

5.1 Por que SFT não basta

SFT ensina "responda assim" com exemplos positivos. Mas há coisas que exemplos positivos não capturam bem: o que não fazer (não inventar, não ser prolixo, não bajular, não sair do escopo), e preferências sutis entre duas respostas plausíveis ("esta é boa, mas aquela é melhor"). Preference tuning treina com pares comparativos.

5.2 RLHF → DPO

• RLHF (Reinforcement Learning from Human Feedback): treina um reward model a partir de comparações humanas, e depois otimiza o LLM contra esse reward com RL (PPO). Poderoso, mas complexo e instável (vários modelos, tuning delicado, reward hacking).
• DPO (Direct Preference Optimization): pula o reward model e o RL — otimiza o modelo diretamente nos pares (chosen, rejected) com uma única loss. Muito mais simples, estável e barato; virou o padrão prático.
• ORPO (combina SFT + preferência num passo só), KTO (usa só "bom/ruim", sem par), SimPO — variações; DPO/ORPO cobrem a maioria.

5.3 O dataset de preferência

{"prompt": "<pergunta ou instrução>",
 "chosen":   "<a resposta que preferimos>",
 "rejected": "<uma resposta pior para o MESMO prompt>"}

• De onde vêm os pares: comparação humana entre duas saídas do modelo; a resposta original (rejected) vs a versão editada por um humano (chosen); a saída do modelo antigo vs a do novo; "melhor de N" vs "pior de N".
• Qualidade: o chosen tem que ser claramente melhor pelo motivo que você quer ensinar; o rejected não pode ser lixo óbvio (senão não ensina nuance) nem quase idêntico.
• Cobertura: os eixos que você quer mover (concisão, honestidade, formato, recusa apropriada) representados em pares.
• Centenas a poucos milhares de pares costumam bastar depois de um SFT.

5.4 Riscos

• Reward hacking / degradação: o modelo aprende o "atalho" da preferência (ex.: fica sempre curto porque respostas curtas foram preferidas) e perde capacidade real.
• "Alignment tax": o preference tuning pode reduzir performance em tarefas não cobertas — meça a regressão (Módulo 7).
• Sobre-recusa: ensinar a recusar demais deixa o modelo inútil.
• Faça DPO depois de um SFT sólido, com beta (o quanto se afasta do modelo de referência) moderado.

6.1 As ferramentas

6.2 O loop

1. Preparar os dados (Módulo 3): JSONL limpo, dedup, split treino/eval sem contaminação.
2. Baseline: medir o modelo base (e prompt+RAG) no seu eval — o número a bater.
3. Configurar (Módulo 4/5): método, hiperparâmetros de partida.
4. Treinar: acompanhar a loss de treino e de validação; salvar checkpoints.
5. Avaliar (Módulo 7): no eval próprio, contra o baseline, checando regressão.
6. Iterar: ajustar dados (o que mais rende), depois hiperparâmetros. Mudar uma coisa por vez.

6.3 Hardware

• Uma GPU de 24 GB faz LoRA de 7–13B (QLoRA vai a 30–70B). Alugar por hora numa cloud é o caminho para não comprar.
• Apple Silicon com bastante RAM roda LoRA de modelos pequenos-médios via MLX.
• Serviço gerenciado se você não quer nem pensar em GPU.

6.4 Logging e checkpoints

• Weights & Biases (ou TensorBoard/MLflow): loss, LR, gradientes, exemplos de geração ao longo do treino.
• Salvar checkpoints e escolher o melhor pela loss de validação (não a de treino) e pelo eval próprio — o último passo nem sempre é o melhor.

6.5 Sinais de overfitting

• Loss de validação para de cair (ou sobe) enquanto a de treino continua caindo.
• O modelo repete frases literais dos exemplos de treino; "decora" em vez de generalizar.
• Melhora nos casos parecidos com o treino, piora nos diferentes; perde capacidade geral.
• Correção: menos epochs, rank menor, mais/melhores dados, early stopping, regularização (dropout no LoRA).

7.1 Nunca só benchmark

• Benchmarks públicos não medem a sua tarefa e têm contaminação. Monte um eval set próprio: 100–500 exemplos representativos, com o resultado esperado ou um verificador, separado do treino.
• Métricas: checagem automática onde dá (classificação bate? JSON válido e correto? o código roda?), LLM-as-judge com rubrica para o que é aberto (ver LLMOps & Avaliação de Sistemas de IA).

7.2 Comparar no mesmo eval

Rode, no mesmo eval set: (a) o modelo base com o seu prompt; (b) base + few-shot; (c) base + RAG se aplicável; (d) o modelo fine-tunado. Só assim você sabe se o fine-tune ganhou de alternativas mais baratas — muitas vezes um bom prompt+RAG empata com o fine-tune e não custa treino nem manutenção.

7.3 Regressão de capacidade (catastrophic forgetting)

• Afinar numa tarefa pode degradar outras: o modelo "esquece" instruções gerais, raciocínio, outros idiomas, segurança.
• Tenha um eval de regressão: um punhado de tarefas gerais (seguir instruções, um pouco de raciocínio, formato, uma tarefa em outro idioma, prompts de segurança) que você roda antes e depois.
• Mitigar: menos epochs, rank menor, misturar alguns exemplos "gerais" no dataset de treino, LR menor.

7.4 Formato, estilo, segurança

• Se o objetivo era formato/estilo, meça isso diretamente (o JSON valida sempre? o tom bate com a rubrica?).
• Segurança: o fine-tune pode ter afrouxado guardrails do base (sobretudo com dados não curados) — re-rode um conjunto de prompts de segurança (ver Segurança de Aplicações de IA).

7.5 "Vale a pena?"

O fine-tune só se justifica se o ganho no eval próprio supera o custo total: dados (coleta, anotação, curadoria), GPU/treino, avaliação, e — o maior — a manutenção: cada vez que o modelo base evolui ou os dados mudam, você re-treina e re-avalia. Se prompt+RAG chega perto, fique com prompt+RAG.

8.1 A ideia

Distillation: um modelo "professor" forte (de fronteira, ou um grande aberto) gera dados de alta qualidade para a sua tarefa; você treina (SFT/LoRA) um modelo "aluno" pequeno nesses dados. O aluno aprende a fazer aquela tarefa quase tão bem, mas com o custo, a latência e a privacidade de um SLM (ver IA Local & SLMs).

8.2 Quando o SLM afinado ganha do modelo de fronteira

• Tarefa estreita e repetitiva: roteamento, classificação, extração, um estilo de reescrita, um formato — o SLM afinado pode bater o modelo de fronteira genérico nela, por focar.
• Volume alto: 100 mil a milhões de chamadas/dia — o SLM local ou barato muda a economia.
• Latência: um SLM responde em dezenas de ms.
• Privacidade: roda on-prem, dados não saem.
• Não ganha em: tarefas abertas, raciocínio difícil, contexto muito longo — aí o modelo grande é insubstituível.

8.3 O pipeline de distillation

1. Definir a tarefa e o formato de saída com precisão.
2. Gerar com o professor: milhares de exemplos (entrada → saída), com prompts variados cobrindo os casos reais; usar entradas reais quando possível (não só sintéticas).
3. Filtrar: descartar as saídas do professor que estão erradas (validação automática, um segundo modelo como juiz, amostragem humana). Lixo do professor = lixo no aluno.
4. Treinar o aluno (SFT/LoRA) nos dados filtrados.
5. Avaliar (Módulo 7) contra o professor e contra o SLM base sem afinar, no seu eval.
6. Iterar: os casos onde o aluno erra viram novos exemplos.

Licença: alguns provedores proíbem usar as saídas do modelo deles para treinar um modelo concorrente — leia os termos antes de destilar (ver IA Local & SLMs, Módulo 2).

8.4 Frota de especialistas

• Em vez de um modelo generalista, vários SLMs afinados — um por tarefa/domínio — + um dispatcher (heurística ou classificador leve) que escolhe.
• Servir como adapters LoRA sobre um base compartilhado mantém o custo de memória baixo (Módulo 9).
• Fallback para um modelo grande nos casos que nenhum especialista cobre bem (cascata — ver IA Local & SLMs, Módulo 8).

9.1 Servir

• Adapter separado: guardar o LoRA (MBs) e carregá-lo sobre o base na inferência. O vLLM serve múltiplos adapters sobre um base compartilhado → um adapter por cliente/tarefa com um só modelo na memória (multi-tenant barato).
• Merged: fundir o adapter no base gera um modelo completo — sem overhead de adapter na inferência, mas ocupa o tamanho inteiro e não dá para trocar em runtime. Bom quando é um modelo só e o throughput importa.
• Ver a apostila IA Local, On-Device & SLMs para o serving (vLLM, quantização, batching).

9.2 Versionar

• Reprodutibilidade: versione juntos o modelo base (nome + hash + quantização), o dataset (versão/hash), a config de treino (hiperparâmetros, seed), e o código. Sem isso, você não consegue re-treinar o "mesmo" modelo.
• Um model registry (MLflow, o registry do seu provedor, um bucket com metadados) — ver MLOps.
• Guardar o eval do modelo junto (os números que justificaram promovê-lo).

9.3 Quando re-treinar

• Drift: as entradas mudaram (novos tipos de ticket, novo jargão) e a qualidade caiu — monitorar em produção.
• Novos dados: acumulou correção humana suficiente para melhorar.
• Novo modelo base: saiu um base melhor; re-treinar o adapter sobre ele (e re-avaliar tudo). Este é o custo escondido do fine-tuning — você fica "preso" à sua pipeline de treino a cada evolução do ecossistema.

9.4 O custo real

Além da GPU do treino (relativamente barato para LoRA): coleta e curadoria de dados (o maior), anotação, construção e manutenção do eval, o tempo de engenharia a cada iteração, e o re-treino a cada troca de base. Compare honestamente com "prompt+RAG que a gente ajusta em minutos".

9.5 Segurança

• Guardrails: o fine-tune (sobretudo com dados não curados) pode remover proteções do base — re-teste segurança depois de todo treino (ver Segurança de Aplicações de IA — OWASP LLM Top 10).
• Vazamento de dados de treino: modelos podem regurgitar exemplos do treino literalmente — não afine com PII ou segredos que não podem sair na saída.
• Envenenamento de dados: se os dados de treino vêm de fonte não confiável (logs manipuláveis, contribuições externas), alguém pode plantar comportamento malicioso — valide a proveniência.

9.6 Licença

• A licença do modelo base permite fine-tune comercial? redistribuir o modelo afinado? (varia — ver IA Local & SLMs, Módulo 2).
• As saídas do modelo professor (na distillation) podem ser usadas para treinar? Alguns termos proíbem.
• Os dados de treino: você tem direito de uso para treinar (licença, consentimento)?

10.1 Onde essa habilidade pesa

• ML engineer / applied AI: customizar modelos para tarefas de produto, distillation, avaliação.
• LLM engineer: a pipeline de fine-tune, o serving de adapters, a integração com o resto do sistema de IA.
• ML platform: a infra de treino, o registry, o serving multi-tenant, os custos.
• Research / applied research: métodos de tuning, alinhamento, avaliação.
• Setores: qualquer produto de IA sério que precise de comportamento consistente, custo controlado ou privacidade.

10.2 Roadmap de estudo (5–7 semanas)

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. LoRA com ganho medível (âncora): uma tarefa real, um QLoRA que bate o base e o prompt+few-shot+RAG no mesmo eval próprio, com o eval de regressão e o raciocínio de "valeu a pena".
2. SLM destilado: um modelo pequeno destilado de um grande para uma tarefa (roteamento/extração/classificação), com relatório de accuracy, custo por 1k e latência vs o professor.
3. DPO a partir de pares de preferência: mover um eixo de comportamento (concisão, honestidade), com a medição do efeito e da regressão.
4. Estudo "fine-tune vs RAG vs prompt": a mesma tarefa pelas três vias, com números lado a lado e a recomendação.
5. Serving multi-tenant: vários adapters sobre um base no vLLM, com o versionamento (base+dados+config) e as métricas de custo/latência.

10.5 Fontes para continuar

• Libs: a documentação do Hugging Face TRL e PEFT, do Axolotl, do Unsloth (e o blog deles, muito prático), do torchtune, do LLaMA-Factory, do MLX-LM.
• Papers: LoRA, QLoRA, DoRA; InstructGPT (RLHF), DPO, ORPO, KTO; estudos sobre catastrophic forgetting e "alignment tax".
• Guias: os cookbooks de fine-tuning da Hugging Face e dos provedores de modelo; materiais sobre "synthetic data" e "LLM-as-judge".
• Nesta trilha: IA Local, On-Device & Small Language Models, Engenharia de LLMs, IA Generativa & RAG, LLMOps & Avaliação de Sistemas de IA, MLOps: do Modelo à Produção, Design de Produtos com IA, Segurança de Aplicações de IA (OWASP LLM Top 10), Governança de IA, Ética & EU AI Act, Machine Learning e IA, Redes Neurais.