Fine-tuning e personalização

O que fine-tuning realmente modifica

No pré-treinamento, um modelo aprende padrões gerais em grande escala. Fine-tuning parte desses pesos e continua a otimização em um conjunto menor e orientado a uma tarefa, domínio ou preferência. O processo ajusta todos os parâmetros ou somente uma fração adicional, alterando probabilidades e comportamento.

Personalização é uma categoria maior. Pode incluir instruções, exemplos no contexto, RAG, ferramentas, regras, preferências armazenadas e fine-tuning. Muitas necessidades de negócio — usar documentos atuais, chamar uma API, respeitar um formato — podem ser resolvidas sem treinamento.

Fine-tuning não instala um banco de fatos confiável. O modelo pode absorver padrões do conjunto, mas recuperação exata, atualização e citação são difíceis. Para políticas que mudam, RAG ou consulta estruturada é mais adequado. Para responder sempre em determinado esquema ou linguagem técnica, ajuste pode ajudar.

Quando fine-tuning vale a pena

O ajuste faz sentido quando a tarefa é frequente, estável e bem especificada; o modelo-base quase resolve; há muitos exemplos corretos; e os ganhos podem ser medidos. Casos comuns incluem classificação especializada, extração em esquema, estilo consistente, vocabulário de domínio e redução do tamanho de prompts repetitivos.

Também pode permitir que um modelo menor atinja qualidade suficiente, reduzindo latência e custo de inferência. Essa hipótese precisa de benchmark: treinamento, hospedagem e manutenção podem eliminar a economia. Modelos menores podem perder capacidade geral ou segurança.

Não faça fine-tuning para corrigir alguns fatos, contornar um processo mal definido ou compensar documentos ruins. Se os requisitos mudam toda semana, o conjunto de treino envelhece. Se não há como dizer o que é resposta correta, não haverá sinal confiável para treinar.

• Há uma baseline clara e uma lacuna recorrente.
• A saída desejada pode ser demonstrada por exemplos consistentes.
• Os dados têm autorização, cobertura e volume adequados.
• O comportamento será usado o suficiente para justificar o ciclo de manutenção.
• Testes mostram que prompting, RAG e regras não atendem sozinhos.
• Existe equipe para avaliar, versionar, monitorar e retirar o modelo.

Dados de treinamento: qualidade, cobertura e direitos

O conjunto deve representar entradas, idiomas, níveis de dificuldade e formatos da produção. Exemplos fáceis demais criam avaliação ilusória. Inclua respostas desejadas, recusas corretas, ambiguidades, dados ausentes e limites. Instruções conflitantes ensinam comportamento instável.

Mais dados não são sempre melhores. Deduplicação evita que um padrão domine. Revisão por especialistas reduz rótulos errados. Guias de anotação definem tom, factualidade, estrutura e tratamento de incerteza. Meça concordância entre revisores para encontrar critérios ambíguos.

Verifique direitos autorais, licença, confidencialidade, dados pessoais, finalidade e retenção. Remover nomes não garante anonimização. Segredos podem ser memorizados. Dados sintéticos ajudam a cobrir variações, mas podem amplificar erros do modelo que os gerou; misture com exemplos reais autorizados e avalie separadamente.

1. Definir tarefa, população, comportamento desejado e proibido.
2. Criar guia de exemplos e critérios antes de coletar em escala.
3. Verificar origem, licença, consentimento, finalidade e necessidade.
4. Deduplicar, limpar, equilibrar e separar casos por fonte ou pessoa.
5. Revisar amostras com especialistas e medir consistência.
6. Dividir treino, validação e teste sem vazamento.
7. Versionar dados, filtros, instruções e responsáveis.

SFT, instruction tuning e aprendizagem por preferências

Supervised fine-tuning, ou SFT, apresenta pares de entrada e saída desejada. Em instruction tuning, esses pares ensinam o modelo a seguir diversos tipos de instrução. O objetivo é aumentar a probabilidade das respostas de referência. A qualidade depende de exemplos e da função de perda, não de uma compreensão automática do critério.

Aprendizagem por preferências usa comparações entre respostas. Um avaliador indica qual é melhor segundo critérios. Métodos podem treinar um modelo de recompensa e aplicar reforço, como RLHF, ou otimizar preferências de modo mais direto, como DPO. Preferências humanas são variáveis e precisam de instruções, amostragem e análise de desacordo.

Alinhamento melhora utilidade e segurança observadas, mas pode gerar respostas excessivamente agradáveis, recusas indevidas ou perda de capacidade. Avalie comportamento desejado e regressões em tarefas gerais e grupos diferentes.

Ajuste completo, PEFT, LoRA e QLoRA

No full fine-tuning, todos ou muitos parâmetros do modelo são atualizados. Isso oferece flexibilidade, mas exige memória, computação e armazenamento. Também aumenta risco de catastrophic forgetting, quando capacidades gerais são degradadas por ajuste excessivo em um domínio estreito.

PEFT significa parameter-efficient fine-tuning. Em vez de alterar todos os pesos, métodos treinam pequena parcela ou módulos adicionais. LoRA representa atualizações de matrizes por componentes de baixa dimensão e preserva o modelo-base congelado. Adaptadores podem ser armazenados e trocados por tarefa.

QLoRA combina quantização do modelo-base com adaptadores LoRA, reduzindo memória. Eficiência não remove complexidade: precisão numérica, escolha de camadas, rank, taxa de aprendizado e dados ainda influenciam estabilidade. O adaptador também precisa ser versionado com modelo-base, tokenizer e configuração compatíveis.

O pipeline de um projeto de fine-tuning

Estabeleça primeiro o modelo-base e a avaliação. Execute prompting bem estruturado para saber se treinamento é necessário. Defina métricas, conjunto de teste congelado e limites de segurança. Depois prepare dados e escolha um método proporcional ao ganho esperado.

Durante o treino, acompanhe perda de treino e validação, mas não use somente essas curvas. Salve checkpoints, sementes, código, ambiente, hiperparâmetros e hash dos dados. Teste diferentes taxas e épocas em escala pequena. Treino longo demais pode memorizar exemplos e piorar generalização.

Após o ajuste, compare lado a lado com o base e com a solução sem ajuste. Analise falhas por categoria e execute red teaming. Só então avalie integração, latência, custo e rollback. O artefato treinado é um novo componente de produção e precisa de ciclo de vida próprio.

1. Definir baseline, métrica, teste congelado e critério de parada.
2. Selecionar modelo-base e confirmar termos de uso e implantação.
3. Preparar dados autorizados com documentação e divisão sem vazamento.
4. Escolher SFT ou preferência e método full ou PEFT.
5. Fazer experimento pequeno, registrar configuração e observar overfitting.
6. Comparar checkpoints no teste e em casos de segurança.
7. Validar custo, latência, compatibilidade e plano de rollback.
8. Implantar gradualmente e monitorar regressões e mudança de demanda.

Avaliação: provar que a personalização ajudou

A avaliação deve medir exatamente a lacuna que motivou o ajuste: schema válido, classificação correta, tom, fidelidade, taxa de recusa ou custo. Compare base com prompt otimizado, RAG quando aplicável e modelo ajustado. Use o mesmo conjunto e configuração para uma comparação justa.

Separe avaliação de capacidade, segurança e operação. O modelo pode melhorar o formato e piorar factualidade. Pode ficar mais especializado e menos capaz de responder fora do domínio. Analise por idioma, categoria, dificuldade e grupo de usuário. Teste exemplos do treino para detectar memorização, mas nunca os conte como generalização.

Avaliação humana precisa de rubrica, treinamento e amostras cegas. Juiz automático por LLM é útil para escala, mas deve ser calibrado contra pessoas e critérios objetivos. Guarde erros representativos como testes de regressão.

• Ganho sobre a melhor baseline, não sobre um prompt fraco.
• Desempenho em dados externos ao treino e à seleção de hiperparâmetros.
• Regressões em capacidade geral e comportamento seguro.
• Robustez a variação de linguagem, ruído e entradas adversariais.
• Memorização ou reprodução de dados sensíveis e protegidos.
• Latência, custo, tamanho, escalabilidade e taxa de revisão.
• Estabilidade após mudanças do sistema e do tráfego.

Riscos, privacidade e governança

Fine-tuning pode memorizar, reforçar vieses e deslocar salvaguardas do modelo-base. Um conjunto criado de interações históricas pode reproduzir atendimento desigual. Dados removidos da fonte não desaparecem automaticamente dos pesos ou adaptadores; exclusão pode exigir novo treino ou descarte da versão.

Documente propósito, origem dos dados, licenças, filtros, modelo-base, método, métricas, limitações e usos proibidos. Controles de acesso protegem datasets, checkpoints, adaptadores e logs. Equipes precisam saber quem aprova dados, treino, implantação, atualização e retirada.

Modelos ajustados a partir de serviços externos permanecem sujeitos aos termos do provedor. Modelos abertos têm licenças próprias. Verifique direito de criar derivados, redistribuir pesos, uso comercial, atribuição e políticas de uso. Avaliação jurídica é necessária quando o impacto ou o conteúdo justificar.

1. Realizar avaliação de risco e impacto antes da coleta.
2. Minimizar e proteger dados durante preparação, treino e armazenamento.
3. Documentar permissões, licenças, transformações e exclusões.
4. Testar viés, segurança, memorização e usos fora de escopo.
5. Controlar acesso a dados, checkpoints e ambiente de inferência.
6. Manter responsável, canal de incidente e plano de retirada.

Implantação, versionamento e manutenção

Uma versão é a combinação de modelo-base, adaptador, tokenizer, prompt, regras, ferramentas e ambiente. Registrar somente o arquivo LoRA não basta. Mudança do modelo-base pode quebrar compatibilidade ou alterar o comportamento. Fixe versões e repita a avaliação antes de atualizar.

A implantação pode manter adaptadores separados ou fundi-los aos pesos. Adaptadores facilitam especializações e rollback; fusão pode simplificar inferência, mas cria um novo artefato. Quantização reduz recurso, podendo alterar qualidade. Meça no hardware real.

Monitore distribuição de entradas, taxa de erro, formato inválido, recusa, custo e feedback. Novos produtos, linguagem e regras causam drift de necessidade, mesmo que o modelo não mude. Decida se a correção exige prompt, dado, RAG, regra ou novo ajuste — retreinar não deve ser automático.

• Versione modelo-base, tokenizer, adaptador, dados, código e configuração.
• Use implantação gradual, comparação e rollback testado.
• Mantenha model card com escopo, métricas e limitações.
• Reavalie após atualização de infraestrutura ou quantização.
• Colete feedback com contexto e revisão, sem incorporá-lo automaticamente.
• Defina gatilhos de reavaliação e critérios para aposentar a versão.

Árvore de decisão para personalizar um modelo

Comece pela pergunta: a lacuna é conhecimento, comportamento, capacidade de ação ou regra? Conhecimento atual e citável aponta para RAG. Dados exatos e ações apontam para ferramenta. Formato determinístico aponta para validador. Comportamento recorrente que o modelo quase domina pode justificar fine-tuning.

Faça a solução mais simples funcionar como baseline. Se um prompt com exemplos atinge a qualidade, ele é mais fácil de alterar. Se o prompt fica enorme e repetitivo ou a consistência permanece baixa, compare um ajuste. Não conte apenas custo por token: inclua dados, GPU, engenharia, avaliação, hospedagem e incidentes.

Personalização madura é uma arquitetura combinada. Um modelo ajustado pode usar RAG, ferramentas e validação. O objetivo não é treinar por treinar, mas alcançar qualidade comprovada com controle sustentável.