作者：永浩根王鑫等。1前言洗浴、KTV、美业、医美、亲子、婚恋、运动健身、娱乐、教育培训、家居、宠物、酒吧、生活服务等数十个重点细分行业，汇聚一堂亿级用户多样化的本地生活需求。其中，推荐系统是实现供需高效匹配的重要环节，是传递数据价值的输出，推荐系统的好坏决定了匹配效果的好坏。如下图1所示，数据经过数据仓库和算法的处理，然后通过数据服务服务于各个业务系统，最后通过客户端埋点传回数据仓库，形成数据的“飞轮效应”，质量正是这个环节中齿轮啮合的关键点，是提高效率和保证效果的重要前提。质量保证必须围绕测量进行，才能“看得见”、“清楚”、“正确”。但传统的后端服务质量指标并不能很好地描述当前“数据飞轮”的质量。我们希望通过综合业务推荐系统的质量模型构建，为类似于多业务线、效果导向的系统质量度量提供一个新的思维角度和实践参考。图1推荐系统“数据飞轮”2现状分析推荐系统是一个效果系统，其质量特征不同于功能系统。通常，功能系统降级后会明显影响用户体验，但推荐结果返回A或A'，用户难以清晰感知。但实际上，如果匹配效果变差，会直接影响用户的隐性体验，需要识别。功能系统一般构建以可用性为核心的质量指标体系。在综合业务推荐系统的业务实践中，我们发现可用性等指标存在以下局限性：可用性对一些缺陷不敏感：可用性是中断频率和持续时间的函数，功能反映系统持续提供的能力服务。只要系统的缺陷不影响对外服务，就不会影响可用性，但有的实际上会影响用户体验。这里的缺陷可能是预期的（例如主动退化）或意外的（模型更新延迟），并且应该包含在质量测量中。可用性难以覆盖数据的全链路：推荐系统的链路涵盖了数据的生产、处理、应用、分析等各个环节。一是可用性不涉及数据表的质量，二是可用性的衡量不能反映数据质量的全貌。数据质量需要考虑完整性、准确性、及时性、安全性等特性，超出了可用性的范围。国际知名学者吴恩达曾表示，人工智能80%的价值取决于数据，而推荐系统所传递的推荐效果（点击转化率、交易转化率、用户停留时间等）的好坏也主要取决于数据。取决于数据的质量。易用性难以体现业务差异：美团覆盖数百个行业，数十个频道页面。出于效率和成本的考虑，推荐系统不能在业务之间完全隔离。评价。不同的业务、访问频率、流量高峰期、业务策略等都存在很大差异，因此质量特征和问题分布也不同。目前的可用性指标缺乏业务维度信息，不利于指导精细化质量运营。在质量建设中，以往以故障等级为目标，验证周期长，具有偶然性，目标与动作逻辑推导的关联性不强。另外，失败本身就是事后诸葛亮，这种问题驱动的思维不利于持续经营。一般来说，以可用性为目标，在实际计算中会出现各种各样的问题。因此，我们考虑构建推荐系统的质量模型，以可用性为基础，进而调整计算方法，指导精细化质量运行。3构建思路3.1业务语境中的质量构建质量模型，首先要回归到对质量本质的理解。根据国际标准化组织（ISO）的定义，质量是反映一个实体满足明示或暗示的“需要”能力的特性的总和。另一个常用的质量概念是稳定性。稳定的核心是让系统长期运行在“预期”的状态。无论是质量还是稳定性，重要的是弄清楚系统需要满足谁的需求和期望。在推荐场景中，对象是产品和算法。业务产品理解用户场景，抽象用户需求，向推荐团队提出产品需求，体现在外部产品迭代中；同时，推荐系统团队相互协作学习最佳优化模型策略，体现在数据团队内部的算法迭代中。如下图2所示，在可用性的计算公式中，强调了长时间，而“需要”和“期望”只体现在对外服务的提供上。这里有一定的合理性。首先，易用性是业界通用的指标，定义上一定要泛化。质量的共性和底线是对外提供服务；第二，大部分后台系统交付功能，大部分对外服务都是在“可用”和“无”中提供的，服务也有一定的降级空间。但是对于一个以效果为核心目标的推荐系统来说，有“是”和“否”之间的“好”和“坏”影响的长谱。我们对推荐系统质量的迭代思考，核心变化是从外部服务的“是”和“否”到外部服务的“好”与“坏”，这也是可用性计算方法转变的出发点图2.缺陷认知影响质量测量3.2缺陷的考虑与选择不满足，缺陷是质量损失的原因。ISO/IEC25010SoftwareQualityModel(2011)软件质量模型定义了软件缺陷，可以看作是一个完整的缺陷集，包括功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性、可移植性8个特征和31个子特征。有一些后台服务不涉及的质量特性（用户界面美观、易学性等），还有一些目前认知中不构成C端质量的突出要素（模块化、共存性、不可抵赖性、可重用性等）).结合推荐系统的业务特点和高频质量问题，现阶段我们重点关注下图3所示的质量特征作为缺陷源。图3推荐系统的质量特征我们发现，传统的可用性度量大多侧重于可靠性、功能完整性和正确性，而缺乏对大多数与推荐质量和效果相关的功能准确性、适当性和安全性的度量密切相关。准确性和适当性对效果的影响更直观，而其他则更间接。比如安全，以安全中的爬虫访问为例，由于爬虫的访问行为不符合真实的人类行为习惯，会影响UVCTR等核心指标的恢复，导致效果误判；同时，如果爬虫数据无法识别和剔除，Noise会进一步影响模型训练的准确性。数据质量问题是数据“飞轮效应”中的“毒丸”，会产生正反馈，不断放大缺陷。我们将在第四章计算规则中对上述缺陷进行量化，扩展可用性的扩展。3.3测量和计算的选择可用性可分为测量方法和计算方法：测量就是我们常说的N个9，计算是通过平均无故障时间和平均恢复时间的函数来衡量的。在测量方法方面，业界常用的质量测量方法如下图4所示：图4评分体系的测量方法选择不是现阶段质量评分的重点。usability本身用到的Nnines也很简单，比较Focus的计算方法。由于业务线众多，推荐系统是一个平台产品，系统与业务的关系是N:N。对于当前的系统可用性，很难计算每个行业、项目和业务的可用性。一个流量位，可以属于休闲娱乐业务，可以属于杀脚本项目，可以属于核心展示主路径的一个环节，也可以属于一种内容推荐。这种灵活的属性可以根据要求使用聚合计算最合适。如下图5所示，如果可用性是requests的一个函数，那么它不仅可以包含上一节我们关心的质量特征，还可以多维度统计具有业务意义的质量。图5从请求的角度衡量质量4计算方法按照上一章的构建思路，从faults到defects，从推荐结果中的“yes”和“no”到推荐结果中的“good”和“bad”效果，从整体到每一个业务，我们描述一个好的质量分数应该具备的特征。本章我们重点关注指标的计算逻辑，选取关键缺陷，定义“请求响应成功”，增加质量点的业务聚合维度。4.1计算公式结合3.2节描述的质量特征，从请求成功比例的角度来评价系统质量。在实际计算中，可以分为以下四个级别的缺陷：系统级：请求触发系统异常，属于缺陷响应。常见的有召回超时、召回失败、召回空结果等。数据层面：如果请求中使用的数据异常，则为缺陷响应。常见的，如供应量异常、标签分布异常等，数据对用户请求的实际影响，依赖于数据亲属关系的建立和影响区域的评估。算法层面：在请求的召回和排序过程中，如果使用的特征、模型、策略出现异常，则为缺陷响应。模型更新延迟和缺失特征等常见问题会影响推荐的性能。业务层面：请求触发业务适用性或安全合规性需求，包含上述结果的请求均为缺陷响应。常见的运营反馈包括严重的BadCases，例如供应质量和内容安全。请求在生命周期中的任何一个环节出现缺陷，在结果上定义为缺陷响应，具体的缺陷环节是分析下钻的维度。我们从3.2章节的质量特征和上述缺陷的四个层次中选取典型问题（业务痛点、高频质量问题）进行计算。下面以图6为例：图6质量分计算方法4.2业务泛化到综合推荐系统业务特点是业务线多、行业差异大、推荐素材位置多。这反映在质量测量中。我们需要在各个层级做聚合分析，指导精细化运营，如下图7所示：图7各个业务层级聚合分析，中低频业务较多，此时比例波动较大受请求的绝对值影响。针对这些场景，可以聚合一些小流量比特，只做行业或项目级别的分钟级监控。4.3指标体系如下图8所示。我们将推荐系统响应的请求视为产品交付行为。这些没有缺陷的请求所占的比例就是推荐系统的质量得分，是顶级的质量输出指标。根据请求的生命周期，可以建立一级输入指标，衡量核心流程的质量状态，如召回缺陷率、分拣缺陷率等，还可以进一步拆解一级指标获取二级输入指标。例如，当召回缺陷率比较高时，可以测量召回无效率和召回超时率。还可以根据业务对用户的请求进行纵向、横向、时间聚合，得到具有业务属性的质量分值，更加具有针对性和针对性。图8质量指标体系改进后的质量评分以请求为基本单位。与原有的可用性计算方法相比，解决了它在一定范围内的局限性：对缺陷敏感，可以包含数据链路。方便多个业务维度的聚合分析。4.4沿袭扩展的质量是根据请求的粒度来计算的。在数据应用服务中，请求只是数据输出的一种形式。在完成基本的质量评分后，应该将请求的生命周期扩展到整个数据链路，这样质量的度量就完成了。这时候就依赖于数据的血缘关系，关联数据表-业务系统-C端流量构建全景质量画像，如下图9所示：由此产生的人际关系，如关系父母与子女之间，兄弟姐妹之间的关系，以及由此衍生出的其他亲属关系，数据也可以进行融合转换，生成数据的血缘关系。数据的血缘关系分为不同层次的数据库、数据表、字段。一般用于数据资产（参考热度计算、理解数据脉络）、数据开发（影响分析、归因分析）、数据治理（链路状态跟踪、数据仓库治理）、数据安全（安全合规检查、标签发布）四个方面。在目前推荐系统质量分的思路下，主要是通过影响分析来扩大质量分，对所有路径失效节点的请求进行标记，并扣除相应的分。在推荐系统的业务语义下，我们定义了六种业务元数据：快照、方案、组件、索引、模型和特征。基于元数据构建血脉，分为任务接入、血脉分析、数据导出。任务访问分为采集模块和存储模块。任务接入完成后，节点及其关系将存储在图数据库中，并使用图算法建立血缘关系。建立血缘关系后，节点自身异常支持系统发现和人工标记，自动完成影响分析。当节点出现异常时，会发送消息通知，异常信息会沿着血缘关系进行传播，进而影响下游链路的质量分值计算。当异常传播到客户端时，我们尝试用商业语言重新描述损失。根据综合收益模型，可以计算出每个业务线的每个意向UV的价值（用户访问商户详情页和团购详情页，称为意向访问），然后利用周访问情况的流量位自动导出业务损失。5指标运行5.1系统实现质量评分的系统实现方法依赖于嵌入和诊断。建议整个链路包括参数输入、召回预处理、召回、召回后处理、粗排序、精排序、重排等多个环节，每个环节都可能失败，所以数据采集需要覆盖运行时异常，各个环节的关键输入输出信息等。如下图10所示，我们通过Kafka异步采集埋入数据，然后在不同场景下对数据进行处理：在生产环境中，ES近实时建立索引，提供近4天的快速查询服务，将4天前的日志归档到Hive中，通过Flink引擎分析埋点数据，经过必要的诊断后，实时计算分值并推送告警信息；测试环境，日志实时整理到MySQL，方便测试排查。最后，结构化展示不同阶段的推荐质量，提高了结果的可读性。图10质量评分系统实现评分系统的完善需要逐步推进。对于推荐系统来说，没有推荐结果是最严重的质量问题。我们首先收集并计算推荐的无效结果，其对应一级指标中的结果缺陷率和召回缺陷率以及二级指标中的结果无效率和召回无效率。同时，由于综合购物的经营特点，行业众多，供给时空分布不均。大量的交叉过滤条件也会出现空结果，影响质量分数的计算。如何剔除符合业务预期的空结果，剔除质量得分噪音？在实现埋点的基础上，诊断就变得非常重要。以空结果为例，我们主要从参数诊断、数据诊断、链路诊断三个环节进行识别。其中，数据诊断是指当在线过滤条件为空结果时，回源两次检查底层数据，查询底层表数据是否为空。如果底表确实没有相关货源，则结算免警规则，并设置免警有效期。一段时间内，如果当前城市的当前行业确实缺乏相关供给，则空结果不计入质量分数的计算。如果底表有供应，说明数据处理或服务过程出现异常，无法召回，再通过链路诊断判断错误链路，计入计算相应的质量分数。如何建立规则匹配机制（即规则引擎）是诊断引擎的关键。目前规则引擎的选择较多，如EasyRule、Drools、Zools、Aviator等。根据以上分析，诊断引擎需要能够对请求参数、推荐链接、底层数据进行规则诊断。请求参数和推荐链接的诊断可以通过内存参数进行诊断，而数据诊断需要从第三方存储中获取信息，所以有些部分需要定制开发。考虑到使用人类工具的成熟度和便利性，Aviator表达式引擎更为合适。为了贴合需要诊断的内容，设计的表达式诊断原语如下：//parameterdiagnosis-primitiveexpression//满足一定参数的诊断原语global:check=aviator[cityId!=nil&&include(string.split('1,2,3,4,5,6,7,8,9,10,16,17',','),str(cityId))]//链路诊断-原始表达式//1,调用异常诊断原语global:recallException=param[${recall#exception#}],global:check=aviator[recallException!=nil&&recallException!='']//2.无一例外地调用诊断原语global:recallEmpty=param[${recall#after#}],global:check=aviator[recallEmpty!=nil&&recallEmpty!='']//3.recall不为空，过滤规则执行后诊断源为空global:check=aviator[(recallEmptyCode==nil||recallEmptyCode=='')&&predictFiltersEmptyCode!=nil]//4.执行特定过滤规则后，没有匹配到的结果/数据诊断-原始表达式（判断底层是否有数据，没有则为真，否则为假）global:keys=keySpread[@prefix138_ymtags_][@crossOrdercity_${cityId}_platform_${platformNo}_surgery_prj_${genericLvlIds}],global:cnt=cellar@cellar[@count${keys}],global:check=aviator[cnt!=nil&&cnt!=''&&long(cnt)<=0]5.2报警跟进质量评分可用于实时监控和运维回顾，需要团队成员及时跟进变化。一般公司常见的告警系统都是按照服务名粒度配置告警接收者。推荐系统等平台化服务通过统一接口提供服务，但模型策略由不同学员维护，业务间存在一定的行业知识和理解门槛。默认的广播告警容易引起告警风暴。每个人都不能专注于自己模块的问题，有时会漏掉警报。出于跟进率的考虑（如下图11），我们在已有告警的基础上重新开发了跟进功能，将特定流量级别的告警路由到专人负责，并记录跟进-up状态流，用于及时通知和事后重播。在运营方面，我们通过数据报表构建质量仪表盘，定期审核不同业务的质量波动情况。图11告警跟进流程5.3治理效果质量评分实现基于结果空值率，拆解收集召回空值率、模型预测空值率、重排算子空值率，按业务聚合到平台、业务等多个维度、形式、项目和交通。治理行为和结果分为以下几个方面：通过埋点和诊断，判断当前空结果是供应问题还是质量问题，排除98%的空结果进入质量分数的计算，避免误报，以及alert日均空值结果计数从40条减少到5条。基于链接过程中各环节空值率分析，采取治理措施，包括数据规范（数据层标准化、标签标识规范）、服务架构（业务隔离、底层数据双媒、降级）、变更规范（配置上线流水线检测、流量回放）保持空结果系统发现率在60%以上。自定义开发告警路由，避免告警广播，支持标记跟进状态，空结果告警跟进率不能算作100%跟进核心流量。经过空结果管理和识别，目前核心流量比特空值为0.01%，也就是说99.99%的核心流量比特请求都有结果。在建立质量分数的同时，保证了系统发现率和告警跟进率。5.4资产积累推荐系统传递的是数据的价值。只有将数据资本化，这个价值才能可持续，才能增值。构建推荐系统质量模型的过程，其实就是在沉淀数据资产。数据采集??并转化为资产后，一般需要满足以下四个条件：可流动、可计量、可控、增值，这在第四章的计算方法中都有涉及。指标运行的过程也是积累优质知识资产的过程。软件缺陷模型如何影响最终的产品交付质量，它们之间是否存在相关性和因果关系，这种影响是显式参与评分计算，还是间接参与。在质量管理过程中，我们可以逐步将质量地图填入脑海，形成指标之间、缺陷之间、指标与缺陷之间的拓扑关系。这是一个质量资本化的过程。比如通过推荐系统的业务实践，我们发现80%的上线失败是因为发布，80%的发布失败是因为数据发布。这可以指导我们通过管理数据发布来减少在线故障。6未来规划基于易用性，我们调整了计算方式，建立了多层次的推荐系统质量分值，并扩展到各种推荐素材和业务模块。对外提供服务“好坏”的认知迭代，也是精细化品质运营的基础。后续规划，一方面，将继续丰富质量模型的计算和链路覆盖；另一方面，我们会在质量模型的基础上做更多的质量治理工作，未来会重点迭代的一些方向包括：和诊断，逐步落实质量评分体系中各层次的指标，丰富质量评分的内涵，容纳更多的质量问题。通过构建多级推荐的灵活降级，迭代了解质量得分并量化不同降级对系统的影响。优化数据沿袭的准确性、覆盖度和时效性，更准确、更快速地评估某一环节质量问题的影响。7本文作者永浩、根根、王欣、和合、李从等，均来自美团到店平台技术部/道宗业务数据团队。
