10.1 Complementary representations
Large language models(大语言模型)represent regularities learned from training data in their parameters. Knowledge graphs represent selected information explicitly through identifiers, relationships, and context. These forms of representation support different operations. A language model can interpret flexible questions and generate readable text. A graph can support precise identity, structured constraints, and traceable updates. Combining them is useful when an application needs both linguistic flexibility and explicit control over evidence.
Pan and colleagues describe several broad directions for unifying language models and knowledge graphs, including graph enhanced language models, language model assisted graph tasks, and closer joint integration [35]. The report adopts this broad distinction while focusing on an operational question: what information crosses the interface, and what guarantees survive the crossing? Turning a precise graph result into prose can lose qualifications. Turning prose into graph records can introduce unsupported precision. Both directions need validation.
10.2 Retrieval augmented generation
Retrieval augmented generation(检索增强生成)conditions an answer on retrieved external information. Lewis and colleagues developed an influential approach combining retrieval with sequence generation for knowledge intensive tasks [34]. In an application, retrieval can update the evidence available to a model without changing all of its parameters. Yet retrieval alone does not guarantee factuality. The system may retrieve irrelevant material, omit a decisive source, or generate an answer that goes beyond the retrieved evidence.
A conventional text retrieval pipeline can be a strong baseline. It searches document chunks, reranks candidates, and provides selected passages to a language model. If the question asks for a definition clearly stated in one document, a graph may add little value. Graph based retrieval becomes more attractive when the answer depends on connecting entities across documents, following typed relationships, or aggregating evidence at a broader level. The workload should determine whether that additional structure is worth constructing and maintaining.
10.3 Several designs called GraphRAG
GraphRAG(图谱检索增强生成)is a family of designs rather than one universally specified algorithm. A system may retrieve explicit triples from an established graph, build a graph from documents, use communities for summarization, or combine graph neural representations with textual evidence. These variants differ in construction cost, query behavior, and error modes. A research comparison should identify which architecture is being evaluated instead of treating all graph augmented systems as equivalent.
Edge and colleagues propose a graph based approach to query focused summarization, using an extracted graph and community summaries to support questions about a corpus as a whole [36]. The contribution addresses a different retrieval need from finding one local fact. It suggests why precomputed summaries can help global questions, while also making construction and summary maintenance part of the system's cost. The report does not infer from this work that every factual question benefits from global community summarization.
LightRAG combines graph structure with retrieval mechanisms designed to access information at different levels [41]. G-Retriever investigates retrieval augmented generation for textual graphs [39]. LEGO-GraphRAG analyzes graph based retrieval through modular components and empirical comparisons [42]. These studies collectively motivate careful decomposition of the pipeline. Each component can improve one dimension while increasing latency, token use, or dependence on the quality of the constructed graph.
| Work | Architectural emphasis | Status |
|---|---|---|
| GraphRAG [36] | Corpus level summaries from extracted graph communities | 2024 preprint |
| Think-on-Graph [37] | Interactive graph path exploration | ICLR 2024 |
| RoG [38] | Planning, retrieval, and graph grounded reasoning | ICLR 2024 |
| G-Retriever [39] | Retrieval for textual graph questions | NeurIPS 2024 |
| LightRAG [41] | Graph supported retrieval at different levels | Findings of EMNLP 2025 |
| LEGO-GraphRAG [42] | Modular analysis of graph retrieval design | PVLDB 2025 |
| Youtu-GraphRAG [43] | Agentic integration of construction and retrieval | 2025 preprint |
A proposed hybrid GraphRAG workflow. Source evidence and qualifiers are passed to the generator after bounded graph expansion.
Original figures retain bilingual labels. Read alongside the explanation; open for a larger view.10.4 A proposed hybrid retrieval pipeline
The proposed Research Evidence Graph assistant first interprets the question and identifies constraints such as method, dataset, date, and evidence standard. It then generates candidate entities through exact identifiers, aliases, lexical search, and semantic retrieval. Candidate resolution is explicit: if “GraphLens” maps to several entities, the system does not silently choose one. It either uses available context to disambiguate or returns a scoped clarification.
After selecting seeds, the retriever follows an allowlisted set of relationship types with bounded depth and result size. For a question about experimental support, it follows evaluations and source claims rather than arbitrary coauthorship links. It collects both the structured records and the source passages that support them. The evidence bundle contains identifiers, source versions, relevant qualifiers, and access decisions. This bundle is the grounding material for answer generation.
A reranker can prioritize evidence by relevance and completeness, but the answer policy should preserve conflicting results. If the top ranked study supports a claim while another valid study contradicts it, a summary that omits the contradiction may be misleading. The system can reserve part of its context budget for disagreement and uncertainty. That is an application design choice to be tested, not an assumption that a relevance model will automatically discover the right scientific balance.
10.5 Global questions and summary maintenance
A question such as “What are the main methodological disagreements in this collection?” requires synthesis across many documents. Community summaries can provide an intermediate representation that is cheaper to inspect than all raw text for every query. Their usefulness depends on whether the communities and summaries preserve the relevant distinctions. A cluster formed by citation proximity may not align with the disagreement the user cares about. The system may need several organizing views or a query specific aggregation step.
Summaries should carry provenance and dependency links to their inputs. When a source changes, the system should mark affected summaries as stale. It should also avoid counting a summary and its underlying sources as independent evidence. A summary is a derived artifact, not another study. This is a recurring source of accidental evidence inflation when multiple retrieval layers are combined without explicit lineage.
The context window remains a resource constraint even when the graph is large. Retrieving every adjacent node can overwhelm the generator with loosely relevant information. A bounded evidence selection process should optimize for answer requirements, diversity of support, and contradiction coverage. More retrieved tokens do not necessarily mean more knowledge. They can also obscure the decisive evidence and increase the chance that the model combines incompatible contexts.
10.6 Faithfulness and fair comparison
Faithfulness(忠实性)asks whether an answer is supported by the supplied evidence. Correctness asks whether the answer is accurate under the task's reference standard. These measures can diverge: an answer can be accidentally correct while unsupported, or faithfully summarize a source that is wrong. A research assistant should be evaluated on both. Citation presence alone is insufficient; the cited passage must support the specific statement attached to it.
A fair comparison holds the language model, source collection, date cutoff, and answer budget constant where possible. It compares text retrieval, hybrid text retrieval, graph retrieval, and any community summary variant on different question classes. Local fact questions, multi source questions, temporal questions, and global synthesis questions should be analyzed separately. Otherwise, an overall average can conceal a substantial improvement on one class and a regression on another.
Costs should include graph construction, updates, and query time. A system that spends heavily before the first query may be economical for a stable corpus with many repeated questions, but expensive for a rapidly changing collection with few queries. Reporting only query latency can hide that difference. The appropriate design is the one that delivers the required evidence quality under the actual lifecycle cost, not the one with the most elaborate retrieval diagram.