简介
优酷搜索承担着内容分发场的头部兵的重任，海量的视频内容都要依赖搜索触达和呈现给 用户，而且逐渐扩大范围，开始向阿里文娱全系产品提供搜索服务和能力。
面对如此复杂且对稳定性、精准性要求极高的系统，质量保障工作显得尤为重要和极具挑 战性。本文将为大家介绍视频搜索的质量体系是如何构建和发挥作用的。
1. 视频搜索架构特点
支持复杂多样的上层业务场景，业务逻辑复杂；
从搜索开始到结果返回的整个业务链路长，涉及的模块及外部依赖多；
算法依赖数据，底层数据变更会引起上层算法结果变化。
业务链路长且复杂，用例覆盖率等难以进行有效度量；
离线和实时数据变更如何影响业务，数据质量的监控如何和业务紧密结合；
算法模块存在复杂性及不可解释性，算法效果难以进行有效评估；
海量数据中单个 badcase 无法说明问题，如何有效发掘共性的 badcase。
1．回归
回归测试主要是上线发布前的测试，目的在于提前发现 bug，保证发布质量。目前各模块 的回归测试均已作为研发流程的一环，交由研发自行进行冒烟，不管是否走提测流程，均能在 一定程度上把控业务质量。
我们根据链路的分层，针对各层模块进行了各模块自身的功能回归建设。各模块测试用例 的自动化回归依托于冒烟平台，其可实现任意环境的快速回归，目前已积累回归用例 5000+， 定时线上巡检，分钟级发现问题。
1）功能监控 仍然是根据链路的模块划分，进行分层监控。监控仍依托于冒烟平台，并存储各模块日常。
冒烟监控数据以及真实 bug 数据。目前通过巡检已累计发现线上 bug50+。具体冒烟监控数据大盘如下图所示。
2）效果监控线上效果监控的目的在于快速发现线上效果问题，保证线上质量；此外通过固化每次效果
监控数据，监控线上效果问题的长期变化趋势，以辅助研发进行算法迭代优化，最大化利用人工评测数据。已经形成了生成监控集合->定时监控->发现问题->解决问题闭环的处理机制。
1）离线
借助集团已有平台的监控能力，定制业务细则，监控流程基本分为几个阶段：存在原始表，创建对应表的分区及监控规则，订阅分区规则，原始表周期任务执行结束自动触发 dqc 上对应表的对应分区的规则，如果异常会根据订阅内容报警。
step1: 确定监控哪些表。比如我们监控 A 表，该节点监控规则一旦失败是否要中断后续的 生产流程，如果需要中止后续的生产流程，那 stepn 配置强规则即可,此时要保证监控规则是业 务合理的，当然一旦中止数据生产流程，我们要承受住多方的考验，节点多次失败账号健康分 会受影响，任务的执行也会受影响；如果不需要中止后续的生产流程，有两种方案，一是创建 影子表，监控影子表(浪费一个存储周期的空间)；二是所有规则置为弱规则(短信告警无法判断 报警的严重程度)。实践中，重要的宽表数据我们采用了监控影子表方案，次重要的表采用了对 原始表全部配置弱规则的方案。
step2：在监控平台创建分区，用来指定是要监控哪天的数据。
step3:配置规则，规则可分为通用规则和特性规则。数据量重要度属于 P0 级，采用数据量 绝对值>阈值；同时采用了 7 天趋势绝对值变动在预警值在 10%，20%(不同业务阈值根据业务 需要设定)。表数据量突增和突降在优酷场都不合理，所以采用了 7 天平均值波动+绝对值模式。 通用规则是各字段通用的规则，基本包含是否非空，是否为 0 等等，体现在数据监控上面就是 非空的数据量|数据占比变化趋势是否符合预期，值域非 0 的的数据量|数据占比变化趋势是否符 合预期。特性规则需要视业务特性而定，采取单字段 max、min、均值、总量，组合特征数量、 变化率、空置率等个性化定制规则。
step4：订阅，支持短信、钉钉机器人、邮件等等。
2）实时
把握整个实时流式计算的业务系统有几个关键点：流式计算、数据服务、全链路、数据业 务（包括索引和摘要）。结合质量保障体系的线上、线下全链路闭环的理论体系去设计我们的整 体质量保障方案，如下图所示：
1）特征算子组件单测
UDF 在算法数据特征计算过程中是特别普遍的开发组件单元，实时和离线都有自己的 UDF 定义，UDF 也支持多种语言，UDF 本质上是一个函数，它以不同的工程资源形式附加到各个平 台的项目中使用，UDF 的测试就可以简化成函数的测试，归结为输入输出的类函数单测的模式。 我们复用统一框架的执行能力设计 UDF 单测模式如下：
UDF 从功能输出来说分为三类：
第一类是有固定规则和处理逻辑的，这种可以通过输入输出来构建 case，判断时候则判断 固定的输入是否等于输出就行；
第二类则是一些通用的规则类或者一下非固定业务含义输出的，这一类我们则通过正则匹 配或者通用规则来去校验结果；
第三类则是算法模型类，这种我们通过构建算法的评测集合，去执行评测集，获得recall&accuracy 指标阈值来进行是是否通过校验。
2）feature 列级测试
列级特征则是将整个列的计算逻辑以 UDF 算子为单元组件进行 DAG 逻辑编排，然后通过 编译生成图化逻辑来流式构建特征列。计算引擎原理如图：
列级特征本质上就是一个图化的 UDF 组合逻辑，可以看做是一个复杂图化的计算函数，包 含了很多子 UDF 的图化遍历的逻辑。构建编译器在列级图化逻辑编排完成之后进行编译会得到 该列的 DAG 信息。这个 DAG 信息就会作为列级的图化逻辑属性。当列级 feature 进行逻辑执行 的时候会解析该 DAG 信息进行图的遍历依次执行 UDF 算子。同样的原理，我们在测试构建时 候我们构造列级特征检测的 case 集合。
特征既有数据含义，同时也具备部分业务应用上的含义， 特征检测我们可以结合数据规则和业务含义内容共同制定特征检测机制。通过构建特征输入集 来进行图化逻辑执行得到特征值，通过特征值的检测、特征分布、特征业务属性检测几个维度 去完成特征检测。这个时候我们会通过统一的 trace 策略机制去记录每个 UDF 的调用执行情况， 以供追查 UDF 执行错误和异常情况。
3）全图化索引测试
前面 UDF 是算子组件维度的，而特征 feature 是列维度的，索引全列则是以行为维度的， 每行综合多列。而全列索引特征构建是综合多列 feature 的图化逻辑形成的一个 pipline。pipline 以引擎索引分类为一个完整的 Pipline，比如 OCG 就是一个全列的完整 Pipline。所以 Pipline 级 别的数据测试则是以行维度的数据。
1）效果基线 对搜索整条链路以及链路上影响算法的重要模块如意图分析模块都建设了效果基线。
a）搜索链路效果基线建设。
效果测试集必须是动态的，这里采用 case 放在云文件或者数据平台，当流量出现新词的时 候随时添加。要作为效果基线，必须保证测试集对应的预期结果必须是准确的，这里采用的机 制是评测同学维护。总体流程是评测同学在数据平台维护效果基线 query、预期结果，代码加载 数据进行规则判断，噪音消除，失败报警。
规则：检测 TOP n 召回某种类型卡片，TOP n 只能召回某些 showids，聚合卡片中 TOPN 只能召回某些 showids，n 可配、showids 可配、卡片类型可配等等；
噪音消除：失败重试、运营数据剔除、showid 可能出现在多种卡片，每种都需要相应业 务逻辑。
使用场景：
搜索链路所有模块发布卡口；
被列为 AB test 期间关注的指标之一，指标一旦失败，实验回滚；
大流量桶的日常监控，成功率要求 100%，一旦失败必须及时修正。
b）意图模块
QP 的效果基线建设。方案：方案主要涉及意图类型、测试集构建、验证规则。效果基线要 check 哪些意图呢？主要是从产品形态和算法使用情况来确定，每个意图都涉及正样本和负样本；样本数据取自线上已经识别出的意图数据然后人工审核后分别放在对应的正样本和负样本，负样本还有一部分 数据来自互斥意图的正样本数据；规则：同一个意图对于不同的算法使用意图不同，比如人物， “郭德纲于谦”切词后这个词属于人物，但是不应该出人物卡。
使用场景：
发布卡口；
线上定时监控：对于意图模块数据回流、代码发布都会影响效果，数据回流是自动触发， 数据是否正确未知，也就说明线上定时监控的必要性。
2）搜索效果影响面自动评估
测试集构建：线上真实流量按照 SQV 进行分层、采样(越偏头部采样密度越大)，线上流 量映射到测试集；
评测规则：分析用户使用搜索的习惯，对用户经常点击的位置分别进行比对；
影响面计算：异常请求的 sqv 总和/所有 sqv 总和；
噪音消除：异常重试、去掉算法无关卡片，来保证影响面评测的准确度。
3）指标看板
将评测能力集成到监控中，分钟级运行，产出效果指标大盘，及时发现算法问题并能指导算法优化。
分析线上流量， badcase 挖掘主要集中在腰尾部高跳词。除了流量分层还有一个重要的流 量就是实效性极高的热点。
1）高跳 badcase 挖掘：通过竞品对比等手段检测出多种类型的 badcase，badcase 会映射到 具体原因上，直接进行专项优化，优化后的 case 会放入每次迭代，未优化的 case 以 badcase 形 式存在 badcase 库，后续效果迭代会运行这些数据，以检测 badcase 的效果；
2）时效性分析：分析各大平台的热点内容，与自身做对比，并加入了相关性过滤逻辑。运 行机制：一天两次，研发会及时处理报警内容，同时会进行长期优化，现在 badcase 比例已明 显下降。
依托优酷舆情发现和处理平台优酷声音，聚合用户观点，针对搜不到、搜不好等问题，做专项优化，已解决 5 大类 badcase。
京公网安备 11010802035086号