O que é RAG
RAG (Retrieval-Augmented Generation) é uma abordagem em que um modelo de linguagem encontra fragmentos relevantes na sua base de conhecimento antes de responder e só então gera texto. Em vez de "memorizar" todos os documentos nos pesos do modelo ou carregá-los inteiros no contexto, o sistema busca os trechos certos e os insere no prompt. Abaixo - o que é RAG, como funciona o pipeline e quando faz sentido em produção.
Definição em termos simples
Retrieval-Augmented Generation combina duas etapas:
- Retrieval (recuperação) - a partir da pergunta do usuário, o sistema encontra os fragmentos de texto mais adequados em um corpus: wiki, PDF, tickets, código, normas.
- Generation (geração) - o LLM recebe esses fragmentos como contexto e formula a resposta com base neles.
O termo se consolidou após Lewis et al. (2020) e virou padrão para chatbots corporativos, sistemas de suporte e assistentes internos. RAG não substitui o modelo - complementa com dados atuais que não estavam no treinamento ou mudaram ontem.
Como o RAG funciona: pipeline típico
┌──────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────┐
│Documentos│───▶│ Chunking + │───▶│ Vector DB │ │ │
│ (PDF, MD)│ │ Embeddings │ │ (índice) │ │ LLM │
└──────────┘ └─────────────┘ └──────┬───────┘ │ │
│ │ │
Consulta ──▶ Embedding ──▶ Top-K ──▶ Prompt + contexto ──▶ Resposta
1. Preparação de dados (offline)
- Ingestão - parsing de PDF, HTML, Markdown, Confluence, Notion, repositórios.
- Chunking - divisão em fragmentos de 256-1024 tokens com sobreposição para não cortar o sentido na borda do parágrafo.
- Embedding - cada chunk vira vetor com modelo de embeddings (OpenAI text-embedding-3, Cohere, BGE, E5 open source).
- Indexação - vetores salvos em vector store: Pinecone, Weaviate, Qdrant, pgvector, Chroma, Milvus.
Essa etapa roda ao adicionar ou atualizar documentos, não a cada consulta do usuário.
2. Consulta (online)
- A pergunta do usuário também é embedada com o mesmo encoder.
- A vector DB retorna Top-K chunks mais próximos (geralmente K = 3-10).
- Opcionalmente - reranking: um segundo modelo reordena candidatos por relevância com mais precisão que similaridade coseno pura.
- Fragmentos encontrados vão ao prompt system/user com instrução de "responder só com base no contexto".
- O LLM gera a resposta; muitas vezes se adicionam citações ao id do chunk ou página fonte.
A qualidade do RAG depende ~80% da recuperação: se o fragmento certo não entra no Top-K, o modelo alucina ou diz honestamente "não sei".
Componentes principais
| Componente | Papel | Exemplos |
|---|---|---|
| Modelo de embedding | Texto → vetor para busca semântica | text-embedding-3-large, bge-m3, voyage-3 |
| Banco vetorial | Armazenamento e busca ANN rápida | Qdrant, Pinecone, pgvector, Weaviate |
| Estratégia de chunking | Equilíbrio detalhe vs ruído | Tamanho fixo, split semântico, por títulos |
| LLM | Resposta final com raciocínio | GPT-5.6, Claude Fable 5, Gemini 3.1, modelos locais |
| Orquestrador | Une etapas, cache, logging | LangChain, LlamaIndex, Haystack, código próprio |
Em 2026 muitos frameworks (LlamaIndex, LangGraph) e produtos (Cursor @Codebase, Notion AI, sistemas tipo Glean) implementam RAG por baixo, mas entender o pipeline básico é necessário para depurar e ajustar.
Casos de uso práticos
- Suporte e FAQ - respostas a partir de base de artigos e tickets antigos sem busca manual.
- Wiki interna - "como pedir férias", "onde está o runbook de incidente".
- Jurídico e compliance - busca em contratos e normas com referência à cláusula.
- Assistentes de código - busca semântica no repositório (índice + embeddings), complemento ao contexto completo no IDE.
- Análise de documentos - perguntas sobre relatórios, pesquisas, transcrições de reuniões.
Padrão comum: corpus grande, atualizações frequentes, citação de fontes - RAG encaixa melhor que enviar arquivo uma vez no chat.
RAG vs fine-tuning vs contexto longo
| Abordagem | Quando usar | Limitação |
|---|---|---|
| RAG | Documentos atuais, fontes transparentes, updates sem retreinar | Depende da qualidade da busca |
| Fine-tuning | Estilo, formato, terminologia de domínio, conhecimento estável | Caro atualizar quando dados mudam |
| Contexto longo | Documento ou codebase inteiro em uma sessão | Custo, latência, "lost in the middle" |
Essas abordagens não são excludentes. Esquema típico 2026: RAG para buscar no corpus + contexto longo para poucos arquivos completos + fine-tuning leve ou system prompt para tom da empresa.
Limitações e problemas comuns
RAG resolve acesso ao conhecimento, mas não:
- garantia de exatidão factual (o modelo pode ignorar o contexto)
- ações complexas de vários passos (precisa de tools / MCP)
- atualização automática do índice (ETL ao mudar documentos)
Falhas frequentes:
- Chunking ruim - tabela partida ao meio, fórmula sem título.
- K errado - poucos chunks → fatos perdidos; demais → ruído no prompt.
- Índice desatualizado - documento atualizado, embedding não recalculado.
- Busca híbrida não configurada - busca semântica pura erra SKU, ID, datas exatas; híbrido (BM25 + vetores) ajuda.
Em produção: monitorar hit rate de retrieval, A/B de chunk size, feedback humano, guardrails "se confiança baixa - não responder".
Como melhorar um sistema RAG
- Metadados - tags de departamento, data, versão; filtro antes de vector search.
- Busca híbrida - keyword (BM25) + semântica; especialmente em docs técnicos.
- Reranker - cross-encoder após Top-20 inicial → Top-5 final.
- Transformação de consulta - reformulação, multi-query, HyDE (documento hipotético).
- Graph RAG - entidades ligadas (pessoas, projetos, dependências) sobre chunks planos.
- Avaliação - dataset pergunta-resposta gold; métricas faithfulness, context recall (RAGAS, DeepEval).
Comece com pipeline simples (chunk → embed → Top-5 → GPT), meça baseline e só então adicione complexidade onde métricas subirem.
RAG e o ecossistema de agentes
RAG costuma ir com MCP e tool calling: RAG puxa conhecimento de documentos, tools executam ações (criar ticket, consultar saldo). No Cursor o índice semântico @Codebase é um caso de RAG sobre arquivos do projeto; em enterprise escala-se o mesmo padrão para Confluence, Slack e CRM.
| Camada | Tarefa |
|---|---|
| RAG | "O que dizem os documentos?" |
| MCP / tools | "O que está no sistema agora? Aja" |
| LLM | Sintetizar resposta e planejar passos |
Resumo
RAG é a forma padrão de conectar um LLM aos seus dados sem retreinar: documentos são indexados, fragmentos relevantes são recuperados por consulta, o modelo responde com base neles. Escala de protótipo Chroma + OpenAI até cluster com busca híbrida, reranking e monitoramento de qualidade.
Para o primeiro projeto: escolha um corpus (ex.: FAQ de 50 páginas), configure chunking e Top-K, meça se o parágrafo certo entra no contexto - é o principal preditor de sucesso do sistema.
Perguntas frequentes
Qual a diferença entre RAG e fine-tuning?
Fine-tuning altera os pesos do modelo com seus exemplos - bom para estilo, formato e padrões estáveis. RAG não mexe nos pesos: a cada consulta traz fragmentos frescos do índice. Documentos que mudam toda semana atualizam melhor via RAG (reindexação) que retreinando. Fine-tuning quando o modelo deve "saber" um procedimento de cor; RAG quando importam atualidade e citação de fonte.
Preciso de RAG se o modelo tem contexto de um milhão de tokens?
Contexto longo (1M+ tokens no Claude, Gemini, GPT-5.6) permite carregar muito texto numa sessão, mas não substitui RAG em corpus grandes: 100 GB de PDF não cabem no prompt e custo e latência crescem linearmente. RAG escolhe trechos relevantes; contexto longo serve para poucos arquivos completos após retrieval ou código do repo no IDE. Na prática combina-se os dois.
Qual banco vetorial escolher para RAG?
Depende de escala e infraestrutura. pgvector - se já tem PostgreSQL e até milhões de vetores. Qdrant, Weaviate, Milvus - self-hosted ou managed ao crescer. Pinecone - managed sem operar cluster. Chroma - início rápido de protótipo. O crítico é qualidade de embeddings, chunking e monitoramento; muitos sistemas começaram no Chroma e migraram para pgvector ou Qdrant sem mudar a lógica da app.
Por que o RAG às vezes dá respostas erradas?
Causas principais: (1) falha de retrieval - chunk certo não entrou no Top-K; (2) modelo ignorou contexto e completou da "memória"; (3) índice desatualizado; (4) chunks contraditórios. Corrige com busca melhor (híbrida, reranker), prompt rígido ("se não está no contexto - diga que não sabe"), citações e set de eval para regressões.
Dá para construir RAG com modelos locais?
Sim. Modelos de embedding (bge-m3, nomic-embed) e LLM (Llama, Qwen, Mistral via Ollama) rodam offline; vector store também pode ser local. Limites - qualidade em hardware modesto; escolher tamanho conforme GPU/RAM. Para dados confidenciais (saúde, finanças, setor público) RAG local é comum: documentos não saem do perímetro e a arquitetura do pipeline é a mesma da nuvem.