O que é RAG
📍 In One Sentence
RAG recupera documentos relevantes da sua base de conhecimento e os fornece ao LLM junto com a pergunta, para que o modelo responda a partir dos seus dados em vez de adivinhar.
💬 In Plain Terms
Sem RAG = prova de livro fechado (o modelo responde de memória, pode inventar detalhes). Com RAG = prova de livro aberto (o modelo consulta suas anotações primeiro). Ainda pode interpretar mal as anotações, mas pelo menos não inventa fatos.
RAG combina um recuperador que encontra informações relevantes com um gerador que escreve a resposta final usando essas informações. O recuperador pesquisa uma base de conhecimento (como PDFs indexados, páginas da web ou documentos internos) com base na consulta do usuário. O gerador então lê os trechos recuperados e produz uma resposta que cita ou reflete esse conteúdo.
Isso é diferente de uma chamada simples a um modelo de linguagem, em que o modelo responde apenas a partir de seus parâmetros internos. No RAG, o modelo "lê" contexto atualizado toda vez que você faz uma pergunta. Em abril de 2026, RAG é a arquitetura padrão para sistemas de IA empresarial que precisam responder a partir de documentos proprietários, dados recentes ou bases de conhecimento privadas.
Por que RAG importa
RAG importa porque reduz alucinações e mantém as respostas atualizadas. Um modelo de linguagem puro pode inventar detalhes com confiança, especialmente em tópicos especializados ou recentes. Com RAG, as respostas são ancoradas em documentos recuperados que você controla.
RAG também é importante para privacidade e governança. Em vez de fazer fine-tuning de um modelo com dados sensíveis, você pode manter esses dados na sua própria infraestrutura e passar apenas fragmentos relevantes ao modelo no momento da consulta. Assim, o modelo raciocina sobre seu conteúdo sem absorvê-lo permanentemente. Para contexto de privacidade de dados, a LGPD brasileira e a ANPD regulam o processamento de dados pessoais — RAG facilita a conformidade ao manter dados pessoais fora dos parâmetros do modelo.
Quando os documentos que você deseja recuperar não podem sair da sua infraestrutura, todo o pipeline RAG pode ser executado no seu próprio hardware.
Como funciona um sistema RAG passo a passo
Um sistema RAG típico passa por quatro etapas principais: ingestão, indexação, recuperação e geração. Cada etapa pode ser ajustada de forma independente.
- 1Ingestão: Você carrega documentos (por exemplo PDFs, artigos da base de conhecimento, tickets, código) e os divide em fragmentos, geralmente de 200–1.000 tokens cada. Metadados como títulos, datas, autores ou tags podem ser anexados.
- 2Indexação: Cada fragmento é transformado em uma representação vetorial usando um modelo de embedding e armazenado em um banco de dados vetorial ou índice de busca. Isso permite ao sistema encontrar conteúdo semanticamente similar para novas consultas.
- 3Recuperação: Quando o usuário faz uma pergunta, o sistema converte a consulta em vetor e recupera os fragmentos mais relevantes do índice. Filtros (como intervalo de datas, tipo de documento ou permissões de usuário) podem ser aplicados nessa etapa.
- 4Geração: O sistema constrói um prompt que inclui a pergunta do usuário e os fragmentos recuperados e o envia a um modelo de linguagem. O modelo gera uma resposta consistente com o contexto fornecido.
Como a recuperação e a geração estão desacopladas, você pode melhorar uma sem alterar a outra — por exemplo, trocar por um recuperador melhor mantendo o mesmo modelo.
RAG vs Fine-Tuning: quando usar cada um
RAG e fine-tuning resolvem problemas diferentes e funcionam melhor quando combinados, não tratados como alternativas. Use RAG primeiro. Adicione fine-tuning apenas quando precisar de mudanças de comportamento consistentes que o RAG não consegue fornecer via prompting.
| Fator | RAG | Fine-Tuning |
|---|---|---|
| Fonte de conhecimento | Recuperado no momento da consulta a partir dos seus documentos | Incorporado nos parâmetros do modelo durante o treinamento |
| Atualidade dos dados | Em tempo real — atualize documentos, respostas mudam imediatamente | Estático — requer retreinamento para atualizar |
| Dados sensíveis | Permanecem na sua infraestrutura — o modelo nunca os absorve | Absorvidos nos pesos do modelo permanentemente |
| Rastreabilidade | Cada resposta pode ser rastreada até os documentos fonte | Sem proveniência clara para o texto gerado |
| Custo de atualização | Baixo — adicione ou remova documentos do índice | Alto — requer nova execução de treinamento |
| Mudança de estilo/comportamento | Não pode alterar o comportamento do modelo | Pode ensinar estilo, tom e comportamento de domínio consistentes |
| Melhor para | Políticas, documentação de produto, dados recentes, dados privados | Comportamento de domínio fixo, tarefas estreitas e estáveis |
| Uso típico | Q&A empresarial, bots de suporte, assistentes de pesquisa | Processamento de documentos jurídicos, codificação médica |
Comparação de bancos de dados vetoriais
A escolha do banco de dados vetorial certo depende da sua escala, requisitos de residência de dados e modelo operacional. A tabela abaixo cobre as seis opções mais amplamente implantadas em 2026.
| Banco de dados | Tipo | Melhor para | Residência de dados na UE | Auto-hospedado | Custo aproximado |
|---|---|---|---|---|---|
| Pinecone | Nuvem gerenciada | Início rápido, escala de produção com mínima operação | Região UE disponível | Não | Camada gratuita; ~$70/mês starter |
| Weaviate | Open-source / gerenciado | Esquema flexível, busca híbrida, conformidade UE | Auto-hospedado ou nuvem UE | Sim | Grátis (auto-hospedado); gerenciado a partir de $25/mês |
| Chroma | Open-source, local | Desenvolvimento local, prototipagem, conjuntos pequenos de documentos | On-premise (controle total) | Sim | Grátis |
| Milvus | Open-source / gerenciado | Cargas de trabalho empresariais em escala de bilhões | Auto-hospedado ou nuvem UE (Zilliz) | Sim | Grátis (auto-hospedado); gerenciado a partir de $65/mês |
| Qdrant | Open-source / gerenciado | Busca vetorial filtrada de alto desempenho | Região UE disponível; auto-hospedado | Sim | Grátis (auto-hospedado); gerenciado a partir de $25/mês |
| pgvector | Extensão do PostgreSQL | Equipes já no PostgreSQL, evitando nova infraestrutura | Onde o PostgreSQL rodar | Sim | Grátis (extensão do PostgreSQL) |
Exemplo: Sem RAG vs com RAG
O benefício do RAG fica claro ao comparar responder apenas de memória com responder usando documentos recuperados. Aqui está um exemplo conceitual para uma pergunta sobre políticas internas.
Prompt ruim – Sem RAG
"Qual é a política de reembolso de viagens da nossa empresa?"
O modelo vai adivinhar com base em padrões genéricos, que podem estar errados para a sua organização.
Prompt bom – Com RAG
"Você é um assistente que responde perguntas sobre as políticas internas da nossa empresa. Aqui estão os trechos relevantes da política:
...insira os fragmentos de texto da política recuperados...
Usando apenas as informações nesses trechos, responda à pergunta: 'Qual é a política de reembolso de viagens da nossa empresa?' Se algo não estiver coberto nos trechos, diga isso."
No segundo caso, o modelo está ancorado nos seus documentos de política reais, e fica claro o que fazer quando a informação está ausente.
RAG em fluxos de trabalho multimodelo
RAG se torna ainda mais poderoso quando combinado com múltiplos modelos e prompting estruturado. Você pode:
- Usar um modelo ou serviço para embedar e recuperar documentos, e outro para gerar respostas.
- Aplicar prompts focados em raciocínio (como chain-of-thought) sobre o contexto recuperado.
- Executar o mesmo prompt RAG em vários modelos para comparar como cada um usa os mesmos documentos.
Essa modularidade é um dos maiores pontos fortes do RAG: você pode atualizar componentes individuais — recuperador, índice, gerador, prompts — sem reconstruir todo o sistema.
RAG em ambientes regulados: Brasil, UE, Japão e China
RAG é a arquitetura preferida para organizações que operam sob regulamentações de proteção de dados, pois dados sensíveis nunca entram nos parâmetros do modelo.
Brasil (LGPD/ANPD): A Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) e as diretrizes da Autoridade Nacional de Proteção de Dados (ANPD) exigem base legal para o processamento de dados pessoais e impõem obrigações de minimização de dados. RAG facilita a conformidade porque os documentos permanecem na sua infraestrutura e apenas trechos relevantes são passados ao LLM no momento da consulta — nenhum dado pessoal é transmitido a um provedor externo durante a geração. Para dados de saúde e financeiros sujeitos a regulamentações setoriais adicionais, bancos de dados vetoriais auto-hospedados são a opção recomendada.
UE / RGPD: RAG é a arquitetura preferida para organizações da UE que gerenciam dados pessoais. Como os documentos permanecem na sua infraestrutura, nenhum dado pessoal é transmitido a um provedor externo durante a geração. O AI Act da UE, Artigo 11, exige que sistemas de IA de alto risco documentem suas fontes de conhecimento — um sistema RAG com repositório de documentos versionado atende a esse requisito diretamente.
Japão (METI): As Diretrizes de Governança de IA do METI exigem que as organizações documentem as fontes de dados usadas em decisões assistidas por IA. Um sistema RAG com repositório de documentos curado e versionado produz exatamente esse rastro de auditoria.
China (CAC): As Medidas de Serviço de IA Generativa do CAC (2023) exigem que as fontes de dados de recuperação sejam documentadas e revisadas antes do uso em sistemas de IA em produção. Arquiteturas RAG com fontes domésticas aprovadas são a arquitetura compatível padrão para IA empresarial na China.
Erros comuns
❌ Fragmentos muito longos
Why it hurts: Fragmentos com mais de 1.000 palavras reduzem a precisão da recuperação e desperdiçam tokens de contexto com conteúdo irrelevante.
Fix: Use fragmentos de 200–500 palavras com sobreposição de 10–20%. Teste com 3 tamanhos de fragmento antes de decidir.
❌ Sem limiar de relevância
Why it hurts: Passar todos os fragmentos recuperados ao LLM independentemente da pontuação de similaridade adiciona ruído ao contexto e confunde o modelo.
Fix: Defina um limiar mínimo de similaridade de cosseno de 0,7. Retorne "não encontrado na base de conhecimento" quando nenhum fragmento superar o limiar.
❌ Tratar o conteúdo recuperado como instruções
Why it hurts: Se os documentos recuperados contiverem texto adversarial, o modelo pode interpretar esse conteúdo como instruções do sistema, levando a uma injeção de prompt.
Fix: Use delimitadores claros entre as instruções do sistema e o conteúdo recuperado. Nunca trate o conteúdo recuperado como instruções executáveis.
❌ Não testar a recuperação de forma isolada
Why it hurts: A maioria das falhas de RAG são falhas de recuperação — os documentos errados são retornados. Melhorar o gerador não ajuda se a recuperação estiver com problemas.
Fix: Teste seu recuperador de forma independente em 20 consultas representativas antes de avaliar o pipeline completo.
Como implementar RAG
- 1Identifique fontes de conhecimento: documentos, PDFs, bancos de dados ou APIs dos quais a IA precisa responder.
- 2Converta documentos em embeddings pesquisáveis usando um banco de dados vetorial (Pinecone, Weaviate, Chroma, Milvus) com fragmentos de 200–500 palavras.
- 3Configure o pipeline de recuperação no momento da consulta: converta a consulta em vetor, recupere os fragmentos mais similares, passe o contexto e a pergunta ao LLM.
- 4Implemente uma estratégia de fragmentação com sobreposição de 10–20% para manter a coerência do contexto entre fragmentos adjacentes.
- 5Adicione limiar de relevância (>0,7 de similaridade de cosseno) e tratamento de fallback para quando não houver contexto relevante.
Fontes
- Lewis, P., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020. — O artigo RAG original que introduz a arquitetura recuperar-depois-gerar.
- Gao, Y., et al. (2023). "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997. — Levantamento abrangente de arquiteturas RAG e variantes até 2023.
- Guu, K., et al. (2020). "REALM: Retrieval-Augmented Language Model Pre-Training." ICML 2020. — Abordagem de pré-treinamento que integra a recuperação ao treinamento de modelos de linguagem.
- OpenAI. (2024). "Retrieval and Augmentation in Language Models." — Documentação da plataforma.
Perguntas frequentes
O que é RAG?
RAG (Retrieval-Augmented Generation) recupera documentos relevantes antes de gerar uma resposta, em vez de depender do conhecimento de treinamento do modelo. A resposta é ancorada nos seus documentos, não inventada.
Como o RAG reduz alucinações?
O RAG ancora a resposta no texto recuperado. O prompt instrui o modelo a responder apenas com base nos trechos fornecidos e a sinalizar informações ausentes. Isso elimina o incentivo do modelo de inventar detalhes plausíveis.
Qual é a diferença entre RAG e fine-tuning?
O RAG recupera conhecimento no momento da consulta e o adiciona ao prompt. O fine-tuning modifica os parâmetros do modelo permanentemente. RAG é melhor para dados dinâmicos; fine-tuning para comportamento estável.
RAG funciona com qualquer modelo de linguagem?
Sim. RAG é agnóstico ao modelo. Qualquer LLM que aceite um prompt com contexto pode usar documentos recuperados. Isso inclui GPT-5.5, Claude Opus, Gemini, modelos open-source como Llama e modelos locais via Ollama.
Qual é o tamanho ideal de fragmento para RAG?
Para a maioria dos casos: 200–500 palavras por fragmento com sobreposição de 10–20% entre fragmentos adjacentes. Fragmentos menores (50–100 palavras) melhoram a precisão; fragmentos maiores (500+ palavras) fornecem mais contexto, mas arriscam incluir trechos irrelevantes.
O que é um limiar de relevância no RAG?
Um limite de pontuação de similaridade. Se a similaridade de um documento recuperado estiver abaixo do limiar (por exemplo, 0,7 de similaridade de cosseno), ele não é passado ao LLM. Isso evita que contexto de baixa qualidade confunda o modelo.
RAG é melhor do que uma janela de contexto grande?
Para coleções massivas de documentos, sim. RAG busca milhões de documentos em milissegundos via similaridade semântica. Janelas de contexto grandes são mais caras e exigem saber de antemão quais documentos incluir.
Posso combinar RAG com fine-tuning?
Sim. Faça fine-tuning de um modelo para melhorar estilo, tom ou comportamento de domínio. Em seguida, use RAG para ancorá-lo em fatos atuais. Isso cria o melhor dos dois: comportamento consistente + ancoragem factual.
Como evito ataques de injeção de prompt no RAG?
Valide o conteúdo recuperado antes de incluí-lo no prompt. Use delimitadores claros entre as instruções do sistema e o texto recuperado. Nunca trate o conteúdo recuperado como instruções executáveis. Monitore padrões suspeitos.
RAG precisa de um banco de dados vetorial?
Não para coleções pequenas. A busca por palavras-chave BM25 funciona para menos de 10.000 documentos sem vetores. Para similaridade semântica em coleções maiores, um banco de dados vetorial (Weaviate, Pinecone, Chroma, Milvus) é essencial.