核心洞察值得单独写一笔：LLM生成答案前的prefill阶段，本来就要计算query与每篇候选文档之间的注意力——这恰好就是cross-encoder重排器在做的事。同一件事为什么要付两次钱？Glance（arXiv 2610.40454，AI Run团队）的做法是在最后一层加一个256维指针头，从缓存的prefill里为每篇候选读出一个相关性分数。读一遍，顺路把账记了。
账面数字经原文核对基本全对：SciFact上nDCG@10零点七四一对零点七二一（对比bge-reranker-v2-m3），HotpotQA三百题答案F1提升零点零四五（配对bootstrap置信区间零点零一四到零点零七六），每技能额外显存约零点一GiB，MS MARCO微调三十九分钟——单卡B200，峰值二十一GiB，LoRA秩十六。底座是小米MiMo-V2.6-Distill-Qwen-9B，Gated DeltaNet与全注意力三比一的混合架构且全程bf16冻结。「prefill即cross-encoder」在线性注意力骨架上也成立，这点论文没吹但很值钱。
但有一处需要勘误：原帖写「NQ：答案F1提升零点零三一」——全文查无此数。论文摘要末尾自己划了边界：「评估目前覆盖两个检索数据集、一个问答数据集和一个底座家族」，那个问答数据集就是HotpotQA，全文没有Natural Questions的实验。这可能是把HotpotQA的增益误记成了第二数据集。另一处表述过强：原帖说延迟差异「可忽略」，实况是k等于一百时每次查询一点零五秒，k两百时走分块探测路径十五点八秒——仍快于逐对推理，但绝不能叫可忽略。
这个工作的真正价值在「换层面」三个字。传统思路把重排当独立任务，优化方向是造更强的重排器；Glance的思路是发现重排所需的信息已经存在于生成的前置过程里，缺的只是一个读出机制。零样本适配器也能打（四千四百条通用决策记录、二十分钟训练、不碰任何检索数据就有基础重排能力），说明指针头读的确实是prefill里现成的交互信号，不是硬背出来的。检索器已被嵌入能力吞并，重排器正在被prefill吞并，RAG的组件清单还在变短。
工程账也值得算给团队听：一个独立cross-encoder重排器约占一点五GiB显存，Glance的指针头加LoRA约零点一GiB，差十五倍；训练三十九分钟意味着任何有一张卡的团队当天就能自产一个重排技能。当然边界也要看清，作者自己写明只测了两个检索集、一个问答集、一个底座家族，九B混合架构之外的泛化还没有数；四万三千token的候选堆进一次prefill，对上下文窗口小的老模型也不适用。模板价值大于结论价值：任何「前置筛选加后置生成」的流程都值得问一遍——生成器在prefill时已经看过了所有候选，能不能顺便打个分。钉子：探针分支机制在超长候选集下的缓存管理；以及「生成器顺便打分」这个模板下一个被套用的场景——对话历史筛选还是多文档摘要，谁的prefill冗余更大，谁先受益。