Fine-tuning vs RAG vs Prompt Engineering: quando usar cada abordagem

Quando a IA “quase funciona” mas não funciona de verdade

Janeiro de 2024. Rafael Campos, CTO da LegalTech Solutions (startup com 45 funcionários focada em análise de contratos), estava frustrado.

Ele havia implementado um assistente de IA para analisar cláusulas contratuais usando GPT-4 direto da API. Funcionava… mais ou menos.

O problema:

• 40% das análises estavam corretas e impressionantes
• 35% estavam “quase corretas” mas com erros críticos (identificava cláusula errada, interpretava mal conceitos jurídicos)
• 25% estavam completamente equivocadas (inventava jurisprudência, citava leis inexistentes)

“O pior é que não dava para confiar”, explica Rafael. “Quando funciona 40% do tempo, você precisa revisar 100% das saídas. Ou seja: não economiza nada. Só adiciona trabalho.”

Rafael pesquisou soluções. Encontrou três abordagens diferentes:

1. Melhorar os prompts (prompt engineering)
2. Adicionar base de conhecimento (RAG - Retrieval-Augmented Generation)
3. Treinar o modelo (fine-tuning)

Ele não sabia qual escolher. Cada artigo dizia uma coisa diferente. Uns defendiam RAG, outros diziam que fine-tuning era essencial, outros garantiam que “prompt engineering bem feito resolve tudo”.

Rafael escolheu testar as três abordagens sistematicamente.

Resultados após 6 semanas de testes:

• Apenas melhorar prompts: acurácia subiu de 40% para 58% (melhora, mas insuficiente)
• RAG (base de conhecimento + busca): acurácia de 79% (dramática melhora)
• Fine-tuning: acurácia de 71% (melhor que prompt puro, pior que RAG)
• RAG + Fine-tuning combinados: acurácia de 91% (melhor de todos, mas mais complexo)

A solução final? RAG puro. Custo-benefício imbatível para o caso dele.

Este artigo explica exatamente quando usar cada abordagem, com exemplos práticos e frameworks de decisão baseados em casos reais.

As três abordagens fundamentais: o que são e como funcionam

Prompt Engineering: a arte de fazer boas perguntas

O que é:

Prompt engineering é simplesmente a prática de escrever instruções (prompts) otimizadas para obter melhores resultados de modelos de linguagem.

Como funciona:

Você usa o modelo de IA “como está” (zero alteração no modelo), mas cria prompts mais eficazes.

Exemplo básico vs otimizado:

❌ Prompt básico:

Analise este contrato e me diga se há problemas.

✅ Prompt otimizado:

Você é um advogado especializado em contratos B2B com 15 anos de experiência.

Analise o contrato abaixo procurando especificamente por:
1. Cláusulas de rescisão desfavoráveis ao contratante
2. Penalidades desproporcionais
3. Obrigações abertas ou mal definidas
4. Prazos impraticáveis

Para cada item identificado:
- Cite a cláusula específica (número e texto)
- Explique o risco
- Sugira redação alternativa

Contrato:
[texto do contrato]

Formato de saída:
[JSON estruturado especificado]

Técnicas comuns:

1. Definir persona/papel: “Você é um especialista em…”
2. Dar contexto: “Você está ajudando uma empresa de médio porte que…”
3. Few-shot examples: mostrar exemplos do que você espera
4. Instruções step-by-step: quebrar tarefa complexa em passos
5. Especificar formato de saída: JSON, markdown, etc.
6. Chain-of-thought: pedir que “pense passo a passo”

Vantagens:

• Zero custo adicional
• Implementação imediata (minutos/horas)
• Fácil de iterar e testar
• Sem manutenção complexa

Limitações:

• Não adiciona conhecimento novo ao modelo
• Limitado pelo contexto (comprimento do prompt)
• Pode ser inconsistente (mesma pergunta, respostas diferentes)
• Depende de habilidade de escrever bons prompts

RAG (Retrieval-Augmented Generation): dar ao modelo o conhecimento que ele precisa

O que é:

RAG significa “Geração Aumentada por Recuperação”. Na prática: buscar informação relevante e incluir no prompt.

Como funciona:

1. Você cria uma base de conhecimento (documentos, manuais, dados proprietários)
2. Quando usuário faz uma pergunta, sistema busca informação relevante
3. Informação recuperada é incluída no prompt
4. Modelo responde baseado nessa informação

Exemplo concreto:

Usuário pergunta: “Como configurar autenticação SSO?”

Sem RAG:

• GPT responde de forma genérica
• Pode inventar passos que não aplicam ao seu produto
• Ou dizer “não tenho informações específicas”

Com RAG:

1. Sistema busca em sua documentação interna
2. Encontra: “Manual de SSO - Configuração passo a passo”
3. Inclui esse conteúdo no prompt
4. GPT responde especificamente para seu produto

Arquitetura simplificada:

Usuário: "Como fazer X?"
    ↓
[Sistema de busca semântica]
    ↓
Encontra documentos relevantes em sua base
    ↓
[Monta prompt]
Contexto: [documentos encontrados]
Pergunta: Como fazer X?
    ↓
[LLM (GPT-4, Claude, etc)]
    ↓
Resposta específica baseada em seus documentos

Vantagens:

• Adiciona conhecimento atualizado/proprietário
• Pode citar fontes (rastreabilidade)
• Fácil de atualizar (só adicionar novos documentos)
• Reduz alucinações drasticamente
• Custo moderado

Limitações:

• Depende de qualidade da base de conhecimento
• Precisa de sistema de busca semântica (embeddings)
• Limitado pelo tamanho de contexto do modelo
• Complexidade técnica moderada

Fine-tuning: ensinar o modelo com seus dados

O que é:

Fine-tuning é re-treinar um modelo existente com seus próprios dados para especializá-lo.

Como funciona:

1. Você prepara dataset de treinamento (pares: input → output desejado)
2. Modelo “aprende” padrões específicos dos seus dados
3. Modelo fine-tuned se comporta de forma mais alinhada ao seu caso de uso

Exemplo concreto:

Empresa quer modelo que classifique tickets de suporte em 12 categorias específicas.

Dataset de treinamento (simplificado):

[
  {
    "messages": [
      {"role": "system", "content": "Classifique tickets de suporte."},
      {"role": "user", "content": "Não consigo fazer login"},
      {"role": "assistant", "content": "Categoria: Autenticação"}
    ]
  },
  {
    "messages": [
      {"role": "system", "content": "Classifique tickets de suporte."},
      {"role": "user", "content": "Como exporto relatório em Excel?"},
      {"role": "assistant", "content": "Categoria: Relatórios"}
    ]
  }
  // ... 500-5000 exemplos similares
]

Após fine-tuning com 2.000 exemplos reais, modelo aprende:

• Vocabulário específico da sua empresa
• Padrões de como seus clientes descrevem problemas
• Nuances entre categorias que são específicas do seu produto

Vantagens:

• Modelo se especializa no seu domínio
• Pode reduzir tamanho de prompts (economia)
• Consistência maior em tarefas repetitivas
• Pode capturar padrões sutis

Limitações:

• Custo alto (treinamento + preparação de dados)
• Complexidade técnica alta
• Requer dataset grande e de qualidade (500-5000+ exemplos)
• Atualizar conhecimento requer novo fine-tuning
• Risco de overfitting (modelo “decora” ao invés de generalizar)

Comparação lado a lado: quando usar cada abordagem

Matriz de decisão rápida

Critério	Prompt Engineering	RAG	Fine-tuning
Complexidade	Baixa	Média	Alta
Custo setup	R$ 0	R$ 5k - R$ 40k	R$ 15k - R$ 100k+
Custo operacional/mês	R$ 50 - R$ 500	R$ 300 - R$ 2k	R$ 500 - R$ 5k+
Tempo de implementação	Horas/dias	2-6 semanas	6-12 semanas
Adicionar conhecimento novo	Não	Sim (fácil)	Sim (difícil)
Atualizar conhecimento	Imediato	Imediato	Requer re-treinar
Tamanho dataset necessário	0	50-500 docs	500-5000+ exemplos
Reduz alucinações	Pouco	Muito	Médio
Melhora tom/estilo	Médio	Pouco	Muito
Consistência	Baixa-Média	Média-Alta	Alta

Quando usar Prompt Engineering

✅ Use prompt engineering quando:

1. Tarefa de propósito geral

   • Resumir textos
   • Traduzir
   • Responder perguntas gerais
   • Gerar ideias

2. Você está começando/testando

   • Validando se IA resolve seu problema
   • Proof of concept
   • MVP

3. Orçamento zero ou muito limitado

   • Sem budget para infra/desenvolvimento
   • Precisa de resultados imediatos

4. Conhecimento necessário cabe no prompt

   • Suas instruções cabem em 1-2 páginas
   • Não precisa de dados proprietários extensos

❌ Não use apenas prompt engineering quando:

• Modelo precisa de conhecimento proprietário extenso
• Consistência é crítica (compliance, legal)
• Taxa de erro mais de 20% é inaceitável
• Tarefas altamente especializadas/técnicas

Exemplo de sucesso: Email drafting

Empresa usa GPT-4 para ajudar equipe de vendas a escrever emails personalizados.

Solução: Prompt engineering puro

Você é um especialista em vendas B2B consultivas.

Escreva um email de follow-up para [prospect], considerando:
- Reunião anterior abordou: [tópicos]
- Próximo passo desejado: [ação]
- Tom: profissional mas cordial
- Tamanho: máximo 150 palavras

[Dados do prospect]

Por que funcionou apenas com prompts:

• Não precisa de dados proprietários além do contexto fornecido
• Tarefa relativamente genérica (escrever email)
• Qualidade “boa o suficiente” (não precisa ser perfeita)
• Custo zero vs complexidade de RAG/fine-tuning

Quando usar RAG

✅ Use RAG quando:

1. Precisa de conhecimento proprietário/atualizado

   • Documentação interna
   • Manuais de produtos
   • Políticas da empresa
   • Dados que mudam frequentemente

2. Rastreabilidade é importante

   • Precisa citar fontes
   • Auditoria é necessária
   • Compliance exige transparência

3. Base de conhecimento já existe

   • Você tem documentação
   • Wikis, manuais, FAQs
   • Apenas precisa torná-los acessíveis via IA

4. Conhecimento é grande demais para prompts

   • Milhares de páginas de documentação
   • Não cabe em janela de contexto

5. Reduzir alucinações é crítico

   • Respostas precisam ser factuais
   • Inventar informação é inaceitável

❌ Não use RAG quando:

• Base de conhecimento não existe (e criá-la seria muito caro)
• Documentos são desorganizados/incompletos
• Tarefa não depende de conhecimento factual específico
• Orçamento muito limitado (menos de R$ 10k para implementar)

Exemplo de sucesso: Suporte técnico da SoftwareHouse

Empresa com 300 clientes e 2.000 artigos de documentação implementou RAG.

Antes (apenas prompts):

• Cliente: “Como integrar com Salesforce?”
• GPT: responde genericamente sobre integrações Salesforce
• Problema: não era específico para o produto deles

Depois (com RAG):

1. Sistema busca em documentação: “Integração Salesforce - Guia Completo”
2. Inclui no prompt
3. GPT responde especificamente para o produto deles, citando seções relevantes

Resultados:

• Taxa de resolução no primeiro contato: 34% → 71%
• Satisfação com respostas: CSAT de 6,2 → 8,4
• Redução de 58% em tickets repetitivos

Por que RAG foi a escolha certa:

• Documentação já existia (2.000 artigos)
• Precisava de respostas específicas ao produto
• Rastreabilidade importante (citar artigo específico)
• Conhecimento mudava frequentemente (fácil de atualizar)

Quando usar Fine-tuning

✅ Use fine-tuning quando:

1. Tarefa muito específica e repetitiva

   • Classificação de tickets
   • Extração de dados estruturados
   • Categorização de documentos
   • Análise de sentimento em contexto específico

2. Tom/estilo/formato é crítico

   • Precisa responder exatamente como sua marca
   • Formato de saída muito específico
   • Vocabulário/jargão particular

3. Volume altíssimo (economia de custo)

   • Milhões de chamadas de API/mês
   • Fine-tuned models são mais baratos por chamada
   • Prompts menores = menos tokens = custo menor

4. Você tem dataset grande e de qualidade

   • 1.000+ exemplos de input/output perfeitos
   • Dados representativos do uso real
   • Recursos para preparar dados corretamente

5. Latência é crítica

   • Fine-tuned models podem ser menores/mais rápidos
   • Não depende de busca (RAG adiciona latência)

❌ Não use fine-tuning quando:

• Dataset pequeno (menos de 500 exemplos de qualidade)
• Conhecimento muda frequentemente (atualizar é caro)
• Primeiro projeto de IA (complexidade desnecessária)
• Budget limitado
• Não tem expertise técnico (ML/data science)

Exemplo de sucesso: Classificação de NFs da ContabilTech

Empresa de contabilidade digital processa 50.000 notas fiscais/mês que precisam ser categorizadas em 45 categorias contábeis.

Tentativa 1: Apenas prompts

• Acurácia: 62%
• Custo: R$ 8.200/mês (prompts grandes)

Tentativa 2: RAG

• Acurácia: 68%
• Custo: R$ 6.800/mês
• Melhora marginal

Solução final: Fine-tuning

• Criaram dataset com 4.500 NFs manualmente categorizadas
• Fine-tuned GPT-3.5-turbo
• Acurácia: 94%
• Custo: R$ 2.400/mês (prompts muito menores + modelo mais barato)

Por que fine-tuning foi a escolha certa:

• Tarefa altamente específica e repetitiva
• Dataset grande disponível (anos de dados históricos)
• Volume justificava investimento
• ROI: investimento de R$ 45k se pagou em 6 meses

Combinando abordagens: quando 1+1=3

RAG + Prompt Engineering: a combinação mais comum

Quando faz sentido:

Praticamente sempre que você usa RAG, também usa prompt engineering. São complementares:

• RAG: fornece conhecimento relevante
• Prompt engineering: instrui como usar esse conhecimento

Exemplo:

# RAG: buscar documentos relevantes
documentos = buscar_em_base_de_conhecimento(pergunta_usuario)

# Prompt engineering: instruir como usar
prompt = f"""
Você é um assistente de suporte técnico.

Use APENAS as informações abaixo para responder.
Se a resposta não estiver nos documentos, diga "não tenho essa informação".

Documentos:
{documentos}

Pergunta: {pergunta_usuario}

Responda de forma:
- Direta e concisa
- Citando o documento específico
- Em português brasileiro
"""

Resultado: melhor de ambos os mundos

• Acurácia do RAG
• Controle de tom/formato do prompt engineering

Fine-tuning + RAG: especialização + conhecimento atualizado

Quando faz sentido:

• Você precisa de conhecimento atualizado (RAG)
• E também de comportamento muito específico (fine-tuning)
• E tem budget para ambos

Exemplo: Assistente médico especializado

Uma empresa de tecnologia para clínicas implementou:

Fine-tuning para:

• Aprender linguagem médica específica
• Entender abreviações da especialidade
• Formato de saída (CID, TUSS, etc.)

RAG para:

• Protocolos clínicos atualizados
• Diretrizes que mudam periodicamente
• Base de casos similares

Resultado:

• Fine-tuning garante “fala como médico deveria falar”
• RAG garante “informação está atualizada e correta”

Trade-off:

• Complexidade: alta
• Custo: R$ 80k setup + R$ 4k/mês
• Mas ROI justificou (mercado de healthtech)

Quando NÃO combinar (KISS principle)

Começar com a solução mais simples que funciona:

1. Primeiro: otimizar prompts
2. Se insuficiente: adicionar RAG
3. Se ainda insuficiente: considerar fine-tuning

Muitas empresas pulam direto para fine-tuning sem validar se RAG resolve.

Regra prática:

• 70% dos casos: RAG + prompts resolve
• 20% dos casos: apenas prompts resolve
• 10% dos casos: fine-tuning adiciona valor significativo

Caso real: LegalTech escolhe entre as três abordagens

Problema inicial e tentativas

Contexto:

• LegalTech Solutions: startup com 45 funcionários
• Produto: análise automatizada de contratos B2B
• Volume: 800-1.200 contratos analisados/mês
• Problema: precisão de apenas 40% com prompts básicos

Por que importava:

Advogados não podem confiar em sistema com 40% de acurácia:

• Erro pode custar milhões (cláusula problemática não identificada)
• Reputação da empresa em jogo
• Clientes pagam pelo serviço: esperavam qualidade

Teste sistematizado das três abordagens

Rafael, o CTO, criou metodologia rigorosa:

Dataset de validação:

• 100 contratos reais, manualmente analisados por 3 advogados
• Consenso sobre: cláusulas problemáticas, riscos, interpretações
• “Ground truth” para comparar resultados

Métricas:

• Acurácia: % de análises corretas
• Recall: % de cláusulas problemáticas identificadas
• Precision: % das cláusulas identificadas que eram realmente problemáticas
• Custo: R$/contrato analisado
• Tempo de implementação
• Esforço de manutenção

Abordagem 1: Aprimorar prompt engineering (2 semanas)

Investimento:

• 40 horas de Rafael otimizando prompts
• Custo: R$ 0 adicional (tempo interno)

Evolução:

Prompt v1 (baseline):

Analise o contrato e identifique cláusulas problemáticas.

Resultado: 40% acurácia

Prompt v2:

Você é um advogado especialista em contratos B2B.
Analise o contrato procurando:
[lista de 12 tipos de cláusulas]

Para cada cláusula problemática, retorne:
[JSON estruturado]

Resultado: 52% acurácia (+30% melhora)

Prompt v3 (após muitas iterações):

Você é um advogado sênior com 15 anos de experiência em contratos B2B,
especialmente contratos de software/tecnologia.

CONTEXTO:
Você está revisando contratos para empresas de médio porte (50-500 funcionários)
que estão contratando serviços B2B. Seu objetivo é proteger os interesses do CONTRATANTE.

ANÁLISE PASSO A PASSO:

1. Leia o contrato inteiro primeiro
2. Identifique as seguintes cláusulas problemáticas:
   [lista detalhada com exemplos]
3. Para cada uma, avalie gravidade (baixa/média/alta)

[Mais 15 linhas de instruções detalhadas]

[Few-shot examples: 3 exemplos de análises perfeitas]

FORMATO DE SAÍDA:
[JSON schema detalhado]

Resultado: 58% acurácia (+45% vs baseline)

Conclusão:

• Melhora significativa, mas insuficiente
• Prompts estavam gigantes (custando mais por análise)
• Inconsistência permanecia (mesmo contrato, resultados diferentes)

Abordagem 2: Implementar RAG (4 semanas)

Investimento:

• 2 semanas de desenvolvimento
• R$ 12.000 de consultoria (especialista em RAG)
• Setup de Pinecone + OpenAI embeddings
• Total: R$ 28.000 + 160 horas de dev

Base de conhecimento criada:

1. Playbook jurídico interno (80 páginas)

   • Tipos de cláusulas problemáticas
   • Exemplos reais comentados
   • Jurisprudência relevante

2. Biblioteca de 230 contratos analisados

   • Contratos anteriores + análises de advogados
   • Anotações sobre cláusulas específicas

3. Checklist de revisão (40 páginas)

   • Procedimento passo a passo
   • Red flags comuns
   • Padrões por tipo de contrato

Funcionamento:

Para cada contrato novo:

1. Sistema identifica tipo de contrato (SaaS, consultoria, etc.)
2. Busca em base: checklist específico + contratos similares + playbook
3. Inclui esse contexto no prompt
4. GPT-4 analisa baseado nesse contexto específico

Resultado:

• Acurácia: 79% (+97% vs baseline, +36% vs melhor prompt puro)
• Recall: 85% (pegava 85% das cláusulas problemáticas)
• Precision: 73% (73% do que identificava era realmente problemático)
• Custo/contrato: R$ 4,20
• Consistência: muito melhor (mesmo contrato = mesma análise)

Por que funcionou:

RAG forneceu:

• Conhecimento específico da firma (interpretações, jurisprudência)
• Exemplos de contratos similares (aprendizado por analogia)
• Checklist específico por tipo de contrato

Abordagem 3: Fine-tuning (6 semanas)

Investimento:

• 3 semanas preparando dataset
• 2 semanas treinando e testando modelos
• R$ 35.000 de consultoria (ML specialist)
• R$ 3.200 em custos de treinamento (OpenAI)
• Total: R$ 52.000 + 240 horas

Preparação do dataset:

Criar dataset de fine-tuning é trabalhoso:

1. Selecionar 1.000 contratos representativos

2. Gerar análises perfeitas para cada um:

   • Advogados sêniores analisaram manualmente
   • Formato: input (contrato) → output (análise em JSON)
   • 4 semanas de trabalho de 2 advogados
   • Custo adicional não contabilizado: ~R$ 80.000

3. Validar qualidade do dataset:

   • Revisar por inconsistências
   • Garantir distribuição balanceada

Treinamento:

• Fine-tuned GPT-3.5-turbo (mais barato que GPT-4)
• 3 epochs
• Validação contínua para evitar overfitting

Resultado:

• Acurácia: 71% (+77% vs baseline, mas -10% vs RAG)
• Recall: 78%
• Precision: 69%
• Custo/contrato: R$ 1,80 (muito mais barato)
• Consistência: excelente

Por que não superou RAG:

Fine-tuning melhorou:

• Entendimento de jargão jurídico específico
• Formato de saída (sempre JSON perfeito)
• Tom/estilo das análises

Mas não adicionou:

• Conhecimento atualizado (playbook, jurisprudência)
• Capacidade de aprender com contratos similares
• Flexibilidade (atualizar requer re-treinar)

Decisão final: RAG puro (com prompts otimizados)

Rafael escolheu RAG, por estas razões:

1. Melhor acurácia: 79% vs 71% (fine-tuning) vs 58% (prompts puros)

2. Melhor custo-benefício:

   • RAG: R$ 28k setup, R$ 4,20/contrato
   • Fine-tuning: R$ 132k setup (incluindo dataset), R$ 1,80/contrato
   • Volume de 1.000 contratos/mês → diferença de custo operacional: R$ 2,40/contrato = R$ 2.400/mês
   • Payback do investimento adicional em fine-tuning: 43 meses (inviável)

3. Facilidade de atualização:

   • RAG: adicionar novo documento ao playbook = atualização imediata
   • Fine-tuning: requer preparar novos exemplos + re-treinar

4. Rastreabilidade:

   • RAG permite citar: “baseado no checklist X, seção Y”
   • Importante para explicar decisões aos advogados

5. Maturidade da equipe:

   • RAG: manutenção por desenvolvedor full-stack
   • Fine-tuning: requer expertise ML (que não tinham)

Considerou combinação (RAG + Fine-tuning)?

Sim. Testaram:

• Acurácia subiu para 91% (impressionante!)
• Mas adicionou R$ 104k ao investimento inicial
• Complexidade operacional muito maior
• Decisão: deixar para “fase 2” se acurácia de 79% não for suficiente

Resultados após 6 meses de produção

Métricas de produto:

• Acurácia em produção: 81% (melhor que teste, pois base de conhecimento cresceu)
• 12.000 contratos analisados
• Zero falhas críticas (passar cláusula altamente problemática)

Impacto no negócio:

• Redução de 65% no tempo de análise de contratos
• Advogados focam em revisão, não em leitura inicial
• Customer satisfaction score: 7,2 → 8,9
• Churn: 8%/mês → 3%/mês

Evolução da base de conhecimento:

• Playbook inicial: 80 páginas → 240 páginas
• Contratos de referência: 230 → 890
• Sistema “aprende” continuamente (sem re-treinar)

ROI:

• Investimento: R$ 28.000
• Economia de tempo: ~R$ 95.000/mês (advogados sêniores)
• Payback: 9 dias
• ROI ano 1: 4.070%

Checklist: qual abordagem faz sentido para você?

Teste rápido de adequação

Responda estas perguntas:

1. Você já tem uma base de conhecimento organizada?

   • Sim, temos documentação extensa e relativamente organizada → +3 pontos RAG
   • Temos conteúdo, mas desorganizado → +1 ponto RAG
   • Não temos base de conhecimento → +0 pontos RAG

2. Qual é a natureza da sua tarefa?

   • Precisa de conhecimento específico/proprietário → +3 pontos RAG
   • Tarefa repetitiva com formato muito específico → +3 pontos Fine-tuning
   • Tarefa de propósito geral → +3 pontos Prompt Engineering

3. Qual seu volume mensal?

   • menos de 1.000 interações/mês → +3 pontos Prompt Engineering
   • 1.000 - 50.000 interações/mês → +3 pontos RAG
   • mais de 50.000 interações/mês → +3 pontos Fine-tuning (economia de custo)

4. Qual seu orçamento disponível?

   • < R$ 5.000 → +3 pontos Prompt Engineering
   • R$ 5.000 - R$ 40.000 → +3 pontos RAG
   • > R$ 40.000 → +1 ponto Fine-tuning (viável)

5. Você tem dataset de treinamento de qualidade?

   • Sim, 1.000+ exemplos perfeitos → +3 pontos Fine-tuning
   • Temos dados, mas precisam ser preparados → +1 ponto Fine-tuning
   • Não temos → +0 pontos Fine-tuning

6. Com que frequência seu conhecimento muda?

   • Constantemente (semanal/mensal) → +3 pontos RAG
   • Periodicamente (trimestral) → +1 ponto RAG, +1 ponto Fine-tuning
   • Raramente → +2 pontos Fine-tuning

7. Expertise técnico disponível:

   • Desenvolvedor full-stack → +2 pontos RAG
   • Data scientist/ML engineer → +3 pontos Fine-tuning
   • Apenas usuário de ferramentas → +3 pontos Prompt Engineering

Contagem de pontos:

• Maior pontuação em Prompt Engineering: comece otimizando prompts
• Maior pontuação em RAG: implemente RAG + prompt engineering
• Maior pontuação em Fine-tuning: considere fine-tuning (mas valide com RAG primeiro)

Framework de decisão passo a passo

Passo 1: Começar sempre com Prompt Engineering

Motivo: validar se IA resolve seu problema antes de investir.

Perguntas:

• Testando apenas com prompts otimizados, consigo 60%+ de acurácia?
• Se sim → talvez prompts bastem (vá para Passo 2)
• Se não → definitivamente precisa RAG ou fine-tuning (vá para Passo 3)

Passo 2: Prompts estão “quase bons o suficiente”?

Se acurácia está entre 60-75% com prompts:

Perguntas:

• “Quase bom” é aceitável para meu caso de uso?
• Custo de erro é baixo?
• Volume é pequeno (menos de 500/mês)?

Se SIM para todas → fique com prompts (KISS principle) Se NÃO para qualquer uma → vá para Passo 3

Passo 3: Você precisa de conhecimento específico?

Perguntas:

• Modelo precisa de informação proprietária?
• Documentação/manuais/políticas precisam ser consultados?
• Conhecimento muda periodicamente?

Se SIM para qualquer uma → RAG é sua solução Se NÃO para todas → vá para Passo 4

Passo 4: Tarefa é altamente repetitiva e você tem dados?

Perguntas:

• Mesma tarefa, milhares de vezes?
• Tenho 1.000+ exemplos de input/output perfeitos?
• Tom/estilo/formato específico é crítico?
• Volume é alto (mais de 10k/mês)?

Se SIM para todas → Fine-tuning faz sentido Se NÃO → volte para RAG ou prompts

Passo 5: Combinação faz sentido?

Se você tem:

• Budget > R$ 60k
• Expertise técnica (ML)
• RAG sozinho não está entregando acurácia necessária (mais de 90%)

Então: considere RAG + Fine-tuning

Caso contrário: escolha apenas uma abordagem

Conclusão: escolha estratégica, não tática

A escolha entre prompt engineering, RAG e fine-tuning não é sobre “qual é melhor”. Cada abordagem resolve problemas diferentes.

Três aprendizados principais:

1. Comece simples, sempre

   • 80% dos casos: prompts otimizados + RAG resolvem
   • Fine-tuning raramente é necessário (e caro)
   • KISS principle: simplicidade tem valor

2. RAG é o “sweet spot” para maioria dos casos B2B

   • Adiciona conhecimento proprietário
   • Mantém flexibilidade
   • Custo-benefício imbatível
   • Facilidade de manutenção

3. Fine-tuning é especialização, não solução geral

   • Ótimo para tarefas muito específicas
   • Requer investimento significativo
   • Valide com RAG primeiro

Framework mental:

• Precisa adicionar conhecimento? → RAG
• Precisa de comportamento específico? → Fine-tuning
• Precisa controlar tom/formato? → Prompt engineering
• Precisa de tudo? → RAG + Fine-tuning + Prompts (complexo, mas poderoso)

O que fazer agora:

Se você está considerando IA para seu caso de uso:

1. Semana 1: Teste com prompts otimizados (custo ~zero)
2. Semana 2-3: Se insuficiente, implemente piloto de RAG (200 documentos)
3. Semana 4-5: Valide ROI do RAG
4. Mês 2-3: Se RAG não basta, considere fine-tuning

Não pule etapas. Muitas empresas gastam R$ 100k+ em fine-tuning quando RAG de R$ 20k resolveria.

Quer ajuda para escolher e implementar a abordagem certa?

Na Orient.me, já implementamos dezenas de projetos usando RAG, fine-tuning e combinações.

Nossa metodologia:

• Diagnóstico (1 semana): análise do caso de uso, dados disponíveis, requisitos
• Recomendação fundamentada: qual abordagem faz sentido (com números)
• Piloto (3-4 semanas): validar solução com dados reais
• Implementação completa: apenas se piloto comprova ROI

Agende uma conversa gratuita de 30 minutos para avaliar qual abordagem faz sentido para o seu caso.