StructRAG (ICLR 2025)：选择正确的文档结构，性能领先 GraphRAG 28 分
生产环境中 RAG 的常见槽点在于，当相关事实分散在数十个格式不兼容的文档中时，检索显得过于笨拙。StructRAG（Li 等人，ICLR 2025）通过在推理前将检索到的文本转换为适合任务的结构——表格、图、目录、算法或纯文本块——来直接解决这一问题。其动力源于一种认知理论主张：人类在处理复杂推理任务时，会自然地将原始信息重塑为结构化表示。无论这种框架更多是隐喻还是机制，其经验数据都值得仔细研究。
论文详解
StructRAG 提出了一个包含三个模块的推理阶段流水线。首先，混合结构路由器（Qwen2-7B-Instruct，基于 900 个合成偏好对进行 DPO 微调）预测五种结构类型中哪一种最适合输入的查询及其文档。其次，分散知识结构化器（Qwen2-72B-Instruct）将检索到的文本块重写为所选格式。第三 ，结构化知识利用器将问题分解为子问题，检索相关的结构化片段，并生成最终答案。这五种结构类型分别是：表格（统计比较）、图（多跳链，编码为“头-关系-尾”三元组）、算法（规划任务，编写为伪代码）、目录（总结、分层编号）和文本块（简单的单跳检索，默认的 RAG 备选方案）。
作者主要在 Loong 基准测试（EMNLP 2024 Oral）上进行评估，这是一个涵盖财务报告、法律案件和学术论文的多文档问答基准，输入范围从 1 万到 25 万个 token，涵盖四种任务类型：关键定位、比较、聚类和推理链。
核心观点
- 经过 DPO 训练的路由器在结构类型选择上的准确率达到 94.38%，而 Qwen2-72B-Instruct 的零样本准确率仅为 50.04%——路由决策是其中最关键的组件。移除路由器后，大语言模型（LLM）的总分从 60.38 降至 45.33。
- 在难度最大的文档长度层级（20 万至 25 万 token）中，StructRAG 得分为 51.42，而长上下文（Long-Context）模型为 28.92，标准 RAG 为 29.29——随着上下文增加，这种约 22 分的差距会进一步扩大。标准的“填鸭式”方法性能会急剧下降，而 StructRAG 的性能衰减更为平缓。
- 尽管 GraphRAG 也引入了结构，但其在 Loong 上的 LLM 总分为 40.82，而 StructRAG 为 69.43，且 GraphRAG 每个查询耗时 217.1 分钟，而 StructRAG 仅需 9.7 分钟。预构建全局知识图谱既慢又不如按需选择正确格式准确。
- 在播客转录文本（开放式摘要）测试中，StructRAG 对比长上下文方法的成对胜率达到 95.75%，这表明即使在结构化程度较低的源材料上，结构化合成的表现也优于全上下文方法。
- 精准匹配（EM）得分始终落后于 LLM 评判得分，因为结构化改变了表面措辞（例如，“$1,308,463”在表格单元格中变成“138463”），产生了一种系统性的 token 不匹配问题，从而在自动化评估中被扣分。
哪些结论成立，哪些存疑
核心结果是真实的，消融实验的逻辑也很清晰：路由最重要，其次是结构化，最后是利用。长文档长度下的改进是最有力的发现——在 20 万 token 规模下提升 22 分绝非偶然。
即便如此，我有三点保留意见。首先，基准测试覆盖面较窄。StructRAG 仅报告了 Loong 和播客转录测试。标准的多跳基准测试（HotpotQA、2WikiMultiHopQA、MuSiQue、NQ）显著缺失，这使得无法评估 StructRAG 与这些成熟数据集上的大量现有检索研究相比表现如何。ICLR 的审稿人大概率提出了这一点，但该论文的正式版本未提供直接回应。
其次，评估模型是 GPT-4。以大模型作为裁判（LLM-as-judge）容易受到长度偏见和文风偏好的影响，可能会偏向来自相同结构化过程的输出，特别是当裁判模型也接受过类似结构化文本的训练时。精准匹配（EM）指标是一种修正，但作者将其解释为指标本身的局限性，而非方法论问题的证据。
第三，StructRAG 使用了大型骨干模型（结构化器和利用器均使用 Qwen2-72B-Instruct）。目前尚不清楚性能增益有多少来自于路由，又有多少仅仅是调用强大模型进行重写和总结带来的。如果能针对同等规模的直接回答基线进行消融实验将能解决这一疑问，但论文中并未展示。
为什么这对金融 AI 很重要
Beancount 账本是“信息分散”问题的典型案例。一个简单的对账问题——“为什么我的净资产在第三季度下降了？”——可能需要读取三个账户的交易分录，交叉引用资产负债表报告，并追踪一个多步骤的更正链。这些需求几乎与 StructRAG 的结构类型一一对应：用于余额比较的表格、用于交易链的图、用于期间摘要的目录。
路由洞察特别适用。一个专注于查询的 Beancount 代理不应总是直接将文本块塞进上下文中；它应该首先询问答案需要什么形状。余额趋势问题需要表格。解释报销链的问题需要图。总结年度支出问题需要目录。明确这种路由决策——即使是使用小型模型——也可以显著减少困扰当前账本问答的幻觉和数字错误。
217 分钟与 9.7 分钟的延迟对比在实践中也非常重要。对于交互式 Beancount 代理，GraphRAG 的预索引成本对于频繁更新的账本来说是不可接受的；StructRAG 的推理阶段方法更适合“写多查少”的账本使用场景。
需要注意的是：StructRAG 的结构化器在每次查询时都会调用大型 LLM。对于漫长的账本历史，这种推理成本可能会变得非常可观。实现 token 高效的结构化——也许是通过更小的微调模型——是一个开放的工程问题。
延伸阅读
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge et al., 2024, arXiv:2404.16130) —— Microsoft GraphRAG 对全局查询使用社区摘要；理解 StructRAG 的推理阶段结构化在何处优于 GraphRAG 的预索引，是掌握架构权衡的关键。
- FinAuditing: A Financial Taxonomy-Structured Multi-Document Benchmark (arXiv:2510.08886) —— 在具有分层表格的 XBRL 申报文件上测试了 13 个大模型；这是对 StructRAG 的表格和目录结构是否能迁移到类似于 Beancount 账本的结构化申报格式的直接测试。
- InvestorBench: A Benchmark for Financial Decision-Making Tasks with LLM-based Agent (arXiv:2412.18174, ACL 2025) —— 评估代理在真实金融决策中的表现，这可以让我们衡量 StructRAG 的结构化推理是否真的有助于下游决策质量，而不仅仅是单跳问答的准确性。
