SPLADE 与学习型稀疏检索：让倒排索引学会语义

RAG 圈这两年聊检索，几乎默认「向量检索」三个字。但企业搜索的工程现实里，BM25 依然是很多系统的第一跳——倒排索引成熟、可控、可解释，Lucene/OpenSearch/Elasticsearch 的生态沉淀几十年。《一篇读懂 BM25》讲过它的原理与不可替代性，也讲过它的天花板：纯词法匹配，不懂语义——用户搜「怎么退货」，文档通篇写「退换货政策」里没有「退货」二字？BM25 无能为力（「退换」能部分命中，纯改写就彻底失手）。SPLADE（Formal 等人，2021）给出的方案很有意思：用神经模型学会语义扩展，但把输出做成稀疏的词权重，仍然塞进倒排索引。语义与词法，在它的框架里不是二选一。

核心机制：让模型输出「词权重表」

SPLADE 的骨架是一个预训练语言模型（BERT 类），在编码查询或文档时，把每层的输出接到词表大小的分类头上——模型对输入里的每个 token，预测「词表里每个词与当前文本的相关程度」。所有位置的预测经过 max pooling 汇总后，得到一张长度等于词表的权重表：绝大多数词是零，少数词有正权重。

这张表有两个来源的成分。原词权重：文档里真实出现的词获得与重要度相称的权重（相当于学了 TF-IDF 但比手工公式更贴语义）；扩展词权重：文档里没出现、但语义相关的词也获得非零权重——写「退换货政策」的文档，会在「退货」「退款」「售后」这些词上获得权重。查询侧同理：用户查询也会被扩展出相关词。于是匹配发生在「两份都被语义扩展过的稀疏权重表」之间，点积即得分。

这就是它与 BM25 的本质差别：BM25 的词权重是固定公式算的，词典之间没有联系；SPLADE 的词权重是模型在语料上学出来的，词与词之间的语义关系被编码进了权重分布。扩展词的存在，让「词法不匹配但语义匹配」的召回成为可能——而这原本是 dense 检索的独门领地。

三足鼎立：BM25、SPLADE、dense 各守一段

把三种检索放在一起看，分工非常清晰：

SPLADE 保留的两个 dense 检索的软肋恰好是工程上最痛的：精确匹配（产品型号、错误码、专有名词——扩展不等于替换，原词权重还在，标识符类查询依然稳）和可解释性（命中的是哪些词、权重多少，一目了然，排查检索质量时是刚需）。代价也有三笔：每篇文档入库时多一次模型推理（和嵌入同量级）；文档扩展让倒排里的 postings 变长，索引体积膨胀；查询侧也多一次模型延迟。

工程落地：基础设施是最大红利

SPLADE 最诱人的工程性质是：输出就是稀疏向量，倒排索引直接可用。权重表里非零的词就是「带权重的词条」，塞进 Lucene 类索引即可复用全部现有设施——分片、过滤、高亮、BM25 兜底混合。Elasticsearch 与 OpenSearch 近年都加入了学习型稀疏的支持（ES 的 sparse vector / 推理端点、OpenSearch 的神经稀疏检索），把模型推理做成了 pipeline 组件，不需要自己维护模型服务。对已经重度投资倒排生态的团队，这是「升级语义能力而不推翻基础设施」的路径——比引入一整套向量数据库轻得多。

自建的话，权重截断是关键参数：扩展词太多既涨索引又引噪声，实践中通常保留 top 几百个词。查询与文档可以用不同的扩展强度（查询扩得少、文档扩得多是常见配置）。与 dense 检索混合时，SPLADE 常常取代 BM25 的位置进入 RRF 或加权融合（《混合检索与重排序》的三段式完全兼容），检索质量的上限通常高于 BM25 版组合。

两阶段形态与查询侧的取舍

SPLADE 的原始形态查询与文档都用模型扩展，工程上有一个流行的简化变体：文档侧用模型扩展（离线、不赶时间），查询侧保持 BM25 式的原词匹配（在线、省一次推理）。它的依据是「查询通常已经足够聚焦，扩展的主要收益在文档侧」——文档写「退换货政策」时预先长出「退货」「退款」「售后」的权重，用户搜「退货」直接命中，查询侧不需要再扩展。这个两阶段形态省掉了查询延迟与查询侧模型服务，是搜索引擎系团队（Elasticsearch/OpenSearch 的 neural sparse 默认配置之一）偏好的形态；代价是放弃了查询侧扩展（用户查询口语化、离题措辞多的场景收益略降）。两种形态都在评测集上量一下再定，通常十几分钟的实验能省掉线上一次模型部署。

索引膨胀的量化与管理

「文档扩展让索引变大」具体有多大？粗算一下：BM25 的倒排里一篇文档贡献「它包含的去重词数」个 postings（普通中文文本约几百个）；SPLADE 截断到 top 500 词后，每篇文档固定贡献最多 500 个——索引体积大约是 BM25 的 1～3 倍（原词之外净增扩展词）。这个量级对大多数系统是可接受的（倒排索引本就远小于向量索引），但两个管理动作要做：权重阈值截断（保留 top 词时设下限权重，低权重扩展词的检索贡献小、索引贡献大）；扩展词去停用（虚词、高频通用词出现在扩展表里就砍掉——它们只会膨胀 postings 不改善检索）。OpenSearch 的 neural sparse 配置里这些开关都是现成的，自建实现时要写进管道。

混合检索里的融合配比

把 SPLADE 放进《混合检索与重排序》的三段式时，融合层的配比有经验可循。RRF 融合对「各路分数的绝对值不敏感」，SPLADE 直接替换 BM25 的位置即可，无需调参——这是它进混合体系的最低摩擦路径。加权线性融合则需要重标定：SPLADE 的分数分布比 BM25 更「尖」（扩展词命中带来的高分更陡），旧配比下的归一化参数不能沿用，跑一遍评测集重标。另一个实践信号：SPLADE 与 dense 的相关性高、与 BM25 的相关性低（它们共享语义能力），所以「SPLADE + dense」的组合多样性收益不如「BM25 + dense」，某些语料上 SPLADE + BM25（词法+学习稀疏）+ dense 的三路反而比双路好——融合几路、各路权重多少，还是那句话：评测集说话。

什么时候选它

三条判断：语料以自然语言文本为主（SPLADE 对代码、表格这类非自然语言结构的收益有限，代码检索另见 Code RAG 一篇）；已有倒排索引基础设施且希望渐进升级语义能力；查询存在改写、口语化、同义现象（用户是外部客户的企业站尤其典型）。反之，如果团队已深度投入向量生态且检索瓶颈在别处，SPLADE 不是必需品——它解决的是「BM25 不懂语义」，如果你的 BM25 场景里语义改写本来就不是痛点，升级收益有限。

模型从哪来：开源权重与蒸馏

现成权重：SPLADE 系列有公开的训练配方与社区权重（基于预训练语言模型），通用英文场景开箱即用；中文场景要选中文基座的相关实现或自训——词表覆盖与中文分词特性直接决定扩展词的质量，英文权重的中文表现通常不可用。自训与蒸馏：SPLADE 的训练目标（词表上的权重预测加相关性监督）不挑数据规模，几万对「查询-相关文档」就能训出可用的领域版本；工程上更常见的是蒸馏管线——用大模型或 dense 检索器生成软标签，蒸馏出轻量的稀疏编码器，引擎生态里的官方稀疏模型多是这样产出的。判断路径与 ColBERT 一致：现成模型在你的评测集上够好就用现成的；不够好且检索层是瓶颈，自训的几千对标注是入场费。

边界：SPLADE 不擅长的三类语料

学习型稀疏不是万金油，三类语料上的收益要打折扣。代码与强格式文本：标识符、错误码、配置片段没有「语义扩展」可言（model_id 扩展出 model_identifier 毫无价值），这类语料词法匹配本就最优，SPLADE 的推理开销白花——代码检索另见《Code RAG》。表格数据：行列结构里的语义在单元格组合里，词表权重模型捕捉不了结构关系，表格问答走专门的方案。超短查询为主的海量流量（搜索框式的一两个词）：扩展的主要收益在文档侧，查询侧开销占比升高，两阶段形态（文档扩展、查询原词）才是对的形态。还有一条多语言提醒：中英混合语料要确认模型的训练覆盖——扩展词的质量取决于语言模型对每种语言的词表语义理解，覆盖不足的语言扩展出的词是噪声。对照这四条过一遍你的语料与查询分布，SPLADE 的收益预期就清楚了。

小结

SPLADE 的位置可以这样概括：它把「语义理解」搬进了倒排索引，把「词法精确」留在了 dense 检索够不着的地方。一张模型算出的稀疏词权重表，同时具备 BM25 的基础设施亲和性与 dense 检索的语义扩展力，是两者之间被低估的第三选项。三足格局里没有全能选手——BM25 守精确、SPLADE 守「精确+改写」、dense 守纯语义——混合使用、按查询特性路由（下一篇《查询路由》讲的就是这个），才是检索层的完整答案。

参考资料

• Formal et al., SPLADE (arXiv:2107.05720) —— 稀疏词权重与扩展机制的原始论文
• Elasticsearch: Sparse vector / 学习型稀疏文档 —— 引擎侧落地形态
• OpenSearch: Neural Sparse Search —— 神经稀疏检索的两阶段实现
• 本系列前篇：《一篇读懂 BM25》《混合检索与重排序》《一篇读懂 Embedding》