How does GraphRAG differ from HippoRAG despite both using knowledge graphs?
This explores why two knowledge-graph RAG systems end up solving different problems — GraphRAG is built to summarize a whole corpus, while HippoRAG is built to chase facts across multiple hops.
This explores why two systems that both turn a corpus into a knowledge graph behave so differently — and the short answer is that they build the graph for opposite jobs. GraphRAG is a *top-down summarizer*. After extracting an entity graph, it runs Leiden community detection to cluster the graph into modular groups, then pre-generates a summary for each community so it can answer broad, corpus-wide questions through a map-reduce pass over those summaries Can community detection enable RAG systems to answer global corpus questions?. Its sweet spot is the "global" question — themes, overviews, "what does this whole collection say about X" — which flat chunk retrieval simply can't reach.
HippoRAG is a *bottom-up traverser*. It also converts the corpus to a graph, but instead of clustering and summarizing, it seeds Personalized PageRank from the concepts in your query and lets the random walk fan out across connected entities — collapsing what would normally be several iterative retrieval rounds into a single multi-hop step, 10–20x cheaper and with markedly better accuracy on multi-hop QA Can knowledge graphs enable multi-hop reasoning in one retrieval step?. So the divide is summarization-vs-traversal: GraphRAG pre-computes structure to answer questions about the corpus as a whole; HippoRAG leaves the structure unsummarized and navigates it per query to stitch together specific facts.
That contrast lines up with a larger debate in the corpus about *when* to build the graph and *how much* of it to read. GraphRAG's pre-built, pre-summarized graph is powerful but also expensive and stale-prone — which is exactly the cost LogicRAG attacks by constructing query-specific logic graphs at inference time instead Can query-time graph construction replace pre-built knowledge graphs?. And GraphRAG's instinct to ingest community structure wholesale runs into context limits, which is what Graph-O1 sidesteps by learning a traversal policy that selectively walks the graph rather than reading all of it Can learned traversal policies beat exhaustive graph reading? — landing it much closer to HippoRAG's navigate-don't-summarize philosophy.
The deeper point is that "uses a knowledge graph" isn't one design choice but several. StructRAG argues the structure should be matched to the query's demands — sometimes a graph, sometimes a table or catalogue — and trains a router to pick Can routing queries to task-matched structures improve RAG reasoning?. Read that way, GraphRAG and HippoRAG aren't competitors so much as two different points on a structure-selection spectrum: one optimized for global synthesis, the other for relational hop-chasing. Others push the representation itself, like hypergraph memory that binds three-plus entities into one relation for constraints a pairwise graph would lose Can hypergraphs capture multi-hop reasoning better than graphs?.
One under-appreciated wrinkle: GraphRAG's reliance on LLM extraction and graph topology is also a liability. Because answers funnel through community structure, tiny perturbations — editing under 0.05% of source words — can cascade through the topology and collapse QA accuracy from 95% to 50% How vulnerable is GraphRAG to tiny text manipulations?. The very pre-built structure that gives GraphRAG its global reach is what makes it brittle, whereas a query-seeded traversal approach distributes its dependence differently. The architecture you choose decides not just what questions you can answer, but how you can be attacked.
Sources 7 notes
GraphRAG uses Leiden community detection to partition entity graphs into modular groups with pre-generated summaries, enabling map-reduce answering of global questions that pure RAG and prior summarization methods cannot handle efficiently.
HippoRAG converts corpus into a knowledge graph, then uses Personalized PageRank seeded from query concepts to traverse multi-hop paths in one step. It matches iterative retrieval while being 10-20x cheaper and 6-13x faster, with 20% better accuracy on multi-hop QA.
LogicRAG constructs directed acyclic graphs from queries at inference time rather than pre-building corpus-wide graphs, eliminating construction overhead, avoiding staleness, and enabling query-specific retrieval logic without sacrificing multi-hop reasoning capability.
Graph-O1 replaces whole-graph ingestion with step-by-step agentic navigation using Monte Carlo Tree Search and reinforcement learning. This approach fits within LLM context windows while learning domain-specific traversal policies, though it trades certainty about the full graph for decision-making under uncertainty.
StructRAG demonstrates that selecting knowledge structure type based on query demands—via DPO-trained router choosing among tables, graphs, algorithms, catalogues, and chunks—improves knowledge-intensive reasoning over standard retrieval. The approach grounds this in cognitive load and cognitive fit theory from cognitive science.
HGMem organizes retrieved evidence as hyperedges rather than flat lists or binary graphs, allowing three or more entities to bind into single relations without decomposition. This structure accumulates coherent knowledge across retrieval steps, trading representational complexity for constraint expressiveness.
Two knowledge poisoning attacks modify fewer than 0.05% of source words to reduce QA accuracy from 95% to 50%. The attacks exploit GraphRAG's reliance on LLM extraction, which amplifies small perturbations through graph topology.