RAG ou Graph? A pergunta certa é: qual problema você está tentando resolver?

RAG resolve recuperação de conteúdo semanticamente relevante em corpora não estruturados. Um grafo de conhecimento resolve navegação sobre relações explícitas entre entidades. São primitivas diferentes, com garantias diferentes, e a escolha entre elas não deveria ser feita no nível da tecnologia. Deveria ser feita no nível da consulta que o sistema precisa responder.

Vou tratar isso com o rigor que a decisão merece: pipeline completo, garantias e limitações de cada abordagem, quando combiná-las em GraphRAG, e o que muda quando o sistema sai do protótipo e vai para produção com múltiplos tenants, SLAs de latência e exigências de auditoria.

RAG resolve um problema específico: relevância semântica sobre texto

RAG existe para responder uma classe de pergunta: "o que o meu conteúdo diz sobre isso". O pipeline real, não a versão simplificada de "gerar embedding e consultar banco vetorial", tem mais estágios do que a maioria das implementações iniciais assume:

Sources → Ingestion → Parsing → Normalization → Chunking →
Metadata Enrichment → Embedding → Indexing → Retrieval →
Filtering → Reranking → Context Assembly → Generation → Citations → Evaluation

Cada estágio carrega decisões que determinam se o sistema funciona em produção ou só na demo:

Chunking. Chunk fixo por tamanho de token é a abordagem mais simples e a que mais degrada relevância em documentos estruturados (contratos, políticas, regulamentações). Vale separar três estratégias que costumam ser tratadas como sinônimo e não são. Structure-aware chunking respeita fronteiras estruturais do documento, título, seção, parágrafo, e evita cortar uma cláusula no meio. Semantic chunking usa similaridade de significado entre trechos consecutivos para decidir onde uma ideia termina e outra começa, independentemente da estrutura visual do documento. Chunking hierárquico preserva a relação cláusula-seção-documento como uma árvore navegável, o que costuma superar chunking plano em conteúdo jurídico e regulatório. Chunk overlap bem calibrado, em qualquer uma das três estratégias, reduz fragmentação de contexto nas bordas.

Retrieval. Vector search puro (dense retrieval) tem um ponto cego conhecido: falha em queries com termos exatos, siglas, números de contrato ou nomenclatura específica de domínio, porque embeddings capturam similaridade semântica, não correspondência lexical exata. Por isso, hybrid search combinando dense retrieval com BM25 (sparse retrieval) tornou-se uma das principais estratégias em RAG corporativo, e costuma ser uma baseline mais robusta do que dense retrieval isolado quando o corpus tem identificadores, códigos e nomenclatura de domínio.

Reranking. Retrieval inicial otimiza para recall, não para precisão. Um reranker (cross-encoder) aplicado sobre o top-k recuperado corrige boa parte dos falsos positivos que o retrieval inicial traz por proximidade vetorial sem relevância real.

Vector database. Antes de introduzir um banco vetorial dedicado (Qdrant, Pinecone, Weaviate, Milvus), avalio se PostgreSQL com pgvector atende volume, QPS e requisitos de filtro por metadados. Um banco vetorial separado adiciona superfície operacional, mais um sistema para monitorar, fazer backup e manter consistente. Só se justifica quando volume, dimensionalidade ou throughput realmente exigem.

O ponto estrutural é este: RAG recupera conteúdo relevante para uma pergunta. Ele não sabe, e não deveria saber, se dois trechos recuperados representam uma relação de negócio real entre entidades. Proximidade vetorial entre "Cliente A" e "Contrato 93821" não implica que o Cliente A possui o Contrato 93821. Essa é uma inferência estatística sobre texto, não uma afirmação factual sobre dados. Tratar similaridade semântica como se fosse relação de negócio é uma fonte recorrente de alucinação silenciosa em sistemas RAG corporativos.

Graph resolve outro problema: navegação sobre relações explícitas

Quando a pergunta muda de forma, "quais clientes possuem contratos associados ao produto X e foram impactados pelo processo Y", RAG não é o instrumento certo. Essa pergunta não pede um trecho de texto semanticamente parecido. Pede um caminho verificável em um grafo de entidades:

Cliente --possui--> Contrato --utiliza--> Produto --depende_de--> Processo --executado_por--> Sistema

Um grafo de entidades (ou grafo de conhecimento, nome formal do conceito) modela conhecimento como entidades, relacionamentos tipados e atributos, normalmente persistidos em um banco de grafos (Neo4j, Amazon Neptune, TigerGraph) ou, em escala menor, como tabelas relacionais com forte modelagem de foreign keys quando o grafo é raso e a query pattern é previsível. A escolha entre grafo nativo e modelo relacional depende de profundidade de travessia: para consultas de um a dois saltos, um banco relacional bem indexado resolve. Para travessias multi-hop, caminhos variáveis e análise de impacto (blast radius), um banco de grafos nativo com linguagem de consulta como Cypher ou Gremlin evita joins recursivos caros e torna a consulta legível e performática.

O ganho real de um grafo de relacionamentos aparece em perguntas de impacto e dependência:

"Quais clientes podem ser impactados se o Modelo Antifraude V4 ficar indisponível?"

Modelo Antifraude V4 <--utilizado_por-- Sistema <--depende-- Produto <--associado-- Contrato <--possui-- Cliente

Essa é uma travessia reversa sobre um grafo de dependências, o tipo de consulta em que busca vetorial simplesmente não tem primitiva equivalente. Domínios em que essa capacidade costuma justificar o investimento: financeiro (risco, antifraude, produtos regulados), seguros (sinistros e apólices interligadas), telecom (topologia de rede e impacto de outage), saúde (histórico clínico relacional), supply chain (rastreabilidade de fornecedores) e compliance (mapeamento de exposição regulatória).

GraphRAG: quando a pergunta exige conteúdo e relação ao mesmo tempo

A pergunta que expõe a limitação de tratar RAG e Graph como excludentes é esta: "quais clientes são impactados pela mudança regulatória descrita na Resolução X". Ela tem duas partes que pedem mecanismos diferentes. A primeira parte, "o que a resolução diz", é recuperação documental. A segunda, "quais clientes, contratos e produtos estão relacionados a essa regra", é travessia de grafo. Uma arquitetura GraphRAG pode combinar os dois mecanismos para responder perguntas compostas como essa em uma única camada de recuperação:

                         Pergunta do usuário
                                 |
                        Query Understanding
                                 |
                 -----------------------------------
                 |                                 |
         Busca semântica                    Graph Traversal
                 |                                 |
        Conteúdo documental                 Relacionamentos
                 |                                 |
                 -----------------------------------
                                 |
                          Context Builder
                                 |
                                LLM
                                 |
                    Resposta fundamentada + evidências

O ponto que costuma passar despercebido é que GraphRAG não substitui embeddings, ele orquestra dois mecanismos de recuperação com forças complementares. Vector search encontra similaridade semântica em texto não estruturado. Grafo navega relações explícitas e verificáveis. Uma arquitetura corporativa madura tende a compor várias fontes de recuperação sob um roteador de consulta:

Vector Search + Keyword Search (BM25) + SQL + Graph + APIs + Business Rules

com o LLM atuando como camada de entendimento de consulta, planejamento de quais fontes acionar e composição da resposta final, não como fonte de verdade sobre relações de negócio. Deixar o modelo inferir relações entre entidades a partir de proximidade textual, em vez de consultar o grafo, é abrir a porta para exatamente o tipo de alucinação que a arquitetura deveria prevenir.

Um cuidado com o termo GraphRAG

O diagrama acima descreve o padrão arquitetural mais comum de graph-augmented RAG. Mas o termo GraphRAG também nomeia uma implementação de referência específica, publicada pela Microsoft, que vai além dessa composição.

Nela, um pipeline de indexação extrai entidades, relações e claims do corpus inteiro usando LLM, organiza essas entidades em uma hierarquia de comunidades e gera resumos por comunidade. A camada de consulta oferece modos distintos: Global Search, para perguntas holísticas sobre o dataset inteiro, navegando os resumos de comunidade; Local Search, que expande a partir de entidades específicas e seus vizinhos diretos no grafo; e DRIFT Search, que combina os dois, partindo de resumos de comunidade para gerar sub-perguntas refinadas por local search.

Se o objetivo é sumarização e reasoning sobre um corpus inteiro, essa abordagem hierárquica resolve um problema que a composição simples de vector search mais graph traversal não resolve sozinha. Se o objetivo é responder perguntas pontuais que cruzam conteúdo documental com relações estruturadas, a composição mais simples costuma ser suficiente e mais barata de operar.

Comparação estrutural

Similaridade vetorial não é verdade, é hipótese

Vale reforçar isso porque é o erro arquitetural mais recorrente que vejo em implementações de RAG corporativo. Dois textos podem estar próximos no espaço vetorial sem que exista entre eles nenhuma relação de negócio real. "Cliente A", "Produto Crédito" e "Contrato 93821" podem aparecer semanticamente próximos em um embedding sem que isso signifique Cliente A --possui--> Contrato 93821. Essa afirmação só é confiável quando vem de uma fonte de verdade estruturada, seja um banco transacional, um CRM ou um grafo curado. E vale a mesma cautela para o próprio grafo: um grafo populado por extração automática de entidades e relações via LLM, sem etapa de validação, carrega risco equivalente de relação incorreta, entity resolution mal feita e dado desatualizado. A confiabilidade do grafo não vem do fato de ser um grafo, vem da qualidade do processo que o alimenta. Tratar embeddings como fonte de fatos de negócio é o tipo de decisão que passa despercebida em demonstração e vira incidente de confiabilidade em produção, porque o modelo vai responder com confiança sobre uma relação que nunca existiu.

Governança é o que separa demo de sistema em produção

Em demonstração, basta a resposta parecer correta. Em produção corporativa, o sistema precisa responder a perguntas que a demo nunca fez: de onde veio essa informação, qual documento e qual versão foram usados, qual dado originou essa relação, quem tem permissão para acessar essa informação, quando ela foi atualizada, e se a resposta é reproduzível dado o mesmo estado de dados. Isso não é detalhe de implementação, é requisito não funcional de primeira classe em qualquer arquitetura de IA corporativa: lineage, versionamento de índice e de grafo, autorização por tenant, auditoria, qualidade e proveniência de dados, observabilidade do pipeline de retrieval e políticas de retenção. Em setores regulados, saber como a resposta foi construída é tão relevante quanto a resposta em si, porque é isso que sustenta uma auditoria ou uma disputa contratual.

Uma heurística direta para decidir

Preciso descobrir o que documentos dizem: RAG.

Preciso descobrir como entidades estão relacionadas: Graph.

Preciso entender conteúdo e depois navegar pelas relações que ele aciona: GraphRAG.

E a pergunta que vem antes de qualquer uma dessas três: essa complexidade é justificada pelo volume e pela criticidade real das perguntas que o sistema vai responder, ou estou adicionando um mecanismo de recuperação porque está em evidência? Se a grande maioria das perguntas do sistema for respondida por busca documental, introduzir um banco de grafos, um pipeline de extração de entidades e uma camada de roteamento adiciona custo operacional permanente para resolver uma fração pequena dos casos. Arquitetura madura inclui saber quando não adicionar uma tecnologia.

Conclusão

RAG, Graph e GraphRAG não competem entre si porque resolvem classes diferentes de problema de recuperação de conhecimento. RAG responde o que o conteúdo diz. Graph responde como as entidades se relacionam. GraphRAG responde as duas coisas ao mesmo tempo, quando a pergunta de negócio realmente exige isso. A decisão arquitetural que separa um sistema de IA generativa robusto de um protótipo que não sobrevive à produção não começa na escolha do modelo, do framework ou do banco vetorial. Começa em identificar com precisão qual tipo de pergunta o negócio precisa que o sistema responda, e só depois desenhar o mecanismo de recuperação, a modelagem de dados e a camada de governança que sustentam essa resposta em escala, com rastreabilidade e sob auditoria.