阿里QA导读:蚂蚁搜推营广业务在算法技术领域持续精进,以质量视角出发,在常规质量保障体系之上外,如何深入评价和保障算法业务效果成为新的研究方向。本文主要介绍了如何通过建设三种评测能力,进行算法业务效果保障。
要建设算法业务的效果验收能力,我们核心要解决2个问题:
要衡量算法策略的效果,那么验证方法本身的置信度如何保障?
业务对验证效率要求高,如何设计一套极致效率的系统化平台能力去支撑?
解法:
针对于问题1:
拦截数据类算法业务效果问题:
从业务视角出发,结合算法策略生效特点(具备很强的统计学规律) 以及算法链路数据构造的高复杂度,通过对业务系统生产环境发起端到端的大数据请求,并通过统计指标来评估算法的业务效果是否符合业务预期。对线上环境发起请求,最大程度提升了结果评估的置信度,仿真度极大提升;同时将大数据仿真评估环节前置到AB实验切流之前,可以拦截一些明显不符合要求的算法AB实验发布上线,解决了背景中提到的在线AB实验可能会有损的问题;
拦截体验类算法业务效果问题:
跟集团的亲测,蚂蚁的AlphaQ等专业的标注平台不同,我们通过把服务端的数据在端内实现1:1的真实产品还原+辅助决策信息(用户画像/特征/行为数据等)+标注问卷的方式形成了独有的蚂蚁搜推产品级人工评测能力,可以在新产品对外发布,通过模拟不同城市不同用户的算法结果提早发现产品体验类问题;
通过竞品评测对竞品评估分析发现体验类问题取长补短,为超越竞品提供数据支撑。
针对于问题2:
当前我们使用离线评估(大数据仿真评测和人工评测)和竞品评测的算法业务效果验收能力,在前期的样本准备,评估后的指标分析和报告产出阶段重点突破,做到极致效率,接下来的内容会重点介绍我们的技术思考。
因此我们基于以上思考我们建立了一套端到端的算法业务效果评估能力:
从研发流程上来看,大数据仿真评测和人工评测的评估能力属于离线评估阶段的评估能力,旨在减少对生产环境上用户的使用体验影响。
如何建设一套高效、安全、仿真度高的算法业务效果验收,我们面临如下问题:
单薄的数据输入,case by case对于整体的算法评估不足。
如何将算法业务效果验收提前至ab实验前,且能得到与ab实验接近的评估效果?
没有确定的输出结果。传统的软件测试,有确定的预期输出,使效果测试基本空缺。
代码工程测试将实际输出进行对比,就能知道工程代码是否能够通过。但算法模型没有固定的输出结果,也没有绝对的好,需要使用各种指标进行评价。
......
虽然算法模型产出的结果是无法穷举的,但其在业务调用上却是有着明确预期的。比如,支付宝红包码分人群定价,算法根据不同人群分成不同档位,算法的打分区间和档位的分布比例是有明确预期的。那么从算法业务效果的角度我们可以通过一套指标体系去评价算法效果是否符合预期。本质上和工程用例是相同的解法思路。算法效果没有绝对的对与错,只有相对的好与不好。那么,我们采用评估的方式建立起一套置信度较高的评价体系,从样本、特征、模型、业务和工程等维度去评价算法的好与不好,将会是一个不错的解法。
根据以上问题分析和痛点,我们需要解决的关键点有以下几个:
大而全的样本覆盖
解决方案:样本流量准备。通过SLS定时清洗业务T+1线上请求,满足回放的数据要求;目前样本类型包含离线ODPS表、实时SLS流式样本等;
真实的还原数据表现
解决方案:大数据仿真评测引擎核心。按照业务需求对样本流量分层,将流量发送到业务算法平台,获取业务平台返回的仿真结果;为了还原真实数据表现,所以我们在模型上线开流之前进行数据评估。
所以,我们需要一套回放线上用户真实请求的机制,来帮助我们收集从业务系统到底层算法系统的全链路数据。首先,在进行大数据仿真评测前须根据每个业务场景的需要准备好回放的样本流量。然后,需要建设一套工程系统,将准备好的流量按需发送给待仿真的业务算法平台。最后,收集整个回放链路中产出的日志,结合样本表进行指标加工。最终,产出评估所需的指标集。概要流程如下:
从技术架构上需要解决2个仿真度问题和1个执行效率的问题。
第一个仿真度问题是样本的仿真度:为了确保模拟的请求足够真实,我们采集了各业务场景每天的线上真实的请求数据,定时更新存储到离线样本中心。
第二个仿真度问题是执行环境的仿真度:支付宝的算法特点是,除了算法之外,还有非常重的规则和策略。所以我们直接对算法业务系统进行仿真,评估最终返回给用户的结果。由于线下缺乏真实用户数据,我们采用线上环境进行回放。这里就涉及到仿真流量如何隔离。我们在sofa上下文增加了仿真标记,业务系统识别标记进行存储和日志隔离,并设计了限流和一键熔断的安全措施。
关于大数据仿真评测的执行效率问题,在回放阶段我们将目标样本从离线odps存储迁移到多模数据库,提升样本的读取效率。指标计算部分,我们采用sls+kepler/blink实时计算能力,做到分钟级计算出所需要的统计指标结果。
综上所述,大数据仿真评测平台从工程上分为三个部分:
第一,样本流量准备。不仅支持离线清洗的业务T+1线上请求,还支持线上实时日志请求的清洗,满足不同时效性要求的回放数据拆求;
第二,大数据仿真评测引擎核心。按照业务需求对样本流量分层,将流量发送到业务算法平台,获取业务平台返回的仿真结果;
第三,仿真评测指标报告。收集业务算法平台以及下游链路的处理日志,通过实时计算引擎实时产出指标数据。最终就可以用一套通用展现模板输出评估报告。
当然,由于平台是直接请求线上业务系统,为了保证不影响线上业务系统的正常运转。我们也做了请求隔离和并发控制,业务系统也配合做了日志隔离,保证了大数据仿真评测链路的逻辑独立性。
支付宝推荐、搜索、流量运营等后端算法业务场景,不论是常规的日常迭代,还是新产品功能发布,除了常规的功能、性能、稳定性测试以外,也需要有效果质量评估体系保障,全方位保障业务效果、线上质量,最大程度避免对用户产生影响, 我们总能或多或少遇到下面的问题:
总有一些问题,从数据指标层面较难识别;
总有一些问题,不仅仅是标准确定性的问题,也有可能是不好的主观感受;
总有一些问题,不是发生在所有用户的手机上;
总有一些问题,可能只会影响某些城市;
... ...
显而易见人工评测是解决上述问题的有效手段,那常规的人工评测还有如下问题要解决:
服务端的数据如何产品化1:1还原端内展现(因为我们要评估不仅仅是一张图片、一段文本,而是一个真实的产品)?
如何提供更多的信息(特征/画像/行为数据),使得评估过程中的标注结果更为准确?
普通用户如何快速发布一个搜索、推荐产品的人工评测任务?
评估结果如何快速生成的分析数据?
要完全解决上述问题,需要建设一个具备复杂数能力、1:1真实还原端效果的渲染能力、全面的数据分析能力的平台能力。
首先我们要建设的不是一个标注平台,而是一个与搜推业务深度结合的人工评测平台,主要能力体现在如何高效地将复杂的服务端数据在端上真实的还原出来,同时结合辅助信息(用户画像/特征/行为数据等)提高标注的准确性。在复杂数据处理&规范映射设计能力建设上我们把线上海量的历史流量和通过大数据仿真评测得到的结果数据,转换为可以在端上渲染还原的数据,这依赖于我们与众测平台合作建设的一套端内模板渲染的能力,可以将鸟巢/cardsdk/投放sdk的能力复用在评估任务中1:1还原推荐、搜索、腰封的端内效果。
一此评估能力的对比:
评估要素 | 普通标注任务 | 人工评测 |
标注对象 | 元素级别(图片、视频等) | 产品级别(首页推荐栏目、搜索结果页等) |
评估数据来源 | 用户根据平台要求自己清洗(且一般不支持产品级渲染的数据) | 平台提供可供直接发布任务的基础数据表(线上历史流量或大数据仿真评估结果) |
评估数据准备效率 | 几小时·几天不等 | 产品级待标数据分钟级产出 |
辅助标注信息 | 无或者少量 | 时空信息/用户画像/特征/行为数据等 |
平台不仅完成了从0到1的全流程基础能力建设,也具备了快速发布人工评测任务的能力,实现了迭代质量与效能的双提升。整体能力如下:
当前竞品评测平台化的首要目标是解决评测分析效率,为此我们着力解决当前竞品评测的几个痛点:
需要手动在多个竞品app中切换和操作;
没有现在可用竞品标注平台,记录问题时依赖标注人员的表格记录;
竞品评估过程中截图存分散,不方便与任务绑定关联;
统计分析时还需要人工聚合表格,人工生成分析图表;
部分竞品账号资源稀缺,如何最大程度保证其使用效率;
我们的解决方案是:
搭建云真机实时渲染待评估的竞品app,预装app和账号登录;
具备任务切换时操作自动化或最小人工化(自动完成搜索动作,标注人员只需要关注内容和标注);
设计&配置标准格式的问卷,支持实时现场的截图与任务关联;
标注结果自动体系化分析&报表生成。
设备动态调度管理,保证稀缺账号机器资源优先供给对应的竞品评估任务;
在竞品评测能力建设上,通过落地搜索业务的评估,我们主要达到了以下几个目标:
单query结果打开效率(以3个app为例) 1-3分钟 -> 10秒内,以1000个query的任务为例,至少节省14小时。
同机型多竞品同时标注和截图能力,以及标注结果实时的统计分析能力,提效50%。
通过对业务海量可动态定制(人群、时空等)的流量样本进行大数据仿真评测,并结合按业务场景定制的评估指标实现算法冷启动业务效果评估和算法迭代AB实验前置的能力,可以发现实验配置问题、工程链路错误、业务效果不达标(召回热点、空结果、结果重复、打散效果差等)问题;
评估样本【数据能力】:平台共提供3种数据输入分别为:历史请求(全量)条件筛选、自定义筛选、标签圈流分别解决历史场景流量回放、冷启动、特定人群预演问题;具备定时T+1样本更新保持样本新鲜度能力;百万级别样本准备30m内完成。
评估任务【回放能力】:支持多种AB实验能力(单一实验、分层实验、环境、机器等对比评估方式);提供样本实时加工能力,减少样本数据使用成本;支持定时自动启动、根据样本历史请求时间24h回放;安全性上针对不同系统不同场景具备限流、熔断能力;稳定性上支持生产环境6个数据通道仿真;能力开放上共输出32个TR接口,能力开放至AB实验平台、活动预演平台等。
评估报告【指标体系】:共支持工程、效果、模型、特征四大类指标能力,共计300+指标,其中包含平均请求耗时、链路错误数、错误详情等基础指标,item分布、推荐结果重复率、推荐结果空值率、结果打散失效率等业务效果类指标;支持指标7种展现形式,8种模板动态调节,即调即用;支持指标4层分级,重点指标重点颜色展示;时效性上基于实时计算引擎的流式计算实时产出指标;
通过对达尔文算法实验的大数据仿真评测,我们可以对多个达尔文的实验分桶或不同的生产环境(预发、灰度、线上)进行同源样本的流量回放,并在评估指标报告页中聚合展现统计指标,以方便快速发现不同实验分桶或不同环境上的基础工程问题和业务效果问题,如工程链路耗时增加、结果分布异常等等
平台还具备结果级DIFF能力,可以将多个实验分桶或多个环境的同源样本的请求结果进行diff计算,找到可以初步评估结果diff是否符预期,如:搜索结果的排序变化,搜索结果子服务的tab标签的变化等。可以2种方式判断:
一个是直接看结果diff的数据
一个是通过debug平台实时查看带有类似于端上渲染效果的diff情况:
目前平台支持三种接入方式:
嵌入式接入开发:较多应用于平台尚未支持的业务系统接入,通过平台详细的接入指导文档,完成业务系统的接入;
全链路功能sdk方式复用接入:应用于平台已支持的业务系统评估能力,可通过平台提供的大数据仿真评测全链路的tr接口复用评估能力;
部分功能sdk接入:应用于平台已支持的业务系统评估能力,且只需要部分能力接入即可(如任务的触发,样本创建等功能),部分功能仍复用平台能力即可(如指标计算,评估报告等);
目前人工评测评估能力已基本覆盖蚂蚁搜索和推荐的主要业务场景,除覆盖重要项目评估外(首页推荐feed&栏目、搜索二方接入等),不仅成为搜索算法迭代常规评估手段(相关性DIFF评测、满意度评测等),还支持了 风险治理团队的 双周级例行评估任务(推荐有点东西栏目&中间页的服务风险评估)。此外在端渲染标注能力上支持了服务端结果数据1:1还原端上产品效果的渲染能力。实现了结合画像特征(时空、人群、行为特征等) + 1:1真实还原产品端内效果且可实时交互的产品渲染 + 问卷(支持单、多选双层问卷)的 三维一体产品标注形态, 可动态定制城市、人群、模型实验等多维度的数据,从生产->渲染->标注->报告全链路的产品体验效果主观评估,可以发现从数据统计层面不易发现的体验类问题,如:图文不符、内容质量差、排序不合理、时空不符、相关性差等体验&效果问题;
通过云真机聚合渲染的方式实现支付宝与竞品APP同屏效果对比,配合完善的问卷标注与结果统计报表,帮助业务从产品形态到结果内容质量上,更加直观便捷的发现自身优劣势,为后续产品设计、体验升级、超越竞品提供有力的数据依据。目前应用场景主要在蚂蚁搜索业务上落地,并进行了多轮体验效果评估。此外我们还支持:
支持多个竞品app同时打开
切换任务时自动完成搜索动作
竞品app预装及账号登录
标注问卷&现场截图
标注结果分析报告等
为评测平台的核心价值就是为帮忙业务用最小的时间成本发现更多的业务算法效果问题,下面给大家介绍一下平台帮助业务提前发现的部分典型效果问题。
新增特征要加载特征脚本到内存,没加载到内存之前,会有耗时的问题;
代码异常,抛出了NPE导致;
活动规则配置不合理,使发券效果不及预期;
用户积分发放不符合预期,用户等级升级数量控制失效等;
仿真评测能力已经融入多个业务研发CI/CD中,部分业务已实现对仿真评测效果不合预期的迭代和实验进行拦截。
发现推荐的服务或产品的配图问题:有黑色边框、配图有大量水印、配图为手机截图等
关注「阿里巴巴技术质量」阅读更多