Fluxo de trabalho de RAG de ponta a ponta: como funciona a Geração Aumentada por Recuperação

A Geração Aumentada de Recuperação (RAG) é um padrão de arquitetura de AI que conecta grandes modelos de linguagem a fontes de conhecimento externas no momento da inferência, permitindo que esses modelos gerem respostas precisas e conscientes do contexto que vão além de seus dados de treinamento estáticos. Em vez de depender do conhecimento codificado durante o pré-treinamento, um sistema RAG recupera documentos relevantes de um banco de dados externo em resposta a cada consulta do usuário e injeta esse conteúdo no prompt do LLM antes da geração. O resultado é um sistema de AI generativa que produz respostas precisas e específicas do domínio, baseadas em fontes verificadas — sem exigir o retreinamento completo do modelo sempre que o conhecimento subjacente muda.

Os LLMs frequentemente fornecem respostas desatualizadas devido a limites de conhecimento e não conseguem acessar documentos internos proprietários ou fontes de dados externas em tempo real. O RAG aborda diretamente essa limitação. Mais de 60% das organizações estão desenvolvendo ativamente ferramentas de recuperação baseadas em AI, refletindo uma mudança fundamental de depender exclusivamente da memória do modelo para conectar dinamicamente a AI a bases de conhecimento ativas que contêm documentos internos, documentação de produtos e dados atuais.

Este guia aborda todo o fluxo de trabalho do RAG — desde os componentes de arquitetura e ingestão de dados até a recuperação híbrida, design de prompt, avaliação e implantação — com orientações práticas para equipes que estão criando pipelines de RAG em produção.

Principais componentes de uma arquitetura RAG

Os sistemas RAG contêm quatro componentes principais: uma base de conhecimento que armazena conhecimento externo, um componente de recuperação de informações (o recuperador) que encontra documentos relevantes para cada consulta, uma camada de integração que monta o contexto recuperado em um prompt de LLM e um gerador (o LLM) que produz a resposta final. Cada componente pode ser otimizado de forma independente, e a qualidade geral do pipeline é limitada pelo elo mais fraco — um LLM de alta qualidade não pode compensar um recuperador que exibe consistentemente documentos irrelevantes.

O recuperador e o banco de dados vetorial

O recuperador aceita uma consulta do usuário, converte-a em uma representação comparável e retorna os documentos mais relevantes da base de conhecimento. A qualidade do recuperador é o principal fator determinante da qualidade do resultado do RAG. O banco de dados vetorial armazena representações numéricas de fragmentos de documentos — chamadas de embeddings — permitindo uma busca rápida por similaridade em escala. Ao contrário dos bancos de dados relacionais que fazem a correspondência com valores exatos, os bancos de dados vetoriais encontram documentos cujo significado é semanticamente mais próximo da consulta usando métricas de distância, como a similaridade de cosseno.

O gerador e a camada de orquestração

O gerador é o grande modelo de linguagem que recebe o prompt aumentado — a pergunta original do usuário combinada com o contexto recuperado — e produz a resposta final. A camada de orquestração conecta todos os componentes em um pipeline de RAG coerente, lidando com a montagem do prompt, o histórico de conversas e o tratamento de erros. Frameworks como LangChain e LlamaIndex fornecem primitivas comuns de orquestração, enquanto plataformas como a Databricks oferecem infraestrutura gerenciada para toda a pilha.

Fontes de dados e conhecimento externo

A gama de fontes de dados válidas para um sistema RAG é ampla: dados estruturados em tabelas relacionais, texto não estruturado em arquivos PDF e markdown, documentos internos como runbooks de engenharia e políticas de HR, documentação de produtos e bases de conhecimento externas. Os dados específicos do domínio — conteúdo diretamente relevante para as perguntas que os usuários farão — devem ser ingeridos primeiro e mantidos com o maior cuidado. Os dados internos, incluindo pesquisas proprietárias e documentos internos, geram a vantagem mais defensável em uma implementação de RAG porque representam um conhecimento com o qual nenhum LLM público foi treinado.

A questão prática ao selecionar fontes de dados é a densidade de relevância: qual porcentagem de documentos indexados será realmente recuperada em resposta a consultas reais? Fontes de alta relevância justificam os custos computacionais e financeiros de embedding e indexação; fontes de baixa relevância diluem a qualidade da recuperação ao aumentar o ruído que o recuperador deve filtrar.

Várias fontes de dados podem ser combinadas em um único sistema RAG — por exemplo, combinando um corpus de documentação de produto com um banco de dados de clientes em tempo real — desde que o pipeline de ingestão normalize cada fonte para um formato de texto consistente. As equipes devem documentar a linhagem de dados de cada fonte indexada para que a origem de qualquer documento recuperado possa ser rastreada até sua origem autoritativa, permitindo fluxos de trabalho de auditoria e conformidade em setores regulamentados.

Modelo de embedding e armazenamento vetorial

Selecionando um modelo de embedding

Um modelo de embedding é um modelo de linguagem especializado que converte texto em representações numéricas — vetores de alta dimensão que codificam o significado semântico. Quando um usuário envia uma consulta, o mesmo modelo de embedding converte essa entrada do usuário em um vetor comparável, permitindo a comparação matemática entre a consulta e todos os embeddings de documentos armazenados. O modelo de embedding usado durante a ingestão deve ser idêntico ao usado no momento da consulta.

A seleção do modelo envolve compensações entre qualidade de representação, dimensionalidade do vetor, latência de inferência e custos financeiros. Modelos de uso geral como bge-large-en produzem vetores de 1.024 dimensões que apresentam bom desempenho em diversos domínios. Modelos de embedding específicos de domínio com ajuste fino em textos técnicos frequentemente superam os modelos gerais em tarefas de recuperação específicas. Os modelos de embedding transformam o texto bruto nas representações numéricas que tornam possível a busca por similaridade vetorial.

Os modelos de embedding também podem ser avaliados quanto à sua capacidade de lidar com consultas formuladas de maneira diferente dos documentos que devem recuperar — uma propriedade chamada de robustez multilíngue ou de paráfrase. Em ambientes corporativos onde os usuários formulam perguntas de forma conversacional enquanto a documentação é escrita de forma formal, essa ponte semântica é fundamental. Testar o modelo de embedding em uma amostra representativa de consultas reais de usuários antes de se comprometer com uma execução de indexação em produção pode evitar o re-embedding dispendioso de todo o corpus posteriormente.

Estratégia de fragmentação e indexação

Documentos grandes devem ser divididos em fragmentos menores antes do embedding porque a janela de contexto do modelo de embedding é finita e porque fragmentos menores resultam em uma recuperação mais precisa. O tamanho do fragmento afeta diretamente a qualidade do resultado: fragmentos muito pequenos perdem o contexto circundante, enquanto fragmentos muito grandes diluem a passagem específica mais relevante para a pergunta do usuário. As estratégias comuns incluem a divisão de tamanho fixo por contagem de tokens e a divisão por limite de frase com bordas sobrepostas para reduzir o risco de o contexto principal cair em um limite.

Depois de gerados os embeddings, os vetores são armazenados e indexados no armazenamento vetorial. Um índice vetorial que usa algoritmos como HNSW organiza os embeddings para permitir a busca de vizinhos mais próximos aproximados em escala, reduzindo a recuperação de uma varredura linear de todos os embeddings para uma busca de submilisegundos.

Recuperação de informações e busca híbrida

A busca semântica — a espinha dorsal da maioria dos sistemas RAG — encontra documentos cujo significado é mais próximo da consulta do usuário, lidando com paráfrases e sinônimos de forma natural. A Databricks AI Search implementa a busca vetorial semântica com sincronização automática a partir de tabelas Delta para que a base de conhecimento reflita novos dados sem a necessidade de reindexação manual.

A busca semântica pura tem uma fraqueza conhecida com consultas de correspondência exata: códigos de erro específicos, números de versão ou entidades nomeadas. A busca híbrida aborda isso combinando a busca vetorial semântica com a busca por palavra-chave BM25 — um modelo probabilístico de frequência de termos que se destaca na correspondência de termos exatos e raros. Executar ambos os caminhos de busca em paralelo e mesclar os resultados usando a fusão de classificação recíproca melhora a eficiência da recuperação em uma distribuição de consultas mais ampla.

Uma etapa de reclassificação (reranking) pode melhorar ainda mais os resultados ao aplicar um modelo de cruzamento de codificadores (cross-encoder) para pontuar cada documento recuperado em relação à consulta e reordenar os resultados para que os documentos mais relevantes apareçam no topo. Métodos de recuperação como o reranking melhoram significativamente a precisão e são especialmente valiosos quando a janela de contexto do LLM limita a quantidade de documentos que podem ser passados para o gerador.

Os limites de similaridade adicionam um filtro de qualidade final: documentos cuja pontuação de relevância fica abaixo de um limite mínimo devem ser totalmente filtrados, em vez de serem passados para o gerador como contexto de baixa qualidade. Passar um contexto irrelevante é pior do que não passar contexto nenhum — isso consome a janela de contexto e aumenta o risco de o LLM misturar informações corretas e incorretas na resposta gerada. Definir limites conservadores e monitorar a taxa de filtragem ao longo do tempo é uma maneira simples de manter a qualidade da recuperação sem alterações na arquitetura.

Como o RAG funciona: da ingestão à geração

O fluxo de trabalho do RAG segue cinco etapas sequenciais que transformam a pergunta do usuário em uma resposta fundamentada e precisa.

Etapa 1: Ingerir e normalizar dados externos

O pipeline de RAG começa com a ingestão de dados. Os documentos brutos são carregados em um pipeline de ETL que limpa e normaliza o texto — removendo clichês, padronizando espaços em branco e extraindo conteúdo estruturado de tabelas e códigos. A arquitetura de lakehouse de dados centraliza a ingestão de conteúdos estruturados e não estruturados sob uma governança unificada, tornando-se uma base natural para a base de conhecimento do RAG.

Etapa 2: Fragmentar, gerar embeddings e indexar

Os documentos limpos são divididos em chunks, cada chunk é passado pelo modelo de embedding para gerar um vetor, e os embeddings resultantes são gravados no vector store junto com o texto original e os metadados (título do documento, data, URL de origem). Os metadados permitem a recuperação filtrada — restringindo os resultados a documentos publicados dentro de um intervalo de datas ou acessíveis a uma função de usuário específica. O RAG exige atualizações contínuas para manter a relevância dos dados; os sistemas de produção precisam de pipelines automatizados que detectem documentos de origem atualizados e acionem o re-embedding de forma agendada ou baseada em eventos.

Etapa 3: Recuperar documentos relevantes

Quando um usuário envia uma consulta, o sistema RAG aplica o mesmo modelo de embedding para converter a entrada do usuário em uma representação vetorial e consulta o vector store, executando uma busca por similaridade que retorna os top-k chunks de documentos mais relevantes. O valor de k — quantos chunks recuperar — equilibra a cobertura de recuperação com o consumo da janela de contexto e deve ser ajustado para o LLM de destino.

Etapa 4: Aumentar o prompt do LLM

Os documentos recuperados são reunidos no prompt aumentado. Uma estrutura típica coloca primeiro uma instrução do sistema ("Responda à pergunta do usuário com base apenas no contexto fornecido. Se não conseguir encontrar a resposta no contexto, diga isso."), seguida pelos chunks de texto recuperados e, depois, pela pergunta original do usuário. Colocar os documentos mais relevantes primeiro tende a melhorar o foco, especialmente para modelos propensos ao fenômeno "lost in the middle" (perdido no meio), onde o contexto próximo ao início e ao fim recebe mais atenção do que o conteúdo no centro.

Etapa 5: Gerar a resposta final

O gerador recebe o prompt aumentado e produz a resposta final. O pós-processamento pode anexar citações de fontes, filtrar saídas fora do tópico ou estruturar os resultados em um formato consistente. O LLM gera respostas precisas porque tem acesso ao contexto recuperado, em vez de depender apenas de dados de treinamento estáticos do pré-treinamento.

O gerenciamento do histórico de conversas é uma preocupação importante da camada de geração para aplicações RAG multiturno. Quando o sistema RAG precisa se lembrar de interações anteriores em uma sessão — para que os usuários possam fazer perguntas de acompanhamento que façam referência a respostas anteriores —, o histórico de conversas deve ser incorporado ao prompt aumentado. Isso aumenta o comprimento efetivo do prompt e reduz a janela de contexto disponível para os documentos recém-recuperados. As equipes devem implementar um gerenciamento explícito de orçamento de contexto que aloque tokens entre o histórico, o contexto recuperado e a consulta atual do usuário.

IA generativa, design de prompt de LLM e orquestração

Um modelo de prompt de LLM reutilizável separa as instruções estáticas — função do sistema, restrições comportamentais, formato de saída — do conteúdo dinâmico inserido em tempo de execução: contexto recuperado e consulta do usuário. A instrução para responder "apenas a partir do contexto fornecido" é particularmente importante para sistemas RAG. Sem ela, os modelos de IA generativa complementarão o conteúdo recuperado com dados de treinamento memorizados, produzindo respostas que misturam informações verificadas com conhecimento potencialmente incorreto do modelo.

A injeção de citações — anexar metadados do documento de origem a cada resposta gerada — permite que os revisores humanos verifiquem se as respostas estão fundamentadas em dados reais recuperados. Em implantações corporativas, o suporte a citações e as instruções do sistema que restringem o escopo do tópico, o comprimento da resposta e o comportamento de escalonamento são requisitos de produção para obter respostas precisas.

Fine-tuning, conhecimento de domínio e alternativas

O fine-tuning adapta um modelo pré-treinado a um domínio específico, modificando os pesos do modelo em um conjunto de dados selecionado. Ao contrário do RAG, o fine-tuning altera o comportamento do modelo subjacente — seu vocabulário, tom e conhecimento implícito do domínio —, em vez de injetar contexto no momento da inferência. O fine-tuning é apropriado quando o modelo base interpreta incorretamente de forma consistente a terminologia específica do domínio ou quando o estilo de resposta exigido não pode ser alcançado apenas por meio de engenharia de prompt.

O fine-tuning não é um substituto eficaz para o RAG quando o objetivo é o acesso a informações atualizadas. O fine-tuning de LLMs em novos dados gera custos computacionais e financeiros significativos e não consegue acompanhar bases de conhecimento em constante mudança. A maioria dos sistemas de produção combina ambos: um modelo com fine-tuning lida com o tom e a terminologia do domínio, enquanto o fluxo de trabalho do RAG fornece acesso ao conhecimento. Depender exclusivamente do fine-tuning para o acesso ao conhecimento é um erro comum e caro.

A engenharia de prompt — projetar instruções do sistema e exemplos few-shot para guiar o comportamento do modelo — continua sendo o ponto de partida básico para qualquer personalização de LLM. Ela não exige infraestrutura adicional e produz resultados imediatamente. Para sistemas RAG, a engenharia de prompt controla como o contexto recuperado é apresentado ao modelo e como o modelo sinaliza incerteza quando os documentos recuperados não respondem totalmente à pergunta do usuário. Todo sistema RAG incorpora engenharia de prompt por definição, já que a montagem do prompt aumentado é, por si só, uma forma de design de prompt.

Avaliação de RAG e testes de recuperação

Medindo a qualidade da recuperação

A avaliação de RAG deve analisar o componente de recuperação de informações e o componente de geração de forma independente. A avaliação de recuperação usa precision@k: dos k documentos recuperados para uma determinada consulta, qual fração é realmente relevante? Um conjunto de dados de avaliação de referência (ground-truth) — consultas emparelhadas com documentos e respostas sabidamente corretos — é o pré-requisito necessário. A criação desse conjunto de dados exige muito esforço, mas é essencial; sem ele, as equipes não conseguem distinguir melhorias reais na avaliação do RAG de variações aleatórias.

Medindo a fidelidade da geração

A avaliação de geração mede se as respostas do modelo são fiéis ao contexto recuperado — se a resposta gerada contém informações incorretas ou inventadas extraídas dos dados de treinamento do modelo, em vez de fontes recuperadas. A avaliação com LLM como juiz (LLM-as-judge), em que um segundo LLM pontua a fidelidade de cada resposta, oferece cobertura escalável em grandes conjuntos de testes. A avaliação de LLM com MLflow integra métricas de recuperação e geração em uma estrutura unificada de rastreamento de experimentos. O RAG reduz as alucinações em modelos de IA generativa, mas não pode eliminar todas as alucinações de IA nas respostas geradas.

Monitoramento, governança e segurança

Os sistemas RAG herdam os requisitos de governança de suas fontes de dados. Os usuários devem apenas recuperar documentos que estão autorizados a acessar. O Unity Catalog oferece governança detalhada em toda a base de conhecimento do RAG — índices de vetores, tabelas Delta e endpoints de modelo governados sob um modelo de controle de acesso comum com rastreamento completo de linhagem de dados. A marcação de proveniência — associar cada resposta gerada aos chunks de documentos específicos que a produziram — permite que os revisores humanos verifiquem as fontes citadas e auditem o conteúdo gerado por IA. Em setores regulamentados, a proveniência costuma ser um requisito de conformidade.

O monitoramento também deve rastrear a desatualização da base de conhecimento — a lacuna entre a última atualização dos documentos de origem e a última atualização do índice RAG. Uma base de conhecimento que retorna consistentemente documentos desatualizados é operacionalmente equivalente a um LLM com um limite de treinamento (training cutoff) desatualizado; ambos produzem respostas que eram precisas em algum momento, mas não refletem mais as informações atuais. Alertas automatizados de desatualização que são acionados quando um documento de origem não foi reindexado dentro de um SLA definido evitam a degradação silenciosa da precisão da resposta ao longo do tempo.

Os vector stores devem ser criptografados em repouso, os endpoints de inferência de LLM e embedding devem ser implantados dentro de limites de rede seguros, e os logs de auditoria devem capturar todas as consultas e eventos de recuperação para detectar acessos anômalos.

Os controles de acesso baseados em função na camada de recuperação são particularmente importantes em implantações RAG multi-tenant, onde diferentes usuários ou equipes devem apenas recuperar documentos de seus domínios de dados autorizados. Sem controles de acesso na camada de recuperação, uma consulta do usuário poderia expor documentos confidenciais de uma unidade de negócios não relacionada — uma falha de governança de dados que é invisível na resposta gerada, mas está presente no log de recuperação subjacente. Projetar o controle de acesso na arquitetura RAG desde o início é significativamente mais fácil do que adaptá-lo depois que os dados já foram indexados.

Escalonamento operacional e práticas recomendadas de implantação

A ingestão inicial de uma grande base de conhecimento exige embedding em lote (batch) em escala. Após a carga inicial, a ingestão incremental apenas recria os embeddings dos documentos novos ou atualizados. Os sistemas devem fazer o escalonamento automático (autoscale) da computação de embedding para cargas iniciais e reduzir para atualizações incrementais contínuas. O embedding em lote é significativamente mais barato por documento do que o embedding em tempo real; os sistemas de produção devem usar o processamento em lote para cargas de trabalho de ingestão e reservar o embedding em tempo real para o processamento de consultas de usuários.

A inferência de LLM normalmente domina os custos operacionais do RAG. Passar mais documentos recuperados para o LLM aumenta proporcionalmente o custo de inferência por consulta; as equipes devem definir políticas explícitas sobre a contagem máxima de documentos recuperados e o comprimento do prompt para limitar os custos. Cada componente — inferência de embedding, vector store, serviço de orquestração, endpoint de LLM — deve ser conteinerizado para uma implantação reproduzível com lógica de repetição (retry) e padrões de disjuntor (circuit-breaker) para tolerância a falhas (failover).

O Databricks MLflow oferece rastreamento de experimentos, registro de modelos e ferramentas de avaliação integradas a toda a pilha do RAG, permitindo que as equipes controlem as versões dos modelos de embedding, rastreiem experimentos de recuperação e gerenciem o ciclo de vida do pipeline de RAG em produção.

Perguntas frequentes

Como o fluxo de trabalho do RAG difere do fine-tuning de um LLM?

O fluxo de trabalho de RAG recupera documentos relevantes no momento da inferência e os injeta no prompt do LLM, enquanto o ajuste fino modifica os pesos do modelo ao treiná-lo com novos dados antes da implantação. O RAG fornece acesso dinâmico a informações atualizadas sem a necessidade de retreinar o modelo, tornando-o mais econômico para conhecimentos que mudam com frequência. O ajuste fino é mais adequado para adaptar o estilo de resposta, o vocabulário do domínio ou a especialização em tarefas. A maioria dos sistemas em produção combina ambos: um modelo com ajuste fino para o tom do domínio, combinado com um fluxo de trabalho de RAG para acesso ao conhecimento.

Qual é o modo de falha mais comum em um sistema de RAG?

A baixa qualidade de recuperação é o modo de falha mais comum do RAG. Se o componente de recuperação de informações retornar documentos irrelevantes, o LLM gerará respostas que parecem confiantes, mas não são baseadas em informações corretas — uma falha que é mais difícil de detectar do que alucinações óbvias. As falhas de recuperação decorrem de fragmentação (chunking) inadequada, incompatibilidade entre o espaço semântico do modelo de embedding e a distribuição de consultas, cobertura insuficiente de busca híbrida ou uma base de conhecimento que simplesmente carece das informações solicitadas pelos usuários. Avaliar a precisão da recuperação separadamente da fidelidade da geração é essencial para diagnosticar essa classe de falha.

Como o RAG reduz as alucinações de AI?

O RAG reduz as alucinações em modelos de AI generativa ao fornecer ao LLM um contexto específico e verificado para cada consulta, em vez de exigir que o modelo responda de memória. Quando o prompt instrui explicitamente o modelo a responder apenas com base no contexto recuperado, o modelo tem menos liberdade para inventar informações. A redução é proporcional à qualidade da recuperação — quanto mais relevantes e completos forem os documentos recuperados, menos o modelo precisará inferir. O RAG não pode eliminar todas as alucinações de AI, pois os modelos ocasionalmente interpretam mal o contexto recuperado, mas reduz substancialmente sua frequência em comparação com a geração sem recuperação.

Quais fontes de dados externas funcionam melhor com o RAG?

Fontes de alta densidade e específicas de domínio produzem os melhores resultados de recuperação: documentação de produtos, bases de conhecimento técnico, documentos de políticas da empresa e repositórios internos selecionados. Fontes com formatação consistente e limites de parágrafo claros são fragmentadas e convertidas em embeddings de forma mais confiável do que conteúdos pouco estruturados. Fontes de conhecimento externas de provedores terceiros — relatórios regulatórios, padrões do setor, literatura acadêmica — ampliam a cobertura além do conteúdo proprietário. Os sistemas de RAG dependem da qualidade das fontes de dados externas; documentos de origem imprecisos ou com formatação inconsistente produzem respostas imprecisas, independentemente da qualidade da arquitetura de recuperação.

Quais são os principais componentes de uma arquitetura RAG?

Uma arquitetura RAG contém quatro componentes principais: a base de conhecimento (o armazenamento de dados externos indexados), o recuperador (o componente de recuperação de informações que traz à tona documentos relevantes), a camada de integração (a lógica de orquestração que monta o contexto em um prompt de LLM) e o gerador (o grande modelo de linguagem que produz a resposta final). O banco de dados vetorial é um elemento de infraestrutura crítico da base de conhecimento, armazenando representações numéricas de fragmentos de documentos (chunks) e permitindo uma busca rápida por similaridade semântica. Saiba mais sobre os padrões de arquitetura de geração aumentada por recuperação na página de glossário da Databricks.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original