At 02:13, a fictional checkout service begins timing out shortly after a release. Search returns four promising items: a runbook, the deployment record, an older incident report, and a page from the service map.
They all mention the affected service or a related dependency. But the on-call engineer still needs to know: did the release change a dependency used by this request path? Does the earlier incident concern the same version? Does the runbook’s mitigation apply to the system as it runs now?
The search results are useful. They are not yet an explanation. The missing information lies in the relationships between the records.
Interactive figure
Same hits. Different context.
Similarity view: ranked hits show relevance, but not how the records connect.
The same four records can be read as ranked search results or as a bounded evidence network. The relationship view makes the current release path explicit while keeping the similar but outdated incident visible.
Similarity finds the trail
Retrieval-augmented generation (RAG) adds retrieved material to a model’s input. The original RAG study combined a language model with a retriever and an external document index, evaluating the approach on knowledge-intensive tasks. Its authors also identified provenance and updating knowledge as open problems. Retrieval can bring relevant evidence into reach; it does not automatically establish how multiple sources connect or which one applies. (Lewis et al., NeurIPS 2020)
In the incident example, the deployment record may name a library, the service map may identify which service uses it, and the prior incident may describe a different version. Each passage can be relevant on its own. The useful context depends on linking them correctly and preserving when each fact was true.
A retriever can return the trail. The system still has to trace it.
A context graph is a query-shaped evidence network
Here, a context graph means a task-specific network of relevant entities, evidence, and relationships assembled for a request. It may draw on a persistent knowledge graph, but it is the bounded view selected for the current question, including source material and current state.
For the incident, the graph might connect:
- the affected service to the dependency it uses;
- the release to the component it changed;
- the alert to the observed failure;
- the prior incident to the dependency version involved;
- the runbook to the system versions its mitigation covers.
Each relationship should retain its evidence, time range, and verification status. A link such as “observed with” should not silently become “caused by.” The graph should expose the path supporting an explanation while leaving causal conclusions to evidence and analysis.
This is different from sending a model every node in a large enterprise knowledge graph. The context graph is a selected neighborhood around a specific task. It combines linked records with the original passages needed to check what those links mean.
Graphs extend retrieval in specific ways
Recent research explores several ways of combining graph structure with retrieval.
KG²RAG starts with semantically retrieved seed passages, then uses a knowledge graph to expand and organize related chunks. Its authors report results on HotpotQA and variants for the retrieval and response measures they tested. (Zhu et al., NAACL 2025)
HippoRAG combines knowledge graphs, language models, and Personalized PageRank for multi-hop question answering. Its authors evaluate it against other retrieval methods on benchmark QA tasks. (Gutiérrez et al., NeurIPS 2024)
GraphRAG uses entity relationships and community summaries to support questions about an entire corpus. Its preprint reports improvements over a conventional RAG baseline for a particular class of global sensemaking questions over million-token-range datasets. (Edge et al., Microsoft Research, 2024 preprint)
These are distinct systems and evaluations, not a direct comparison establishing one winning architecture. They show why it can be useful to preserve relationships alongside retrieved text, especially for multi-hop and corpus-wide questions.
Keep the graph where the relationships matter
A graph is most useful when the task depends on connections that may cross documents, systems, or time:
| Task pattern | What graph structure can add |
|---|---|
| A single fact in one authoritative document | Retrieval may be sufficient |
| Evidence spans several sources | Links can expose how the sources connect |
| An answer depends on versions or dates | Validity and supersession relationships can be made explicit |
| A question asks for a pattern across a corpus | Clusters and summaries can support global synthesis |
| A system proposes an operational action | The evidence path and applicable constraints can be inspected |
Longer inputs do not remove the need to choose and organize evidence. In their experiments on multi-document question answering and key-value retrieval, Liu and colleagues found that model performance could vary with the position of relevant information in a long context. That result is limited to the tasks and models they tested, but it is a reason to assess context organization as well as retrieval quality. (Liu et al., TACL 2024)
A graph introduces new failure modes
Relationships can be wrong, stale, or missing. An entity resolver might merge two similar services. An extracted edge might connect a release to a dependency it did not change. A graph can make a mistaken relationship easier to reuse if its evidence and validity are not retained.
Graph expansion can also add too much material. A context graph should not become an excuse to pass an entire knowledge base to a model. Traverse only relationships that support the current task, then select the relevant source records and passages.
Permissions need separate enforcement as well. A relationship being visible in a graph does not mean every user or agent is authorized to see the underlying record.
Upgrade the context when retrieval exposes a relationship problem
A practical graph-augmented system can keep its existing retriever. Retrieval supplies candidate evidence; entity resolution identifies what the evidence refers to; graph traversal finds related records; context selection retains the applicable paths and source text. Inference then works over that bounded context, and validation checks whether the answer is supported.
If the system cannot find the evidence, improve retrieval or source coverage. If it finds relevant evidence but cannot determine how the pieces relate, add semantic structure. If the relationship is uncertain or unsupported, surface that uncertainty instead of letting a fluent answer hide it.
This distinction keeps the architecture proportionate. Simple lookups do not need a graph layer. Repeated multi-hop, temporal, or cross-source failures may justify one.
RAG finds candidate evidence. A context graph helps show how that evidence fits together for a specific question.
References
- Lewis, P. et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” Advances in Neural Information Processing Systems 33, 2020. Paper
- Zhu, X. et al. “Knowledge Graph-Guided Retrieval Augmented Generation.” Proceedings of NAACL-HLT 2025, 8912–8924. Paper
- Gutiérrez, B. J. et al. “HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models.” NeurIPS 2024. Paper
- Edge, D. et al. “From Local to Global: A Graph RAG Approach to Query-Focused Summarization.” Microsoft Research, 2024 preprint. Publication page
- Liu, N. F. et al. “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics, 12, 157–173, 2024. Paper