The original HippoRAG combines a knowledge graph with Personalized PageRank to retrieve evidence across documents. Its 2024 paper is useful when the clues to an answer don't all resemble the question closely enough to be retrieved as isolated passages.
In my DTCC talk, “Not only Vector,” I keep coming back to the same point: vector retrieval is valuable, and we need to understand its limits. If the answer is sitting in one passage, similarity search can be a very direct way to find it.
The awkward cases are the ones where a person appears in document A, the relevant relationship appears in document B, and the fact you need is in document C. Each passage may look only weakly related to the full question. The answer becomes visible when the clues connect.
HippoRAG makes a practical choice here. It brings knowledge graphs and Personalized PageRank into RAG so those clues can meet. It still uses a retrieval encoder. The point is to give the system another way to find associations.
Sometimes the clues were never connected
Many RAG systems encode passages independently. If a passage is close to the query in the embedding space, it has a better chance of being retrieved. That works well for plenty of local questions. It can struggle when the answer depends on joining relationships across documents.
The paper's example involves Stanford, Alzheimer's research, and Thomas Südhof. One passage can connect the researcher to Stanford while another connects him to the research topic. Either passage alone may be a weak match for the complete query. The relationships meet at the same entity.
This is what a graph lets the system represent explicitly. It gives retrieval a way to follow the connections among the query's concepts.
How HippoRAG builds and searches its memory
The offline stage uses an LLM for open information extraction, or OpenIE. It extracts triples from passages to form a knowledge graph without starting from a fixed relation schema. A dense retrieval encoder also helps link nodes whose wording differs but whose meanings are close.
At query time, the system extracts named entities from the question and links them to graph nodes. Those nodes seed Personalized PageRank, or PPR. Relevance propagates through the graph, and the resulting node scores help rank the original passages.
The paper explains the architecture through hippocampal indexing theory, using an analogy involving the neocortex, parahippocampal regions, and hippocampus. It's a memorable way to describe the roles. I would still keep the boundary clear: this is a retrieval system inspired by a theory of memory, not a demonstration that the system functions as a human brain.
Multiple hops without repeated question generation
Some approaches to retrieval across multiple hops alternate between retrieving evidence and asking a model to produce the next question. That can follow a useful trail. It can also wander off course, and each step brings additional latency and calls.
HippoRAG can run PPR over a graph that has already been built. A single retrieval stage can activate associations around several query entities. “Single” here refers to the retrieval stage, not to one edge traversal or one internal iteration of the graph algorithm.
The paper evaluated methods on 1,000 validation questions each from MuSiQue, 2WikiMultiHopQA, and HotpotQA. On 2WikiMultiHopQA, HippoRAG with ColBERTv2 scored 70.7% Recall@2 and 89.1% Recall@5, versus 59.2% and 68.2% for ColBERTv2 alone. That is a gain of 11.5 and 20.9 percentage points. These metrics measure recall of supporting passages among the top two or five retrieved results, not answer accuracy. Gains were smaller on MuSiQue. On HotpotQA, which the authors discuss as requiring less knowledge integration, HippoRAG didn't win across the board. See Table 2 in the paper.
Those results are a reason to examine the task. A graph is useful when the question actually benefits from relationships across documents. Adding one doesn't establish that every retrieval workload will improve.
The paper also reports comparable or better performance than iterative retrieval such as IRCoT, with lower online cost and latency in its setup. I wouldn't turn that into a general speed claim. The comparison depends on the models, implementation, and workload, and a system still has to pay for building its index.
A graph can connect mistakes, too
HippoRAG's graph is extracted by an LLM. It isn't a knowledge base that someone has carefully checked edge by edge. Automated extraction makes graph construction practical, but the mistakes come along for the ride.
The authors examined 100 errors from MuSiQue. They attributed 48% to named entity recognition limitations, 28% to incorrect or missing OpenIE output, and 24% to PPR graph search. This small analysis doesn't describe every deployment. It does show where the pipeline can break.
A key clue may never be extracted from the query. An extracted relationship can be wrong. Even with useful nodes and edges, graph search can emphasize an unhelpful association.
I keep making this point about AI in data governance: it can be a powerful assistant, but the people operating the system remain responsible for how the output is used.
A vector result can be similar without being relevant. A graph adds the possibility that two things are connected for the wrong reason. Nodes and edges give us something to inspect. That is a starting point for governance, not a certificate of accuracy.
What this suggests for agent storage
In our design discussions around Cortrix, I think about this as a semantic storage question. If every block remains an isolated vector, how does an agent accumulate relationships across documents? If we introduce a graph, how do we preserve node identity and trace an edge to its source? What happens when the source turns out to be wrong?
Those are requirements to work through. They don't imply that Cortrix implements HippoRAG or that every graph governance capability is already available.
I don't take the paper as an instruction to force every dataset into a knowledge graph. I would rather let exact identifiers, full text retrieval, vector search, and explicit relationships do the jobs they are suited to. The system needs to keep the sources and boundaries clear enough that we can inspect the result.
Seventeen years of papers, one persistent data problem
We started in 2007 with DBpedia and a stable identity for the thing being discussed. TransE then gave relationships a learnable representation.
With RAG, external knowledge came back into generation. Reflexion asked how an agent could carry an experience into a later attempt. HippoRAG brings us back to connections across that stored material.
The technology changes, but I keep finding the same practical concern underneath it: can the system retain the context it needs, find it again, and give us a way to check what it is using?
That is the foundation I wanted to revisit with these five papers. It remains relevant whether you come to the problem through databases, retrieval, or agent memory.
References
Bernal Jiménez Gutiérrez et al. HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. NeurIPS 2024. Read the original paper. arXiv record for the original HippoRAG. Authors' code repository.