A arquitetura RAG: indexação e recuperação

Um sistema RAG opera em duas fases fundamentalmente diferentes, executadas em momentos distintos. A fase de indexação offline processa seus documentos uma vez (ou quando eles são alterados) e prepara um índice pesquisável. A fase de recuperação online é executada em tempo real para cada consulta do usuário. Compreender essa separação é essencial para projetar sistemas rápidos no momento da consulta e fáceis de manter ao longo do tempo.

A indexação começa com o carregamento de documentos: a leitura de arquivos brutos provenientes dos seus sistemas de origem. Os documentos podem ser PDFs, arquivos do Word, páginas HTML, arquivos Markdown, linhas de bancos de dados ou qualquer fonte de texto. Cada documento é carregado na memória como texto simples, preservando a estrutura sempre que possível. Bibliotecas como pypdf, python-docx e unstructured cuidam da maior parte da análise específica de cada formato.

Os LLMs têm janelas de contexto finitas, e recuperar documentos inteiros é ineficiente. O texto carregado é dividido em trechos menores, com aproximadamente 200 a 1.000 tokens cada. Uma boa divisão preserva a coerência semântica: um trecho deve expressar uma ideia completa. Uma estratégia comum usa janelas sobrepostas, fazendo com que as frases próximas aos limites dos trechos apareçam em dois trechos e evitando a perda de informações nos pontos de divisão.

Cada trecho de texto é convertido em um embedding vetorial denso que representa numericamente seu significado semântico. O senhor chama um modelo de embeddings — como o text-embedding-3-small da OpenAI — para cada trecho e recebe uma matriz de números de ponto flutuante de alta dimensionalidade. Trechos com significado semelhante produzem vetores próximos nesse espaço de alta dimensionalidade, o que possibilita a pesquisa por similaridade semântica.

Os trechos transformados em embeddings são armazenados em um banco de dados vetorial junto com seus metadados (arquivo de origem, número da página, título da seção). O repositório vetorial cria uma estrutura de índice (normalmente HNSW) que permite uma pesquisa rápida aproximada pelos vizinhos mais próximos. Esse índice é persistido em disco para sobreviver a reinicializações. A indexação normalmente ocorre uma vez durante a configuração e de forma incremental quando novos documentos são adicionados.

Quando um usuário envia uma consulta, começa a fase de recuperação online. A primeira etapa é gerar o embedding da pergunta do usuário usando o mesmo modelo de embeddings empregado durante a indexação. Isso é fundamental: se o senhor indexou com text-embedding-3-small, também deve consultar com text-embedding-3-small. O embedding da consulta é um vetor que codifica o significado semântico daquilo que o usuário está perguntando.

O embedding da consulta é enviado ao repositório vetorial, que realiza uma pesquisa aproximada pelos vizinhos mais próximos (ANN) para encontrar os K trechos cujos embeddings são mais semelhantes ao vetor da consulta. Essa pesquisa é extremamente rápida (normalmente leva menos de 10 ms), pois os índices HNSW trocam uma pequena parcela da revocação por ganhos enormes de velocidade em relação à pesquisa por força bruta. O senhor recupera os K principais trechos — normalmente, de K=5 a K=20.

A principal conclusão é que a indexação e a recuperação são projetadas para funcionar em conjunto. O modelo de embeddings deve ser idêntico nas duas fases, pois o espaço matemático onde os vetores ficam é específico do modelo. Se o senhor trocar de modelo de embeddings, deverá reindexar todos os documentos. O repositório vetorial é a ponte: ele aceita vetores durante a indexação e retorna vetores durante a recuperação, desacoplando as duas fases no tempo e mantendo-as alinhadas no espaço vetorial.

A pesquisa vetorial encontra trechos semanticamente semelhantes, mas às vezes o senhor também precisa filtrar por metadados. Por exemplo: recuperar apenas trechos de documentos enviados em 2025 ou apenas da pasta do departamento de RH. Os repositórios vetoriais oferecem pré-filtragem ou pós-filtragem nos campos de metadados. A pré-filtragem (compatível com Pinecone e Qdrant) aplica o filtro antes da pesquisa ANN, sendo mais rápida e precisa do que a pós-filtragem dos resultados principais, até K.

Em produção, seu conjunto de documentos muda ao longo do tempo. Uma arquitetura de indexação eficaz oferece atualizações incrementais: quando um documento é editado, exclua seus vetores existentes pelo ID e faça upsert dos novos. Quando documentos forem excluídos, remova seus vetores. Atribua a cada trecho um ID determinístico baseado no caminho do documento de origem e na posição do trecho, para que o senhor possa sempre encontrar e atualizar os vetores corretos sem reindexar tudo.

A arquitetura completa do RAG é assim: Offline: Documentos → Carregador → Divisor em Trechos → Modelo de Embeddings → Repositório Vetorial. Online: Consulta do Usuário → Modelo de Embeddings → Repositório Vetorial (pesquisa ANN) → Principais Trechos, até K → Montagem do Prompt → LLM → Resposta. O pipeline offline é executado uma vez a cada atualização de documento. O pipeline online é executado em milissegundos para cada consulta do usuário, e o LLM vê apenas o contexto relevante, não todo o conjunto de documentos.

Teste sua compreensão dos conceitos de Engenharia de IA desta lição.

Nesta lição, o senhor aprendeu: a fase de indexação offline, composta pelas etapas de carregar, dividir em trechos, gerar embeddings e armazenar, executadas uma vez por documento; a fase de recuperação online, que gera o embedding da consulta, realiza uma pesquisa ANN e retorna os principais trechos, até K, em milissegundos; e estratégias de indexação incremental para manter o repositório vetorial atualizado à medida que os documentos mudam. A seguir, exploraremos como criar prompts aumentados eficazes que usem bem o contexto recuperado.