O que é RAG

RAG é 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:

1. 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.
2. 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)

1. A pergunta do usuário também é embedada com o mesmo encoder.
2. A vector DB retorna Top-K chunks mais próximos (geralmente K = 3-10).
3. Opcionalmente - reranking: um segundo modelo reordena candidatos por relevância com mais precisão que similaridade coseno pura.
4. Fragmentos encontrados vão ao prompt system/user com instrução de "responder só com base no contexto".
5. 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

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

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

1. Metadados - tags de departamento, data, versão; filtro antes de vector search.
2. Busca híbrida - keyword (BM25) + semântica; especialmente em docs técnicos.
3. Reranker - cross-encoder após Top-20 inicial → Top-5 final.
4. Transformação de consulta - reformulação, multi-query, HyDE (documento hipotético).
5. Graph RAG - entidades ligadas (pessoas, projetos, dependências) sobre chunks planos.
6. 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.

Quando o RAG não é indicado

RAG traz complexidade de engenharia e exige manutenção, então nem sempre vale a pena adotá-lo:

• Base de conhecimento pequena e que quase não muda - basta colar o texto uma vez no system prompt; não precisa de busca nem de banco vetorial.
• Sem recursos para manter o pipeline - o índice precisa ser atualizado a cada mudança nos documentos e a qualidade da busca precisa ser monitorada; sem uma equipe ou fornecedor dedicado, o sistema fica desatualizado rápido e passa a dar respostas erradas.
• Precisa de exatidão garantida - para cálculos, redação jurídica e outras tarefas em que erro não é aceitável, sistemas determinísticos e revisão humana são mais confiáveis que geração por modelo.
• A tarefa é sobre ações, não busca em documentos - criar um ticket, atualizar um registro - só o RAG não resolve, é preciso tools/MCP (veja abaixo).

Antes de começar, vale estimar o volume de documentos, a frequência de mudança e quem vai cuidar do índice - isso define se o RAG compensa ou se uma solução mais simples já resolve.

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.

Se precisar de ajuda com desenvolvimento, implementação de IA ou suporte ao site para o seu projeto - escreva-me.

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.

Termos deste artigo

RAG — Retrieval-Augmented Generation — geração aumentada por recuperação

pipeline — sequence of processing stages

retrieval — finding relevant context before generation — busca de contexto relevante antes da geração

LLM — Large Language Model — modelo de linguagem grande

Confluence — Atlassian wiki for team documentation — wiki da Atlassian para documentação de equipe

chunking — splitting documents into retrieval-friendly pieces — divisão de documentos em fragmentos para busca

embeddings — numeric vectors that capture text meaning — vetores numéricos que capturam o sentido do texto

vector store — database optimized for similarity search over embeddings — armazenamento otimizado para busca por similaridade de embeddings

Pinecone — managed vector database for similarity search — BD vetorial gerenciada para similaridade

pgvector — PostgreSQL extension for vector search — extensão do PostgreSQL para busca vetorial

vector db — database for similarity search over embeddings — BD para busca por similaridade de embeddings

Qdrant — vector database for similarity search — banco vetorial para busca por similaridade

reranking — reordering search results by relevance — reordenação de resultados por relevância

Chroma — open-source embedding database for RAG apps — BD de embeddings open-source para apps RAG

chunks — small text pieces indexed for retrieval — pedaços curtos de texto indexados para retrieval

top-k — keep only the k most likely next tokens when sampling — no sampling manter só os k tokens mais prováveis

LlamaIndex — framework for connecting LLMs to private data — framework para conectar LLM a dados privados

LangChain — framework for building LLM applications — framework para aplicações com LLM

fine-tuning — additional training of a model on domain data — treinamento adicional do modelo com dados do domínio

ANN — Approximate Nearest Neighbor — busca aproximada dos vizinhos mais próximos no espaço vetorial

system prompt — hidden instructions that steer the model for a task — instruções ocultas que guiam o comportamento do modelo

runbook — step-by-step playbook for incidents and operations — roteiro passo a passo para incidentes e operação

vector search — finding nearest neighbors in embedding space — busca dos vizinhos mais próximos no espaço de embeddings

cross-encoder — rerank model that scores query and document together — modelo de rerank que pontua consulta e documento juntos

guardrails — rules and filters that keep AI outputs safe and on-policy — regras e filtros que mantêm saídas de IA seguras e conforme política

faithfulness — how well an answer sticks to the retrieved sources — o quanto a resposta se apega às fontes recuperadas

tool calling — model invoking external tools or APIs — modelo chama ferramentas ou APIs externas

hit rate — share of requests served from cache — parcela de requisições atendidas pelo cache

reranker — model that reorders search hits by relevance — modelo que reordena resultados por relevância

SKU — Stock Keeping Unit — unidade de manutenção de estoque

baseline — reference measurement before changes

MCP — Model Context Protocol — protocolo de contexto do modelo

CRM — Customer Relationship Management — gestão de relacionamento com clientes

self-hosted — software you run on your own servers — software que você roda nos seus próprios servidores

GPU — Graphics Processing Unit — unidade de processamento gráfico