Guia GraphRAG: Quando Grafos de Conhecimento Vencem o RAG Vetorial (e Quando Não Vencem)

Guia GraphRAG: Quando Grafos de Conhecimento Vencem o RAG Vetorial (e Quando Não Vencem)

O GraphRAG não está morto, mas também não é o padrão. O microsoft/graphrag lançou a v3.1.1 em 2026-07-18 com 35.088 estrelas no GitHub, e três papers de benchmark de 2026 agora relatam, em voz alta, que ele frequentemente perde para a recuperação vetorial simples. Então este guia GraphRAG responde à única pergunta que sobrou: um grafo de conhecimento justifica a conta de indexação?

Você Deve Usar o GraphRAG? A Resposta Curta

Use o GraphRAG quando suas perguntas cruzam entidades ou abrangem o corpus inteiro, como "para quais fornecedores nosso maior cliente também vende?" Fique com o RAG vanilla ou híbrido para buscas de fato single-hop, documentos que mudam rápido e orçamentos apertados de latência. O grafo se paga nas perguntas multi-hop e custa dinheiro em todo o resto.

O GraphRAG não está morto e não é o padrão. Ele justifica a conta de indexação quando suas perguntas são multi-hop ou globais para o corpus, e perde dinheiro quando não são.

A versão curta:

• O GraphRAG vence nas perguntas multi-hop e que abrangem o corpus inteiro; o RAG vanilla vence nas buscas single-hop.
• Os benchmarks de 2026 são contraditórios: grafos ajudam na agregação, mas podem atrapalhar a sumarização de granularidade fina.
• O custo chega na hora da indexação, nas chamadas de LLM para extração, não na hora da consulta.
• Rode o Basic Search como controle no seu próprio corpus antes de construir qualquer coisa.

Se você já roda um pipeline de RAG vetorial funcional, a única decisão é se um grafo por cima justifica sua manutenção. A tabela abaixo é o argumento inteiro em seis linhas, e onde ela diz para ficar no vanilla, essa é a resposta honesta, com mais frequência do que os fornecedores admitem. A busca híbrida BM25 mais vetorial cobre a maioria desses casos sem nenhum grafo.

O Que o GraphRAG Realmente É: De Chunks a Comunidades

O GraphRAG é uma geração aumentada por recuperação sobre um grafo de conhecimento em vez de sobre chunks desconectados. Na indexação, um LLM extrai entidades e relacionamentos dos seus documentos, o algoritmo Leiden agrupa essas entidades em comunidades, e cada comunidade recebe um resumo. Na consulta, o grafo mais esses resumos respondem perguntas que uma janela top_k sobre chunks estruturalmente não consegue responder.

O pipeline, de ponta a ponta:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Duas fases fazem o trabalho. A fase de indexação é a cara: cada chunk custa uma chamada de LLM para extrair entidades e relacionamentos, e os resumos de comunidade custam ainda mais chamadas por cima. A fase de consulta é onde o retorno aparece. Como o grafo armazena relacionamentos explicitamente, uma pergunta como "para quais fornecedores nosso maior cliente também vende?" vira uma travessia em vez de uma aposta de que os dois chunks certos caiam na mesma janela top_k.

Os resumos importam porque são eles que o Global Search realmente lê: perguntas sobre o corpus inteiro são respondidas a partir de prosa de comunidade pré-escrita, não de chunks brutos. E cada aresta é um julgamento do LLM, armazenado como uma tripla que você poderia consultar em Cypher em um banco de dados de grafos de verdade. Esse design também é o motivo de a indexação dominar o custo, o que os números abaixo tornam concreto.

O enquadramento que merece seu lugar: o RAG vanilla recupera passagens, e o GraphRAG recupera estrutura. Sua escolha de modelo de embedding ainda importa para a camada vetorial, e seu banco de dados vetorial ainda armazena as descrições, mas o grafo é a nova peça que sustenta a carga. A documentação Index Overview oficial descreve cada etapa por completo.

Quais São os Quatro Métodos de Consulta do GraphRAG?

O motor de consultas do GraphRAG traz quatro métodos: Local Search, Global Search, DRIFT Search e Basic Search. O Local Search raciocina para fora a partir de entidades específicas, o Global Search agrega resumos de comunidade pelo corpus inteiro, o DRIFT Search mistura os dois recursivamente, e o Basic Search é uma baseline vetorial simples. Um quinto recurso, a Geração de Perguntas, fica por cima do motor, não ao lado dele.

Conferimos a documentação ativa em microsoft.github.io/graphrag/query/overview/ em 2026-07-30, e a conta é quatro. A maioria dos guias que ranqueiam cita dois ou três. A mesma checagem encontrou a palavra "lazy" zero vez nas páginas de visão geral de Index e Query, o que importa para a seção de custo abaixo.

A linha que merece sua atenção é a última. O Basic Search é a baseline vetorial vanilla embutida, e ele existe para que você possa testar o grafo em A/B contra a recuperação simples no seu próprio corpus e descobrir se o grafo está justificando sua conta. Isso não é trivial; é o procedimento de decisão inteiro deste guia em um único recurso. Rode o Basic Search primeiro. Se o Local, o Global ou o DRIFT Search não o superarem nas perguntas que você realmente recebe, o grafo é um custo, não um upgrade.

O Que os Benchmarks de 2026 Realmente Descobriram?

Três papers de benchmark de 2026 concluem que o GraphRAG ajuda em tarefas de agregação multi-hop e de múltiplos fatos, mas frequentemente perde para o RAG vanilla em outros lugares. Um deles constrói um benchmark especificamente para achar onde os grafos perdem. Os três concordam que a vitória depende do tipo de pergunta, não do tamanho do corpus. A evidência diz que o GraphRAG é situacional, não padrão.

Um quarto esforço, o GraphRAG-Bench (repositório), avalia nove métodos GraphRAG em 16 disciplinas e 20 livros didáticos, e chega à mesma conclusão por um ângulo mais amplo.

Os três papers convergem em um ponto: o grafo justifica seu custo na agregação multi-hop e o perde na recuperação de granularidade fina.

Nossa leitura: o ciclo de hype causou o dano, e esses papers são a correção. Nenhum deles diz que grafos são inúteis. O que eles dizem, com consistência, é que a etapa de agregação que torna o GraphRAG bom em temas de todo o corpus é a mesma etapa que desfoca os detalhes de granularidade fina. O WildGraphBench é o exemplo mais claro: grafos ajudaram a agregação de múltiplos fatos a partir de um número moderado de fontes, e prejudicaram a precisão da sumarização na mesma avaliação. Isso não é uma contradição; é um único mecanismo aparecendo duas vezes.

A consequência prática é que você não consegue decidir isso só pela literatura. Os papers dizem quais tipos de pergunta testar, não se o seu corpus é um deles. É exatamente para isso que serve o controle com Basic Search da seção de métodos acima.

Quanto Custa o GraphRAG? (E a Ressalva do LazyGraphRAG Que Todo Mundo Repete Errado)

O custo do GraphRAG é uma conta de indexação, não de consulta, e é exatamente por isso que ele surpreende as pessoas. As chamadas de LLM que extraem entidades e relacionamentos de cada chunk, mais a passada de sumarização de comunidade, são o que o torna caro. Você paga adiantado, antes de uma única consulta rodar. A consulta é mais barata, mas não é grátis: o Global Search expande sobre os resumos de comunidade com uma chamada de LLM por comunidade, e é por isso que a tabela de métodos acima o marca como alto.

Os únicos números públicos concretos vêm da Microsoft Research. Em 2024-11-25, a equipe relatou que o custo de indexação do LazyGraphRAG era idêntico ao do RAG vetorial e 0,1% do custo do GraphRAG completo, e que, com 4% do custo de consulta do global search do GraphRAG, ele superou os métodos concorrentes testados, nos dois tipos de consulta, local e global (Microsoft Research). Esses são os números da Microsoft, do blog da Microsoft, e os relatamos como tal; não rodamos uma indexação com preço por conta própria.

Aqui está a correção que a maioria dos artigos perde. O LazyGraphRAG não é uma opção de pip install. Pela própria nota editorial da Microsoft de 2025-06-06, ele foi lançado no Microsoft Discovery e no Azure Local, não no pacote open source. Conferimos as páginas oficiais Index Overview e Query Overview em 2026-07-30: a palavra "lazy" aparece zero vez nas duas. Então, se um guia lista o LazyGraphRAG como uma variante que você pode subir hoje à tarde, ele está repetindo uma afirmação que deixou de ser verdadeira no mundo open source.

O que você pode fazer hoje: rodar o modelo de extração localmente. Apontar a etapa de indexação para um modelo local via Ollama remove as taxas de API por token da fase mais cara, e combinar isso com um armazenamento vetorial auto-hospedado mantém o resto da conta perto de zero.

Qual Biblioteca GraphRAG É Realmente Mantida?

Duas das seis bibliotecas GraphRAG mais citadas não recebem um push há seis e nove meses. Puxamos esses números da API do GitHub em 2026-07-30, e o censo abaixo é a checagem que os round-ups mais antigos pulam, com o comando para rodá-la de novo antes de você se comprometer com uma. LightRAG e microsoft/graphrag são as ativas; nano-graphrag e fast-graphrag estão caminhando para o abandonware.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Nossa leitura: stars são uma métrica de vaidade; a data do push é o número que importa. LightRAG e microsoft/graphrag são ambos mantidos ativamente, com o Graphiti logo atrás com uma abordagem de grafo temporal. nano-graphrag e fast-graphrag são os dois que posts antigos ainda recomendam só pela reputação, e nenhum dos dois lança nada há meio ano.

Como escolher: fique com o microsoft/graphrag se você quer a implementação de referência com os quatro métodos de consulta oficiais, com o LightRAG se você quer o projeto mais ativo e uma pegada mais leve, e com uma biblioteca mantida por fornecedor como a neo4j-graphrag-python se você já roda o banco de dados desse fornecedor. Evite qualquer coisa cujo último push seja anterior ao seu projeto em meio ano.

O Graphiti merece uma nota com escopo: seu design de grafo temporal é feito para recuperação sobre dados que mudam com o tempo, e ele se sobrepõe à memória de agentes, que cobrimos separadamente no nosso guia sobre Graphiti e memória de grafo temporal. Para o campo mais amplo, veja o ecossistema mais amplo de ferramentas RAG.

O Que Quebra Depois do Dia 200: Deriva do Grafo e Reextração

A deriva do grafo (graph drift) é o imposto que você paga depois do lançamento, e é a objeção número um dos praticantes por um bom motivo. Todo tutorial trata o grafo como algo que você constrói uma vez. Equipes reais travam no dia 200.

Três coisas decaem. Primeiro, a reindexação a cada atualização de documento. Quando 40 documentos mudam, você não pode simplesmente re-embedá-los; você precisa rodar de novo a extração por LLM nos chunks alterados, reconciliar as entidades novas com o grafo antigo e recalcular as comunidades afetadas e seus resumos. Um guia no Medium chama a atualização incremental de fácil. Os praticantes no r/Rag discordam. O autor de uma thread de 2026-04-25 rodando BM25 mais BGE-M3 sobre cerca de 600 documentos foi direto: "A extração de entidades/relações baseada em LLM é ruidosa, e reindexar a cada atualização de documento parece doloroso."

Segundo, a degradação da resolução de entidades. "Acme Corp", "Acme" e "ACME Corporation" chegam em documentos diferentes, com meses de intervalo, e se dividem em três nós que deveriam ser um. Nada os mescla automaticamente.

Terceiro, relacionamentos que eram verdadeiros na extração e silenciosamente deixaram de ser. Ninguém recebe um alerta quando uma aresta reports_to fica obsoleta.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Um codebase é o pior caso, e o mais interessante. O autocomplete agora sugere "graphrag for codebase", "graphrag claude code" e "graphrag mcp server", e um codebase é um grafo que muda a cada hora: cada commit reescreve arestas de chamada, move símbolos e apaga funções. Isso é deriva do grafo em um cronograma que nenhum re-index noturno consegue acompanhar por completo. É também por isso que as ferramentas sérias de grafo de código se apoiam em parsers determinísticos como tree-sitter e LSP para as arestas e reservam o LLM para a prosa ao redor delas: docstrings, mensagens de commit, threads de review. Se você está grafeando um repositório, grafe a camada que se move devagar com o LLM e a que se move rápido com um parser.

O Que os Desenvolvedores Realmente Dizem Sobre o GraphRAG?

Os desenvolvedores em atividade estão divididos, e o Google parece saber disso: uma thread do Reddit ranqueia em segundo lugar para "graphrag vs rag", o que é o motor de busca dizendo que esse tópico quer a opinião de pares, não texto de fornecedor.

O ceticismo é real. Na thread de 2024 do r/Rag "Você sempre recomendaria RAG com (grafo de) conhecimento em vez do RAG normal?" (10 pontos, 86% de votos positivos), u/EncartaIt escreveu: "Todos os tutoriais que encontrei são simplistas demais e não fazem uma defesa convincente do padrão de grafo de conhecimento." u/Prestigious_Run_4049 foi mais direto: "Acho que graph rag é só hype. As pessoas adoram falar sobre isso e soa legal, mas ninguém usa de verdade em casos de uso reais." Nem todos concordam. u/pytheryx, argumentando a partir da produção, observou que a recuperação por grafo vence nas perguntas do tipo lista que precisam de contexto de mais chunks do que o top_k retorna; o corpus de whitepapers dele precisa de cerca de 50 chunks para uma resposta completa.

A thread de 2026 é mais ponderada. u/Popular_Sand2773: "A maioria das implementações de graph rag simplesmente trapaceia em escala. Você roda uma busca vetorial ou de metadados padrão para encontrar os nós iniciais e depois caminha pelo grafo." u/ggone20, rodando um sistema com cerca de 300 milhões de artefatos: "Em escala, você literalmente não consegue viver sem eles para responder perguntas reais."

Nossa leitura coincide com o argumento mais afiado das duas threads: o ponto de inflexão é a complexidade das suas perguntas, não o tamanho do seu corpus. É também o que os benchmarks acima encontraram, e é por isso que ficamos do lado dos praticantes que limitam o escopo da ferramenta ao trabalho multi-hop, não dos que a chamam de morta.

Como a Techsy Aborda Isso

Aqui está a sequência que usamos em projetos de clientes, e ela é deliberadamente sem emoção.

Primeiro, prove o teto da recuperação híbrida. A maioria dos pedidos de "precisamos de um grafo" que ouvimos é, na verdade, um problema de chunking ou de reranking disfarçado. Um pipeline de BM25 mais vetorial com um reranker decente responde mais do que as equipes esperam.

Segundo, rode o Basic Search como controle no seu próprio corpus antes de construir qualquer coisa. É exatamente para isso que o quarto método de consulta serve: uma baseline vetorial simples contra a qual você pode testar o grafo em A/B, nos seus dados, com as suas perguntas.

Terceiro, só construa o grafo quando uma classe medida de perguntas falhar nesse controle. Se consultas multi-hop ou de corpus inteiro errarem, você tem um caso real. Se não errarem, você acabou de se livrar de uma conta de indexação e de um problema de deriva.

Quer um segundo par de olhos na sua stack de recuperação? Receba uma consultoria gratuita.

Sobre o Autor

Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a stack de ferramentas de LLM que a equipe da Techsy realmente usa em produção. Nos projetos de clientes, ele toma as decisões de arquitetura de recuperação: quando a busca híbrida basta, e quando um corpus realmente precisa de um grafo. Conecte-se com ele no LinkedIn.

Perguntas Frequentes

Como o GraphRAG funciona?

O GraphRAG indexa seus documentos em um grafo de conhecimento. Um LLM extrai entidades e relacionamentos de cada chunk, o algoritmo Leiden agrupa essas entidades em comunidades, e cada comunidade recebe um resumo. Na consulta, o motor busca no grafo e nesses resumos, então ele consegue conectar fatos que estão em chunks diferentes.

Qual é a diferença entre GraphRAG e RAG?

O RAG padrão recupera os top-k chunks mais similares e os passa para o modelo. O GraphRAG recupera estrutura: entidades, os relacionamentos entre elas e resumos de comunidade pré-escritos. Essa estrutura extra é o que permite responder perguntas multi-hop e de corpus inteiro, e é também o que torna a indexação mais lenta e mais cara.

Quando devo usar o GraphRAG?

Use quando suas perguntas cruzam entidades ou abrangem o corpus inteiro, como perguntas de sobreposição de fornecedores ou análise de temas recorrentes sobre milhares de documentos. Pule para buscas de fato single-hop, corpus que muda rápido e orçamentos apertados de latência ou de custo. Se um pipeline híbrido simples já responde a uma classe de perguntas, o grafo adiciona custo sem adicionar valor.

O GraphRAG está morto?

Não, mas também não é o padrão. Os benchmarks de 2026 mostram que ele frequentemente perde para o RAG vanilla em tarefas do dia a dia, o que matou o hype, ao mesmo tempo que ainda vence nas perguntas multi-hop e de agregação. O enquadramento honesto é situacional: o GraphRAG justifica seu custo para os tipos de pergunta certos e perde dinheiro no resto.

Quais são os métodos de consulta do GraphRAG?

O motor de consultas oficial traz quatro: Local Search para perguntas centradas em entidades, Global Search para agregação de todo o corpus, DRIFT Search para uma mistura recursiva dos dois, e Basic Search para recuperação vetorial simples. Um quinto recurso, a Geração de Perguntas, fica por cima. O Basic Search é o que mais importa: ele é o controle contra o qual você testa o grafo em A/B.

Quanto custa a indexação do GraphRAG?

O custo chega na indexação, nas chamadas de LLM que extraem entidades e relacionamentos de cada chunk mais a sumarização de comunidade. A Microsoft Research relatou a indexação do LazyGraphRAG em 0,1% do custo do GraphRAG completo e idêntica à do RAG vetorial, mas essa variante foi lançada em produtos da Microsoft, não na biblioteca open source. Não rodamos uma indexação com preço por conta própria.

Dá para rodar o GraphRAG localmente com o Ollama?

Sim. A biblioteca microsoft/graphrag permite apontar a indexação e as consultas para um modelo local servido pelo Ollama, o que remove as taxas de API por token da etapa de extração. Você troca velocidade e qualidade por custo: modelos locais são mais fracos na extração de entidades, então espere grafos mais ruidosos e indexações mais longas em hardware modesto.

LightRAG ou Microsoft GraphRAG: qual é melhor?

Eles otimizam para coisas diferentes. O LightRAG (38.353 stars, push em 2026-07-30) é o mais ativo e mais leve de rodar; o microsoft/graphrag (35.088 stars, v3.1.1) é a implementação de referência com os quatro métodos de consulta oficiais. Fique com o LightRAG para um grafo de produção eficiente, com o da Microsoft para comportamento fiel à especificação e o controle do Basic Search.

Quem criou o GraphRAG e quando?

A Microsoft Research criou o GraphRAG. A equipe publicou o paper em 2024 e mantém o repositório open source microsoft/graphrag sob a licença MIT, com documentação em microsoft.github.io/graphrag. A biblioteca de referência chegou à v3.1.1 em 2026-07-18, e um ecossistema ativo de implementações de terceiros, incluindo LightRAG e Graphiti, cresceu ao redor dela.

O Veredito: Quando um Grafo Justifica Seu Custo

A evidência aponta para uma direção, então aqui está a posição.

• O GraphRAG não está morto. Ele é situacional, e os benchmarks de 2026 dizem isso em voz alta.
• Ele justifica a conta de indexação nas perguntas de entidades multi-hop e na agregação de todo o corpus. Perde dinheiro nas buscas single-hop.
• O custo é uma conta de indexação, e a variante barata que todo mundo cita, o LazyGraphRAG, nunca chegou à biblioteca open source.
• O grafo decai depois do lançamento: a resolução de entidades deriva e os relacionamentos ficam obsoletos, então reserve orçamento para reindexação.
• Rode o Basic Search como controle no seu próprio corpus antes de construir qualquer coisa.

Em uma frase: um grafo de conhecimento justifica seu custo quando suas perguntas são multi-hop ou globais para o corpus, e não antes. Se você quer uma segunda opinião sobre sua stack de recuperação, receba uma consultoria gratuita.