检索系统不用二选一了：RetrievalRouter 给每条查询挑一条「刚好够用」的流水线

上周翻 arXiv 的时候看到一篇论文，解决的是一个做 RAG 的人几乎都纠结过的问题：线上检索系统到底用哪条流水线？上 ColPali 这类多模态 late-interaction 模型，精度是好看，但单查询 8 秒多的延迟根本没法上线；退回到 BM25 或者稠密向量，延迟下来了，遇到图表密集的文档又集体翻车。大部分人最后的选择是——拍脑袋定一条，然后对所有查询一刀切。

这篇论文（arXiv: 2608.25625）的核心观点就一句话：这个妥协是多余的，因为不是每条查询都需要同一条流水线。

核心摘要

RetrievalRouter 是一个轻量的查询感知路由器：只看查询文本本身，就为它挑选一条检索流水线——从 BM25 到多模态重排序一共 5 条候选。训练时用一个可调参数 \(\lambda\) 平衡精度和延迟，扫一遍 \(\lambda\) 就能画出整条精度-延迟帕累托前沿。结果相当能打：在 11 个金融、科学、开放域基准上，它比最强的静态流水线（多模态 late-interaction）精度高 2.5 个点，同时快 12.4 倍；对比此前的自适应策略选择方法（Arabzadeh et al. 2021），在精度优先的设定下 nDCG@5 显著更高，延迟优先的设定下也不落下风。我的判断：这不是底层模型突破，而是一个定位很准的工程范式论文——它把「检索选型」从架构问题重新定义为路由问题，而且给出了可直接复现的代码和 8 万多条查询级标签。做企业文档检索的值得细看。

论文信息

  • 标题：RetrievalRouter: Joint Modality and Architecture Selection for Document Retrieval
  • 作者：Emre Kuru、Mehmet Onur Keskin、Reza Farahbakhsh、Noel Crespi
  • 机构：SAMOVAR, Télécom SudParis, Institut Polytechnique de Paris（法国）；Özyeğin University（土耳其）
  • 日期：2026 年 8 月 26 日
  • 链接：https://arxiv.org/abs/2608.25625 ｜ 代码：https://github.com/emrekuruu/retrieval-router

📖 为什么需要这篇论文

先交代一下背景。现代文档检索流水线沿着两个轴展开：

  • 模态轴：纯文本流水线（先把 PDF 解析成文本再检索）vs 多模态流水线（直接把渲染后的页面截图丢给视觉模型，比如 ColPali 那一系）；
  • 架构轴：稠密检索（整篇文档压成一个向量，快）vs late-interaction（保留 token/patch 级的细粒度向量，准但贵，ColBERT 范式）。

两条轴交叉，再算上重排序变体，作者搭了 7 条流水线出来：

缩写 流水线 底层模型 特点
BM25 文本稀疏 词项匹配 最快，零嵌入开销
TD 文本稠密 Linq-Embed-Mistral 单向量语义匹配
TL 文本 late-interaction GTE-ModernColBERT 文本侧最准也最慢
TR 文本重排序 TD 粗排 + TL 精排 工业界标准部署形态
MD 多模态稠密 Nomic-Embed-Multimodal 页面截图单向量
ML 多模态 late-interaction ColNomic（ColPali 式） 全场最准，慢到离谱
MR 多模态重排序 MD 粗排 + ML 精排 多模态侧的部署形态

有个细节值得注意：为了让对比公平，作者还用 Gemini 3.0 Flash 给所有文本流水线的图表、表格做了 caption 拼接进索引。也就是说，文本流水线的任何落后都不能甩锅给「看不到图」，纯粹是架构能力问题。这个实验控制做得挺讲究的。

问题在于——没有一条静态流水线是全能的。文本流水线在视觉复杂的文档上集体跳水；多模态流水线在需要长程文本推理的查询上又反过来输；late-interaction 准但贵；稠密快但在一部分查询上就是检不对。传统做法是设计时选一条，然后让每条查询都付同样的代价。

作者给出的替代方案直觉上很简单：每条查询分派到「能答对它的最便宜的那条流水线」。简单查询省下来的钱，正好补贴给真正需要重武器的难查询。

论文里 Figure 1 给了三个很直观的例子：问「红色柱状图展示了什么」——文本流水线根本感知不到颜色，必须走多模态；问「CEO 是谁」——关键词直接命中，BM25 足矣，上神经网络纯属浪费；问「Q4 业绩是否符合 Q1 预期」——证据分散在长文档两端，稠密检索把全文平均成一个向量会丢失这种远端结构，必须上 late-interaction。

🧠 RetrievalRouter 怎么做

动作空间：7 条流水线砍到 5 条

路由器在 \(\mathcal{A}=\{\text{BM25}, \text{TD}, \text{TR}, \text{MD}, \text{MR}\}\) 这 5 条流水线里选。纯 late-interaction 的 TL 和 ML 被移出了动作空间，只留作静态 baseline——因为预实验发现重排序变体（TR/MR）用低得多的延迟就能拿到几乎相同的精度，同时保留两对近似冗余的动作只会让路由信号更难学。这个裁减很务实。

奖励函数：一个旋钮调出整条前沿

每条流水线 \(p_i\) 在查询 \(q\) 上的奖励定义为：

\[r_i(q) = (1-\lambda)\cdot s_i(q) + \lambda\cdot\left(1-\ell_i(q)\right)\]

其中 \(s_i(q)\) 是该流水线的 nDCG@5，\(\ell_i(q)\) 是归一化延迟（单条流水线延迟除以 5 条流水线的延迟总和）。\(\lambda=0\) 时只看精度，\(\lambda\to1\) 时只奖励快。训练时扫不同的 \(\lambda\)，就能描出整条精度-延迟帕累托前沿——部署方拿到的是一条曲线，而不是一个固定点，想要多准多快自己选工作点。这个设计对工程落地很友好。

训练目标：软标签是这篇论文真正的技术点

这里有个值得展开讲的决策。最直觉的做法是硬标签：每条查询标上「最优流水线」，训练一个分类器。作者明确拒绝了这条路——因为很多查询上多条流水线检出的文档完全一样，nDCG 打平，硬逼路由器选一个任意赢家，等于往训练数据里注噪声。

他们改成软标签：把 5 条流水线的奖励向量过一个小温度 softmax 作为目标分布：

\[\tilde{p}_i(q) = \frac{\exp(r_i(q)/\tau)}{\sum_{p_j\in\mathcal{A}} \exp(r_j(q)/\tau)},\quad \tau=0.1\]

为什么温度要压到 0.1？奖励都在 \([0,1]\) 区间，且大多数查询上各流水线都打平、挤在一个窄带里，标准 softmax（\(\tau=1\)）会得到接近均匀的目标分布，训练信号被稀释——尤其在简单查询上，唯一的区分度就是延迟。小温度把微小的奖励差距放大成明确的偏好，而真正打平的依然保持打平。这个细节说实话挺精巧的，我之前做类似的多模型选择时也踩过「目标分布太平导致模型学成均匀输出」的坑，当时的解法是加 margin loss，没有这个干净。

最终目标是路由器预测分布与目标分布的 KL 散度：

\[\mathcal{L}(\theta) = \sum_{q\in\mathcal{D}_{\text{train}}} D_{\text{KL}}\left(\tilde{\mathbf{p}}(q)\,\big\|\,\pi_\theta(\cdot\mid q)\right)\]

全零奖励的查询（所有流水线都失败的）在 \(\lambda=0\) 时被踢出梯度，因为它们不含任何选择信号。

路由器本身有多重

编码器是 Qwen3-0.6B-Base，冻结主干，只在注意力和 FFN 投影上挂 LoRA；最后一层隐状态 mean-pooling 成 1024 维查询向量，上面接一个线性层输出 5 个 arm 的 logits。推理开销 15ms——相对于它省下的秒级延迟，基本可以忽略。

📊 实验：数据说话

评测横跨 11 个数据集（REAL-MM-RAG、T2-RAGBench、MMDocRAG 三个基准的金融报告、幻灯片、科学论文、长文档 QA 等），所有系统跑在同一块 H100 80GB 上测延迟，统计显著性用配对 t 检验 / Wilcoxon + Holm 校正，报 \(p\lt0.001\)。实验规范度没得挑。

静态流水线：没有全能选手

流水线 nDCG@5 MRR@5 Recall@5 平均延迟(s) P95(s)
BM25 0.510 0.476 0.613 0.019 0.046
TD 0.492 0.456 0.601 0.455 0.845
TR 0.604 0.572 0.702 0.924 1.665
TL 0.597 0.560 0.706 2.796 5.717
MD 0.666 0.629 0.779 0.385 0.792
MR 0.733 0.701 0.830 1.121 1.967
ML 0.737 0.704 0.834 8.283 17.744

表 1：7 条静态流水线的整体表现。注意 TD（0.492）甚至低于 BM25（0.510）——文本稠密检索在这些文档上并没有占到便宜。

最准的 ML 平均每条查询 8.3 秒，P95 接近 18 秒——这个延迟在任何线上系统里都是不可接受的。而它的重排序变体 MR 用 1.1 秒拿到 0.733，几乎追平。这印证了一个工业界共识：late-interaction 的正确部署方式就是重排序，纯 late-interaction 全库跑基本只存在于论文里。

帕累托前沿：路由器支配所有静态点

图 2：精度-延迟工作点全景。绿色阴影区是「想要区」——比最准静态流水线更准、且平均延迟低于 1 秒。RetrievalRouter（蓝色方块）整条曲线都在 Arabzadeh baseline（紫色虚线）上方，且在 \(\lambda=0\) 和 \(\lambda=0.1\) 处进入绿色区域

图 2：所有方法的精度-效率工作点。横轴是对数刻度的平均延迟，纵轴 nDCG@5。

看这张图最直观。所有静态流水线（红点）分布在右下和左上两个「难受区」：要么快而不准，要么准而不快。RetrievalRouter 的蓝线则穿过绿色阴影区——比最准的静态流水线还准，延迟却在 1 秒以内。几个关键工作点：

  • \(\lambda=0.1\)：0.755 nDCG@5、0.666 秒。比 ML 高 2.5 个点、快 12.4 倍；比 MR 高 3.0 个点、快 1.7 倍；
  • \(\lambda=0.5\)：0.707 nDCG@5、0.314 秒。比 MD 高 6.2 个点、比 TD 高 43.6 个点，还更快；
  • \(\lambda=1\)：全部查询走 BM25，加上路由开销总延迟 0.034 秒，仍然快过所有神经静态流水线。

路由器自身的 15ms 开销只在大量查询走 BM25 时才显眼（0.019s 涨到 0.034s），即便那样也还是全场最快。

对比此前的自适应方法

跟 Arabzadeh et al.（2021）的策略选择方法正面刚：

\(\lambda\) RetrievalRouter nDCG 延迟(s) Arabzadeh nDCG 延迟(s) Oracle nDCG
0.00 0.755 † 0.821 0.712 0.522 † 0.901
0.10 0.755 † 0.666 0.715 0.476 † 0.901
0.30 0.742 † 0.469 0.706 0.382 † 0.901
0.50 0.707 † 0.314 0.678 0.276 † 0.893
0.70 0.630 0.148 0.624 0.171 0.829
1.00 0.510 0.034 0.510 0.034 0.510

表 2：自适应方法对比。† 表示 \(p\lt0.001\) 显著。

精度优先区间（\(\lambda\leq0.5\)），RetrievalRouter 的 nDCG 显著更高，但 baseline 显著更快——各赢一个轴；到了延迟优先的 \(\lambda=0.7\)，路由器在精度（0.630 vs 0.624）和延迟（0.148s vs 0.171s）上数值双赢，不过差异不显著。坦率的讲，这个「双赢但不显著」的表述作者写得挺诚实的，没有硬吹。

为什么会有这个差距？看路由分布就明白了：

图 3a：RetrievalRouter 的路由分布。即使 \(\lambda=0\)（纯精度目标），仍有 6% 的查询被分给 BM25（粉色），26% 给 MD（橙色），50% 给 MR（绿色）——它把 BM25 当作某些查询的最优解，而不是省钱备胎

图 3b：Arabzadeh baseline 的路由分布。\(\lambda=0\) 时 75% 查询堆在 MD（橙色）上，19% 给 TR（深蓝），BM25 一条都没有——硬标签天生学不出「贵但更好」的偏好

图 3：两种自适应方法在前沿上的流水线分配对比（粉=BM25，浅蓝=TD，深蓝=TR，橙=MD，绿=MR）。

Baseline 的硬标签是「能成功的最便宜流水线」，所以哪怕全压精度，它也只能学成「选第一个不失败的」，天然够不到「选最好的」。RetrievalRouter 的软标签直接来自完整奖励向量，\(\lambda=0\) 时延迟项消失，目标纯粹反映检索质量，该上重排序就上重排序。更让我印象深刻的一个数据：在 Wiki-SS 数据集上，即使 \(\lambda=0\)，路由器也把 20% 的查询分给了 BM25——因为在那个数据集上 BM25 确实打赢了 6 条神经流水线里的 4 条。词项匹配在合适的查询上就是最优解，这跟「BM25 只是省钱备胎」的刻板印象完全不同。

路由决策质量：对角线优势

图 4b：RetrievalRouter 的奖励热力图（\(\lambda=0.1\)）。行是被选中的流水线（括号是查询数），列是各流水线在这批查询上的奖励。对角线明显最深——被选中的流水线在它负责的查询上确实接近最优

图 4：路由决策热力图。MR 行（3,099 条难查询）里 BM25 的奖励只有 0.34，而 MR 自己 0.71——路由器没有「全局偏爱」某条流水线，而是按需激活。

热力图验证了路由器学到的是有意义的选择：Oracle 和路由器都呈现强对角线模式。还有几个有意思的发现：纯 late-interaction 极少被 Oracle 选中（TL 只有 213 条、ML 只有 39 条，对比 TR 的 882 和 MR 的 1,068），重排序几乎总能接住；反过来，重排序也不是永远必要——Oracle 选中 MD 的 1,828 条查询上，MD 平均奖励 0.93，硬加一道重排序（MR）反而掉到 0.70。等等，重排序居然会把好结果排坏？这个数据说实话让我愣了一下，但想想也合理：粗排已经全对的情况下，精排只是在引入噪声。

模态敏感性：为什么单一模态不够用

作者用 DocLayout-YOLO 算了每个数据集的「视觉密度」（页面中非文本元素占比），然后看各流水线随密度变化的表现：

图 5：nDCG@5 随视觉内容密度的变化。BM25（粉色三角）从低密度区的 0.593 一路崩到高密度区的 0.292；文本系流水线整体下滑；多模态系（橙、绿）明显更稳；RetrievalRouter（紫色菱形）全程贴着多模态系上沿走

图 5：视觉密度 vs 检索精度。路由器（紫）始终压在单模态流水线上方。

反向的失败同样存在：在强调长程文本推理的 Wiki-SS 上，TL（0.784）反超 ML（0.743）和 MR（0.732），连 BM25（0.745）都赢了两条多模态 late-interaction。视觉编码器的 patch 结构在语言密集型任务上反而稀释了序列文本结构。路由器识别出了这种结构，在 Wiki-SS 上拿到 0.785，微微超过最强静态流水线。路由决策也确实跟着视觉密度走：\(\lambda=0\) 时多模态流水线的查询占比从低密度区的 69.7% 升到高密度区的 95.2%。

🤔 我的判断

这篇论文最值钱的地方：把一个业界天天靠拍脑袋解决的问题（检索流水线选型）形式化成了一个有原则的路由问题，而且解法足够轻——LoRA 微调的 0.6B 编码器加一个线性层，15ms 开销，换来的是整条帕累托前沿上的支配地位。软标签 + 小温度 softmax 的训练设计是对硬标签缺陷的清醒回应，这个思路可以直接迁移到任何「多模型/多策略选择」场景，比如模型路由、工具选择。

但要泼几盆冷水：

  1. 存储和显存代价被轻描淡写地放在了 Limitations 里。路由器要同时维护 4 个向量索引 + 1 个 BM25 词项索引，其中 ColPali 式的多模态 late-interaction 索引约 39GB，是文本稠密索引的 13 倍；所有模型常驻需要 40GB 显存。说白了，这是拿存储和显存换延迟——作者自己也承认这套方案只适合「延迟敏感、硬件成本次要」的场景。对很多团队来说，一张 H100 常驻 40GB 显存跑检索，账未必算得过来。

  2. 只看查询文本是有天花板的。像「总结第 5 页的表格」这种查询，语言上完全无法判断目标文档是信息图还是纯文本——最优流水线取决于文档的潜在版式，而不是查询意图。Oracle 的 0.90 nDCG 对比路由器的 0.755，这 14 个点的差距很大程度就卡在这里。作者提到的解法（先做探测性检索再分派）其实已经往级联系统的方向走了，跟路由范式谁更优，论文没答。

  3. 评测是 in-domain 的 80/10/10 切分。路由器可能学到的是「金融词汇 → 高视觉密度」这类领域表层线索，而不是真正的语义结构。作者的辩护（企业搜索引擎本来就是固定语料 + 已知查询分布）有一定道理，但零样本跨域泛化（比如在 ViDoRe 上测）没做，宣称的通用性要打个问号。

跟同期工作比，RouterRetriever 是在单一稠密架构内路由 LoRA 专家，MoR 是稀疏稠密加信任加权集成，Arabzadeh 是稀疏稠密二选一——RetrievalRouter 确实是第一个在同一语料上联合路由「模态 × 架构」两个轴的。这个定位是真的，不算营销话术。

工程启发：如果你在维护一个文档检索服务，且流量里混着「CEO 是谁」这类白给查询和「Q4 对比 Q1」这类硬骨头，这个思路值得认真考虑——哪怕不照搬它的路由器，「给每条查询算一遍各流水线奖励、扫一个 \(\lambda\) 选工作点」的评估框架本身就很有用。它还顺手开源了 8 万多条查询级最优流水线标签，做模型路由研究的人可以直接拿去用。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我