RAG é uma arquitetura de IA que combina um mecanismo de busca de documentos com um modelo de linguagem (LLM) para gerar respostas apoiadas em fontes externas, em vez de depender só do que o modelo memorizou no treinamento. A sigla vem de retrieval-augmented generation (geração aumentada por recuperação). Neste artigo, você vê como um pipeline de RAG funciona por dentro, quando ele ganha do fine-tuning, o que ele resolve (e o que não resolve) de alucinação, e como o tema aterrissa no Brasil, com dados atualizados até 27 de agosto de 2026.
De onde vem o RAG: o artigo da Meta AI que criou o termo em 2020
O RAG nasceu como pesquisa, com nome e data. O termo apareceu no artigo do Facebook AI Research, hoje Meta AI, apresentado na NeurIPS 2020 com colegas da University College London e da New York University, para atacar tarefas “intensivas em conhecimento”: aquelas em que um LLM puro falha porque tudo o que ele sabe está congelado nos pesos, e atualizar pesos custa caro.
A arquitetura original separa três peças:
- Memória paramétrica: o que o modelo aprendeu no treinamento e carrega nos próprios pesos.
- Memória não paramétrica: um corpus externo de documentos (no experimento original, a Wikipédia) que pode ser trocado sem treinar o modelo de novo.
- Late fusion: segundo a explicação da própria Meta AI sobre o método, a fusão tardia entre o que foi buscado e o que vai ser gerado.
Na prática, funciona assim: ao receber uma pergunta, o sistema busca documentos de apoio no corpus, concatena esses trechos com a entrada original e entrega o conjunto inteiro ao gerador, enquanto os sinais de erro voltam para aprimorar o próprio mecanismo de busca. Esse desacoplamento explica por que o RAG se espalhou: você atualiza o que o sistema sabe trocando a base documental, sem encostar no modelo.
Como funciona um pipeline de RAG, do chunking à resposta final
Um pipeline de RAG padrão tem cinco etapas. São os componentes descritos no survey de 2025 sobre arquiteturas de Agentic RAG, que mapeou a anatomia típica desses sistemas:
- Chunking: os documentos são divididos em chunks, blocos de aproximadamente 1.000 tokens, de preferência respeitando limites de frase para preservar a coerência semântica.
- Indexação: cada chunk vira um vetor gerado por um modelo de embeddings e entra na base de dados que o sistema vai consultar.
- Retrieval: na hora da pergunta, a busca densa retorna os chunks semanticamente mais próximos da query.
- Reranking (opcional): um modelo reordena os candidatos e descarta os menos úteis.
- Geração: o LLM recebe a pergunta junto com os trechos selecionados e escreve a resposta final.
O que ninguém descobre até montar o primeiro protótipo: o gargalo quase nunca é o LLM. É o chunking. Regras fixas de corte rompem o contexto dos documentos, e o mesmo survey aponta essa etapa como um dos limites reais desses sistemas. Um trecho separado do parágrafo em que vivia aparece na busca sem contexto e derruba a resposta inteira. Em projetos de desenvolvimento de RAG, é aí que a engenharia gasta mais tempo.
Existem também variantes que checam a qualidade do que foi buscado antes de gerar, caso do Corrective RAG, que adiciona uma etapa de autoavaliação dos documentos recuperados. E há a geração mais nova, o Agentic RAG, em que o próprio modelo decide quando, o quê e como buscar, com base na sua trajetória de raciocínio.
Qual a diferença entre RAG e fine-tuning em um projeto de LLM?
A diferença cabe numa linha. O fine-tuning (ajuste fino) muda o que o modelo sabe, ajustando os pesos com dados de domínio; o RAG muda o que o modelo consegue acessar na hora da inferência, sem tocar nos pesos. São respostas para problemas distintos, e dá para combinar as duas.
O RAG tende a ganhar quando a informação muda com frequência:
- dados regulatórios e jurisprudência recente;
- preços e condições de mercado;
- documentação institucional que a equipe atualiza toda semana;
- qualquer base em que treinar o modelo de novo a cada mudança sairia caro demais.
O fine-tuning compensa no cenário oposto: conhecimento de domínio estável, de longo prazo, com alto volume de consultas. Ali, o custo de inferência menor de um modelo especializado paga o investimento inicial de treinamento. Também existe o caminho híbrido, em que o componente de busca e o gerador passam juntos por ajuste fino, para que os dois aprendam a trabalhar em par.
Minha leitura, depois de ver a escolha errada em produção: comece por RAG quase sempre. Trocar um índice é reversível em horas; um fine-tuning malfeito exige treinar tudo de novo.
Para que serve RAG? Menos alucinação e respostas sempre atuais
RAG serve para duas coisas. A primeira: reduzir alucinações, dando ao LLM evidência externa em vez de deixá-lo improvisar de memória. A segunda: manter respostas atuais, porque modelos treinados até uma data de corte não incorporam sozinhos nada do que aconteceu depois, e a base de dados que o RAG consulta pode ser atualizada todo dia.
Sobre alucinação, vale precisão. Nem todo erro é igual: há alucinações baseadas em conhecimento, que o RAG ataca diretamente fornecendo o documento certo, e alucinações baseadas em lógica, em que buscar mais texto não resolve o raciocínio quebrado.
RAG reduz alucinação, mas não zera. A busca semântica pode retornar trechos tecnicamente próximos e contextualmente errados, e a resposta final nunca fica melhor do que a cobertura e a qualidade da base indexada. Entra lixo, sai lixo.
Como avaliar um sistema de RAG sem depender de anotação humana
Avaliar um RAG é medir duas coisas em separado: a busca e a geração. Uma resposta ruim pode nascer de um retrieval que trouxe o documento errado ou de um LLM que ignorou o documento certo, e sem separar as medições você conserta o componente errado.
O framework Ragas, proposto em 2023, avalia sistemas de RAG sem anotações humanas de referência e virou um dos padrões mais citados do campo. A avaliação madura se organiza em três tarefas: encontrar os documentos-fonte corretos, gerar texto fundamentado neles e compor a resposta final. Medir só a última esconde os erros das duas primeiras.
RAG no Brasil: adoção nas empresas, guia do governo e limites da LGPD
No Brasil, o RAG chega numa onda de adoção que dá para medir. O uso de IA generativa por empresas brasileiras subiu de 13% em 2024 para 17% em 2025, revertendo a estagnação registrada desde 2021. Nas grandes empresas, a adoção de IA foi de 38% para 50% no mesmo período, e as ferramentas de linguagem natural generativa saltaram de 20% para 30%, a categoria que mais cresceu.
O governo federal já tomou posição. O guia IA Generativa do Ministério da Gestão e da Inovação em Serviços Públicos trata o RAG como uma das apostas para a gestão do conhecimento no setor público e recomenda a técnica até para modelos de código fechado, como forma de incorporar dados institucionais sem expor dados brutos a sistemas externos. A definição do guia cabe numa frase:
“RAG é uma técnica que combina síntese de texto com recuperação de informação”
E, diferentemente do fine-tuning, o guia lembra que a técnica não modifica o modelo em si: apenas o conecta a bases de dados consultáveis na hora de gerar a resposta.
Quando essas bases contêm dados pessoais, entram em cena os princípios de finalidade, necessidade e minimização da Lei 13.709/2018 (LGPD), que limitam o acesso ao estritamente necessário para cada tratamento. A fiscalização tem calendário: no Mapa de Temas Prioritários publicado pela Agência Nacional de Proteção de Dados (ANPD) em dezembro de 2025, “Inteligência Artificial e tecnologias emergentes” é um dos quatro eixos de fiscalização, com ações planejadas até 2027 e foco no uso de dados pessoais em sistemas automatizados.
O risco de governança mais citado é concreto: um RAG mal configurado deixa um colaborador acessar, com uma pergunta simples, informação que extrapola suas permissões, porque a resposta combina várias fontes sem mostrar de onde veio cada trecho. O controle de acesso precisa morar na camada de retrieval, junto do índice. Filtrar só na geração chega tarde.
Como levar um projeto de RAG do protótipo à produção
Comece pela base documental, antes do modelo. Um RAG fica exatamente tão bom quanto o corpus que indexa, o chunking que preserva contexto e as permissões que controlam quem vê o quê. Depois, meça busca e geração em separado antes de trocar qualquer componente, porque o diagnóstico errado custa semanas.
Latência também é requisito de produção. Na AlphaCorp AI, construímos o RustyRAG, nossa stack de retrieval-augmented generation, para responder em menos de 200 ms, porque assistente interno lento vira assistente ignorado. Se a sua equipe está avaliando por onde começar, dá para conversar direto com quem constrói: quem atende o projeto é quem escreve o código. Protótipo de RAG qualquer um monta num fim de semana. Produção é outro esporte.
