乐趣区

关于数据挖掘:火山引擎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 零碎的搜寻性能还有很多有意义的工作值得咱们持续摸索,例如:
  • 血统中的搜寻。当一个资产的一级上游就超过上千个时,想从以后资产的泛滥上游中查找到相干的资产并不容易,因而提供基于血统的筛选和搜寻是一个不错的抉择。
  • 多租户之间模型的迁徙。作为反对多租户的私有云服务,因为租户之间数据的差别,新租户的冷启动问题,以较小的数据量和老本来反对不同租户都有好的搜寻体验,也是一个值得挑战的方向。
退出移动版