StructRAG
icip-cas/StructRAG加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下，当你向一个大语言模型提问「某篇论文的核心贡献是什么」时，模型要么大海捞针般在整篇文档里搜索，要么干脆「想不起来」——这就是知识密集型推理任务长期面临的困境。中科院计算所的研究者们在 ICLR 2025 发表的 StructRAG 框架，给出了一个优雅的答案：让 LLM 在推理阶段动态决定「用哪种结构来理解知识」，而不是机械地让向量数据库做 RAG。
简单来说，StructRAG 做了一件很聪明的事：当用户提出问题时，它先让模型「想一想」这个问题需要什么类型的知识——是需要精确的表格数据？还是需要关系网络中的路径推理？或者需要分层的目录结构？然后，它只提取最相关的那部分信息，用最优的结构化方式呈现给大模型，从而大幅提升回答质量。
图1：StructRAG 整体框架
检索增强生成（RAG）已经成为让大模型接入私有知识的主流方案。但传统 RAG 方法存在一个根本性缺陷：无论问题是什么，都把知识统一处理成向量检索的「块」（chunk）。这就好比图书馆管理员不管你问什么书，都只给你一叠随机页面。
以 Loong 数据集（StructRAG 的评估基准）中的知识密集型问答为例，问题类型差异巨大：有的需要精确比对表格数据（如「某方法在某数据集上的准确率是多少」），有的需要关系推理（如「作者A和作者B有没有合作过」），有的需要分步流程理解（如「某算法的输入输出是什么」）。将所有这些异构知识都压缩成向量块，显然会丢失大量结构信息。
StructRAG 来自中国科学院计算技术研究所（ICT, CAS），被 ICLR 2025 接收，论文发表在 OpenReview 上。项目由该机构的多位研究者联合开发，目前 GitHub 获星 169，是 RAG 领域值得关注的前沿工作。
把 StructRAG 想象成一个多语言翻译官：同样是回答「这本书讲了什么」这个问题，
这种「按需选择最优结构」的方法，比把所有知识都翻译成同一种语言（向量块）要高效得多。实验表明，这种混合结构化方法在知识密集型推理任务上，显著优于传统的 chunk-based RAG 基线。
StructRAG 的代码架构非常清晰，分为三大核心模块：
图2：Router-Structurizer-Utilizer 流水线示意
Router 是整个流水线的「大脑」。它接收用户的自然语言查询，利用 LLM 的推理能力，判断当前问题最适合哪种知识结构。代码中硬编码支持四种结构类型：
Router 的实现非常轻量：读取 prompts/route.txt 中的提示词模板，将查询和候选结构类型列表拼接后发给 LLM，由 LLM 做路由决策。默认使用 few-shot examples，论文指出 Qwen2-72B-Instruct 在该设置下已有不错的路由准确率。当然，如果你想进一步提升精度，还可以通过 DPO 算法微调一个小模型（7B）作为路由器。
一旦 Router 决定了目标结构，Structurizer 负责从原始文档中提取信息并转换为目标结构。这一步同样依赖 LLM 的能力，代码中为每种结构类型都设计了专门的提示词模板：
prompts/construct_table.txt：指导 LLM 从文档中提取表格数据prompts/construct_graph.txt：指导 LLM 构建知识图谱（节点+边）prompts/construct_algorithm.txt：指导 LLM 提取分步流程prompts/construct_catalogue.txt：指导 LLM 提取目录结构Structurizer 的输入是原始文档 chunks，输出是结构化的知识表示（JSON 格式）。这种转换是可验证、可解释的——你可以直接看到 LLM 是如何「理解」原始知识的。
最后，Utilizer 模块接收用户的原始查询和结构化后的知识，通过 prompts/decompose.txt 中的提示词，让 LLM 基于特定结构回答问题。这里的关键设计是分解（decompose）：将复杂查询拆解为多个子查询，分别在对应的结构化知识中检索答案，再综合形成最终回复。
以一个具体例子理解：假设问题是「比较方法A和方法B在3D重建任务上的精度差异，并说明各自优缺点」。Router 可能会选择 table（数值对比）和 algorithm（优缺点分析）两种结构，Structurizer 分别从文档中提取相关表格和流程信息，Utilizer 则综合这些结构化信息给出对比分析——这比传统 RAG 只给出一堆相关段落要精准得多。
StructRAG 是纯 Python 研究代码，主要依赖：
| 依赖 | 版本 | 用途 |
|---|---|---|
| vLLM | 0.6.3.post1 | LLM 推理服务（支持 tensor parallel） |
| accelerate | 0.31.0 | 分布式训练加速 |
| deepspeed | 0.15.0 | 模型并行训练 |
| faiss-gpu | 1.7.2 | GPU 加速向量索引 |
| datasets | 2.21.0 | 数据集处理 |
| anthropic | 0.30.1 | Anthropic API 调用 |
| dashscope | 1.20.1 | 通义千问 API |
核心推理流程依赖 vLLM 提供的模型服务，默认支持 Qwen2-72B-Instruct（需要 4 卡 tensor parallel）。如果你有足够的 GPU 资源，可以本地部署；也可以通过 API 服务（如 DashScope 的 Qwen API）调用云端模型。
必须直说：StructRAG 不是给普通用户准备的工具，而是面向研究人员的实验框架。 部署它面临三重门槛：
硬件门槛：默认使用 Qwen2-72B-Instruct，需要 4 张 GPU（tensor parallel size=4），每张卡至少 24GB 显存。论文中也提到可以用更小的模型做实验（如 7B 路由器微调），但核心推理效果会打折扣。
数据门槛：Loong 数据集需要从 Google Drive 手动下载（Loong/README.md 提供了链接），不是 pip install 就能跑起来的那种。数据格式为 JSONL，包含大量知识密集型问答的原始文档和标注。
工程门槛：需要自己启动 vLLM API 服务器（python -m vllm.entrypoints.openai.api_server），配置模型路径、端口、tensor parallel 参数。没有 Docker、没有 Web UI、没有一键启动脚本。
当然，如果你的研究重点是探索「不同结构化方法对 RAG 效果的影响」，StructRAG 提供了完整可复现的实验框架——包括训练路由器的 DPO 脚本、批量推理脚本、评估脚本。相比很多「论文放出来代码跑不通」的工作，这已经算良心了。
推理成本翻倍：每次查询都要经过 Router → Structurizer → Utilizer 三个 LLM 调用，相比传统 RAG 的单次检索+生成，API 调用成本和延迟都明显增加。在对响应速度有要求的在线场景中，这是一个不可忽视的权衡。
路由决策的准确性：Router 的路由决策完全依赖 LLM 的推理能力。如果 LLM 错误地选择了不匹配的结构类型（如把需要图推理的问题路由到 table），后续的结构化和利用步骤都会出错，形成「一步错步步错」的风险。
结构化知识的质量依赖底层模型：Structurizer 的输出质量直接由 LLM 决定。如果 LLM 在结构化过程中遗漏了关键信息或产生了错误关联，整个 RAG 链路的上限就被锁死了。这也是为什么默认使用 72B 大模型的原因之一。
缺乏生产级工程优化：当前代码是研究原型，缺少缓存机制、批处理优化、错误重试等生产环境必备的特性。从研究论文到生产系统，还有大量工程工作要做。
StructRAG 最重要的贡献，不是提出了又一个 SOTA 结果，而是重新定义了 RAG 的信息处理粒度。传统 RAG 在「块」的层面操作，StructRAG 尝试在「结构」的层面操作——这是一个更接近人类认知方式的知识组织方式。
从增长曲线看，StructRAG 虽然目前只有 169 星（作为一个刚发表半年的 ICLR 论文，属于正常水平），但它代表了一个值得关注的研究方向：未来 RAG 系统可能不再只比拼向量检索算法，而会更深入地探讨「如何让机器真正理解知识的语义结构」。
对于 AI 开发者而言，StructRAG 的启发是：当你发现 RAG 效果不好时，先别急着调向量检索参数，想想是不是知识本身的组织方式出了问题。有时候，换一种知识结构，比换一百个 embedding model 都有用。