多向量嵌入模型革命：Sentence Transformers 6.0如何重塑检索技术

2 阅读

多向量嵌入模型技术的出现标志着信息检索领域的重要转折点。随着Sentence Transformers 6.0版本的发布，这一Python库引入了第四种模型类型——MultiVectorEncoder，为ColBERT风格的延迟交互检索提供了强大支持。这种技术突破不仅解决了传统密集嵌入模型在处理复杂查询时的局限性，还为视觉文档检索、音频检索和视频检索等多模态应用场景开辟了新的可能性。

传统的密集嵌入模型将整个文本压缩成单个固定大小的向量，这种方法虽然在许多场景下表现良好，但存在明显的局限性。当面对包含多个具体要求的复杂查询时，如'绿色带木腿圆垫沙发'，单个向量必须将所有特征融合成一个点，导致相关性匹配不够精确。而多向量模型则跳过了这种压缩过程，为每个token保持独立的向量表示，从而保留了更细粒度的匹配信息。

多向量模型的核心机制

多向量模型，也称为延迟交互或ColBERT风格模型，其工作原理与传统密集嵌入模型截然不同。传统模型将文本读取后返回单个固定大小的向量，所有信息都必须压缩到有限的维度空间中。相比之下，多向量模型运行相同的transformer架构，但不将token嵌入池化成单个向量，而是将每个token嵌入投影到较小维度并全部保留。

以9个token的文档为例，传统方法产生1x128向量，而多向量方法产生9x128矩阵。这种设计使得查询和文档之间的交互被推迟到评分阶段，这就是'延迟交互'名称的由来。交叉编码器在早期进行交互，两个文本一起通过模型，准确性高但无法预计算；双编码器几乎不交互，仅通过两个摘要的一次点积完成匹配，允许离线编码文档；延迟交互介于两者之间，文档仍可独立编码并离线索引，但评分时比较每个查询token与每个文档token。

MaxSim操作符是多向量模型评分的核心机制。对于每个查询token，取其与任何文档token的最高相似度，然后对查询中的这些最大值求和。数学表达式为：MaxSim(Q, D) = ∑Qi∈Q max Dj∈D Qi·Dj。由于token嵌入经过L2归一化，每个点积都是[-1, 1]范围内的余弦相似度，整个和落在[-num_query_tokens, num_query_tokens]范围内。

这种操作可以理解为软对齐：每个查询token指向最能解释它的文档token，分数反映文档整体支持查询的程度。重要的是，这种对齐不需要词汇层面的匹配，因为token嵌入是上下文化的。例如，使用lightonai/mLateOn对'企鹅住在哪里？'和'企鹅栖息在南极洲'进行编码时，查询token'住'在0.94相似度下找到文档token'栖息'的最佳匹配，尽管这两个词没有共同字符。

性能优势与成本考量

多向量模型的主要优势体现在检索质量的提升，特别是在需要文档特定部分相关的查询上，多需求查询的处理能力，以及跨域数据的表现。当文档长度增加时，这种优势更加明显，因为更多文本需要适应相同的固定向量。

然而，这种改进伴随着索引大小的成本。每个token一个向量而非每个文档一个向量意味着大量额外的向量，虽然维度较小，但总体存储需求显著增加。以4,874个Natural Questions段落为例，使用lightonai/LateOn编码产生608,414个token向量，平均每段落124.8个向量。这比MiniLM索引大约42倍，达到62 KiB每段落。

不过，索引通常会被压缩，例如相同的608,414个向量在fast-plaid索引中占用92 MB，因为PLAID存储质心ID加上量化残差而非原始向量。对于规模参考，像Qwen3-Embedding-8B这样的4096维密集模型需要约80 MB来处理相同的4,874个段落，因此压缩后的多向量索引与人们已运行的密集索引处于相同水平。

安装与模型加载

多向量模型可以通过标准安装方式使用：pip install -U sentence-transformers。对于ColPali风格的视觉文档检索，还需要图像依赖项：pip install -U "sentence-transformers[image]"。Sentence Transformers v6.0需要transformers v5.x，torch 2.2+，以及huggingface-hub v1.x。

加载多向量模型与加载其他Sentence Transformers模型完全相同：from sentence_transformers import MultiVectorEncoder; model = MultiVectorEncoder("lightonai/LateOn")。要查找可用模型，请查看Hub上的multi-vector和sentence-transformers标签。

Dense embedding versus multi-vector late interaction: a dense model encodes each text into one vector and scores with cosine similarity, while a multi-vector model keeps one vector per token and scores every query token against every document token with MaxSim

多向量模型携带多个配置参数：查询和文档的标记前缀、长度限制、查询是否用[MASK]token填充，以及评分文档时跳过的token。所有这些都存储在模块配置中，print(model)显示确切加载的内容。例如，原始ColBERTv2检查点将每个查询填充到恰好32个token并将文档截断为180个。

Multi-vector backend benchmarks on GPU

编码查询与文档

Multi-vector backend benchmarks on CPU

多向量模型具有不对称性：查询和文档通过不同的前缀、长度限制和评分掩码处理。与许多密集模型不同，encode_query()和encode_document()是获得正确嵌入的必需方法。查询和文档分别编码，返回每个输入的2D张量列表，形状为(num_tokens, embedding_dim)。

每个调用都会应用模型的自有配方。encode_query预置查询标记，根据检查点要求扩展查询到固定长度，并将其限制在查询长度内。encode_document预置文档标记，限制在文档长度内，并从评分掩码中删除任何列入黑名单的token（大多数检查点的标点符号）。

MaxSim评分机制

model.similarity()计算完整的全对MaxSim矩阵。MaxSim求和每个查询token，因此其幅度随查询token数量缩放，这意味着无法跨具有不同查询配方的模型比较分数。如果要在有界尺度上获得分数，可以将模型的相似度函数切换到MeanMaxSim，它除以查询token计数。

语义搜索应用

对于小型语料库，对所有内容进行详尽的MaxSim是最简单有效的方案。编码语料库一次，然后对每个查询与所有内容进行评分。这种方法精确但在线性总语料库token上扩展，并将每个token向量保留在内存中，适用于数千个文档而非数百万个。

对于更大规模的应用，需要真正的延迟交互索引。几种向量数据库原生索引和评分多向量：Qdrant自v1.10起，Weaviate自v1.29起，Vespa多年来一直支持，LanceDB自v0.15.0起，以及VectorChord添加了Postgres的MaxSim操作符。LightOn的fast-plaid是一个pip安装选项，直接实现PLAID。

MaxSim heatmap of the query token

检索和重排序策略

另一种方法是在不维护延迟交互索引的情况下获得延迟交互质量，即使用多向量模型作为重排序器。快速双编码器缩小大型语料库到少数候选者，然后多向量模型仅重新评分这些候选者。这种方法的优势在于索引保持正常密集索引，token向量是临时的。

视觉文档检索

延迟交互是视觉文档检索的最新技术：匹配文本查询与页面图像，图表、表格和布局保持完整，无需OCR步骤。ColPali系列模型就是这样做的，这些检查点加载和运行通过相同API。图像文档作为URL、本地路径或PIL图像传递。

音频和视频检索

多向量模型支持多种模态，包括音频和视频检索。ColQwen-Omni等模型接受所有四种模态，音频检索完全零样本，无需转录步骤。视频检索需要采样帧以避免VRAM耗尽，建议使用低分辨率和稀疏帧率。

可解释性分析

由于MaxSim是每个查询token最大值的和，排名可以精确分解：文档分数的每个点属于一个查询token和一个文档token。这使得能够精确回答'为什么这个排名在这里？'的问题。对于图像文档，解释性模块覆盖分解到页面上作为标准ColPali热图。

令牌池化技术

如果索引足迹令人担忧，最有效的控制方法是存储更少的token向量。HierarchicalTokenPooling实现token池化技术，将每个文档的token向量聚类并替换每个聚类为其均值，保持约1/pool_factor的token。这种方法在很大程度上减少冗余而非信号。

推理加速

多向量模型通过与Sentence Transformers其余部分相同的后端机制运行，支持torch（默认）、onnx和openvino，以及半精度、Flash Attention和torch.compile。在GPU上，fp16与Flash Attention是最佳配置，吞吐量比fp32提高2.44倍且无检索质量损失。

模型评估

MultiVectorNanoBEIREvaluator运行NanoBEIR套件的13个小BEIR子集，使用MaxSim评分，无需数据准备。这使得容易验证多向量vs密集嵌入的选择效果。实验表明，延迟交互在13个数据集中的9个获胜，平均NDCG得分略高于密集模型。

技术发展趋势

多向量嵌入模型代表了信息检索技术的重要发展方向。随着多模态数据的快速增长，这种能够处理文本、图像、音频和视频的统一框架显示出巨大潜力。未来的发展可能包括更高效的索引算法、更好的跨模态对齐机制，以及针对特定应用场景的专门优化。

当前的技术挑战主要集中在索引大小管理、推理速度优化和跨模态一致性等方面。token池化、量化技术和硬件加速等方法正在不断改进，使得多向量模型在实际部署中更加可行。

实际应用考虑

在选择多向量模型时，需要权衡检索质量提升与存储和计算成本。对于需要精确匹配的场景，如法律文档检索、科学文献搜索等，多向量模型的优势更加明显。而对于一般性的语义搜索任务，需要根据具体需求评估是否值得承担额外的资源开销。

部署时应考虑硬件要求、索引构建时间、查询响应延迟等因素。多向量模型通常需要更多内存和计算资源，但提供了更精确的检索结果，这在某些关键应用场景中是必要的投资。

总的来说，多向量嵌入模型技术为信息检索领域带来了重要的进步，特别是在处理复杂查询和多模态数据方面。随着技术的不断完善和优化，预计将在更多实际应用中发挥重要作用。