夜雨聆风一句话总结：单向量检索把整篇文档压缩成一个摘要，多向量检索则保留 token 级线索；它不是免费的升级，而是一笔用索引空间换召回质量的工程交易。
很多 RAG 系统的第一步，都是把一段文本变成一个向量。
这一步很有效：文档可以提前编码，查询时只要做向量相似度计算，就能从大规模库里快速找出候选。
但它也做了一件不可逆的事：把一整段文本里不同的重要信息，压缩进一个固定长度的数字数组。一个罕见的人名、一个产品编号、一条关键限制，可能和其他内容一起被平均掉。
Hugging Face 最近介绍的 MultiVectorEncoder，把另一条路线带进了 Sentence Transformers 6.0：不再为整篇文档只保留一个向量，而是为每个 token 保留一个向量，把查询与文档的精细匹配延后到打分时。
这不是所有 RAG 都需要的方案，但它很适合回答一个问题：当“文档整体大致相关”还不够时，检索系统怎样保住局部证据？
单向量的优势，正是它的限制
普通的 dense embedding 会把一段文本压成一个固定维度的向量，比如 384、768 或 1024 个数字。
这样做的好处很明确：索引小、查询快、工程链路成熟。几百万条文档都可以提前编码，查询时通过近似最近邻搜索快速缩小范围。
限制也同样明确。
如果一段文档同时包含产品型号、适用条件、例外条款和时间限制，这些信息都要争夺同一个向量里的表达空间。查询只关心其中一个稀有细节时，整体相似度可能把它淹没。
例如，用户问的是“有木质腿、圆形靠垫的绿色沙发”。一段只写“绿色沙发”的文档，可能因为整体语义相近而排在前面；真正同时包含四个条件的文档，反而可能因为被压缩得太厉害而没有获得足够分数。
多向量把匹配推迟到最后一刻
多向量模型保留每个 token 的表示，再用 MaxSim 做打分：对查询里的每个 token，找出文档中与它最相似的 token，把这些最高匹配加起来。
可以把它理解成一种“软对齐”：查询里的每个要求，都要在文档里找到一个能解释它的证据。
它不要求两个词字面相同。上下文向量可以让 live 找到 inhabit，同时又保留产品编号、函数名和罕见实体这种精确 token 的独立信号。
这就是 late interaction 的位置：
cross-encoder 在模型内部让查询和文档充分交互，但每次查询都要重新处理文档； dense bi-encoder 几乎不交互，换来很快的预计算和检索； multi-vector 让文档仍然可以独立编码、提前建索引，但把更细的 token 对齐留到打分阶段。
它在精度和成本之间，站在两者中间。
代价是索引会明显变大
质量提升并不是免费得到的。
Hugging Face 给出的示例里，4,874 个 Natural Questions 段落，用 dense 模型只需要 4,874 个向量；用 LateOn 则产生了 608,414 个 token 向量。按 float32 计算，MiniLM 索引约 7.5 MB，LateOn 约 311.5 MB，存储量大约是前者的 42 倍。
当然，量化和专用索引可以把成本压下来。相同数据经过 fast-plaid 索引后约为 92 MB，已经接近不少大维度 dense embedding 的量级。
但工程团队仍然要正视几个问题：
文档越长，token 向量越多； 编码和打分的计算量会上升； 多向量分数不能随意跨模型比较； 模型的 document_length会决定哪些内容根本进不了索引。
如果团队没有清楚的召回问题，直接把所有文档改成多向量，可能只是把存储账单放大。
三种落地方式，不必一上来重做整套 RAG
第一种，小规模语料直接做精确打分。
几千篇文档以内，可以提前编码所有文档，查询时做完整的 MaxSim。实现简单，适合验证质量和建立基线，但规模扩大后会受到线性扫描限制。
第二种，dense 检索后用多向量重排。
先用成熟的单向量索引从大库里取出前 50 或前 100 个候选，再用多向量模型做第二阶段重排。这样既保留了第一阶段的速度，也让第二阶段重新关注局部证据，不必为整个语料库维护巨大的多向量索引。
第三种，为大规模系统使用专用 late-interaction 索引。
Qdrant、Weaviate、Vespa、LanceDB、VectorChord 等系统已经提供了不同形式的多向量存储与 MaxSim 支持；不想运行服务，也可以看 fast-plaid、PyLate 这类组件。
选择哪一种，应该由错误类型决定：如果问题是“候选根本召回不到”，重排解决不了；如果候选已经找到了，但排序总把包含关键细节的文档压到后面，多向量重排才更有价值。
多模态文档是它更容易体现优势的地方
多向量检索还有一个很重要的应用：视觉文档检索。
ColPali 一类模型可以直接把页面图像变成 token 级表示，文字查询不必先经过传统 OCR，再去匹配纯文本。对于表格、版式复杂的 PDF、扫描文档和图文混排页面，这条路线保留了更多原始布局信息。
当然，视觉检索也会增加模型、索引和评估的复杂度。它更适合那些 OCR 丢失的信息确实影响答案质量的场景，而不是为了追赶技术名词。
RAG 的下一步，不是“向量越多越好”
多向量模型提醒工程团队：检索质量的瓶颈，有时不是模型不够大，而是系统太早把信息压扁了。
但它也提醒了另一件事：每一次保留更多信息，都要付出存储、计算、延迟和运维成本。
比较稳妥的路线是先建立错误样本：哪些问题被 dense 检索漏掉？是稀有实体、多个约束、长文档，还是视觉布局？只有当错误模式与 token 级匹配有关时，再把多向量引入对应的阶段。
好的 RAG 不是选择最新的 embedding，而是知道哪些信息不能在检索链路中过早丢掉。
参考资料：Hugging Face Blog，《Multi-Vector (Late Interaction) Embedding Models with Sentence Transformers》。文中关于索引规模、MaxSim 和 Sentence Transformers 6.0 的说明均来自该技术文章。