美团综合业务推荐系统的质量模型及实践

Posted 2022-06-20 美团技术团队

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了美团综合业务推荐系统的质量模型及实践相关的知识，希望对你有一定的参考价值。

推荐系统是效果导向的数据应用服务，在功能的“有”和“无”之间，有很长的效果“好”和“坏”的光谱。本文以用户请求的粒度建立质量模型，通过数据血缘关联了数据表、算法模型、系统服务和用户请求，并结合美团综合业务的实践进行了拓展泛化，希望能对大家有所帮助或启发。

1 前言

美团到店综合业务（以下简称到综）是美团到店业务的重要板块之一，涵盖洗浴、KTV、美业、医美、亲子、结婚、运动健身、玩乐、教育培训、家居、宠物、酒吧、生活服务等数十个重点细分行业，满足数以亿计用户多样化的本地生活需求。推荐系统在其中是实现供给和需求高效匹配的重要环节，是传递数据价值的出口，而推荐系统的质量决定了匹配效果的折损。如下图 1 所示，数据经过数仓处理、算法加工，再通过数据服务到各个业务系统，最后通过客户端埋点又重新流转回数仓，形成了数据的“飞轮效应”，而质量恰恰是这条链路中齿轮啮合的关键点，是提升效率和保障效果的重要前提。

质量保障要围绕着度量开展，才能“看得见”、“理得清”、“改得准”。但是传统的后台服务质量指标并不能很好地描述当前“数据飞轮”的质量。我们希望通过综合业务推荐系统的质量模型建设，为类似多业务线、效果导向的系统质量度量提供一种新的思考角度和实践参考。

图1 推荐系统的“数据飞轮”

2 现状分析

推荐系统是效果类系统，质量特点与功能类系统有所不同。功能类系统一般降级后会较为显性地影响用户体验，但推荐结果返回 A 或者 A'，用户很难有明显感知。但实际上，如果匹配效果变差，就会直接影响到用户的隐性体验，需要被识别。功能类系统一般以可用性为核心来构建质量指标体系，在综合业务推荐系统的业务实践中，我们发现可用性等指标存在以下的局限性：

可用性对部分缺陷不敏感：可用性是中断频率和持续时间的函数，体现的是系统持续提供服务的能力。只要系统的缺陷不影响对外提供服务，就不影响可用性，但有些实际上影响了用户体验。这里的缺陷可能是意料中的（如主动降级），也可能是意料外的（模型更新延迟），都应该被纳入质量的度量中。
可用性难以覆盖数据的全链路：推荐系统的链路涵盖了数据生产、加工、应用、分析等环节。一是可用性并不涉及数据表的质量，二是在可用性能度量的地方无法反应数据质量的全貌。数据质量需要考虑完整性、准确性、时效性、安全性等特征，超出了可用性的范畴。国际知名学者吴恩达曾说过，人工智能的价值 80% 取决于数据，推荐系统交付推荐效果（点击转化率、交易转化率、用户停留时长等）的质量，也主要取决于数据的质量。
可用性难以反映业务差异性：美团到综覆盖上百个行业、几十个频道页，推荐系统出于效率和成本考虑，业务间无法完全进行隔离，可用性的串并联计算方式难以区分业务进行单独评价。到综不同业务差异很大，访问频次、流量高峰期、业务策略各不相同，从而质量的特点和问题分布也不同。目前可用性的指标缺乏业务维度信息，不利于指导精细化的质量运营。

在质量建设中，过去以故障等级作为目标，验证周期长，具备偶然性，且目标和动作逻辑推导关系不强。另外，故障本身偏事后，这种问题驱动的思路不利于持续运营。总的来说，以可用性为目标，在实际落地计算时存在种种问题，所以我们考虑进行推荐系统的质量模型建设，以可用性为基础，然后调整计算方式，进而指导精细化的质量运营。

3 建设思路

3.1 业务语境下的质量

建设质量模型，先回到对质量本质的理解。根据国际标准化组织（ISO）的定义，质量是反映实体满足明确或隐含“需要”能力的特征总和。另一个常用的质量概念是稳定性，稳定性的核心是让系统长时间地运行在“预期”状态。无论是质量还是稳定性，都要搞清楚系统需要满足谁的需要和预期。在推荐的场景下，这个对象是产品和算法。业务产品通过理解用户场景，抽象用户需求，向推荐团队提出产品需求，体现为对外的产品迭代；同时推荐系统团队内部相互协作，学习最佳优化模型策略，体现为数据团队内部的算法迭代。

如下图 2 所示，在可用性的计算公式中，强调了长时间，而“需要” 和“预期” 只体现在对外提供服务上。这里具有一定的合理性，一是可用性作为业界通用的指标，定义必然是泛化的，那么质量的共性和底线就是对外提供服务；二是大多数后台系统交付功能，对外提供服务大多在“有”和“无”之间，也有一定的空间给到服务降级。但是对于以效果为核心目标的推荐系统，在功能“有”和“无”之间，存有很长的效果“好”和“坏”的光谱。我们对推荐系统质量的思考迭代，核心改变就是从对外提供服务的“有”“无”，变更到对外提供服务的“好”“坏”，这也是改造可用性计算方式的出发点。

图2 对缺陷的认知影响质量度量

3.2 缺陷的考量和选择

不满足“需要”或者“预期”则会产生缺陷，缺陷是质量折损的原因。ISO/IEC 25010 Software Quality Model (2011) 软件质量模型定义了软件缺陷，可以看作是缺陷的全集，它包含了功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性、可移植性 8 个特征及 31 个子特征。这里面有一些质量特征后台服务不涉及（用户界面美学、易学性等），有一些在当下认知中不构成 C 端质量的突出要素（模块性、共存性、不可抵赖性、可重复使用性等）。结合推荐系统的业务特色和高频质量问题，现阶段我们重点考虑如下图 3 所示的质量特征作为缺陷来源。

图3 推荐系统的质量特征

我们发现传统可用性的度量，大多集中在可靠性、功能完整性、正确性方面，但是对于大部分的功能准确性、适当性以及安全性都缺乏度量，这些都与推荐的质量和效果紧密相关。准确性、适当性对效果的影响比较直观，其他则较间接。比如安全性，以安全性中的爬虫访问为例，爬虫由于访问行为不符合真实人类的行为习惯，会影响 UVCTR 等核心指标的回收，从而造成效果误判；同时如果不能识别和剔除爬虫数据，噪声会进一步影响模型训练的准确性。数据质量问题是数据“飞轮效应”中的“毒丸”，会产生正反馈不断放大缺陷。我们将在第四章计算规则中，量化上述的缺陷，拓展可用性的外延。

3.3 度量和计算的选型

可用性可以分为度量方式和计算方式：度量即我们常说的 N 个 9，计算则用平均故障间隔时间和平均恢复时间的函数来衡量。在度量方式上，业界常用的质量度量方式如下图 4 所示：

图4 度量方式

度量方式选几分制，不是现阶段质量分的重点，可用性本身采用的 N 个 9 也足够简单可比较，我们重点考虑计算方式。由于到综业务线众多，推荐系统作为平台型产品，系统与业务是 N:N 的关系，当下系统的可用性难以去计算每个行业、项目和业务的可用性。一个流量位置，它可以归属于休闲玩乐这个业务，可以归属于剧本杀这个项目，可以归属于核心展示主路径的一环，也可以归属于内容推荐的一种，这种灵活的归属性，用请求来聚合计算是最合适的。如下图 5 所示，如果可用性是请求的函数，它既可以包括上一节中我们关心的质量特征，也可以在多个维度统计有业务意义的质量情况。

图5 从请求的角度度量质量

4 计算方式

根据上一章节的建设思路，从故障到缺陷，从推荐结果的“有”、“无”到推荐效果的“好”、“坏”，从整体到各个业务，我们描述了一个好的质量分应该有的特征。这一章节我们着重在指标的计算逻辑上，选取关键缺陷，定义“成功的请求响应”，并增加质量分的业务聚合维度。

4.1 计算公式

结合 3.2 章节中描述的质量特征，从成功请求占比的角度评估系统质量，在实际落地计算时可以分成以下四个层面的缺陷：

系统层面：该请求触发了系统异常，则为缺陷响应。常见的如召回超时、召回失败、召回空结果等。
数据层面：该请求用到的数据出现异常，则为缺陷响应。常见的如供给数量异常、标签分布异常等，数据对用户请求的实际影响，依赖数据血缘关系的建立和影响面评估。
算法层面：该请求在召回和排序过程中，使用的特征、模型、策略异常，则为缺陷响应。常见的如模型更新延迟、特征缺失等，影响推荐的效果表达。
业务层面：该请求触发了业务适当性或安全合规要求，则结果中包含以上结果的请求均为缺陷响应。常见的如运营反馈有供给质量、内容安全等严重的 Bad Case。

一条请求，在生命周期的任意环节经历了缺陷，则在结果上定义为缺陷响应，具体的缺陷环节是分析下钻的维度。我们从 3.2 章节的质量特征和上述缺陷的四个层面选取典型问题（业务痛点、高频质量问题）进行计算，以下图 6 为例：

图6 质量分计算方法

4.2 业务泛化

到综推荐系统的业务特色是多业务线，行业差异大，推荐物料位置多，这折射到质量度量上，我们需要各个层次的聚合分析，进而指导精细化的运营，如下图 7 所示：

图7 各业务层次的聚合分析

到综有很多中低频业务，此时比值的波动受请求绝对值影响较大。针对这些场景，可以聚合部分小流量位，只在行业或者项目层面进行分钟级的监控。

4.3 指标体系

如下图 8 所示，我们将推荐系统响应的一条请求作为一次产品交付行为看待，这些请求中无缺陷的比例，就是推荐系统的质量分，是顶层的质量输出指标。可以根据请求的生命周期，建立一级输入指标，衡量核心流程的质量现状，如召回缺陷率、排序缺陷率等。还可以再将一级指标进一步拆解，得到二级输入指标，比如召回缺陷率比较高时，可以再去衡量召回空值率、召回超时率等。用户的请求还可以根据业务进行垂直、横向、时间维度聚合，得到有业务属性的质量分，这样会更有针对性，更加聚焦。

图8 质量指标体系

这套改进后的质量分，以请求为基本单位，相较于最初的可用性计算方式，在一定范围内解决了它的局限性：对缺陷敏感，可以包括数据链路带来的影响，方便进行多业务维度的聚合分析。

4.4 血缘拓展

质量分以请求的粒度统计，在数据应用服务中，请求只是数据对外输出的形式之一。在完成基础的质量分后，请求的生命周期应该延展到数据全链路，这样对质量的度量才完整。这时就依赖数据的血缘关系，将数据表 - 业务系统 - C 端流量关联起来，构建全景的质量画像，如下图 9 所示：

图9 推荐系统的数据血缘

血缘关系是人类社会由婚姻和生育产生的人际关系，如父母和子女的关系、兄弟和姐妹的关系，以及由此派生出的其他亲属关系，数据也可以通过融合、转换产生数据的血缘关系。数据的血缘关系分数据库、数据表、字段不同级别，一般用于数据资产（引用热度计算、理解数据上下文）、数据开发（影响分析、归因分析）、数据治理（链路状态追踪、数仓治理）、数据安全（安全合规检查、标签传播）四个方面。在目前推荐系统质量分的思路下，主要用影响分析去拓展质量分，将所有途径故障节点的请求都打上标记，扣除相应分数。

在推荐系统的业务语义下，我们定义了六种业务元数据：快照、方案、组件、索引、模型、特征，基于元数据我们构建血缘，可以分为任务接入、血缘解析、数据导出。任务接入分为采集模块和入库模块，当任务接入完成后，将通过图数据库存储节点及节点的关系，利用图算法建立血缘。建立血缘之后，节点本身的异常支持系统发现和人工标记，影响分析则可以自动完成。当节点出现异常则进行消息通知，异常信息会沿着血缘传播，继而影响下游环节的质量分计算。

当异常波及到用户端，我们尝试用业务语言重新描述损失。根据到综收入模型，可以计算出各个业务线每个意向 UV 的价值（用户访问商户详情页、团单详情页称之为意向访问），再利用该流量位周同比的访问情况，自动推导业务损失。

5 指标运营

5.1 系统实现

质量分的系统实现方式依赖于埋点和诊断。推荐全链路包含参数输入、召回前置处理、召回、召回后置处理、粗排、精排、重排等多个环节，每个环节都有可能出故障，因此数据采集需要覆盖运行时异常、各环节的关键输入输出信息等。如下图 10 所示，我们通过 Kafka 异步收集埋点数据，然后分场景进行数据处理：生产环境下，近实时 ES 构建索引，提供近 4 天快速查询服务，4 天前的日志入 Hive 归档，另外通过 Flink 引擎解析埋点数据，经过必要的诊断后，实时计算分数并推送告警信息；测试环境下，日志实时分拣至 mysql，方便测试排查。最后，结构化展示推荐不同阶段的质量情况，提高了结果的可读性。

图10 质量分的系统实现

分数体系的完善需要逐步推进，对于推荐系统，没有推荐结果是最严重的质量问题。我们首先采集和计算的是推荐空结果，对应一级指标里的结果缺陷率、召回缺陷率和二级指标里的结果空值率、召回空值率等。同时由于到综的业务特性，行业众多、供给时空分布不均，大量可交叉的筛选条件也会有空结果，影响质量分的计算。

如何剔除符合业务预期的空结果，消除质量分噪声，在实现埋点的基础上，诊断就变得非常重要。以空结果为例，我们主要从参数诊断、数据诊断、链路诊断三个环节去识别。其中数据诊断指的是当线上筛选条件出现空结果时，回源二次校验底层数据，查询底表数据是否为空。如果底表确实没有相关供给，则沉淀免告警规则，设置免告警有效期，在一段时间内，当前城市当前行业确实缺少相关供给，该空结果不纳入质量分计算。如果底表存在供给，则说明是数据加工或者服务过程中出现了异常，导致无法召回，则再经过链路诊断确定出错环节，纳入相应质量分计算。

如何建立规则匹配机制（即规则引擎）是诊断引擎的关键。当下的规则引擎选择非常多，例如 EasyRule、Drools、Zools、Aviator 等。根据上文分析，诊断引擎需要能够对请求参数、推荐链路以及底层数据进行规则诊断。对于请求参数、推荐链路的诊断均可通过内存参数进行诊断，而数据诊断则需要从第三方存储中获得信息，因此必然有一部分需要定制开发。考虑人员工具使用成熟度以及便利性来说，Aviator 表示式引擎较为合适。为契合需要诊断的内容，设计的表达式诊断原语如下：

//参数诊断-原语表达
//是否符合一定参数的诊断原语
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、召回不为空，过滤规则执行后为空的诊断原语
global:recallEmptyCode=param[$recall#after#],
global:predictFiltersEmptyCode=param[$predict#after#filters#],
global:check=aviator[(recallEmptyCode ==nil || recallEmptyCode =='')  && predictFiltersEmptyCode !=nil]
//4、执行某一具体过滤规则后，导致无结果的匹配
global:filterEmptyCode=param[$PredictStage#filter#after#_compSkRef#],
global:check=aviator[filterEmptyCode !=nil  && filterEmptyCode =='deleteItemByConditionalFilter' ]

//数据诊断-原语表达（判断底层是否有数据，若没有则为true，否则为false）
global:keys=keySpread[@prefix 138_ymtags_][@crossOrder city_$cityId_platform_$platformNo_surgery_prj_$genericLvlIds],
global:cnt=cellar@cellar[@count $keys],
global:check=aviator[cnt !=nil && cnt !='' && long(cnt) <= 0 ]

5.2 告警跟进

质量分可以用于实时监控和运营复盘，需要团队成员及时跟进异动。一般公司通用的告警系统，都是基于服务名称粒度配置告警接收人。推荐系统这类平台型的服务，通过统一的接口提供服务，但是模型策略却是由不同的同学维护，业务间存在一定的行业知识和理解门槛。默认广播式的告警，容易引起告警风暴，每个人无法专注于自己模块的问题，有时也会遗漏告警。

出于跟进率的考量（如下图 11 所示），我们基于现有告警二次开发了跟进功能，将特定流量位的告警路由到专属负责人，并记录跟进状态流转，便于及时周知及事后复盘。在运营方面，我们通过数据报表搭建质量分看板，定期回顾不同业务的质量波动情况。

图11 告警跟进流程

5.3 治理效果

质量分的落地以结果空值率为抓手，按流程拆解采集召回空值率、模型预测空值率、重排算子空值率，并按业务聚合成平台、业务、形态、项目、流量位多个维度。治理动作和成果分为以下几个方面：

通过埋点和诊断，判断当前的空结果是供给问题还是质量问题，排除 98% 的空结果不纳入质量分计算，避免误告警，日均空结果告警数从 40 个降低到 5 个。
基于分析链路过程中各环节的空值率，采取治理措施，包括数据规范（数据分层标准化、标签打标规范）、服务架构（业务隔离、底层数据双介质、降级）、变更规范（配置上线流水线检查、流量回放），将空结果系统发现率保持在 60% 以上。
定制化开发告警路由，避免告警广播，支持标记跟进状态，空结果告警跟进率由无法统计，到核心流量位 100% 跟进。

经过空结果的治理和识别，目前核心流量位空值率为 0.01%，即保证核心流量位 99.99% 的请求有结果，在建设质量分的同时，保证系统发现率和告警跟进率。

5.4 资产沉淀

推荐系统传递的是数据的价值，只有数据被资产化，这种价值才是可持续可增值的。建设推荐系统质量模型的过程，其实也在做数据资产化沉淀。数据在采集后变成资产，一般要满足以下四个条件：可流动、可计量、可管控、可增值，这些在第四章计算方式中都有所涉及。

指标运营的过程，同时也是沉淀质量知识资产的过程。软件缺陷模型究竟如何影响最终的产品交付质量，他们之间是否有相关性、因果性，这种影响是显式地参与分数计算，还是间接影响的。在质量分运营过程中，我们可以逐渐填补脑海中的质量地图，形成指标间、缺陷间、指标和缺陷间的拓扑关系，这是一个将质量资产化的过程。比如通过推荐系统的业务实践，我们发现 80% 的线上故障是由于发布引起的，发布故障中的 80% 又是由于数据发布引起的，这可以指导我们通过治理数据发布减少线上故障。

6 未来规划

我们以可用性为基础，调整计算方式，建立了多层次的推荐系统质量分，并拓展到各种推荐物料、各个业务模块，核心是我们完成了从对外提供服务的“有无”到对外提供服务的“好坏”的认知迭代，这也是质量精细化运营的基础。后续的规划，一方面是继续充实质量模型的计算和链路覆盖；另一方面，我们会基于质量模型做更多的质量治理工作，后续将重点思考与迭代的一些方向包括：