RAG vs Fine-Tuning vs Contexto Longo: Como Escolher a Arquitetura LLM Certa em 2026

Você tá construindo uma aplicação com LLMs e precisa que ela trabalhe com seus próprios dados. Talvez documentação interna, tickets de suporte, contratos legais ou um catálogo de produtos. O modelo base não sabe nada disso. Aí você bate de frente com a pergunta que todo engenheiro de IA enfrenta eventualmente:

Uso RAG, faço fine-tuning do modelo, ou enfio tudo na janela de contexto?

Um ano atrás, era uma decisão entre duas opções. Em 2026, virou uma escolha entre três, e errar significa queimar dinheiro em infraestrutura que você não precisa, ou lançar uma aplicação que alucina sobre seus dados proprietários.

Este guia te dá o framework de decisão completo. Sem enrolação. Arquiteturas reais, matemática de custos concreta, código de produção e uma árvore de decisão que você pode usar hoje.

As Três Abordagens de Relance

Antes de ir fundo, vamos entender o que cada abordagem realmente faz:

RAG (Retrieval-Augmented Generation) busca fragmentos relevantes dos seus dados no momento da consulta e injeta no prompt. Os pesos do modelo nunca mudam. Você tá dando uma cola pra cada pergunta.

Fine-tuning modifica os pesos do modelo treinando com seus dados específicos. O conhecimento fica assado dentro do modelo. Pense nisso como ensinar o modelo a falar a linguagem do seu domínio nativamente.

Contexto longo simplesmente joga todo seu dataset (ou grandes partes dele) direto na janela de contexto do modelo. Sem pipeline de busca, sem treinamento. Com a janela de 1M tokens do Claude e do Gemini 3.1, isso agora é viável pra datasets que antes eram impossíveis.

┌──────────────────────────────────────────────────────────────────┐
│                   Seus Dados + LLM = Resposta                    │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  RAG                    Fine-Tuning            Contexto Longo    │
│  ┌──────────────┐       ┌──────────────┐      ┌──────────────┐  │
│  │ Query → Buscar│       │ Treinar o    │      │ Jogar todos  │  │
│  │ → Top K chunks│       │ modelo com   │      │ os dados no  │  │
│  │ → Injetar no  │       │ seus dados   │      │ prompt       │  │
│  │   prompt      │       │ → Novos pesos│      │ → Perguntar  │  │
│  │ → Gerar       │       │ → Gerar      │      │ → Gerar      │  │
│  └──────────────┘       └──────────────┘      └──────────────┘  │
│                                                                  │
│  Modelo inalterado       Modelo modificado     Modelo inalterado │
│  Dados externos          Dados internalizados  Dados no prompt   │
│  Conhecimento dinâmico   Conhecimento estático Estático por query│
│  Infra pesada            Treino pesado         Tokens pesados    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Bora detalhar cada um.

RAG: Retrieval-Augmented Generation

Como Funciona

RAG divide seu pipeline em duas fases: recuperação e geração.

1. Indexação (offline): Seus documentos são divididos em chunks, convertidos em vetores e armazenados num banco de dados vetorial
2. Recuperação (no momento da consulta): A query do usuário é embedada e os chunks mais similares semanticamente são recuperados
3. Geração: Os chunks recuperados são injetados no prompt como contexto, e o LLM gera uma resposta fundamentada

Pipeline RAG de Produção em 2026

RAG moderno não é só "embedar e buscar." Um setup de produção é assim:

import { OpenAIEmbeddings } from "@langchain/openai";
import { PGVectorStore } from "@langchain/community/vectorstores/pgvector";
import { ChatOpenAI } from "@langchain/openai";
import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";

// 1. Chunking com consciência semântica
const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 512,
  chunkOverlap: 64,
  separators: ["\n## ", "\n### ", "\n\n", "\n", " "],
});

const chunks = await splitter.splitDocuments(documents);

// 2. Embedar e armazenar com metadata
const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large",
  dimensions: 1024,
});

const vectorStore = await PGVectorStore.fromDocuments(chunks, embeddings, {
  postgresConnectionOptions: { connectionString: process.env.PG_URL },
  tableName: "documents",
});

// 3. Busca híbrida: vetorial + filtragem por metadata
async function retrieve(query: string, filters?: Record<string, any>) {
  const results = await vectorStore.similaritySearchWithScore(query, 10, filters);
  const reranked = await rerank(query, results);
  return reranked.slice(0, 5);
}

// 4. Gerar resposta com contexto recuperado
async function generateAnswer(query: string) {
  const context = await retrieve(query);
  const contextText = context.map(([doc]) => doc.pageContent).join("\n\n---\n\n");

  const llm = new ChatOpenAI({ model: "gpt-4.1", temperature: 0 });
  const response = await llm.invoke([
    {
      role: "system",
      content: `Responda com base no contexto fornecido. Se o contexto não 
                contiver a resposta, diga isso. Cite o documento fonte.
                
                Contexto:
                ${contextText}`,
    },
    { role: "user", content: query },
  ]);
  return response.content;
}

Quando RAG dá show

RAG é a escolha certa quando:

• Os dados mudam com frequência: Catálogos de produtos, tickets de suporte, notícias, documentação atualizada semanalmente
• Atribuição de fontes importa: Jurídico, medicina, compliance. Você precisa apontar exatamente de onde veio a resposta
• O dataset é grande: Centenas de milhares de documentos onde você só precisa de pequenos fragmentos relevantes por consulta
• Precisão importa mais que estilo: Quando acurácia factual pesa mais que como a resposta soa
• Aplicações multi-tenant: Diferentes usuários precisam de respostas de diferentes subsets de dados

Quando RAG sofre

• Raciocínio complexo cruzando muitos documentos: Se responder requer sintetizar informação de 50+ documentos, a recuperação pode perder peças críticas
• Requisitos de estilo/tom/formato: RAG não muda como o modelo fala, só o que ele sabe no momento da consulta
• Apps sensíveis à latência: O passo de busca adiciona 100-500ms a cada request
• Datasets pequenos e estáveis: Se seus dados cabem numa janela de contexto e raramente mudam, RAG é exagero

Perfil de Custos do RAG

O custo escondido: tempo de engenharia. Montar e manter um pipeline RAG de produção não é brincadeira. É um investimento de eng pesado.

Fine-Tuning

Como Funciona

Fine-tuning pega um LLM pré-treinado e treina mais com seus dados específicos, modificando os pesos do modelo pra internalizar conhecimento de domínio, estilo ou padrões de comportamento.

Fine-Tuning na Prática

import openai
import json

# 1. Preparar dados de treino em formato JSONL
training_data = [
    {
        "messages": [
            {
                "role": "system",
                "content": "Você é um engenheiro sênior de segurança na Acme Corp. "
                           "Responda sobre políticas de segurança e procedimentos "
                           "de resposta a incidentes com linguagem precisa e "
                           "acionável. Sempre referencie o número da seção."
            },
            {
                "role": "user",
                "content": "Qual o procedimento quando há suspeita de data breach?"
            },
            {
                "role": "assistant",
                "content": "Conforme Política §4.2.1 - Resposta a Data Breach:\n\n"
                           "1. **Contenção imediata** (15 min): Isole os "
                           "sistemas afetados. NÃO desligue. Preserve "
                           "evidências forenses.\n"
                           "2. **Escalação** (30 min): Notifique o Comandante "
                           "de Incidentes via #security-incidents no Slack.\n"
                           "3. **Avaliação** (2 horas): Determine o escopo "
                           "usando o modelo DREAD (§4.2.3).\n"
                           "4. **Notificação** (24 horas): Se PII estiver "
                           "envolvido, Jurídico deve ser notificado por §7.1 LGPD.\n\n"
                           "NÃO comunique externamente até ter OK do Jurídico."
            }
        ]
    },
    # ... centenas de exemplos mais
]

with open("training_data.jsonl", "w") as f:
    for example in training_data:
        f.write(json.dumps(example) + "\n")

# 2. Upload e iniciar o fine-tuning
client = openai.OpenAI()
file = client.files.create(file=open("training_data.jsonl", "rb"), purpose="fine-tune")
job = client.fine_tuning.jobs.create(
    training_file=file.id,
    model="gpt-4.1-mini",
    hyperparameters={"n_epochs": 3, "learning_rate_multiplier": 1.0},
)

# 3. Usar o modelo fine-tunado
response = client.chat.completions.create(
    model="ft:gpt-4.1-mini:acme-corp:security-bot:abc123",
    messages=[{"role": "user", "content": "Como lidamos com um incidente de phishing?"}]
)

Quando Fine-Tuning dá show

• Você precisa mudar o comportamento do modelo: Formato de saída específico, tom, estilo de raciocínio, voz de marca
• Seu conhecimento é estável: Políticas internas, expertise de domínio, padrões de código que não mudam semanalmente
• Latência importa: Sem passo de busca, respostas mais rápidas (só inferência)
• Custo em escala: Pra apps de alto volume com conhecimento estável, um modelo fine-tunado menor evita o token bloat do RAG por query
• Raciocínio especializado: Ensinar o modelo padrões de raciocínio específicos de domínio

Quando Fine-Tuning sofre

• Dados mudam frequentemente: Cada atualização exige re-treinamento
• Você não consegue produzir dados de treino de alta qualidade: Entra lixo, sai lixo
• Catastrophic forgetting: O modelo pode "esquecer" capacidades gerais ao ser treinado agressivamente com dados restritos
• Atribuição de fontes: Modelos fine-tunados não conseguem apontar onde aprenderam algo
• Times pequenos: O overhead de ML engineering é significativo

Perfil de Custos do Fine-Tuning

O custo escondido: curação de dados. Você precisa de centenas a milhares de conversas de exemplo de alta qualidade. Essa parte é a mais chatinha do projeto inteiro.

Janelas de Contexto Longo

Como Funciona

A abordagem mais simples de todas: pegue seus documentos, concatene, e jogue na janela de contexto do modelo junto com a query. Sem pipelines de embedding, sem bancos vetoriais, sem treinamento.

import Anthropic from "@anthropic-ai/sdk";
import { readFileSync, readdirSync } from "fs";
import { join } from "path";

const anthropic = new Anthropic();

function loadDocuments(dir: string): string {
  const files = readdirSync(dir).filter((f) => f.endsWith(".md"));
  return files
    .map((f) => {
      const content = readFileSync(join(dir, f), "utf-8");
      return `--- ${f} ---\n${content}`;
    })
    .join("\n\n");
}

const allDocs = loadDocuments("./docs");

async function askQuestion(question: string) {
  const response = await anthropic.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 4096,
    messages: [{
      role: "user",
      content: `Aqui tá toda nossa documentação:\n\n${allDocs}\n\n` +
               `Com base na documentação, responda: ${question}`,
    }],
  });
  return response.content[0].text;
}

É isso. Sem chunking, sem embeddings, sem vector DB, sem reranking. Só documentos e uma pergunta.

Tamanhos de Janela de Contexto em 2026

Quando Contexto Longo dá show

• Dataset pequeno a médio: Menos de ~500K tokens, essa é a opção mais simples
• Você precisa agora: Zero infraestrutura. Comece a consultar em minutos
• Raciocínio cruzando documentos: O modelo vê tudo de uma vez, consegue sintetizar informação que RAG poderia perder
• Fase de protótipo/MVP: Faça funcionar primeiro, otimize depois
• Consultas infrequentes: Umas centenas de perguntas por dia, o custo por query é aceitável

Quando Contexto Longo sofre

• Custo em escala: 500K tokens por query a $3/M =$1.50 por query. 10K/dia = $15,000/dia
• Latência: Processar 500K tokens demora significativamente mais que um prompt RAG de 2K tokens
• "Agulha no palheiro": Modelos podem falhar em encontrar detalhes enterrados no meio de contextos massivos
• Dataset excede a janela: 10M tokens de dados e 1M de janela, não funciona

Perfil de Custos do Contexto Longo

O custo escondido: não escala. A opção mais barata no início vira a mais cara com volume.

O Framework de Decisão

Matriz de Comparação

Padrões de Arquitetura do Mundo Real

Padrão 1: RAG (Dinâmico) + Fine-Tuning (Comportamento) = Híbrido

O padrão mais poderoso. Fine-tune pra como o modelo se comporta, RAG pro que ele sabe.

Padrão 2: Contexto Longo pra Protótipo → RAG pra Produção

Comece com contexto longo pra validar sua abordagem, depois migre pra RAG quando precisar escalar.

Padrão 3: Arquitetura em Camadas

Use as três num só sistema, roteando queries pro approach mais eficiente:

async function routeQuery(query: string, queryType: string) {
  switch (queryType) {
    case "factual_lookup":
      return await ragPipeline(query);
    case "complex_analysis":
      return await longContextAnalysis(query);
    case "formatted_report":
      return await fineTunedWithRAG(query);
    default:
      return await ragPipeline(query);
  }
}

Padrão 4: RAG Agêntico

A evolução 2026 do RAG onde um agente de IA decide dinamicamente como buscar, de quais fontes, e se faz busca multi-step:

import { ChatOpenAI } from "@langchain/openai";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const tools = [
  vectorSearchTool, sqlQueryTool, webSearchTool,
  graphTraversalTool, calculatorTool,
];

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: "gpt-4.1" }),
  tools,
  messageModifier: `Você é um agente de pesquisa. Pra cada consulta:
    1. Decida quais ferramentas usar baseado no tipo de pergunta
    2. Se necessário, busque informação em múltiplas fontes
    3. Verifique cruzando os achados
    4. Sintetize uma resposta completa com citações`,
});

Erros Comuns

Erro 1: Usar RAG pra Tudo

RAG virou a opção "segura", mas nem sempre é a certa. Se seu dataset são 50 páginas estáveis e você recebe 100 queries/dia, contexto longo é mais simples, mais barato e na maioria das vezes mais preciso. Não complica o que não precisa.

Erro 2: Fine-Tunar Quando Precisa de RAG

"Nosso modelo não sabe dos nossos produtos" → Problema de conhecimento, não de comportamento. RAG resolve.

Regra: "O modelo não sabe X" → RAG. "O modelo não fala/pensa como X" → Fine-tuning.

Erro 3: Ignorar o "Lost in the Middle"

Modelos ainda apanham pra recuperar informação do meio de contextos muito longos. Coloque o contexto mais importante no início e no final do prompt.

Erro 4: Over-Engineering de RAG

Seu pipeline não precisa de GraphRAG + HyDE + reranker no dia um. Comece simples. Meça. Adicione complexidade quando os dados mostrarem que ajuda.

Erro 5: Não Medir Qualidade de Busca

A falha de RAG mais comum não é o LLM. É a busca ruim. Se não tá medindo recall@k e precision@k, tá voando às cegas.

def evaluate_retrieval(test_queries, ground_truth_docs, retriever, k=5):
    recalls = []
    for query, expected_doc_ids in zip(test_queries, ground_truth_docs):
        retrieved = retriever.retrieve(query, k=k)
        retrieved_ids = {doc.id for doc in retrieved}
        expected_ids = set(expected_doc_ids)
        recall = len(retrieved_ids & expected_ids) / len(expected_ids)
        recalls.append(recall)
    avg_recall = sum(recalls) / len(recalls)
    print(f"Recall@{k}: {avg_recall:.2%}")
    return avg_recall

Matemática de Custos: Exemplo Concreto

Vamos comparar custos pra um cenário concreto: um bot de suporte atendendo 50,000 queries/mês contra uma base de 10,000 artigos FAQ (~2M tokens total).

Opção A: RAG

Opção B: Fine-Tuning + RAG (Híbrido)

Opção C: Contexto Longo

O veredito é claro nesse cenário: RAG ganha por uma margem de 100x em escala. Mas pra um protótipo com 50 queries/dia? Contexto longo custa ~$60/mês com zero setup.

A lição: sempre faça a matemática de custos pra sua escala específica antes de se comprometer com uma arquitetura.

O Panorama 2026

Três mudanças importantes estão reformulando essa decisão:

1. Janelas de Contexto Crescendo

Llama 4 Scout com 10M tokens sugere que estamos caminhando pra modelos que podem segurar codebases inteiros ou bibliotecas de documentos completas. Não mata RAG, mas encolhe os casos onde é estritamente necessário. À medida que os modelos processam mais contexto nativamente, a pergunta muda de "consigo colocar tudo no contexto?" pra "deveria?", e a resposta depende de custo e latência.

2. RAG Agêntico

Pipelines estáticos evoluindo pra sistemas autônomos que decidem como, de onde e se fazem busca multi-step. Isso combina a precisão do RAG com a flexibilidade dos agentes, e é uma das tendências mais importantes em AI engineering.

3. Fine-Tuning Mais Barato

LoRA (Low-Rank Adaptation) e QLoRA cortaram custos drasticamente. Dá pra fine-tunar um modelo de 70B parâmetros numa GPU só em horas. Isso torna o caso de uso "conhecimento estável + comportamento" cada vez mais atraente comparado com pipelines RAG complexos.

4. RAFT (Retrieval-Augmented Fine-Tuning)

Fine-tunar pra trabalhar bem com contexto recuperado emerge como um padrão poderoso. O modelo aprende a extrair informação relevante de chunks ruidosos e ignorar o irrelevante, combinando os pontos fortes de ambas abordagens. RAFT é especialmente promissor pra cenários que precisam tanto de precisão na recuperação quanto qualidade no output.

Conclusão

Não existe abordagem universalmente "melhor." A arquitetura certa depende dos seus dados, sua escala, latência e capacidades do time.

A cola:

Dados mudam frequentemente? → RAG

Precisa mudar comportamento do modelo? → Fine-tuning

Dataset pequeno, precisa agora? → Contexto longo

Melhor qualidade em escala? → Fine-tune + RAG

Prototipando? → Contexto longo → migre pra RAG depois

Para de tratar isso como debate religioso. Faça a matemática. Meça a qualidade de busca. Comece simples. Adicione complexidade quando os dados pedirem.

Os engenheiros fazendo as melhores apps LLM em 2026 não são os com os pipelines mais sofisticados. São os que escolheram a abordagem certa pro problema e executaram bem.