77-91% 的覆盖率，23-78% 的准确率——信息就在那里，但模型用不上

“The Reasoning Bottleneck in Graph-RAG” [ref] 在 KET-RAG 系统上测了三个多跳 QA 数据集（HotpotQA, MuSiQue, 2WikiMultiHopQA），发现一个令人不安的数字：gold answer 在检索到的上下文中出现的比例是 77-91%，但模型实际回答正确的比例只有 23-78%。

更精确地说，73-84% 的错误发生在答案已经在上下文中的时候。不是找不到，是连不上。

这个发现直接映射到一个一般性的模式：获取信息 ≠ 利用信息。检索已经基本解决了（覆盖率 >80%），真正的瓶颈在于模型能否从 ~10,000 token 的上下文中定位相关事实并串联起来。

两个推理时增强，8B 匹配 70B

论文提出两个不需要重新训练的增强方法：

  1. SPARQL CoT：让模型先把问题分解为 SPARQL 三元组查询模式（?x tributaryOf ?y），然后逐步绑定变量。本质上是把开放式推理转化为结构化的模式匹配。

  2. Graph-Walk 压缩：从问题实体出发做 BFS，只保留拓扑上相连的上下文，~60% 压缩（10,000 → 4,000 token），零 LLM 调用。

核心结果（Table 3 和 Table 6）：

配置 HotpotQA MuSiQue 2WikiMHQA
8B baseline 67.0% 23.6% 31.4%
8B + SPARQL + GW 76.6% 30.6% 55.8%
8B + routing + GW 79.8% 35.6% 64.8%
70B baseline 78.0% 35.2% 48.8%

8B + 全套增强在所有三个 benchmark 上匹配或超过未增强的 70B，成本约 12x 更低。这是"推理时利用效率"可以弥补 ~9x 参数差距的直接证据。

最有趣的发现：压缩和脚手架的协同效应

Table 7 的交互效应矩阵是这篇论文最有价值的部分：

方法 模型 HotpotQA MuSiQue 2WikiMHQA 平均
Base + GW 8B -3.4 -4.2 -1.0 -2.9
SPARQL + GW 8B +6.0 +1.8 +10.2 +6.0
Base + GW 70B +1.2 +4.6 +4.8 +3.5
SPARQL + GW 70B -0.6 -1.6 -1.2 -1.1

模式很清楚：

  • 8B 没有脚手架时，压缩有害（-2.9pp）：小模型依赖穷举上下文做模式匹配，减少信息就减少了成功的概率
  • 8B 有脚手架时，压缩有益（+6.0pp）：结构化提示提供了"推理路线图"，压缩减少了无关噪声，两者协同
  • 70B 没有脚手架时，压缩有益（+3.5pp）：大模型本身有足够的推理能力，减少噪声直接帮助它聚焦
  • 70B 有脚手架时，压缩无益（-1.1pp）：大模型 + 结构化提示已经可以很好地在全量上下文中导航，压缩反而可能去掉了有用的背景信息

这说明脚手架和压缩不是独立的优化——它们的效果取决于模型自身的推理能力。小模型需要两者配合，大模型只需要其中一个。

CoT 格式偏好与模型规模：复杂度匹配窗口

另一个引人注目的发现在 CoT ablation 中（Table 5，2WikiMHQA）：

方法 8B 准确率 70B 准确率
Generic CoT 52.6% 56.4%
SPARQL CoT 45.6% 61.0%

8B 偏好更简单的 generic CoT（自然语言子问题），70B 偏好更结构化的 SPARQL CoT（三元组模式）。论文的解释：SPARQL 语法对 8B 施加了额外认知负担（syntax overhead），但 70B 能利用三元组模式与知识图谱上下文的结构对齐。

问题类型路由进一步证实了这个模式：把 bridge 问题发给 SPARQL，comparison/inference 问题发给 generic，8B 准确率从 45.6% 提升到 58.4%。不同推理格式有各自适合的问题类型。

与 RLLM 论文的平行：复杂度匹配是通用规律？

这让我想到一个可能的通用规律。Meta RLLM 论文 [ref] 中发现的训练格式迁移不对称：

  • 训练时：数学对象（复杂格式）→ 数值/MCQA（简单格式）可以迁移；MCQA（简单格式）→ 其他格式都差。简单训练强化快捷策略（backward chaining），不利于深层推理。
  • 推理时（本文）：SPARQL（复杂结构化提示）对 70B 更好，generic（简单结构化提示）对 8B 更好。复杂脚手架需要匹配模型的处理能力。

两个层面都存在一个复杂度匹配窗口：

  • 太简单 → 强化快捷策略，无法发展/利用深层推理
  • 太复杂 → 超出模型处理能力，语法/格式开销吞噬推理资源
  • 刚好 → 最优利用

如果这是对的，那么利用效率优化的核心问题就不只是"添加更多脚手架"或"用更好的训练格式"，而是为给定的模型能力找到复杂度匹配点。

批判

  1. benchmark 的局限：HotpotQA/MuSiQue/2WikiMHQA 都是结构化的 Wikipedia 问答，答案通常是单个实体。在开放式、需要综合性回答的场景中，SPARQL 模式匹配方法的适用性存疑。

  2. 路由的真实成本：论文说"8B + routing + GW 匹配 70B"，但路由需要一个分类器调用 + 可能的重试，实际成本不是单纯的 12x 差距。尤其在 MuSiQue 上 8B routing 只比 70B baseline 高 0.4pp（35.6% vs 35.2%），统计显著性存疑。

  3. 使用了旧模型：Llama 3.1 8B 和 Llama 3.3 70B。社区评论正确指出（Reddit 帖子中），如果用更新的模型（Qwen 3.5 等），基线会更高，但论文的方法论洞察（脚手架-压缩协同效应）应该仍然成立。

  4. "复杂度匹配"假说目前只有两个数据点：RLLM 的训练格式实验和本文的 CoT 格式实验。这可能只是 Goldilocks principle 的又一个实例化（“not too X, not too Y, just right”），作为预测工具的实用价值有限。需要更多跨层级的系统性验证——比如，能否在架构层面（FFN 宽度 vs 任务复杂度）也找到类似的匹配窗口？

Graph-RAG Reasoning Bottleneck 论文 + Meta RLLM 论文 的交叉分析