严选算法模型质量保障

原创严选技术严选技术产品团队

在算法模型整个生命周期（算法模型生命周期：初始训练数据 --> 模型训练 --> 模型评估 --> 模型预估 --> 训练数据）中，任何环节的问题引入都可能导致算法模型质量问题。所以我们在做模型质量保障的过程中，需要关注各个阶段的质量。

1. 背景

目前算法模型已经被广泛应用于严选各个方面，可以说算法无处不在：

在C端为严选APP提供搜索、推荐能力；
在智能触达营销系统中提供个性化营销能力；
在外部广告实时竞价交易平台中提供智能竞价能力；
在B端为供应链提供预估商品补货量能力；
……

随着业务的不断发展，算法模型质量保障的完善也日趋紧急。算法模型质量保障在严选的起步相对较晚，最近两年才开始起步，本文将对严选当前的模型质量保障体系做一下简单的总结，谈一谈模型质量保障的手段以及严选优先落地的保障手段。

算法在严选的应用核心主要可以分为三大块：召回、排序、重排。

召回层首先通过算法模型从多个目标候选集中召回资源（如商品、榜单、活动、话题等）；
排序层的模型主要是精排的深度学习模型，按照预估的点击率、加购率、转化率等进行排序；
重排层主要是重排算法和策略，包括流量决策算法、多样性重排算法等。

最后将个性化的结果展示给用户，然后用户是否点击、加购、购买等行为再进行埋点落数仓，提取出训练样本，用来更新模型，如此形成一个良性的闭环系统。

我们对算法模型系统生命周期进行了抽象，以此来探索算法全方位质量保障，算法模型生命周期大概经过以下流程：初始训练数据 -> 模型训练（生成模型） -> 模型评估（测试模型） -> 模型预估（使用模型） -> 模型应用（反馈模型），最终形成闭环。

模型训练过程是通过训练样本和答案得出算法模型的过程；
模型评估是通过评估样本和刚训练完成的模型得出新答案的过程，因为评估样本是已知答案的，所以可以通过对比新答案和参考答案，来评估模型效果；
模型预估是通过预估样本和模型得出答案的过程，在商品推荐场景中预估样本可以理解为用户+商品，而我们预估的就是用户对商品的点击或者购买概率，只是是否点击、购买发生在未来；
模型应用是反馈模型生成新的训练样本的过程，在商品推荐场景中就是将推荐商品展现给用户，然后获取用户真实的点击、购买等行为数据。

在算法模型生命周期中，任何环节的问题引入都会导致算法质量问题。

我们也分析了一下算法测试相比其他服务端测试的难点：

首先，其他服务端的行为基于不同的输入预先确定，而算法的测试输入为特征（比如用户特征是实时更新的），测试输出是预估值存在不确定性，可解释性方面由于深度学习模型的神经网络不可解，所以可解释性差，在结果验证方面无法确认输入对应输出的逻辑是否准确；
测试周期方面，由于模型版本会自更新，随时间变化模型预估效果可能会出现偏差，所以我们无法在模型上线后就确定测试完成不会发生模型类问题，需要持续关注；
测试关注点上，不仅要关注模型质量，还要关注特征质量、数据质量；
除此之外，相对于其他服务端测试，模型问题抽象度高，难分析定位。

下面通过算法模型生命周期，进行模型问题分析。

2. 模型问题分析

我们对算法模型系统抽象出来了一个闭环，讲到任何环节的问题引入都会导致算法模型质量问题。所以接来下我们会从算法模型闭环出发，以算法问题视角讲述算法会出现的典型问题，引出算法的全方位质量保障手段。

我们从模型应用阶段开始分析，模型应用是模型预估后反馈模型的一个过程，比如严选推荐场景中推荐的商品曝光给用户，用户会产生点击、收藏、加购、购买等一系列行为，这些数据是建立机器学习的第一步，而这个阶段容易出现数据质量问题。
在模型应用到模型训练的过程中，算法工程师会根据原始数据经过一系列拼接、计算等得到训练用的特征，而这个过程中容易出现特征质量问题（也可以归为数据质量问题）。
在模型训练阶段，容易出现欠拟合、过拟合等一系列问题，但是这些问题是算法工程师需要关注的，QA可以不过多关注。
在模型评估阶段，容易出现验证集和训练集划分不均等问题导致模型评估失真，但是这些问题同样是算法工程师需要关注的。
在模型训练到模型预估的过程中，容易出现模型延时问题，严选目前对模型实效性要求不高，但是后续也会升级到小时级更新，延时问题会更突出。
在模型预估阶段，容易出现策略机制一致性问题（模型实际效果不符合调研预期）、数据质量问题（样本数据问题、特征计算问题）、功能、性能问题等。

首先根据问题症状的明显度，我们先把问题进行了大致分类，偏急性的问题，问题症状严重，表现明显，这类问题则需要拦截；偏慢性的问题，初始症状不明显，但是积累渐变，这类问题则需要召回。分析整个算法模型闭环，我们把问题分成5大类：

第一类是主要针对搜索推荐等容易出现的Badcase；
第二类是策略机制一致性问题，出现在模型预估阶段；
第三类是模型延时问题，出现在模型评估到模型预估的过程中；
第四类是数据质量问题，出现在模型预估阶段或者模型预估到模型训练的过程中；
第五类是功能、性能问题，出现在模型预估阶段。

其中两类是急性问题，两类是慢性问题，还有一类比较特殊，他就是Badcase。Badcase更准确来讲应该是一种结果而出现这种结果的原因可能包含其他四种问题，所以Badcase挖掘可以理解为把整个算法系统当作黑盒来测试。

分析这些问题可以发现，最终导致的结果可以分为三种：

第一种是Badcase；
第二种是算法模型效果问题，包括策略机制一致性问题，模型延时问题，数据质量问题、性能问题等都会影响最终的模型效果；
第三种是功能策略问题。

因此也引出算法模型质量问题保障的重点：Badcase挖掘、算法模型效果问题发现、功能策略问题发现。

算法模型效果的质量保障是模型质量保障的重点和难点，影响模型效果的因素多样，导致模型问题抽象度高，难分析定位。考虑到优先级和投入产出比，算法模型效果质量保障是一个由浅入深的过程，或者说是一个从问题可知、可测到问题可控的过程。

所以前期我们对算法模型效果质量的保障的目标是做到问题可知，因为模型离线评估是算法同学完成的，如果评估指标下降会拦截模型作用到线上，所以我们可以通过模型先验和后验效果一致性来发现实际效果问题，然后在此基础上关注了性能问题对实际效果的影响。对于数据质量问题、策略机制一致性问题、模型延时问题等是后续需要进一步深入完善的。另外，在模型上线效能上我们通过pipeline上线自动化验证实现了进一步提升。

3. 模型质量保障重点

3.1 Badcase挖掘

因为算法模型原因，线上搜索、推荐可能存在较明显Badcase，比如检索词和搜索结果不相符，推荐结果出现不应该出现的商品，推荐等。这些Badcase对用户体验伤害很大，甚至会影响转化、收入。

那我们要做的就是在线下尽可能拦截这类问题，在线上尽早召回问题。因此问题分析可以概括为两点：

从模型评估到模型预估的过程中，缺少高效率、高覆盖的算法模型Badcase线下验证、拦截能力；
在模型预估过程中，缺少有效的算法模型Badcase线上召回能力。

对此我们平台化打造了Badcase挖掘能力，作为模型升级、新模型上线前质量保障的重要环节，实现模型可能引起的Badcase线下可拦截；通过属性条件筛选用户，以及自动挖掘，实现测试用户高覆盖、高效率。在这之前我们线下挖掘Badcase只能看自己账号测试APP，覆盖低；或者构造用户手动请求接口获取搜索推荐商品ID，然后再把ID通过小工具可视化，效率低。

Badcase挖掘平台化主要经历了两个阶段：

阶段一是人工挖掘，通过平台人工查看模型作用下给用户推荐的商品，或者用户搜索到的商品，分析为该用户推荐某商品，或者搜索到某商品的原因，从而确认模型效果。但是，人工评测的模式强依赖测试人员经验积累，门槛高，且每次只能评测单个用户的推荐、搜索商品，效率较低、用户覆盖面有限，因此需要寻求低门槛、更高效、高覆盖的模型线下效果验证能力。
阶段二是自动挖掘，通过平台选择批量的用户生成批量的测试结果，自动计算模型评测指标，自动筛选出Badcase风险等级高的结果，最后再人工确认高风险结果，通过这样的方式提高测试用户覆盖，提高测试效率。

3.2 模型效果质量

问题分析中讲到算法模型效果质量的保障这块我们优先实现了问题可知，我们第一步建立了模型后验效果监控，实现了模型效果问题T+1可知。在此基础上，我们建立了精细化的性能监控，对性能问题实时可知。后续我们还会进一步深入保障数据质量，模型延时等方面。

3.2.1 模型后验效果

模型效果的评估指标有很多，我们需要做的是根据不同场景和业务，选择合适的指标，这样通过观察评估指标就能判断模型实际效果，从而协助模型升级和迭代。

一般模型主要包括分类、回归、聚类模型，我们首先分析下这些模型通用的模型效果评估指标：

分类模型通用评估指标包括查准率、查全率、正确率、F1分数、AUC/GAUC、KS值、PSI值等；
回归模型通用评估指标包括平均绝对值误差、均方误差、均方根误差、均值平方对数误差、中位数绝对值误差、决定系数等；
聚类模型通用评估指标包括纯度、F1分数等。

虽然搜索、推荐、广告等通常使用回归模型，但是它们的衡量标准其实是是否点击、是否转化，是一种分类问题，所以使用分类模型评估指标更加合理。另一方面，我们发现模型离线评估其实通常是由算法同学完成的，只有通过离线评估的模型才会作用到线上，所以我们在评估模型实际效果的时候不应该盲目去评估所有的指标，而应该以离线评估指标为基准。

以严选为例，搜索、推荐、广告等模型的离线评估使用点击、加购或者转化的AUC/GAUC，所以在线模型评估需要关注的指标也是点击、加购或者转化的AUC/GAUC，在此基础上完善其他指标可以辅助多维度分析模型效果。

理想情况下某个用户对某个商品的兴趣分通过模型预估流和模型评估流结果是一样的，因此我们可以通过先验和后验效果一致性来发现这种问题。那什么是先验效果和后验效果？

所谓先验效果就是模型评估效果（发生在模型生效前），而后验是指非实时的，需要通过应用反馈的曝光、点击、转化数据来计算线上实际的效果指标。

如图是模型预估和模型评估两条流的逻辑抽象：

先验、后验效果一致性的原理图

在模型评估阶段，我们通过对已知答案的评估样本计算特征，使用模型再排序的方式，观察是否把转化的样本尽量排在前面来评估模型效果（先验效果），如果模型的目标是点击或者转化，那么先验效果可以通过点击AUC/GAUC或者转化AUC/GAUC来衡量。
在模型预估阶段，我们类似的对预估样本计算特征，使用模型计算预估值的方式进行排序，未来用户会产生真实的点击、购买行为，这样就可以计算模型实际效果（后验效果），同样的，后验效果指标可以去对齐先验效果指标。

但是很多时候模型评估和预估阶段，采用了不同的评价体系，在线只是通过实验方式对比新老模型点击、转化、UV价值等业务效果指标，包括我们也有这样的情况，这样做的问题在于不知道线上点击率、转化率达到多少或者提升多少才算达到预期，所以对模型效果问题的判断其实是不够的。

3.2.2 性能监控

性能问题和大多数工程服务问题存在着共通性，想必大家都是比较了解的。比如活动期间流量往往会成倍上升，算法服务如果存在性能问题会导致大量超时：

如果是召回阶段的大量超时，则会导致召回商品没有用户相关性关联而效果差，影响转化、收入，甚至开天窗的可能；
如果是精排模型或者重排算法的大量超时，则会导致线上没有算法加成效果大打折扣，影响转化、收入。

对此，我们监控了所有场景下各链路召回耗时、精排耗时、重排耗时，召回超时量/率、精排超时量/率、重排耗时量/率，以及前处理耗时、后处理耗时、pipeline耗时、总耗时等，及时召回所有场景各个阶段的超时问题并处理。

3.3 pipeline上线自动化验证

严选为了适应不同场景下的搜索、推荐，召回、排序、重排使用的模型、算法、策略都是以算子的概念任意配置组装的，因为配置是人工操作的，所以策略、算法作用到模型预估阶段容易出现因为配置错误导致的策略、算法问题，甚至模型未生效等情况，影响模型效果质量。因为模型后验效果是T+1问题可知的，问题可知滞后，所以这个阶段基本的验证是有必要的，可以有效拦截大部分策略、算法问题作用到线上。我们已经将自动化验证结果作为pipeline上线的卡点，只有验证通过的pipeline才能上线。

在上线前这个阶段，我们可以做策略、算法有效性的校验，以及Badcase挖掘等。在有效性校验中，验证多通道召回的召回类型、算法得分，排序前后位置变化、排序模型得分，重排前后位置变化等。在Badcase挖掘中，根据不同场景配置不同的自动挖掘指标。

在自动化验证前，pipeline上线没有严格的卡点，依赖算法同学自己验证导致线上问题频现。另外验证需要一系列的操作：配置pipeline -> 配置实验 -> 手动用例请求 -> 手动验证 -> 上线，耗时1小时以上。接入pipeline自动化验证后只需要操作：配置pipeline -> 自动化验证 ->上线，整个过程的操作下降到分钟级别，其中自动化验证耗时2分钟以内。通过这样的方式，大大提升了pipeline上线效率。

4. 模型质量平台

基于模型质量保障重点中的保障点，我们通过平台化的方式落地了其中的测试、监控能力。下面会介绍平台的设计、展示等。

4.1 模型质量平台设计

4.1.1 平台架构设计

目前我们将Badcase挖掘、模型效果质量、pipeline上线自动化验证卡点等能力都综合到了算法模型质量平台。

模型评估指的是在线模型评估，对原始数据进行处理生成曝光转化、曝光加购、曝光点击等数据，再进行评估指标计算分析，将分析结果保存在MySQL中，最后通过平台实现灵活配置、可视化，监控报警。目前平台内的评估指标包括各个场景下不同模型目标、算子类型、模型版本、坑位等的AUC、GAUC、CTR、PCTR、CVR、PCVR、PCOC等。

模型评测模块提供Badcase挖掘功能，包括手动挖掘和自动挖掘，通过获取真实用户推荐结果或搜索结果，再进行计算分析，并将分析结果保存在MySQL中。详见模型评测篇
模型验证模块为pipeline上线提供自动化验证的能力，综合pipeline有效性自动验证结果和Badcase自动挖掘结果。pipeline有效性验证为其中各个算子的有效性验证，Badcase挖掘包括重合度、打散度、覆盖度等。该模块根据平台配置的各个场景下验证项和阈值，触发一键验证后，通过计算中心计算结果判断是否可以上线。