O que é RAG (Retrieval Augmented Generation): Guia Completo [2026]

Se você já perguntou algo para uma IA e recebeu uma resposta inventada com toda a confiança do mundo, você esbarrou no maior limite dos modelos de linguagem: eles só sabem o que viram no treinamento. O que é RAG, então? RAG (Retrieval Augmented Generation, ou geração aumentada por recuperação) é a técnica que resolve esse limite conectando o modelo a uma base de conhecimento externa. Antes de responder, o sistema busca os documentos relevantes e entrega esse material para o modelo usar como contexto. O resultado são respostas baseadas em dados reais, atualizados e verificáveis.

Na Marfin, RAG deixou de ser assunto de paper acadêmico e virou peça de trabalho no dia a dia. Usamos a técnica para dar às nossas automações acesso a documentação interna, histórico de clientes e conteúdo do blog, e vimos na prática a diferença entre um chatbot que chuta e um assistente que responde com fonte. Neste guia, explicamos como o RAG funciona por dentro, quando ele vence o fine-tuning, como montar um pipeline completo, quais ferramentas usar em 2026 e quanto tudo isso custa.

O que é RAG e como funciona

RAG é uma arquitetura que combina dois componentes: um sistema de recuperação de informação (retrieval) e um modelo de linguagem gerador (generation). O termo apareceu em um paper do Facebook AI Research em 2020, mas explodiu de verdade a partir de 2023, quando empresas perceberam que precisavam de LLMs que soubessem responder sobre seus próprios dados, e não apenas sobre a internet pública de meses atrás.

O fluxo básico é simples de entender. O usuário faz uma pergunta. Em vez de mandar essa pergunta direto para o modelo, o sistema primeiro busca em uma base de conhecimento os trechos de documentos mais relevantes para aquela pergunta. Esses trechos são inseridos no prompt junto com a pergunta original, com uma instrução do tipo "responda usando apenas o contexto abaixo". O modelo então gera a resposta apoiado nesse material. Na prática, é como dar uma prova com consulta para o modelo: ele continua responsável por interpretar e redigir, mas agora tem o material certo na mesa.

As duas etapas: retrieval e generation

A etapa de retrieval é onde mora a maior parte da engenharia. O sistema precisa encontrar, entre milhares ou milhões de documentos, os três, cinco ou dez trechos que de fato respondem à pergunta. Se a busca trouxer lixo, o modelo vai gerar uma resposta ruim mesmo sendo o melhor LLM do mercado. A qualidade do retrieval define o teto de qualidade do sistema inteiro, e é por isso que times experientes gastam mais tempo ajustando busca do que trocando de modelo.

A etapa de generation é onde o modelo de linguagem entra. Aqui valem as boas práticas que já cobrimos no nosso guia de prompt engineering: instruir o modelo a responder apenas com base no contexto fornecido, pedir que ele admita quando a informação não está nos documentos e exigir citação da fonte de cada afirmação. Modelos recentes como o Claude Opus 4.8 e o Sonnet 4.5 seguem essas instruções com muito mais disciplina do que as gerações anteriores, o que tornou sistemas RAG bem mais confiáveis em 2026.

Embeddings e busca vetorial

Para a busca funcionar, os documentos precisam estar em um formato que a máquina consiga comparar semanticamente. É aí que entram os embeddings: representações numéricas de texto em forma de vetores, geralmente com centenas ou milhares de dimensões. Textos com significados parecidos ficam próximos nesse espaço vetorial. A frase "quanto custa o plano Pro" e a frase "qual o preço da assinatura profissional" não compartilham quase nenhuma palavra, mas seus embeddings ficam colados um no outro.

O processo funciona assim: cada trecho de documento passa por um modelo de embedding e vira um vetor, que é armazenado em um banco vetorial. Quando o usuário pergunta algo, a pergunta também vira um vetor, e o banco retorna os trechos cujos vetores estão mais próximos, usando uma métrica como similaridade de cosseno. Essa busca semântica captura intenção, e não apenas palavras exatas, o que é a grande vantagem sobre a busca tradicional por palavra-chave. Os sistemas mais maduros combinam as duas: busca vetorial para semântica e busca lexical (BM25) para termos exatos como códigos de produto e nomes próprios, no que se chama de busca híbrida.

Por que os modelos alucinam e como o RAG reduz isso

Modelos de linguagem são treinados para prever a próxima palavra mais provável, e fazem isso com base em padrões estatísticos aprendidos durante o treinamento. Quando a pergunta toca um assunto que o modelo não viu, ou viu pouco, ele não tem um mecanismo nativo para dizer "não sei". Ele gera o texto mais plausível, e texto plausível sem lastro em fatos é a definição de alucinação. Some a isso o corte de conhecimento (um modelo treinado até janeiro de 2026 desconhece tudo que aconteceu depois) e a total ignorância sobre dados privados da sua empresa, e fica claro o tamanho do buraco.

O RAG ataca as três frentes de uma vez. Contra a alucinação, ele ancora a resposta em documentos reais e instrui o modelo a não sair deles. Contra o corte de conhecimento, ele permite atualizar a base a qualquer momento: publicou uma política nova, ela entra no índice em minutos e passa a alimentar as respostas. Contra a ignorância sobre dados privados, ele dá ao modelo acesso controlado a contratos, manuais, tickets de suporte e qualquer documento interno, sem precisar treinar nada.

Tem ainda um benefício que consideramos decisivo para uso corporativo: rastreabilidade. Um sistema RAG bem construído cita a fonte de cada resposta. O usuário consegue clicar e verificar de onde a informação saiu. Isso muda a relação de confiança com a ferramenta, porque transforma a resposta de "a IA disse" em "está na página 12 do manual, e aqui está o link". Nenhum benchmark captura o valor disso quando o assunto é convencer um time jurídico ou financeiro a adotar IA. Se você quer entender melhor onde a IA generativa encaixa na operação de uma empresa, nosso guia de IA generativa para negócios cobre esse panorama completo.

RAG vs fine-tuning vs contexto longo

Sempre que explicamos RAG para alguém, a mesma pergunta aparece: por que não fazer fine-tuning do modelo com os dados da empresa? A resposta curta: para conhecimento factual, fine-tuning é quase sempre a escolha errada. Fine-tuning ajusta os pesos do modelo para mudar comportamento, estilo e formato de saída. Ele funciona bem para ensinar o modelo a escrever no tom da sua marca ou a seguir um formato específico de resposta. Ele funciona mal para injetar fatos, porque o modelo não memoriza documentos de forma confiável, continua alucinando, e cada atualização de dados exige um novo treinamento, com custo e demora.

RAG inverte essa lógica. O conhecimento fica fora do modelo, em uma base que você controla, atualiza e audita. Adicionar um documento novo custa centavos de embedding e alguns segundos de indexação. Remover informação errada é apagar um registro do banco. E você pode trocar de modelo (de Claude para outro, ou de uma versão para a mais recente) sem perder nada, porque a inteligência sobre os seus dados não está nos pesos.

E a janela de contexto longa? Modelos como o Claude Opus 4.7 trabalham com 200 mil tokens de contexto, o que dá para colocar um livro inteiro no prompt. Para bases pequenas, jogar tudo no contexto funciona e dispensa infraestrutura. Mas a conta muda rápido: processar 200 mil tokens em cada requisição custa caro e adiciona latência, e a maioria das bases corporativas passa de milhões de tokens, o que não cabe em janela nenhuma. Além disso, pesquisas seguem mostrando que modelos perdem precisão quando a informação relevante está enterrada no meio de contexto gigante. Nossa regra prática na Marfin: até umas dezenas de páginas, contexto direto resolve; acima disso, RAG. E as duas técnicas se combinam, porque uma janela grande permite recuperar mais trechos com mais folga.

Vale citar também o MCP (Model Context Protocol), padrão aberto da Anthropic que virou a forma padrão de conectar modelos a fontes de dados em 2026. Em muitos casos, um servidor MCP apontando para sua base substitui parte do pipeline RAG tradicional. Explicamos essa peça em detalhe no nosso guia sobre MCP.

Como montar um pipeline de RAG na prática

Um pipeline de RAG completo tem cinco etapas: ingestão e chunking, embedding, armazenamento, retrieval e geração. Vamos passar por cada uma com as decisões que você vai precisar tomar.

Chunking: dividindo os documentos

Documentos inteiros são grandes demais para virar um único embedding com qualidade, então o primeiro passo é dividi-los em pedaços, os chunks. O tamanho do chunk é uma das decisões que mais afetam o resultado final. Chunks muito pequenos perdem contexto: uma frase solta sobre "o desconto de 15%" não diz desconto de quê. Chunks muito grandes diluem o significado e trazem ruído junto com a informação útil. Na nossa experiência, algo entre 300 e 800 tokens com sobreposição de 10% a 20% entre chunks consecutivos funciona bem como ponto de partida, mas o ideal é respeitar a estrutura do documento: quebrar por seção, por título, por parágrafo lógico. Chunking semântico, que usa a própria estrutura do texto para decidir os cortes, quase sempre supera cortes de tamanho fixo.

Embeddings e banco vetorial

Com os chunks prontos, cada um passa pelo modelo de embedding. Em 2026, as opções mais usadas são o text-embedding-3-large da OpenAI, os modelos da Voyage AI (que a Anthropic recomenda para uso com Claude) e alternativas open source como os modelos da família BGE, que rodam na sua infraestrutura de graça. Para conteúdo em português, vale testar mais de um: a diferença de qualidade entre modelos de embedding em textos em português é maior do que os benchmarks em inglês sugerem.

Os vetores vão para um banco vetorial. Aqui existe um espectro que vai de "use o banco que você já tem" até "banco vetorial dedicado". No primeiro grupo, o pgvector, extensão do PostgreSQL, é o nosso padrão: como já usamos Supabase como backend na maioria dos projetos, ganhamos busca vetorial no mesmo banco onde moram os outros dados, com RLS para controle de acesso por usuário. No segundo grupo estão Pinecone, Weaviate e Qdrant, que fazem sentido quando a escala passa de dezenas de milhões de vetores ou quando você precisa de latência mínima em busca. Para quase toda startup começando, pgvector no Supabase resolve, e comparamos essa base com a alternativa do Google no nosso artigo Supabase vs Firebase.

Retrieval e reranking

Na hora da pergunta, o sistema busca os chunks mais próximos do vetor da query. O número de resultados recuperados (o famoso top-k) costuma ficar entre 5 e 20. Mas busca vetorial pura tem limites, e os pipelines sérios adicionam duas camadas. A primeira é a busca híbrida, combinando vetores com busca lexical, indispensável quando os usuários pesquisam por termos exatos. A segunda é o reranking: um modelo especializado (como os rerankers da Cohere ou da Voyage) reordena os 20 ou 50 resultados iniciais e devolve os melhores, com precisão bem maior do que a busca inicial. O reranker adiciona algumas dezenas de milissegundos e melhora a qualidade final de forma visível. Foi a otimização com melhor custo-benefício que aplicamos nos nossos pipelines.

Geração com citação de fontes

Os chunks selecionados entram no prompt com a pergunta e as instruções. O modelo gera a resposta e, se bem instruído, cita qual chunk sustenta cada afirmação. Duas práticas que adotamos: pedir que o modelo responda "não encontrei essa informação na base" quando o contexto não cobre a pergunta, em vez de improvisar, e registrar em log quais chunks alimentaram cada resposta, o que facilita depurar quando algo sai errado. Errou a resposta? Na maior parte das vezes o problema está no retrieval, e o log mostra isso na hora.

O que é RAG na prática: casos de uso em marketing e negócios

A teoria é bonita, mas o que nos convenceu foi ver RAG resolvendo problemas reais. O caso mais óbvio é o suporte ao cliente: um assistente conectado à central de ajuda, à documentação do produto e ao histórico de tickets responde dúvidas com precisão e cita o artigo de origem, derrubando o volume que chega ao time humano. Diferente dos chatbots de árvore de decisão que todo mundo odeia, um assistente com RAG entende a pergunta como ela foi feita.

No marketing, usamos RAG para dar memória às nossas automações de conteúdo. Um agente que escreve posts conectado a uma base com nossos artigos publicados, guias de tom de voz e dados de performance produz conteúdo consistente com o que a marca já disse, em vez de reinventar o posicionamento a cada geração. Essa mesma lógica alimenta personalização de e-mail em escala e qualificação de leads com contexto do CRM. Mostramos várias dessas aplicações no nosso guia de IA no marketing.

Conhecimento interno é outro campo fértil. Empresas acumulam anos de documentos, propostas, contratos e decisões espalhados em drives e wikis que ninguém consegue buscar direito. Um RAG em cima desse acervo vira a memória institucional pesquisável que o buscador do drive nunca foi. Times de vendas consultam propostas antigas, o jurídico encontra cláusulas em segundos, novos funcionários tiram dúvidas de onboarding sem interromper ninguém.

E tem um ângulo que interessa a quem produz conteúdo: os buscadores com IA, como o Google com a SGE e o ChatGPT com busca, funcionam internamente como sistemas RAG gigantes, recuperando páginas da web para compor respostas. Otimizar seu conteúdo para ser recuperado e citado por esses sistemas é a nova fronteira do SEO, e cobrimos isso em detalhe no nosso guia de SEO para IA.

Ferramentas e stack para RAG em 2026

Para desenvolver os pipelines, nossa ferramenta número um é o Claude Code, que usamos para escrever e manter o código de RAG de ponta a ponta: ele lê o projeto inteiro, implementa o chunking, cria as tabelas com pgvector e testa o retrieval de forma autônoma no terminal. Para o trabalho de building no dia a dia, com edição e depuração em cima do editor, usamos o Cursor AI. Essa dupla cobre 90% do nosso fluxo de desenvolvimento.

Na camada de orquestração, LangChain e LlamaIndex continuam sendo os frameworks mais populares, com componentes prontos para cada etapa do pipeline. Nossa opinião sincera: eles aceleram protótipos, mas para produção preferimos código próprio e enxuto, porque um pipeline RAG básico tem poucas centenas de linhas e a abstração extra vira custo de manutenção. Quem prefere montar fluxos visuais sem código encontra nós de RAG prontos em ferramentas de automação, e o n8n faz esse papel bem para times não técnicos.

Na camada de dados, o Supabase com pgvector é o nosso backend padrão, pelos motivos que já citamos: PostgreSQL de verdade, auth, storage e edge functions no mesmo lugar. Para o modelo gerador, o Claude é nossa escolha: o Opus 4.8 para respostas que exigem raciocínio pesado sobre muitos documentos e o Haiku 4.5 para volume alto com custo baixo. A comparação completa entre os modelos do mercado está no nosso Claude vs ChatGPT vs Gemini.

Preços e planos

A boa notícia: RAG é barato para começar. O custo se divide em quatro linhas. Embeddings custam centavos: o text-embedding-3-small da OpenAI sai a US$ 0,02 por milhão de tokens, o que significa indexar uma base de 10 mil páginas por poucos dólares, uma única vez. O banco vetorial pode custar zero: o plano Free do Supabase já inclui pgvector, e o plano Pro, a US$ 25 por mês, aguenta bases de centenas de milhares de vetores com folga. O Pinecone tem plano Starter gratuito e planos pagos a partir de US$ 50 mensais, enquanto Qdrant e Weaviate têm versões open source para rodar na sua própria infraestrutura sem licença.

A linha mais pesada é a geração. Na API da Anthropic, o Haiku 4.5 custa US$ 1 por milhão de tokens de entrada e US$ 5 por milhão de saída, e como cada requisição RAG carrega alguns milhares de tokens de contexto, um assistente com mil consultas diárias fica na casa de poucos dólares por dia. Prompt caching derruba esse custo ainda mais quando as instruções do sistema se repetem entre chamadas. O reranking, se você adotar, adiciona algo como US$ 1 a US$ 2 por mil buscas nos serviços da Cohere e da Voyage.

Somando tudo, um RAG de produção para uma startup pequena roda tranquilamente abaixo de US$ 50 mensais no início, com o grosso do investimento indo para o tempo de desenvolvimento, não para infraestrutura. Comparado ao custo de um fine-tuning bem feito, que envolve preparação de dataset, treinamento e reavaliação a cada atualização, a diferença é de uma ordem de grandeza.

7 dicas para implementar RAG sem dor de cabeça

1. Comece pelo retrieval, não pelo modelo. Antes de discutir qual LLM usar, monte um conjunto de 30 a 50 perguntas reais e verifique se a busca retorna os documentos certos para cada uma. Se o retrieval falha, nenhum modelo salva a resposta.

2. Respeite a estrutura dos documentos no chunking. Cortar texto a cada 500 tokens sem olhar títulos e seções produz chunks sem pé nem cabeça. Quebre por seção lógica e preserve o título da seção dentro de cada chunk como contexto.

3. Use busca híbrida desde o início. Busca vetorial pura erra feio com códigos de produto, siglas e nomes próprios. Combinar vetores com BM25 custa pouco para implementar e evita uma classe inteira de falhas.

4. Adicione um reranker antes de trocar de modelo de embedding. Quando a qualidade da busca decepciona, o instinto é trocar o embedding. Na nossa experiência, colocar um reranker em cima dos resultados existentes melhora mais, com menos esforço de migração.

5. Instrua o modelo a admitir quando não sabe. A instrução "se o contexto não contém a resposta, diga que não encontrou a informação" é a linha mais valiosa do seu prompt. Sem ela, o modelo preenche lacunas com invenção e você perde o principal benefício do RAG.

6. Registre tudo e crie um conjunto de avaliação. Guarde pergunta, chunks recuperados e resposta de cada interação. Com esse log, você identifica padrões de erro e monta um conjunto de testes que roda a cada mudança no pipeline, evitando regressões silenciosas.

7. Atualize a base com processo, não na mão. Documento desatualizado no índice gera resposta errada com cara de certa. Automatize a reindexação quando a fonte muda e defina dono para cada coleção de documentos, porque base abandonada é o jeito mais rápido de matar a confiança no sistema.

Depois de dois anos construindo pipelines de RAG para nós e para clientes, nossa conclusão é direta: essa é a técnica com melhor relação entre esforço e impacto para colocar IA de verdade dentro de uma operação. Ela transforma modelos genéricos em assistentes que conhecem o seu negócio, com fontes verificáveis e custo de manutenção baixo. E o melhor: a barreira de entrada nunca esteve tão baixa. Com Supabase, a API do Claude e um fim de semana de trabalho com Claude Code no terminal, você sai do zero para um protótipo respondendo perguntas sobre os seus próprios documentos. Comece pequeno, com uma base limitada e um caso de uso específico, meça a qualidade do retrieval desde o primeiro dia e expanda a partir do que funcionar.

Leia também:

TL;DR