2.1 — Quando Ajustar um Modelo: Árvore de Decisão e Custo Total de Propriedade (Fine-tuning)

Objetivo da Aula

Ao concluir esta aula, você será capaz de:

Aplicar a árvore de decisão completa para decidir entre prompt engineering, RAG e fine-tuning

Calcular TCO (Total Cost of Ownership) de modelo customizado vs prompt engineering

Identificar os sinais que indicam que fine-tuning é necessário (e não apenas cômodo)

Reconhecer quando fine-tuning é uma armadilha disfarçada de solução

Evitar os erros mais comuns de quem decide fine-tuning prematuramente

Por que isso importa

Fine-tuning é a ferramenta mais cara e lenta do arsenal de personalização de LLMs. É também a mais frequentemente escolhida de forma prematura — porque parece técnica, impressiona stakeholders e dá a sensação de “propriedade” do modelo.

A realidade: 80% dos casos que chegam ao time de ML como “precisamos de fine-tuning” se resolvem com um system prompt bem feito ou RAG com documentos atualizados.

Conceitos Fundamentais

Árvore de Decisão

Decisão de Arquitetura: Prompt → RAG → Fine-tuning

A régua de decisão é simples: o problema é de instrução (diga como responder)? → mude o system prompt. É de conhecimento (o modelo não sabe o dado)? → use RAG. É de comportamento/estilo (o modelo sabe mas não age como você quer, mesmo com boa instrução)? → considere fine-tuning. Fine-tuning não injeta conhecimento — ajusta pesos para reproduzir um comportamento. Se você fine-tuna para "responder só em JSON estrito", está mudando comportamento. Se você fine-tuna para "saber os procedimentos internos da empresa", está confundindo comportamento com conhecimento — RAG faz isso melhor, mais barato e com dados atualizáveis. Fine-tuning prematuro custa de $1k a $100k, pode obsolescer quando o modelo base é atualizado, e resolve menos do que parece.

Problema de qualidade com LLM base?

│

├── É falta de conhecimento (dados que o modelo não tem)?

│   ├── Dados mudam frequentemente? → RAG (base de conhecimento dinâmica)

│   └── Dados são estáticos e volumosos? → Considerar fine-tuning

│

├── É falta de formato/estilo/tom específico?

│   ├── Prompts longos e repetitivos? → Fine-tuning para reduzir tokens

│   └── Formato complexo mas bem descritível? → System prompt

│

├── É latência/custo?

│   ├── Custo de tokens alto por prompts grandes? → Fine-tuning pode ajudar

│   └── Latência do modelo? → Usar modelo menor (não fine-tuning)

│

└── Já esgotou prompt engineering e RAG?

    ├── Não → VOLTE para prompt engineering primeiro

    └── Sim → Fine-tuning pode ser adequado

Regra de ouro: fine-tuning resolve problemas de comportamento, não de conhecimento.

Quando Fine-Tuning é Necessário

✅ CASOS VÁLIDOS:

- Tom muito específico que não cabe em system prompt (ex: jargão corporativo específico)

- Redução de latência: contexto de 8K tokens → fine-tuned pode fazer com 500 tokens

- Tarefa narrow e repetitiva: classificar tickets de suporte em 50 categorias

- Comportamento que models gerais recusam mas é legítimo no domínio



❌ CASOS ONDE É ARMADILHA:

- "Queremos que o modelo conheça nossa empresa" → use RAG

- "O modelo alucina sobre nossos produtos" → use RAG

- "Queremos respostas mais curtas" → use system prompt

- "A resposta não tem o formato certo" → use output formatting no prompt

Custo Total de Propriedade

def calcular_tco_finetuning(

    n_exemplos: int,

    custo_por_exemplo_geracao: float,    # custo de gerar exemplos com Claude

    custo_treinamento_1000_tokens: float, # OpenAI: $0.008/1K tokens (gpt-4o-mini)

    custo_inferencia_ft: float,           # custo por 1K tokens do modelo FT

    custo_inferencia_base: float,         # custo por 1K tokens do modelo base

    tokens_por_request: int,              # tokens de input no modelo base

    tokens_economizados_ft: int,          # tokens que o FT não precisa

    requests_por_mes: int,

) -> dict:

    custo_criacao_dataset = n_exemplos * custo_por_exemplo_geracao

    

    tokens_treino = n_exemplos * tokens_por_request

    custo_treinamento = (tokens_treino / 1000) * custo_treinamento_1000_tokens

    

    economia_mensal = (tokens_economizados_ft / 1000) * custo_inferencia_base * requests_por_mes

    custo_extra_ft = (custo_inferencia_ft / 1000) * tokens_por_request * requests_por_mes

    

    payback_meses = (custo_criacao_dataset + custo_treinamento) / max(economia_mensal - custo_extra_ft, 0.01)

    

    return {

        'investimento_inicial': round(custo_criacao_dataset + custo_treinamento, 2),

        'economia_mensal': round(economia_mensal, 2),

        'payback_meses': round(payback_meses, 1),

    }



# Exemplo real:

tco = calcular_tco_finetuning(

    n_exemplos=1000,

    custo_por_exemplo_geracao=0.001,   # R$ com haiku

    custo_treinamento_1000_tokens=0.008,

    custo_inferencia_ft=0.000003,      # FT gpt-4o-mini

    custo_inferencia_base=0.000015,    # sonnet com system prompt longo

    tokens_por_request=2000,

    tokens_economizados_ft=1800,       # FT não precisa de 90% do system prompt

    requests_por_mes=50000,

)

# → investimento: ~$9.00

# → economia mensal: ~$1.35

# → payback: ~7 meses

Aprofundamento Técnico

Fine-Tuning vs RAG: Complementaridade

Fine-tuning e RAG não são concorrentes — frequentemente são complementares:

Cenário: Chatbot de suporte para SaaS corporativo



RAG: base de conhecimento com docs de produto atualizados diariamente

Fine-Tuning: tom corporativo específico + formato de resposta padronizado



RAG sem FT: conhecimento atualizado, tom genérico

FT sem RAG: tom certo, mas alucina sobre features lançadas ontem

FT + RAG: tom certo + conhecimento atualizado = solução ideal

Quando o Modelo Menor Supera o Modelo Grande Fine-Tunado

Fine-tuning de gpt-4o-mini em tarefa específica geralmente supera gpt-4o base na mesma tarefa. Isso é contraintuitivo mas consistente: fine-tuning “comprime” o conhecimento necessário para o modelo menor.

Exemplos Anotados

Exemplo 1: Diagnóstico de Problema

Problema: "Nosso chatbot de atendimento responde em inglês às vezes"



Diagnóstico:

- Primeiro, adicionar ao system prompt: "Responda SEMPRE em português, nunca em inglês."

- Se persistir: revisar exemplos de treino que podem ter inglês misturado

- Se o volume de conversas é alto: fine-tuning pode "memorizar" o comportamento PT-BR



Custo/benefício:

- Fix via prompt: 5 minutos, $0

- Fine-tuning: semanas de trabalho, $100-500

Decisão: comece pelo prompt.

Padrões e Armadilhas

Padrões

Padrão 1: “Fine-tuning last” framework Esgote em ordem: prompt engineering → few-shot examples → RAG → fine-tuning.

Padrão 2: Dataset de qualidade vale mais que tamanho 100 exemplos perfeitos > 10.000 exemplos de qualidade mediana.

Armadilhas

⚠️ Armadilha 1: Fine-tuning como solução para alucinações Fine-tuning não elimina alucinações — o modelo ainda inventa fatos não treinados. RAG é a solução.

⚠️ Armadilha 2: Esquecimento catastrófico Fine-tuning intenso em dados estreitos pode fazer o modelo “esquecer” capacidades gerais. Use regularização e mantenha exemplos de capacidades gerais no dataset.

⚠️ Armadilha 3: Dataset com viés de seleção Exemplos gerados pelo próprio modelo base para treinar o modelo → amplifica os erros existentes. Use exemplos humanos ou de alta qualidade como golden set.

⚗ Laboratório prático — mozak.tech
Se não for realizar o laboratório, pule para o próximo capítulo.

Ponte para o Lab

Esta unidade é conceitual. Use os exercícios em exercicios.md para fixar: 1. Dado um cenário, escolher entre prompt engineering, RAG ou fine-tuning 2. Calcular TCO de um caso real do seu contexto

A decisão que você tomar nesta unidade determina se o trabalho das próximas unidades vale a pena.

Agora você está pronto para o lab.