天津做一个简单的网站首页,长沙做官方网站,正在建设中网站,重庆网站推广公司京东推荐系统的数据体系极其复杂#xff0c;从召回、模型到策略和效果评估#xff0c;每个环节都需要强大的海量数据处理能力支撑。然而#xff0c;在实际运行中#xff0c;整个数据链路面临着诸多挑战#xff1a;如实时与离线数据的埋点口径不一致、数仓模型存在偏差、计…京东推荐系统的数据体系极其复杂从召回、模型到策略和效果评估每个环节都需要强大的海量数据处理能力支撑。然而在实际运行中整个数据链路面临着诸多挑战如实时与离线数据的埋点口径不一致、数仓模型存在偏差、计算口径不统一等问题都会直接影响推荐效果的优化。更棘手的是由于数据来源多样、体量庞大整个推荐系统的数据质量控制和校验机制往往难以得到有效保障。
京东零售技术专家张颖参与Flink Forward Asia 2024 峰会带来分享《京东零售基于 Flink 的推荐系统智能数据体系》介绍了基于Flink构建的推荐系统数据以及Flink智能体系带来的智能服务功能。
以下是分享实录
01 推荐系统架构 推荐系统通常包含推荐服务这一服务提供了推荐系统的出口基于此接口能够实现多种推荐场景如个性化推荐、热门推荐、新品推荐以及多样化推荐等。此外我们关注的推荐系统的关键模块主要划分三个召回模块、模型粗排、精排、重排等及策略。在召回及策略模块中召回服务的作用是将推荐系统底池数据规模从亿或者百亿级别降低至千万级。
以电商场景为例常见的召回方式包括行为召回、搜索词热门召回以及 I2I 召回等上百路召回。模型主要涉及粗排、精排与重排这三个环节。当然某些特定功能既可以归类到模型服务也可划分至策略模块。至于策略模块其中会涵盖混排相关内容比如搜推混排、推荐与广告混排、搜索与广告混排等。混排过程中可能还涉及 CVR转化率、CTR点击率等多目标排序以及流量扶持等策略。
接下来我们看看推荐系统的智能数据体系构成该体系的数据底层大致由五部分组成分别是索引、特征、样本、可解释性内容以及指标后续将详细阐述每个模块的具体功能。这些数据主要服务于推荐系统的召回、模型、策略等链路进而支持相关场景如常见的搜索、推荐、广告推广以及用户增长场景。
02 索引 2.1 什么是索引 接下来详细介绍京东搜索推荐系统智能数据体系的构成第一个模块为索引主要为召回服务提供数据支持。常见的索引构建流程是从底池数据出发经过索引构建操作将构建完成的索引提供给召回服务。 索引常见类型可划分为三类
(1) 个性化索引这类索引可能涉及特定用户或某类用户的行为足迹或者是基于品类、品牌偏好形成的索引。
(2) 基础索引以京东海量商品为例可将其归纳为基于品类、品牌的索引同时还包括时间、LBS相关的索引。
(3) 策略索引此类型索引可能涉及流量扶持相关策略如冷启动索引、低曝光商品索引等此外还包括兜底索引。 接下来介绍一下什么是索引数据索引数据主要分为正排数据与倒排数据正排数据本质上是将商品的各项属性依次排列这也是大家通常所指的正排形式倒排数据则是依据属性信息把相应的商品作列表作为值进行存储。
2.2 索引架构 下面我们来分析常见的索引架构索引主要由实时索引、增量索引和全量索引三部分构成这三部分在保障索引稳定性方面相互补充。例如若增量索引出现故障实时索引和全量索引可继续维持若实时索引失效增量索引能够发挥作用索引更新频率并非固定为小时级也可以是15分钟级等其他时间粒度。
在索引构建过程中一般从实时链路着手首先从上游 Kafka 消息队列获取相应数据对数据进行解析与去重处理之后可能还需补充属性信息如 SKU 对应的商品品牌及标签属性处理后的数据写入Kafka供下游索引服务读取并构建实时链路索引增量索引通常按小时或者分钟级更新实时索引数据会实时写入 OLAP 在 OLAP 中补齐实时属性比如计算商品前一小时或前五分钟的点击量等完成正排计算后基于正排结果进行倒排计算进而进行构建索引并将数据存储到索引服务中天级增量索引的流程与小时分钟级类似只是涉及的数据范围可能更广。全量索引的更新周期一般为天级、周级或月级等。
03 样本 3.1 样本开发架构 接下来我们探讨样本的整体开发架构其主要分为流式与批式两种方式。
在流式样本开发方面主要操作是将曝光、点击等用户行为数据中的关键信息与特征数据进行关联 Join 关联后的数据向后发送从而形成流式样本。这些流式样本会按小时级或分钟级进行落盘存储如此便生成了增量样本增量样本可用于模型的增量训练。
而批式样本的生成是将用户行为表与特征表进行拼接拼接后即形成批式样本。由于批式样本通常涵盖较长时间跨度的数据因此这类样本又被称为离线样本。在训练模型例如精排模型时仅使用几天或一周的数据往往是不够的通常需要一个月、两个月甚至几年的数据。
在进行流式或增量训练时会基于这个离线样本训练出初始模型Model然后再依据增量数据做进一步拟合Fit。在实时训练过程中则会基于增量模型继续对实时样本进行拟合。
3.2 样本特定场景 我们来分析在样本构建过程中所涉及的各类场景对于离线样本通常会面临样本冷启动以及样本特征回溯的问题而针对实时样本可能遭遇的问题包括延时反馈以及样本采样方法的选择。
3.3 离线样本架构 这里我们主要介绍下离线样本拼接接下来我们看样本的离线架构它与前文提及的架构大致相似主要操作是将用户行为的离线label表与离线特征表进行批式拼接进而生成天级样本表随着日复一日的积累这些天级样本表会形成月级样本以此便可开展全量训练。然而在此过程中会出现一些问题。例如在全新的业务场景下可能初始并无可用样本此时就需要将诸如订单、点击等标签 Label 的计算工作全部重新计算此外完成这部分操作后还可能涉及生成特征Feature 宽表这同样是基于全量数据且以月级为周期的特征处理在进行这些数据计算和关联 Join 操作时对算力的要求极高。
关于特征回溯其操作与上述过程类似即把 FN 1 的新表与已有样本进行关联 Join 。但此过程涉及特征计算需要完整计算新表近一个月或几个月的特征数据并且还需与之前的样本表进行行对齐。需要补充说明的是在进行样本表关联 Join 时必须借助唯一标识组件 ID如 Request ID 来实现对齐如此关联后的样本表才能作为特征回溯的样本表。
3.4 实时样本架构-分阶段窗口 接下来分析实时样本架构它基于分阶段的窗口机制实现。首先从 Kafka 接收用户行为的关键数据经数据解析后与同样经过解析如 PB 解析的特征数据进行拼接在曝光与特征拼接环节尽管这一过程实际速度很快但为确保拼接的成功率我们设置了五分钟的时间窗口也就是说只有当特征成功拼接到曝光数据后数据才会继续向后传递此时间窗口为五分钟随后是曝光与点击的拼接环节该环节时间窗口可设置为十分钟即曝光发生后若十分钟内未产生点击行为相应数据将被视为负样本。再之后是曝光点击样本与加购和下单行为的拼接此环节时间窗口设定为二十分钟。需注意的是五分钟、十分钟和二十分钟这些时间窗口并非固定不变而是可根据具体业务场景灵活配置。例如在结算页场景中用户决策时间相对较短而在搜索或推荐场景下用户考虑时间可能较长。
此外时间窗口还可依据品类和品牌进行针对性配置。以电商场景为例购买食品时用户可能十分钟内就会下单整个链路的时间窗口或许设置为十分钟至二十分钟即可但购买家电时用户考虑时间较长一天可能都不够。当然针对这种情况虽可通过离线方式进行数据回补但我们当前聚焦实时处理期望通过分阶段窗口机制尽可能快速地为模型提供样本。
再来看延时反馈问题。延时反馈本质上是为模型提供三个标签即正标签、负标签以及一个修正标签。当数据到来时先赋予其负标签随后进入等待流程通过判断时间若发现时间已过特定期限确定该数据实际应为正标签但之前发送时可能误判为负标签此时对这部分数据进行修正即修正标签并将其发送至实时样本流中。另外在离线训练时我们能够随意对样本数据进行 Shuffle 操作这样可有效避免因数据不均衡给模型带来的问题。然而实时场景下由于数据是流式传输无法进行 Shuffle。因此我们采用了一种配置策略即将离线处理得到的部分数据与实时数据按一定Mix策略进行混合然后发送至实时样本中。
3.5 实时样本架构-OnlineEvaluation 下面我们来看实时样本的 Online Evaluation 模块该模块主要应用于模型评估场景。实时样本的情况与上页 PPT 结尾部分大致相似但在此过程中会涉及采样策略。在上页 PPT 结尾我们提到将数据全部发送至Kafka而实际操作中我们会对数据进行95%和5%的采样。其中95%的数据用于模型训练5%的数据用于评估Evaluation。 在评估环节又细分为实时评估与离线评估。之所以如此划分是因为离线评估虽然不够实时但实时评估在一定程度上无法起到全面指导的作用实时评估有三种标签。为综合两者优势我们将评估工作分为离线和实时两部分在进行离线评估时只有当模型的 AUC 达到预先配置的数值才会将模型推向线上应用若未达到该数值模型将立即重新进行训练。而在实时评估过程中我们会持续监控模型数据一旦模型准确率下降系统便会马上发出警报同时考虑是否需要对模型进行回滚操作。
接下来我们探讨特征相关内容着重分析整个特征开发过程中的难点。在推荐系统里特征需求极为繁杂这是因为特征开发与模型实验紧密相连、相辅相成且特征开发的逻辑极为复杂。以京东电商场景为例存在用户维度、Item 维度、Session 维度等不同维度的特征同时还包含统计类、序列类等一系列丰富多样的特征类型。此外特征回溯困难正如前文所提及的若要回溯前一个月的特征数据不仅计算量巨大而且所需耗费的时间周期也很长。
04 特征 4.1 实时特征开发架构触发流架构 下面我们来看实时特征开发的架构在我们内部它被称作触发流架构。该架构将数据整体划分为三层
第一层是行为接入层此层主要涵盖各类用户行为的关键数据例如用户在京东 APP 上的曝光、点击、浏览等行为数据这些数据是整个实时特征开发的基础输入记录了用户与平台交互的原始行为信息
第二层是行为补全层。在这一层我们会对前期的数据进行整合与补充。以点击行为为例我们会将近三天的点击数据汇总对于订单行为则会整合近三年的数据从而形成一条完整的行为记录基于这些整合后的数据我们可以计算出诸如点击商品列表、加购商品列表等用户行为数据。从商品角度看我们也能获取商品的相关行为信息比如商品被曝光的次数、被哪些用户曝光等信息可作为衡量商品是否优质的依据例如如果商品的曝光点击率较高通常可认为它是优质商品但倘若其曝光点击率高然而下单率却很低这时就需要深入分析出现这种现象的原因。
第三层是特征挖掘层。这一层基于上面的用户行为层来计算具体的用户/商品特征其中包括统计类特征比如通过获取用户行为list计算近五分钟或近十分钟的点击量通过依据时间维度进行数据筛选与计算确保所得到的数据准确可靠。若某个用户在近五分钟内对某类商品的点击量极高这表明该用户对这个品类具有浓厚的兴趣基于此我们在推荐时就可以考虑向该用户着重推荐该品类下的优质商品。
此外还有用户的序列特征我们将其细分为长期序列和短期序列。由于在第二层已经完成了数据的补齐工作所以在这一层计算长期序列和短期序列特征时就变得相对简便直接基于行为补全层的数据进行计算即可对于商品而言计算逻辑也是类似的。我们已经获取了商品相关的列表和计数信息因此计算商品近五分钟的曝光数、点击数等数据也能快速完成。
在处理用户与商品的交叉特征时无论是用户属性与商品品类的交叉还是用户属性与商品品牌的交叉相较于直接处理原始数据在样本冷启动阶段以及特征调研阶段这种分层架构计算交叉特征的方式都要高效得多。
4.2 特征在离线不一致 穿越解决方案 下面我们来探讨特征方面常见的问题主要包括离线不一致问题以及特征穿越问题同时看看针对这些问题是如何解决的。
首先是在离线不一致问题为确保在线和离线环境下特征的一致性我们采用 SDK 的方式即在线和离线计算均统一使用一套C 的 SDK 来开展特征工程如此一来在线和离线所生成的特征就能保持一致。
接着是特征穿越问题。针对这一问题我们采用 Feature Dump 方案。具体做法是基于埋点数据、用户数据以及商品数据进行特征开发将开发好的特征存储起来以此提供特征服务。在提供特征服务的过程中每当用户请求模型时系统会通过 Feature Dump 进行特征快照将用户当时请求时所涉及的一系列特征完整地记录下来并将这部分特征输入到模型中供其使用从而有效解决特征穿越问题。 此外在提供特征服务时可能会涉及离线样本的特征计算。如果分别使用 C 和 Java 进行计算可能会因精度问题导致特征不一致。而统一使用 C 的 SDK 进行计算就能够避免此类问题的发生。这些计算出的特征一部分用于Predictor一部分则用于生成 Feature 样本的特征。
4.3 特征样本在离线 DIFF 接下来分析特征样本在离线 DIFF问题这在我们内部是一个较为棘手的痛点。 DIFF 本质上可归结为三个方面其一实时与离线数据的口径可能不一致其二实时与离线数据的解析方式或许存在差异其三实时与离线数据的计算过程也不尽相同。
先看前两个方面即如何确保口径与解析的一致性。对于埋点口径和解析逻辑的一致性我们需要将实时和离线数据统一到相同口径具体而言离线数据应完整源自实时数据并且要保证埋点口径、过滤条件等方面完全一致以此解决实时与离线数据的口径一致性问题。在解析环节通过提供统一的 SDK 来实现如此离线和实时就能保证解析算子的逻辑统一。
再谈计算环节实时部分会涉及实时特征与实时样本在进行实时特征计算时我们会将属性特征与序列特征写入特征存储进而提供特征服务在样本场景下由于涉及样本拼接通常是多流拼接的过程以京东场景为例常常需要将用户行为的埋点日志与特征日志进行拼接多的时候可能涉及七八个流此外还需解决超大窗口的问题比如在业务场景中将时间窗口设置为一天以便与离线样本完整拼接。同时样本纠偏和延时反馈等问题也需在计算过程中妥善处理。从工程实现角度要确保在离线计算的一致性这里主要涉及口径与采样问题。就采样而言离线采样和实时采样有所不同。例如离线采样能够计算全局正副样本比例为1:15但实时采样难以做到因为实时数据一旦流过便无法回溯。为此我们采用相对易实现的方案即在实时场景下按照配置比例丢弃副样本在京东场景中副样本通常较多离线场景下同样要保证口径与解析的完全一致。离线场景也会涉及样本与特征的生成如通过 Batch Join 生成离线样本宽表并提供给下游制定样本策略之后供给模型服务。
同时还需关注质量与校验方面。在整个数据体系中特征样本的分布必须保持一致。若某个特征的空值率升高可能意味着在某个阶段出现了问题。另外延时也需保持一致正常情况下特征的延时应在秒级样本的延时为其 Window Size 配置化的秒级。一旦延时增大数据的时效性降低会影响模型效果针对特征样本的 Label DIFF 同样要实现离线与在线的差异监控做到天级或秒级的实时监测确保数据准确无误。所采用的技术手段包括保证数据源算子与解析算子的一致性在多流拼接场景中运用实时 Flink 中的 Union 加Timer 实现同时还涉及大状态的优化以及离线 Join 的优化。
05 可解释 5.1 什么是推荐系统的可解释 接下来我们看看在可解释性方面的工作。首先介绍一下推荐系统可解释性的概念它主要分为三个方面排序可解释、模型可解释以及流量可解释这是我们内部划分的三个研究方向。鉴于今天的分享聚焦于 Flink 所以我们主要探讨与 Flink 相关的排序可解释和流量可解释。
排序可解释其核心在于阐释推荐系统的排序结果。具体做法是详细记录物料从召回到过滤再到排序策略等各个阶段的信息以此作为可解释数据的基础。例如当用户请求一次推荐系统服务时需要记录召回的数据情况包括从哪几路召回、具体召回了哪些数据经过了哪些过滤环节如曝光过滤在粗排和精排过程中输入粗排的特征有哪些、粗排返回了哪些数据、精排又返回了哪些数据以及执行了哪些策略都要详细记录。
模型可解释主要是对推荐系统的模型结果进行解读。在这方面我们重点实现了模型特征的解释即从特征层面剖析模型链路对某些 SKU 得分高低的影响。
流量可解释目前我们还处于建设阶段。它主要是从整体流量的宏观角度也就是站在整个推荐系统的层面来解释商品的差异。例如分析京东为什么会出现商品分层现象以及一些长尾商品被归为长尾的原因究竟是因为未被召回还是在排序过程中排序分数较低从而导致未能获得曝光机会。
5.2 可解释系统架构 下面我们来剖析可解释系统的架构。在可解释系统架构中最左侧是模型可解释的应用这里主要细分为 SKU 特征重要性、用户特征重要性以及全局特征重要性在此不做过多赘述。
重点来看右侧底层的搭建。我们将用户的算法日志以及用户行为数据进行解析与展开处理后写入 ClickHouseCK中。借助CK 强大的功能我们能够进行多维度聚合操作以及针对精细化场景案例的查询。例如分析为何在情人节时系统会向用户推送丧葬用品类的鲜花。 在排序可解释方面主要涉及一些常见场景的分析。比如当用户发现某些商品未得到曝光时通过排查若发现商品未被召回就需要进一步分析是否应增加一路召回途径或者检查某路召回是否出现故障。对于模型而言若某个模型一直表现稳定但突然某项得分持续下降就需判断是否是模型本身出现了问题。针对策略方面要分析策略是否存在问题或者优势体现在何处。还有过滤环节像曝光过滤的设置是否合理等都能通过可解释系统进行深入分析。 流量可解释主要从两个方向展开。其一全域的模型打分问题即分析模型给出的分数是否合理。其二SKU 流量对比的原因分析例如某些 SKU 的流量获取能力较强像新发布的苹果17其流量通常会高于新上架的普通苹果产品这里所举例子虽较为极端但旨在说明问题我们可以从召回、模型、策略、过滤等多个维度全面分析此类问题在这个架构中Flink 发挥了重要作用它实现了数据以天级为单位的 PB 级增长并能做到实时入仓。而 Click House则为我们提供了多维分析的查询功能有效解决了排序可解释分析过程中面临的困难。
5.3 排序可解释 下面进一步详细介绍排序可解释。排序可解释主要由五个模块构成分别是 Trace 链路、Debug 链路、用户画像、商品画像以及行为画像。 在这一过程中 Flink 发挥着关键作用主要承担实时数据 ETL ExtractTransformLoad即数据提取、转换和加载功能。对于数据基石部分我们会在排序服务器上部署 SDK 。该 SDK 能够将日志采集到消息队列中而后续在进行 ETL时则借助 Flink 来实现。值得一提的是通过 Flink 的处理数据能够做到实时入仓且这一过程的延迟时间大约在秒级确保了数据的高效处理与及时存储。
5.4 流量可解释 接下来深入探讨流量可解释。流量可解释大致分为三层架构。最底层是数据采集层主要负责采集埋点数据以及用户行为数据并借助 Flink 实现实时入仓功能确保数据能够及时、高效地存储为后续分析提供基础。
基于底层采集的数据构建上层的流量可解释模块该模块主要涵盖推荐系统整体流量的归因分析例如针对召回、排序、策略等环节进行漏斗分析以此洞察流量在各个关键节点的转化情况。同时还涉及用户行为动线的建设在此需要明确区分用户行为动线与序列数据序列数据通常包含京东平台上的主要用户行为如曝光、点击、下单等可能还包括一些更为精细的行为像点击评论、点击大图等而用户行为动线建设侧重于描绘用户在某一特定周期内的行为轨迹例如用户从一个频道跳转至另一个频道以及在此过程中所执行的一系列动作将这些行为串联起来形成动线为上层应用提供深入分析的依据。借助这些数据可以开展多种业务操作。比如进行跟单操作通过跟踪用户行为来优化业务流程构建用户行为序列为个性化推荐提供更精准的数据支持实施特征回溯以完善模型的特征数据助力样本冷启解决新业务场景下样本不足的问题。不过目前流量可解释模块尚处于建设阶段后续仍需不断完善和优化。
06 指标 下面我们来关注指标方面的内容。在推荐系统里 Flink 主要实现了指标的实时化维度。整个指标体系的构建是先通过 Flink 将埋点数据导入 OLAP 系统基于这些数据我们能够从多个维度展开指标分析例如从实验维度、品牌品类维度等所计算的指标丰富多样涵盖 UCTR、UCVR、GMV、单量以及流动性等关键指标。大家不难发现有些指标单纯依靠 OLAP 进行计算可能会面临困难以典型的 OLAP 系统 Click House 为例当进行多表 Join 操作时其性能会明显下降。所以为了准确且高效地计算各类指标除了 OLAP我们还会借助 Flink 来完成其他指标的计算工作。
推荐系统的数据体系极其复杂索引、样本、特征任何阶段的不一致都会导致推荐系统出现或大或小的case本文从数据在离线一致性、系统可解释性等不同方面解释了这些问题产生的原因和京东的解决方式欢迎一起讨论交流。
