Query-Centric Graph Retrieval Augmented Generation

## Abstract

Abstract Graph-based retrieval-augmented generation (RAG) enriches large language models (LLMs) with external knowledge for long-context understanding and multi-hop reasoning, but existing methods face a granularity dilemma: fine-grained entity-level graphs incur high token costs and lose context, while coarse document-level graphs fail to capture nuanced relations. We introduce QCG-RAG, a query-centric graph RAG framework that enables query-granular indexing and multi-hop chunk retrieval. Our query-centric approach leverages Doc2Query and Doc2Query– to construct query-centric graphs with controllable granularity, improving graph quality and interpretability. A tailored multi-hop retrieval mechanism then selects relevant chunks via the generated queries. Experiments on LiHuaWorld and MultiHop-RAG show that QCG-RAG consistently outperforms prior chunk-based and graph-based RAG methods in question answering accuracy, establishing a new paradigm for multi-hop reasoning.

## 1 Introduction

Retrieval-augmented generation (RAG) has become a standard approach for improving the factuality of large language models (LLMs) by grounding them in external knowledge (Gao et al., 2023). By retrieving supporting chunk-based evidence, RAG not only enhances accuracy but also mitigates hallucinations common in LLM generation (Yu et al., 2024). However, existing chunk-based RAG pipelines often fail when queries are underspecified or require multi-hop reasoning, due to a mismatch between query intent and the fragmented distribution of supporting chunk-level evidence in retrieval (Tang & Yang, 2024).

Graph-based RAG provides a more effective strategy for capturing relational knowledge and associating dispersed evidence across documents (Peng et al., 2024; Han et al., 2024; Yu et al., 2025) compared to chunk-based RAG.
In particular, GraphRAG (Edge et al., 2024a) constructs a fine-grained entity-centric knowledge graph (KG) with community summaries, allowing retrieval to exploit both text similarity and entity-level connections. This fine-grained KG strengthens semantic coherence across dispersed entity-level evidence, thereby enabling deeper contextual understanding. GraphRAG is especially effective for multi-hop reasoning and long context understanding, enabling applications in question answering over massive documents (Ghassel et al., 2025; Chen et al., 2024) and long dialogues (Fan et al., 2025; Zhang et al., 2025b).

However, existing graph-based RAG methods face a fundamental trade-off: fine-grained entity-level graphs incur prohibitive token costs and often lose semantic coherence, while coarse-grained document-level graphs sacrifice nuanced relations.
For instance, GraphRAG imposes considerable computational overhead: constructing fine-grained entity-level graphs and producing community summaries inflate token budgets and inference cost, and can erode contextual coherence (Min et al., 2025; Zhang et al., 2025a).
Recent work simplifies graph construction by skipping community detection and summarization, and instead using lightweight information extractors (e.g., SpaCy (Honnibal et al., 2020)) or fine-tuned small LLMs (e.g., Phi-3-3.8B (Abdin et al., 2024), but at the cost of lower graph quality.
Other efforts adopt hierarchical index graphs with document-level links (Chen et al., 2024), which are efficient but too coarse to support nuanced reasoning.
These limitations highlight the need for strategies that balance granularity and effectiveness in graph-based RAG.

Figure: Figure 1: Illustration of (a) coarse-grained document-level graphs, (b) fine-grained entity-level graphs, and (c) controllable-grained query-centric graphs for RAG.
Refer to caption: task.png

Document expansion techniques, such as Doc2Query (Nogueira et al., 2019) for generating queries from documents and Doc2Query– (Gospodinov et al., 2023) for filtering irrelevant queries, provide a query-centric expansion paradigm. We argue that integrating Doc2Query-generated queries with graphs enables the construction of a controllable query-centric graph that lies between fine-grained entity-level and coarse-grained document-level representations.
To overcome the above mentioned granularity dilemma, we propose Query-Centric Graph Retrieval-Augmented Generation (QCG-RAG), a framework that tailors graph construction and retrieval to the granularity of queries. QCG-RAG introduces a query-centric graph (QCG), constructed with Doc2Query and Doc2Query– techniques to generate query-guided nodes and edges, yielding indexing graphs with controllable granularity. On top of this graph, we design a multi-hop retrieval & generation mechanism that efficiently selects relevant chunks via generated queries, enabling precise reasoning across dispersed evidence.
Figure [1](https://arxiv.org/html/2509.21237v1#S1.F1) illustrates (a) coarse-grained document-level graphs, (b) fine-grained entity-level graphs, and (c) controllable-grained query-centric graphs for RAG.
The main contributions of this paper are threefold:

• Query-Centric Graph Construction. We present the first query-driven, granularity-controllable graph construction framework for RAG, which improves graph quality and preserves interpretability via generated queries.

• Query-Centric Retrieval & Generation Mechanism. We develop an effective multi-hop retrieval process on QCG, which enables accurate retrieval of relevant text chunks for complex queries.

• Comprehensive Evaluation. We conduct experiments demonstrating that QCG-RAG consistently outperforms prior chunk-based and graph-based RAG methods in question answering accuracy.

## 2 Related Work

#### Chunk-based RAG.

Conventional chunk-based RAG frameworks, such as Naive RAG (Gao et al., 2023), typically follow a four-step pipeline: (1) Chunking: documents are segmented into fixed-length units using sliding windows or semantic boundary detection to balance granularity and context; (2) Embedding: chunks are encoded into dense vectors with pretrained encoders (e.g., BGE-M3 (Multi-Granularity, 2024) and Sentence-BERT (Reimers & Gurevych, 2019)) and indexed in vector databases (e.g., FAISS (Douze et al., 2024), Milvus (Wang et al., 2021), and ElasticSearch(^1^11[https://github.com/elastic/elasticsearch](https://github.com/elastic/elasticsearch))); (3) Retrieval: user queries are embedded and compared against chunk vectors via similarity metrics, optionally reranked with cross-encoders; and (4) Generation: top-k retrieved chunks are concatenated with the query and fed into LLMs (e.g., GPT-4 (Achiam et al., 2023), Qwen2.5 (Qwen et al., 2025), DeepSeek-R1 (Guo et al., 2025)) to produce responses. While effective for factual grounding, this pipeline often suffers from semantic misalignment between retrieval and generation, as well as insufficient coverage for multi-hop queries. These limitations motivate graph-based RAG approaches, which introduce structured semantic representations to better bridge the gap between queries and dispersed evidence.

#### Graph-based RAG.

Graph-based RAG extends conventional chunk-based RAG by introducing structured knowledge graphs that capture entity-level relations, enabling retrieval not only by text similarity but also through graph-based reasoning (Peng et al., 2024). Typical implementations, such as GraphRAG (Edge et al., 2024a), construct entity-centric graphs using LLM-based extraction, cluster entities into communities, and generate community summaries for retrieval alongside original documents, thereby supporting cross-chunk association and multi-hop reasoning. This line of work has motivated both (1) simplified variants (e.g., Fast GraphRAG(^2^22[https://github.com/circlemind-ai/fast-graphrag](https://github.com/circlemind-ai/fast-graphrag)), LightRAG (Guo et al., 2024), LazyGraphRAG (Edge et al., 2024b), Triplex(^3^33[https://huggingface.co/SciPhi/Triplex](https://huggingface.co/SciPhi/Triplex)), and E^2GraphRAG (Zhao et al., 2025)) that reduce construction costs through model and pipeline optimization, and (2) structural extensions (e.g., KG-Retriever (Chen et al., 2024), Mixture-of-PageRanks (Alonso & Millidge, 2024)) that organize knowledge into hierarchical indexes to improve retrieval coverage, highlighting the persistent granularity trade-off in graph-based RAG.

In particular, Fast GraphRAG simplifies this pipeline by eliminating community detection and summary generation to reduce LLM usage. LightRAG further streamlines the process by removing the community component entirely, making the system more lightweight. LazyGraphRAG replaces LLM-based extraction with small local models that capture noun co-occurrences, while generating community summaries dynamically at query time. Triplex leverages a fine-tuned lightweight LLM (Phi3-3.8B) and E^2GraphRAG employs traditional NLP tools such as SpaCy (Honnibal et al., 2020) for graph extraction, significantly lowering construction costs. Beyond simplification, KG-Retriever constructs a hierarchical index that integrates an entity-level knowledge graph with a document-level layer, enhancing intra- and inter-document connectivity to support efficient cross-document retrieval and multi-granularity access.
To address the granularity dilemma of graph-based RAG, we propose Query-Centric Graph RAG (QCG-RAG), which enables controllable query-centric graph construction to balance granularity and align retrieved evidence with user intent.

#### Document Expansion with Doc2Query & Doc2Query–.

Doc2Query (Nogueira et al., 2019) is a document expansion technique that trains sequence-to-sequence models (e.g., T5 (Raffel et al., 2020)) to generate queries likely associated with a given document, thereby improving retrieval by appending the generated queries to the document chunks. Doc2Query– (Gospodinov et al., 2023) refines this approach by filtering out irrelevant or hallucinated queries based on their similarity to the original chunks, which improves retrieval quality while reducing index overhead. The queries produced by these methods naturally operate at an intermediate granularity: richer and more interpretable than fine-grained entity triples, yet more precise than coarse-grained document chunks. This property makes them well suited for integration with graph-based RAG, where query nodes enable controllable, query-centric graph (QCG) construction that balances granularity and enhances both the accuracy and interpretability of multi-hop retrieval.

## 3 Methodology

### 3.1 Preliminaries

We consider the task of open-domain question answering (QA) under the retrieval-augmented generation (RAG) paradigm.
Formally, let $\mathcal{C}=\{c_{1},c_{2},\ldots,c_{N}\}$ denote a collection of text chunks derived from a document corpus $\mathcal{D}$, where each chunk $c_{i}(i\in[1,N])$ is a contiguous segment of text (e.g., a dialogue or passage).
Given a user query $q_{u}\in\mathcal{Q}$, the goal is to generate an answer $a$ by retrieving relevant chunks from $\mathcal{C}$ and conditioning a large language model (LLM) on both $q_{u}$ and the retrieved chunk evidence.

#### Doc2Query.

Doc2Query (Nogueira et al., 2019) is a document expansion technique that enrich the retrieval space, where each chunk $c_{i}$ is used as a prompt to an LLM to generate multiple synthetic query:

$$ $\mathcal{Q}_{g,i}=\{q_{g,i}^{1},q_{g,i}^{2},\ldots,q_{g,i}^{M}\},$ $$

where $q_{g,i}^{j}(j\in[1,M])$ denotes a generated query that is grounded in the chunk content of $c_{i}$. $M$ is the number of generated queries per chunk $c_{i}$.
This document expansion allows the retrieval module to associate user queries not only with explicit surface forms of chunks, but also with semantically aligned synthetic queries.

#### Doc2Query–.

Doc2Query– (Gospodinov et al., 2023) is a further filtering step to mitigate noise introduced by synthetic queries.
Specifically, the semantic similarity is computed between each generated query $q_{g,i}^{j}$ and its originating chunk $c_{i}$, denoted $\text{sim}(q_{g,i}^{j},c_{i})$.
The generated queries are ranked by similarity and only the top $\alpha$-fraction (with $\alpha\in(0,1]$) are retained:

$$ $\mathcal{Q}_{g,i}^{\alpha}=\text{Top-}\alpha\big\{q_{g,i}^{j}\mid\text{sim}(q_{g,i}^{j},c_{i})\big\}.$ $$

This maintains synthetic queries faithfulness to $c_{i}$ while improving retrieval precision.

#### Standard RAG Pipeline.

In the RAG framework, the retrieval component returns a ranked list of top-$K$ chunks $\mathcal{C}_{\text{top-}K}=\{c_{1},\ldots,c_{K}\}$ based on a similarity function $\text{sim}(q,c)$, often instantiated by dense embedding retrievers.
The generation component then produces the final response:

$$ $a=\text{LLM}\big(q_{u}\mid\mathcal{C}_{\text{top-}K}\big).$ $$

We use this setting, augmented with extended Doc2Query and Doc2Query–, as the basis for introducing our proposed Query-Centric Graph Retrieval Augmented Generation (QCG-RAG) framework.

Figure: Figure 2: Overview of our proposed QCG-RAG framework, which consists of (a) Query-Centric Graph Construction and (b) Query-Centric Graph Retrieval & Generation.
Refer to caption: qcgrag.png

### 3.2 Framework Overview

Prior graph-based RAG approaches exhibit inherent limitations in granularity: either too fine-grained with entity-level graphs or too coarse-grained with document-level graphs.
To address this granularity dilemma, we propose Query-Centric Graph Retrieval-Augmented Generation (QCG-RAG), a novel framework that integrates Query-Centric Graph (QCG) indexing and retrieval mechanisms to enhance response accuracy and interpretability.
As illustrated in Figure [2](https://arxiv.org/html/2509.21237v1#S3.F2), our framework consists of two major steps: Query-Centric Graph Construction and Query-Centric Graph Retrieval & Generation.

#### Query-Centric Graph Construction.

We first enrich the retrieval space by generating synthetic query–answer pairs from each text chunk using extended Doc2Query.
Given a chunk $c_{i}$, an LLM generates a set of queries $\{q_{g,i}^{j}\}$ with corresponding answers $\{a_{g,i}^{j}\}$ that faithfully represent the content of $c_{i}$.
To reduce noise, we apply extended Doc2Query–, which ranks the generated query-answer pairs by their semantic similarity to the source chunk and retains only the top $\alpha$ fraction.
Note that, unlike the original Doc2Query and Doc2Query–, which leverage queries only, the extended methods incorporate query–answer pairs.
The resulting high-quality queries serve as nodes in the Query-Centric Graph (QCG), where edges represent chunk–query membership and query–query similarity relations.
This process enables graph construction with controllable granularity while strengthening chunk–query associations and capturing richer semantic relations among queries.

#### Query-Centric Graph Retrieval & Generation.

Given a user query $q_{u}$, retrieval proceeds in four steps:
(1) retrieving semantically related queries from the graph (*Query $\to$ Retrieved Queries*);
(2) expanding to neighboring queries to capture multi-hop relations (*Retrieved Queries $\to$ Neighboring Queries*);
(3) aggregating and ranking associated chunks linked to the retrieved query set (*Query Set $\to$ Chunk Set*);
and (4) generating the final response by conditioning the LLM on the user query and the top-$K$ retrieved chunks (*Top-$K$ Chunk Set $\to$ Generation*).
This query-centric retrieval design enables flexible granularity control, better coverage of relevant document segments, and interpretable reasoning paths.

### 3.3 Query-Centric Graph Construction

This component builds a controllable-granularity *Query-Centric Graph* by leveraging and extending Doc2Query and Doc2Query–.
It consists of three sequential steps:
(1) query generation, (2) query quality and quantity control, and (3) indexing graph construction.

#### Step 1: Query Generation.

Given a corpus of chunks $\mathcal{C}=\{c_{1},c_{2},\ldots,c_{N}\}$, each chunk $c_{i}$ is expanded into multiple synthetic query–answer pairs via extended Doc2Query:

$$ $\mathcal{Q}_{g,i}=\{(q_{g,i}^{1},a_{g,i}^{1}),(q_{g,i}^{2},a_{g,i}^{2}),\ldots,(q_{g,i}^{M},a_{g,i}^{M})\},$ $$

where $q_{g,i}^{j}(j\in[1,M])$ is a generated query grounded in $c_{i}$ and $a_{g,i}^{j}$ is its corresponding answer.
Query–answer pairs enrich semantic signals by anchoring queries with contextualized answers, reducing ambiguity, strengthening chunk alignment, and expanding retrieval through multiple grounded entry points for each chunk.

#### Step 2: Query Quality and Quantity Control.

For each generated query-answer pair $(q_{g,i}^{j},a_{g,i}^{j})$, we compute its semantic similarity with the source chunk $c_{i}$ according to extended Doc2Query–:

$$ $s_{i}^{j}=\text{sim}(q_{g,i}^{j}\oplus a_{g,i}^{j},c_{i}),$ $$

where $\text{sim}(\cdot,\cdot)$ denotes the semantic similarity function (e.g., cosine similarity). $\oplus$ denotes text-level concatenation.
The queries are ranked by $s_{i}^{j}$, and only the top $\alpha$ percentile are retained:

$$ $\mathcal{Q}_{g,i}^{\alpha}=\text{Top-}\alpha\big\{(q_{g,i}^{j},a_{g,i}^{j})\;\mid\;s_{i}^{j}\big\},\quad\alpha\in(0,1].$ $$

This mechanism maintains the fidelity of synthetic query-answer pairs to the source content $c_{i}$, which in turn contributes to more precise and reliable retrieval.

#### Step 3: Indexing Graph Construction.

We construct a two-layer indexing graph $\mathcal{G}=(V,E)$ consisting of a query-level layer and a chunk-level layer:

$$ $V=\mathcal{C}\;\cup\;\mathcal{Q}_{g},where~\mathcal{Q}_{g}=\bigcup_{i=1}^{N}\mathcal{Q}_{g,i}^{\alpha}.$ $$

Edges $E$ capture two types of relations:

$$ $\displaystyle E_{\text{intra}}$ $\displaystyle=\{(q,q^{\prime})\;\mid\;q^{\prime}\in\text{KNN}(q,k),q\in\mathcal{Q}_{g}\},$ $\displaystyle E_{\text{inter}}$ $\displaystyle=\{(q,c_{i})\;\mid\;q\in\mathcal{Q}_{g,i}^{\alpha},c_{i}\in\mathcal{C}\},$ $$

where $E_{\text{intra}}$ encodes semantic similarity between queries, and $E_{\text{inter}}$ links queries to their source chunks.
For simplicity, let $q$ denote $(q,a)$ and $q^{\prime}$ denote $(q^{\prime},a^{\prime})$.
In practice, $q$ corresponds to the combined query–answer pair $q\oplus a$ before being embedded into a vector space.
Unless otherwise stated, we adopt this simplified notation throughout the following discussion.
$\text{KNN}(q,k)$ denotes the set of the $k$ most similar queries $q^{\prime}$ to $q$ based on the similarity function.
The resulting *Query-Centric Graph* provides a high-quality, semantically rich, and granularity-controllable structure for downstream retrieval.

### 3.4 Query-Centric Graph Retrieval & Generation Mechanism

This component performs retrieval and response generation over the constructed Query-Centric Graph.
It consists of four sequential steps: (1) retrieving relevant queries, (2) expanding to neighboring queries, (3) collecting and ranking associated chunks, and (4) generating responses.

#### Step 1: Retrieving Relevant Queries.

Given a user query $q_{u}$, we first compute its similarity with graph queries $\mathcal{Q}_{g}=\bigcup_{i=1}^{N}\mathcal{Q}_{g,i}^{\alpha}$.
The similarity is defined as:

$$ $s(q_{u},q)=\text{sim}(q_{u},q)+\epsilon,\quad\forall q\in\mathcal{Q}_{g},$ $$

where $\text{sim}(\cdot,\cdot)$ denotes cosine similarity, and $\epsilon=1$.
To construct the set of retrieved queries, we apply both a similarity threshold $\gamma\in[0,2]$ to ensure relevance and a maximum node constraint $n$ to control graph size.

$$ $\mathcal{Q}_{r}=\big\{q\in\mathcal{Q}_{g}\;\mid\;s(q_{u},q)\geq\gamma\big\},\quad|\mathcal{Q}_{r}|\leq n.$ $$

#### Step 2: Expanding to Neighboring Queries.

For each retrieved query $q\in\mathcal{Q}_{r}$, we collect its $h$-hop neighbors from the query-level graph.
Formally, the one-hop neighbors are defined as:
$\mathcal{H}^{1}(q)=\{q^{\prime}\mid(q,q^{\prime})\in E_{\text{intra}}\}.$
For $h>1$, the $h$-hop neighbors are obtained by expanding the $(h-1)$-hop set:

$$ $\mathcal{H}^{n}(q)=\bigcup_{q^{\prime}\in\mathcal{H}^{n-1}(q)}\mathcal{H}^{1}(q^{\prime}).$ $$

The final query set is then the union of retrieved queries and their $h$-hop neighborhoods:

$$ $\mathcal{Q}^{*}=\mathcal{Q}_{r}\cup\bigcup_{q\in\mathcal{Q}_{r}}\bigcup_{i=1}^{h}\mathcal{H}^{i}(q).$ $$

#### Step 3: Collecting and Ranking Associated Chunks.

Each query $q\in\mathcal{Q}^{*}$ is linked to its originating chunk(s) via query–chunk membership relations:

$$ $\mathcal{C}^{*}=\{c_{i}\in\mathcal{C}\mid(q,c_{i})\in E_{\text{inter}},\;q\in\mathcal{Q}^{*}\}.$ $$

To select the most relevant chunks, we compute a relevance score for each chunk $c\in\mathcal{C}^{*}$:

$$ $s(c)=\frac{1}{|\mathcal{Q}_{c}|}\sum_{q\in\mathcal{Q}_{c}}\text{sim}\big(q_{u},\;q\big),$ $$

where $\mathcal{Q}_{c}$ denotes the subset of queries in $\mathcal{Q}^{*}$ associated with chunk $c$.
Chunks are ranked by $s(c)$, and the top-$K$ are retained:

$$ $\mathcal{C}_{\text{top-}K}=\text{Top-}K\{c\in\mathcal{C}^{*}\mid s(c)\}.$ $$

#### Step 4: Generating Responses.

Finally, the answer is generated by conditioning the LLM on the user query $q_{u}$ and the top-$K$ selected chunks $\mathcal{C}_{\text{top-}K}$:

$$ $a=\text{LLM}\big(q_{u}\mid\mathcal{C}_{\text{top-}K}\big).$ $$

The Query-Centric Graph Retrieval & Generation process enhances traditional RAG by retrieving through queries rather than directly over chunks, expanding to multi-hop neighbors, and aggregating evidence with controllable granularity.
This design ensures better coverage of relevant document segments, improved response accuracy, and interpretable reasoning paths, distinguishing it from conventional chunk-based and graph-based RAG approaches.

## 4 Experiments

### 4.1 Experimental Settings

#### Datasets.

We evaluate on two QA benchmarks: LiHuaWorld (Fan et al., 2025) and MultiHop-RAG (Tang & Yang, 2024). LiHuaWorld contains one year of English chat records from a virtual user, with queries spanning single-hop, multi-hop, and unanswerable types, each paired with annotated answers and supporting documents. MultiHop-RAG is constructed from English news articles and provides multi-hop queries with ground-truth answers and evidence. Together, these datasets cover long-term personal memory QA and news-based multi-hop reasoning. Detailed statistics are provided in Appendix [A](https://arxiv.org/html/2509.21237v1#A1).

#### Evaluation Metric.

We evaluate the RAG system outputs using automatic exact-match Accuracy and an LLM-as-a-Judge protocol (Gu et al., 2024).
*Accuracy* is defined as the proportion of queries for which the predicted answer exactly matches the reference semantically.
For *LLM-as-a-Judge*, we employ a strong instruction-tuned model (Qwen2.5-72B-Instruct) as the evaluator. The judge receives the user query, candidate response(s), and the reference answer, and outputs a categorical correctness decision (correct/incorrect). To ensure reproducibility, we adopt a fixed prompt and deterministic decoding.

#### Baselines.

We compare QCG-RAG with representative RAG and graph-based RAG methods:

• Naive RAG (Lewis et al., 2020): A standard baseline that retrieves relevant documents via a dense retriever and conditions an LLM generator on the retrieved content.

• D2QRAG & D2Q–RAG: Extensions of Naive RAG that incorporate Doc2Query (Nogueira et al., 2019) or Doc2Query– (Gospodinov et al., 2023) for document expansion. Doc2Query appends generated queries to documents, while Doc2Query– further filters irrelevant or hallucinated queries.

• GraphRAG (Edge et al., 2024a): A graph-based approach that constructs entity-centric knowledge graphs and community-level summaries, and applies a map-reduce strategy over communities to aggregate answers.
GraphRAG is implemented using MsGraphRAG-Neo4j(^4^44[https://github.com/neo4j-contrib/ms-graphrag-neo4j](https://github.com/neo4j-contrib/ms-graphrag-neo4j)), enabling retrieval over chunks, entities, relations, and summaries.

• LightRAG (Guo et al., 2024): A graph-based method that builds entity–relation indexes and employs a dual-level retrieval framework for fine-grained entity access and coarse-grained topic retrieval.

• MiniRAG (Fan et al., 2025): A lightweight heterogeneous graph framework that unifies text chunks and entities into a single index and employs heuristic retrieval for efficient knowledge discovery.

• KG-Retriever (Chen et al., 2024): A hierarchical index graph (HIG) framework combining an entity-level knowledge graph with a document-level layer to enhance both intra-document and cross-document connectivity.

#### Setup Details.

Following prior work (Fan et al., 2025), we segment documents into chunks of 1200 tokens with an overlap of 100 tokens, and additionally use a 512-token with 64-token overlap setting for comparison.
For embeddings, we employ Sentence-BERT (Reimers & Gurevych, 2019), using all-MiniLM-L6-v2 as the default model and all-mpnet-base-v2 for comparison; cosine similarity is used for retrieval without reranking. We retrieve the top-$K$ chunks ($K=5$) and cap the input length at 6000 tokens.

For QCG-RAG, we set dataset-specific hyperparameters: for LiHuaWorld, $M=20$, $\alpha=80\%$, $h=1$, $k=2$, $n=10$, and $\gamma=1.5$; for MultiHop-RAG, $M=20$, $\alpha=80\%$, $h=1$, $k=3$, $n=15$, and $\gamma=1.0$.
Details of the implementation can be found in Appendix [B](https://arxiv.org/html/2509.21237v1#A2).

We adopt Qwen2.5-72B-Instruct (Team, 2024) for query generation to build query-centric graphs, and use Qwen2.5-7B-Instruct for comparison. We also employ Qwen2.5-72B-Instruct for question answering and response evaluation within the *LLM-as-a-Judge* framework. The LLM prompts are provided in Appendix [C](https://arxiv.org/html/2509.21237v1#A3).

To assess the impact of node choice on QCG-RAG performance, we also conduct an ablation on node formulations using both LiHuaWorld and MultiHop-RAG. Specifically, we compare four variants: (1) QCG w/ Query, where only queries are used as nodes; (2) QCG w/ Answer, where only answers are used as nodes; (3) Doc2Query w/ 7B, where queries are generated by Qwen2.5-7B-Instruct; and (4) Sentence Nodes, where each sentence forms a graph node. The default setting of QCG-RAG employs concatenated Query+Answer nodes.

**Table 1: Performance comparison on LiHuaWorld and MultiHop-RAG using Accuracy (%). Context indicates whether the method incorporates chunks (C), entities (E), relations (R), or summaries (S). Graph includes Knowledge Graph (KG), Hierarchical Index Graph (HIG), and Query-Centric Graph (QCG). The best results are highlighted in bold, and the second-best results are underlined.**
| Method | Graph | Context | LiHuaWorld | MultiHop-RAG |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C | E | R | S | Overall | Multi | Single | Null | Overall | Inference | Comparison | Temporal | Null |  |  |
| Naive RAG | - | ✓ | ✗ | ✗ | ✗ | 65.78% | 43.94% | 66.80% | 80.00% | 75.80% | 93.46% | 66.85% | 68.00% | 71.21% |
| D2QRAG | - | ✓ | ✗ | ✗ | ✗ | 63.74% | 39.39% | 65.22% | 76.92% | 76.20% | 92.81% | 69.61% | 66.00% | 71.21% |
| D2Q–RAG | - | ✓ | ✗ | ✗ | ✗ | 64.99% | 40.91% | 66.60% | 76.92% | 76.80% | 92.16% | 67.96% | 70.00% | 75.76% |
| GraphRAG | KG | ✓ | ✓ | ✓ | ✓ | 42.70% | 28.79% | 39.72% | 80.00% | 67.20% | 81.05% | 64.09% | 66.00% | 45.45% |
| LightRAG | KG | ✗ | ✓ | ✓ | ✗ | 66.41% | 57.58% | 69.76% | 49.23% | 72.20% | 94.12% | 71.82% | 59.00% | 42.42% |
| MiniRAG | KG | ✓ | ✓ | ✗ | ✗ | 60.28% | 62.12% | 58.89% | 69.23% | 60.40% | 75.16% | 54.70% | 54.00% | 51.52% |
| KG-Retriever | HIG | ✗ | ✗ | ✓ | ✗ | 31.24% | 18.18% | 27.67% | 72.31% | 47.60% | 79.08% | 19.89% | 33.00% | 72.73% |
| QCG-RAG | QCG | ✓ | ✗ | ✗ | ✗ | 73.16% | 62.12% | 74.51% | 73.85% | 79.60% | 93.46% | 74.59% | 69.00% | 77.27% |

### 4.2 Experimental Results

#### RQ1: How does QCG-RAG perform in QA compared with baselines?

Table [1](https://arxiv.org/html/2509.21237v1#S4.T1) reports accuracy across LiHuaWorld and MultiHop-RAG. Overall, QCG-RAG achieves the best performance among all baselines, with an average accuracy of 73.16% on LiHuaWorld and 79.60% on MultiHop-RAG. Compared to Naive RAG (65.78% / 75.80%), QCG-RAG yields consistent gains of +7.4 and +3.8 points, demonstrating that query-centric indexing substantially improves retrieval quality and answer correctness. On the more challenging multi-hop subsets, QCG-RAG notably outperforms prior graph-based methods: 62.12% vs. 57.58% (LightRAG) on LiHuaWorld multi-hop, and 74.59% vs. 71.82% (LightRAG) on MultiHop-RAG comparison queries. Importantly, QCG-RAG maintains competitive performance across null queries (73.85% / 77.27%), showing robustness against unanswerable cases where many graph-based baselines degrade sharply. These results confirm that balancing graph granularity via query-centric construction yields stronger semantic alignment, leading to superior QA accuracy across both long-term personal memory and news-based multi-hop reasoning tasks.

Figure: (a) LiHua World
Refer to caption: lihuaworld-nhops.png

Figure: (a) LiHua World
Refer to caption: qcg_ablation_lihuaworld.png

#### RQ2: Why does QCG-RAG improve QA performance for multi-hop questions?

Figure [3](https://arxiv.org/html/2509.21237v1#S4.F3) shows the effect of hop size $h$ on QA accuracy across LiHuaWorld and MultiHop-RAG. QCG-RAG consistently outperforms Naive RAG under all hop settings, with the largest gains observed for one-hop and two-hop settings. For instance, on MultiHop-RAG, QCG-RAG ($k{=}3$) improves accuracy from 75.8% (Naive RAG) to nearly 80%, demonstrating stronger multi-hop reasoning. This advantage arises because query-centric graphs explicitly encode query-to-query and query-to-chunk relations, enabling effective expansion from initial retrieved queries to semantically related neighbors. By leveraging these structured connections, QCG-RAG can capture dispersed evidence across documents and integrate it into coherent reasoning chains, thereby addressing the limitations of chunk-only retrieval that often misses intermediate links.
Case studies on both datasets are provided in Appendix [D](https://arxiv.org/html/2509.21237v1#A4) to illustrate scenarios where QCG-RAG succeeds in deriving correct answers through multi-hop retrieval over QCG, whereas Naive RAG fails.

#### RQ3: What are the effects of QCG nodes in QCG-RAG?

Figure [4](https://arxiv.org/html/2509.21237v1#S4.F4) presents an ablation study on different node choices in QCG-RAG. The full model, which uses concatenated Query+Answer as nodes, consistently achieves the best accuracy on both LiHuaWorld and MultiHop-RAG. Using only queries (QCG w/ Query) yields competitive but lower performance, while using only answers (QCG w/ Answer) results in a substantial drop, highlighting that queries provide essential semantic grounding while answers alone lack sufficient context. Moreover, replacing the 72B-based Doc2Query with a smaller generator (Doc2Query w/ 7B) leads to reduced performance, indicating that graph quality benefits from stronger generators but ultimately depends more on node formulation than model size alone. Finally, constructing graphs with sentence-level nodes (Sentence Nodes) underperforms QCG, confirming that query-centric granularity provides a better balance between semantic richness and interpretability. Overall, these results demonstrate that QCG nodes, particularly the Query+Answer concatenation, are critical to achieving robust retrieval and reasoning performance.

Figure: (a) Top-$\alpha$ Percentile
Refer to caption: lihuaworld-alpha.png

Figure: (a) Top-$\alpha$ Percentile
Refer to caption: multihoprag-alpha.png

#### RQ4: How do the hyperparameters, such as α \alpha , k k and n n , affect the performance of QCG-RAG?

Figures [5](https://arxiv.org/html/2509.21237v1#S4.F5) and [6](https://arxiv.org/html/2509.21237v1#S4.F6) present ablations of key hyperparameters in QCG-RAG: (a) the effect of query truncation at the top-$\alpha$ percentile under different chunking strategies; (b) the effect of the number of nearest neighbors per node $k$ under different embedding models; and (c) the effect of the maximum number of retrieved query nodes $n$ under different similarity thresholds $\gamma$.
First, the query truncation top-$\alpha$ percentile (Figures [5](https://arxiv.org/html/2509.21237v1#S4.F5)a, [6](https://arxiv.org/html/2509.21237v1#S4.F6)a) shows a clear upward trend from 20% to 80%, after which performance plateaus or slightly decreases, suggesting that moderate query pruning effectively balances noise reduction and coverage.
Second, the number of the nearest neighbors per node $k$ (Figures [5](https://arxiv.org/html/2509.21237v1#S4.F5)b, [6](https://arxiv.org/html/2509.21237v1#S4.F6)b) peaks around $k=3$, reflecting that too few neighbors restrict multi-hop associations on QCG, whereas too many introduce noisy or redundant connections.
Finally, the maximum number of retrieved nodes $n$ (Figures [5](https://arxiv.org/html/2509.21237v1#S4.F5)c, [6](https://arxiv.org/html/2509.21237v1#S4.F6)c) achieves optimal performance when set between $10$ and $15$. A smaller $n$ (e.g., $5$) limits retrieval coverage, while a larger $n$ (e.g., $20$) introduces noisy queries that degrade accuracy.
Overall, the findings underscore that carefully balanced hyperparameters (e.g., $\alpha{=}80\%$, $k{=}3$, $n{=}15$) are crucial for QCG-RAG, as they enable adequate evidence coverage while avoiding redundancy and noise from excessive expansion.

## 5 Conclusion

We presented QCG-RAG, a query-centric graph retrieval-augmented generation framework that addresses the granularity dilemma in existing graph-based RAG methods. Unlike prior approaches that rely on either coarse document-level graphs or fine-grained entity-centric graphs, QCG-RAG constructs controllable-granularity query-centric graphs by leveraging Doc2Query and Doc2Query–, and employs a tailored multi-hop retrieval process over these graphs. Extensive experiments on LiHuaWorld and MultiHop-RAG demonstrate that QCG-RAG consistently outperforms both chunk-based and graph-based baselines, achieving state-of-the-art performance on multi-hop and long-context question answering. Our ablations further show that query formulation, node design, and balanced hyperparameter settings are critical to performance.

## Limitations

While QCG-RAG advances the state of graph-based retrieval-augmented generation, it still has several limitations. First, the framework depends on query generation quality; errors or biases in Doc2Query may propagate into graph construction and retrieval. Second, although query-centric graphs mitigate token overhead compared to entity-level graphs, constructing and maintaining large-scale QCGs remains computationally costly when applied to web-scale corpora. Third, our experiments are limited to English QA benchmarks; extending QCG-RAG to multi-lingual or domain-specific scenarios (e.g., legal or biomedical text) requires further validation. Finally, the current retrieval mechanism primarily focuses on structural and semantic similarity, but does not incorporate advanced reasoning strategies such as reinforcement learning or self-reflection, which may further enhance complex reasoning. We leave these directions for future work.

## Ethics Statement

This work builds on QA benchmarks (LiHuaWorld and MultiHop-RAG) that contain either synthetic or publicly available text, without involving private or sensitive user data. The proposed QCG-RAG framework aims to improve retrieval-augmented reasoning and does not introduce additional risks beyond those inherent to large language models, such as potential hallucinations or biases inherited from pre-trained models. We caution against deploying QCG-RAG in high-stakes domains (e.g., healthcare, law) without rigorous domain-specific validation, and emphasize that our contributions should be viewed as methodological advances in retrieval and reasoning.

## Reproducibility Statement

We have provided detailed descriptions of the QCG-RAG framework, including graph construction, retrieval mechanisms, and hyperparameter choices, in the main text and appendix. Dataset statistics, evaluation metrics, and experimental setups (embedding models, LLM configurations, and query generation methods) are reported in full. Hyperparameter ranges and default settings for both LiHuaWorld and MultiHop-RAG are explicitly specified, and all prompts used for query generation and evaluation are included in the appendix. Together, these details ensure that our experiments can be reliably reproduced.

## References

- Abdin et al. (2024)
Marah Abdin, Jyoti Aneja, Hany Awadalla, et al.
Phi-3 technical report: A highly capable language model locally on your phone, 2024.
URL [https://arxiv.org/abs/2404.14219](https://arxiv.org/abs/2404.14219).
- Achiam et al. (2023)
Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al.
Gpt-4 technical report.
*arXiv preprint arXiv:2303.08774*, 2023.
- Alonso & Millidge (2024)
Nicholas Alonso and Beren Millidge.
Mixture-of-pageranks: Replacing long-context with real-time, sparse graphrag.
*arXiv preprint arXiv:2412.06078*, 2024.
- Chen et al. (2024)
Weijie Chen, Ting Bai, Jinbo Su, Jian Luan, Wei Liu, and Chuan Shi.
Kg-retriever: Efficient knowledge indexing for retrieval-augmented large language models.
*arXiv preprint arXiv:2412.05547*, 2024.
- Douze et al. (2024)
Matthijs Douze, Alexandr Guzhva, Chengqi Deng, Jeff Johnson, Gergely Szilvasy, Pierre-Emmanuel Mazaré, Maria Lomeli, Lucas Hosseini, and Hervé Jégou.
The faiss library.
2024.
- Edge et al. (2024a)
Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness, and Jonathan Larson.
From local to global: A graph rag approach to query-focused summarization.
*arXiv preprint arXiv:2404.16130*, 2024a.
- Edge et al. (2024b)
Darren Edge, Ha Trinh, and Jonathan Larson.
Lazygraphrag: Setting a new standard for quality and cost, November 2024b.
Microsoft Research Blog, Published November 25, 2024.
- Fan et al. (2025)
Tianyu Fan, Jingyuan Wang, Xubin Ren, and Chao Huang.
Minirag: Towards extremely simple retrieval-augmented generation.
*arXiv preprint arXiv:2501.06713*, 2025.
- Gao et al. (2023)
Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yixin Dai, Jiawei Sun, Haofen Wang, and Haofen Wang.
Retrieval-augmented generation for large language models: A survey.
*arXiv preprint arXiv:2312.10997*, 2(1), 2023.
- Ghassel et al. (2025)
Abdellah Ghassel, Ian Robinson, Gabriel Tanase, Hal Cooper, Bryan Thompson, Zhen Han, Vassilis Ioannidis, Soji Adeshina, and Huzefa Rangwala.
Hierarchical lexical graph for enhanced multi-hop retrieval.
In *Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2*, pp. 4457–4466, 2025.
- Gospodinov et al. (2023)
Mitko Gospodinov, Sean MacAvaney, and Craig Macdonald.
Doc2query–: when less is more.
In *European Conference on Information Retrieval*, pp. 414–422. Springer, 2023.
- Gu et al. (2024)
Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, et al.
A survey on llm-as-a-judge.
*arXiv preprint arXiv:2411.15594*, 2024.
- Guo et al. (2025)
D. Guo, D. Yang, H. Zhang, et al.
Deepseek-r1 incentivizes reasoning in llms through reinforcement learning.
*Nature*, 645:633–638, 2025.
doi: 10.1038/s41586-025-09422-z.
URL [https://doi.org/10.1038/s41586-025-09422-z](https://doi.org/10.1038/s41586-025-09422-z).
- Guo et al. (2024)
Zirui Guo, Lianghao Xia, Yanhua Yu, Tu Ao, and Chao Huang.
Lightrag: Simple and fast retrieval-augmented generation.
*arXiv preprint arXiv:2410.05779*, 2024.
- Han et al. (2024)
Haoyu Han, Yu Wang, Harry Shomer, Kai Guo, Jiayuan Ding, Yongjia Lei, Mahantesh Halappanavar, Ryan A Rossi, Subhabrata Mukherjee, Xianfeng Tang, et al.
Retrieval-augmented generation with graphs (graphrag).
*arXiv preprint arXiv:2501.00309*, 2024.
- Honnibal et al. (2020)
Matthew Honnibal, Ines Montani, Sofie Van Landeghem, Adriane Boyd, et al.
spacy: Industrial-strength natural language processing in python.
2020.
- Lewis et al. (2020)
Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, et al.
Retrieval-augmented generation for knowledge-intensive nlp tasks.
*Advances in neural information processing systems*, 33:9459–9474, 2020.
- Min et al. (2025)
Congmin Min, Rhea Mathew, Joyce Pan, Sahil Bansal, Abbas Keshavarzi, and Amar Viswanathan Kannan.
Efficient knowledge graph construction and retrieval from unstructured text for large-scale rag systems.
*arXiv preprint arXiv:2507.03226*, 2025.
- Multi-Granularity (2024)
Multi-Linguality Multi-Functionality Multi-Granularity.
M3-embedding: Multi-linguality, multi-functionality, multi-granularity text embeddings through self-knowledge distillation, 2024.
- Nogueira et al. (2019)
Rodrigo Nogueira, Wei Yang, Jimmy Lin, and Kyunghyun Cho.
Document expansion by query prediction.
*arXiv preprint arXiv:1904.08375*, 2019.
- Peng et al. (2024)
Boci Peng, Yun Zhu, Yongchao Liu, Xiaohe Bo, Haizhou Shi, Chuntao Hong, Yan Zhang, and Siliang Tang.
Graph retrieval-augmented generation: A survey.
*arXiv preprint arXiv:2408.08921*, 2024.
- Qwen et al. (2025)
Qwen, :, An Yang, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jingren Zhou, Junyang Lin, Kai Dang, Keming Lu, Keqin Bao, Kexin Yang, Le Yu, Mei Li, Mingfeng Xue, Pei Zhang, Qin Zhu, Rui Men, Runji Lin, Tianhao Li, Tianyi Tang, Tingyu Xia, Xingzhang Ren, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yu Wan, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, and Zihan Qiu.
Qwen2.5 technical report, 2025.
URL [https://arxiv.org/abs/2412.15115](https://arxiv.org/abs/2412.15115).
- Raffel et al. (2020)
Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J Liu.
Exploring the limits of transfer learning with a unified text-to-text transformer.
*Journal of machine learning research*, 21(140):1–67, 2020.
- Reimers & Gurevych (2019)
Nils Reimers and Iryna Gurevych.
Sentence-bert: Sentence embeddings using siamese bert-networks.
*arXiv preprint arXiv:1908.10084*, 2019.
- Tang & Yang (2024)
Yixuan Tang and Yi Yang.
Multihop-rag: Benchmarking retrieval-augmented generation for multi-hop queries.
*arXiv preprint arXiv:2401.15391*, 2024.
- Team (2024)
Qwen Team.
Qwen2.5: A party of foundation models, September 2024.
URL [https://qwenlm.github.io/blog/qwen2.5/](https://qwenlm.github.io/blog/qwen2.5/).
- Wang et al. (2021)
Jianguo Wang, Xiaomeng Yi, Rentong Guo, Hai Jin, Peng Xu, Shengjun Li, Xiangyu Wang, Xiangzhou Guo, Chengming Li, Xiaohai Xu, et al.
Milvus: A purpose-built vector data management system.
In *Proceedings of the 2021 International Conference on Management of Data*, pp. 2614–2627, 2021.
- Yu et al. (2024)
Hao Yu, Aoran Gan, Kai Zhang, Shiwei Tong, Qi Liu, and Zhaofeng Liu.
Evaluation of retrieval-augmented generation: A survey.
In *CCF Conference on Big Data*, pp. 102–120. Springer, 2024.
- Yu et al. (2025)
Hui-Hung Yu, Wei-Tsun Lin, Chih-Wei Kuan, Chao-Chi Yang, and Kuan-Min Liao.
Graphrag-enhanced dialogue engine for domain-specific question answering: A case study on the civil iot taiwan platform.
*Future Internet*, 17(9):414, 2025.
- Zhang et al. (2025a)
Qinggang Zhang, Shengyuan Chen, Yuanchen Bei, Zheng Yuan, Huachi Zhou, Zijin Hong, Junnan Dong, Hao Chen, Yi Chang, and Xiao Huang.
A survey of graph retrieval-augmented generation for customized large language models.
*arXiv preprint arXiv:2501.13958*, 2025a.
- Zhang et al. (2025b)
Yujie Zhang, Weikang Yuan, and Zhuoren Jiang.
Bridging intuitive associations and deliberate recall: Empowering llm personal assistant with graph-structured long-term memory.
In *Findings of the Association for Computational Linguistics: ACL 2025*, pp. 17533–17547, 2025b.
- Zhao et al. (2025)
Yibo Zhao, Jiapeng Zhu, Ye Guo, Kangkang He, and Xiang Li.
Eˆ 2graphrag: Streamlining graph-based rag for high efficiency and effectiveness.
*arXiv preprint arXiv:2505.24226*, 2025.

## Appendix A Dataset Statistics

#### LiHuaWorld.

LiHuaWorld is an English dialogue dataset comprising one year of conversational records from a virtual user, spanning diverse daily-life topics such as social interactions, fitness, entertainment, and personal affairs. It contains 442 documents and 637 queries, including 506 single-hop, 66 multi-hop, and 65 unanswerable (null) questions. Each query is paired with manually annotated answers and supporting documents, allowing fine-grained evaluation of both retrieval and reasoning.

#### MultiHop-RAG.

MultiHop-RAG is a news-based multi-hop QA dataset constructed from English news articles. It consists of 609 documents and 2,556 queries with ground-truth answers and supporting evidence.
We use the first 500 queries as the test set, primarily to ensure computational feasibility and enable extensive ablation studies, while maintaining coverage across query types.
Queries are categorized into Inference (153), Comparison (181), Temporal (100), and Null (66) types.

Together, these datasets provide complementary evaluation scenarios: LiHuaWorld targets long-term personal memory QA, while MultiHop-RAG emphasizes news-based multi-hop reasoning.

## Appendix B Implementation Details

### B.1 Embedding Model Settings

We employed pre-trained sentence embedding models from the Sentence-Transformers(^5^55[https://huggingface.co/sentence-transformers](https://huggingface.co/sentence-transformers)) library for encoding text segments. Unless otherwise specified, the default model is all-MiniLM-L6-v2, which produces 384-dimensional embeddings. This model is lightweight and optimized for efficiency, making it suitable for large-scale retrieval scenarios.
For comparison, we also experimented with all-mpnet-base-v2, a stronger encoder that outputs 768-dimensional embeddings. While this model provides higher representational capacity and improved semantic alignment, it incurs increased computational and memory costs.
Both models were applied in a zero-shot manner without task-specific fine-tuning. During retrieval, embeddings were $\ell_{2}$-normalized before similarity computation to ensure stable and consistent cosine similarity scores.

### B.2 LLM Settings

All large language models (LLMs) were accessed via the BaiLian(^6^66[https://bailian.console.aliyun.com/](https://bailian.console.aliyun.com/)) API platform with default generation parameters: $temperature=0.7$, $top_p=0.8$, $top_k=20$, $max_input_tokens=129{,}024$, and $max_tokens=8{,}192$.
For query generation, question answering, and evaluation, we primarily employed Qwen2.5-72B-Instruct. For comparison, we also considered Qwen2.5-3B-Instruct in query-centric graph construction. The 72B model was mainly applied to computationally intensive tasks requiring stronger reasoning capacity and long-context processing.
Unless otherwise specified, all models were used in a zero-shot setting without task-specific fine-tuning.

### B.3 QCG-RAG Hyperparameters

We report the default hyperparameter settings for each dataset and the candidate search ranges considered during tuning.

#### Default Values.

For the LiHuaWorld dataset, we set $M=20$, $\alpha=80\%$, $h=1$, $k=2$, $n=10$, and $\gamma=1.5$.
For the MultiHop-RAG dataset, we set $M=20$, $\alpha=80\%$, $h=1$, $k=3$, $n=15$, and $\gamma=1.0$.

#### Candidate Ranges.

The hyperparameters were selected from the following ranges:
$\alpha\in\{20\%,40\%,60\%,80\%,100\%\}$,
$k\in\{1,\ldots,5\}$,
$h\in\{0,1,2\}$,
$n\in\{5,10,15,20\}$,
and $\gamma\in\{1.0,1.5\}$.
Here, $M$ is the number of generated queries per chunk, $\alpha$ controls the query truncation ratio, $h$ denotes the number of retrieval hops, $k$ specifies the number of retrieved query nodes, $n$ is the number of neighbors per node, and $\gamma$ is the similarity threshold.
Unless otherwise specified, reported results correspond to the default settings.

## Appendix C LLM Prompts

We show LLM prompts for query generation and answer evaluation, including Doc2Query Prompt, Response Generation Prompt, and Evaluation Prompt.

### C.1 Doc2Query Prompt

To generate diverse supervision signals for query-centric graph construction, we adopted a standardized Doc2Query prompt. This prompt instructs the model to produce multiple distinct queries from each text chunk, along with exact answers grounded in the chunk. The full prompt is shown in Prompt [C.1](https://arxiv.org/html/2509.21237v1#A3.SS1).

### C.2 Response Generation Prompt

To guide model responses grounded in tabular data, we employed a standardized prompt that specifies the assistant’s role, objective, and the required response length and format. The full prompt is shown in Prompt [C.2](https://arxiv.org/html/2509.21237v1#A3.SS2).

### C.3 Evaluation Prompt

To ensure consistent and transparent evaluation of candidate answers
generated by retrieval-augmented generation (RAG), we employed a standardized
prompt for judgment. The prompt specifies the evaluation role, criteria, and
output format, focusing on factual accuracy and completeness.
The full evaluation prompt is shown in Prompt [C.3](https://arxiv.org/html/2509.21237v1#A3.SS3).

## Appendix D Case Studies

### D.1 A Case Study on LiHuaWorld

We present an example of question answering with supporting evidence chunks on LiHuaWorld in Example [D.1](https://arxiv.org/html/2509.21237v1#A4.SS1). From the example, it can be observed that the supporting evidence chunks “20261219_19:00-0”, “20261220_20:00-0”, and “20261228_10:00-0” provide only one part of the answer, namely “LiHua,” whereas “20261221_12:00-0” contains all answer entities: “LiHua,” “Chae Song-hwa,” and “Yuriko Yamamoto.”

#### Naive RAG on LiHuaWorld.

We provide an illustrative example of a query–answer evaluation case produced by Naive RAG. The instance is shown in Use Case [D.1](https://arxiv.org/html/2509.21237v1#A4.SS1.SSS0.Px1).
From the use case, it can be observed that Naive RAG, in its Top-5 chunk ranking, retrieved only “20261219_19:00-0” and “20261228_10:00-0,” which record conversations between Wolfgang Schulz and Li Hua about the Hong Kong trip, and thus evidently produced an incorrect answer.

#### QCG-RAG on LiHuaWorld.

We also provide an illustrative example of a query–answer evaluation case produced by our proposed QCG-RAG. The instance is shown in Use Case [D.1](https://arxiv.org/html/2509.21237v1#A4.SS1.SSS0.Px2).
In addition, the generated Query+Answer text information corresponding to
topk_qids and extra_qids_via_knn is presented in the
Detail section.
The q_id consists of a document ID $x$, a chunk ID $y$, and a
generation index $z$, in the format “$x$-$y$-$z$” (by default, 20 queries
are generated, so $z\in[0,19]$). For example,
“20261221_12:00-0-1” denotes the chunk “20261221_12:00”,
with “0” as the chunk ID and “1” as the generation index.

From the use case, it can be seen that QCG-RAG, by directly retrieving
generated Query+Answer pairs, can accurately match those produced by the
“20261219_19:00-0,” and “20261228_10:00-0” chunks,
as well as the query associated with the chunk “20261221_12:00-0” that
contains all correct answers:

> {"q_id": "20261221_12:00-0-14", "query": "What does Yuriko Yamamoto say about Wolfgang’s trip?", "answer": "Aww, Wolfgang, we’ll miss you! But safe travels!"}

Furthermore, through one-hop expansion on the query-centric graph (QCG), it can additionally
retrieve another query from the same chunk:

> {"q_id": "20261221_12:00-0-12", "query": "What does Wolfgang say about catching up after his trip?", "answer": "I’ll be eager to catch up once I’m back and hear all the new stuff!"}

This enables the relevance score of “20261221_12:00-0” to be further
enhanced in subsequent chunk ranking.

### D.2 A Case Study on MultiHop-RAG

We present an example of question answering with supporting evidence chunks on MultiHop-RAG in Example [D.2](https://arxiv.org/html/2509.21237v1#A4.SS2). The example question is of the type “comparison query,” which requires leveraging two long documents, “doc-451” and “doc-167,” to answer. Each document can be segmented into multiple chunks, with each chunk containing no more than 1200 tokens.

#### Naive RAG on MultiHop-RAG.

We provide an illustrative example of a query–answer evaluation case
produced by Naive RAG. The instance is shown in Use Case [D.2](https://arxiv.org/html/2509.21237v1#A4.SS2.SSS0.Px1). From the
experimental results, Naive RAG failed to retrieve the correct article
segment “doc-451” using the keywords ‘‘The Age’’ article
and Australia’s Davis Cup team. Instead, it only captured
“doc-167-chunk-0,” which led to a misinterpretation during the
comparison process: the target entity “Australia’s Davis Cup Team” was
mistakenly understood as “Australian Rugby (Wallabies).”

#### QCG-RAG on MultiHop-RAG.

Use Case [D.2](https://arxiv.org/html/2509.21237v1#A4.SS2.SSS0.Px2) shows an example of a query–answer evaluation case by QCG-RAG. From the results, QCG-RAG effectively retrieved queries associated with evidences “doc-451” and “doc-167”, and through query-centric graph reasoning, obtained additional queries linked to “doc-167”. Based on the retrieved chunk context information,
QCG-RAG was able to correctly and effectively identify the comparison entities and contents: “Australia’s Davis Cup Team” vs. “South Africa National Rugby Team.”

## Peer Reviews

confidence: 4
contribution: 2
initial_rating: 2
presentation: 3
questions: How does your algorithm work on other datasets and comparing with other baselines?

How does the algorithm perform on large datasets?

How do you control the precision and recall of the retrieved passages with theoretically bounded error rates.
soundness: 2
strengths: 1. Well motivated.

The granularity trade-off in graph-RAG is a timely issue, as highlighted in recent works (e.g., GraphRAG). The paper correctly identifies limitations like high token costs in entity extraction and semantic loss in coarse graphs. These are practical challenges when applying graphRAG algorithms in realworld scenarios.

2. Clear Presentation.

The introduction and methodology sections are structured logically, with formal definitions and a helpful overview figure. Ablations on node formulations provide some insight into design choices.
summary: This paper aims to address the "granularity dilemma" in graph-based RAG methods, and proposes Query-Centric Graph Retrieval-Augmented Generation (QCG-RAG). QCG-RAG uses extended Doc2Query techniques to query-answer pairs as augmented query graph for enhancing retrieval. Retrieval involves multi-hop expansion over this graph to identify relevant chunks.

Experiments on two datasets (MultiHop-RAG, Lihuaworld)  claim superior accuracy over baselines like graphRAG and NaiveRAG.
weaknesses: 1. Limited Novelty.

The core contribution *using Doc2Query-generated queries as graph nodes* is not sufficiently original for ICLR. Doc2Query and Doc2Query-- are established document expansion techniques, and their integration with graphs feels like a straightforward, engineered combination rather than a breakthrough. The "query-centric" framing is appealing but overstates the innovation; it's essentially a hybrid index, not a "new paradigm" as claimed.

2. Technical Defects.

- The similarity function in retrieval (s(qu, q) = sim(qu, q) + ε, with ε=1) is ad-hoc and lacks motivation—why add a constant bias?
- The graph construction uses KNN for edges but doesn't discuss scalability (e.g., for large corpora, O(N^2) similarity computations could be prohibitive).
- Efficiency analysis are not give, what is the complexity (token cost, indexing time, retrieval time)of the algorithm on large algorithm? 
- Hyperparameters (e.g., α=80%, h=1, k=2-3, γ=1.0-1.5) are dataset-specific and tuned aggressively, potentially overfitting to benchmarks.
- False statement or clarity issue: (1) the begining of the introduction (line 26) "RAG has become a standard approach for improving the factuality of LLMs....." is not true, there are many ways, e.g. fintuning, or knowledge editing. (2)  "Controllable granularity" is overused without precise definition.


3. Empirical Shortcomings.

- Datasets are limited to two (LiHuaWorld, MultiHop-RAG). While Lihuaworld is not a widely-used datasets. Other popular RAG datasets such as Musique and HotpotQA are not included. Plz see HippoRAG[1] for the dataset details.
- Baselines are cherry-picked. Only naive RAG and several GraphRAG with poor performance (comparable to or worse than Naive RAG) are included. All state-of-the-art graphRAG algorithms (HippoRAG[1], HippoRAG2[2], GFM[3], Raptor[4], E^2GraphRAG[5], LogicRAG[6]) are missing.
- No efficiency validation is given. 
- No idea how the performance will be when the corpora become large. The edges are built based on similarity, so the *similary queries* can become overwhelming and densely connected, which can be disaster for the graph-expansion based retrieval: the recalled passages can be overloaded and noisy.






---
References

- [1] HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models, Neurips'24
- [2] From RAG to Memory: Non-Parametric Continual Learning for Large Language Models NeurIPS'25
- [3] GFM-RAG: Graph Foundation Model for Retrieval Augmented Generation, NeurIPS'25
- [4] RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, neurips'24
- [5] E^2GraphRAG: Streamlining Graph-based RAG for High Efficiency and Effectiveness, arxiv'25
- [6] You Don't Need Pre-built Graphs for RAG: Retrieval Augmented Generation with Adaptive Reasoning Structures, arxiv'25

---

confidence: 5
contribution: 3
initial_rating: 4
presentation: 3
questions: The quality of queries generated by different models — as well as the varying preferences of different retrievers toward these queries — would intuitively have a significant impact on the proposed method. I believe this is a necessary analysis with important practical and methodological implications.
soundness: 2
strengths: **Good presentation:** This work is easy to read and follow.

**Clear motivation:** The motivation of the QCG-RAG framework is clear, and it proposes an innovative solution for RAG on QCG.
summary: This paper presents the QCG-RAG framework, which follows Doc2Query and Doc2Query-- to build a query-centric graph (QCG) and address the granularity issue in graph-based methods, significantly enhancing retrieval for multi-hop reasoning tasks. Experimental results show that QCG-RAG achieves good performance on the LiHuaWorld and MultiHop-RAG datasets.
weaknesses: **Limited Dataset:** The paper only evaluates the model on LiHuaWorld and MultiHop-RAG datasets. While these datasets are useful, they are not sufficient to demonstrate the framework's generalizability across a broader range of tasks. **It is necessary to use more multi-hop reasoning datasets to verify the claim of "enhancing retrieval for multi-hop reasoning tasks" and show the framework's applicability across various contexts.**

**Insufficient Comparison with Multi-Hop RAG Baselines**: Although QCG-RAG performs well in multi-hop reasoning, **the baselines used for comparison are still focused on single-hop scenarios**. To highlight the claimed advantages of QCG-RAG in multi-hop reasoning, it is necessary to include comparisons with other multi-hop RAG methods to demonstrate the superiority of this method in multi-hop reasoning tasks.

**Lack of Cost Analysis:** The paper does not provide an analysis of the computational cost, particularly for large-scale corpora. Given that QCG-RAG involves huge amount of synthetic query generation for all chunks, the computational overhead could be substantial. **It would be good to include a cost analysis and compare it with the baseline methods, especially under different corpus sizes. Without this comparison, discussing effectiveness alone is somewhat unfair, and the practical value of the method remains unclear.**

---

confidence: 3
contribution: 3
initial_rating: 6
presentation: 4
questions: Q1: How does the concept extraction method handle polysemous words or concepts that may have different meanings in different contexts?

Q2: What is the computational complexity of constructing the concept graph, especially for large-scale corpora?

Q3: The dual-path retrieval strategy combines results from both concept graph and core-KG, but how do you ensure that the retrieved information is complementary rather than redundant? What mechanisms are in place to handle potential conflicts between the two retrieval paths?
soundness: 3
strengths: S1: The paper introduces an innovative Graph-Guided Concept Selection (G2ConS) framework that effectively addresses the prohibitive cost issue in GraphRAG construction. The core chunk selection method reduces construction costs by up to 80% while maintaining competitive performance, making GraphRAG more practical for real-world deployment.

S2: The dual-path retrieval strategy combining both knowledge graph and concept graph is well-designed. The concept graph provides LLM-independent retrieval capabilities that can fill knowledge gaps introduced by chunk selection, while the weighted ensemble mechanism balances granularity differences between the two retrieval paths.

S3: The paper provides solid empirical validation through comprehensive experiments on multiple multi-hop QA benchmarks (MuSiQue, HotpotQA, 2WikiMultiHopQA), demonstrating consistent improvements across different metrics. The concept deletion ablation study provides valuable insights into the importance of different knowledge components.

S4: The method shows excellent compatibility with existing GraphRAG approaches (MS-GraphRAG, LightRAG, etc.), making it a practical plug-and-play solution rather than requiring complete system redesign. This generalizability is crucial for real-world adoption.
summary: This paper presents Graph-Guided Concept Selection (G2ConS), a novel framework for efficient retrieval-augmented generation that addresses the prohibitive construction costs of GraphRAG systems. The method introduces a dual-path retrieval strategy combining a core knowledge graph (built from selected chunks) with an LLM-independent concept graph to balance cost efficiency and retrieval effectiveness. Through concept deletion experiments, the authors demonstrate that certain concepts are more important for multi-hop reasoning, leading to a core chunk selection method that reduces construction costs by up to 80% while maintaining competitive performance. The approach is evaluated on multiple multi-hop QA benchmarks and shows compatibility with existing GraphRAG frameworks.
weaknesses: W1: The paper lacks sufficient theoretical analysis of why the proposed concept graph construction and dual-path retrieval strategy works. While empirical results are promising, the theoretical foundations for concept importance ranking using PageRank and the optimal combination of concept graph and core-KG are not well established.

W2: The method introduces multiple hyperparameters (θsem, θco, κ, λ, k, N) that require careful tuning, potentially making it difficult to generalize across different domains and datasets.

W3: The evaluation is limited to multi-hop QA tasks on relatively small datasets (500 QA pairs each). The scalability and effectiveness of the approach on larger, more diverse corpora and different types of reasoning tasks remain unclear.

---

confidence: 4
contribution: 3
initial_rating: 6
presentation: 3
questions: Q1: To follow up on my point in the weaknesses: in Section 3.4, Step 1, when you compute similarity $s
(q_u, q)$, is $q_u$ being compared to the embedding of the query $q$ alone, or to the embedding of the concatenated query-answer pair $q \oplus a$?

Q2: This reviewer suggests the authors to provide more detail on the construction cost? Specifically, how many total tokens or how
much time did it take to build the graphs for the two datasets using the 72B model? How does this cost compare to the GraphRAG baseline's extraction process?

Q3: The optimal hyperparameters ($k, n, \gamma$) were different across the two datasets. How sensitive is the model to this? What happens if you run the LiHuaWorld experiment using the best parameters from MultiHop-RAG, and vice-versa? This reviewer is curious about how generalizable these settings are.

Q4: Figure 4 is really interesting. "QCG w/ Answer" performs much worse than "QCG w/ Query," and both are worse than the full Query+Answer model. What's your intuition for this? Why are the answers alone so bad as retrieval nodes?

Q5: This reviewer is interested to know the rationale of using these two datasets instead of the commonly adopted QA datasets like 2WikiMQA, HotpotQA, and MuSiQue.
soundness: 3
strengths: Novel Graph Construction: The main strength is the novel query-centric graph (QCG) construction. Building the graph from synthetic QA pairs is a smart way to get a semantically-rich, intermediate-
granularity index that is "controllable".

Strong Empirical Performance: The method puts up strong numbers, consistently beating baselines on
two different benchmarks. It's especially good on the multi-hop subsets (e.g., 62.12% vs 57.58% on LiHuaWorld multi-hop), which directly backs up the authors' claims about their multi-hop retrieval design.

Thorough Ablation Studies: The ablation studies are comprehensive. The authors did a good job validating their design choices, especially in Figure 4 (showing Query+Answer nodes are best) and in analyzing the impact of all the new hyperparameters (Figures 5, 6).
Clarity and Case Studies: The paper is just very clearly written. The detailed case studies in Appendix D give good qualitative insight into why the method works for multi-hop queries when Naive RAG fails.
summary: This paper presents QCG-RAG, a new graph-RAG framework aimed at solving the "granularity dilemma" in existing methods. The authors' main point is that current methods are stuck in a trade-off: entity-level graphs are too costly and lose context, while document-level graphs miss important details.

The paper's core idea is a "query-centric graph" (QCG) built at an intermediate granularity. They use Doc2Query and Doc2Query to generate query-answer (QA) pairs from text chunks, and these high-quality QA pairs become the nodes in the graph. Edges then connect nodes based on semantic similarity ($E_{intra}$) or link nodes back to their source chunks ($E_{inter}$). The retrieval process then works on this graph, finding relevant query nodes, expanding to neighbors for multi-hop reasoning, and finally gathering the underlying text chunks for the LLM. Experiments on LiHuaWorld and MultiHop-RAG show their method beats other chunk-based and graph-based RAGs.
weaknesses: High Construction Cost: The graph construction seems to be expensive. The best results require generating $M=20$ queries per chunk using a 72B model (Qwen2.5-72B-Instruct) The ablation (Figure 4) shows that using a smaller 7B model hurts performance. This reliance on a massive generator model is a big practical drawback for scaling this up to large datasets, as the authors also note.

Hyperparameter Sensitivity: The method introduces a lot of new hyperparameters ($M$, $\alpha$, $h$, $k$, $n$, and $\gamma$) . The ablation plots (Figures 5, 6) show performance can be pretty sensitive to $k$ (neighbors) and $n$ (max nodes). A bigger concern is that the optimal settings were different for the two datasets (e.g., $k=2, n=10, \gamma=1.5$ for LiHuaWorld vs. $k=3, n=15, \gamma=1.0$ for MultiHop-RAG). This suggests that the method might need a lot of careful, dataset-specific tuning, which makes it harder to apply to out-of-domain scenarios.

Ambiguity in Retrieval Similarity: This reviewer finds Section 3.4 a bit unclear on one point. The graph nodes $q$ are
defined as the concatenated $q \oplus a$ pairs . But in Step 1 of retrieval, the paper says it computes $sim(q_u, q)$. Is the user query $q_u$ being compared against the full $q \oplus a$ embedding, or just Novel Graph Construction: The main strength is the novel query-centric graph (QCG) construction. Building the graph from synthetic QA pairs is a smart way to get a semantically-rich, intermediate-
granularity index that is "controllable".


Decision: Reject