深度解析 BGE-M3“双向量”生成：为什么它让 BM25+Dense 成为过去式？

在 RAG 系统的索引构建中，混合检索（Hybrid Search）一直是提升召回率的“银弹”。传统的做法是“BM25 + 通用嵌入模型”，以此兼顾关键词匹配和语义理解。但 BGE-M3 的出现，彻底打破了这一传统组合。

今天，我们就来深挖 BGE-M3 的“双向量”生成机制，并通过全方位对比，解答你心中那个最核心的疑问：有了 BGE-M3，我们还需要 BM25 吗？

一、什么是 BGE-M3 的“双向量”生成？

BGE-M3（BAAI General Embedding M3）是北京智源人工智能研究院推出的里程碑式模型，其名字中的“M”代表 Multi-Functionality（多功能性），而“双向量”正是其最核心的技术突破。

传统的嵌入模型（如 BGE-large、text-embedding-ada-002）在编码文本时，只输出一种向量——即固定长度的稠密向量（Dense Vector）（例如 768 维或 1024 维的浮点数数组）。这意味着无论文本多长，最终都被“压缩”成一个黑盒式的语义坐标。

而 BGE-M3 在编码文本时，会同时输出两种不同类型的向量：

1. 稠密向量（Dense Embedding）—— 语义的“抽象画”

• 生成方式：将文本输入 Transformer 编码器，取最后一层的[CLS]标记向量或进行平均池化（Mean Pooling）。

• 特点：固定维度（1024 维）、数值稠密（几乎每一维都不为 0）。

• 核心能力：深度语义理解与泛化。它能捕捉“苹果很好吃”和“我喜欢这种水果”之间的隐含语义关联，解决“同义不同词”的问题。它是 RAG 进行模糊语义匹配的主力军。

2. 稀疏向量（Sparse Embedding / Lexical Weights）—— 关键词的“智能摘抄”

• 生成方式：利用模型的MLM（掩码语言模型）头（即计算词汇表概率的输出层）。模型会根据上下文，为词汇表中每一个 token（约 30 万个）计算一个重要性权重。但只有极少数 token（如专有名词、核心动词）获得高权重，其余维度权重为 0，形成一个极其高维（30万维）但极度稀疏的向量。

• 特点：超高维度、极度稀疏（绝大部分为 0）、维度直接对应词表中的 Token。

• 核心能力：上下文感知的关键词匹配。它不仅仅是统计词频（像 BM25 那样），而是依赖 BERT 的注意力机制来判定权重。例如，在“苹果发布了新手机”中，“苹果”和“手机”权重极高；而在“我吃了一个苹果”中，“吃”和“苹果”权重极高。这种动态、感知上下文的稀疏权重，是传统 BM25 无法企及的。

二、BGE-M3 真的能自己做“混合检索”吗？

答案是肯定的。因为 BGE-M3 同时输出了两种向量，我们在构建索引时，自然可以分别利用它们：

1. 构建密集索引（Dense Index）：将 BGE-M3 产出的稠密向量存入支持 ANN（近似最近邻）的向量数据库中，用于语义召回。

2. 构建稀疏索引（Sparse Index）：将 BGE-M3 产出的稀疏向量存入支持稀疏向量检索的数据库中，用于精准关键词召回。

在查询时，查询文本同样经过 BGE-M3 编码输出两种向量，分别向两个索引发起检索，最后通过RRF（倒数排名融合）或加权求和，得到最终的混合检索结果。

结论非常明确：BGE-M3 原生、无缝地支持混合检索（Hybrid Retrieval）！

三、BGE-M3 的双向量可以存入 ChromaDB 吗？

答案是肯定的！而且 ChromaDB 在 2025 年就已经原生支持稀疏向量。

3.1 ChromaDB 的稀疏向量支持

ChromaDB 从 2025 年起正式支持稀疏向量搜索，主要特点包括：

• 原生支持 BM25 和 SPLADE 风格的稀疏嵌入

• 支持在现有 Collection 中添加稀疏向量，无需重建密集索引

• 支持将稀疏向量与密集向量结合，实现一站式混合检索

• 支持通过 RRF 等算法融合两种检索结果

3.2 方式一：使用 HuggingFaceSparseEmbeddingFunction（官方推荐）

ChromaDB 官方提供了HuggingFaceSparseEmbeddingFunction，可以直接加载 BGE-M3 模型并生成稀疏向量：

from chromadb.utils.embedding_functions import HuggingFaceSparseEmbeddingFunction # 创建稀疏嵌入函数，直接加载 BGE-M3 sparse_ef = HuggingFaceSparseEmbeddingFunction( model_name="BAAI/bge-m3", device="cpu" # 可选 "cuda" ) # 生成稀疏向量（返回 dict[int, float]，键为 token ID，值为权重） texts = ["FAISS是一个用于高效相似性搜索的库。", "LangChain是一个LLM应用开发框架。"] sparse_embeddings = sparse_ef(texts) # 输出示例：[ # {1523: 0.82, 4521: 0.67, 8932: 0.54, ...}, # 第一个文本的稀疏向量 # {2314: 0.91, 6732: 0.58, 1245: 0.43, ...} # 第二个文本的稀疏向量 # ]

在 ChromaDB 中存储 BGE-M3 稀疏向量的完整示例：

import chromadb from chromadb import Schema, SparseVectorIndexConfig, K from chromadb.utils.embedding_functions import HuggingFaceSparseEmbeddingFunction from sentence_transformers import SentenceTransformer # 1. 创建 Schema，添加稀疏向量索引 schema = Schema() sparse_ef = HuggingFaceSparseEmbeddingFunction( model_name="BAAI/bge-m3", device="cpu" ) schema.create_index( config=SparseVectorIndexConfig( source_key=K.DOCUMENT, # 从文档内容生成稀疏向量 embedding_function=sparse_ef ), key="sparse_embedding" # 稀疏向量存储在 metadata 的此字段中 ) # 2. 创建 Collection（同时支持稠密和稀疏） client = chromadb.Client() collection = client.create_collection( name="bge_m3_hybrid_collection", schema=schema, embedding_function=your_dense_ef # 稠密向量嵌入函数（可用 SentenceTransformer） ) # 3. 添加文档（稠密和稀疏向量自动生成） collection.add( ids=["doc1", "doc2"], documents=[ "FAISS是一个用于高效相似性搜索和密集向量聚类的库。", "LangChain是一个用于开发由语言模型驱动的应用程序的框架。" ] ) # 4. 混合检索（同时使用稠密和稀疏） from chromadb import Search, Knn dense_rank = Knn(query="向量检索", key="embeddings") # 稠密检索 sparse_rank = Knn(query="FAISS", key="sparse_embedding") # 稀疏检索 search = (Search() .rank(dense_rank) .rank(sparse_rank) .rrf() # RRF 融合 .limit(5) ) results = collection.search(search)

3.3 方式二：使用 Superlinked SIE（企业级方案）

如果你需要更强大的稀疏向量生成能力，Superlinked 的sie-chroma包提供了对 BGE-M3 的深度集成：

from sie_chroma import SIESparseEmbeddingFunction import chromadb # 创建 Superlinked 稀疏嵌入函数 sparse_ef = SIESparseEmbeddingFunction( base_url="http://localhost:8080", # SIE 服务地址 model="BAAI/bge-m3", ) # 返回格式：dict[int, float] —— token ID 到权重的映射[reference:32] client = chromadb.Client() collection = client.create_collection( name="documents", embedding_function=sparse_ef, # 直接用 BGE-M3 生成稀疏向量 )

3.4 ChromaDB 存储 BGE-M3 双向量的核心要点

四、核心争议点：BGE-M3 vs. 传统 BM25+BGE-Dense

既然 BGE-M3 自己能做混合检索，那我们还需要老一套的“BM25（统计关键词）+ 另一个普通稠密模型”吗？

结论先行：在绝大多数企业级 RAG 场景中，你不再需要 BM25 了，用 BGE-M3 自己生成的“学习型稀疏向量”去替换 BM25 是最佳选择。

下面我从四个维度，为你详细拆解两者的本质区别，并解释为什么 BGE-M3 是“降维打击”：

1. 机制维度：割裂的“拼凑” vs 统一的“原生”

• BM25 + Dense：这本质上是“三国鼎立”式的拼凑。BM25 是一个纯粹的统计学算法，基于词频和逆文档频率计算权重，完全不理解语义；而 Dense 部分负责理解语义。两者在底层逻辑上是完全割裂的，像两个说着不同语言的人，只能靠翻译（应用层融合逻辑）勉强合作。

• BGE-M3 混合检索：这是“统一战线”式的原生设计。稠密向量和稀疏向量由同一个深度模型（Transformer）在统一的训练目标（对比学习 + MLM）下共同产出。它们从“出生”那一刻起就互相配合，融合效果自然远超生硬的拼凑。

2. 智能维度：统计“盲人” vs 语义“大脑”

• BM25：它是“瞎子摸象”。无论在哪句话里，“苹果”这个词的 IDF 权重对 BM25 来说都是一样的。如果用户搜“苹果”，BM25 会把“我喜欢吃苹果”和“苹果电脑好用”都匹配上，它完全分不清“水果”和“公司”的语境。

• BGE-M3 稀疏向量：它是“火眼金睛”。它能根据整句话的上下文动态调整词权重。如果句子是“苹果手机很流畅”，模型会给“苹果”、“手机”、“流畅”打出极高的稀疏权重，而自动忽略“很”；如果句子是“这个苹果真甜”，则会给“苹果”、“甜”高权重，并自动降低“这个”的权重。这种精确到语境的能力，是 BM25 这种“死记硬背”的算法永远无法提供的。

3. 匹配维度：死板的“字符” vs 灵动的“语义”

• BM25：它是一个“杠精”，只认死理——必须字符完全匹配。例如，如果用户搜“ChatGPT”，BM25 只会找包含这 7 个字符的文档。如果文档里写的是“GPT-4”，BM25 就搜不到，因为它不懂这两个词其实高度相关。

• BGE-M3 稀疏向量：它是一个“学霸”，因为它在海量语料中预训练过。即使你搜“ChatGPT”，它也能通过子词（Subword）的语义关联，在稀疏向量空间中对“GPT-4”、“OpenAI”等高度相关的实体“网开一面”，把它们也拉进召回范围，极大地降低了漏召回率。

4. 运维维度：人工“修修补补” vs 模型“自动过滤”

• BM25：它像一个需要保姆照顾的巨婴。你需要人工维护一个庞大的停用词表，告诉它“的”、“了”、“吗”这些词是没用的，否则它们就会像噪音一样干扰打分结果。这需要不断地人工调优。

• BGE-M3 稀疏向量：它是一个“懂事的成年人”。模型通过 MLM 预训练，早就知道“的”、“是”这类词在语义贡献上趋近于零。所以它输出的稀疏向量中，这些词的维度权重天然就是 0 或极低值。不需要停用词表，不需要人工调参，开箱即用！

五、终极对决：系统架构复杂度的颠覆性差异

• BM25 + Dense：你需要部署两套独立的系统。一套是传统搜索引擎（如 Elasticsearch），负责 BM25 倒排索引；另一套是向量数据库，负责稠密索引。查询时，你需要向两个地方发起请求，再在应用层编写复杂的硬编码逻辑来融合结果。运维两套系统，调试两个接口，痛苦翻倍。

• BGE-M3 混合检索：你只需要一套支持双向量存储的数据库（如 ChromaDB 或 Milvus）。模型一次推理输出两种向量，数据库执行一次混合查询（自带 RRF 融合策略），直接返回最终结果。系统架构极简，代码优雅，调试方便。

六、BGE-M3 的完整生态：不只是“双向量”

在本文的结尾，我们有必要全面了解 BGE-M3 的完整生态。你之前已经了解了它的“双向量”能力（属于 Multi-Functionality），但 BGE-M3 名字中的“M3”其实代表三大核心特性：

1. 多语言性（Multi-Linguality）

BGE-M3 支持超过 100 种语言的语义表示及检索任务。这意味着你可以：

• 用中文搜索英文文档（跨语言检索）

• 在一个知识库中混合存储和处理多语言文档

• 无需为每种语言单独训练或部署模型

BGE-M3 在 MIRACL（多语言检索）和 MKQA（跨语言检索）等权威评测中全面领先。

2. 多粒度性（Multi-Granularity）

BGE-M3 最高支持8192 个 token的输入长度。这意味着它可以高效处理：

• 短句（如用户查询、商品标题）

• 段落（如新闻摘要、产品描述）

• 篇章（如技术博客、报告章节）

• 完整文档（如论文、合同、书籍章节）

相比之下，许多传统嵌入模型只支持 512 个 token，长文本被迫截断，导致信息丢失。BGE-M3 的 8192 token 容量让长文档的完整语义建模成为可能。

3. 多功能性（Multi-Functionality）

这是你之前已经深入了解的部分——BGE-M3 同时支持三种检索模式：

三种方式联合检索的 BGE-M3（ALL）在多项评测中全面领先。

4. FlagEmbedding 开源生态

BGE-M3 隶属于智源的FlagEmbedding开源项目，这是一个聚焦于检索增强 LLM 领域的完整技术栈，包括：

这意味着，当你选择 BGE-M3 时，你不仅仅获得了一个模型，而是进入了一个完整的技术生态，可以无缝衔接从嵌入、检索到重排序的完整 RAG 流水线。

七、总结：你该怎么选？

基于以上分析，我为你梳理出最清晰的选型路线图：

对于新项目，我的建议是：

1. 数据库选型：使用支持双向量的 ChromaDB（0.5.0+）或 Milvus（2.4+）

2. 嵌入模型：直接采用 BGE-M3，一次编码同时获得稠密和稀疏两种向量

3. 检索策略：使用 ChromaDB 的混合检索 API（稠密 + 稀疏 + RRF 融合）

4. 重排序（可选）：接入 BGE Reranker 进一步精排结果

BGE-M3 的双向量设计，不仅是一次模型升级，更是一次 RAG 架构范式的革新。它将过去“两套系统、两种算法”的笨重混合检索，浓缩为“一次编码、统一存储”的极简流程。如果你的数据库（如 ChromaDB 0.5+ 或 Milvus 2.4+）支持稀疏向量，你可以拥抱 BGE-M3 原生的混合检索。

如果本文对你有帮助，欢迎点赞、收藏、转发！有任何疑问，欢迎在评论区交流讨论～