Sentence Transformers 出到 v6.0，新增了一个模型类型叫 MultiVectorEncoder，专门用来训练 ColBERT 式的多向量检索模型。作者 Tom Aarsen 自己做了个示范：一张 RTX 3090，训练 14.5 小时，微调出一个叫 mLateOn-medical 的医疗检索模型，在自建的评测集上 NDCG@10 跑到 0.9139，把稠密向量、稀疏向量、BM25，乃至没微调的多向量模型全部甩在后面。
这个故事讲起来很诱人：一张消费级显卡、半天多时间，就能训出一个吊打通用模型的领域专用检索器。但看完完整的评测细节和多向量检索这套技术真正落地要走的路，我更想问一句——训练便宜了，检索真的也便宜了吗？
碾压的分数怎么来的
mLateOn-medical 的训练数据是医疗问答数据集 MIRIAD，评测留出 1000 条问题，对着 20 万条段落的语料库检索，段落平均长度 941 个 token。这个长度对多数通用检索模型是灾难，因为经典 ColBERT 系模型习惯把文档截到 180 到 512 个 token，剩下的直接扔掉。作者测过，光是截断这一项，在这批数据上就能吃掉最多 0.24 的 NDCG@10，比模型架构差异的影响还大。
打开截断长度后，训练出来的多向量模型确实赢了：NDCG@10 从零样本版本的 0.8520 涨到 0.9139，同时甩开 Qwen3-Embedding-4B（0.7817）、BM25（0.7501）和 splade-v3（0.6853）。
这张图确实好看，但有个细节值得多看一眼：BM25——一个纯词面匹配、跟语义没什么关系的老方法——居然排到第四，比不少稠密向量模型还高。这不太正常。
分数里藏着的一处偏差
MIRIAD 的问题是直接从对应段落生成出来的，查询和文档之间的词汇重叠天然偏高。这解释了 BM25 为什么能考出这么高的分——它靠的就是词面重叠，而这批数据恰好给它开了外挂。同样的偏差也可能悄悄放大了多向量模型的优势，因为 MaxSim 本质上也是一种更精细的词级匹配。
换句话说，"碾压所有通用检索器"更准确的说法是"在词汇高度重叠的合成问答对上碾压"。放到真实用户措辞跟原文差异更大的查询上，这个优势会不会缩水，原文没有回答，目前也没人测过。
领域微调是真收益，评测的干净程度是另一个问题。
多向量模型对领域词汇和长文档敏感，这点没有争议。但一个"全面碾压"的结论建立在有偏差的基准上，说服力就要打个折。
训练完只是走了一半
原文从头到尾讲的是怎么训练，只字未提训练完之后怎么用。MultiVectorEncoder 本质上是模型层，负责产出 token 级向量、算 MaxSim 分数，它不是一套能扛几十万文档规模的生产索引方案。真要把这样的模型部署成检索服务，还得再接一层索引引擎——常见选择是 PyLate 配 FastPLAID，或者 RAGatouille。
这一步的代价被完全隐藏了。ColBERTv2 论文给过一组数字：原始多向量索引 154GiB，压缩到 1-bit 残差后 16GiB，2-bit 压缩后 25GiB——省是省了，但对比同等规模的稠密向量索引，量级依然大出一截。PLAID 这类加速方案能把检索速度提上来，GPU 上最多 7 倍、CPU 上最多 45 倍，前提是你得先把这套索引管线搭起来。
生态本身也没那么齐整。PyLate 维护更活跃，在 H100 上的吞吐比旧版 PLAID 提升明显，但社区反馈过索引规模到几百万文档量级时会内存溢出。RAGatouille 上手更简单，却不官方支持 Windows，得绕道 WSL2。选哪条路取决于语料规模和运维能力，这套选择题，训练教程里完全没提。
- 风险.训练教程完全没提索引与部署成本，团队照单跟做容易低估上线难度。
该怎么看这件事
单卡训一个领域检索模型，门槛确实降下来了——医疗、法律、金融、企业内部文档，这些没有官方模型覆盖的场景，现在有了一条不算贵的自训练路径。这是真进步，LightOn 此前为代码检索单独训 LateOn-Code，已经证明这条路能走通。
但"训练降本"和"检索系统降本"是两件事。前者省的是显卡时间和数据标注成本，后者省的是索引存储和运维复杂度——目前看，后者的账还没人真正算清楚。想认真上线一个多向量检索系统，别看到"14.5 小时"就心动，先把索引方案和语料规模摆到桌面上算一遍，再决定要不要走这条路。
- 结论.多向量检索的门槛在训练端确实降了，但部署端的成本才刚开始暴露。