GraphRAG / Arquitetura RAG

O abismo entre "chunks semanticamente semelhantes" e "respostas corretas e completas" é onde a maioria das implantações corporativas de RAG falha. O Laboratório de IA de Stanford constatou que 40% das respostas de RAG alucinam mesmo quando os documentos corretos são recuperados. A recuperação funcionou. A fundamentação não.

Por Que o RAG Recupera Documentos, Não Respostas

Isso acontece porque a similaridade vetorial padrão não consegue distinguir entre um trecho tematicamente relevante e um que realmente responde à pergunta. Quando a sua equipe de conformidade pergunta "quais são os requisitos de notificação para uma violação de dados que afeta residentes da UE menores de 16 anos?" e o seu sistema retorna três chunks sobre notificação de violações sob o GDPR sem as disposições específicas sobre a idade, a resposta parece correta, mas é perigosamente incompleta.

Nossa abordagem consiste em construir sistemas de recuperação projetados para fechar essa lacuna. A arquitetura que escolhemos depende dos seus documentos, das suas consultas e da sua tolerância a respostas incorretas. Às vezes, trata-se de recuperação híbrida BM25 + densa com um reranker cross-encoder. Outras vezes, é um pipeline completo de GraphRAG com extração de entidades e sumarização de comunidades. Em certos casos, é um loop de recuperação agêntica que decompõe perguntas complexas, recupera iterativamente e se autocorrige antes da geração. Não recorremos por padrão à opção mais complexa — recorremos àquela que resolve o seu problema de recuperação a um custo que você pode sustentar.

Três Arquiteturas de Recuperação, Escolhidas pelos Seus Padrões de Consulta

Adequamos a arquitetura aos seus padrões de consulta em vez de recorrer à complexidade por padrão. Os três padrões abaixo cobrem a maioria das necessidades de produção.

Recuperação híbrida com reranking

É aqui que a maioria dos sistemas RAG em produção deve começar. O BM25 gerencia a correspondência exata de palavras-chave (códigos de erro, SKUs de produtos, números de citações regulatórias), enquanto embeddings densos capturam a intenção semântica. A fusão recíproca de ranqueamento (RRF, k=60) mescla os dois conjuntos de resultados sem os problemas de normalização de pontuação que afetam abordagens de fusão aprendida.

Um reranker cross-encoder atua no topo: BGE-reranker-v2-m3 em GPU entrega latência de 50–100 ms a custo contínuo zero de API, ou Cohere Rerank para equipes que preferem infraestrutura gerenciada. Benchmarks de produção mostram que esse pipeline de dois estágios supera todos os métodos de estágio único. A recuperação contextual da Anthropic é uma técnica aplicada como camada complementar, reduzindo as falhas de recuperação em 49% (67% com reranking) ao anexar previamente o contexto em nível de documento a cada chunk antes da geração de embeddings.

Recuperação aumentada por grafo (GraphRAG)

Quando suas perguntas exigem a sintetização de informações de múltiplos documentos ou o raciocínio sobre relações entre entidades, a similaridade vetorial isolada não é suficiente. Uma equipe jurídica que pergunta "quais subsidiárias da AcquiringCo possuem ações regulatórias pendentes em jurisdições onde a TargetCo opera?" precisa de resolução de entidades, navegação em relações e raciocínio multi-hop.

Construímos grafos de conhecimento a partir dos seus documentos, utilizando extração baseada em dependências que alcança 94% do desempenho baseado em LLMs a uma fração do custo em tokens (detalhado em nossa pesquisa sobre GraphRAG com imposição de citações). A abordagem GraphRAG da Microsoft (clusterização Leiden + sumarização de comunidades) funciona para consultas de compreensão global em nível de corpus, mas seus custos de indexação são de 4 a 8x os do RAG padrão. Nós a utilizamos de forma seletiva:

• Sumarizações de comunidades para consultas globais.
• Navegação em grafo de propriedades para perguntas de entidade-relacionamento.
• Recuperação vetorial padrão para todo o restante.

Para o armazenamento de suporte do grafo, o FalkorDB gerencia cargas de trabalho RAG com leitura intensa a 6.693 QPS com inicializações a frio sub-milissegundo, enquanto o Neo4j permanece a escolha certa quando você precisa de RBAC maduro, clusterização e agregações complexas.

Recuperação agêntica

O padrão mais capaz em 2026 e o mais caro para implementar com precisão. Um loop de recuperação agêntica decompõe consultas complexas em subconsultas, roteia cada uma para a estratégia de recuperação adequada (vetorial, em grafo ou banco de dados estruturado), avalia se os resultados são suficientes e itera até que os limites de confiança sejam atingidos.

Implementamos isso sobre o LangGraph, onde a abstração de máquina de estados oferece ramificação condicional, nós de interrupção com intervenção humana (human-in-the-loop) e auditabilidade determinística. Camadas de RAG Corretivo adicionam 100–800 ms de latência por consulta, mas capturam erros de recuperação antes que eles cheguem ao LLM. Esse padrão está pronto para produção na Morgan Stanley, PwC e ServiceNow. Não está pronto para equipes sem capacidade dedicada de MLOps para monitorar e ajustar os loops de recuperação.

O Que Acontece Antes do Embedding: Acertando o Chunking

O chunking é onde os sistemas RAG falham silenciosamente. O chunking ingênuo de tamanho fixo produz pontuações de fidelidade de 0,47–0,51. O chunking semântico alcança 0,79–0,82, mas tem o custo de gerar embeddings para cada frase do seu corpus. A estratégia correta depende dos seus documentos:

• Arquivos regulatórios estruturados — o parsing com reconhecimento de layout preserva a hierarquia das seções.
• PDFs de conteúdo misto com tabelas e gráficos — o chunking guiado por visão computacional (tratando cada página como uma imagem para detecção de layout e, em seguida, extraindo as regiões de texto) melhora a precisão de recuperação em 8–15% em comparação com o parsing apenas de texto.
• Documentos narrativos longos — o late chunking processa o documento completo pelo transformer primeiro para que o embedding de cada token reflita o contexto bidirecional, aplicando os limites de chunk somente após a passagem direta (forward pass).

Testamos de três a quatro estratégias de chunking com o seu conjunto real de consultas antes de escolher uma. O ambiente de avaliação (métricas de fidelidade + precisão de contexto do RAGAS, julgamentos de relevância específicos do domínio) é entregue como parte integrante do pipeline, não como uma reflexão tardia. 60% das novas implantações de RAG agora incluem avaliação sistemática desde o primeiro dia, acima de menos de 30% no início de 2025. Integramos a avaliação ao seu CI/CD para que a qualidade da recuperação seja medida em cada deploy, e não descoberta quando os usuários reclamam.

Quanto Custa Operar um Sistema RAG Corporativo?

Uma empresa de manufatura gastou US$ 400.000 na implantação de um sistema RAG, para depois descobrir que as operações contínuas custavam US$ 18.000/mês — mais que o dobro de sua projeção. O modelo de custos que eles negligenciaram: o reranking. APIs de embedding custam US$ 20–120 por bilhão de tokens. A hospedagem de bancos de dados vetoriais para 10M de vetores custa de 1,5 a 3 vezes mais com serviços gerenciados (Pinecone, Weaviate Cloud) em comparação com soluções auto-hospedadas (Qdrant, pgvector). Mas o reranking em volumes de consulta de produção é onde os orçamentos extrapolam: o Cohere Rerank custa US$ 2 por 1.000 consultas, enquanto o BGE-reranker-v2-m3 auto-hospedado em uma única GPU iguala essa latência a custo contínuo zero por consulta — embora você pague pela instância de GPU.

O GraphRAG adiciona outra camada de custo. A construção do grafo de conhecimento consome de 4 a 8x mais tokens do que o texto de origem para extração de entidades e sumarização de comunidades. A manutenção consome 40–60% do orçamento de engenharia do primeiro ano porque resolução de entidades, deduplicação e atualizações de ontologia são trabalhos contínuos, e não uma configuração única. A extração baseada em dependências (NLP clássico em vez de chamadas de LLM) reduz os custos de construção em cerca de 90% mantendo 94% da qualidade de extração. Dimensionamos cada projeto com projeções explícitas de custos operacionais mensais cobrindo embedding, armazenamento, recuperação, reranking e manutenção do grafo.

Quando o GraphRAG Vale a Pena (e Quando Não Vale)

Você precisa de recuperação aumentada por grafo quando suas consultas exigem raciocínio multi-hop entre entidades e relacionamentos:

• Due diligence de M&A abrangendo centenas de registros de subsidiárias.
• Síntese de evidências clínicas entre bases de dados de interação medicamentosa.
• Análise de risco de cadeia de suprimentos conectando redes de fornecedores a ações regulatórias.

O GraphRAG atinge sua mais alta precisão de busca em consultas corporativas complexas em múltiplas camadas em benchmarks (veja uma demonstração prática de recuperação jurídica com verificação de citações). Você não precisa dele quando suas consultas são buscas em documento único, respostas no formato FAQ ou pesquisas orientadas por palavras-chave — a recuperação híbrida BM25 + densa com um reranker resolve isso a uma fração do custo e da complexidade. Se o seu corpus tiver menos de 5 milhões de vetores e suas perguntas não cruzarem fronteiras entre documentos, o pgvector com indexação HNSW é plenamente suficiente. Avaliamos isso antes de recomendar a arquitetura e lhe diremos quando a opção mais simples for a escolha correta.

A questão "nós realmente precisamos de RAG?" também é importante. Com janelas de contexto atingindo mais de 1M de tokens (Gemini 3 Pro com 10M), algumas equipes consideram inserir corpora inteiros no prompt. O problema: uma única consulta de 1M de tokens custa US$ 2–10, o que é insustentável no volume de consultas de uma empresa. A qualidade do contexto também se degrada após certos limites, mesmo dentro das capacidades anunciadas. O RAG continua sendo a arquitetura certa para qualquer sistema que processe consultas repetidas sobre conjuntos de documentos grandes e em constante mudança.

Qual É a Superfície de Ataque de um Pipeline RAG?

A pesquisa PoisonedRAG (USENIX Security 2025) demonstrou que cinco documentos cuidadosamente manipulados e injetados em um corpus de um milhão de documentos podem adulterar respostas de IA com mais de 90% de sucesso. Seu pipeline de recuperação é uma via de ingestão para conteúdo adversarial. A OWASP agora reconhece formalmente vulnerabilidades em vetores e embeddings (LLM08:2025) e injeção de prompt por meio de documentos recuperados (LLM01:2025) como principais riscos de segurança em LLMs.

Incorporamos rastreamento de proveniência de documentos, detecção de anomalias no nível de embeddings e camadas de sanitização de entrada ao pipeline de recuperação. Cada trecho recuperado traz metadados de origem e pontuação de confiança. A camada de geração é restrita a citar trechos específicos, e afirmações que não puderem ser fundamentadas no conteúdo recuperado são sinalizadas em vez de repassadas diretamente. Isso não é opcional para nenhum sistema RAG implantado em ambientes regulados, conforme detalhado em nossa pesquisa sobre a proteção de LLMs corporativos privados.

O Que Entregamos

Cada projeto produz:

• Uma arquitetura de recuperação escolhida para seus padrões de consulta e tipos de documentos específicos.
• Uma estratégia de chunking e embedding avaliada por benchmark com suas consultas reais.
• Um ambiente de avaliação de nível de produção com métricas RAGAS e casos de teste específicos do domínio.
• Projeções de custo explícitas cobrindo embedding, armazenamento, recuperação, reranking e qualquer manutenção de grafos.
• Hardening de segurança contra ataques baseados em recuperação.
• Uma stack de monitoramento que detecta a degradação da qualidade da recuperação antes que os usuários percebam.

Também lhe informamos quando a sua configuração atual for adequada e o investimento em uma recuperação mais complexa não trouxer retorno financeiro.