RAG 系统里有一笔默认架构账:检索之后挂一个独立重排模型给段落打分,再挂一个生成模型读段落写答案,候选段落要被编码两遍,显存里也要同时驻留两份模型权重。Airun Intelligence Labs 10 月 29 日提交到 arXiv 的论文 Glance 提出一条更省的路径:反正生成器接下来就要读这些段落,不如让它自己给所有候选打分(论文)。

机制:一次共享 prefill,每段一条短探针

Glance 在一个冻结的 9B 骨干(MiMo-V2.6-Distill-Qwen-9B,混合门控 DeltaNet 线性注意力与全注意力层,比例 3:1)上挂了 rank-16 LoRA 适配器加一个 256 维指针头,这就是全部可训练参数。具体做法是把 k 个候选段落拼进同一个共享上下文,再为每段发一条约 30 token 的相关性探针,探针从共享缓存分叉,一条探针产出一个分数:段落只 prefill 一次,不再逐对编码。

因为每条探针都能看到全部候选,作者推测它能拿一段和邻居段落做对比,这是孤立打分做不到的。打分结束关掉适配器,同一份骨干立刻变回普通聊天模型,模式切换实测 4.2–9.4 毫秒、输出概率逐位一致,显存驻留 16.85 GiB;每多挂一个决策技能只增加约 0.1 GiB。

论文还测了一个更省的变体:适配器只在探针 token 上激活,段落编码仍走基座权重,答案生成就能直接续写重排时留下的缓存,段落真正只读一次。100 道 HotpotQA 题上,共享状态前向 64 毫秒、10 条探针 85 毫秒,续写缓存作答比重新 prefill 前三段更快(138 对 181 毫秒),F1 0.750 对 0.754 基本持平。作者标注这是 100 题、单随机种子的结果。

数字账:39 分钟训练,自报分数略高于交叉编码器

在 MS MARCO 上微调 39 分钟(4,000 条查询、55,598 个标注探针,单块 B200,峰值显存 21 GiB)后,论文报告 SciFact nDCG@10 0.741、NFCorpus 0.345,对照专用交叉编码器 bge-reranker-v2-m3 的 0.721 与 0.326;再加 14 分钟长上下文训练,两榜到 0.749 与 0.346。

作者自己给这组数字踩了刹车:BEIR 上的差异没做显著性检验,样本只有约 300 条查询时,小于 0.02 的差距只能算指示性。换句话说,0.741 对 0.721 的领先按论文自己的标准就该谨慎读。

更有分量的是下游。HotpotQA 300 题上,同一个 9B 生成器从 Glance 选出的前三段作答,F1 为 0.729,从交叉编码器选出的前三段作答是 0.684,差 +0.045(配对 bootstrap 95% 置信区间 [0.014, 0.076]),金段落召回 R@2 也更高(0.897 对 0.863)。

反直觉点:召回更低,答案反而更好

零样本那组实验有个值得记下的现象:Glance 的金段落召回明显低于交叉编码器(R@2 0.762 对 0.863),但生成器从它选的段落作答,F1 反而更高(0.718 对 0.683)。作者的解释是生成器挑的是自己用得上的上下文,但论文紧接着自我刹车:训练标签是段落相关性,不是答案质量,这不能说明模型学会了答案效用。

诚实的负结果清单

  • 速度:专用交叉编码器每查询 31–60 毫秒,Glance 训练后在 B200 上约 420 毫秒,论文和模型卡都明说交叉编码器每查询仍然更快;
  • 内存:当前实现里每个探针分支要复制一份共享缓存,内存按候选数乘上下文长度增长,100 个候选时峰值 56 GiB;200 个候选(4.34 万 token)放不进单次调用,走分块路径要 15.8 秒;
  • 零样本适配器超过 20 个候选就退化,200 个候选时塌到 0.505;训练过的适配器反而随候选数上升继续涨(200 个候选时 0.717,对照交叉编码器 0.659);
  • 跨查询批处理目前反而降吞吐(每秒 2.87 降到 1.57);
  • 适配器特化伴随遗忘:通用决策基准 JevBench 从 184/231 掉到 175/231,丢的 9 题里 7 题在困难档;
  • 段落排列顺序会影响打分:不同顺序下 nDCG@10 在 0.678 到 0.693 之间波动,排序第一的段落有 91% 与原顺序一致——这是探针看得见邻居的代价。

限制一节作者把话说得很透:这是概念验证,评估只覆盖两个检索数据集、一个问答集、一个骨干族。工程侧他们搭了一个 vLLM 原型,同一个引擎里聊天请求不带适配器、决策行带适配器、共享前缀缓存:20 个打包请求的输出与自研运行时秩相关 0.995,吞吐 1.54 对 0.86 请求每秒——生产化路径存在,但概率还有 0.006 的平均偏差。

所以呢

这份工作真正值钱的不是 0.741 这个分数,而是把「多驻留一个重排模型」这笔真实的显存与处理账摆上桌面,并给出一条 LoRA 级替代路径:一个骨干、多个 0.1 GiB 的决策技能、按请求切换。速度与内存工程都还没做,现在就在生产里砍掉重排器显然过早;适配器与代码已按 Apache-2.0 在 Hugging Face 开源。对做 RAG 服务的人,更实际的启发或许是那个反直觉发现:重排器优化的段落相关性,和生成器真正需要的东西,可能本来就不是同一个目标函数。