当RAG遇上知识图谱：一个让LLM"开卷考试也翻车"的新基准
论文标题：How Much Reasoning Do Retrieval-Augmented Models Add beyond LLMs? A Benchmarking Framework for Multi-Hop Inference over Hybrid Knowledge
论文链接：https://arxiv.org/abs/2602.10210
机构：Emory University, Amazon
一句话总结：这篇论文搞了一套自动化基准生成框架 HybridRAG-Bench，专门用来测 RAG + 知识图谱方法在多跳推理上到底行不行——结果发现，大部分方法在真正需要跨源推理的问题上，表现远没有我们以为的那么好。
🎯 这篇论文想解决什么问题？
RAG（Retrieval-Augmented Generation）这两年火得一塌糊涂。几乎所有想让LLM"落地"的团队，都在用某种形式的RAG——把外部知识检索出来，塞进上下文，让模型"有据可依"地回答问题。
但一个尴尬的事实是：我们怎么知道模型真的在"推理"，而不是在"回忆"？
想象一下高考场景。你让一个学生做"开卷考试"，结果发现他之前就把答案背下来了——那这个"开卷"考的到底是查阅能力还是记忆力？对LLM来说也是一样的：HotpotQA、WebQuestions、ComplexWebQuestions 这些经典的多跳问答基准，很多数据早就混进了LLM的预训练语料。模型看到问题，可能直接从参数里"回忆"出答案，根本不需要真正去检索和推理。
这就是所谓的数据污染（data contamination）问题。
更麻烦的是，现有基准大多只考虑文本检索，不涉及知识图谱。可真实世界里，很多问题需要同时用到非结构化文本和结构化知识——比如你问"发明了Transformer的团队里，谁后来去了哪家公司做了什么产品？"，这种问题单靠搜文档或者单靠查知识图谱都搞不定，得两边结合才行。
HybridRAG-Bench 就是冲着这两个痛点来的：用时间窗口隔离来消除数据污染，用混合知识（文本+KG）来测试真正的多跳推理能力。
📖 背景知识：RAG和KG-RAG的江湖
在深入论文细节之前，先理清几个关键概念之间的关系。
RAG：给LLM配一本"参考书"
RAG 的核心思路很直观：模型回答问题时，先从外部知识库里检索相关文档，把检索结果拼进 prompt，再让模型基于这些"参考资料"生成答案。这就像学生做开卷考试——虽然脑子里不一定记得所有知识点，但可以翻书找到相关内容再作答。
标准的 RAG 流程是：Query → 文档检索 → 拼接上下文 → LLM 生成答案。这种方式在单跳事实性问答上效果不错，但碰到多跳推理就开始吃力——因为你可能需要先找到A文档里的线索，再根据这个线索去B文档里找另一条信息，最后把两条信息串起来才能得出答案。传统 RAG 做一次检索就完事了，没有这种"链式追踪"的能力。
知识图谱：把知识"结构化"
知识图谱（Knowledge Graph, KG）用三元组（实体-关系-实体）来存储知识，比如 (Transformer, invented_by, Vaswani et al.)。它的优势在于关系是显式编码的——你可以沿着边一步步跳，天然适合多跳推理。
但 KG 也有软肋：覆盖率不够。真实世界的知识太丰富了，KG 不可能把所有信息都编码成三元组。很多细节、上下文、数值描述，只存在于非结构化文本里。
KG-RAG：两条腿走路
于是就有了各种 KG-RAG 方法，试图把文本检索和图谱推理结合起来。这些方法的核心思路各不相同：
- Think-on-Graph (ToG)：让 LLM 在知识图谱上"边走边想"，每一步都由 LLM 决定往哪个方向扩展，同时做剪枝，避免搜索空间爆炸。
- Reasoning-on-Graph (RoG)：先从 KG 中抽取子图，再让 LLM 在子图上做推理，支持自纠错。
- Plan-on-Graph (PoG)：引入自适应规划，让模型先制定推理计划再执行。
- Chain-of-Knowledge (CoK)：动态选择知识源并适配推理路径。
- EvoReasoner：基于演化式知识图谱构建和推理，这其实是论文作者团队自己的方法。
这些方法各有千秋，但之前缺少一个公平的"考场"来一较高下——尤其是一个不存在数据污染问题的考场。
🏗️ HybridRAG-Bench：一个自动造题的考试工厂
这是整篇论文最核心的贡献。HybridRAG-Bench 不是一个静态数据集，而是一个可配置的基准生成框架。你可以指定主题领域、时间窗口、问题类型和数量，框架会自动帮你生成一套高质量的多跳问答基准。
图1：HybridRAG-Bench 的四阶段流水线。用户输入时间范围、主题领域、论文数量、问题类型和数量，框架依次完成语料收集、知识图谱构建、QA生成和质量控制，最终输出可直接用于评估的基准数据。
整个流水线分四步走，每一步都有讲究。
Step 1：时间限定语料收集（Time-Framed Corpus Collection）
为什么要限定时间？ 这是对抗数据污染的关键一招。
做法很简单但很有效：只采集 LLM 预训练截止日期之后发表的 arXiv 论文。比如你用的模型训练数据截止到2024年6月，那就只收2024年7月之后的论文。这样模型不可能"见过"这些内容，回答问题时就只能依赖检索和推理，而不是靠记忆。
论文实验中构建了三个领域的数据集： - Arxiv-AI：人工智能方向（cs.AI），863个问题 - Arxiv-CY：密码学方向（cs.CY），966个问题
- Arxiv-BIO：计算生物学方向（q-bio），1040个问题
选这三个领域也有考量：AI 领域更新快、论文多，密码学偏形式化和精确，生物学偏跨学科和术语密集，三个领域特征互补。
Step 2：知识图谱构建（EvoKG）
有了语料之后，下一步是自动构建知识图谱。这里论文提出了 EvoKG（Evolutionary Knowledge Graph Construction），一个增量式的 KG 构建方法。
传统的 KG 构建方法（像 OpenIE）有个老毛病：实体碎片化。同一个概念在不同论文里可能有不同的表述——"large language model"、"LLM"、"大语言模型"——OpenIE 会把它们当成三个不同实体，导致图谱里充满冗余节点，关系也断裂了。
EvoKG 的做法是四步走：
- 实体和关系提取：用 LLM 从每篇论文中抽取候选实体和关系三元组。
- 实体对齐（Alignment）：基于文本嵌入做近邻搜索，判断新提取的实体是否对应已有节点。如果相似度超过阈值就合并，否则创建新节点。这一步用了 HNSW 索引，查询复杂度是 \(O(\log N)\)，不会随图谱规模爆炸。
- 关系规范化：同一对实体之间可能有多种描述方式的关系，EvoKG 会保留多个候选关系及其置信度，而不是硬选一个。
- 证据追踪：每条关系都链接回原始文本证据，这对后续生成"有据可查"的问题至关重要。
这套方法的效果如何？看 Table 5 的对比：
| 方法 | 事实恢复率（MINE 基准） |
|---|---|
| OpenIE | 29.36% |
| GraphRAG | 47.08% |
| KGGen | 66.46% |
| EvoKG | 71.36% |
EvoKG 以 71.36% 的事实恢复率拿下第一，比 GraphRAG 高了 24 个百分点，比最近的 KGGen 也高了近 5 个点。OpenIE 只有不到 30%，这也解释了为什么传统 KG 构建方法在下游任务中经常拖后腿。
再看成本和可扩展性。论文测量了处理不同长度语料时的 token 消耗和处理时间：
图2：KG 构建的 Token 消耗（y轴）与语料长度（x轴，字符数）的关系。散点分布基本呈线性趋势，没有出现超线性爆炸。
图3：KG 构建的处理时间（y轴，秒）与语料长度（x轴，字符数）的关系。趋势与 Token 消耗类似，确认了方法的可扩展性。
从图2和图3来看，token消耗和处理时间都与语料长度成近似线性关系。这意味着当你需要处理更多论文时，成本是可预测的、线性增长的，不会突然飙升。EvoKG 的总计算复杂度为 \(O(n \log N + m \log M)\)，其中 \(n, m\) 是新提取的实体/关系数量，\(N, M\) 是已有节点/边数量，瓶颈在于 HNSW 相似性搜索。而且由于每篇论文可以独立处理，框架天然支持数据并行，进一步压缩端到端时间。
Step 3：混合知识驱动的 QA 生成
KG 构建完成后，接下来要自动生成问答对。这一步的关键设计是六种问题类型，覆盖了从简单到复杂的完整推理谱系：
| 问题类型 | 说明 | 设计意图 |
|---|---|---|
| Single-hop | 单跳事实查询 | 基线能力，测检索准确性 |
| Single-hop w. Condition | 带约束条件的单跳 | 测精确过滤能力 |
| Multi-hop | 常规多跳推理 | 核心能力，需要链式推理 |
| Multi-hop (Difficult) | 困难多跳，路径经过高度节点 | 测抗干扰能力，高度节点有大量邻居 |
| Counterfactual | 反事实推理 | 测模型是否真正理解关系，而非模式匹配 |
| Open-ended | 开放式问题 | 测综合理解和生成能力 |
问题生成的流程是：从 KG 中采样推理路径 → 结合 KG 路径和对应的文本证据 → 用 LLM 根据模板和上下文示例生成问题 → 同时生成参考答案。
其中，困难多跳的设计特别巧妙：它要求推理路径经过"高度节点"（degree 很高的节点）。为什么？因为高度节点有大量邻居关系，就像一个路口连着十几条路——模型不仅要找到正确的路径，还要在众多干扰项中做出正确选择。这比普通多跳难得多。
反事实推理也很有意思：它生成的是"如果X不成立，那Y会怎样？"这类问题。这种问题逼迫模型真正理解因果关系，而不是简单地做模式匹配或者信息拼凑。
三个数据集的问题分布如下：
| 问题类型 | Arxiv-AI | Arxiv-CY | Arxiv-BIO |
|---|---|---|---|
| Single-hop | 249 (29%) | 238 (25%) | 264 (25%) |
| Single-hop w. Condition | 139 (16%) | 128 (13%) | 193 (19%) |
| Multi-hop | 165 (19%) | 149 (15%) | 195 (19%) |
| Multi-hop (Difficult) | 149 (17%) | 166 (17%) | 139 (13%) |
| Counterfactual | 114 (13%) | 173 (18%) | 59 (6%) |
| Open-ended | 47 (5%) | 112 (12%) | 190 (18%) |
| 总计 | 863 | 966 | 1040 |
可以看到各类型问题的比例在不同领域间有所变化——这不是bug，而是feature：不同领域的知识结构不同，自然会影响各类型问题的生成比例。比如 BIO 领域的开放式问题占比更高（18%），可能因为生物学研究中跨学科的综合性问题更多。
Step 4：质量控制
自动生成的问题不可能百分百靠谱，所以需要质量把关。论文设计了两道筛选：
- 可答性验证（Answerability）：用 LLM-as-a-Judge 检查每个问题是否能基于给定的上下文（KG路径 + 文本证据）回答。答不出来的直接淘汰。
- 独立性过滤（Independence）：过滤掉包含局部引用的问题，比如"in this paper"、"the above method"这种依赖特定论文上下文才能理解的表述。确保每个问题都是自包含的。
🧪 实验：14种方法的大考
实验设置覆盖了 4 个 LLM backbone × 14 种方法 × 3 个领域，每种配置跑 3 次取平均值和标准差。这个实验量说实话挺大的。
参赛选手一览
纯LLM方法（不用外部知识）： - IO：直接输入输出，不做任何额外引导 - CoT：Chain-of-Thought，让模型"一步步想" - SC：Self-Consistency，多次采样取多数投票
文本检索方法： - RAG：经典密集检索 + 上下文拼接
朴素KG增强： - 1-hop KG：把问题中实体的一跳邻居直接注入 - RAG + 1-hop KG：文本检索 + 一跳邻居，两条腿走路
KG-RAG方法（高级选手）： - CoK、RoG、ToG/ToG2.0、PoG、R2-KG、HippoRAG2.0、EvoReasoner
主实验结果
来看最核心的 Table 3。数据比较多，我挑关键信息聊：
DeepSeek V3.2 (685B) 上的表现
| 方法 | Arxiv-AI | Arxiv-CY | Arxiv-BIO |
|---|---|---|---|
| IO（纯记忆） | 37.75 | 43.62 | 39.88 |
| CoT | 36.69 | 39.50 | 39.75 |
| RAG | 43.68 | 41.82 | 48.61 |
| 1-hop KG | 27.55 | 29.63 | 40.67 |
| RAG+1-hop KG | 49.42 | 47.27 | 58.99 |
| ToG2.0 | 63.59 | 66.17 | 64.69 |
| HippoRAG2.0 | 62.39 | 58.57 | 62.19 |
| EvoReasoner | 75.69 | 69.15 | 75.92 |
几个关键发现：
发现一：纯靠记忆（IO/CoT/SC）真的不够用。 即使是 685B 参数的 DeepSeek V3.2，IO 准确率也只在 37-44% 之间。CoT 甚至还比 IO 低了一点（AI 领域 36.69 vs 37.75）——这说明链式思考在缺乏事实基础的情况下可能适得其反，模型"想多了"反而编出更多错误。
这个结果直接验证了基准的核心设计——时间窗口隔离确实管用。如果这些问题的答案已经在预训练数据里了，685B 的模型不可能只答对不到 40%。
发现二：1-hop KG 注入是个坑。 在 AI 领域只有 27.55%，比什么都不做的 IO（37.75%）还低了 10 个点！原因很直观：高度节点的一跳邻居可能有几十上百个三元组，一股脑塞进上下文不但没帮上忙，反而制造了大量噪声，把有用信息淹没了。
这就好比你问路去火车站，路人不是给你指个方向，而是把整张城市地图摊开在你面前——信息量是足够了，但反而更难找到你要的路线。
发现三：EvoReasoner 一骑绝尘。 在三个领域都拿到了最高分：AI 75.69%、CY 69.15%、BIO 75.92%。比第二名 ToG2.0 高了 5-12 个百分点。
跨模型一致性
把四个模型的结果放在一起看，EvoReasoner 的优势非常稳定：
| 模型 | EvoReasoner (AI/CY/BIO) | 次优方法 | 次优得分 |
|---|---|---|---|
| DeepSeek V3.2 685B | 75.69 / 69.15 / 75.92 | ToG2.0 | 63.59 / 66.17 / 64.69 |
| Qwen 2.5 72B | 71.30 / 66.89 / 73.31 | ToG2.0 | 58.61 / 59.05 / 60.36 |
| LLaMA 3.3 70B | 66.78 / 66.31 / 69.94 | ToG2.0 | 59.37 / 60.85 / 57.40 |
| LLaMA 3.1 8B | 55.74 / 55.22 / 58.13 | ToG2.0 | 49.25 / 51.91 / 51.58 |
几个有意思的观察：
- 即使是 8B 的小模型，EvoReasoner 也能达到 55-58% 的准确率，和 LLaMA 3.3 70B + ToG2.0 差不多。换句话说，好的推理框架可以弥补模型规模的差距。
- HippoRAG2.0 在 DeepSeek 上表现不错（62%左右），但换到 Qwen 上直接崩了（12-33%）。这种模型依赖性说明它的推理机制可能过度适配了某些模型的行为特征。
- RAG+1-hop KG 组合在 BIO 领域表现特别好（DeepSeek 上 58.99%），可能因为生物学知识图谱的结构更适合这种简单融合策略。
按问题类型细分：深水区在哪里？
Table 4 以 Qwen2.5-72B 为例，展示了不同方法在各类问题上的表现。这张表信息量很大，我摘录 Arxiv-AI 领域的关键对比：
| 方法 | Single-Hop | Single-Hop w.Cond | Multi-Hop | Multi-Hop (Hard) | Counterfactual | Open-ended |
|---|---|---|---|---|---|---|
| IO | 21.20 | 20.29 | 16.36 | 17.72 | 68.07 | 45.96 |
| RAG | 53.55 | 67.63 | 41.82 | 29.31 | 48.54 | 85.11 |
| RAG+1-hop KG | 58.77 | 65.47 | 42.22 | 32.21 | 37.72 | 82.98 |
| ToG2.0 | 59.52 | 54.82 | 44.73 | 43.89 | 90.35 | 83.40 |
| EvoReasoner | 71.75 | 75.54 | 65.86 | 53.47 | 88.30 | 90.78 |
这张表揭示了很多有趣的规律：
多跳推理是分水岭。 从 Single-Hop 到 Multi-Hop，再到 Multi-Hop (Hard)，所有方法的准确率都在下降，但下降幅度差别巨大。RAG 从 53.55% 掉到 29.31%（掉了 24 个点），而 EvoReasoner 从 71.75% 掉到 53.47%（只掉了 18 个点）。越是需要链式推理，结构化知识图谱的优势就越明显。
反事实推理结果出人意料。 IO（纯记忆）在反事实问题上拿到 68.07%，比 RAG（48.54%）和 RAG+1-hop KG（37.72%）都高。这是什么情况？
我的理解是：反事实问题需要的是"理解关系"而非"找事实"。模型要判断"如果X不成立会怎样"，这更接近逻辑推理而非信息检索。RAG 检索回来的都是"X确实成立"的证据，反而干扰了反事实推理。而 KG-RAG 方法（ToG2.0 拿到 90.35%）之所以表现好，是因为知识图谱提供了清晰的因果链，模型可以沿着因果链做"假设替换"。
这给我的启发是：不是所有问题都适合用检索来解决。 有时候，模型自己的推理能力反而比你塞给它的"参考资料"更可靠——前提是你塞的资料要对症，否则就是在帮倒忙。
开放式问题是 RAG 的舒适区。 RAG 在开放式问题上拿到 85.11%，几乎追平了 EvoReasoner 的 90.78%。这也合理：开放式问题对"精确答案"的要求低，只要检索到相关文档，模型就能综合生成一个像样的回答。
🔬 EvoKG：如何构建一个"好用"的知识图谱？
论文中 EvoKG 的设计思路值得单独拉出来聊，因为知识图谱的质量直接决定了下游推理的天花板。
现有方法的问题
传统 KG 构建管线通常是这样的：原始文本 → NER/关系抽取 → 三元组存储。问题出在"抽取"这一步：
- OpenIE 类方法：依赖句法规则，遇到复杂长句就抓瞎，实体边界识别不准，导致大量碎片化的、无意义的三元组。29.36% 的事实恢复率就说明了一切。
- GraphRAG：微软提出的方法，用 LLM 做社区检测和摘要，但它更偏向"文档聚类"而非"精确事实抽取"，47.08% 的恢复率虽然比 OpenIE 好不少，但距离实用还有差距。
- KGGen：最近的方法，66.46% 已经不错了，但仍然缺少增量式的实体对齐机制，处理大规模语料时容易出现重复节点。
EvoKG 的四步法
EvoKG 的核心改进在于"增量演化"——不是一次性把所有文档处理完，而是一篇一篇地处理，每处理一篇新文档就更新现有图谱。这个过程类似于一个人不断学习新知识并整合进已有认知体系：
- 提取：让 LLM 从当前文档中提取所有实体和关系候选。
- 对齐：拿每个新实体去和已有图谱中的节点比对。用文本嵌入做 HNSW 近邻搜索——如果找到足够相似的已有节点（比如"LLM"和"Large Language Model"），就合并到已有节点上；如果没找到相似的，就创建新节点。
- 规范化：同一对实体间可能有多种关系描述（"A proposes B"和"A introduces B"），EvoKG 不强制选一个，而是都保留，同时记录置信度。
- 追溯：每条关系都记录来源文本，形成"关系→证据"的完整链路。
这种增量式设计带来两个好处：一是避免了实体碎片化（通过对齐），二是成本可控（每篇文档独立处理，可并行）。
🤔 我的分析和思考
这篇论文做对了什么？
1. 抓住了真问题。 数据污染和单模态评测，这两个痛点确实是当前 RAG 研究中最被忽视的问题。很多论文在 HotpotQA 上刷到 80+ 的 F1，然后声称自己的方法"显著优于"baseline，但你把数据换成模型没见过的，成绩可能直接腰斩。
2. 框架设计而非静态数据集。 HybridRAG-Bench 是一个"造题工厂"，不是一个固定的题库。这意味着它可以随着时间推移持续生成新的基准——只要你调整时间窗口，就能保证数据对最新模型仍然"新鲜"。这个设计比做一个一次性数据集聪明多了。
3. 实验规模和严谨度。 4个模型 × 14种方法 × 3个领域 × 3次重复，每个实验都报了标准差。在这个领域的论文里，这种实验规模属于中上水平。
哪些地方有疑问？
1. EvoReasoner 是作者自己的方法。 论文提出了一个基准框架，然后在这个框架上测试了自己的方法并拿到了最好成绩——这个narrative虽然逻辑上没问题（如果框架是公平的话），但总觉得有点"既当裁判又当运动员"的味道。
公平地说，论文开源了框架和数据，其他研究者可以自己验证。但如果是别的团队用这个框架测出了类似的结论，说服力会更强。
2. EvoKG 和 EvoReasoner 的耦合度。 EvoReasoner 在 EvoKG 构建的图谱上表现最好，这并不奇怪——它们是同一团队设计的，天然有"协同设计"的优势。我更好奇的是：如果把 EvoReasoner 放到 GraphRAG 或 KGGen 构建的图谱上，表现会怎样？反过来，如果把 ToG2.0 放到 EvoKG 图谱上，能不能缩小差距？论文没有做这个消融实验，有点可惜。
3. 评估方式的局限。 论文使用 LLM-as-a-Judge 做答案评估，判断生成答案和参考答案是否语义一致。这种评估方式本身就有噪声——不同的 judge 模型可能给出不同的判断，而且对于开放式问题，什么算"正确"本身就是模糊的。论文虽然跑了 3 次取平均来降低方差，但评估本身的偏差可能更大。
对工程落地的启示
1. 别迷信"越多信息越好"。 1-hop KG 注入的惨败说明，盲目塞信息不如精准检索。在工程实践中，宁可花力气做好相关性排序和噪声过滤，也不要一股脑把所有"可能相关"的知识都塞进上下文窗口。
2. 混合策略比单一策略好。 RAG+1-hop KG 的组合在多数场景下优于单独的 RAG 或 1-hop KG。这提示我们：在构建 RAG 系统时，可以考虑同时维护一个轻量级的知识图谱作为"骨架"，文本检索提供细节，KG 提供关系结构。
3. 问题类型决定方法选择。 不同类型的问题适合不同的方法。如果你的业务场景主要是事实查询（单跳），标准 RAG 就够了；如果涉及多跳推理或因果分析，就值得投入精力搞 KG-RAG；如果主要是开放式问答，RAG 的性价比反而最高。
4. 小模型 + 好框架 ≈ 大模型 + 差框架。 LLaMA 3.1 8B + EvoReasoner（~56%）和 LLaMA 3.3 70B + RAG+1-hop KG（~50%）的表现差不多。在推理成本敏感的场景下，投资一个好的推理框架可能比换更大的模型更划算。
📊 关键实验结果总结
把整篇论文的核心发现浓缩成几条：
| 编号 | 发现 | 数据支撑 |
|---|---|---|
| 1 | 时间窗口隔离有效消除了数据污染 | 685B 模型 IO 只有 37-44%，说明无法靠记忆作弊 |
| 2 | RAG 比纯 LLM 提升明显 | RAG vs IO 平均提升 7-29 个百分点 |
| 3 | 朴素 KG 注入可能帮倒忙 | 1-hop KG 多次低于 IO baseline |
| 4 | 混合 KG-RAG 在多跳问题上优势显著 | EvoReasoner 多跳准确率 65.86% vs RAG 41.82% |
| 5 | 反事实推理需要结构化知识 | ToG2.0/EvoReasoner >88% vs RAG <49% |
| 6 | 好框架弥补模型规模差距 | 8B + EvoReasoner ≈ 70B + RAG |
💡 写在最后
HybridRAG-Bench 这篇论文最大的价值，可能不在于它测出了哪个方法最好（毕竟作者自己的方法赢了，这个结论需要更多独立验证），而在于它提供了一个可持续、可复现、抗污染的评测框架。
RAG 领域现在有点像几年前的 NLP——各家都在自己选的基准上刷分，缺少一个公认的、持续更新的"高考"。HybridRAG-Bench 的时间窗口机制让它天然具备"保鲜"能力：只要 arXiv 上还有新论文发表，它就能源源不断地生成新的测试题。
另一个值得关注的趋势是：知识图谱正在 RAG 体系中找到自己的生态位。不是替代文本检索，而是互补——文本提供细节和上下文，KG 提供结构和关系。EvoReasoner 在反事实推理和多跳问题上的优势，恰恰说明了结构化知识在"推理"（而非"检索"）任务中的不可替代性。
对于做 RAG 系统的工程师来说，这篇论文传递的核心信息是：别把所有问题当成同一类问题来处理。简单的事实查询用标准 RAG 就好，复杂的多跳推理值得引入知识图谱，而反事实或假设性问题可能需要完全不同的推理策略。一个真正好用的 RAG 系统，应该能根据问题类型动态选择推理路径——这也是未来研究的一个值得深挖的方向。
论文信息 - 标题：How Much Reasoning Do Retrieval-Augmented Models Add beyond LLMs? A Benchmarking Framework for Multi-Hop Inference over Hybrid Knowledge - 作者：来自 Emory University 和 Amazon 的研究团队 - 链接：https://arxiv.org/abs/2602.10210 - 代码/数据：论文提到将开源框架和数据