DataLeap Catalog系统搜索实践(三):Learning to rank与后续工作

技术大讲堂

Learning to rank

picture.image

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系统的搜索功能还有很多有意义的工作值得我们继续探索,例如:

  • 血缘中的搜索。当一个资产的一级下游就超过上千个时,想从当前资产的众多下游中查找到相关的资产并不容易,因此提供基于血缘的筛选和搜索是一个不错的选择。
  • 多租户之间模型的迁移。作为支持多租户的公有云服务,由于租户之间数据的差异,新租户的冷启动问题,以较小的数据量和成本来支持不同租户都有好的搜索体验,也是一个值得挑战的方向。
316
0
0
0
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论