推荐系统在美团综合业务中的应用及实践
猜你喜欢
0、【免费下载】2022年8月热门报告盘点1、如何搭建一套个性化推荐系统？2、从零开始搭建创业公司后台技术栈3、全民K歌推荐系统算法、架构及后台实现4、微博推荐算法实践与机器学习平台演进5、腾讯PCG推荐系统应用实践6、强化学习算法在京东广告序列推荐场景的应用7、飞猪信息流内容推荐探索8、华为项目管理培训教材9、美团大脑系列之商品知识图谱的构建和应用
推荐系统是效果导向的数据应用服务，在功能的“有”和“无”之间，有很长的效果“好”和“坏”的光谱。本文以用户请求的粒度建立质量模型，通过数据血缘关联了数据表、算法模型、系统服务和用户请求，并结合美团综合业务的实践进行了拓展泛化，希望能对大家有所帮助或启发。
1 前言
2 现状分析
3 建设思路
3.1 业务语境下的质量
3.2 缺陷的考量和选择
3.3 度量和计算的选型
4 计算方式
4.1 计算公式
4.2 业务泛化
4.3 指标体系
4.4 血缘拓展
5 指标运营
5.1 系统实现
5.2 告警跟进
5.3 治理效果
5.4 资产沉淀
6 未来规划
1 前言
美团到店综合业务（以下简称到综）是美团到店业务的重要板块之一，涵盖洗浴、KTV、美业、医美、亲子、结婚、运动健身、玩乐、教育培训、家居、宠物、酒吧、生活服务等数十个重点细分行业，满足数以亿计用户多样化的本地生活需求。推荐系统在其中是实现供给和需求高效匹配的重要环节，是传递数据价值的出口，而推荐系统的质量决定了匹配效果的折损。如下图 1 所示，数据经过数仓处理、算法加工，再通过数据服务到各个业务系统，最后通过客户端埋点又重新流转回数仓，形成了数据的“飞轮效应”，而质量恰恰是这条链路中齿轮啮合的关键点，是提升效率和保障效果的重要前提。
质量保障要围绕着度量开展，才能“看得见”、“理得清”、“改得准”。但是传统的后台服务质量指标并不能很好地描述当前“数据飞轮”的质量。我们希望通过综合业务推荐系统的质量模型建设，为类似多业务线、效果导向的系统质量度量提供一种新的思考角度和实践参考。
2 现状分析
推荐系统是效果类系统，质量特点与功能类系统有所不同。功能类系统一般降级后会较为显性地影响用户体验，但推荐结果返回 A 或者 A'，用户很难有明显感知。但实际上，如果匹配效果变差，就会直接影响到用户的隐性体验，需要被识别。功能类系统一般以可用性为核心来构建质量指标体系，在综合业务推荐系统的业务实践中，我们发现可用性等指标存在以下的局限性：
可用性对部分缺陷不敏感：可用性是中断频率和持续时间的函数，体现的是系统持续提供服务的能力。只要系统的缺陷不影响对外提供服务，就不影响可用性，但有些实际上影响了用户体验。这里的缺陷可能是意料中的（如主动降级），也可能是意料外的（模型更新延迟），都应该被纳入质量的度量中。
可用性难以覆盖数据的全链路：推荐系统的链路涵盖了数据生产、加工、应用、分析等环节。一是可用性并不涉及数据表的质量，二是在可用性能度量的地方无法反应数据质量的全貌。数据质量需要考虑完整性、准确性、时效性、安全性等特征，超出了可用性的范畴。国际知名学者吴恩达曾说过，人工智能的价值 80% 取决于数据，推荐系统交付推荐效果（点击转化率、交易转化率、用户停留时长等）的质量，也主要取决于数据的质量。
可用性难以反映业务差异性：美团到综覆盖上百个行业、几十个频道页，推荐系统出于效率和成本考虑，业务间无法完全进行隔离，可用性的串并联计算方式难以区分业务进行单独评价。到综不同业务差异很大，访问频次、流量高峰期、业务策略各不相同，从而质量的特点和问题分布也不同。目前可用性的指标缺乏业务维度信息，不利于指导精细化的质量运营。
在质量建设中，过去以故障等级作为目标，验证周期长，具备偶然性，且目标和动作逻辑推导关系不强。另外，故障本身偏事后，这种问题驱动的思路不利于持续运营。总的来说，以可用性为目标，在实际落地计算时存在种种问题，所以我们考虑进行推荐系统的质量模型建设，以可用性为基础，然后调整计算方式，进而指导精细化的质量运营。
3 建设思路
3.1 业务语境下的质量
建设质量模型，先回到对质量本质的理解。根据国际标准化组织（ISO）的定义，质量是反映实体满足明确或隐含“需要”能力的特征总和。另一个常用的质量概念是稳定性，稳定性的核心是让系统长时间地运行在“预期”状态。无论是质量还是稳定性，都要搞清楚系统需要满足谁的需要和预期。在推荐的场景下，这个对象是产品和算法。业务产品通过理解用户场景，抽象用户需求，向推荐团队提出产品需求，体现为对外的产品迭代；同时推荐系统团队内部相互协作，学习最佳优化模型策略，体现为数据团队内部的算法迭代。
如下图 2 所示，在可用性的计算公式中，强调了长时间，而“需要” 和“预期” 只体现在对外提供服务上。这里具有一定的合理性，一是可用性作为业界通用的指标，定义必然是泛化的，那么质量的共性和底线就是对外提供服务；二是大多数后台系统交付功能，对外提供服务大多在“有”和“无”之间，也有一定的空间给到服务降级。但是对于以效果为核心目标的推荐系统，在功能“有”和“无”之间，存有很长的效果“好”和“坏”的光谱。我们对推荐系统质量的思考迭代，核心改变就是从对外提供服务的“有”“无”，变更到对外提供服务的“好”“坏”，这也是改造可用性计算方式的出发点。
3.2 缺陷的考量和选择
不满足“需要”或者“预期”则会产生缺陷，缺陷是质量折损的原因。ISO/IEC 25010 Software Quality Model (2011) 软件质量模型定义了软件缺陷，可以看作是缺陷的全集，它包含了功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性、可移植性 8 个特征及 31 个子特征。这里面有一些质量特征后台服务不涉及（用户界面美学、易学性等），有一些在当下认知中不构成 C 端质量的突出要素（模块性、共存性、不可抵赖性、可重复使用性等）。结合推荐系统的业务特色和高频质量问题，现阶段我们重点考虑如下图 3 所示的质量特征作为缺陷来源。
我们发现传统可用性的度量，大多集中在可靠性、功能完整性、正确性方面，但是对于大部分的功能准确性、适当性以及安全性都缺乏度量，这些都与推荐的质量和效果紧密相关。准确性、适当性对效果的影响比较直观，其他则较间接。比如安全性，以安全性中的爬虫访问为例，爬虫由于访问行为不符合真实人类的行为习惯，会影响 UVCTR 等核心指标的回收，从而造成效果误判；同时如果不能识别和剔除爬虫数据，噪声会进一步影响模型训练的准确性。数据质量问题是数据“飞轮效应”中的“毒丸”，会产生正反馈不断放大缺陷。我们将在第四章计算规则中，量化上述的缺陷，拓展可用性的外延。
3.3 度量和计算的选型
可用性可以分为度量方式和计算方式：度量即我们常说的 N 个 9，计算则用平均故障间隔时间和平均恢复时间的函数来衡量。在度量方式上，业界常用的质量度量方式如下图 4 所示：
度量方式选几分制，不是现阶段质量分的重点，可用性本身采用的 N 个 9 也足够简单可比较，我们重点考虑计算方式。由于到综业务线众多，推荐系统作为平台型产品，系统与业务是 N:N 的关系，当下系统的可用性难以去计算每个行业、项目和业务的可用性。一个流量位置，它可以归属于休闲玩乐这个业务，可以归属于剧本杀这个项目，可以归属于核心展示主路径的一环，也可以归属于内容推荐的一种，这种灵活的归属性，用请求来聚合计算是最合适的。如下图 5 所示，如果可用性是请求的函数，它既可以包括上一节中我们关心的质量特征，也可以在多个维度统计有业务意义的质量情况。
4 计算方式
根据上一章节的建设思路，从故障到缺陷，从推荐结果的“有”、“无”到推荐效果的“好”、“坏”，从整体到各个业务，我们描述了一个好的质量分应该有的特征。这一章节我们着重在指标的计算逻辑上，选取关键缺陷，定义“成功的请求响应”，并增加质量分的业务聚合维度。
4.1 计算公式
结合 3.2 章节中描述的质量特征，从成功请求占比的角度评估系统质量，在实际落地计算时可以分成以下四个层面的缺陷：
系统层面：该请求触发了系统异常，则为缺陷响应。常见的如召回超时、召回失败、召回空结果等。
数据层面：该请求用到的数据出现异常，则为缺陷响应。常见的如供给数量异常、标签分布异常等，数据对用户请求的实际影响，依赖数据血缘关系的建立和影响面评估。
算法层面：该请求在召回和排序过程中，使用的特征、模型、策略异常，则为缺陷响应。常见的如模型更新延迟、特征缺失等，影响推荐的效果表达。
业务层面：该请求触发了业务适当性或安全合规要求，则结果中包含以上结果的请求均为缺陷响应。常见的如运营反馈有供给质量、内容安全等严重的 Bad Case。
一条请求，在生命周期的任意环节经历了缺陷，则在结果上定义为缺陷响应，具体的缺陷环节是分析下钻的维度。我们从 3.2 章节的质量特征和上述缺陷的四个层面选取典型问题（业务痛点、高频质量问题）进行计算，以下图 6 为例：
4.2 业务泛化
到综推荐系统的业务特色是多业务线，行业差异大，推荐物料位置多，这折射到质量度量上，我们需要各个层次的聚合分析，进而指导精细化的运营，如下图 7 所示：
到综有很多中低频业务，此时比值的波动受请求绝对值影响较大。针对这些场景，可以聚合部分小流量位，只在行业或者项目层面进行分钟级的监控。
4.3 指标体系
如下图 8 所示，我们将推荐系统响应的一条请求作为一次产品交付行为看待，这些请求中无缺陷的比例，就是推荐系统的质量分，是顶层的质量输出指标。可以根据请求的生命周期，建立一级输入指标，衡量核心流程的质量现状，如召回缺陷率、排序缺陷率等。还可以再将一级指标进一步拆解，得到二级输入指标，比如召回缺陷率比较高时，可以再去衡量召回空值率、召回超时率等。用户的请求还可以根据业务进行垂直、横向、时间维度聚合，得到有业务属性的质量分，这样会更有针对性，更加聚焦。
这套改进后的质量分，以请求为基本单位，相较于最初的可用性计算方式，在一定范围内解决了它的局限性：对缺陷敏感，可以包括数据链路带来的影响，方便进行多业务维度的聚合分析。
4.4 血缘拓展
质量分以请求的粒度统计，在数据应用服务中，请求只是数据对外输出的形式之一。在完成基础的质量分后，请求的生命周期应该延展到数据全链路，这样对质量的度量才完整。这时就依赖数据的血缘关系，将数据表 - 业务系统 - C 端流量关联起来，构建全景的质量画像，如下图 9 所示：
血缘关系是人类社会由婚姻和生育产生的人际关系，如父母和子女的关系、兄弟和姐妹的关系，以及由此派生出的其他亲属关系，数据也可以通过融合、转换产生数据的血缘关系。数据的血缘关系分数据库、数据表、字段不同级别，一般用于数据资产（引用热度计算、理解数据上下文）、数据开发（影响分析、归因分析）、数据治理（链路状态追踪、数仓治理）、数据安全（安全合规检查、标签传播）四个方面。在目前推荐系统质量分的思路下，主要用影响分析去拓展质量分，将所有途径故障节点的请求都打上标记，扣除相应分数。
在推荐系统的业务语义下，我们定义了六种业务元数据：快照、方案、组件、索引、模型、特征，基于元数据我们构建血缘，可以分为任务接入、血缘解析、数据导出。任务接入分为采集模块和入库模块，当任务接入完成后，将通过图数据库存储节点及节点的关系，利用图算法建立血缘。建立血缘之后，节点本身的异常支持系统发现和人工标记，影响分析则可以自动完成。当节点出现异常则进行消息通知，异常信息会沿着血缘传播，继而影响下游环节的质量分计算。
当异常波及到用户端，我们尝试用业务语言重新描述损失。根据到综收入模型，可以计算出各个业务线每个意向 UV 的价值（用户访问商户详情页、团单详情页称之为意向访问），再利用该流量位周同比的访问情况，自动推导业务损失。
5 指标运营
5.1 系统实现
质量分的系统实现方式依赖于埋点和诊断。推荐全链路包含参数输入、召回前置处理、召回、召回后置处理、粗排、精排、重排等多个环节，每个环节都有可能出故障，因此数据采集需要覆盖运行时异常、各环节的关键输入输出信息等。如下图 10 所示，我们通过 Kafka 异步收集埋点数据，然后分场景进行数据处理：生产环境下，近实时 ES 构建索引，提供近 4 天快速查询服务，4 天前的日志入 Hive 归档，另外通过 Flink 引擎解析埋点数据，经过必要的诊断后，实时计算分数并推送告警信息；测试环境下，日志实时分拣至 MySQL，方便测试排查。最后，结构化展示推荐不同阶段的质量情况，提高了结果的可读性。
分数体系的完善需要逐步推进，对于推荐系统，没有推荐结果是最严重的质量问题。我们首先采集和计算的是推荐空结果，对应一级指标里的结果缺陷率、召回缺陷率和二级指标里的结果空值率、召回空值率等。同时由于到综的业务特性，行业众多、供给时空分布不均，大量可交叉的筛选条件也会有空结果，影响质量分的计算。
如何剔除符合业务预期的空结果，消除质量分噪声，在实现埋点的基础上，诊断就变得非常重要。以空结果为例，我们主要从参数诊断、数据诊断、链路诊断三个环节去识别。其中数据诊断指的是当线上筛选条件出现空结果时，回源二次校验底层数据，查询底表数据是否为空。如果底表确实没有相关供给，则沉淀免告警规则，设置免告警有效期，在一段时间内，当前城市当前行业确实缺少相关供给，该空结果不纳入质量分计算。如果底表存在供给，则说明是数据加工或者服务过程中出现了异常，导致无法召回，则再经过链路诊断确定出错环节，纳入相应质量分计算。
如何建立规则匹配机制（即规则引擎）是诊断引擎的关键。当下的规则引擎选择非常多，例如 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 所示），我们基于现有告警二次开发了跟进功能，将特定流量位的告警路由到专属负责人，并记录跟进状态流转，便于及时周知及事后复盘。在运营方面，我们通过数据报表搭建质量分看板，定期回顾不同业务的质量波动情况。
5.3 治理效果
质量分的落地以结果空值率为抓手，按流程拆解采集召回空值率、模型预测空值率、重排算子空值率，并按业务聚合成平台、业务、形态、项目、流量位多个维度。治理动作和成果分为以下几个方面：
通过埋点和诊断，判断当前的空结果是供给问题还是质量问题，排除 98% 的空结果不纳入质量分计算，避免误告警，日均空结果告警数从 40 个降低到 5 个。
基于分析链路过程中各环节的空值率，采取治理措施，包括数据规范（数据分层标准化、标签打标规范）、服务架构（业务隔离、底层数据双介质、降级）、变更规范（配置上线流水线检查、流量回放），将空结果系统发现率保持在 60% 以上。
定制化开发告警路由，避免告警广播，支持标记跟进状态，空结果告警跟进率由无法统计，到核心流量位 100% 跟进。
经过空结果的治理和识别，目前核心流量位空值率为 0.01%，即保证核心流量位 99.99% 的请求有结果，在建设质量分的同时，保证系统发现率和告警跟进率。
5.4 资产沉淀
推荐系统传递的是数据的价值，只有数据被资产化，这种价值才是可持续可增值的。建设推荐系统质量模型的过程，其实也在做数据资产化沉淀。数据在采集后变成资产，一般要满足以下四个条件：可流动、可计量、可管控、可增值，这些在第四章计算方式中都有所涉及。
指标运营的过程，同时也是沉淀质量知识资产的过程。软件缺陷模型究竟如何影响最终的产品交付质量，他们之间是否有相关性、因果性，这种影响是显式地参与分数计算，还是间接影响的。在质量分运营过程中，我们可以逐渐填补脑海中的质量地图，形成指标间、缺陷间、指标和缺陷间的拓扑关系，这是一个将质量资产化的过程。比如通过推荐系统的业务实践，我们发现 80% 的线上故障是由于发布引起的，发布故障中的 80% 又是由于数据发布引起的，这可以指导我们通过治理数据发布减少线上故障。
6 未来规划
我们以可用性为基础，调整计算方式，建立了多层次的推荐系统质量分，并拓展到各种推荐物料、各个业务模块，核心是我们完成了从对外提供服务的“有无”到对外提供服务的“好坏”的认知迭代，这也是质量精细化运营的基础。后续的规划，一方面是继续充实质量模型的计算和链路覆盖；另一方面，我们会基于质量模型做更多的质量治理工作，后续将重点思考与迭代的一些方向包括：
通过完善埋点和诊断，逐步落地质量分体系中的各层指标，丰富质量分的内涵，容纳更多的质量问题。
通过建设多层次的推荐柔性降级，迭代对于质量分的理解，量化不同降级对于系统的影响。
优化数据血缘的准确性、覆盖率和时效性，更加正确快速评估某一个环节质量问题的影响面。
7 本文作者
勇皓、根根、王欣、贺贺、俐聪等，均来自美团到店平台技术部/到综业务数据团队。
「 更多干货，更多收获 」
推荐系统工程师技能树
【免费下载】2022年8月份热门报告盘点
美团大脑系列之：商品知识图谱的构建及应用
【干货】2021社群运营策划方案.pptx大数据驱动的因果建模在滴滴的应用实践
联邦学习在腾讯微视广告投放中的实践如何搭建一个好的指标体系？如何打造标准化的数据治理评估体系？【干货】小米用户画像实践.pdf（附下载链接）
推荐系统解构.pdf（附下载链接）
短视频爆粉表现指南手册.pdf（附下载链接）
推荐系统架构与算法流程详解如何搭建一套个性化推荐系统？某视频APP推荐策略详细拆解（万字长文）关注我们
|
智能推荐 个性化推荐技术与产品社区 |
长按并识别关注
|
一个「在看」，一段时光
猜你喜欢0.淘宝首页猜你喜欢推荐建模实践1.[免费下载]2022年8月份热门报告 2.[实践]小红书推荐中台实践 3.微信视频号实时推荐技术架构分享 4.对比学习在快手推荐系统中的应用实践 5.微博推 ... 「Industry AI Live」是 biendata 的学术直播间,旨在帮助更多的青年学者宣传其最新科研成果.我们一直认为,单向地输出知识并不是一个最好的方式,而有效地反馈和交流可能会让知识的传播 ... 数据猿导读 本文根据美团高级技术专家翟艺涛在2018 QCon全球软件开发大会上的演讲内容整理修改而成.文章分享了深度学习在酒店搜索NLP中的应用,并重点介绍了深度学习排序模型在美团酒店搜索的演进路线 ... 导读:近年来,云原生化.全用户态.软硬协同等技术对KV存储服务产生了巨大的影响,上述技术在极大提升了服务的性能和降低服务成本的同时,也对系统的架构和实现提出了新的要求.百度在信息流和搜索业务中大量使用 ... 本文根据美团高级技术专家翟艺涛在2018 QCon全球软件开发大会上的演讲内容整理而成,内容有修改. 引言 2018年12月31日,美团酒店单日入住间夜突破200万,再次创下行业的新纪录,而酒店搜索在 ... 概述 爱奇艺的信息流推荐业务每天会产生数十亿规模的 feed 浏览,如此大规模的数据给模型训练带来了很大的挑战.同时,信息流这类用户与推荐系统的强交互场景也引入了很多有趣的研究课题.对于信息流推荐产品 ... 本文根据美团高级技术专家翟艺涛在2018 QCon全球软件开发大会上的演讲内容整理而成,内容有修改. 引言 2018年12月31日,美团酒店单日入住间夜突破200万,再次创下行业的新纪录,而酒店搜索在 ... 领域模型之预算上下文 领域模型之费用执行上下文 代码分层架构 实体 聚合根 作者:曹剑 来源:DDD 中国峰会 来自:美团技术团队 业务策略多变导致需求多变,是业界很多技术团队面临的最具挑战的问题之一.那么如何设计一套易于扩展和维护的营销系统呢? 今天的文章来自美团外卖营销技术团队,他们分享了从领域模型到代码工 ...推荐系统在美团综合业务中的应用及实践相关推荐
最新文章
热门文章