QueryFlow: Multi-Hop Graph Retrieval with Adaptive Query Evolution

这篇论文做了一个边找边改问题的多跳图检索器 QueryFlow：图上每传播一层，它就把已找到的上下文压成一个摘要向量，并入问题状态，再用新的问题状态引导下一层怎么找。之前的图检索器，比如 GFM-RAG，整个传播过程一直用最初的问题当条件。可多跳问答里，有些证据单看原问题并不相关，要先找到中间的事实才显得有用。在四个多跳问答数据集上，和 GFM-RAG 比，前 10 条结果凑齐全部所需证据的比例平均提高 8.40 个百分点，大模型答对的比例提高 11.6 个百分点。问题状态随已知信息更新，比固定问题更容易把证据找全。

做多跳检索的团队值得读。它没有引入新的大模型调用，改动全在图检索内部：每次更新问题状态，是对全图实体做一次注意力汇总，再过一个 GRU，都是张量运算。这和"让大模型一轮轮改写查询"的迭代检索不同：那类方法每轮都要调用一次大模型，花 token。在答题准确率上，QueryFlow 比答题最强的对手 LinearRAG 也高 8.0 个百分点。

它到底在解决什么问题

拿论文图 1 的例子：问"《霍比特人》的作者出生在哪里"。要答对，需要两篇文档：一篇写《霍比特人》的作者是托尔金，另一篇写托尔金出生在布隆方丹。只拿原问题去比，第二篇很难排到前面。

这类问题用"完全召回"衡量最直接：一道题需要的文档全部出现在前 k 条里才算 1，缺一篇就算 0（论文记作 FR@k）。R@k 在缺一篇时也能拿到不错的分数，可生成环节缺了这一篇往往就答不出来。

整体流程

QueryFlow 建在一张实体图上。离线阶段从文档里抽出实体和实体之间的关系，再记下每个实体出现在哪些文档里。在线检索一道题时，流程是：

1. 用冻结的文本编码器把问题编成向量，作为初始的问题状态；问题里提到的实体在图上被标为起点。
2. 在图上传播 6 层。传播开始前，起点实体的表示就是初始问题状态，其余实体从零开始；每种关系的向量来自同一个编码器对关系名称的编码。每层里，每个实体收集邻居发来的消息，再和自己原来的表示合在一起，得到新表示。
3. 相邻两层之间（共 5 次），用当前的问题状态把全图的实体表示汇总成一个向量，再把它并进问题状态，供下一层使用。
4. 6 层传播结束后，给每个实体打分，再把实体分数汇总到它所在的文档上，取分数最高的 k 篇交给大模型作答。

设计的关键分工是：实体表示负责积累图上找到的关系，问题状态负责决定下一层往哪个方向找。下面拆开讲第 3 步，以及问题状态怎样影响下一层。

问题状态怎么更新

问题状态是一个 512 维的向量，开头就是问题本身的编码。除最后一层外，每层传播结束后，它分两步更新。

第一步是汇总。用上一层的问题状态和每个实体的表示算一个相似度，所有实体按相似度用 softmax 分到权重，再把实体表示加权平均。和当前问题越对得上的实体，在汇总里分量越重。不管图有多大，汇总出来都是一个固定长度的向量。

第二步是并入。一个 GRU 拿汇总向量和旧的问题状态算出一个候选新状态；另一个门再按每一维决定新旧之间的差值收进来多少。沿用托尔金的例子（示意）：第一层传播后，"托尔金"这个实体的表示里已经带上了"《霍比特人》的作者"这层关系，汇总时它的权重高，于是更新后的问题状态往"托尔金"这一侧偏了一些。 Hoot 说▾

Hoot 说问题状态一次更新怎么走（示意）收起 ✕

先按相关程度汇总实体，再逐维决定改多少。同样的差值，门开得大就多收，门开得小就几乎不动。

1. 示意：某一维旧值 0.2，候选值 1.0，差值是 0.8。
2. 门值 0.9：收进 0.72，这一维变成 0.92，几乎走到候选。
3. 门值 0.1：只收进 0.08，这一维变成 0.28，基本不动。

示意例子，数字不是论文结果。和问题对得上的实体在汇总里分量大。GRU 给出一个候选新状态。门按每一维决定朝候选走多远。所以问题状态是一点点偏过去，不是整个换掉。 出处: 论文 §3.3 问题状态更新（汇总、GRU、逐维门、归一化）；数字为示意

为什么不干脆每轮让大模型改写一次查询？那样每轮都要一次大模型调用。QueryFlow 的更新全是图上的张量运算，检索器本身不花 API token。

新的问题状态怎样影响下一层

问题状态通过两个接口作用在下一层传播上。

第一个是起点注入（论文叫 boundary feedback）。每一层都会把当前的问题状态重新加到起点实体上。起点始终是问题里提到的那几个实体，但注入的内容随问题状态变。这样，后面几层的传播里一直带着最新的检索意图。

第二个是关系门（论文叫 relation feedback）。图上每种关系有自己的向量，比如"作者是""出生于"。问题状态生成一组 0 到 1 之间的门，按维度去乘这些关系向量，所有关系共用同一组门。乘完之后，每层再用自己的一个两层 MLP 变换一次，得到这一层用的关系向量。一条消息沿边传过去时，邻居的表示按维度乘上调过的关系向量，就是这条消息。一个实体收到的所有消息直接相加，起点实体还要再加上注入的问题状态；这个和与实体原来的表示拼在一起，经过一层线性变换和归一化，再加回原表示，得到新表示。效果上，问题状态可以放大或压低关系向量里的某些维度，从而改变邻居消息怎么传。

最后打分时，模型用的不是更新后的问题状态，而是最初的问题向量。它把这个向量和每个实体的最终表示拼起来，送进一个两层 MLP，输出这个实体的分数。作者的考虑是：更新过的问题状态负责引导传播，最终相关性仍对准原问题。消融显示这样做更好，如果在第 6 层之后再做一次更新，用得到的问题状态打分，FR@10 低 1.82 个点。这个状态只在这个消融里出现。

实体分数到文档分数这一步也有个细节。每个实体的分数先变成正数，再加到它出现过的每篇文档上；一个实体出现在越多文档里，分给每篇的份额越小。比如"美国"这种到处出现的实体（示意），它给每篇文档加的分就很少。

训练和评测

训练用的是三个数据集（2WikiMultiHopQA、HotpotQA、MuSiQue）训练集里的 6 万道题。监督信号是每道题的一组支撑实体，损失只在实体打分上算，让支撑实体的分数高于其他实体。问题状态的更新模块也是通过它对后续传播和实体分数的影响一起学出来的。检索时用不到这些标注。

评测用这三个数据集验证集里的固定子集：2WikiMultiHopQA 和 HotpotQA 各 1,000 题，MuSiQue 1,003 题，再加上没有参与训练的 ConcurrentQA 全部 1,600 道验证题。评测时，"需要的文档"来自各数据集标注的支撑文档，只用来算 R@k 和 FR@k。检索器在线时只看问题、问题里链接到的实体和离线建好的图。所有方法都用 Qwen3.5-9B 根据检索结果作答，答案由大模型裁判判对错，记作 LLM-Acc。

结果说明了什么

检索数字是四个数据集的平均（%），LLM-Acc 是平均答对比例。LinearRAG 不在论文的检索对比里，只比较了答题结果。

和 GFM-RAG 比，R@10 提高 4.98 个点，FR@10 提高 8.40 个点。完全召回涨得更多，说明收益主要来自补上最后缺的那篇。MuSiQue 上更明显：HippoRAG 2 的 R@10 比 QueryFlow 高（64.42% 对 61.60%），FR@10 却低（31.11% 对 37.82%）。只看平均召回，会看不出谁更常把一道题的证据凑齐。

问题状态的更新到底贡献多少？并入那一步里，新旧差值加回问题状态之前，要先乘一个 0 到 1 的系数，论文叫更新强度，完整模型取 1。作者用同一个训练好的模型，把这个系数设为 0，跳过并入，让问题状态一直停在初始值。这时 FR@10 从 70.38% 降到 61.78%，论文报告的差距是 8.59 个点，说明这个模型很依赖问题状态的更新。

四个数据集都在掉，ConcurrentQA 掉得最多，达 15.51 个点，2WikiMultiHopQA 最少，只有 2.50 个点。两个接口分开去掉，起点注入影响更大：去掉它 FR@10 少 4.73 个点，去掉关系门少 3.44 个点。

需要 4 篇文档的题，收益最大。和 GFM-RAG 在 4,596 道共同的题上逐题对比，需要 4 篇文档的题，FR@10 从 32.16% 提到 50.25%。在全部 4,596 道共同题上，QueryFlow 新凑齐 434 道，丢掉 86 道，净多 348 道；GFM-RAG 凑齐的题里，97.0% QueryFlow 也凑齐了，说明它多凑齐的题远多于丢掉的题。论文也提醒，支撑集大小和数据集构成有关；这组数字按题数汇总，不是四个数据集的平均。

在线成本上，在 2WikiMultiHopQA 的 1,000 道评测题上，处理问题、检索加答题总共 580 秒，GFM-RAG 要 5,960 秒；token 用量从 544 万降到 359 万。这个差距不该算作问题更新的功劳，问题更新本身只会多出计算。QueryFlow 只取前 5 篇时的完全召回（62.63%），已经略高于 GFM-RAG 取前 10 篇（61.98%），这意味着喂给大模型的上下文可以更短。

我认为它的局限

第一，"去掉问题更新"的对照没有重新训练。8.59 个点的差距来自把一个按更新训练好的模型直接冻住问题状态，这个模型从没学过在固定问题下传播，差距可能比"单独训练一个固定问题的模型"要大。最接近的固定问题基线是 GFM-RAG，两者共用建图和文档汇总方式，差距 8.40 个点。但两者的训练设置不一定相同，这也不是严格的同架构对照。

第二，训练集和评测集同源。三个数据集的训练集各取了 2 万道题，评测又用它们的验证集。唯一没参与训练的 ConcurrentQA 上 FR@10 仍比 GFM-RAG 高 6.90 个点，说明不全是记住了数据分布，但每个评测语料只有几千到一万多篇文档，离生产环境的语料还有距离。

第三，离线建图不便宜。在 2WikiMultiHopQA 上，建索引要用 1,120 万 token，和 GFM-RAG 相当，而且整个方法依赖实体抽取和实体链接的质量。

第四，所有结果来自同一个随机种子的一次训练。1 到 5 个点的消融差距，还需要多次训练来确认。

一个检索团队可以怎么试

1. 先在自己的多跳问题上统计完全召回。挑一批需要两三篇文档才能答的 query，看现有检索的 R@10 和 FR@10 差多少；如果 FR@10 本身已经不低，两者差距又小，证据凑不齐就不是主要问题。
2. 如果已经在用 GFM-RAG 这类基于实体图的检索器，架构上的改动不大：加注意力汇总、GRU、更新门和关系门。但要用带支撑实体标签的数据重新训练整个检索器。问题状态更新是前提；两个接口里，去掉起点注入影响更大，要裁剪时优先保留它。
3. 用更新强度做开关。同一个模型把强度设成 0 和 1 各跑一遍，比较 FR@k，可以快速看出问题更新在你的数据上值多少。这个差距是上限估计，要知道真实增益，还要和单独训练的固定问题模型比。
4. 最后看能不能缩短上下文。如果前 5 篇的完全召回已经追上原来的前 10 篇，就可以减少喂给大模型的文档数，省下生成成本。

结论

一句话：多跳检索里，问题状态应该随已经找到的东西更新，而这件事可以在图检索内部用张量运算完成，不用调用大模型。