深圳电商公司排行榜,兰州网络优化seo,php做二手商城网站源码,网站建设数据库在算法模型整个生命周期**#xff08;算法模型生命周期#xff1a;初始训练数据 -- 模型训练 -- 模型评估 -- 模型预估 -- 训练数据#xff09;**中#xff0c;任何环节的问题引入都可能导致算法模型质量问题。所以我们在做模型质量保障的过程中#xff0…
在算法模型整个生命周期**算法模型生命周期初始训练数据 -- 模型训练 -- 模型评估 -- 模型预估 -- 训练数据**中任何环节的问题引入都可能导致算法模型质量问题。所以我们在做模型质量保障的过程中需要关注各个阶段的质量。
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 模型效果质量
问题分析中讲到算法模型效果质量的保障这块我们优先实现了问题可知我们第一步建立了模型后验效果监控实现了模型效果问题T1可知。在此基础上我们建立了精细化的性能监控对性能问题实时可知。后续我们还会进一步深入保障数据质量模型延时等方面。
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上线自动化验证
严选为了适应不同场景下的搜索、推荐召回、排序、重排使用的模型、算法、策略都是以算子的概念任意配置组装的因为配置是人工操作的所以策略、算法作用到模型预估阶段容易出现因为配置错误导致的策略、算法问题甚至模型未生效等情况影响模型效果质量。因为模型后验效果是T1问题可知的问题可知滞后所以这个阶段基本的验证是有必要的可以有效拦截大部分策略、算法问题作用到线上。我们已经将自动化验证结果作为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挖掘包括重合度、打散度、覆盖度等。该模块根据平台配置的各个场景下验证项和阈值触发一键验证后通过计算中心计算结果判断是否可以上线。 4.2 模型质量平台展示
4.2.1 Badcase挖掘
进入“自动挖掘”界面 - 根据筛选条件查询用户 - 批量选择测试的用户 - 选择想要测试的接口模型 - 生成批量请求数据 - 编辑、确认请求数据 - 发送请求开始Badcase挖掘。 挖掘报告界面
上部为所有测试用户评测指标的均值可以反映模型表现在各评测指标的整体趋势。
下部为所有单测试用户评测指标可以快速筛选出Badcase风险等级较高的测试用户。 查看详情可以进一步人工确认是否为Badcase然后进行反馈 4.2.2 模型后验效果
模型后验效果的计算依赖客户端埋点数据经过拼接、计算后可以得到曝光点击、曝光转化等数据。 然后通过计算得到模型评估指标。目前我们对指标进行了精细化模型目标包括点击、加购、转化算子类型包括召回、精排、重排编排版本包括线上生效的所有版本坑位包括全坑位以及靠前的多个坑位另外还区分了新老用户。通过这样的方式多维度分析模型实际效果。
在指标上我们优先落地了AUC、GAUC、PCOC、CTR、PCTR、CVR、PCVR等。 最后根据平台配置对异常点及时报警。
4.2.3 pipeline上线自动化验证
联合算法一体化平台在预发布阶段一键触发自动化验证只有验证通过才能上线。 然后可以进一步查看测试报告详情定位问题。 4.3 模型质量平台总结
模型质量平台经过一年多时间的打磨演进经历了多个阶段。Badcase挖掘从一开始人工挖掘到自动挖掘再到成为自动化验证项模型后验效果从脚本工具阶段到平台化模型上线流从手动验证到一键自动化验证。实现了严选算法模型质量保障很多方面的从无到有降低了模型质量保障的技术门槛同时提高了效率。
5. 展望
模型质量平台目前已经实现了自动化、工具化、服务化、可视化等能力。未来我们期望可以实现模型训练、模型评估、模型预估、模型应用等阶段的全流程质量保障闭环
首先从算法模型质量保障的深度上来说还有待进一步深入到特征质量、 数据质量。其次从实效性方面考虑目前的模型后验效果是T1问题可知当天问题无法召回需要进一步提升实效性。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
