“多语言混合搜索模型”是指一个模型同时产生 dense embedding + learned sparse representation（神经稀疏向量），从而不再需要单独维护 dense + BM25 两套模型/索引，目前最值得关注的是 BGE-M3，另外还有比较新的 MILCO、SPLADE 系列。
目前比较值得看的
| 模型 | 多语言 | Dense | Sparse | Multi-vector | 特点 |
|---|---|---|---|---|---|
| BGE-M3 | ✅ 100+ | ✅ | ✅ | ✅ | 最成熟、生态最好 |
| MILCO 300M/560M | ✅ | ❌/重点在 Sparse | ✅ | ❌ | 专门解决跨语言稀疏检索 |
| SPLADE v3 | 主要英语 | ❌ | ✅ | ❌ | 神经稀疏检索代表 |
| multilingual E5 / Qwen3-Embedding 等 | ✅ | ✅ | ❌ | ❌ | 主要还是 dense |
BGE-M3 比较特殊：一次 encoder forward 就可以得到 dense、sparse、ColBERT-style multi-vector 三种表示，并支持 100+ 语言、最长 8192 tokens。(BGE Model)
关键问题：它和 Dense + BM25 到底有什么区别？
我认为这是最值得关注的地方。
传统方案：
Query
├── Dense Embedding ──→ Vector DB
│
└── BM25 ─────────────→ Inverted Index
↓
RRF / 加权融合
↓
Reranker例如：
score = 0.6 * dense_score + 0.4 * bm25_scoreBGE-M3：
┌── dense vector
Query → BGE-M3 ──┼── sparse vector
└── multi-vector其中 sparse 并不是普通 BM25，而是模型学习出来的 lexical weights（词汇权重）。它和 SPLADE 的思路类似：模型会预测哪些词应该参与匹配以及它们的重要程度。(BGE Model)
所以它实际上是：
Dense：
“汽车” ≈ “轿车” ≈ “automobile”
Sparse：
“XR-7742” → XR-7742
“Boeing 737 MAX” → Boeing / 737 / MAX两者互补。
相比 Dense + BM25，优势是什么？
1. 跨语言能力明显更自然
这是 BGE-M3 这种模型最大的意义之一。
例如：
Query:
What causes battery thermal runaway?
Document:
锂离子电池热失控的主要原因包括……Dense 本身就能够跨语言匹配。
但传统 BM25：
thermal runaway和：
热失控完全不是同一组 token。
BGE-M3 的 sparse 部分则是经过多语言训练的神经词汇匹配，因此可以学习跨语言的 lexical correspondence。BGE-M3 的论文报告其支持 100+ 语言，并针对 multilingual / cross-lingual retrieval 做了训练。(arXiv)
而更进一步的 MILCO 就是专门针对这个问题设计的 multilingual learned sparse retrieval，它把不同语言映射到共享的 lexical space。(Hugging Face)
2. Sparse 比 BM25 更“聪明”
BM25 基本上是：
出现了这个词 → 加分
出现次数、文档频率 → 调整分数而 learned sparse：
Query
↓
Transformer
↓
token weights
↓
inverted index模型可以学习：
"car accident"
↓
automobile
vehicle
collision
crash也就是说它可以做一定程度的词汇扩展（lexical expansion）。
SPLADE 的核心就是这个思想，而且仍然可以使用倒排索引，因此兼具 lexical matching 和神经语义扩展。(GitHub)
这对技术文档尤其有意思。
例如：
query:
mysql connection pool exhausted
document:
database/sql reports "too many connections"BM25 可能抓不到足够强的词面关系。
Dense 能理解语义，但可能把很多“数据库连接相关”的文档都召回来。
learned sparse 则有机会同时做到：
connection
pool
exhausted
too many connections这种语义扩展 + lexical precision。
3. 一个模型同时得到 dense + sparse
这是工程上的一个很大的优势。
BGE-M3 可以一次推理得到：
dense_vec
lexical_weights
colbert_vecs官方也明确建议把 dense + sparse 做 hybrid retrieval，再进行 reranking。(Hugging Face)
因此：
BGE-M3
│
├── dense index
└── sparse index
↓
fusion
↓
reranker而不是：
Dense Model
+
BM25 tokenizer/index维护两套完全不同的语言处理体系。
但它并不是全面碾压 BM25
这是很重要的。
BM25 有一个非常强的优势：
精确匹配极其可靠。
比如搜索：
ERR_CONNECTION_RESET或者：
Qdrant 1.19.0或者：
0x80070005或者：
github.com/foo/barBM25：
找到了就是找到了。
神经 sparse：
模型认为这个 token 重要。
中间反而多了一层模型判断。
所以对于：
- SKU
- 产品型号
- 错误码
- API 名称
- 类名
- 函数名
- IP 地址
- UUID
- 版本号
- 专有名词
BM25 依然非常强。
这也是为什么实际生产系统中，我通常不会建议：
BGE-M3 sparse完全替代：
BM25而更倾向于：
Dense + BM25 + Neural Sparse或者至少：
Dense + BM25再根据 benchmark 决定是否加入 neural sparse。
还有一个非常现实的区别：索引大小
Dense：
1024 dimensions × float16
≈ 2 KB / document百万文档就是大约：
2 GB还没算 ANN index。
BM25：
倒排索引通常对于文本搜索非常高效。
Neural sparse：
词 → weight
词 → weight
词 → weight
...同样可以走 inverted index，因此不会像 dense 那样每个文档固定保存 1024/1536 个浮点数。
SPLADE 的研究也专门研究了如何通过稀疏化降低索引和检索成本，并取得接近 BM25 的检索延迟。(GitHub)
如果你的场景是“多语言 RAG”，我会这么选
如果你现在做的是类似：
中文 + 英文 + 日文 + 韩文
↓
RAG / Qdrant我会优先考虑：
方案 A：简单、成熟
BGE-M3 dense
+
BM25
↓
RRF
↓
reranker这是我最推荐的生产起点。
方案 B：追求检索效果
BGE-M3 dense
+
BGE-M3 sparse
+
BM25
↓
RRF
↓
multilingual reranker
↓
LLM尤其适合：
技术文档、知识库、代码文档、混合语言企业资料。
方案 C：如果你非常看重跨语言 lexical retrieval
可以关注 MILCO。
它的目标非常明确：解决 multilingual learned sparse retrieval，而且 2026 年的结果已经开始显示它在 multilingual/cross-lingual sparse retrieval 上可以超过 BGE-M3、Qwen3-Embedding 等基线。(Hugging Face)
不过它的生态成熟度目前显然还不能和 BGE-M3 相比。
一句话总结：
Dense + BM25 是“语义搜索 + 精确词匹配”；BGE-M3 这类模型是“语义搜索 + 模型学习的词汇匹配”，最大的价值在于把 lexical matching 也变成了多语言、可泛化的神经检索。
但对于生产 RAG，我暂时不会因为 BGE-M3 sparse 的出现就把 BM25 扔掉——尤其是你的数据里面如果有大量 API、错误码、版本号、代码、产品型号，BM25 依然是一把非常锋利的手术刀。
如果你现在是准备在 Qdrant 里实现这个方案，BGE-M3 的 dense+sparse 在 Qdrant 里的具体索引结构和 prefetch + fusion 设计也挺值得讲，因为它和单纯的 dense + BM25 + RRF 在数据库层面的实现方式不太一样。