共计 2805 个字符，预计需要花费 8 分钟才能阅读完成。
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 零碎的搜寻性能还有很多有意义的工作值得咱们持续摸索，例如： - 血统中的搜寻。当一个资产的一级上游就超过上千个时，想从以后资产的泛滥上游中查找到相干的资产并不容易，因而提供基于血统的筛选和搜寻是一个不错的抉择。
- 多租户之间模型的迁徙。作为反对多租户的私有云服务，因为租户之间数据的差别，新租户的冷启动问题，以较小的数据量和老本来反对不同租户都有好的搜寻体验，也是一个值得挑战的方向。
