在 RAG 系统的索引构建中混合检索Hybrid Search一直是提升召回率的“银弹”。传统的做法是“BM25 通用嵌入模型”以此兼顾关键词匹配和语义理解。但 BGE-M3 的出现彻底打破了这一传统组合。今天我们就来深挖 BGE-M3 的“双向量”生成机制并通过全方位对比解答你心中那个最核心的疑问有了 BGE-M3我们还需要 BM25 吗一、什么是 BGE-M3 的“双向量”生成BGE-M3BAAI 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 同时输出了两种向量我们在构建索引时自然可以分别利用它们构建密集索引Dense Index将 BGE-M3 产出的稠密向量存入支持 ANN近似最近邻的向量数据库中用于语义召回。构建稀疏索引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_nameBAAI/bge-m3, devicecpu # 可选 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_nameBAAI/bge-m3, devicecpu ) schema.create_index( configSparseVectorIndexConfig( source_keyK.DOCUMENT, # 从文档内容生成稀疏向量 embedding_functionsparse_ef ), keysparse_embedding # 稀疏向量存储在 metadata 的此字段中 ) # 2. 创建 Collection同时支持稠密和稀疏 client chromadb.Client() collection client.create_collection( namebge_m3_hybrid_collection, schemaschema, embedding_functionyour_dense_ef # 稠密向量嵌入函数可用 SentenceTransformer ) # 3. 添加文档稠密和稀疏向量自动生成 collection.add( ids[doc1, doc2], documents[ FAISS是一个用于高效相似性搜索和密集向量聚类的库。, LangChain是一个用于开发由语言模型驱动的应用程序的框架。 ] ) # 4. 混合检索同时使用稠密和稀疏 from chromadb import Search, Knn dense_rank Knn(query向量检索, keyembeddings) # 稠密检索 sparse_rank Knn(queryFAISS, keysparse_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_urlhttp://localhost:8080, # SIE 服务地址 modelBAAI/bge-m3, ) # 返回格式dict[int, float] —— token ID 到权重的映射[reference:32] client chromadb.Client() collection client.create_collection( namedocuments, embedding_functionsparse_ef, # 直接用 BGE-M3 生成稀疏向量 )3.4 ChromaDB 存储 BGE-M3 双向量的核心要点要点说明稠密向量存储使用SentenceTransformer加载 BGE-M3通过collection.add(embeddings...)存入稀疏向量存储使用HuggingFaceSparseEmbeddingFunction存入 metadata 的指定字段混合检索使用 ChromaDB 的SearchAPI同时执行稠密和稀疏检索通过 RRF 融合版本要求需要 ChromaDB 0.5.0 以上版本推荐使用最新版本四、核心争议点BGE-M3 vs. 传统 BM25BGE-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-LingualityBGE-M3 支持超过 100 种语言的语义表示及检索任务。这意味着你可以用中文搜索英文文档跨语言检索在一个知识库中混合存储和处理多语言文档无需为每种语言单独训练或部署模型BGE-M3 在 MIRACL多语言检索和 MKQA跨语言检索等权威评测中全面领先。2. 多粒度性Multi-GranularityBGE-M3 最高支持8192 个 token的输入长度。这意味着它可以高效处理短句如用户查询、商品标题段落如新闻摘要、产品描述篇章如技术博客、报告章节完整文档如论文、合同、书籍章节相比之下许多传统嵌入模型只支持 512 个 token长文本被迫截断导致信息丢失。BGE-M3 的 8192 token 容量让长文档的完整语义建模成为可能。3. 多功能性Multi-Functionality这是你之前已经深入了解的部分——BGE-M3 同时支持三种检索模式检索模式说明适用场景稠密检索Dense将文本映射为单个向量通过向量相似度判断相关性语义搜索、模糊匹配稀疏检索Sparse向量维度为整个词表仅对出现的词计算权重关键词精确匹配、专有名词检索多向量检索Multi-Vector对每个文本使用多个向量表示如 ColBERT 风格细粒度检索、重排序三种方式联合检索的 BGE-M3ALL在多项评测中全面领先。4. FlagEmbedding 开源生态BGE-M3 隶属于智源的FlagEmbedding开源项目这是一个聚焦于检索增强 LLM 领域的完整技术栈包括子项目功能LLM Embedder大语言模型嵌入BGE Embedding通用文本嵌入BGE 系列BGE Reranker重排序模型LM-Cocktail模型微调与融合Activation Beacon长上下文 LLMC-MTEB中文嵌入模型评测基准这意味着当你选择 BGE-M3 时你不仅仅获得了一个模型而是进入了一个完整的技术生态可以无缝衔接从嵌入、检索到重排序的完整 RAG 流水线。七、总结你该怎么选基于以上分析我为你梳理出最清晰的选型路线图你的场景特征推荐方案核心理由纯语义搜索如智能客服、闲聊单独使用 BGE-M3 稠密向量不需要关键词匹配时只用密集向量即可存储和计算成本最低关键词密度高如法律条文、产品型号查找强烈推荐 BGE-M3 混合检索双向量~~不再推荐 BM25 其他 Dense~~BGE-M3 的稀疏向量在专有名词召回上全面超越 BM25且系统架构更简单。这是当前 RAG 索引构建的“最优解”。遗留系统无法升级ES 集群已构建且不支持稀疏向量保留 BM25 接入 BGE-M3 稠密受限于现有基础设施的无奈之选。但如果是新项目请务必直接选择支持稀疏向量的最新版 ChromaDB 或 Milvus对于新项目我的建议是数据库选型使用支持双向量的 ChromaDB0.5.0或 Milvus2.4嵌入模型直接采用 BGE-M3一次编码同时获得稠密和稀疏两种向量检索策略使用 ChromaDB 的混合检索 API稠密 稀疏 RRF 融合重排序可选接入 BGE Reranker 进一步精排结果BGE-M3 的双向量设计不仅是一次模型升级更是一次 RAG 架构范式的革新。它将过去“两套系统、两种算法”的笨重混合检索浓缩为“一次编码、统一存储”的极简流程。如果你的数据库如 ChromaDB 0.5 或 Milvus 2.4支持稀疏向量你可以拥抱 BGE-M3 原生的混合检索。如果本文对你有帮助欢迎点赞、收藏、转发有任何疑问欢迎在评论区交流讨论