推荐系统是一种信息过滤系统，用于预测用户偏好，从大量的信息中筛选出用户可能感兴趣的内容进行个性化推荐。一个完整的推荐系统流程主要包括了 多路召回 -> 素材补全 -> 精排过滤 -> 混排 ->适配输出 等处理节点。混排作为结果输出前的最后一层处理，主要作用是将不同来源的推荐结果进行归一化的组合排序，一方面是为了获取对于用户推荐效果最优的排序序列，另一方面也能提高推荐的多样性、个性化以及覆盖范围。
淘宝信息流融合混排服务升级
▐ 现有链路
淘宝信息流是一个典型的推荐系统。在信息流中，存在多种类型的业务卡片，如商品，广告、云主题、短视频、直播等。我们会将业务卡片分为广告结果和自然推荐结果两个大类。在排序阶段也会分两个串行的处理模块来对这两种不同类型的结果做混排。
广告结果：广告主要采用了动态坑位展现策略，通过调用广告提供的动态展现服务来决策哪些坑位上出广告、具体展现哪一个广告结果以及对应的广告计费，决策目标是最优商业化价值。决策时会将所有推荐候选集作为上下文特征输入，但是并不会对其中自然结果的顺序作决策。 自然结果：对自然结果的重排过程并不会将广告候选集作为上下文特征来进行决策，同样的，也不会对广告候选集的排序做额外的决策，仅会在自然结果内部做重排，以获取最优用户价值的排序序列。
▐ 存在问题
算法策略目标不一致，无法获取全局最优结果：广告的展现策略更多地从商业化价值出发，对自然结果的用户价值考虑较少，虽然可通过调整两者之间的tradeoff系数实现指标的置换，但是显然并不能得到一个全局最优的序列结果。 算法策略迭代和业务逻辑迭代有较高的耦合：在当前链路中，算法同学需要和工程同学共同开发同一套代码，同时，涉及到的各部分策略模块，又分散在流水线的不同阶段，例如广告动态定坑服务依赖的广告ecpm价值服务会在补全阶段调用，而实际的动态定坑结果则在混排定坑时处理，导致整体系统的复杂度较高，稳定性维护成本较高。
▐ 解决方案
混排策略目标调整：混排服务要能将用户价值和商业化价值综合考虑，以页面的整体价值最大化作为混排策略目标。 策略与业务解耦：将混排策略逻辑从服务端业务链路中抽离出来，作为一个独立的服务接入，后期的迭代升级都由算法同学在新服务中进行维护，将算法的策略迭代和工程链路的业务迭代独立开来，使开发的分工更加明确，降低相应的维护成本。
具体实施方案
▐ 技术选型
本次新增的混排融合服务选择了 xrec 作为代码框架。xrec是一套基于tpp图化引擎的业务框架，该框架主要包括了以下的优点：
推荐业务过程的组件化：xrec框架能够将链路的业务节点抽象为一个个组件，开发者只需要将每个节点的业务按照框架约定的组件实现规范进行实现，并通过一个固定格式的json文件进行流程的编排，不需要在代码层面考虑业务流程的编排。
全异步并发性能优化：和原本工程链路采用的TPE框架流水线式的执行流程不同，xrec框架通过自动化多路并发、封装数据操作来提升场景性能，用图化结构来描述业务过程，让用户无需学习并发编程就可以做到大规模的安全的并发，同时把数据序列化/反序列化、数据转换、常用外部服务调用这些操作封装为算子操作供使用，用性能优化过的平台模块取代未经性能打磨的用户代码。
xrec框架为算法开发同学省去了很多工作量，但同时也对编码规则有了更多的约束，开发过程需要严格按照框架的规则进行。
▐ 链路方案
混排服务链路方案
基于xrec框架，我们搭建了一个独立的TPP服务（xhuffle），用于承接所有广告&自然结果的融合混排策略逻辑。服务整体链路如下所示。xhuffle服务内部会并行调用广告ecpm价值预估服务和推荐统一价值模型，获取广告&自然结果的价值信息，融合混排机制模块会对汇总广告&自然结果价值信息，对所有卡片的排序结果做决策，给定卡片的坑位或对卡片进行重新排序，最终调用广告计费服务，针对广告结果获取广告计费信息。
在原工程链路中，混排依赖的服务模块分散在流水线的不同阶段。新建服务后，混排相关逻辑整合在独立的服务中，都能在新服务中单独迭代，大大减少了开发维护成本。 推荐统一价值模型和广告ecpm预估服务由推荐和广告分别维护，各自负责推荐价值分和广告价值分的获取。 融合混排机制模块由广告和推荐侧共同维护迭代。 广告计费服务由广告侧维护，通过调用广告EADS服务的方式，将广告计费串的生成收敛于广告服务内部，确保信息安全。
另外，由于购中后信息流中还存在部分业务定坑策略，如云主题、短视频定坑等，在原有的混排策略中，并没有考虑到这部分的策略，对于业务定坑所占的坑位，混排策略仍然有可能会决策到，这就导致这些业务定坑的卡片会和混排结果相互干扰，直接影响了业务数据指标。在xhuffle服务中，我们将这部分业务定坑信息也作为服务入参给到混排模块，主动避让开这部分坑位，保证了混排结果和业务定坑结果互不干扰。
工程链路服务调用方案
方案一：拆分排序阶段，并行调用服务
前置排序阶段：该阶段主要进行一些前置的卡片过滤。在获得前置过滤的卡片序列后，发起混排服务和工程链路其他外部服务的并行调用。 后置排序阶段：该阶段会根据混排结果，进行卡片序列的排序截断处理，决定最终需要适配输出的卡片序列。
方案二：串行调用服务
这种调用方式对链路的RT压力会更大，由于是串行执行，服务调用的耗时会直接体现到整体链路耗时上。为了缓解RT的压力，我们采取了以下两个方面的措施：
xhuffle服务本身的链路优化。混排服务中耗时占比最大的是推荐统一价值模型的调用，在最初的方案中是通过调用外部tpp服务进行处理，目前已优化为在服务中直接进行RTP调用来处理，同时调用所需的qinfo数据直接使用商品召回的缓存数据，不用重新生成。
购后工程链路在不影响用户体验的前提下，适当放宽超时限制，以此降低端上的超时率。目前，各场景均将场景超时限制放宽50ms。
两种方案对比
优点 | 缺点 |
并行调用对链路整体的RT影响较小 | 将工程链路其他处理前置，会带来下游服务承接的卡片数量增长三至四倍，带来冗余的资源消耗 |
链路改造成本小，无冗余资源消耗 | 服务耗时会直接体现在链路整体耗时上，对系统稳定性的压力更大 |
经过综合考虑后，我们认为方案一带来的冗余资源消耗是不可接受的，最终选择了方案二作为正式的链路改造方案。
▐ 链路稳定性结果
混排服务场景指标：入口场景的服务调用平均RT保持在30ms以内，P99保持在70ms以内。服务调用超时率稳定在0.5%以内。 入口场景整体的系统稳定性指标：链路整体耗时可控，整体超时率保持在0.3%以内。 端上用户体验指标：由于各场景均扩了超时RT限制，我们通过端上接口的耗时变化来反映对用户体感上的影响。从扩RT前后分端接口耗时来看，用户体感上没有明显的变化。
▐ 未来展望
短视频、直播等业务的混排策略升级，减少业务定坑对混排的约束。 类目打散等规则化策略的融入。 建设通用化的混排服务链路接入方案，以同一套方案为更多场景提供混排策略服务。
这里有巨大的流量，可以满足你对高并发大规模分布式系统练手的畅想；
这里有前沿的算法应用场景，可以玩转各种智能创新；
这里有严苛的系统指标要求，可以让你感受到优化复杂系统化的快感~