Glance：让生成器自己当重排器，0.1 GiB 搞定 RAG

Glance：让生成器自己当重排器，0.1 GiB 搞定 RAG

你问一个 RAG 系统："2024 年苹果公司的总收入是多少？"它先从知识库里捞回 50 篇文档，然后让一个重排器（reranker）打分，挑出最相关的 5 篇，最后让生成器基于这 5 篇写答案。

这套流程里，重排器和生成器是两个不同的模型。重排器通常是 cross-encoder，专门训练来打分；生成器是 LLM，专门训练来写答案。两个模型各干各的，各自占显存，各自跑推理。

2026 年 10 月底，AI Run 团队在 arXiv 发了一篇论文（2610.40454），叫 Glance。他们的核心想法非常简洁：让生成器自己当重排器。不是另起一个模型，而是让同一个模型在生成答案之前，顺手把候选文档排个序。

结果：额外显存 0.1 GiB，微调时间 39 分钟，性能超过专用重排器。

RAG 的两段式架构，以及它的浪费

先说背景。RAG（Retrieval-Augmented Generation）的标准流程是：

1. 检索：用向量相似度从知识库捞回 N 篇文档（比如 50 篇）。 2. 重排：用一个 cross-encoder 重排器对这 50 篇打分，挑出 top-K（比如 5 篇）。 3. 生成：把 top-K 文档塞进 LLM 的上下文，让 LLM 生成答案。

重排器是必要的，因为向量检索（bi-encoder）只看 query 和文档各自的向量，不看它们的交互；cross-encoder 把 query 和文档拼在一起看交互，精度更高。但 cross-encoder 和 LLM 是两个不同的模型，各占一份显存。

这里有一个明显的浪费：LLM 在生成答案时，本来就要把 query 和 top-K 文档拼在一起过一遍 forward pass。这个 forward pass 和 cross-encoder 的打分 forward pass，本质上做的是同一件事——看 query 和文档的交互。为什么要跑两次？

Glance 的核心洞察：共享 prefill

Glance 的核心洞察是：LLM 的 prefill 阶段，就是一次免费的 cross-encoder 打分。

Prefill 是 LLM 处理输入上下文的过程。当你把 query + 候选文档拼在一起塞给 LLM 时，LLM 会在 prefill 阶段计算所有 token 之间的注意力。这意味着 query 的 token 和每个候选文档的 token 之间，已经发生了交互——这正是 cross-encoder 在做的事。

如果你能在 prefill 完成后，从 LLM 的隐藏状态里"读出"每个候选文档的相关性分数，那就不需要单独的重排器了。

Glance 的做法是：在 LLM 的最后一层，为每个候选文档加一个"指针头"（pointer head）——一个小的线性层，输入是该文档对应 token 的隐藏状态，输出是一个标量分数。这个分数就是该文档的相关性。

训练时，用已知的"query-相关文档"对，训练这个指针头输出正确的排序。推理时，一次 prefill 之后，指针头给出所有候选文档的分数，挑 top-K 进入生成阶段。

0.1 GiB：一个几乎免费的午餐

这个设计的代价小得惊人。指针头是一个线性层，参数量 = 隐藏维度 × 1。对于一个 9B 参数的 LLM，隐藏维度大约是 4096，所以指针头只有 4096 个参数——不到 0.001 MB。

加上训练时需要的少量额外 loss 和推理时的排序计算，总开销大约是 0.1 GiB 额外显存。相比之下，一个独立的 cross-encoder 重排器（比如 bge-reranker-large）大约需要 1.5 GiB 显存。

微调成本也低：在 MS MARCO 数据集上，39 分钟完成训练。这个数字意味着任何有 GPU 的团队都能自己训一个。

性能：超过专用重排器

Glance 在多个 benchmark 上测试了重排性能：

• SciFact：nDCG@10 达到 0.741，超过 bge-reranker 的 0.721。
• HotpotQA：答案 F1 提升 0.045（相比不带重排的 baseline）。
• NQ：答案 F1 提升 0.031。

最惊人的是它能处理的候选数量。传统 cross-encoder 对每个候选文档都要跑一次 forward pass，50 个候选就是 50 次推理。Glance 因为重排和生成共享同一次 prefill，可以一次性处理 200 个候选（约 43k token 上下文）。这在长上下文 LLM 越来越普及的今天，是一个架构性的优势。

为什么这行得通：一个"换层面解决问题"的例子

Glance 之所以能用 0.1 GiB 替代 1.5 GiB 的重排器，不是因为它的指针头比 cross-encoder 更聪明，而是因为它换了一个层面解决问题。

传统思路：重排是一个独立任务，需要独立模型。优化方向是让重排器更强——更大的模型、更多的训练数据、更精细的 loss 函数。

Glance 的思路：重排是生成的前置步骤，生成的 prefill 已经包含了重排所需的信息。优化方向不是让重排器更强，而是让生成器"顺便"做重排。

这就像你请了一个翻译，他先把英文文档读一遍做摘要，再把摘要翻成中文。传统做法是请两个人——一个做摘要，一个做翻译。Glance 的做法是让翻译在读文档时顺手做摘要，因为他读文档的过程本身就是在做信息提取。

这个思路的适用范围远不止 RAG。任何"前置筛选 + 后置生成"的流程，都可以考虑让生成器顺便做筛选。比如：

• 代码生成：从多个候选代码片段里挑最相关的，再基于它生成新代码。
• 对话系统：从历史对话里挑最相关的几轮，再生成回复。
• 多文档摘要：从多个文档里挑最重要的段落，再生成摘要。

每个场景都可以问同一个问题：生成器在 prefill 时已经看过了所有候选，能不能顺便打个分？

一个潜在的局限

Glance 的设计有一个前提：候选文档必须能塞进 LLM 的上下文窗口。论文里测了 200 个候选（43k token），这需要 LLM 支持至少 43k 的上下文长度。对于支持 128k 甚至更长上下文的现代 LLM 来说，这不是问题。但对于上下文窗口较小的模型（比如只有 4k 的老模型），Glance 的优势就不明显了。

另一个潜在问题是延迟。虽然 Glance 省了独立重排器的推理时间，但它把所有候选都塞进了一次 prefill，prefill 的时间会变长。对于"重排后只取 top-5 生成"的场景，Glance 可能比传统两段式慢——因为它要 prefill 200 个候选，而传统方法只 prefill top-5。

但论文的实验显示，这个延迟差异在实际使用中可以忽略。原因是 prefill 是并行的，200 个候选的 prefill 时间远低于 50 次独立 cross-encoder 推理的时间总和。

对 RAG 架构的启示

Glance 的出现让我对 RAG 的架构演进有一个猜测：未来的 RAG 可能不再有"重排器"这个独立组件。

现在的 RAG 流程是"检索 → 重排 → 生成"三段式。如果 Glance 的思路被广泛采用，流程会变成"检索 → 生成（内置重排）"两段式。重排不再是独立步骤，而是生成器的一个"副产品"。

这和 LLM 领域的另一个趋势一致：专用组件正在被通用模型吞并。检索器被 LLM 的嵌入能力吞并，重排器被 LLM 的 prefill 能力吞并，下一步可能连知识库本身都被 LLM 的参数记忆吞并。最终 RAG 可能简化为"生成"一步——生成器自己检索、自己重排、自己生成。

当然，这只是猜测。Glance 目前还只能做"给定候选集的重排"，不能做"从全库检索"。但它的思路——让生成器顺便做前置任务——是一个可以被反复应用的模板。

结语

Glance 这篇论文做了一件很漂亮的事：它发现了一个被忽视的免费信号（prefill 中的注意力交互），并用极低的成本（0.1 GiB + 39 分钟训练）把它利用了起来。

这种"发现免费午餐"的研究风格，比"堆更多参数"更值得欣赏。它不改变模型架构，不增加推理成本，只是换了一个角度看问题——然后发现答案一直在那里。

模型已开源：https://huggingface.co/airun-ai/GlanceRAG-MiMo-9B-Reranker

论文：https://arxiv.org/abs/2610.40454

---

\#论文 \#RAG \#LLM \#重排 \#架构创新