淘宝信息流融合混排服务升级

推荐系统是一种信息过滤系统，用于预测用户偏好，从大量的信息中筛选出用户可能感兴趣的内容进行个性化推荐。一个完整的推荐系统流程主要包括了多路召回 -> 素材补全 -> 精排过滤 -> 混排 ->适配输出等处理节点。混排作为结果输出前的最后一层处理，主要作用是将不同来源的推荐结果进行归一化的组合排序，一方面是为了获取对于用户推荐效果最优的排序序列，另一方面也能提高推荐的多样性、个性化以及覆盖范围。

技术链路现状

▐ 现有链路

淘宝信息流是一个典型的推荐系统。在信息流中，存在多种类型的业务卡片，如商品，广告、云主题、短视频、直播等。我们会将业务卡片分为广告结果和自然推荐结果两个大类。在排序阶段也会分两个串行的处理模块来对这两种不同类型的结果做混排。

购中后信息流混排流程示意

广告结果：广告主要采用了动态坑位展现策略，通过调用广告提供的动态展现服务来决策哪些坑位上出广告、具体展现哪一个广告结果以及对应的广告计费，决策目标是最优商业化价值。决策时会将所有推荐候选集作为上下文特征输入，但是并不会对其中自然结果的顺序作决策。
自然结果：对自然结果的重排过程并不会将广告候选集作为上下文特征来进行决策，同样的，也不会对广告候选集的排序做额外的决策，仅会在自然结果内部做重排，以获取最优用户价值的排序序列。

最终输出的结果序列中，会优先将广告结果安排到动态展现服务决策好的坑位上，剩下空出的坑位才会展示其他的自然推荐结果。

▐ 存在问题

算法策略目标不一致，无法获取全局最优结果：广告的展现策略更多地从商业化价值出发，对自然结果的用户价值考虑较少，虽然可通过调整两者之间的tradeoff系数实现指标的置换，但是显然并不能得到一个全局最优的序列结果。
算法策略迭代和业务逻辑迭代有较高的耦合：在当前链路中，算法同学需要和工程同学共同开发同一套代码，同时，涉及到的各部分策略模块，又分散在流水线的不同阶段，例如广告动态定坑服务依赖的广告ecpm价值服务会在补全阶段调用，而实际的动态定坑结果则在混排定坑时处理，导致整体系统的复杂度较高，稳定性维护成本较高。

▐ 解决方案

基于上述一些问题，我们希望对当前的混排策略服务进行统一化升级，升级后的服务应有以下特点：

混排策略目标调整：混排服务要能将用户价值和商业化价值综合考虑，以页面的整体价值最大化作为混排策略目标。
策略与业务解耦：将混排策略逻辑从服务端业务链路中抽离出来，作为一个独立的服务接入，后期的迭代升级都由算法同学在新服务中进行维护，将算法的策略迭代和工程链路的业务迭代独立开来，使开发的分工更加明确，降低相应的维护成本。

具体实施方案

▐ 技术选型

扫描二维码关注公众号，回复： 17378755 查看本文章

本次新增的混排融合服务选择了 xrec 作为代码框架。xrec是一套基于tpp图化引擎的业务框架，该框架主要包括了以下的优点：

推荐业务过程的组件化：xrec框架能够将链路的业务节点抽象为一个个组件，开发者只需要将每个节点的业务按照框架约定的组件实现规范进行实现，并通过一个固定格式的json文件进行流程的编排，不需要在代码层面考虑业务流程的编排。
全异步并发性能优化：和原本工程链路采用的TPE框架流水线式的执行流程不同，xrec框架通过自动化多路并发、封装数据操作来提升场景性能，用图化结构来描述业务过程，让用户无需学习并发编程就可以做到大规模的安全的并发，同时把数据序列化/反序列化、数据转换、常用外部服务调用这些操作封装为算子操作供使用，用性能优化过的平台模块取代未经性能打磨的用户代码。

xrec框架为算法开发同学省去了很多工作量，但同时也对编码规则有了更多的约束，开发过程需要严格按照框架的规则进行。

▐ 链路方案

混排服务链路方案

基于xrec框架，我们搭建了一个独立的TPP服务（xhuffle），用于承接所有广告&自然结果的融合混排策略逻辑。服务整体链路如下所示。xhuffle服务内部会并行调用广告ecpm价值预估服务和推荐统一价值模型，获取广告&自然结果的价值信息，融合混排机制模块会对汇总广告&自然结果价值信息，对所有卡片的排序结果做决策，给定卡片的坑位或对卡片进行重新排序，最终调用广告计费服务，针对广告结果获取广告计费信息。

在原工程链路中，混排依赖的服务模块分散在流水线的不同阶段。新建服务后，混排相关逻辑整合在独立的服务中，都能在新服务中单独迭代，大大减少了开发维护成本。
推荐统一价值模型和广告ecpm预估服务由推荐和广告分别维护，各自负责推荐价值分和广告价值分的获取。
融合混排机制模块由广告和推荐侧共同维护迭代。
广告计费服务由广告侧维护，通过调用广告EADS服务的方式，将广告计费串的生成收敛于广告服务内部，确保信息安全。

xhuffle服务整体链路示意

另外，由于购中后信息流中还存在部分业务定坑策略，如云主题、短视频定坑等，在原有的混排策略中，并没有考虑到这部分的策略，对于业务定坑所占的坑位，混排策略仍然有可能会决策到，这就导致这些业务定坑的卡片会和混排结果相互干扰，直接影响了业务数据指标。在xhuffle服务中，我们将这部分业务定坑信息也作为服务入参给到混排模块，主动避让开这部分坑位，保证了混排结果和业务定坑结果互不干扰。

工程链路服务调用方案

在引入xhuffle服务后，服务调用的时机是上游工程链路重点关注的问题。基本思路是在排序阶段前置过滤完成后，调用xhuffle服务，对前置过滤后的广告&自然结果候选集做决策，然后根据混排结果决定最终输出的卡片序列。这样一方面可以避免了对已过滤的卡片做决策，提高了坑位的利用率；另一方面也减少了候选集的数量，可以一定程度上减轻服务的压力。

在这里，我们提出了两种链路调用方案。

方案一：拆分排序阶段，并行调用服务

由于现有链路在排序阶段是串行执行的，考虑到新增了一个外部服务调用，在方案一中，我们将排序阶段拆分成了两个阶段：

前置排序阶段：该阶段主要进行一些前置的卡片过滤。在获得前置过滤的卡片序列后，发起混排服务和工程链路其他外部服务的并行调用。
后置排序阶段：该阶段会根据混排结果，进行卡片序列的排序截断处理，决定最终需要适配输出的卡片序列。

方案一工程链路示意

这种并行调用的方式看似减轻了链路RT的压力，实际上引入了一个新的问题。排序阶段输入的候选集序列大小一般是数倍于最终排序输出的序列大小，例如在购物车场景，每次请求最终返回的卡片序列数量为20，而排序阶段输入的卡片序列数量一般可达到100。在原有链路中，工程链路其他处理过程只会承接最终确认好顺序的20张卡片。如果将这部分处理前置，即使经过了前置过滤，这部分的服务实际承接的卡片序列数量还是将增长三至四倍，无形中加重了下游服务的压力。

在这部分外部服务中，UMP导购券后价接口的问题比较突出，这主要是因为UMP接口限制了接口一次调用承接的卡片数量不能超过15个，超出数量限制就需要分批发起多次调用，原本承接20张卡片就需要发起两次调用。如果承接的卡片数量增多，那么会直接增加对下游服务的请求量。

在前期小流量验证阶段，我们发现在实验流量上，对UMP服务接口的调用QPS增长了约3倍左右，这一现象也符合我们上述对该方案的分析。在小流量实验上并不能暴露出QPS增长带来的具体问题，但是如果采用这种方案进行推全，全量后下游的UMP接口将承载入口流量六至八倍的流量，压力实在太大，并且最终输出的卡片序列数量并没有增多，这部分新增的资源消耗并不是有效消耗，而是冗余消耗。

方案二：串行调用服务

考虑到上述方案带来的冗余资源消耗问题，我们提出了第二种链路调用方案，将xhuffle服务作为整体排序阶段的一个串行模块，在前置过滤完成后，直接串行执行服务调用。

方案二工程链路示意

这种调用方式对链路的RT压力会更大，由于是串行执行，服务调用的耗时会直接体现到整体链路耗时上。为了缓解RT的压力，我们采取了以下两个方面的措施：

xhuffle服务本身的链路优化。混排服务中耗时占比最大的是推荐统一价值模型的调用，在最初的方案中是通过调用外部tpp服务进行处理，目前已优化为在服务中直接进行RTP调用来处理，同时调用所需的qinfo数据直接使用商品召回的缓存数据，不用重新生成。
购后工程链路在不影响用户体验的前提下，适当放宽超时限制，以此降低端上的超时率。目前，各场景均将场景超时限制放宽50ms。

两种方案对比

优点	缺点
并行调用对链路整体的RT影响较小	将工程链路其他处理前置，会带来下游服务承接的卡片数量增长三至四倍，带来冗余的资源消耗
链路改造成本小，无冗余资源消耗	服务耗时会直接体现在链路整体耗时上，对系统稳定性的压力更大

经过综合考虑后，我们认为方案一带来的冗余资源消耗是不可接受的，最终选择了方案二作为正式的链路改造方案。

总结与展望

在进行上述的链路改造后，xhuffle服务已在购中后信息流推全，好价版信息流正在逐步接入中。经过一系列优化迭代，目前的xhuffle服务在保证了系统稳定性前提下，取得了自然&广告双涨的结果。

▐ 链路稳定性结果

混排服务场景指标：入口场景的服务调用平均RT保持在30ms以内，P99保持在70ms以内。服务调用超时率稳定在0.5%以内。
入口场景整体的系统稳定性指标：链路整体耗时可控，整体超时率保持在0.3%以内。
端上用户体验指标：由于各场景均扩了超时RT限制，我们通过端上接口的耗时变化来反映对用户体感上的影响。从扩RT前后分端接口耗时来看，用户体感上没有明显的变化。

▐ 未来展望

短视频、直播等业务的混排策略升级，减少业务定坑对混排的约束。
类目打散等规则化策略的融入。
建设通用化的混排服务链路接入方案，以同一套方案为更多场景提供混排策略服务。

网络包传输

淘天集团首页&信息流技术-首页团队，目前负责集团电商平台的首页和信息流推荐，其中手机淘宝首页、信息流、NewDetail等场景每天服务数亿用户，大促核心系统峰值QPS千万计，工作涉及全链路端到端性能优化，流量效率提升、用户体验、提高商家及达人参与淘宝的积极性，优化商业生态运行机制。在过去的几年时间，我们一直专注手机淘宝首页、推荐信息流核心链路业务支持和业务平台抽象，与业界领先的算法团队紧密协作，不断拓展业务边界并将核心业务指标一次次踩在脚下。
这里有巨大的流量，可以满足你对高并发大规模分布式系统练手的畅想；
这里有前沿的算法应用场景，可以玩转各种智能创新；
这里有严苛的系统指标要求，可以让你感受到优化复杂系统化的快感~

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法

本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。