HiRAG：分层知识图谱增强检索，突破 RAG 的「知识孤岛」困境

痛点切入：传统 RAG 为何总在关键时刻「掉链子」？

想象一个场景：你在构建企业内部知识库问答系统，导入了几百份技术文档、专利文献和行业报告。当用户问起「这家公司近三年在新能源汽车领域的专利布局，与竞争对手相比有何差异化优势？」——这类需要跨文档关联推理的问题，传统 RAG 的命中率会断崖式下跌。

根源在于：传统 RAG 将文档切成独立 chunks，各自为战，忽略了知识之间的拓扑关系——谁属于谁、谁引用了谁、谁与谁矛盾。HiRAG（Hierarchical Retrieval-Augmented Generation）正是为解决这一问题而生。

背景故事：从GraphRAG到HiRAG的演进

HiRAG 由香港科技大学（HKUST）知识计算实验室团队提出，论文《HiRAG: Retrieval-Augmented Generation with Hierarchical Knowledge》被 EMNLP 2025 Findings 接收。

它的核心灵感来自 GraphRAG——微软提出的基于知识图谱的检索增强方案。但 GraphRAG 的痛点在于：需要完整的知识图谱构建周期，无法在测试时动态调整知识库结构，每次增删知识都要全量重建索引，成本极高。

HiRAG 提出了分层桥接知识（Hierarchical Bridge Knowledge）机制：在索引阶段将文档构建为层级图结构（含实体节点、社区、跨社区桥梁），查询阶段通过动态社区检测实现无需重建索引的知识更新。这相当于给 RAG 系统装上了「动态知识拓扑」能力。

核心原理：三层知识结构 + 六种检索模式

HiRAG 的知识组织形态像一个多层级城市交通网络：

1. Local Knowledge（本地知识）

最底层的实体节点和边——具体的人名、术语、事件。与 Naive RAG 的 chunk 类似，但保留了实体关系图谱的拓扑信息。

2. Global Knowledge（全局知识）

通过 Leiden/Leiden 算法对知识图谱进行层级聚类，生成社区报告（Community Report）——每个社区代表一个主题簇，由 LLM 自动化生成摘要。可以理解为「给每片知识区域写一份地图简介」。

3. Bridge Knowledge（桥接知识）

这是 HiRAG 最独特的设计——跨社区的连接节点。解决的是「从 A 话题跳转到 B 话题」时的信息丢失问题。当用户问题跨越多个主题时，桥接知识提供平滑的知识跳转路径。

六种检索模式

HiRAG 支持 6 种检索模式（mode 参数）：

• naive：传统 RAG 基准
• hi：完整 HiRAG 模式（Local + Global + Bridge 协同）
• hi_nobridge：无桥接知识
• hi_local：仅本地知识
• hi_global：仅全局知识（社区报告）
• hi_bridge：仅桥接知识

论文实验表明，HiRAG 在 UltraDomain 数据集上相比 Naive RAG 显著提升，尤其在跨文档多跳推理场景中优势明显。

技术架构：存储层抽象与多后端支持

HiRAG 的代码采用经典的三层抽象架构：

存储层（Storage Abstraction）

定义了三个抽象接口：BaseVectorStorage（向量存储）、BaseGraphStorage（图存储）、BaseKVStorage（键值存储），每种支持多个后端：

存储类型	支持后端
图存储	NetworkX（内存）、Neo4j（持久化）
向量存储	NanoVectorDB（轻量）、Cohere API
KV存储	JSON 文件（本地持久化）

这意味着开发者可以在不同规模下切换后端：小规模用 NetworkX + JSON 文件快速原型；生产环境切 Neo4j + NanoVectorDB 无需改业务代码。

LLM 层

通过 _llm.py 实现了对 OpenAI、DeepSeek、GLM、Cohere、Ollama 五大后端的统一封装，自动降级机制（检测 API Key 和 base_url）。嵌入模型同样支持 OpenAI、Cohere、GLM、Dense、Ollama 等多种方案。

知识处理流程

1. Chunking：用 tiktoken 按 token 大小切分文档（默认 chunk_token_size=1200，overlap=100）
2. 实体抽取：用 LLM 从每个 chunk 提取命名实体及关系三元组
3. 层级聚类：用 Leiden 算法对实体关系图进行社区检测，支持多级（level 1/2/3）
4. 社区摘要：LLM 为每个社区生成结构化报告（JSON 格式）
5. Node2Vec 嵌入：对图节点生成向量表示，用于语义相似度检索

检索流程

查询参数 QueryParam 控制检索行为，核心逻辑在 _op.py 的 hierarchical_query() 函数族——根据 mode 参数组合 Local/Global/Bridge 知识的融合比例，最终将上下文注入 LLM 生成答案。

上手体验：依赖复杂但示例清晰

优点：

• 示例代码极简，核心使用只需 15 行 Python 代码
• 多后端适配器设计优秀，hi_Search_openai.py / deepseek.py / glm.py / ollama.py / cohere.py 五个示例文件覆盖主流 LLM
• 支持通过 working_dir 热插拔不同知识库实例

缺点：

• 无 Docker 支持，必须手动配置 Neo4j 环境（需要 Java 运行时）
• 依赖链长：graspologic、networkx、scikit-learn、UMAP、neo4j-driver 等 20+ 依赖
• 需要 LLM API Key（DeepSeek/GLM/OpenAI/Cohere 之一），无法纯离线运行
• 图数据库启动和索引构建耗时，文档未给出明确的时间预期
• enable_hierachical_mode=True 时 embedding 批量处理次数多（embedding_batch_num=6, max_async=8），对 API 限流敏感

硬件与部署要求

指标	要求
Python	>= 3.9
GPU	推荐（本地 embedding 时必须）
VRAM	6GB+（gte-qwen2-7b 等 7B 模型）
RAM	8GB+
磁盘	10GB+（索引文件 + Neo4j 数据）
必需服务	Neo4j 图数据库（端口 7687/7474）

行业意义与局限

意义： HiRAG 解决了 RAG 领域的一个核心痛点——跨文档知识关联推理，相比 Naive RAG 在多跳问答上有显著提升，且支持测试时知识更新而不必重建索引，这是 GraphRAG 路线的重要改进。

局限：

1. 依赖 LLM API 调用，推理成本高于纯本地模型
2. 社区检测和报告生成引入额外延迟，实时性要求高的场景需优化
3. Neo4j 作为唯一生产级图存储后端，增加了运维复杂度
4. 论文在非英语数据集上的评估覆盖不足

结论

HiRAG 是当前 RAG 领域中最具学术深度和工程价值的开源实现之一，适合知识密集型问答、专利分析、学术文献综述、企业知识图谱问答等场景。部署有一定门槛，建议有图数据库运维经验的团队使用。星数增长快（548★），且有 EMNLP 2025 论文背书，社区活跃度可期。