GraphRAG: a evolução do RAG que usa grafos para entender relações entre dados

Se você já ouviu falar de RAG (Retrieval-Augmented Generation), sabe que ele resolve um problema clássico dos modelos de linguagem: as alucinações. Em vez de o modelo inventar respostas a partir de um conhecimento congelado no treinamento, o RAG busca informações em uma base externa antes de responder. É a diferença entre um aluno que responde de memória e um aluno que consulta a biblioteca antes de levantar a mão.

O problema é que essa biblioteca, na maioria das implementações, é organizada de um jeito essencialmente plano: pedaços de texto (chunks) transformados em vetores e guardados em um banco vetorial. Quando você pergunta algo, o sistema procura os trechos matematicamente mais parecidos com a pergunta e entrega esses trechos ao modelo. Funciona bem para perguntas pontuais — "qual é o prazo de garantia do produto X?" —, mas começa a falhar feio quando a resposta não está em nenhum trecho específico, e sim na relação entre muitos trechos.

É exatamente essa lacuna que o GraphRAG veio preencher.

O limite do RAG vetorial: quando a resposta não está em lugar nenhum

Imagine que você tem 40 mil chamados técnicos de uma operação industrial e pergunta: "Quais são os problemas recorrentes e como eles se relacionam entre si?". Um RAG vetorial tradicional vai fazer o que sabe fazer: buscar os trechos de texto mais similares à palavra "problemas recorrentes". O resultado tende a ser uma coleção de relatos soltos, todos parecidos entre si, mas sem nenhuma visão agregada.

A pergunta é de natureza global — ela exige síntese do corpus inteiro —, e a busca por similaridade é de natureza local. Há um descasamento estrutural. O sistema até pode acertar por sorte, juntando fragmentos suficientes, mas não há garantia de que ele cobriu o conjunto, nem de que conseguiu conectar um incidente de janeiro com a causa raiz registrada em agosto por outro time.

Some a isso dois problemas conhecidos:

• Fragmentação de contexto: a resposta depende de três documentos diferentes, mas o retrieval traz apenas um deles, porque os outros dois usam vocabulário distinto.
• Ausência de multi-hop: perguntas que exigem encadear entidades ("quem fornece o componente que falhou no lote que foi reprovado?") exigem navegar por relações, não por similaridade de texto.

O RAG vetorial não enxerga estrutura. Ele enxerga proximidade semântica. E proximidade semântica, sozinha, não é conhecimento.

O que é GraphRAG, afinal

GraphRAG é uma arquitetura que combina Retrieval-Augmented Generation com grafos de conhecimento. Em vez de indexar apenas vetores de texto, o pipeline extrai do corpus as entidades (pessoas, organizações, produtos, eventos, conceitos) e as relações entre elas, montando um grafo. Sobre esse grafo, aplica-se detecção de comunidades — agrupamentos de entidades densamente conectadas — e gera-se, para cada comunidade, um resumo em linguagem natural.

O resultado é uma estrutura hierárquica: entidades na base, comunidades no meio e sumários de alto nível no topo. Quando chega uma pergunta, o sistema pode escolher em qual nível da hierarquia mergulhar.

A abordagem ganhou tração com o trabalho do time de pesquisa da Microsoft, que popularizou o termo em 2024 e publicou uma implementação aberta. A ideia central do artigo original é direta: LLMs falham em tarefas de "sensemaking" sobre um corpus privado porque não têm como percorrer o todo; um índice baseado em grafo, construído com o próprio LLM, resolve isso ao pré-computar a estrutura do conhecimento.

Como resumiu um dos artigos que serviram de base para esta matéria, estamos percebendo que, para fazer algo significativamente útil com IA generativa, não dá para depender apenas de LLMs autorregressivos tomando todas as decisões. RAG vetorial e fine-tuning ajudam — e são bons o suficiente para vários casos de uso —, mas existe uma classe inteira de problemas em que eles simplesmente não chegam lá.

Por dentro do pipeline: como o grafo é construído

Entender o GraphRAG na prática exige olhar para o processo de indexação, que é bem mais caro e mais interessante que o do RAG vetorial.

1. Segmentação em unidades de texto
O corpus é dividido em trechos. Até aqui, nada diferente do RAG clássico.

2. Extração de entidades e relações
Cada trecho é enviado a um LLM com um prompt estruturado que pede: liste as entidades mencionadas, seus tipos e as relações entre elas. O modelo devolve algo como "Fornecedor A — fornece — Componente B", com uma descrição e um peso de confiança. Isso roda milhares de vezes, uma por trecho.

3. Resolução de entidades (entity resolution)
"Cláudio Vago", "C. Vago" e "o diretor de tecnologia" precisam virar um único nó. Essa etapa de desambiguação e merge é uma das mais delicadas — e uma das principais fontes de erro em produção.

4. Construção do grafo
Entidades viram nós; relações viram arestas, com peso proporcional à frequência e à força da conexão. O grafo resultante é um mapa navegável do conhecimento contido no corpus.

5. Detecção de comunidades
Aqui entra o algoritmo Leiden, uma evolução do Louvain, que particiona o grafo em comunidades de nós fortemente conectados. Comunidades podem ser hierárquicas: uma comunidade grande se subdivide em subcomunidades menores e mais coesas.

6. Sumarização hierárquica
Para cada comunidade, o LLM gera um relatório em linguagem natural descrevendo seus temas, entidades centrais e relações. Esses sumários formam o nível "global" do índice.

7. Geração de perguntas candidatas (opcional)
Algumas implementações geram automaticamente perguntas que cada comunidade responde bem. Isso melhora a qualidade do retrieval em modo global.

Os modos de busca: local, global e além

A grande virada prática do GraphRAG está nos modos de consulta, que atacam problemas diferentes.

Busca local — funciona de forma parecida com o RAG tradicional, mas ancorada no grafo. O sistema identifica entidades na pergunta, encontra os nós correspondentes, expande para vizinhos e traz trechos de texto associados a esse subgrafo. Excelente para perguntas específicas, com a vantagem de capturar conexões que a busca vetorial perderia.

Busca global — aqui está o diferencial. A pergunta é respondida com base nos sumários das comunidades, não nos chunks originais. O sistema pode fazer uma varredura em map-reduce: cada sumário de comunidade recebe a pergunta e produz uma resposta parcial com uma pontuação de relevância; depois, as parciais são consolidadas numa resposta final. É assim que se responde "quais são os temas recorrentes deste corpus?" com cobertura real, e não com uma amostra enviesada por similaridade.

Busca híbrida ou drift — combina os dois modos, começando pelo nível global e "derivando" para comunidades específicas conforme a pergunta exige detalhe.

Busca por entidade — usa o grafo como índice de busca direta para perguntas do tipo "tudo o que sabemos sobre o fornecedor X".

GraphRAG vs. RAG vetorial: onde cada um ganha

A leitura correta dessa tabela não é "GraphRAG substitui RAG vetorial". É "cada um resolve uma classe de problema". Em muitas arquiteturas de produção, os dois convivem: o roteador decide se a pergunta é local (vetorial) ou global (grafo).

Custos, limites e as dores do mundo real

Seria desonesto vender GraphRAG como bala de prata. Ele tem custos concretos.

Indexação cara. A extração de entidades roda um LLM sobre cada chunk do corpus — e o mesmo conteúdo costuma ser processado mais de uma vez (extração de entidades, extração de relações, sumarização). Para um corpus de milhões de documentos, a conta de tokens pode ser proibitiva. É comum ver projetos que reduzem o escopo do corpus antes de indexar, ou que usam modelos menores e mais baratos para a extração, reservando o modelo grande para a sumarização.

Grafo desatualizado. Diferente de um banco vetorial, em que basta adicionar novos embeddings, inserir um documento novo no grafo pode alterar entidades, arestas e comunidades — o que invalida sumários já gerados. Estratégias incrementais existem, mas exigem engenharia.

Erros se propagam. Uma entidade mal resolvida contamina o grafo inteiro. Duas pessoas com o mesmo nome fundidas em um único nó geram respostas confiantes e erradas. Curadoria e validação não são opcionais.

Avaliação difícil. Métricas tradicionais de retrieval não capturam qualidade de resposta global. Boa parte dos times recorre a avaliação humana ou a LLMs-juízes, com todos os vieses que isso implica.

Nem todo corpus tem grafo. Em textos curtos, isolados e pouco relacionais, o ganho pode não justificar o custo. A regra prática: quanto mais entidades compartilhadas e relações implícitas o corpus tiver, maior o retorno.

Onde isso já faz diferença

Os casos de uso mais maduros compartilham uma característica: o valor está nas conexões, não nos documentos.

• Jurídico e compliance: milhares de contratos, aditivos e pareceres. Perguntas como "quais cláusulas de rescisão aparecem em contratos com fornecedores do setor X?" exigem agregação e cruzamento.
• Manufatura e suporte técnico: correlacionar chamados, lotes, componentes e fornecedores para encontrar causa raiz recorrente.
• Inteligência de mercado: mapear concorrentes, produtos, patentes e movimentações de executivos a partir de notícias e relatórios.
• Saúde e pesquisa: conectar medicamentos, condições, estudos e efeitos adversos em literatura científica.
• Cibersegurança: modelar ativos, vulnerabilidades, ameaças e campanhas como um grafo, permitindo perguntas de impacto em cadeia.

O ecossistema de ferramentas

O campo amadureceu rápido. Hoje há opções para diferentes níveis de ambição:

• Microsoft GraphRAG — implementação de referência, com busca local e global, pipeline completo e CLI.
• Neo4j — banco de grafos com integrações dedicadas e suporte a consultas Cypher combinadas com vetores.
• LlamaIndex — oferece PropertyGraphIndex, integrando extração, armazenamento em grafo e retrieval.
• LangChain — componentes para construção de grafos de conhecimento e recuperação híbrida.
• LightRAG, nano-graphrag e similares — implementações enxutas, pensadas para reduzir custo e complexidade.
• Bancos de grafo vetoriais como FalkorDB e NebulaGraph — unem travessia de grafo e busca por similaridade no mesmo motor.

Para quem está começando, a recomendação é quase unânime: não comece pelo corpus inteiro. Escolha um domínio delimitado, valide se a pergunta que você quer responder é realmente global ou multi-hop, e só então escale.

Boas práticas para não quebrar a cara

1. Defina a ontologia antes de extrair. Saber quais tipos de entidade importam evita um grafo poluído com ruído.
2. Meça o custo por documento antes de escalar. Projete tokens e latência para o corpus completo.
3. Invista em resolução de entidades. É a etapa que mais impacta a qualidade final.
4. Mantenha o texto original rastreável. Todo nó e aresta deve apontar para os trechos que os originaram — isso sustenta a auditabilidade, principal vantagem do GraphRAG.
5. Combine com busca vetorial. Um roteador que escolhe entre local e global costuma superar qualquer modo isolado.
6. Estabeleça um conjunto de avaliação desde o dia zero. Sem isso, você não saberá se o grafo está ajudando ou só encarecendo.

O futuro: grafos como memória de agentes

A tendência mais forte é o GraphRAG deixar de ser apenas uma técnica de recuperação e virar infraestrutura de memória para agentes de IA. Agentes que executam tarefas longas precisam lembrar não só de fatos, mas de como os fatos se relacionam — quem pediu o quê, quando, com base em qual informação. Um grafo é uma representação natural para isso.

Junto vem a ideia de ontologias aprendidas: em vez de um esquema rígido definido à mão, o sistema descobre os tipos de entidade e relação a partir do próprio corpus, refinando o grafo continuamente. E, na direção oposta, cresce o interesse por grafos curados por humanos em domínios regulados, onde a rastreabilidade não é um luxo, é exigência legal.

Conclusão

O RAG resolveu o problema da alucinação ao dar ao modelo uma fonte externa de verdade. O GraphRAG resolve o problema seguinte: dar a essa fonte estrutura. Ao transformar um corpus em um grafo de entidades e relações — e ao resumir esse grafo em camadas hierárquicas —, ele torna possível responder perguntas que o RAG vetorial simplesmente não alcança: perguntas sobre padrões, sobre temas recorrentes, sobre cadeias de causalidade espalhadas por milhares de documentos.

A conta, porém, é real. Indexar um grafo custa caro, mantê-lo exige disciplina e nem todo problema justifica a complexidade. A pergunta certa não é "GraphRAG ou RAG?", e sim "a resposta que eu preciso está em um documento ou na relação entre muitos deles?". Se for a segunda opção, o grafo deixou de ser um experimento de pesquisa e passou a ser infraestrutura.

E, à medida que agentes autônomos passam a operar sobre bases de conhecimento corporativas, é provável que a estrutura em grafo deixe de ser um diferencial competitivo para se tornar o padrão básico. A pergunta, então, não será mais se vale a pena construir o grafo — mas por que você ainda não construiu o seu.