O que é RAG (Retrieval-Augmented Generation)

Nota: Este documento é uma tradução automática da versão original em inglês.

O que é RAG (Retrieval-Augmented Generation)

Imagine um estudante fazendo uma prova com consulta. Em vez de responder a cada questão apenas de memória, o estudante folheia um livro didático, encontra as páginas mais relevantes, lê-as e então escreve uma resposta que combina conhecimento memorizado com fatos recém-consultados. Retrieval-Augmented Generation (RAG) funciona da mesma forma para um grande modelo de linguagem. O modelo não depende apenas do que memorizou durante o treinamento — ele primeiro pesquisa uma base de conhecimento externa, recupera os documentos mais relevantes e os usa como contexto adicional ao gerar sua resposta.

Essa técnica importa porque mesmo os LLMs mais poderosos têm uma data de corte de conhecimento, podem "alucinar" (produzir afirmações plausíveis, mas incorretas) e podem carecer de conhecimento especializado de domínio. RAG aborda todas as três fraquezas de uma vez, dando ao modelo acesso a fontes atualizadas, específicas de domínio e verificáveis toda vez que responde a uma pergunta.

Em resumo: RAG é um padrão de arquitetura que combina um sistema de recuperação com um LLM. Não é um tipo de modelo separado — é uma forma de trabalhar com conhecimento e contexto externos.

Como funciona

Um pipeline RAG segue uma sequência clara de cinco etapas. Compreender cada etapa ajuda você a avaliar se um projeto que alega RAG tem uma camada de recuperação genuinamente funcional ou apenas envolve uma chamada padrão de LLM.

Etapa 1 — Consulta do usuário

O processo começa quando um usuário envia uma pergunta, comando ou prompt. Essa consulta é o ponto de partida para tudo o que se segue. Por exemplo, um usuário pode perguntar: "Quais foram as principais propostas de governança no Ethereum no último mês?" O sistema não tenta responder apenas a partir da memória do LLM — em vez disso, trata a consulta como uma instrução de pesquisa.

Etapa 2 — Embedding da consulta

A consulta de texto bruto é convertida em uma representação numérica chamada embedding — um vetor de números que captura o significado semântico da consulta. Esta etapa usa um modelo de embedding especializado (como o text-embedding-ada-002 da OpenAI ou uma alternativa de código aberto como E5 ou BGE). O vetor resultante permite que o sistema realize busca semântica — encontrar documentos por significado em vez de correspondência exata de palavras-chave.

Etapa 3 — Recuperação da base de conhecimento

O embedding da consulta é comparado com um banco de dados vetorial (também chamado de vector store) que armazena embeddings pré-computados de documentos, trechos ou blocos de dados. O banco de dados retorna os top-k itens semanticamente mais semelhantes. Os bancos de dados vetoriais comuns incluem Pinecone, Weaviate, Qdrant, Milvus e Chroma.

A qualidade da recuperação depende de vários fatores:

Estratégia de chunking — como os documentos originais foram divididos em pedaços menores. Chunks grandes demais diluem a relevância; chunks pequenos demais perdem o contexto. Encontrar o tamanho certo de chunk é uma das decisões de engenharia mais impactantes em um pipeline RAG.
Modelo de embedding — quão precisamente o significado é capturado em vetores. Um modelo de embedding fraco leva a uma recuperação fraca, independentemente do banco de dados.
Ranqueamento de relevância — se a busca retorna resultados verdadeiramente relevantes ou apenas superficialmente semelhantes. Alguns sistemas adicionam uma etapa de re-ranking que usa um cross-encoder para repontuar os resultados iniciais.

Etapa 4 — Injeção de contexto

Os documentos recuperados são combinados com a consulta original do usuário em um único prompt (às vezes chamado de "prompt aumentado") que é enviado ao LLM. O prompt normalmente instrui o modelo a responder à pergunta usando o contexto fornecido e a indicar quando o contexto não contém informação suficiente.

Etapa 5 — Geração e saída do LLM

O LLM lê o prompt aumentado e gera uma resposta fundamentada tanto em seu conhecimento pré-treinado quanto na evidência recuperada. Um sistema RAG bem projetado também pode incluir uma camada de citação que vincula partes da resposta a documentos-fonte específicos, dando ao usuário uma forma de verificar as afirmações.

Estágio	Entrada	Saída	Componente-chave
Consulta	Texto do usuário	Consulta bruta	Interface do usuário
Embedding	Consulta bruta	Vetor da consulta	Modelo de embedding
Recuperação	Vetor da consulta	Documentos relevantes	Banco de dados vetorial
Injeção de contexto	Consulta + documentos	Prompt aumentado	Template de prompt
Geração	Prompt aumentado	Resposta final	LLM

Por que o RAG importa

RAG aborda três limitações bem conhecidas dos LLMs isolados:

Alucinações. Os LLMs podem produzir respostas confiantes, mas incorretas. RAG reduz isso fundamentando as respostas em documentos reais. Quando o modelo pode referenciar um trecho específico, o risco de fabricação cai significativamente.
Conhecimento desatualizado. Um modelo pré-treinado tem uma data de corte de conhecimento. RAG permite o acesso a dados frescos e continuamente atualizados — um banco de dados externo pode ser atualizado diariamente ou até em tempo real.
Especificidade de domínio. Fazer fine-tuning de um LLM para um domínio restrito é caro e demorado. RAG permite que um modelo de uso geral trabalhe com bases de conhecimento especializadas sem retreinamento, tornando mais rápido e barato implantar aplicações específicas de domínio.

RAG vs fine-tuning

Tanto RAG quanto fine-tuning visam melhorar o desempenho de um LLM em tarefas específicas, mas funcionam de maneiras fundamentalmente diferentes.

Aspecto	RAG	Fine-tuning
Quando o conhecimento é adicionado	No tempo de inferência (cada consulta)	No tempo de treinamento (uma vez, depois estático)
Custo para atualizar	Baixo — atualizar a base de conhecimento	Alto — retreinar ou refazer o fine-tuning do modelo
Frescor do conhecimento	Pode ser quase em tempo real	Congelado no corte de treinamento
Requer infraestrutura de treinamento	Não	Sim (GPUs, datasets, pipeline de treinamento)
Mais adequado para	Recuperação factual, Q&A de documentação	Estilo, tom, formato, otimização de tarefa restrita
Auditabilidade	Alta — as fontes recuperadas podem ser registradas em log	Baixa — o conhecimento está embutido nos pesos

Na prática, muitos sistemas de produção combinam ambos: um modelo com fine-tuning fornece o tom e o comportamento de tarefa certos, enquanto o RAG fornece fundamentação factual atualizada.

Padrões avançados de RAG

O pipeline básico de cinco etapas descrito acima é às vezes chamado de naive RAG. À medida que a técnica amadureceu, os engenheiros desenvolveram variantes mais sofisticadas:

RAG multietapa (iterativo). Em vez de recuperar uma vez, o sistema recupera, gera uma resposta intermediária, identifica lacunas de conhecimento, recupera novamente com uma consulta refinada e repete até que a resposta esteja suficientemente completa. Essa abordagem lida com perguntas complexas que não podem ser respondidas a partir de uma única passagem de recuperação.
RAG agêntico. A etapa de recuperação é envolvida dentro de uma estrutura de agente de IA. O agente decide quando recuperar, qual base de conhecimento consultar, se deve reformular a consulta e quando tem contexto suficiente para gerar uma resposta final. Esse padrão borra a linha entre RAG e agentes autônomos.
Busca híbrida. Combinar busca semântica baseada em vetores com busca tradicional por palavras-chave (BM25) na mesma etapa de recuperação. A busca híbrida captura correspondências baseadas tanto em significado quanto em termos, melhorando o recall para consultas que contêm termos técnicos específicos ou nomes próprios.
Graph RAG. Em vez de blocos de documentos planos, a base de conhecimento é estruturada como um grafo de conhecimento — entidades e relações. A recuperação segue as arestas do grafo em vez de (ou além de) a similaridade vetorial, permitindo raciocínio multi-hop sobre dados estruturados. Esses padrões importam para a avaliação: um projeto que descreve um pipeline graph-RAG com recuperação iterativa está fazendo uma alegação mais específica (e mais difícil de falsificar) do que um que simplesmente diz "usamos RAG".

Exemplos reais de RAG

RAG não é um conceito teórico — ele alimenta alguns dos produtos de IA mais amplamente usados hoje.

Bing Chat (Microsoft Copilot). Quando você faz uma pergunta ao Bing Chat, ele pesquisa na web, recupera páginas relevantes e as usa como contexto para a resposta do LLM. As citações inline que você vê na resposta são um resultado direto da etapa de recuperação.
Perplexity. O Perplexity é construído em torno de uma arquitetura RAG: cada consulta do usuário dispara uma busca na web, os resultados são alimentados a um LLM, e a resposta inclui referências de fonte numeradas. O usuário pode clicar para verificar cada afirmação.
Assistentes de conhecimento corporativos. As empresas usam sistemas RAG internos para permitir que os funcionários consultem políticas de RH, documentação de engenharia ou contratos jurídicos usando linguagem natural. A camada de recuperação pesquisa o repositório de documentos interno da empresa em vez da web aberta. Esses exemplos demonstram que RAG é tecnologia consolidada. Quando um projeto de crypto AI diz "usamos RAG", a questão não é se RAG é tecnologia real, mas se a implementação específica do projeto é sólida: quais dados são recuperados, como são indexados e se a qualidade da recuperação foi medida.

Por que o RAG aparece em projetos de crypto AI

Muitos projetos de crypto AI usam RAG ou alegam usá-lo em suas arquiteturas. Os casos de uso comuns incluem:

Assistentes de documentação — recuperar documentos de protocolo, whitepapers ou propostas de governança para responder a perguntas dos usuários sobre as regras ou parâmetros de um protocolo.
Ferramentas de inteligência de cripto — extrair dados de mercado em tempo real, eventos on-chain ou artigos de notícias para gerar resumos de análise ou alertas.
Bases de conhecimento para agentes — construir repositórios estruturados que os agentes de IA podem consultar antes de agir, garantindo que as decisões sejam informadas pelos dados mais recentes.
Fundamentação em dados on-chain — conectar a camada de recuperação a indexadores de blockchain para que o LLM possa responder a perguntas sobre saldos de carteiras, históricos de transações ou estados de smart contracts com informação atual em vez de snapshots do tempo de treinamento.

Os valores típicos de AI component nos cartões de projeto do DecAIHub que envolvem padrões RAG incluem: "3D AI agents (RAG/memory/LLM catalog)", "AI summaries + crypto intelligence terminal" e "AgentData (real-time data streams for AI agents)".

RAG não é um modelo

Um equívoco comum é tratar RAG como um tipo de modelo de IA. Não é. RAG é um padrão de arquitetura — uma forma de combinar um sistema de recuperação com um LLM. O modelo dentro de um pipeline RAG pode ser GPT, DeepSeek, Mistral ou qualquer outro LLM. O componente de recuperação pode ser um banco de dados vetorial, uma API de busca ou um grafo de conhecimento estruturado.

Dizer "usamos RAG" diz a você como o sistema está organizado. Não diz qual modelo é usado, se é proprietário ou quão boa é a qualidade da recuperação. Dois projetos podem ambos alegar RAG enquanto têm níveis de sofisticação muito diferentes — um com uma base de conhecimento cuidadosamente curada e embeddings personalizados, outro com um protótipo montado às pressas que raramente retorna documentos relevantes.

O que o RAG não comprova

Usar RAG não comprova que o LLM subjacente é proprietário ou tem fine-tuning. O projeto pode estar chamando uma API de terceiros.
Construir um pipeline RAG não comprova que a qualidade da recuperação é alta. A qualidade depende da base de conhecimento, da estratégia de chunking, do modelo de embedding e da relevância da busca.
Ter uma arquitetura RAG não comprova que as respostas são precisas. Uma recuperação ruim pode alimentar contexto irrelevante, e o LLM ainda pode alucinar.
Mencionar RAG em uma landing page não comprova que o sistema realmente realiza recuperação. Sem evidência Tier-1 — código, diagramas de arquitetura, logs de demonstração — a alegação permanece não verificada. Ao avaliar um projeto de crypto AI que alega RAG, procure por especificidades: qual base de conhecimento está sendo pesquisada, qual modelo de embedding é usado, como a relevância é medida e se quaisquer métricas de qualidade são publicadas.

Onde aparece nos cartões de projeto do DecAIHub

RAG é normalmente referenciado no campo AI component — diretamente ou através de descrições que implicam um pipeline de recuperação mais geração. A flag AI_1 verifica se o AI component é descrito com especificidade suficiente. Simplesmente escrever "RAG" não é suficiente; o cartão deve explicar o que está sendo recuperado, de onde e para qual propósito.

Não confundir com

LLM — o motor de geração dentro de um pipeline RAG. RAG adiciona a recuperação por cima.
Treinamento — RAG é um padrão de tempo de inferência. Ele não retreina o modelo; ele aumenta o prompt com contexto recuperado.
Agente de IA — um agente pode usar RAG como uma de suas ferramentas, mas RAG sozinho não torna um sistema um agente.
Fine-tuning — o fine-tuning ajusta os pesos do modelo durante uma fase de treinamento. RAG injeta conhecimento externo no tempo de inferência sem modificar o modelo.
Camada de recuperação / conhecimento — o componente de recuperação é uma metade do RAG. RAG adiciona a etapa de geração por cima da recuperação pura.

Perguntas frequentes

Qual é a diferença entre RAG e fine-tuning?

O fine-tuning altera permanentemente os pesos do modelo treinando-o sobre um dataset especializado. O novo conhecimento se torna parte do próprio modelo. O RAG deixa o modelo intocado e, em vez disso, fornece documentos relevantes no momento da consulta. O fine-tuning é melhor para ensinar a um modelo um novo estilo ou formato de tarefa; RAG é melhor para manter as respostas fundamentadas em fatos frescos e verificáveis. Muitos sistemas de produção usam ambos — o modelo com fine-tuning lida com tom e formato, enquanto o RAG fornece fundamentação factual atualizada.

RAG torna os LLMs mais precisos?

RAG pode reduzir significativamente as alucinações fundamentando a saída do modelo em evidência recuperada. No entanto, a precisão depende da qualidade da recuperação. Se o sistema de recuperação retorna documentos irrelevantes ou desatualizados, o LLM pode produzir respostas confiantemente erradas — agora apoiadas pela evidência errada. RAG eleva o teto para a precisão, mas não a garante. Medir a precisão (precision) e o recall da recuperação é essencial para qualquer implantação séria de RAG.

O que é um banco de dados vetorial?

Um banco de dados vetorial é um armazenamento de dados especializado projetado para guardar e pesquisar vetores numéricos de alta dimensão (embeddings). Quando um embedding de consulta é submetido, o banco de dados realiza uma busca por similaridade — normalmente usando algoritmos como HNSW ou IVF — para encontrar os vetores correspondentes mais próximos. Isso permite a busca semântica: encontrar documentos por significado em vez de correspondência exata de palavras-chave. Os bancos de dados vetoriais populares incluem Pinecone, Weaviate, Qdrant, Milvus e Chroma.

Como o RAG é usado em projetos de crypto AI?

Os projetos de crypto AI usam RAG para conectar LLMs com dados específicos de blockchain: documentação de protocolo, propostas de governança, históricos de transações on-chain, feeds de preços em tempo real e código-fonte de smart contracts. A camada de recuperação pesquisa essas fontes especializadas para que o LLM possa responder a perguntas específicas de domínio com dados atuais em vez de depender de conhecimento de treinamento desatualizado. A qualidade de tais sistemas varia amplamente — de bases de conhecimento bem indexadas e curadas a configurações mínimas que recuperam pouco contexto útil.

O RAG pode funcionar com dados on-chain?

Sim. A camada de recuperação em um pipeline RAG pode se conectar a indexadores de blockchain, subgraphs ou APIs de analytics on-chain. Quando um usuário pergunta sobre um saldo de carteira, um histórico de transações ou um estado de smart contract, o sistema de recuperação busca os dados on-chain relevantes, e o LLM gera uma explicação legível por humanos. Os principais desafios são a latência (consultas de blockchain podem ser lentas), a formatação de dados (os dados brutos on-chain devem ser analisados e divididos em chunks para embedding) e o frescor (o índice deve ser atualizado com frequência suficiente para refletir o estado atual da chain).

Ver também

Referências externas

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview