小红书搜索：生成式检索的探索与实践-51CTO.COM

一、研究团队

目前团队有四名成员，主要研究方向包括大模型评测推理及生成式检索，目前在进行技术攻关以实现大模型在搜索系统各环节的落地应用。

二、检索范式

目前常见的检索范式包括：

稀疏检索，如 TF-IDF、BM25，以及一些扩展的混合检索；
密集检索，常见模型有 DSSM，还有一些变体，如难负样本挖掘、后交互、知识蒸馏，以及 loss 上的一些工作（对比学习）。
生成式检索，常见的有三种，一种是对现有检索系统各个模块进行优化，比如在 QP 环节对查询进行改写，对最终结果进行摘要，这在商品搜索、小红书、抖音、快手等平台都能看到，即 one box 查完后上文的摘要；第二种是今天要介绍的主题 GDR，根据 query 直接生成笔记 ID 或文档 ID，要求对检索系统的召回环节进行较大改动；第三种是理想态，如 ChatGPT，直接生成结果的 context。从使用角度看，对于某一类问题，用户可能希望有直接生成的结果，但对于像小红书、抖音、快手等内容平台，用户不仅希望看到搜索结果的摘要，还希望看到其他用户在平台上关于查询内容的分享，所以这几种检索类型都有必要。

三、GDR：记忆机制的双刃剑效应

接下来介绍我们发表在 EACL 2024 Oral 的一个工作：

主要探索生成式检索的关键问题——记忆机制。文章中分析了记忆机制的几个问题，并与密集检索进行了重要差异对比。针对生成式检索的问题，提出了一些解决方案。

简要回顾密集检索，其本质是利用语义向量匹配机制，在各个业务场景广泛应用。其优点是具有较低的时延、可接受的在线计算开销，并且比较灵活，当文档库发生动态更新时，可以快速高效地更新索引。采用双塔模型，无论是 query 侧还是笔记侧，都可以输入丰富的信息，有助于模型捕捉细粒度特征。上图中可以看到，双塔一侧是 query 的语义向量编码，另一侧是 doc 的语义向量编码，在向量空间做距离计算，进行优化。

其不足之处是双塔模型无法进行深度交互，都是得到向量后，语义向量在欧氏空间进行计算。我们知道深交互有助于特征交叉，提升模型性能。但在检索环节，由于对计算时间和开销的要求，一般不会进行深度交互。另外一个缺点是，查询和文档之间具有一对多的特性，候选文档的语义关联可能较远，而查询想召回的所有候选文档则要求它们在语义空间接近，产生了矛盾。

再来看一下生成式检索。给定一个 query，生成式检索的编码端首先得到一个向量，然后将这个向量给到文档解码器，用 Beam Search 解码策略逐步得到每篇笔记的 ID。这意味着笔记需要通过 ID 进行表示，可以是单值或一串序列的值。预测过程是给 query 直接生成笔记 ID，而不是先得到 query 的向量，在欧氏空间和笔记向量进行计算找到最相似的向量。其本质是利用记忆机制，因为 query 进去后，笔记没有拿出向量，所以要求模型根据 query 记住相关笔记的 ID 序列。

在较小规模的候选文档场景下，生成式检索展现出了优于密集检索的召回性能。具体优点包括：模型以参数作为记忆载体，记住所有候选文档，在解码过程中隐式实现了候选文档和查询的深度交互，这是密集检索的主要缺点；另外，文档被赋予了独立的 ID，避免了密集检索存在的 one to many 情况；如果将 query 的编码器换成大语言模型，能有效利用预训练语言模型的语义理解能力。

但生成式检索也存在不足，接下来从三个方面来详细介绍。

首先，对候选文档的细粒度特征有效记忆不足。生成式检索的训练流程是先对文档进行表示，通过聚类得到层级树状图，每篇笔记通过一条 path 表示。然后对 query 进行处理，为每篇笔记生成一堆 query 来表示笔记，将真实 query 和生成 query 集合作为输入，生成对应的笔记 ID。但目前构建 query 的方式不能很好地充分拿到所有笔记信息和进行从细粒度到 high level的表示学习，导致候选文档不能很好地记住细粒度特征。

我们做了一个实验，对比基线是常见的密集检索模型和生成式模型 NCI。对文档获取语义向量后聚类，得到层次化 ID，分别用 AR2 和 NCI 模型召回笔记，在测试集上统计错误率。发现生成式检索模型在前面几位错误率较低，但越往后错误率升得特别快，验证了对细粒度特征有效记忆不足的问题。

其次，当候选文档规模增大时，性能会显著下降。原因是模型参数有限，记忆容量有限，当候选文档容量超过模型记忆容量时，记忆出现瓶颈，性能下降明显。我们做了一个实践，构建不同规模的候选文档集合训练 NCI 模型，测试在不同候选文档下的表现，发现候选文档增多时，生成式模型的召回率下降明显。

第三，候选文档更新时可扩展性差。对于密集检索，新文档加入后可以快速更新向量加入索引。但对于生成式检索，文档变了需要生成新的 query 加入模型训练，容易出现灾难性遗忘问题。如果不训练直接应用，可能会出现预测不准确的问题。我们做了一个验证实验，将数据集均分为两份，先用一份子集训练 NCI 模型，然后更新候选集不重新训练模型，测试在不同查询集上的表现，发现候选集扩充后召回率下降。

总结一下生成式检索和密集检索的优缺点。生成式检索的本质是记忆机制，是序列化生成笔记 ID，自回归解码范式导致时间和计算开销大，当候选文档多时代码层数变多，对细粒度特征记忆不足，候选文档库变化时需要重新训练模型。但优点是在解码过程中实现了查询和候选文档的深交互，文档有独立 ID 且能利用大模型的理解能力。密集检索本质是向量匹配机制，优点是较低的时延、可接受的计算开销，能捕捉细粒度特征，文档库动态变化时可高效更新索引。但缺乏深交互，存在一对多的问题。

经过分析得出结论，两者可以很好地互相补充。

我们可以利用生成式检索的记忆能力记住 high level 的语义类 ID，到细粒度的地方用密集检索做匹配。具体而言，记忆机制主要用来记忆候选文档簇，一旦选到簇这个粒度之后，就会使用匹配机制，在更少的候选文档集合-簇里面做细粒度的匹配。

给定 query，编码器先编码出向量，进入解码阶段，首先对笔记进行向量表示和聚类，解码层级树的前面部分 high level 的 ID，得到候选文档簇的概率。在粗粒度生成后，在相关的叶子节点内进行细粒度的匹配，使用损失函数得到综合分数得到最终结果。

文档簇 ID 层级结构的构建至关重要。传统检索表示到 doc ID 维度会有问题，一是文档数量增加时模型参数量也要增加，否则召回性能下降；二是目前文档表示不一定有助于构建层级文档簇 ID。我们做了分析，如上图中的公式，先用 Bert 对文档进行向量表示得到一个树，再以我们的方式，用双塔模型进行密集检索训练，用文档的 encoder 生成向量，构建一个树，这样得到两个树。在两个树里，分别对正确文档的 ID 计算出最大公共子序列，最前面的最大公共子序列应尽量一致，越一致，模型记忆的负荷越小。因此我们希望构建易于记忆的文档簇，减少模型记忆负荷。