RAG em português: o guia completo de Retrieval-Augmented Generation

O problema que RAG resolve

Suponha que você é compliance officer numa gestora de ativos e precisa responder a seguinte pergunta de um Due Diligence Questionnaire de um fundo de pensão estrangeiro:

"Describe your firm's policy for handling material non-public information, including the procedures for adding securities to a restricted list and the frequency of compliance training."

A resposta existe, está escrita, em português, na sua Política de Confidencialidade e Informações Privilegiadas, página 12, parágrafo 4. O problema é que essa política tem 47 páginas, está num PDF dentro de uma pasta no SharePoint, e você ainda tem mais 199 perguntas pra responder até sexta.

Agora pense em duas formas de resolver isso:

Opção A (ChatGPT puro): você cola a pergunta no ChatGPT. Ele te dá uma resposta plausível, em inglês corporativo competente, citando práticas de mercado. Mas a resposta não é da sua empresa, é uma média estatística do que outras empresas dizem. Se o investidor cruzar com o que você efetivamente faz, você perde credibilidade. Pior: o ChatGPT pode inventar números, prazos ou frameworks que sua empresa não usa.

Opção B (RAG): o sistema vai até a sua Política de Confidencialidade, encontra o trecho exato que responde àquela pergunta, e gera a resposta com aquele trecho como única fonte permitida. A resposta cita: "Política-de-Confidencialidade-v3.pdf, p.12, §4: 'A adição de valores mobiliários à lista restrita é coordenada pela Diretoria de Compliance...'".

Esse é o salto que RAG permite. E é por isso que praticamente toda aplicação séria de IA empresarial em 2026 usa RAG, não LLM puro.

O que significa "RAG"

RAG é a sigla para Retrieval-Augmented Generation, ou em português livre: Geração Aumentada por Recuperação. O termo foi cunhado pela equipe da Meta AI Research no paper de 2020 liderado por Patrick Lewis, e descreve uma arquitetura que combina dois componentes:

1. Retrieval: um sistema de busca que encontra trechos de documentos relevantes para uma pergunta.
2. Generation: um modelo de linguagem que gera uma resposta usando apenas esses trechos como fonte.

A intuição é simples: ao invés do LLM tentar lembrar tudo o que sabe (e provavelmente alucinar), a gente dá pra ele a resposta na forma de contexto e pede pra ele apenas reformular em linguagem natural.

Reação

Como RAG funciona, passo a passo

A maioria dos guias técnicos de RAG pula direto pros embeddings e vector databases. Vou começar pelo o quê acontece antes, porque é aí que mora a maior parte da complexidade real.

Etapa 0: Ingestão de documentos

Antes de qualquer pergunta, você precisa preparar seus documentos. Esta etapa, normalmente esquecida nos papers, é onde 70% dos sistemas RAG dão errado em produção.

Para cada arquivo, o sistema precisa:

1. Extrair texto de PDFs, Word, Excel, PowerPoint, imagens (via OCR). PDFs são especialmente traiçoeiros: tabelas viram texto desordenado, colunas duplas se misturam, e figuras com texto importante somem.
2. Limpar e normalizar: remover headers/footers repetidos, juntar palavras quebradas por hífen no fim de linha, normalizar encoding (Ç virou Ç em Latin-1?).
3. Preservar estrutura: manter a noção de qual texto pertence a qual página, qual seção, qual capítulo. Sem isso, você perde a capacidade de citar fonte exata.

Etapa 1: Chunking (fatiamento)

LLMs têm um limite chamado context window, quanto texto eles aguentam ler de uma vez. Em 2026 esse limite chegou a 2 milhões de tokens em alguns modelos, mas isso ainda não é suficiente pra colocar 200 documentos inteiros como contexto numa só requisição (e mesmo se fosse, seria caríssimo e produziria respostas piores).

Então a gente fatia cada documento em chunks, pedaços de tamanho gerenciável, tipicamente entre 200 e 1.000 tokens (~150 a 750 palavras).

Aqui aparece o dilema do tamanho do chunk:

A solução moderna mais comum é chunking semântico: ao invés de cortar a cada N tokens, o sistema identifica fronteiras naturais (parágrafos, seções, mudanças de assunto) e corta lá. Isso preserva contexto e melhora dramaticamente a qualidade.

Etapa 2: Embeddings

Aqui entra a parte mágica. Cada chunk é transformado num vetor, uma lista de números (tipicamente 768, 1.536 ou 3.072 dimensões) que representa o "significado" daquele texto num espaço matemático.

O conceito chave: textos com significado parecido viram vetores próximos no espaço. "Política de gestão de risco" e "como mitigamos exposições" viram vetores próximos, mesmo sem compartilhar nenhuma palavra. Isso é o salto da busca semântica em relação à busca por palavra-chave.

Esses vetores são gerados por modelos de embedding, em 2026, os mais usados são text-embedding-3-large da OpenAI, voyage-3 da Voyage AI, e modelos open-source como BGE-M3 e nomic-embed-text.

Etapa 3: Vector database

Os vetores precisam ser armazenados num lugar que permita busca rápida por similaridade. Esse lugar é um vector database. As opções mais comuns em 2026:

• pgvector (extensão do PostgreSQL), simples, integrado ao banco que você já tem, bom até alguns milhões de vetores
• Pinecone, managed, escala fácil, caro
• Weaviate, Qdrant, Milvus, open-source, mais controle
• Vector search nativo do MongoDB Atlas, Elasticsearch, Redis, bom se você já usa essas stacks

Pra maioria dos casos empresariais brasileiros, pgvector é a escolha certa: roda em qualquer Postgres (incluindo Supabase), não adiciona infra nova, e dá conta dos volumes típicos (até ~10 milhões de chunks com tuning correto).

Etapa 4: Recuperação (retrieval)

Agora chega uma pergunta do usuário. O sistema:

1. Gera um embedding da pergunta (mesmo modelo usado pros chunks)
2. Busca no vector database os top-K chunks mais próximos (tipicamente K = 5 a 20)
3. Opcionalmente, rerank esses chunks usando um modelo mais preciso (e mais caro), tipo cohere-rerank-3 ou bge-reranker-v2. Isso melhora a precisão em ~15%.

Etapa 5: Geração com contexto

Finalmente, os chunks recuperados viram contexto pro LLM. O prompt típico fica assim:

Você é um assistente que responde perguntas usando APENAS o
contexto fornecido abaixo. Se a resposta não estiver no contexto,
diga "Não encontrei essa informação nos documentos". Cite sempre
a fonte de cada afirmação.

Contexto:
[Chunk 1, Política-de-Risco-v2.pdf, p.3]
A coordenação direta das atividades relacionadas à gestão de
risco é uma atribuição do Diretor de Risco...

[Chunk 2, Manual-de-Compliance.pdf, p.18]
O treinamento de compliance é realizado anualmente para todos...

Pergunta: Como a empresa gerencia risco operacional?

Resposta:

O LLM gera a resposta. Como ele tem instrução clara de só usar o contexto e citar a fonte, a resposta sai grounded, vinculada a fontes verificáveis.

RAG vs. as alternativas

RAG não é a única forma de "ensinar" um LLM sobre dados específicos. Vale entender as alternativas pra saber quando RAG é a escolha certa.

RAG vs Fine-tuning

Fine-tuning é pegar um modelo pré-treinado e continuar treinando ele com seus dados, ajustando os pesos do modelo para que ele "incorpore" o conhecimento.

A confusão mais comum: as pessoas tentam fine-tunar um modelo pra "saber sobre minha empresa". Isso quase sempre é uma má decisão. Use RAG.

Use fine-tuning quando o problema é "o modelo não fala como minha empresa fala" ou "o modelo não sabe extrair entidades do meu domínio específico". Não pra ensinar fatos.

RAG vs Long Context Window

A partir de 2024, surgiram modelos com contexto enorme: Gemini 1.5 Pro com 2M tokens, Claude 3.5 com 200K, GPT-4o com 128K. A pergunta natural é: "se eu posso colocar 1.000 páginas direto no contexto, pra que RAG?"

Três respostas:

1. Custo: cada token de contexto custa dinheiro. Mandar 500 páginas a cada query é proibitivamente caro em escala. RAG manda só os 5-10 chunks relevantes.
2. Lost in the middle: estudos (Liu et al, 2023) mostram que LLMs são piores em encontrar informação no meio de contextos longos. Performance cai ~20% pra info no meio. RAG entrega só o relevante, evitando o problema.
3. Auditabilidade: com contexto longo, você não sabe qual parte o modelo usou. Com RAG, você sabe exatamente quais chunks foram retornados. Pra compliance, isso não é negociável.

RAG vs Function Calling / Tool Use

LLMs modernos podem chamar funções externas (function calling). Você pode imaginar uma função buscar_documento(query) que faz a busca e retorna o resultado. Isso na verdade é RAG, só com um nome diferente. A diferença é que function calling permite ao LLM decidir quando chamar a busca, enquanto RAG tradicional sempre busca antes de gerar.

Os melhores sistemas modernos combinam ambos: chamam de agentic RAG.

Onde RAG é usado de verdade

RAG não é teoria. Em 2026, está rodando em produção em praticamente todo setor que lida com volume de documentos:

• Gestão de ativos: respondendo Due Diligence Questionnaires (DDQs) com base nos manuais de compliance da gestora (veja como o Wicko faz)
• Vendas B2B: respondendo RFPs de clientes corporativos usando product docs e respostas anteriores
• Segurança da informação: respondendo questionários de fornecedor (ISO 27001, SOC 2, CAIQ) usando políticas internas
• Jurídico: análise contratual, busca em jurisprudência, due diligence M&A
• Suporte ao cliente: chatbots que respondem com base na knowledge base oficial, evitando alucinações
• Saúde: assistentes médicos que respondem com base em protocolos hospitalares

As armadilhas do RAG (e como evitar)

RAG não é mágica. Os sistemas RAG mal feitos entregam resultados ruins por motivos previsíveis. Aqui vão as armadilhas mais comuns:

1. Chunking burro

Cortar documento a cada 500 caracteres parece simples, mas destrói o significado. Tabelas viram texto sem sentido, definições ficam separadas dos termos, contextos importantes somem. Solução: chunking semântico ou estrutural (quebrar por seção/parágrafo, não por contagem cega).

2. Embedding ruim em português

Modelo treinado majoritariamente em inglês entrega embeddings ruins pra pt-BR. Solução: testar 2-3 modelos com perguntas reais do seu domínio antes de escolher.

3. K muito baixo ou alto

Buscar só 3 chunks pode perder a resposta. Buscar 50 dilui o sinal e enche o contexto de ruído. Solução: começar com K=10, medir, e ajustar.

4. Sem reranking

A busca por similaridade cosseno é boa mas não perfeita. Sem reranking, os top-5 podem incluir chunks só tangencialmente relevantes. Solução: usar um reranker depois da busca semântica inicial.

5. Prompt sem instrução de citação

Se você não pedir explicitamente que o modelo cite a fonte e diga "não sei" quando não encontrar, ele vai improvisar. Solução: prompt engineering rigoroso, idealmente com schema estruturado de saída.

6. Ignorar o "lost in the middle"

Mesmo com top-K bons, se você joga 10 chunks no contexto sem ordenação, o modelo presta menos atenção nos do meio. Solução: colocar os chunks mais relevantes no início e no fim do contexto.

7. Não medir nada

A maioria dos times implementa RAG e nunca mais avalia. Solução: criar um conjunto de pares pergunta/resposta-correta e medir periodicamente. Frameworks como RAGAS e TruLens ajudam.

RAG no Brasil: o estado da arte em 2026

Falar de RAG em português envolve alguns desafios específicos que os papers em inglês não cobrem:

1. Acentuação e normalização: já comentei, mas vale repetir, sistemas que não normalizam Unicode pra português entregam busca pior. Sempre normalize pra NFC.
2. Documentos legados: muito documento corporativo brasileiro vem de PDF escaneado (pré-2010). OCR é obrigatório, e OCR ruim em português é um desastre. Use modelos de OCR multilíngues recentes (Tesseract 5+, EasyOCR, ou serviços managed).
3. Linguagem formal vs coloquial: documentos jurídicos brasileiros usam linguagem altamente formal ("outrossim", "destarte", "consoante") que aparece pouco no treino dos embeddings. Modelos modernos lidam bem, mas vale testar.
4. Termos regulatórios: CVM, BACEN, ANBIMA, CMN, COAF, esses acrônimos precisam estar normalizados ou expandidos em algum momento, ou a busca falha em queries que usam o nome cheio.
5. Multi-idioma: muito documento brasileiro mistura português e inglês (especialmente em fundos com investidores estrangeiros). Embeddings multilíngues lidam com isso melhor que modelos só pt-BR.

O futuro: além do RAG clássico

RAG está evoluindo rápido. As três tendências mais quentes em 2026:

Agentic RAG

Em vez de uma única busca→geração, o LLM age como agente e decide quando buscar, o quê buscar, e se precisa fazer múltiplas buscas. Isso permite responder perguntas complexas que exigem decompor em sub-perguntas.

GraphRAG

Em vez de só busca por similaridade vetorial, o sistema constrói um grafo de relações entre entidades extraídas dos documentos (pessoas, empresas, contratos, datas) e usa esse grafo na recuperação. Bom pra perguntas que exigem ligação entre múltiplos documentos.

Multi-modal RAG

RAG que indexa também imagens, gráficos e tabelas, não só texto. Crítico pra documentos brasileiros cheios de organogramas, fluxogramas e dashboards.

Resumo

RAG é a forma moderna de fazer IA empresarial confiável. Ele combina busca em documentos próprios com geração por LLM, eliminando alucinação e adicionando citações verificáveis. Os componentes essenciais são:

1. Ingestão e chunking dos documentos
2. Embeddings que capturam significado em vetores
3. Vector database pra busca rápida
4. Recuperação com top-K + reranking
5. Geração com contexto e instrução de citar fonte

Quando bem feito, RAG transforma um LLM genérico numa ferramenta que responde perguntas sobre o seu próprio negócio com a precisão e auditabilidade que compliance, jurídico e investidores exigem.

Quando mal feito, RAG entrega resultados que parecem certos mas erram nos detalhes, o que muitas vezes é pior do que admitir "não sei".

A diferença está nos detalhes que cobri aqui: chunking semântico, embeddings adequados ao português, reranking, prompt engineering rigoroso, e medição contínua.