RetrievalRouter: 文档检索中的联合模态与架构选择

TL;DR RetrievalRouter 按查询文本动态选择检索 pipeline（文本/多模态 + dense/晚交互），用单参数控制精度-延迟权衡，对所有静态基线均找到同时更准更快的工作点，比最佳静态方案高 2.5% nDCG@5 且快 12.4 倍。

问题

文档检索 在金融、医疗、法律等高风险信息获取场景中日益关键。现代检索管道在 模态（文本 vs 多模态）和 检索架构（dense vs late-interaction）两个维度上存在不同选择。

目前普遍做法是设定一个静态检索管道并全局应用。但最有效的管道（如多模态 late-interaction）推理延迟和计算成本过高，无法支撑大规模在线请求；而最快管道（如纯文本 dense）在包含图表、表格等复杂文档上证据召回不足。这种静态选择迫使团队在漏检和不可用延迟之间二选一，并且缺乏 query 级自适应机制。现有基于规则或启发式的方法不能泛化到不同数据集和模态组合。

不同查询对模态与架构的需求差异显著：简单文本查询用轻量管道即可，复杂视觉+语义查询必须调用重型管道。但事先无法知道每个 query 的最优选择，且路由器本身不能引入明显开销。业界在高 stakes 检索场景中既不能接受漏检，又要求低延迟可扩展，因此显式控制准确率-延迟前沿对生产系统具有实际意义。

类似大模型推理中根据 prompt 复杂度动态路由到不同规模的模型，以在成本和质量之间取得平衡。

核心洞察

• RetrievalRouter 的核心洞察是：查询级联合选择模态与检索架构，以极低开销逼近每查询最优 pipeline。不同于以往只做单一维度自适应（如仅选 **dense vs late-interaction** 或仅选文本/多模态）的方法，它仅依赖 `query text`，通过一个轻量 router 同时决定使用文本 or 多模态、dense or late-interaction，并在需要时触发 reranking。这打破了静态 pipeline 在全量查询上的全局权衡：没有哪个静态 pipeline 在所有基准上占优，而 RetrievalRouter 能为每个静态 baseline 找到同时更准确且更快的点。
• 另一个关键设计是用单一可调参数暴露完整 **accuracy-latency frontier**，实现无重训练的部署策略切换。先前自适应策略选择方法通常需为不同延迟预算重新训练或依赖多目标优化，而 RetrievalRouter 通过调节 soft target 的温度/阈值，让路由分布沿 frontier 平滑移动。工程上这意味着同一模型可服务于准确优先和延迟优先的不同场景，且路由开销极小（仅对 query 编码一次），较最佳静态 baseline 快 12.4 倍的同时 nDCG@5 提升 2.5%。

方法

方法概览

RetrievalRouter 是一个查询感知的路由器，仅基于查询文本选择最合适的检索流水线（pipeline）。输入为原始查询文本，输出为候选流水线的选择或概率分布。

关键模块包括：

• 特征编码：使用轻量级编码器（如小型 Transformer 或预训练文本编码器）将查询文本映射为稠密向量。
• 路由决策头：一个线性或 MLP 分类头，输出在候选流水线集合上的概率分布。候选流水线通常包括不同模态（纯文本 / 多模态）和架构（dense / late-interaction / reranking）的组合。
• 训练目标：采用 Oracle labels 生成监督信号，即对每个查询，预先计算所有候选流水线的效果（如 nDCG@5），选择效果最佳的作为硬标签；进一步通过 soft targets 软化标签分布（可能使用温度缩放或对相近性能的流水线分配非零概率），使路由学习更平滑。目标函数在分类损失基础上，加入一个可调参数 λ 控制准确率与延迟的权衡，允许在推理时扫过精度-延迟前沿。

推理过程：给定查询，路由器输出概率分布，根据 λ 参数选择期望延迟最低且准确率足够的流水线。由于路由器本身计算开销极小（轻量级），其开销可忽略不计。

与同类方法的差异：与先前自适应策略选择方法相比，RetrievalRouter 不依赖查询-文档交互特征或候选文档集合，而是仅使用查询文本，且通过软目标和显式延迟权衡参数实现更细粒度的控制，从而在精度和延迟上同时超越静态基线与先前自适应方法。

实验

实验设计

论文在金融与科学文档检索的基准上评估 RetrievalRouter，覆盖文本与多模态两种输入，以及 dense 和 late-interaction 两种架构。路由器仅以查询文本为输入，采用轻量级网络结构。训练时，使用各静态 pipeline 的检索效果生成 oracle 标签，通过软目标交叉熵损失进行优化。设置单一可调参数控制精度与延迟的权衡，扫描得到完整前沿。

关键发现

• 静态 pipeline 无一能在所有查询上同时取得最优效果。
• RetrievalRouter 相对最佳静态基线，准确率提升 2.5%，速度提升 12.4 倍。
• 在 accuracy-oriented 设置下，RetrievalRouter 的 nDCG@5 显著高于先前自适应方法；latency-oriented 设置下，nDCG@5 与延迟持平或更优。
• 路由分布显示，并非所有查询都需要最昂贵 pipeline；纯 late-interaction 很少被选中，reranking 并非总是必要。

基线对比解读

RetrievalRouter 将模态与架构选择从静态固定解耦为查询级动态路由，避免了简单查询被复杂 pipeline 拖慢、复杂查询被简单 pipeline 漏检的问题。相比静态基线，按需分配降低平均延迟同时提升精度；相比先前的自适应方法（通常只调整 rerank 深度或阈值），RetrievalRouter 联合考虑模态和架构，且软目标训练使路由决策更灵活，因此能显著提高 nDCG@5。

行业影响

落地场景

RetrievalRouter 适用于需要在高准确率与低延迟之间动态平衡的文档检索产品。典型用例包括：

• 企业级知识库问答：金融研报、法律合同、医疗文献等场景，简单关键词查询可走轻量 dense 管道，复杂语义查询自动切换到 late-interaction 或多模态管道，避免全量使用高成本模型。
• 电商多模态商品搜索：用户查询可能是纯文本（“红色连衣裙”）或包含视觉描述（“类似这张图的鞋子”），路由可依据查询文本判断是否需要多模态编码，减少对图片编码器的无关调用。

商业价值

核心收益来自降本与体验提升：

• 降本：对简单查询使用更便宜、更快的管道，避免所有查询都跑最重模型，直接降低 GPU/API 推理成本。
• 提速：延迟敏感型业务（如实时搜索、客服问答）可将 P99 延迟显著降低，同时保持整体检索质量不降反升（论文显示比最佳静态基线快 12.4× 且准确率提高 2.5%）。
• 可控权衡：单个可调参数（准确率-延迟前沿）允许产品团队根据预算与 SLA 实时调整路由策略，无需重新训练。

与现有产品/工作流接口

RetrievalRouter 可作为检索服务的前置路由层，集成方式轻量：

1. 接收用户查询文本，输出所选的管道标识（如 dense-text、late-interaction-multimodal）。
2. 根据标识调用已有的检索后端（向量库、重排器、多模态索引）。
3. 路由模型本身不存储文档或索引，只依赖查询文本，部署开销极小，可旁路集成到现有 RAG 或搜索微服务中。

对于已部署多种检索管道的团队，可以将 RetrievalRouter 作为流量分配开关，逐步替换静态路由规则，无需推翻现有基础设施。

局限

• - **输入信号受限**：RetrievalRouter 仅从查询文本学习路由决策，完全忽略文档侧特征、索引统计或上下文信息，可能导致在某些需要文档感知的路由场景中次优。此外，训练依赖 oracle 标签，而 oracle 仅基于预定义的候选管道集合（dense、late-interaction、多模态等）生成，无法发现或泛化到新的管道组合或动态参数调整。论文实验覆盖金融和科学语料库，跨领域、跨语言及分布偏移下的鲁棒性尚未验证，实际部署前需要更广泛的评估。
• - **推理开销与超参敏感**：虽然路由器被设计为轻量级，但其额外的前向计算仍会增加查询处理延迟，在极低延迟要求下可能不可忽略，论文未提供与静态管道在 p99 等尾部延迟上的详细对比。`soft targets` 的温度系数和路由器的结构（如层数、隐藏维度）需要针对新数据集重新调优，缺少自动化选择机制；若候选管道集合本身存在能力上限，路由只能在其内部优化，无法突破该上限。
• - **对比范围有限**：与先前 adaptive strategy selection 方法相比，RetrievalRouter 仅依赖查询文本，而部分同类方法可利用查询-文档交互特征或历史反馈，这可能限制其在复杂查询上的表现。论文虽然报告了 nDCG@5 的显著提升，但缺乏与最新基于强化学习或上下文 bandit 的路由方法的直接比较，也未分析在长尾、会话式查询下的路由质量。此外，评测仅关注 nDCG@5 和延迟，未报告 recall@k 等指标，可能掩盖对高召回场景的不足。