同样的老师，不同的学生：为什么 token 级匹配让模型学会了"举一反三"

一个反直觉的实验设计

你教一个学生英语，用英语教材、英语考试、英语对话。然后你让他做日语阅读理解——他从来没学过日语。

听起来像天方夜谭？这正是检索模型领域的标准做法，叫做"translate-train"：用英语训练数据，翻译成目标语言（比如日语），然后在目标语言上评测。传统做法是翻译成什么语言，就在什么语言上测试。

但 LightOn 团队在 2026 年 7 月的论文 DenseOn with the LateOn 中发现了一件奇怪的事：如果你换一种检索架构，模型不仅能做翻译过的语言，还能做从没翻译过的语言。

同样的训练数据，同样的模型骨架，唯一区别是检索方式——结果泛化能力天差地别。

两种检索，两种哲学

先说背景。检索模型有两种主流架构：

Dense（密集检索）： 把整个查询或文档压缩成一个向量（比如 768 维），然后算两个向量的相似度。就像把一本书浓缩成一句话的摘要，再用摘要来匹配。简单、快，但信息损失大。

Late-Interaction（延迟交互，代表是 ColBERT）： 不压缩，保留文档中每个 token 的向量。查询也是一组 token 向量。匹配时，查询的每个 token 去找文档中最相似的 token，取最大值，然后求和（MaxSim）。就像读原文时手边放一本词典——每个词都去查最合适的释义，而不是把整本书浓缩成一句话。

DenseOn 和 LateOn 是这篇论文发布的两个模型，都是 149M 参数，用完全相同的数据训练：

• 665M 英文对比预训练对（从 1.4B 对中筛选）
• 1.88M 监督微调对（带难负样本挖掘）
• 34 个公开数据源

唯一区别：DenseOn 用密集检索，LateOn 用延迟交互。

数字说话：BEIR、MIRACL、MLDR

英文基准 BEIR 上：DenseOn 56.20，LateOn 57.22。差距不大，LateOn 略胜。

但到了多语言场景，故事变了。多语言版本 mDenseOn 和 mLateOn（307M 参数，共享骨架和训练数据）：

MIRACL（多语言检索基准）：

• mDenseOn：58.02
• mLateOn：67.04

9 分的差距。 同样的骨架，同样的数据，同样的训练目标——仅仅因为检索架构不同，多语言泛化能力差了 9 个点。

更关键的发现藏在"未翻译语言"上。translate-train 的标准流程是：英语数据→翻译成目标语言→在目标语言上训练和测试。但如果你测试一个从没翻译过的语言呢？

• mDenseOn（密集检索）：在未翻译语言上性能大幅下降
• mLateOn（延迟交互）：在未翻译语言上保持较好性能

论文的原文表述是："the dense model is strong on English and translated languages but degrades outside translate-train support, whereas the late-interaction model generalizes better to unseen languages and scripts."

为什么 token 级匹配能"举一反三"？

这个现象的深层原因值得细想。

密集检索的问题： 它把整个文档压成一个向量，这个向量必须同时编码语义、语法、词汇信息。当训练数据只有英语和翻译过的语言时，这个"全能向量"学到的模式偏向这些语言的分布。遇到从没见过的语言，向量空间没有覆盖，就崩了。

延迟交互的优势： 它不压缩。每个 token 独立保留自己的向量。当遇到从没见过的语言时，虽然整体语义可能模糊，但很多 token 可以通过字面相似度（比如数字、专有名词、拉丁词根）或跨语言对齐的子词片段找到匹配。这就像——

类比来了： 假设你要在一份日语文件中找信息。

密集检索的做法是：把日语文件翻译成英语摘要，把你的英语查询也变成摘要，然后比两个摘要。如果这份文件从没被翻译过，你就抓瞎了。

延迟交互的做法是：不翻译，直接拿着英语查询的每个词，去日语原文里找最相似的词。"Tokyo"能匹配"東京"，"5"能匹配"5"，即使语法完全不同，关键 token 的匹配仍然有效。

这就是"token 级匹配让 translate-train 从目标语言扩展策略变成多语言泛化配方"的真正含义。 它不是让模型学会更多语言，而是让模型在不需要学会的情况下也能工作。

完全开源：665M 对数据、149M 参数模型、训练代码

这篇论文的另一个亮点是"完全开源"四个字。

当前 SOTA 检索模型（如 OpenAI 的 embedding API、Cohere 的 multilingual model）越来越依赖闭源训练数据。这创造了一个"可复现性鸿沟"——学术界无法验证、改进或扩展这些模型。

DenseOn/LateOn 的回应是：

• 数据开源： 665M 英文对比预训练对，从 34 个公开数据源重建（不是用私有数据）
• 模型开源： 149M 参数的 DenseOn 和 LateOn，307M 参数的 mDenseOn 和 mLateOn
• 代码开源： 训练代码、评估代码
• 技术开源： 非破坏性过滤管道、难负样本挖掘（用 NV-Retriever 过滤 0.95 阈值，保留 10 个难负样本）

还开源了一个叫 fast-plaid 的推理引擎（https://github.com/lightonai/fast-plaid），专门优化延迟交互模型的推理效率。

一个细节：MLDR 的诚实声明

论文中有一个值得赞赏的诚实声明。在长文档检索基准 MLDR 上，mLateOn 大幅超过 mDenseOn。但作者指出：他们的微调数据包含了 MLDR 的训练集（目标语言），而一些基线模型没有说明是否用了 MLDR 训练数据。

所以他们说："Comparisons with these baselines are therefore not fully controlled. The most reliable comparison is between mDenseOn and mLateOn, which share the same backbone and training data but differ in retrieval paradigm."

最可靠的比较是 mDenseOn 和 mLateOn 之间的比较——同骨架、同数据、不同检索范式。 这种科学诚实比任何性能数字都更有价值。

消融实验的三个发现

附录中的消融实验也有信息量：

知识蒸馏： 用大模型蒸馏小模型，在 BEIR 上有提升但不是决定性的。

MeanMaxSim： 对 LateOn 的 MaxSim 稍作修改，取均值和最大值的组合，有轻微提升。

Matryoshka 表示学习： 让向量在不同维度截断时都保持有用（比如 768 维、512 维、256 维都能用），牺牲少量精度换取灵活性。

这为什么重要

DenseOn with the LateOn 的意义有三层：

第一层：工程价值。 一个 149M 参数的完全开源模型，在多语言、长文档、代码检索上都能打——这给了学术界一个可复现的基线。

第二层：架构洞察。 同样的数据、同样的骨架，仅仅换检索架构就能差 9 分——这说明架构选择不是工程优化，是认知框架选择。密集检索和延迟交互不只是两种工程方案，它们对"什么叫做匹配"有根本不同的假设。

第三层：泛化哲学。 "token 级匹配让 translate-train 从扩展策略变成泛化配方"——这个发现暗示一个更普遍的原则：不压缩的表示比压缩的表示泛化更好。 当你保留颗粒度，你保留了跨域迁移的可能性。当你压缩，你把训练分布的偏见固化了。

这和之前论文笔记里反复出现的"颗粒度同构"原理一致——优化颗粒度应该和被优化对象的颗粒度一致。文档检索的颗粒度是 token 级，那表示就应该保留 token 级。压缩成单一向量，就是把 token 级问题强行降到文档级，必然丢失跨域泛化能力。

---

论文信息：

• 标题：DenseOn with the LateOn: Fully Open Dense and Late-Interaction Models for Multilingual, Long-Context, and Code Search
• 作者：Raphaël Sourty, Antoine Chaffin, Paulo Roberto Moura Junior, Amélie Chatelain（LightOn）
• arXiv：2607.27178（2026 年 7 月 29 日）
• GitHub：https://github.com/lightonai/fast-plaid
• HuggingFace：https://huggingface.co/collections/lightonai/lateon-code

核心数据：

• 149M 参数 DenseOn/LateOn，307M 参数 mDenseOn/mLateOn
• 665M 英文对比预训练对，1.88M 监督微调对
• BEIR：DenseOn 56.20，LateOn 57.22
• MIRACL：mDenseOn 58.02，mLateOn 67.04（9 分差距）
• 关键发现：延迟交互模型在未翻译语言上泛化更好

开源状态： 完全开源——模型、数据、训练代码、推理引擎全部公开。