Thank you very much for your time and effort in reviewing our paper. We sincerely appreciate your feedback. Below, we respectfully provide our detailed responses to address your concerns.

Q1: "The main concerns lie in the evaluation setup. It seems to me that the knowledge sources from each domain are just several documents, and this is quite different to real-world scenarios."

• We sincerely thank the reviewer for highlighting this important concern regarding the evaluation setup. We would like to clarify and justify our choice of knowledge sources and their scale as follows.
• First, to ensure fair comparison with existing GraphRAG baselines, we adopt the same knowledge construction settings used in LightRAG and PathRAG, both of which are based on domain-specific corpora derived from the UltraDomain benchmark. These corpora each contain over 1 million tokens, covering technical content across diverse verticals, and are widely regarded as a reasonable approximation of structured domain knowledge for research purposes.
• Second, to better reflect real-world deployment scenarios, we additionally introduce an application-level medical dataset. In collaboration with medical experts specializing in hypertension, we constructed a new Medicine benchmark using official clinical guidelines as the sole knowledge source. This ensures that the retrieval and generation processes closely simulate real-world use in high-stakes settings, and the resulting setup has been positively validated by our professional clinical partners.
• Furthermore, our system is designed to be highly accessible in practical usage. Users can easily input their own knowledge in plain text, and HyperGraphRAG automatically constructs a hypergraph representation for enhanced retrieval and generation. This makes it a practical solution for building personal knowledge bases or LLM-powered QA systems that leverage structured knowledge without manual annotation or ontology design.
• Together, these choices strike a balance between experimental comparability and realistic applicability, and we hope this clarification addresses the reviewer’s concern.

Q2: "It is questionable whether the method can be generalized to scenarios where we have a much bigger knowledge source (e.g., wikipedia), and there may also be efficiency problems if we would like to construct a hypergraph from a big corpus."

• We appreciate the reviewer’s concern regarding the scalability of HyperGraphRAG to large-scale knowledge sources. To address this, we provide quantitative evidence and clarify the design philosophy of our system.

• As shown in Table 3, constructing a hypergraph from 1,000 tokens takes 3.084 seconds and costs $0.0063 for HyperGraphRAG. This is significantly faster than GraphRAG (9.272 s) and LightRAG (5.168 s), and comparable to HippoRAG2 (2.758 s). These results indicate that the construction efficiency of HyperGraphRAG is already on par with or even more efficient than existing structured GraphRAG baselines under the same settings.
• It is also important to note that our construction process is fully preprocess and supports incremental updates and cache reuse. This ensures that once constructed, the knowledge base can be efficiently maintained and scaled without repeated cost, and further allows knowledge to continuously accumulate and be refined over time, offering long-term value in real-world deployment.
• Moreover, to further address large-scale use cases, we acknowledge that lighter and faster alternatives can be used. For example, combining NER and semantic chunking with small models can enable efficient, zero-cost hypergraph construction without relying on LLM inference. This lightweight method is enabled by the inherent advantages of the hypergraph representation and represents a promising direction for future work.
• In summary, HyperGraphRAG achieves a practical balance between expressiveness and construction efficiency. It matches or exceeds the scalability of existing binary relational GraphRAG methods and offers extensibility to both high-fidelity and lightweight settings.

Q3: "Since the question samples are constructed by the author themselves and there is no clear explanation for this process, I would challenge if the question construction itself benefits the hypergraphRAG and thus leading to better performance comparing with baseline methods."

• We thank the reviewer for the insightful concern regarding the fairness of question construction. To ensure a rigorous and balanced evaluation, we tried to follow the common setups established in LightRAG and PathRAG, which evaluate generation quality by prompting GPT-based models to rank different outputs in a pairwise comparison.
• However, we observed a key limitation in such AB-test-based evaluation: when two generations are close in quality, the choice of LLM becomes unstable, and the result heavily depends on the order in which the outputs are presented in the prompt for comparison. In practice, we found that GPT often favors the first response, even when the second one is equally or more accurate. This issue undermines evaluation fairness, especially when comparing strong baselines.
• To address this, we adopted a more principled evaluation setup inspired by FlashRAG, which ensures both automatic generation and objective supervision. Specifically, take a two-hop question, we:

1. First randomly sample a knowledge sentence from the knowledge context.
2. Then apply NER to extract all entities from this sentence.
3. One entity is randomly selected, and then another sentence in the knowledge context containing this entity is retrieved.
4. These two sentences jointly form the knowledge context of this sample, from which an LLM generates both a question and a golden answer.

• This process is model-agnostic and automatic, ensuring no bias toward HyperGraphRAG, and faithfully reflects the structure of multi-hop questions grounded in real-world domain knowledge. Why does HyperGraphRAG outperform other baselines? We attribute this to several key factors: HyperGraphRAG’s hyperedges not only model knowledge involving multiple related entities, but also significantly reduce semantic loss. At the same time, its hypergraph structure captures complex relationships between entities, which boosts retrieval efficiency. We provide detailed theoretical proofs in Appendix B.3.
• In addition, to ensure a comprehensive and fair comparison, we evaluate each method across three complementary dimensions:

1. Answer F1 score with respect to golden answers.
2. Retrieval quality based on semantic similarity with relevant ground-truth sentences.
3. Score-based generation assessment by LLM-as-a-Judge over multiple axes such as faithfulness, coherence, and relevance.

• The example shown in Figure 8 is a case generated by this standardized protocol with question, knowledge context, and golden answer:

{
  "question": "What type of renal denervation has been shown to demonstrate BP-lowering efficacy over 24 hours in several randomized, sham-controlled trials, particularly for resistant hypertension?",
  "golden_answers": [
    "ULTRASOUND RENAL DENERVATION"
  ],
  "context": [
    "Several randomized, sham-controlled trials have been published, demonstrating a BP-lowering efficacy over 24h.",
    "As discussed in Section 8.6.1, several randomized, sham-controlled trials have been published, demonstrating a BP-lowering efficacy over 24h for radiofrequency and ultrasound renal denervation in a broad spectrum of hypertension, including resistant hypertension."
  ],
  "nary": 3,
  "nhop": 2
}

Q4: "Some technique details are not well explained: (1) It is unclear how v^{score} in line 145 and e^{score}H in line 153 are calculated. (2) It is questionable how the similarity calculation between two vectors of different dimensions (h{V_q} and h_v) is performed in line 143."

• We thank the reviewer for the detailed and constructive feedback. We address both concerns below:

1. Clarification of $v^{\text{score}}$ and $e_H^{\text{score}}$:
   As described in Section 4.1, both scores are generated by the LLM during the entity and relation extraction stage. Specifically, the LLM outputs a confidence score for each extracted entity $v$ and hyperedge $e_H$, which we denote as $v^{\text{score}}$ and $e_H^{\text{score}}$. These scores represent the model’s confidence in the extracted components. An example of this LLM output, including such scores, is shown in Figure 3.
2. Similarity between $h_{V_q}$ and $h_v$:
   The query vector $h_{V_q}$ is obtained by concatenating all extracted entity mentions into a single string, then encoding it with a retriever encoder. Each entity $v$ in the entity vector base is similarly stored as a single string and encoded using the same encoder. As a result, both $h_{V_q}$ and $h_v$ reside in the same vector space and have identical dimensions, making the similarity calculation valid.

• We will update the manuscript to clarify these implementation details and prevent further ambiguity. Thank you again for pointing out these important aspects.

At last, we sincerely appreciate your valuable feedback, and we will carefully consider all your suggestions to further improve our paper. We would be deeply grateful if you could kindly reconsider raising the score to 4 or above. Thank you very much!

Thank you for your comment, and we fully understand and respect your concern.

• We would like to note that the evaluation dataset was constructed in a completely random and method-agnostic manner. It builds on prior RAG evaluation setups, where knowledge fragments were randomly sampled and paired with questions using consistent procedures across all methods, without introducing any bias toward HyperGraphRAG or any specific approach.

• In addition to generation quality, we also evaluate retrieval and grounding via three complementary dimensions: F1 for answer accuracy, R-Similarity for retrieval relevance, and G-Evaluation using LLM-as-a-judge to measure generation quality. In this way, we aim to provide a more holistic view of system performance beyond generation alone.

Thank you for your perspective. We will improve the presentation and clarify our evaluation implementation.

Thank you very much for your time and effort in reviewing our paper. We sincerely appreciate your feedback. Below, we respectfully provide our detailed responses to address your concerns.

W1: "The evaluation benchmark may create questions that are too neatly aligned with the structure of the knowledge graph."

• We appreciate the reviewer’s thoughtful observation. Indeed, a key limitation in prior works such as LightRAG and PathRAG lies in the evaluation protocol itself: they typically rely on prompting LLMs to compare outputs in a pairwise format. We also tried this AB-testing setup but observed that it can produce biased results, especially when generations are of similar quality. For instance, GPT tends to prefer the first response in the prompt, regardless of actual content quality, making the evaluation unstable and sensitive to formatting order.
• To address these concerns, we use the same knowledge construction settings but a different evaluation for accuracy and generation quality. Our benchmark is not constructed based on any pre-existing knowledge graph, nor does it assume or enforce alignment with the hypergraph structure used by HyperGraphRAG. Instead, we adopt a fully automatic, model-agnostic construction process inspired by FlashRAG to ensure objectivity and neutrality in evaluation.
• Concretely, take a two-hop QA as an example, the process involves:
  1. Randomly sampling a knowledge sentence from the domain-specific corpus.
  2. Using NER to extract entities from this sentence.
  3. Selecting one entity and finding another sentence that contains it.
  4. Feeding both sentences into an LLM to generate a multi-hop question and a corresponding golden answer.
• This ensures that questions are grounded in real domain knowledge, but not artificially aligned to favor any retrieval strategy. HyperGraphRAG outperforms other baselines because its hyperedges not only model knowledge involving multiple related entities, but also significantly reduce semantic loss. At the same time, its hypergraph structure captures complex relationships between entities, which boosts retrieval efficiency. We provide detailed theoretical proofs in Appendix B.3.
• Finally, our evaluation protocol includes three complementary metrics:
  • Answer F1 to measure factual correctness.
  • Retrieval similarity to assess grounding.
  • LLM-as-a-judge scoring over coherence, relevance, and faithfulness.
• Together, these components ensure a comprehensive and unbiased evaluation, and we believe they better reflect the performance of retrieval-augmented generation systems in practical settings. We thank the reviewer again for encouraging us to clarify this important point.

W2: "The competing graph-based RAG methods consistently underperform the StandardRAG baseline, which might suggest that the implementations or hyperparameters used for these baselines were not fully optimized."

• We thank the reviewer for raising this important point. To ensure fair comparison, we implemented all competing methods based on the official LightRAG codebase, which provides an excellent GraphRAG framework. Our implementations retain nearly all original hyperparameters and configurations from LightRAG for HyperGraphRAG and baselines, so as to ensure consistency across methods. We also release the full implementation details and baseline configurations in Appendix G, Table 4, to support fairness.
• Regarding the observation that graph-based RAG methods underperform StandardRAG, this is a newly well-discussed insight also discussed in several recent works. As several studies have noted, binary-relation-based GraphRAG methods may not always outperform chunk-based RAG under fair evaluations, especially on tasks that require rich semantic grounding. Because they often suffer from semantic loss, where the decomposition of multi-entity facts into pairwise triples leads to substantial information loss.
• This is precisely where HyperGraphRAG provides an advantage: by modeling n-ary relations as natural language hyperedges, it preserves semantic completeness while still supporting structured graph-based retrieval. This overcomes the expressive limitations of traditional GraphRAG and demonstrates greater potential in domains that demand both relational accuracy and retrieval efficiency.

Q1: "Following W1, do you ever try to evaluate the method on existing QA datasets such as those used by HippoRAG2?"

• We thank the reviewer for this insightful question. While our main paper focuses on domain-specific knowledge-intensive scenarios, we have conducted a follow-up experiment on six general-domain QA datasets adopted in HippoRAG2, including 2Wiki, HotpotQA, Musique, NQ, PopQA, and TriviaQA.

• As shown in the table below, HyperGraphRAG usually outperforms other graph-based RAG baselines across most datasets and metrics. This validates its general retrieval and generation capabilities.
• However, we note that these datasets may lack high-order relations or structured n-ary knowledge, which are key to the hypergraph paradigm. For this reason, they were not included in the main paper, as they do not fully reflect the design motivation of HyperGraphRAG. Nonetheless, we believe this additional evidence demonstrates the broader potential of our approach.

Q2: "Could you provide more detail on the implementation and hyperparameter tuning for these baselines to ensure fair comparison?"

• We thank the reviewer for pointing this out. To ensure rigorous and fair comparison, we strictly followed the LightRAG open-source implementation and preserved the original hyperparameters and retrieval modules for all baselines. Our evaluation adopts a unified configuration across all methods as summarized below:

• To ensure fair comparison during answer generation, we observed that GraphRAG and similar graph methods are highly sensitive to prompt formatting. To eliminate such confounding factors, we use the same generation prompt for all methods, as shown below:

---Role---
You are a helpful assistant responding to questions based on given knowledge.

---Knowledge---
{d['knowledge']}

---Goal---
Answer the given question.
You must first conduct reasoning inside <think>...</think>.
When you have the final answer, you can output the answer inside <answer>...</answer>.

Output format for answer:
<think>
...
</think>
<answer>
...
</answer>

---Question---
{d['question']}

• This unified prompt encourages consistent zero-shot CoT reasoning and avoids format-induced performance differences.

• Why Some GraphRAG Baselines Underperform?

  • Despite fair implementation and tuning, binary-relation-based GraphRAG baselines often suffer from semantic loss during knowledge encoding. Each edge in a binary graph only captures limited pairwise relations, which can fragment original facts and introduce ambiguity or redundancy during retrieval.
  • In contrast, HyperGraphRAG encodes n-ary relations as natural-language hyperedges, preserving full semantic granularity. This leads to better alignment between retrieval and generation, resulting in more faithful and context-complete answers. We also provide theoretical proof in Appendix B.3.

At last, we sincerely appreciate your valuable feedback, and we will carefully consider all your suggestions to further improve our paper. We would be deeply grateful if you could kindly reconsider raising the score further. Thank you very much!

Thank you very much for your time and effort in reviewing our paper. We sincerely appreciate your feedback. Below, we respectfully provide our detailed responses to address your concerns.

Q1: "Systemic Risks Arising from the Method: While conceptually novel, the proposed method makes a significant trade-off. The system functions more as a sophisticated context retriever than as a knowledge base with precise and logical representations."

• We sincerely thank the reviewer for this insightful comment. We would like to clarify that HyperGraphRAG is not a significant trade-off but aims to combine both advantages of the structural rigor of traditional knowledge graphs and the contextual flexibility of RAG systems, while overcoming the limitations of both.
• On the one hand, traditional knowledge graphs, typically based on binary (head, relation, tail) triples, often fail to represent n-ary relations naturally. For example, a fact like
  "Drug X lowers blood pressure in elderly patients with chronic kidney disease"
  must be split into several disconnected triples, potentially losing contextual integrity.
• On the other hand, RAG methods that retrieve raw text chunks lack an explicit structural representation and cannot model relationships between entities, leading to redundant or semantically incoherent retrievals.
• HyperGraphRAG addresses both limitations by encoding each multi-entity fact as a natural language hyperedge, forming a hypergraph where nodes are entities and edges are complete n-ary semantic units. This preserves semantic completeness while maintaining a structured representation.
• As shown in Appendix B.1, we formally prove that our hypergraph representation is both semantically lossless and structurally grounded. For example, a clinical statement like: "In patients with resistant hypertension, ultrasound renal denervation reduces 24-hour BP."
  becomes a hyperedge connecting treatment, patient, and effect, fully modeling the medical fact as a 3-ary connected and queryable unit.
• Moreover, the use of LLMs for n-ary relation extraction enables efficient and scalable construction. This approach has shown strong consistency in prior work and significantly reduces the overhead of manual annotation. Importantly, our system with human-in-the-loop validation ensures that risks associated with automated knowledge extraction can be effectively mitigated.
• In summary, HyperGraphRAG is not merely a “context retriever” but a semantically rich and graph-structural knowledge system, bridging the gap between symbolic reasoning and scalable generation. We believe this novel design offers a promising direction for future retrieval-augmented systems in complex domains.

Q2: "Challenges in Engineering Feasibility and Scalability: The end-to-end pipeline is complex. The heavy reliance on expensive LLMs for extraction and the long, multi-stage processing chain present significant challenges to scalability."

• We thank the reviewer for raising important concerns regarding the engineering feasibility and scalability of our system. While it is true that constructing high-quality structured knowledge representations typically incurs certain complexity and computational cost, we would like to clarify several key points that demonstrate the practical viability of HyperGraphRAG.
• Although HyperGraphRAG consists of three components: knowledge construction, structured retrieval, and generation, its pipeline design closely aligns with standard GraphRAG frameworks widely adopted in industrial settings. It follows a modular and stable structure rather than a lengthy or ad hoc multi-stage pipeline.
• In real-world deployment, the hypergraph can be pre-constructed, enabling efficient and real-time querying, and supports cache-based updates and incremental maintenance (see Section 4.1), showcasing the scalability of the system.
• As shown in Section 5.7, we provide a detailed cost and time analysis for both construction and inference phases. The results show that HyperGraphRAG delivers stronger performance while keeping the overall engineering cost within a practical and acceptable range. Its cost profile is superior to most graph-based systems (e.g., GraphRAG, LightRAG) and comparable to StandardRAG, indicating that the system is resource-efficient and scalable.
• Concretely, as shown in Table 3, constructing a knowledge base from 1,000 tokens of text costs only $0.0063 using HyperGraphRAG. This implies that for a 1 million-token corpus, the total construction cost would be approximately $6.30 only. Furthermore, for the inference phase, answering 1,000 queries only costs $3.184. We believe these costs are acceptable for real-world applications, especially in high-stakes, knowledge-intensive domains such as medicine and law, where HyperGraphRAG offers substantial improvements in knowledge quality, generation accuracy, and reliability.
• In summary, HyperGraphRAG is carefully designed with scalability and real-world deployment in mind. It offers a strong balance between construction cost, runtime efficiency, and deployment flexibility, and does not pose a fundamental scalability bottleneck.

Q3: "Limitations in Representational Capabilities: It struggles to model the complex logical relationships (e.g., causality, dependency, conditionality) that often connect these events in domains like law or science. This limits its applicability for tasks requiring deep, multi-step reasoning."

• We sincerely thank the reviewer for this insightful comment. We fully agree that capturing complex logical relationships and supporting multi-step reasoning are crucial, especially in domains like law and science. Below, we clarify our design choices and the representational potential of HyperGraphRAG.
• First, HyperGraphRAG is designed to enhance structural expressiveness and semantic integrity. Unlike binary knowledge graphs that encode relations as fixed triples (e.g., (A, causes, B)), we adopt semantic hyperedges expressed in natural language. This allows us to capture rich, high-order logic like:
  • "Excessive sodium intake increases blood pressure in hypertensive patients." → causal + conditional.
  • "The contract is void if either party breaches the agreement." → dependency + conditionality.
  • "If a gene is mutated, it may lead to protein dysfunction and cause disease." → causal chain with nested conditions.
• These semantic hyperedges enable flexible representation of causality, dependency, and conditionality across multiple entities within a single edge—capabilities that binary graphs typically struggle to achieve without complex multi-hop construction.
• Second, we acknowledge that this paper focuses on single-hop retrieval, aligned with prior works such as GraphRAG and LightRAG, to isolate and evaluate the expressiveness and efficiency of the hypergraph representation itself (see Figure 6). We intentionally exclude complex multi-step reasoning components to avoid confounding effects.
• That said, HyperGraphRAG is fully compatible with advanced reasoning mechanisms such as:
  • Chain-of-Thought prompting over structured knowledge,
  • Path-based traversal or agent-style step-wise interaction,
  • Reinforcement Learning, which we discuss as future work in Appendix I.
• As demonstrated in Section 5.6, hypergraph retrieval is more efficient than binary graphs and can resolve certain multi-hop logical chains in a single-hop, thanks to n-ary modeling.
• In conclusion, this work aims to establish hypergraphs as a stronger foundation for structured knowledge in LLMs. While we begin with single-hop evaluation, we believe the semantic flexibility and multi-entity capacity of hyperedges make HyperGraphRAG inherently well-suited for modeling complex logical relationships and future multi-step reasoning integration.

Q4: "Absence of Knowledge Discovery Capabilities: The framework's definition of knowledge is confined to explicit statements within the source text, missing a key value proposition of traditional knowledge graphs: data mining and insight discovery."

• We thank the reviewer for this valuable point. We clarify that HyperGraphRAG is designed for Graph-enhanced Retrieval-Augmented Generation (GraphRAG)—a task fundamentally different from traditional knowledge discovery such as link prediction or rule mining.
• HyperGraphRAG focuses on organizing explicit textual knowledge into structured, n-ary hypergraphs to enhance retrieval and generation accuracy. This is especially important in domains like medicine and law, where reliability and traceability outweigh speculative insight.
• For example:
  • A knowledge discovery task might infer:
    "Drug A may treat Disease B based on similar patterns."
  • HyperGraphRAG retrieves a verifiable source:
    "Clinical trial X shows Drug A reduces blood pressure in resistant hypertension."
• While we agree that knowledge discovery is valuable, it often introduces uncertainty—a risk we deliberately avoid in high-stakes settings. Instead, our goal is to improve grounding and reduce hallucination by faithfully structuring existing knowledge, such as pre-existing official clinical guidelines by medical experts or private user-collected knowledge. Then, LLM can be used as a reliable QA system based on structured knowledge.
• Thus, while our task does not target implicit discovery, it maximizes retrieval quality over explicit knowledge—a distinct yet equally important goal.

At last, we sincerely appreciate your valuable feedback, and we will carefully consider all your suggestions to further improve our paper. We would be deeply grateful if you could kindly reconsider raising the score to 4 or above. Thank you very much!

Hi Reviewer hXZP, Thanks again for your thoughtful review and for reading our rebuttal! Just wanted to check if you had any remaining concerns we could help clarify. We really appreciate your time and feedback!

Thank you very much for your time and effort in reviewing our paper. We sincerely appreciate your feedback. Below, we respectfully provide our detailed responses to address your concerns.

W1: "Scalability concerns for complex reasoning tasks. Direct entity-to-entity interactions are missing."

• We thank the reviewer for raising this important point.
• Although HyperGraphRAG retrieves vector-matched entities and hyperedges along with their 1-hop neighbors, this process implicitly preserves rich entity-to-entity interactions via its n-ary relational structure:
  • An entity’s 1-hop neighbor is a hyperedge, whose 1-hop neighbors are other participating entities.
  • Thus, retrieving one entity leads to retrieving all related entities co-involved in the same hyperedge.
• The retrieved knowledge consists of complete multi-entity facts, naturally encoding entity-to-entity semantics through shared hyperedges. We also provide a detailed proof in Appendix B.2 that our hyperedge and one-hop entity-to-entity interaction are equivalent.
• Unlike binary graphs that require multiple hops to recover latent connections, HyperGraphRAG captures multi-entity semantics in a single hop, offering both efficiency and expressiveness.
• We hope this clarifies how HyperGraphRAG inherently supports rich entity-level retrieval while remaining scalable.

W2&Q3&Q4: "Heavy workload for very long documents. How does the N-ary Relation Extraction Prompt handle extremely long documents? How can one address failure cases caused by unstable structured output?"

• We thank the reviewer for pointing out the potential challenge of handling very long documents during n-ary relation extraction.
• To clarify, as shown in Equation4, our implementation segments long documents into shorter, coherent fragments $d$ before feeding them into the LLM for relation extraction. This segmentation step ensures that the model input remains within length limits. After extraction, we perform entity-level merging across different fragments, with identical names. This process yields a well-connected hypergraph, where entities are shared across multiple hyperedges derived from different document segments. This strategy is consistent with prior GraphRAG methods such as LightRAG and PathRAG, which also operate on chunked inputs for knowledge graph construction.
• During retrieval, we leverage this interconnected structure to support global entity-level knowledge retrieval, ensuring that even when documents are long, the retrieved knowledge maintains structural integrity, rich connectivity, and semantic consistency, enabling robust retrieval and generation performance.
• For structured output stability, we use several structured examples to prompt the LLM, which helps mitigate variability in structured outputs. Additionally, we write post-processing code to validate and correct the output string, ensuring that it remains well-formed and semantically coherent. You can refer to the code for more details on the implementation.

W3: "Questionable summarization and abstraction ability."

• We appreciate the reviewer’s observation regarding the lack of community-based graph structuring and hierarchical summarization in HyperGraphRAG, as seen in GraphRAG.
• Indeed, the community detection and summarization mechanisms in GraphRAG are valuable for some applications. However, these features come with notable limitations:
  1. They typically incur higher API costs due to the extra summarization stage;
  2. The summarization process may introduce hallucinations or semantic drift from the original content, especially when compressing complex knowledge into coarse-grained summaries.
• In contrast, HyperGraphRAG adopts a different design philosophy. Our goal is to construct a minimal-loss, structurally rich index over the source knowledge through hypergraph-based representation, which explicitly encodes n-ary relations among entities. This allows for a faithful reconstruction of the original document structure through fine-grained, semantically grounded hyperedges.
• At inference time, the retrieval is performed over this hypergraph structure, enabling access to precise and contextually grounded knowledge segments, closer to the original content than abstracted summaries. This design delivers higher retrieval efficiency than StandardRAG, and more expressive knowledge representation than traditional binary GraphRAG methods, striking a practical balance between fidelity, structure, and scalability.
• Such capabilities make HyperGraphRAG particularly well-suited for domains like medicine and law, where semantic precision and interpretability in knowledge construction are crucial.

W4: "GPT-4o-mini is a short-CoT model, not a long-CoT reasoning LLM like DeepSeek-R1, which is designed to perform more extensive chain-of-thought before answering."

• We thank the reviewer for this insightful observation.
• We found that GraphRAG evaluation is highly sensitive to the final generation prompt. To ensure fair and stable comparison, we adopted a unified prompt format across all methods, reducing the confounding effects of prompt engineering.
• The [THINK]...[/THINK] and [ANSWER]...[/ANSWER] tags serve as a zero-shot CoT strategy, encouraging lightweight reasoning even in short-CoT models like GPT-4o-mini. We intentionally avoided long-CoT models such as DeepSeek-R1 to minimize prompt-specific biases and ensure a level playing field.
• Our goal was to isolate the effects of structured knowledge representation, not to amplify performance via model-specific prompt tuning.

W5: "The ablation studies were conducted primarily within the medicine domain."

• We thank the reviewer for the constructive suggestion.
• We initially focused on the medicine domain because it aligns with our motivation—where structured, high-precision knowledge representation and retrieval are critical. This also enabled fine-grained qualitative evaluation in collaboration with clinical experts.
• We appreciate the reviewer’s feedback to strengthen the generalizability and empirical validation of our work. We will include ablation results from additional domains in the final version to enhance completeness and robustness.

Q1: Could the authors elaborate on the rationale behind choosing a standard graph database instead of a native hypergraph database[1], and discuss any trade-offs or limitations (e.g., information loss, query efficiency, scalability)?

• We thank the reviewer for this thoughtful and technically insightful question. During the review period, we have also noticed related work Hyper-RAG, which is also a wonderful work that employs a native hypergraph database.
• However, as you have noted, our primary motivation for choosing a bipartite graph structure is to ensure broad compatibility with existing standard graph databases and infrastructure, such as Neo4j, RDF stores, TuGraph, and even in-memory graph structures like NetworkX. These platforms are widely adopted in industry and research, and thus enable easier deployment and integration.
• The bipartite transformation corresponds to the star expansion in hypergraph theory and is lossless and theoretically equivalent to native hypergraphs. We formally discuss this in Appendix B.2, demonstrating how n-ary relational semantics are fully preserved via hyperedge-entity linking.
• Regarding query efficiency, the typical one-hop query in native hypergraphs is equivalent to a two-hop traversal in the bipartite graph (entity → hyperedge → entity). Since bipartite edges are non-informative, the actual time complexity remains unchanged.
• Moreover, our schema is representation-agnostic, and HyperGraphRAG can be ported to native hypergraph databases easily with no fundamental changes.
• In summary, we adopt bipartite structures to achieve interoperability and scalability while preserving semantic fidelity and efficiency, making our method practical and extensible for real-world applications.

Q2&Q5: Does HyperGraphRAG have the potential to generalize to multi-hop reasoning scenarios? What about using a long-CoT reasoning LLM as the QA model, since those are better at thinking through complex reasoning before answering?

• We thank the reviewer for this forward-looking question. In the current work, we focus on isolating the effects of hypergraph-based knowledge representation under single-turn QA and non-RL models to ensure fair comparison.
• That said, we strongly believe HyperGraphRAG is well-suited for multi-hop reasoning. As discussed in Appendix I, we are actively extending HyperGraphRAG with end-to-end reinforcement learning (RL) via the GRPO framework. This enables an agent to iteratively explore the hypergraph, retrieving intermediate nodes before final answer generation.
• Our preliminary results from this follow-up system—HyperGraphRAG+GRPO—show strong gains over Search-R1 (a StandardRAG + GRPO baseline) using Qwen2.5-7B as the base model:

• These results suggest that RL amplifies the strengths of hypergraph representations, enabling more effective navigation and reasoning over structured knowledge.
• In conclusion, HyperGraphRAG not only generalizes to multi-hop settings, but also provides a robust foundation for agentic QA and long-CoT reasoning systems.

At last, we sincerely appreciate your valuable feedback, and we will carefully consider all your suggestions to further improve our paper. We would be deeply grateful if you could kindly reconsider raising the score further. Thank you very much!