Por que a escolha importa
Adaptar um LLM para um caso de uso pode seguir três caminhos principais: prompt engineering (instruir o modelo no contexto), RAG (recuperar documentos externos) ou fine-tuning (ajustar pesos do modelo com dados rotulados). Cada um tem custo, complexidade e trade-offs diferentes.
Escolher errado custa caro. Fine-tuning em dados que mudam toda semana exige retreino constante. RAG para uma tarefa ultra-estreita com latência crítica pode ser lento demais. Prompt engineering sozinho falha quando o conhecimento necessário excede a janela de contexto.
Não existe resposta universal — a decisão depende de como seus dados se comportam, quão específica é a tarefa e quais restrições de infraestrutura você tem.
Comparando as três abordagens
| Dimensão | Prompt engineering | RAG | Fine-tuning | |----------|-------------------|-----|-------------| | Custo inicial | Baixo | Médio | Alto | | Dados atualizáveis | Sim (manual) | Sim (reindexar) | Não (retreinar) | | Conhecimento externo | Limitado à janela | Ilimitado (via retrieval) | Embutido no modelo | | Latência | Baixa | Média (retrieval + LLM) | Baixa | | Esforço de manutenção | Baixo | Médio | Alto | | Tom de voz / estilo | Parcial | Parcial | Forte |
Selecione os cenários que se aplicam ao seu projeto
Use a demo acima para mapear cenários do seu projeto. Selecione as condições que se aplicam e veja qual abordagem pontua mais alto — é um ponto de partida, não uma decisão automática.
Prompt engineering: comece aqui
Prompt engineering é ajustar instruções, exemplos few-shot e formato de saída sem alterar o modelo. É o caminho mais rápido para validar se um LLM generalista resolve o problema.
Funciona bem quando:
- A tarefa cabe na janela de contexto com poucos exemplos
- O conhecimento necessário é genérico (não proprietário)
- Você precisa de resultado em horas, não semanas
- O tom de voz pode ser definido via system prompt
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_messages([
("system", """Você é um assistente de suporte interno.
Responda apenas com base no contexto fornecido.
Se não souber, diga explicitamente que não tem informação suficiente.
Use tom formal e objetivo."""),
("human", "Contexto:\n{context}\n\nPergunta: {question}"),
])
chain = prompt | ChatOpenAI(model="gpt-4o-mini")
Limites: conhecimento proprietário extenso, estilo muito específico ou tarefas que exigem formato rígido podem precisar de mais.
RAG: conhecimento externo e atualizável
RAG recupera documentos relevantes em tempo real e os passa como contexto ao LLM. Cobrimos o pipeline em detalhe no post sobre RAG na prática.
Funciona bem quando:
- Dados mudam com frequência (políticas, manuais, bases de conhecimento)
- O volume de conhecimento excede a janela de contexto
- Você precisa citar fontes (auditabilidade)
- O conhecimento é factual, não comportamental
Não é ideal quando:
- Latência abaixo de 300ms é obrigatória e o retrieval adiciona overhead
- A tarefa é transformação de estilo/tom sem necessidade de fatos externos
- Qualidade do retrieval é impossível de garantir (dados muito ruidosos)
RAG combina bem com prompt engineering — o prompt define como responder; o retrieval define com o quê.
Fine-tuning: adaptar o comportamento do modelo
Fine-tuning ajusta pesos do modelo com exemplos rotulados (input → output desejado). Com LoRA e PEFT, o custo cai drasticamente — você treina adaptadores pequenos em vez do modelo inteiro.
Funciona bem quando:
- Tarefa estreita e repetitiva (classificação de intent, extração estruturada, formatação)
- Tom de voz ou estilo muito específico e consistente
- Latência crítica — modelo fine-tuned dispensa retrieval
- Dataset rotulado de qualidade disponível (centenas a milhares de exemplos)
# Conceito com Hugging Face PEFT + LoRA
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.2-1B")
lora_config = LoraConfig(
r=16, # rank — capacidade do adaptador
lora_alpha=32, # escala
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
)
model = get_peft_model(model, lora_config)
# Treinar com dataset de pares (instruction, response)
Não é ideal quando:
- Dados de conhecimento mudam semanalmente — cada mudança exige retreino ou combinação com RAG
- Dataset rotulado é pequeno ou ruidoso — overfitting garantido
- Orçamento de GPU e MLOps é limitado
Combinações que funcionam na prática
As abordagens não são mutuamente exclusivas:
- RAG + prompt engineering — o padrão mais comum em Q&A corporativo
- Fine-tuning + RAG — modelo fine-tuned para formato/tom + retrieval para fatos atualizados
- Fine-tuning do encoder — melhora retrieval em domínios muito específicos (jurídico, médico)
- Prompt + evals — baseline antes de investir em RAG ou fine-tuning
Ordem recomendada de investimento:
Prompt engineering → evals → RAG (se precisar de conhecimento externo) → fine-tuning (se precisar de comportamento específico)
Cada etapa adiciona complexidade. Só avance quando a anterior não resolve com métricas aceitáveis.
Árvore de decisão rápida
Perguntas em sequência:
- O LLM generalista resolve com bom prompt? → Sim: pare aqui
- Precisa de conhecimento que não está no modelo e muda com frequência? → Sim: RAG
- Precisa de comportamento/formato muito específico com dataset rotulado? → Sim: fine-tuning (LoRA)
- Precisa dos dois? → RAG + fine-tuning leve no formato de resposta
Além do básico: pontos de atenção
Erros comuns na escolha:
- Fine-tuning para substituir RAG — modelo não "lembra" documentos novos; use RAG para fatos, fine-tune para comportamento
- RAG sem evals de retrieval — fine-tuning do prompt não conserta chunks errados
- Prompt engineering infinito — dezenas de regras no system prompt viram manutenção impossível
- Ignorar custo total — fine-tuning tem custo de treino + deploy; RAG tem custo de embedding + vector store + LLM
Métricas para decidir:
- Prompt: qualidade da resposta em 10–20 casos de teste
- RAG: context precision + faithfulness (post de evals)
- Fine-tuning: loss de validação + qualidade em holdout + comparação com baseline
Conclusão
Prompt engineering é o ponto de partida. RAG resolve conhecimento externo e atualizável. Fine-tuning adapta comportamento e estilo quando você tem dados rotulados e tarefa estreita.
Use a demo de cenários para orientar a discussão, valide com evals em cada etapa, e combine abordagens quando necessário. A maioria dos sistemas corporativos maduros usa RAG + prompt engineering; fine-tuning entra quando o formato ou tom exige consistência que o prompt sozinho não alcança.