Fine-tuning vs RAG vs Prompting
Quando usar cada abordagem para adaptar LLMs ao seu domínio. Decision tree prático.
Definição
Três estratégias para especializar LLMs: Prompting (instrução no sistema prompt, zero custo, zero persistência), RAG (recuperar conhecimento externo em runtime, dados dinâmicos e rastreáveis), Fine-tuning (treinar nos seus dados, modifica os pesos, comportamento consistente, custo de treinamento). Não são mutuamente exclusivas: fine-tuning + RAG é um padrão comum.
Problema → Solução
Problema
Usar fine-tuning quando prompting seria suficiente (custo desnecessário). Ou usar apenas prompting quando o domínio é muito especializado e os dados privados são críticos (qualidade baixa). Ou RAG quando o problema é de estilo/comportamento (RAG não resolve isso).Solução
Decision tree: 1) Resolvo com prompting? (tarefa comum, formato simples) → use prompting. 2) Preciso de dados privados/atualizados? → use RAG. 3) Preciso de comportamento consistente, estilo específico, ou conhecimento muito especializado difícil de prompt? → fine-tuning. 4) Preciso de dados privados E estilo consistente? → fine-tuning + RAG.Dica de entrevista
Tip
Fine-tuning ensina comportamento e estilo. RAG ensina conhecimento. Se o problema é "o modelo não sabe sobre minha empresa" → RAG. Se o problema é "o modelo não responde no tom/formato que quero" → fine-tuning. Se o problema é "o modelo não sabe um conceito técnico obscuro" → fine-tuning ou RAG dependendo de quantos dados você tem.Código
// Decision tree para escolha de estratégia
// ✅ Apenas prompting — tarefa comum, sem dados privados
const response = await openai.chat.completions.create({
model: 'gpt-4o',
messages: [
{ role: 'system', content: 'Você é um especialista em React. Responda de forma concisa e técnica.' },
{ role: 'user', content: userQuestion }
]
})
// ✅ RAG — dados privados, base de conhecimento dinâmica
const chunks = await vectorStore.similaritySearch(question, 5)
const context = chunks.map(c => c.pageContent).join('\n')
// → inserir context no prompt
// ✅ Fine-tuning — formato/estilo muito específico
// Preparar JSONL dataset:
// {"messages": [
// {"role": "system", "content": "Você analisa tickets de suporte..."},
// {"role": "user", "content": "Cliente diz: produto não funciona"},
// {"role": "assistant", "content": "Categoria: BUG | Prioridade: ALTA | Ação: escalar para eng"}
// ]}
// Verificar se é problema de conhecimento ou comportamento:
// "Ele não sabe X" → RAG ou fine-tuning com dados de X
// "Ele não responde como eu quero" → fine-tuning ou melhorar prompting
// "Os dados mudam frequentemente" → RAG (não fine-tuning)Perguntas de entrevista
Q.Qual o custo real do fine-tuning?▾
A.OpenAI fine-tuning GPT-4o-mini: ~$25/1M tokens de treino + inferência mais cara. Custo de dados: preparar dataset de qualidade (centenas de exemplos) leva dias de trabalho humano. Custo de manutenção: quando o modelo base é atualizado, você retreina. Comparar com RAG: setup mais simples, sem retreinamento, mas latência um pouco maior por chamada.
Q.Quantos exemplos são necessários para fine-tuning?▾
A.OpenAI recomenda mínimo 50, ideal 500-1000 exemplos de alta qualidade. Qualidade > quantidade: 100 exemplos perfeitos supera 1000 exemplos mediocres. Para tarefas de classificação: mais exemplos por classe. Para geração com formato específico: poucos exemplos podem ser suficientes (50-100). Para conhecimento factual: fine-tuning é menos eficaz que RAG.
Q.O que é instruction tuning vs RLHF?▾
A.Instruction tuning: fine-tuning com pares instruction-response para seguir instruções. É o que cria modelos como GPT-3.5-turbo a partir do GPT-3. RLHF (Reinforcement Learning from Human Feedback): treinar com feedback humano de qual resposta é melhor. Mais complexo, cria modelos mais alinhados (ChatGPT, Claude). Como dev, você geralmente faz instruction tuning, não RLHF.
93/122← →