Engenharia de prompt vs. fine-tuning: quando escolher cada um

Fine-tuning não é substituto para dados mal organizados nem para requisitos vagos. Prompt engineering e RAG resolvem uma fatia enorme dos casos com ciclo mais curto. A escolha deve ser econômica e operacional, não ideológica.

O espectro de customização de LLMs

Você tem basicamente quatro níveis de customização, do mais simples ao mais complexo: (1) Prompt engineering: zero-shot ou few-shot, sem treino adicional, (2) RAG (Retrieval-Augmented Generation): injetar conhecimento via contexto recuperado, (3) Fine-tuning: treinar o modelo em dados específicos do seu domínio, (4) Treino do zero: só faz sentido se você for OpenAI, Google ou Anthropic. Vamos focar nos três primeiros.

Quando prompt engineering basta

Prompts bem feitos levam você muito longe. A maioria das aplicações não precisa de fine-tuning. Use prompt engineering quando: o modelo base já tem conhecimento geral suficiente, você precisa iterar rápido e testar hipóteses, o formato de saída pode ser especificado por instruções, e você tem poucos exemplos (< 100) do comportamento desejado.

Técnicas de prompt engineering

Zero-shot: instruções claras sem exemplos (funciona bem com modelos grandes)
Few-shot: incluir 1-5 exemplos no prompt (ajuda a definir formato e tom)
Chain-of-thought: pedir para o modelo 'pensar passo a passo' antes de responder
Self-consistency: gerar múltiplas respostas e escolher a mais frequente
Role prompting: 'você é um especialista em X' para direcionar o comportamento

Limitações do prompt engineering

Prompts têm limites: (1) Contexto finito: você não pode colocar 1000 exemplos no prompt, (2) Custo: few-shot learning consome muitos tokens a cada chamada, (3) Latência: prompts grandes aumentam o tempo de inferência, (4) Conhecimento específico: se o domínio é muito nichado, o modelo pode não ter visto dados suficientes no treino.

Quando RAG é a escolha certa

RAG é a melhor opção quando você precisa injetar conhecimento específico sem retreinar o modelo. Use RAG quando: o conhecimento muda com frequência (políticas, documentos, leis), você precisa de explicabilidade via citação de fontes, os dados são muito volumosos para caber em few-shot, e a tarefa é principalmente question-answering sobre documentos.

Vantagens do RAG

Conhecimento sempre atualizado: basta reindexar documentos novos
Citação de fontes: transparência sobre de onde veio a informação
Sem treino: não precisa de GPUs, datasets rotulados, ou expertise em ML
Controle de acesso: filtrar documentos por permissão do usuário
Modularidade: trocar o retriever ou o LLM independentemente

Limitações do RAG

RAG não é bala de prata: complexidade operacional (mais componentes = mais pontos de falha), latência adicional (embedding + busca + inferência), qualidade depende da recuperação (garbage in, garbage out), e não ensina o modelo tarefas novas (só fornece contexto).

Quando considerar fine-tuning

Fine-tuning faz sentido quando você precisa que o modelo internalize comportamento ou conhecimento específico. Considere fine-tuning quando: você tem milhares de exemplos rotulados de alta qualidade, o formato de saída é altamente específico e consistente, custos de inferência com prompts grandes estão insustentáveis, ou requisitos de privacidade impedem enviar dados a APIs externas.

Tipos de fine-tuning

Full fine-tuning: atualiza todos os pesos do modelo (caro, requer GPU, alto risco de overfitting)
LoRA (Low-Rank Adaptation): treina apenas camadas adapter pequenas (90% mais eficiente que full FT)
QLoRA: LoRA + quantização (treina modelos grandes em GPUs menores)
Instruction tuning: especializar o modelo para seguir instruções em domínio específico
RLHF (Reinforcement Learning from Human Feedback): alinhar o modelo com preferências humanas

Quando fine-tuning resolve problemas que prompt não resolve

Exemplos reais onde FT brilha: (1) Classificação de texto em dezenas de categorias específicas (melhor que few-shot), (2) Extração de entidades muito específicas do domínio (ex: siglas médicas raras), (3) Geração de código em linguagem interna/proprietária, (4) Tom e estilo altamente específico (ex: responder como personagem de marca).

Critérios de decisão

Como decidir entre prompt, RAG e fine-tuning? Use esta árvore de decisão.

1. Você tem dados rotulados?

Menos de 50 exemplos? → Prompt engineering (few-shot)
50-500 exemplos? → Prompt engineering avançado ou RAG se for conhecimento factual
500-5000 exemplos? → Fine-tuning começa a fazer sentido, mas valide com prompt primeiro
Mais de 5000 exemplos de alta qualidade? → Fine-tuning provavelmente vale a pena

2. O conhecimento muda com frequência?

Muda semanalmente/mensalmente? → RAG (reindexar é mais fácil que re-treinar)
Muda raramente (anualmente)? → Fine-tuning pode ser ok
Nunca muda? → Qualquer abordagem funciona

3. Qual é o custo atual de inferência?

Se você está pagando $0.01 por query com prompts enormes e fazendo 100k queries/dia, isso é $1000/dia = $30k/mês. Fine-tuning um modelo menor pode reduzir para $5k/mês. ROI claro.

4. Você precisa de explicabilidade?

Sim, citação de fontes é obrigatória? → RAG
Não, só importa a resposta? → Prompt ou fine-tuning

5. Você tem expertise e infraestrutura de ML?

Não temos time de ML? → Prompt ou RAG (não precisa de ML engineering)
Temos time de ML experiente? → Fine-tuning é viável

Híbrido: combinando as abordagens

Na prática, sistemas de produção combinam múltiplas técnicas. Não é 'prompt OU fine-tuning' — é 'prompt E RAG E fine-tuning onde faz sentido'.

Arquitetura híbrida típica

Exemplo de sistema real: (1) Modelo base fine-tuned para entender o domínio (ex: termos médicos, estilo de resposta), (2) RAG para injetar conhecimento factual atualizado (políticas, regulações), (3) Prompt engineering para controlar formato e comportamento específico de cada endpoint. Cada camada faz o que faz de melhor.

Quando usar fine-tuning + RAG juntos

Fine-tune para tarefa: ensinar o modelo a classificar, extrair, sumarizar no seu domínio
RAG para conhecimento: buscar fatos atualizados para compor a resposta
Prompt para controle: ajustar formato final, tom, validações

Custos: análise real

Vamos comparar custos para um caso típico: chatbot de suporte técnico, 50k queries/mês.

Opção 1: Prompt engineering (GPT-4)

Custo: $0.03 por 1k input tokens + $0.06 por 1k output tokens
Query média: 2k input (prompt + contexto) + 500 output = $0.06 + $0.03 = $0.09/query
50k queries/mês = $4,500/mês
Sem custo de setup ou treino

Opção 2: RAG com modelo menor (GPT-3.5)

Custo LLM: $0.0015 input + $0.002 output por 1k tokens
Custo embedding: $0.0001 por 1k tokens
Custo vector DB (Pinecone): ~$70/mês para 50k queries
Query média: 1.5k input + 300 output = ~$0.003/query
50k queries/mês = $150 + $70 = $220/mês
Custo de setup: configurar pipeline, indexar docs (~semanas de eng)

Opção 3: Fine-tuning (GPT-3.5)

Custo de treino: $0.008 por 1k tokens (one-time, ~$100-500)
Custo de inferência: 2x o preço base = $0.003 input + $0.004 output
Query média: 500 input + 200 output = ~$0.0023/query
50k queries/mês = $115/mês + custo one-time de treino
Custo de setup: coletar e rotular dados, treinar, avaliar (~meses de trabalho)

Roadmap incremental

Não comece com fine-tuning. Comece simples e evolua conforme necessário.

Fase 1: Validação (semanas 1-4)

Prompt engineering com modelo base
Iterar rapidamente com few-shot
Validar product-market fit: alguém usa e acha útil?
Coletar queries reais para entender casos de uso

Fase 2: Conhecimento (meses 2-3)

Implementar RAG se precisar de conhecimento específico
Iterar chunking, retrieval, prompts
Medir latência, custo, acurácia
Coletar feedback de usuários e casos de falha

Fase 3: Especialização (meses 4-6)

Considerar fine-tuning SE: (a) você tem > 1000 exemplos rotulados de qualidade, (b) custos de RAG estão altos, (c) acurácia/formato precisam melhorar além do que RAG entrega
Começar com LoRA/QLoRA antes de full fine-tuning
A/B test: comparar fine-tuned vs prompt+RAG antes de comprometer

Conclusão

Escolha a ferramenta mais simples que resolve o problema. Prompt engineering > RAG > fine-tuning em termos de velocidade de iteração e custo de manutenção. Fine-tuning só se justifica quando você tem volume, dados, expertise e ROI claro.

E lembre-se: o modelo é só uma parte do sistema. Às vezes, o gargalo não é o LLM — é a qualidade dos dados, a clareza dos requisitos, ou a experiência do usuário. Resolve isso antes de partir para fine-tuning.