火山引擎 DataLeap 的 Catalog 系统搜索实践（三）：Learning to rank 与后续工作

Learning to rank

Learning to rank 主要分为数据收集，离线训练和在线预测三个部分。搜索系统是一个 Data-driven system，因此火山引擎 DataLeap 的 Catalog 系统设计之初就需要考虑数据收集。收集的数据可以用来评估和提升搜索的效果。数据收集和在线预测前面已有介绍，不再赘述，下面主要介绍离线训练部分。

离线训练的过程主要包括数据标注，特征工程，模型训练和评估。这四个步骤并非从前往后一气呵成，而是有可能进行评估，发现不足，然后增加标注数据，增加特征，重新训练，再次评估。评估效果有比较明显的收益时，才会上线测试。

数据标注

作为 Data Catalog 的搜索系统，不太容易获取大规模的人工标注数据，主要有两个原因：一是标注的成本较高，二是领域知识的专业性导致不容易找到合适的标注人员。因此，火山引擎 DataLeap 的 Catalog 系统标注数据来源主要有两个：一是来自搜索日志中有点击的部分，火山引擎 DataLeap 的研发人员将这部分数据划分为三档，曝光有点击，曝光排名前五且未点击和曝光未点击，赋予不同的分数；二是火山引擎 DataLeap 的研发人员根据资产名称结合日志中未点击的输入，基于规则生成一定的训练数据。

训练数据集需要持续更新，在 review badcase 时，可以针对需要改进的场景添加相应的训练数据。

特征

特征工程是一个持续的过程。经过一系列的选取，火山引擎 DataLeap 的 Catalog 系统的主要特征分为 4 大类型，涵盖了搜索的文本特征，数据的权威性，用户的个性化数据和数据的时效性。

下面列举了一些用到的主要特征和分类：

• 文本特征

  输入相关的文本特征

  输入长度，比如有多少个词，总长度等等

  输入语言类型，中文或英文

  文本匹配度相关的特征

  基于词袋的 CQR

  Elasticsearch 查询返回分数，基于 BM25

• 数据权威性

  热度：AssetRank, 基于资产的使用量和血缘关系，通过 Weighted PageRank 算法计算得到的资产热度

  元数据完整度，包含资产的业务元数据，如项目，主题，产品线等

  资产的最近 1 天/7 天/30 天的全平台使用总次数

  资产所处的生命周期：如上线，待下线，废弃等

  资产的总点赞数

• 用户个性化数据，分为三大类

  静态个性化数据

  负责人：当前用户是否是该资产的负责人

  收藏：当前用户是否收藏了该资产

  点赞：当前用户是否点赞了该资产

  历史搜索查询行为数据

  当前用户历史上最近 1 天/7 天/30 天全平台使用该资产的次数

  当前用户历史上最近 1 天/7 天/30 天在 Data Catalog 平台查询点击该资产的次数

  协同数据

  同部门人员历史上最近 1 天/7 天/30 天在 Data Catalog 平台查询点击该资产的次数

  当前用户历史上最近 1 天/7 天/30 天在 Data Catalog 平台查询点击该资产所属部门所有资产的次数

  当前用户历史上最近 1 天/7 天/30 天在 Data Catalog 平台查询点击该资产所属负责人所有资产的次数

• 数据时效性，用户会更倾向于使用最近创建或者有数据更新的资产

  资产创建时间

  资产数据的最近更新时间等

模型

Learning to rank 通常有三类方法：Pointwise，Pairwise 和 Listwise。这三类方法各有优缺点，细节介绍如下：

• Pointwise，对每个输入，对每个召回的资产单独打分（通常是 Regression），然后按照分数进行排序。

  优点：简单直观。

  缺点：排序实际上不需要对资产进行精确打分，这类方法没有考虑召回资产之间的互相关系，考虑到用户在一组资产中只会点击其中一个，排名靠后的和排名靠前的资产在损失函数上的贡献没有体现。

• Pairwise，对每个输入，考虑召回结果中所有资产的二元组合<资产 1, 资产 2>, 采取分类模型，预测两个资产的相对排序关系。

  优点：基于点击与原有相关性分数排序标注简单，相比 pointwise 考虑到选项之间关系。

  缺点：同样没有考虑排序前后顺序的重要性不同，样本生成复杂，开销大。对异常标注敏感，错误点影响范围大。

• Listwise，考虑给定输入下的召回资产集合的整体序列，优化整个序列，通常使用 NDCG 作为优化目标。

  优点：优化整个序列，考虑序列内资产之间的关系。

  缺点：单条样本训练量大。样本过少，则无法对所有样本预测得到好的效果。

火山引擎 DataLeap 研发人员对 Pointwise 和 Listwise 都做了实验，最终火山引擎 DataLeap 的 Catalog 系统采用了 Listwise 的方案。主要原因是在我们的标注方式下，Listwise 的方案更容易标注。具体实现上是采用了 LightGBM 的框架。

评估

火山引擎 DataLeap 研发人员使用了 NDCG，AUC 和验证点击率的方式对模型进行评估。

• NDCG，归一化折损累计增益。NDCG 是推荐和搜索中比较常用的评估方法，用来整体评估排序结果的准确性。

• AUC，AUC 主要反映排序能力的相对性，用于在正负样本不均衡的情况衡量离线模型拟合情况。

• 重放有点击历史数据的点击率，使用待评估的模型预测有点击的历史输入，排序后得到 Top3, Top5, Top10 点击率作为参考。这种方式比较直观，缺点是不能反映出在无点击历史数据上的效果。

衡量指标

搜索服务变更或新模型上线后，火山引擎 DataLeap 研发人员需要对线上搜索的真实效果进行衡量。目前火山引擎 DataLeap 研发人员主要通过搜索的点击率和 Top3 点击率来衡量。由于 Data Catalog 搜索的特殊性，火山引擎 DataLeap 研发人员更看重模糊搜索的总体点击率和 Top3 点击率（输入和资产名称完全一致的为精确搜索，其它为模糊搜索）。

实际上，点击率并非越高越好，过高的点击率可能意味着:

• 搜索结果页透出的信息过少，用户不得不点击结果进入资产详情，即使只想查看一些简单的信息。

• 用户在系统上探索的兴趣较小，只搜熟悉的资产或者确定能搜到的输入。

当然过低的点击率意味着较差的搜索体验。因此，点击率保持在一定健康的区间后，火山引擎 DataLeap 研发人员也需要关注模糊搜索和精确搜索的占比等指标。

其它模式

除了个性化的搜索需求，也会有一些场景，用户不需要精细化的排序，只需要把包含相关文本的资产都列举出来，因此我们也支持单纯的列表模式，用户可以在列表模式通过指定字段来对搜索结果进行排序。我们也在规划实现一些 query syntax 的功能，以此来支持用户在列表模式下更灵活地约束输入。

后续工作

火山引擎 DataLeap Catalog 系统的搜索功能还有很多有意义的工作值得我们继续探索，例如：

• 血缘中的搜索。当一个资产的一级下游就超过上千个时，想从当前资产的众多下游中查找到相关的资产并不容易，因此提供基于血缘的筛选和搜索是一个不错的选择。

• 多租户之间模型的迁移。作为支持多租户的公有云服务，由于租户之间数据的差异，新租户的冷启动问题，以较小的数据量和成本来支持不同租户都有好的搜索体验，也是一个值得挑战的方向。