面向文档检索的模态与架构联合路由 RetrievalRouter: Joint Modality and Architecture Selection for Document Retrieval
仅凭查询文本为每个查询选择检索管线，比最强静态管线准确率高2.5%、速度快12.4倍
前置知识
BM25 稀疏检索
BM25 是基于词项频率和逆文档频率的经典概率检索算法，直接对抽取出的文档文本做关键词匹配，不需要任何神经网络编码，也无需生成向量嵌入。它的优点是延迟极低（本文中平均每查询仅 0.019 秒）且在精确关键词匹配场景下表现出人意料地好，缺点是完全无法感知文档的视觉内容和语义改写。
BM25 是本文路由动作空间中最便宜的一个臂，也是论文的重要发现之一：即使在纯准确率导向的设置下，路由器仍会把 6.0% 的查询分给 BM25，说明它不只是低成本的兜底选项。
稠密检索与双编码器
稠密检索用双编码器把查询和文档各自压缩成一个固定维度的向量（本文中文本用 Linq-Embed-Mistral，多模态用 Nomic-Embed-Multimodal），通过向量内积计算相似度。它比词项匹配更能捕捉语义相似性，但把整页文档平均成一个向量会丢失细粒度结构，是速度与精度之间的中间档。
稠密管线是路由动作空间的核心成员，理解单向量表示'平均化'文档结构的缺陷，才能理解为什么后期交互架构在某些查询上不可替代。
后期交互架构
后期交互以 ColBERT 为代表：文档侧保留每个 token（或视觉 patch）的细粒度嵌入，检索时再计算查询与文档之间的逐 token 最大相似度之和。它保留了文档的细粒度结构，特别适合证据分散在长文档两端的查询，但存储和计算开销远高于单向量稠密检索，是最准确也最慢的架构。
后期交互的纯版本（TL、ML）是本文静态基线中的精度上限，而它们的重排序变体（TR、MR）是工业界实际部署的形态，路由器必须同时支配这两类管线。
多模态视觉文档检索
以 ColPali 为代表的范式直接把渲染后的整页图像编码为视觉 patch 嵌入，跳过 OCR 和文本抽取步骤，从而保留表格、图表、版面等空间结构。它解决了文本抽取线性化文档导致的信息丢失问题，但视觉编码在需要长程文本推理的任务上会退化（如 VTCBench 所示）。
模态轴是本文路由的两大维度之一：多模态管线在视觉复杂文档上稳定，但在文本细微推理上输给文本管线，这种互补失败模式正是路由能够获益的根本原因。
重排序管线
重排序是工业界部署后期交互的标准方式：先用快速的稠密检索取回少量候选（本文 k=100），再只用昂贵的后期交互模型对这小批候选精细打分。它以远低于纯后期交互的延迟恢复几乎全部精度，本文中 MR 达到 0.733 nDCG@5、1.121 秒，接近 ML 的 0.737 但快 7 倍以上。
重排序变体是最强的可部署静态基线，也是路由器在准确率导向设置下主要超越和调度的对象；论文还发现重排序并非总是有益，加在已被稠密管线正确回答的查询上反而把奖励从 0.93 拉低到 0.70。
nDCG@5 与软目标蒸馏
nDCG@5 是衡量排序质量的指标：考虑前 5 个结果的相关性等级并做折扣累积，越相关且越靠前得分越高。软目标蒸馏则不用单个硬标签而用完整的目标概率分布训练学生模型，通常通过带温度参数的 softmax 把标量奖励向量转成分布，再用 KL 散度约束学生输出逼近它。
本文训练路由器的关键设计是把每个查询在五个管线上的完整奖励向量经温度 $\tau=0.1$ 的 softmax 变成软目标，再最小化 KL 散度，这直接避免了硬标签在管线并列时的标签噪声问题。
研究动机
现代文档检索支撑着金融、医疗、法律等高风险领域的信息获取，漏掉关键证据可能导致缺乏依据的决策。当前检索管线沿两条设计轴变化：模态轴上，文本管线对抽取出的文本做检索，而多模态管线直接对渲染后的页面图像编码；架构轴上，稠密检索把每页压成单个向量追求速度，后期交互保留逐 token 细粒度嵌入换取精度。这些选择构成了一个残酷的权衡：在 11 个基准上的实测显示，最准确的多模态后期交互管线 ML 达到 0.737 nDCG@5 但每查询耗时 8.283 秒，P95 延迟高达 17.744 秒；最快的 BM25 只要 0.019 秒却只有 0.510 的 nDCG@5。更糟的是失败是不对称且依赖查询的：文本管线因 OCR 抽取错误和版面丢失在视觉复杂文档上急剧退化（BM25 在高视觉密度数据上从 0.593 跌至 0.292），而多模态管线在需要长程文本推理的任务上落后（Wiki-SS 上 TL 0.784 反超 ML 的 0.743）。没有原则性的方法预测哪个查询需要哪种管线，实践者只能在设计时固定一个配置，在每个查询上付出全部代价。
本文的目标是本文的目标是证明这一权衡是不必要的：并非每个查询都需要同一条管线。作者要构建一个轻量的查询感知路由器 RetrievalRouter，仅从查询文本出发，同时预测该查询应使用的检索模态（文本还是多模态）和检索架构（稀疏、稠密还是重排序）。具体而言，路由器在五个动作 $\mathcal{A} = \{\text{BM25}, \text{TD}, \text{TR}, \text{MD}, \text{MR}\}$ 中选择，通过单一可调参数 $\lambda$ 暴露完整的准确率-延迟 Pareto 前沿，并要求对每一个静态基线都提供一个同时更准确且更快的操作点，同时超越已有的自适应策略选择方法。
与已有工作不同的是，已有自适应检索工作分三条线，都留下了联合路由的空白。第一条线决定是否检索或检索多深（如 Self-RAG、MBA-RAG 的 bandit 方法），但检索器本身固定；第二条线跨异构知识库或不同源模态路由，每个语料承担不同语义角色，与本文在单一语料上路由不同；第三条线最接近——在同一语料的不同检索器之间选择，如 Arabzadeh et al. (2021) 的稀疏/稠密策略选择、LiteGator 的延迟预算切换、RouterRetriever 的 LoRA 专家路由、MoR 的信任权重集成——但没有一个系统在模态和架构两条轴上做联合选择。此外，现有方法普遍使用硬标签训练：把'最便宜的成功管线'作为标签，这使模型永远无法纯准确率导向，且在多个管线并列时注入模型无法解决的标签噪声。本文用完整奖励向量的软目标训练绕开了这两个陷阱。
核心方法
RetrievalRouter 的整体思路是：既然七个静态管线（BM25、文本稠密 TD、文本后期交互 TL、文本重排序 TR、多模态稠密 MD、多模态后期交互 ML、多模态重排序 MR）占据准确率-延迟前沿的不同位置且无人支配全局，就训练一个小模型为每个查询挑最合适的那个。直觉上，判断一个查询需要看图还是看文本、需要粗排还是精排的信号就藏在措辞里——问'红色柱状图展示什么'必然需要多模态能力。技术上，先在 8 万多个训练查询上跑全部七个管线，记录各自的 nDCG@5 和墙钟延迟，按 $r_i(q) = (1-\lambda)\, s_i(q) + \lambda\,(1-\ell_i(q))$ 组合成每查询奖励，其中 $s_i(q)$ 是 nDCG@5，$\ell_i(q)$ 是按五臂总延迟归一化的延迟；奖励向量经温度 $\tau=0.1$ 的 softmax 变成软目标分布；再用 Qwen3-0.6B-Base 加 LoRA 编码查询，单线性头输出路由分布，最小化与软目标的 KL 散度。扫 $\lambda$ 从 0 到 1 即得完整 Pareto 前沿，推理时路由仅增加 15 毫秒开销。
核心创新是训练目标的设计：用完整奖励向量的软目标取代硬标签。作者发现对任一查询，多个管线经常检索出相同文档、在 nDCG@5 上打平，硬标签迫使路由器在并列者中挑一个任意赢家，注入了模型无从分辨的标签噪声；而软目标保留完整的每查询奖励分布，精确的平局仍是平局，奖励全零的查询在 $\lambda=0$ 时被剔除出梯度、在 $\lambda>0$ 时由延迟项提供效率信号。第二个关键决策是用单一路由器直接覆盖五个臂，而不是拆成模态路由器加架构路由器的两级结构：管线并非由模态和架构完全刻画，各自有独特的强弱项，判断哪个合适的信号存在于查询的潜在表示中，直接接触全部五个臂的路由器才能学到这些模式。奖励公式本身也把效率内生化为目标的一部分，使 BM25 在纯准确率设置下也能因为'就是最合适的管线'而被选中，而非作为预算耗尽后的兜底。
方法步骤详情
流程分六步。第一步语料准备：文档同时渲染成页面图像（供多模态管线）和抽取为文本，并用 Gemini 3.0 Flash 为图表生成描述拼接进文本索引，使剩余差距反映架构限制而非内容缺失。第二步 Oracle 标注：数据集按 80/10/10 划分，每个训练查询在单张 H100 上跑全部七个管线，记录 nDCG@5 和墙钟延迟。第三步构造奖励向量 $r_i(q) = (1-\lambda)\, s_i(q) + \lambda\,(1-\ell_i(q))$。第四步生成软目标：$\tilde{p}_i(q) = \exp(r_i(q)/\tau) / \sum_{p_j} \exp(r_j(q)/\tau)$，$\tau=0.1$ 由验证集选出，小温度把窄带奖励差放大成清晰偏好。第五步训练：冻结 Qwen3-0.6B-Base，LoRA（rank 16、$\alpha=32$，约 400 万参数）加在注意力与前馈投影，mean-pool 得 1024 维表示，单线性头输出五臂 logits，最小化 $\mathcal{D}_{\mathrm{KL}}(\tilde{p}(q) \| \pi_\theta(\cdot|q))$；128 token 截断，lr $10^{-4}$、有效批 32、2 epochs，每个 $\lambda$ 约 20 分钟。第六步推理：取 $\arg\max_{p_i \in \mathcal{A}} \pi_\theta(p_i|q)$ 分发查询。
技术新颖性
本文的新颖性体现在四个层面。系统层面，它是首个在单一底层语料上同时跨模态（文本/多模态）和架构（稠密/后期交互）两轴做联合路由的系统，此前的路由工作要么只换检索深度，要么只在稀疏/稠密间二选一，要么在域专家间选择。训练范式层面，软目标策略蒸馏是对 Arabzadeh et al. 硬标签策略选择的直接改进——实验证明这一改动带来可观测的行为差异：硬标签基线即使在等效 $\lambda=0$ 设置下也把绝大多数查询派给最便宜的成功管线 MD，永远无法纯准确率导向，而软目标路由器在 $\lambda=0$ 时仍把 6.0% 的查询留给 BM25，因为它学到的是'哪里稀疏匹配真正有效'而非'BM25 是低成本替代品'。接口层面，单一参数 $\lambda$ 通过训练时扫描就能追踪出完整的准确率-延迟 Pareto 前沿，比基线用概率阈值拟合 budget 的方式更干净。资源层面，论文发布了覆盖 8 万多个查询的每查询最优管线标签基准，为自适应检索研究提供了此前不存在的评测资产。
实验结果
静态格局（Table 1）：ML 以 0.737 nDCG@5 居首但耗时 8.283 秒，MR 0.733/1.121 秒几乎保住精度，MD 0.666/0.385 秒居中，BM25 最快 0.019 秒但仅 0.510——没有静态管线兼具后期交互的精度和轻量检索的延迟。路由器（Table 2）：$\lambda=0.1$ 时 0.755/0.666 秒，支配全部四个后期交互管线——比 ML 高 2.5% 且快 12.4 倍，比 MR 高 3.0% 且快 1.7 倍，比 TL 高 26.5% 且快 4.2 倍，比 TR 高 24.9% 且快 1.4 倍（均 $p<0.001$）；$\lambda=0.5$ 时 0.707/0.314 秒，支配稠密管线（比 MD 高 6.2%、快 1.2 倍；比 TD 高 43.6%、快 1.4 倍）；$\lambda=1$ 时全选 BM25，0.034 秒。对比自适应基线：$\lambda=0$ 至 0.5 下显著优于 Arabzadeh et al.（0.755 对 0.712，$p<0.001$），$\lambda=0.7$ 下数值双赢（0.630 对 0.624，0.148 对 0.171 秒）但不显著。Oracle 上界 0.901，留约 14 点空间。机理上：视觉密度升高时 BM25 从 0.593 跌到 0.292，路由器随之把多模态份额从 69.7% 提到 95.2%；重文本的 Wiki-SS 上路由器派 94% 查询给文本管线、20% 给 BM25，达 0.785 超最强静态管线；MD 被选中的 1,828 个查询上加重排序反把奖励从 0.93 拉低到 0.70。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 多模态文档检索（11 个基准聚合，准确率导向） | nDCG@5 | 0.755（RetrievalRouter，λ=0.1） | 0.737（最强静态管线 ML） | +2.5%，同时端到端平均延迟从 8.283s 降至 0.666s（快 12.4 倍），p<0.001 |
| 对比部署标准的重排序管线 | nDCG@5 | 0.755（λ=0.1） | 0.733（MR，重排序是工业界实际部署形态） | +3.0%，延迟从 1.121s 降至 0.666s（快 1.7 倍） |
| 查询级自适应策略选择（对比 Arabzadeh et al. 2021） | nDCG@5（λ=0，纯准确率设置） | 0.755 | 0.712（硬标签策略选择扩展到五管线） | +0.043 nDCG（p<0.001）；在 λ=0.7 延迟导向下也数值双赢：0.630 vs 0.624，0.148s vs 0.171s |
| 端到端延迟效率（中间档运行点） | 平均墙钟延迟/查询 | 0.314s（λ=0.5 时 nDCG@5 为 0.707） | 0.385s（MD，nDCG 0.666）；1.121s（MR，nDCG 0.733） | 比 MD 快 1.2 倍且高 6.2% 精度，比 MR 快 1.7 倍且高约 43.6% 相对提升对应的文本侧比较见 TD（+43.6%、1.4 倍） |
| 长程文本推理数据集 Wiki-SS | nDCG@5 | 0.785（路由器将 94% 查询派给文本管线、20% 给 BM25） | 0.784（TL，该数据集最强静态管线）；多模态 ML 仅 0.743 | 略超最强静态管线，验证路由器能识别'文本优于多模态'的数据集结构 |
| 每查询 Oracle 上界（七管线可选） | nDCG@5 | 0.755（λ=0/0.1 的最佳部署点） | 0.901（每查询选最优管线的不可部署上界） | 差距约 14 个 nDCG 点，量化了仅凭查询文本做路由的语义天花板 |
局限与改进
作者明确承认的局限包括：其一，存储成本——路由器需同时维护四个向量索引加一个 BM25 词法索引，多模态后期交互索引约 39 GB，是文本稠密索引（约 3 GB）的 13 倍，这种'以存储换延迟'的权衡只适合存储便宜、延迟敏感的云环境；其二，显存成本——同时在线运行全部管线需要约 40 GB VRAM；其三，实验采用数据集内 80/10/10 划分，只验证了域内泛化，路由器可能学到金融词汇等表面线索作为高视觉密度的代理特征，跨域零样本能力未知；其四，纯查询语义的歧义性构成根本天花板——诸如'总结第 5 页的表格'这类查询在文本和视觉文档中语言上完全相同，最优管线取决于目标文档的潜在版面而非查询意图，与 Oracle 的 14 点差距正源于此。我补充的观察：所有延迟测量都在同一张 H100 上完成，奖励中的归一化延迟在异构硬件或不同负载下会失真；λ=1 时路由开销使 BM25 延迟从 19 毫秒涨到 34 毫秒（+79%），对极端低延迟场景纯静态 BM25 仍更优；训练只跑单种子单次，未报告方差；语料仅覆盖英文。
独立分析的弱点
独立分析有五个弱点。第一，查询文本信息量的天花板：14 个 nDCG 点的 Oracle 差距说明很多查询的措辞无法揭示目标文档是信息图还是纯文本，改进方向是把路由从'先验猜测'改为'低成本试探'，例如先用稠密检索取回 top-1 页面的版面元数据作为决策条件。第二，资源门槛过高：39 GB 多模态索引加 40 GB VRAM 把中小团队排除在外，改进方向是索引蒸馏（聚合压缩 patch 级多向量）或级联式部署（只在线维护 MD 和 BM25，重管线按需加载）。第三，延迟模型脆弱：奖励中的归一化延迟假设各管线延迟比恒定，但检索延迟受缓存、批处理和硬件影响剧烈，在线漂移后 $\lambda$ 的语义就变了，改进方向是在线估计延迟并滑动更新。第四，未考虑路由错误的非对称代价：把需要 ML 的查询错派给 BM25 的损失远大于反向，但 KL 目标对称处理，应引入代价敏感加权。第五，域内 80/10/10 划分掩盖了分布漂移风险，企业查询分布随时间漂移时静态路由器会退化，可用 bandit 框架在线微调决策头。
未来方向
作者在局限部分提出了四个方向：在 ViDoRe v3 等多模态视觉文档基准上测试零样本跨域泛化；通过主动探测（exploratory dense retrieval 或部分元数据检查）在完整分发前解析文档级结构线索，突破纯语义路由的歧义天花板；把动作空间扩展到昂贵的生成式 LLM 重排序器（listwise/pointwise 推理）以及下游生成器模型规模的选择，构成完整的复合 AI 系统资源分配问题；与级联系统做系统对比。基于本文成果还可延伸：其一，把软目标路由框架推广到检索之外的管线选择场景（如 chunking 策略、OCR 引擎选择）；其二，发布的多查询标签基准天然支持'路由难度'研究——分析哪些查询特征导致 Oracle 与任何可学习路由器的差距，可能催生带不确定性估计的路由器；其三，多模态 patch 索引的 13 倍存储膨胀本身就是研究课题，token 剪枝或乘积量化对路由决策质量的影响值得量化；其四，把 λ 从离线训练旋钮变成运行时 SLO 接口，让同一模型在不重训的情况下响应实时延迟预算。
复现评估
复现基础扎实：代码和训练脚本开源（github.com/emrekuruu/retrieval-router），并发布覆盖 8 万多查询的每查询最优管线标签——这是最有价值的资产，因为标签生成才是复现瓶颈。所用七个检索模型和 11 个基准全部公开。算力上路由器训练很轻：单张 H100 80GB、bf16、每个 $\lambda$ 约 20 分钟、约 400 万 LoRA 参数；但 Oracle 标注需在 8 万多查询上各跑七个管线，最慢的 ML 平均 8.283 秒/查询，粗估需数百 GPU 小时，外加约 39 GB 多模态索引的构建存储，门槛主要在数据准备而非训练。超参披露完整（$\tau=0.1$、rank 16、lr $10^{-4}$、批 32、种子 42），但每个 $\lambda$ 仅单次运行、无方差估计。综合评估复现难度为中高：用官方标签重训路由器容易，从零重建标签昂贵。
论文图表
三个代表性路由案例：问'红色柱状图展示什么'的视觉指代查询被派给多模态管线（文本管线看不见颜色）；问'CEO 是谁'的事实型问题走直接关键词匹配，BM25 即可，更重的管线只会徒增延迟；问'Q4 业绩是否符合 Q1 预期'的长文档跨端证据查询需要后期交互保留 token 级结构，稠密检索单向量会把两端证据平均掉。
这是理解全文核心直觉的最快入口：管线的优劣不是全局属性而是查询属性，路由的价值在于把每个查询送到'能回答它的最便宜管线'。三种失败模式（视觉指代、简单事实、长程结构）分别对应模态轴和架构轴上的选择依据。