Sparse Embedding 还是 BM25?

Infinity 开源以来得到了社区的广泛积极响应，针对我们所宣传的 RAG 必备关键技术——多路召回（向量召回，全文搜索，还有结构化数据查询），有的小伙伴提到，其实单纯用向量也可以满足：我们传统上所说的向量检索，是一种基于稠密的向量数据进行的查询，这称之为 Dense Embedding，还有一类向量数据，是稀疏向量数据，称为 Sparse Embedding，后者可以提供 RAG 所必备的精确查询，因此结合两类向量数据，就可以做多路召回了（2路召回），有了 Sparse Embedding，就可以不需要全文搜索，可以完全替换 BM25 （一种最常见的全文索引的排序方式，可以看作是 TF/IDF 的变种）。那么我们就来看看，是否真的可以这样。

所谓Dense Embedding，是指向量的维度未必很高，但每个维度都有数字表征为某种权重。而Sparse Embedding是指向量的大多数维度都是零，只有个别维度有值，整体向量的维度可以很高。例如下边2个例子，上边的是Dense Embedding，下边的是Sparse Embedding，由于大多数维度没有值，因此可以采用 （位置，值）的形式表达向量中每个存在权重的维度。

[0.2, 0.3, 0.5, 0.7,......]
[{ 331 : 0.5 }, { 14136 : 0.7 }]

Sparse Embedding 用于精确召回，乃至多路召回，大部分知名的向量数据库都有，例如我们可以在文章最后的参考文献 [1-3] 中看到。简单地讲，稀疏向量就是指向量的维度很高，比如有 3 万维，其中每个维度代表一个单词，采用一个专用的 Embedding 模型将文档投射到一个稀疏向量上，让这个稀疏向量与文档的语言词汇一致，随后在词这个维度上进行执行检索策略，就可以起到精确召回的效果。从这个角度来看，稀疏向量跟全文搜索的倒排索引很像：以下图的这个简易倒排索引所示，我们按照列为单元来看倒排索引，那么每列就可以表征为一个文档所包含的单词列表，这其实就是一种稀疏向量。图中的 3 个红色框分别代表了文档 ID 为 1，3，7 的三个不同的稀疏向量。而倒排索引则提供了稀疏向量的高效检索方式。

产生稀疏向量的 Embedding 模型跟产生普通稠密向量的 Embedding 模型不同，后者把文档投射到一个稠密向量，向量只能表征文档的语义关系，而前者则只能用某个特定维度跟某个单词对应起来，无法表征语义。所谓语义，其实最简单的总结，就是它本质上代表了不同单词，在一个上下文窗口共现( Co-occurrence)的概率——这种计算方式，正是最早用语义去表征单词和文档的手段。 当下的 Embedding 模型，则是在所谓共现的基础之上，解决了表征鲁棒性等等问题，但它们的本质，跟最早的语义定义，并没有本质的区别。 相反，产生稀疏向量的 Embedding 模型，则无需这种计算，它解决的是传统信息检索( Information Retrieval) 过程中如何在以上倒排索引的基础之上，进一步对单词进行裁剪、扩展和定义权重的过程，这里边最知名和有代表性的工作就是 SPLADE （参考文献 4），它利用一个标准的预训练数据，将文档中的冗余词删除，并且增加相应扩展词，从而形成一个标准的稀疏向量输出。 这里的冗余词删除，其实就类似传统搜索引擎中分词过程中的“去停用词”，增加相应扩展，也类似传统搜索引擎的查询同义词等扩展技术。站在使用的角度，它可以把任何文档都表征为一个 3万维的稀疏向量，向量每个维度表征这个单词的权重。在不同的信息检索( Information Retrieval) 评测任务中，采用 SPLADE 稀疏向量取得了比传统搜素引擎基于 BM25 排序方式好很多的召回表现，如下图所示：

那么，是否就可以说，有了稀疏向量配合，多路召回就足够，不需要全文搜索了呢？我们来看看最有代表性的稀疏 Embedding 模型 SPLADE：
SPLADE 这类工作来源于近十年来信息检索领域研究不断演进的结果。它是这样得到的： 先用一个预训练语言模型比如 BERT 来做热启动，给网络增加2个损失函数，一个是用来排序的 Ranking Loss，一个是保证稀疏化的 Regularization Loss ，用来学习到在每个单词的权重，以及它可以用来被做扩展的单词（可以类比为同义词）。SPLADE 是利用微软的 MSMARCO 数据集进行训练的，该数据集是先用 BM25 等传统搜索引擎召回方式，把通用领域问答数据整理成“提问：回答列表”的形式，再通过人工标注方式，让更相关的回答排在前边，大概一共有几十万这样的问答对列表。因此我们可以看出：

1. SPLADE 是一个预训练模型，它利用现有的语言模型基于人工标注的搜索/排序数据进行训练，得到最终的结果。因此，在这些数据上， SPLADE 一定比简单的 BM25 表现好。
2. 但我们并不能得出 SPLADE 在所有任务上都能表现好的结论，因为在绝大多数情况下，企业自身的数据，跟 SPLADE 训练的数据，并不是一个领域。尽管用来训练 SPLADE 的数据具备通用性，但它的通用程度，远远没有广泛到覆盖任何场景，毕竟这个数据，只是给学术研究用来评测的一个数据集。
3. 一个不错的实践，是在每家企业，都用 SPLADE，结合企业自身的数据，训练出专有的稀疏化 Embedding 模型，但这带来两方面的问题： 其一，这导致将 RAG 应用到企业的复杂性和成本显著上升；其二，训练数据很难获得，这是比技术性问题更难解决的事情。

事实上，我们所说的多路召回中的全文搜索，并不是简单将 BM25 拿来用就结束了，这些工作，在具体的召回中都是必不可少的：

1. 行业词典，以及基于行业的查询扩展。单词在不同场景下的权重都有所不同，针对金融和针对法律的词权重肯定不一样。这正如有了 Elasticsearch，并不代表搜索的结果就足够好一个道理。
2. 召回和排序是个需要方便定制的任务，尤其对于企业场景。例如： 针对不同业务字段的权重肯定会不一样，这些权重需要能灵活定义； 有很多需要特殊处理的召回规则，比如常见的通配符检索，前缀查询，编辑距离查询，以及短语查询等等，它们都在不同时候需要用到。可能有人会问，这些查询的语法挺复杂的，这不是增加了用户使用成本？ 答案确实如此，但是在一个 RAG 系统的实施中，这些工作是由 RAG 的中间件来负责的，用户只需要用自然语言提问即可，中间件会把这些提问转化成为符合意图的查询条件。 而数据库本身，需要提供尽可能多的可定制性，才能满足多样化的业务场景。

在信息检索和搜索引擎领域，基于 Embedding 来做召回的工作已经存在很多年，这些 Embedding，都是通过 LTR （Learning To Rank）排序学习机制得到的。因此，对于运营一个面向 C 端的搜索引擎来说，获取到足够的用户反馈，再辅之以足够的人工标注，产生出适合自身需要的数据集，是提升自身服务质量的不二选择。 但即便如此，任何一个面向 C 端用户的搜索和对话场景，都是综合了各种方式，共同得到结果的，包括基于倒排索引和网页权重的，基于稀疏向量的，基于稠密向量的，等等，并且在最后的 Reranker 重排序阶段，也是采用同样类似的机制训练得到足够好的排序模型得到最终排序结果。而在面向企业的场景中，这些数据的获取会非常困难，Embedding 模型的通用性也远远没有达到足够覆盖的地步，因此，数据库本身的灵活性和可定制性将非常重要，而将数据库成功用于 RAG 实施，也并不是简单的像传统数据库部署完毕由 DBA 接管即可，在 RAG 中，没有 DBA 的存在，只有将数据应用到具体场景和企业的实施，这是件既复杂又有足够高价值的工作。 回到标题， Sparse Embedding 还是 BM25 ？ 这其实不是一个选择题，答案显而易见，都要，而且只有它们还远不够。

关注Infinity，我们将持续推进数据库本身的开源，也持续推进将 RAG 真正落实到每一家企业。


参考资料

1. https://qdrant.tech/articles/sparse-vectors/
2. https://www.pinecone.io/learn/splade/
3. https://weaviate.io/blog/hybrid-search-explained
4. SPLADE v2: Sparse Lexical and Expansion Model for Information Retrieval, https://arxiv.org/abs/2109.10086, 2021