🎯 Quando usar: Fine-tuning vs RAG vs Prompt Engineering

Decisão central em AI Engineering. Escolher mal = custo alto ou solução que não escala.

---

Árvore de decisão (usa isto primeiro)

1. O problema é conhecimento? (factos, docs, dados que mudam)
   → SIM: RAG
   → NÃO: continua

2. O problema é formato/estilo/consistência?
   → Resolve com prompt (few-shot, instruções)?
   → SIM: Prompt Engineering
   → NÃO: continua

3. O problema é comportamento/tarefa específica?
   → Tens 500+ exemplos?
   → SIM: LoRA/QLoRA (fine-tuning)
   → NÃO: tenta prompt ou gera mais dados

4. Conhecimento + comportamento?
   → RAG (conhecimento) + Prompt (comportamento)
   → Ou RAG + LoRA se o modelo não segue instruções bem

---

Tabela comparativa

---

Exemplos concretos

Usar Prompt Engineering

• Tradução, sumarização, classificação (modelo já sabe)
• Formato JSON específico (instruções + exemplo)
• "Responde em 2 frases" (instrução)
• Few-shot com 3 exemplos resolve

Usar RAG

• Perguntas sobre documentação da empresa
• Base de conhecimento que atualiza semanalmente
• Dados internos (tickets, contratos)
• Factos que o modelo não sabe (cutoff, domínio nicho)

Usar Fine-tuning (LoRA)

• Modelo não segue instruções bem (base model)
• Formato de output muito específico (ex: sempre bullet points)
• Tom/estilo consistente (ex: suporte técnico formal)
• Tarefa que few-shot não resolve com 5 exemplos
• Domínio com jargão (modelo confunde termos)

Usar RAG + Prompt

• Maioria dos casos: RAG para contexto + prompt para formato
• Ex: "Com base nos documentos abaixo, responde em português, máximo 3 parágrafos"

Usar RAG + Fine-tuning

• RAG para conhecimento + LoRA para o modelo seguir melhor as instruções do teu domínio
• Ou: embedding model fine-tuned + RAG (retrieval no domínio)

---

Erros comuns

---

Frase para entrevista

Sempre começo por prompt engineering — resolve 80% dos casos sem custo. Se o problema é conhecimento que muda, RAG. Se é comportamento ou formato que o prompt não resolve, LoRA. Evito full fine-tuning a menos que tenha muitos dados e um problema muito específico.

---

Exemplos práticos reais — para entender e explicar

Cenários concretos que podes usar para explicar em entrevista.

---

Exemplo 1: Prompt Engineering

Cenário: Startup de e-commerce. Queres que o chatbot classifique intenções: "comprar", "devolução", "dúvida produto".

Porquê prompt: O modelo já sabe classificar. Basta few-shot com 3 exemplos por categoria. Zero custo, implementas em 1 hora.

Prompt: "Classifica a intenção do utilizador. Exemplos: 'Quero devolver' → devolução. 'Qual o prazo de entrega?' → dúvida. 'Adicionar ao carrinho' → comprar."

Como explicar: Comecei por prompt com few-shot. O GPT-4 já classifica bem; 9 exemplos foram suficientes. Zero treino, iteramos o prompt em minutos.

---

Exemplo 2: RAG

Cenário: Empresa de seguros. Os colaboradores fazem perguntas sobre apólices, regulamento interno, FAQs. A documentação atualiza-se mensalmente.

Porquê RAG: O conhecimento está em PDFs e Confluence. Muda frequentemente. Fine-tuning seria absurdo — retreinar cada vez que há atualização.

Implementação: Chunking dos docs → embeddings → Pinecone. Query → retrieval → contexto no prompt → LLM responde.

Como explicar: O problema era conhecimento que muda. RAG permite atualizar sem retreinar — basta reindexar os documentos. O LLM não foi treinado; recebe o contexto em runtime.

---

Exemplo 3: LoRA

Cenário: Empresa de saúde. Precisas que o modelo preencha relatórios clínicos num formato muito específico (campos obrigatórios, terminologia médica, tom formal). Few-shot com 10 exemplos não chega — o modelo às vezes inventa campos ou usa linguagem informal.

Porquê LoRA: Comportamento e formato específicos. Tens 2000 exemplos anotados por médicos. O modelo base (Llama, Mistral) não segue o formato de forma consistente.

Implementação: Dataset (instrução, relatório correto). LoRA r=16 em q_proj, v_proj. Treino em A100 40GB. Adapter de 50MB em vez de modelo de 7GB.

Como explicar: O prompt não garantia consistência — o modelo inventava campos. Com 2000 exemplos, fiz LoRA para adaptar o comportamento ao nosso formato. Treinei só 0.1% dos parâmetros; o adapter é pequeno e fácil de versionar.

---

Exemplo 4: QLoRA

Cenário: Mesmo caso do Exemplo 3, mas a empresa só tem uma GPU RTX 3080 (10GB). LoRA em fp16 não cabe.

Porquê QLoRA: Quantizas o modelo base a 4-bit. O modelo cabe em 10GB. Os adapters LoRA ficam em fp16. Treinas na mesma GPU.

Implementação: BitsAndBytesConfig(load_in_4bit=True) + LoraConfig. Mesmo dataset. Treino em 10GB.

Como explicar: Não tínhamos GPU grande. Usei QLoRA — o modelo base em 4-bit, só os adapters em fp16. Treinei Llama 7B numa 3080. Qualidade quase igual ao LoRA em fp16.

---

Exemplo 5: RAG + LoRA (combinado)

Cenário: Consultora. Assistente que responde sobre projetos internos (RAG) mas deve usar sempre tom profissional e estruturar respostas em "Contexto | Ação | Próximos passos".

Porquê os dois: RAG traz o conhecimento (docs dos projetos). LoRA adapta o formato e tom — o modelo base às vezes responde de forma desestruturada.

Implementação: RAG para retrieval. LoRA pequeno (r=8) treinado em 500 exemplos de respostas bem formatadas. Em inferência: RAG injeta contexto + prompt com instrução de formato. O LoRA garante que segue.

Como explicar: RAG para o conhecimento dos projetos; LoRA para o modelo seguir o nosso formato de resposta. O RAG atualiza-se quando há novos docs; o LoRA treinámos uma vez.

---

Resumo dos exemplos