HM-RAG：分层多智能体多模态检索增强生成

背景：从单兵作战到多智能体协作

想象一个医生面对一份同时包含医学影像、患者病历文本和家族基因图谱的复杂病例。传统的 RAG（检索增强生成）系统就像一位只会看单一类型资料的实习医生——要么看影像，要么看病历，很难综合判断。而 HM-RAG 则是一套由三位专科医生组成的会诊团队：一位负责拆解病情（分解智能体），一位负责查阅影像和文献资料（多源检索智能体），最后由主任医生综合各方意见给出诊断（决策智能体）。

HM-RAG 全称 Hierarchical Multi-Agent Multimodal Retrieval Augmented Generation（分层多智能体多模态检索增强生成），由刘沛、刘欣、姚若宇等人提出，发表在 ACM Multimedia 2025（CCF-A 类顶会）。它的核心创新在于：不再让大语言模型"孤军奋战"，而是通过多智能体协作，让向量检索、图谱检索和网络检索三种能力形成合力。

架构解析：三层六步的协作流水线

HM-RAG 的架构分为三个层级，与人类医疗团队的工作流程高度对应：

第一层：分解智能体（Decomposition Agent）

当用户提出一个复杂问题时——比如"最近三年人工智能在医学影像诊断领域的进展如何？有什么具体案例？"——这个问题实际上包含三个独立意图：时间范围（最近三年）、技术领域（AI + 医学影像）、应用案例（具体案例）。分解智能体使用 LangChain + Ollama（Qwen2.5-7B） 驱动，首先判断问题包含几个独立意图，然后通过语义重写和上下文增强，将复杂问题拆解为若干个子问题。这个过程模拟的是人类专家"化繁为简"的思维习惯。

第二层：多源检索智能体（Multi-source Retrieval Agents）

子问题分发后，三个专业检索智能体并行工作：

• 向量检索智能体（Vector Retrieval）：基于文本嵌入（Embeddings），在 Milvus 等向量数据库中检索相关内容，支持语义相似度匹配。
• 图谱检索智能体（Graph Retrieval）：使用 Neo4j 图数据库，通过实体关系网络发现知识间的深层关联——比如发现"某药物"与"某种基因突变"在知识图谱中存在的间接联系，向量检索可能遗漏。
• 网络检索智能体（Web Retrieval）：调用 Serper API 搜索互联网，补充最新资讯和实时数据。

每个智能体由 LightRAG 框架提供统一的检索接口，检索结果以结构化文本形式返回。

第三层：决策智能体（Decision Agent）

三个检索结果汇总后，决策智能体通过 一致性投票（Consistency Voting） 机制整合多源答案，并使用 Expert Model Refinement 解决检索结果中的冲突。例如向量检索说"A 药的疗效优于 B 药"，但网络检索发现了最新临床试验的相反结论，决策智能体会识别这种矛盾并优先信任权威来源，最终给出统一的综合答案。

在 ScienceQA 多模态问答数据集上，HM-RAG 验证了这一架构的有效性。

技术栈：学术研究与工程实践的交汇

从代码结构来看，HM-RAG 的技术选型体现了学术研究的务实风格：

依赖列表中包含了 40+ 个核心包，涵盖数据库驱动、异步 I/O、图算法、机器学习等多个领域，这也是本地部署的主要障碍之一。

上手体验：研究级代码的使用门槛

HM-RAG 的安装流程要求用户具备一定的人工智能研究经验：

conda create --name hmrag python=3.10
conda activate hmrag
pip install -r requirements.txt

但真正的挑战在于运行时环境的准备。你需要：

1. 部署 Ollama 并下载 Qwen2.5-7B 模型（约 5GB）
2. 获取 OpenAI API Key 或 Serper API Key
3. 部署至少一种向量数据库（Milvus 推荐）
4. 可选部署 Neo4j（知识图谱）、MongoDB（文档存储）、PostgreSQL（结构化数据）

如果仅想运行基准测试，还需要下载 ScienceQA 数据集（约 1.6GB）。

命令行参数提供了丰富的配置选项，包括 20+ 种提示词模板格式（CQM-A、CQM-LA 等），支持自定义少样本示例数量和测试集划分。这种灵活性对于研究人员是优势，但对普通用户来说学习曲线陡峭。

局限与风险

必须坦诚地说，HM-RAG 作为学术原型存在一些需要正视的问题：

1. 许可证缺失：项目没有明确的开源许可证（License: None），这意味着代码的二次使用和商业化存在法律风险，使用前需联系作者确认。
2. 维护状态：pushed_at 停留在 2025-07-23，最后更新距今已超过半年，Release Plan 中"优化的多检索方法"和"优化的生成机制"仍未实现。
3. 依赖地狱：40+ 依赖包的版本管理是一大挑战，特别是涉及 CUDA 版本的 deepspeed 和 bitsandbytes，在不同 GPU 架构上可能出现兼容性问题。
4. API Key 硬编码隐患：main.py 中通过命令行参数传入 API Key 是合理设计，但部分示例代码中对 http_proxy 指向 127.0.0.1:11434（Ollama 默认端口）的假设，在生产环境中需要额外注意。

行业意义：从"能用"到"好用"的 RAG 进化

HM-RAG 的价值不在于它是一个可以直接部署的生产系统，而在于它指明了一个方向：多模态 RAG 的下一个突破点在于智能体协作，而非单一检索能力的堆砌。

当前大多数 RAG 系统的瓶颈，不是向量数据库不够快，也不是 Embedding 模型不够准，而是缺乏一个有效的"协调层"——如何让不同类型的检索结果相互补充、相互验证，而不是简单拼接。HM-RAG 通过三层智能体架构，给出了一个值得参考的解决思路。

ACM MM2025 的接收也说明，顶会学术圈对"检索增强生成"与"多智能体系统"的交叉领域持续保持高度关注。随着 GPT-4V、Gemini 等多模态大模型的成熟，能够综合处理文本、图像、知识图谱的 RAG 系统，将成为下一代 AI 应用的基础设施。

如果你正在构建需要处理多模态文档的企业知识库系统，HM-RAG 的架构思路值得借鉴；但若寻求开箱即用的产品，建议关注其后续优化版本的发布计划，或选择更成熟的生产级方案如 LangChain RAG 模板。