1。研发背景1.1我们要解决什么问题？我们期望平台覆盖的三类运营需求如下：(1)突发事件响应：包括但不限于外部不可抗力、互联网热点事件、爆仓等突发事件、搜索&流量等个性化流量推荐场景下，单纯依靠算法模型的学习去适配，在时间上是不被业务方接受的。（2）新品/新人数据缺乏：在扶持新品和留住新人方面，新品召回困难，个性化分数低导致排名低无法曝光，缺乏新人画像会也会影响推荐效果。因此，当需要频繁调整新品权重和新人定向投放时，往往需要人工更改。(3)平台内的实验性/探索性项目：如品类价格带分布控制，一些探索性、尝试性的实验，需要推送指定流量小的产品进行实验，在获得一定的结果和经验后，进行优化推广，ETC。。需要从圈出的产品、圈出的人、AB实验、数据市场等多角度分析；策略打法的频繁调整也需要技术端的迭代升级。1.2为什么要做平台？在不搭建平台的情况下，我们也快速实现业务端的诉求，比如高UE产品权重和价格力产品支持。其方法一般是通过在召回引擎中对产品进行标记，在上游系统中识别出复合服务请求的定向投放规则中，对标记的项进行加权。同时统计埋点数据，评估产品实验组与基准对照组的差异，确保支持满足业务预期。平台化之所以在初期投入大量的研发成本，主要是以下两点：（1）研发&时间成本：每一个策略的加入都需要识别指定的流量，从产品标记到引擎、在线链接、算法赋权、实时数据反馈、离线数据报表等环节迭代，需要BI、enginedump、recalllayer、预测算法、实时数仓等团队总共投入至少10~12人天的研发资源。同时，PMO，各团队的leader和PM等Indirectinput，项目联调，测试资源，线上变更CR等都会累加起来。（2）多场景问题：不同场景的重复建设也会带来成本的增加。我不会在这里详细介绍。更何况，同一个用户在不同的场景下，有着自己的分配规律。如何统一进行AB实验和数据统计分析也存在一定的问题。产品权重的一部分必然会挤出其他产品的自然曝光流量，而这部分被挤占的流量就是我们的运营成本。如何评估每个场景的ROI，当效果不理想时如何停止对单个场景的投入，如何恢复场景的资源投入，也是我们需要面对的问题。1.3我们如何做？以上三类问题其实可以统一抽象为：用户可以随时选择一个产品集合，并进行一定的支持（权重、维护等（体量、曝光率、扩容等））。我们将实现该能力的系统大致分为5个模块，如下图所示：（1）流量运营中心：支持运营同学自由配置策略、变更产品集、调整投放条件、完成审批流程、审核报告等，等待运营操作；策略的增加和改变不再需要长时间等待需求调度和研发周期。(2)流量服务中心：用于匹配运营配置的流量规则与线上请求，同时负责系列算法的中控、产品召回的监管、埋点的上报、灾害恢复和限流等，是链路调节的枢纽。(3)数据计算中心：主要负责两部分。一是将运营配置的产品合集、站内基础数据、产品增量目标完成情况等线下数据更新至搜索引擎。另一部分是线上链路的分钟级统计实时数据，将产品的子实验、子策略、子场景的实时累计数据同步到算法中控，使决策，是搜索引擎实时更新召回过滤条件的依据。（4）流量算法中控：控制环节召回的产品需要中控根据产品特性、用户画像、预估分数、目标达成进度和增长率等因素进行实时调整。平滑控制和过度熔断等职责是整个监管系统的大脑。(5)配套设施：围绕稳定性、问题定位效率等角度建设的基础设施，不再详述。技术链接在下面展开。2.技术环节2.1业务架构：经过2022年Q4季度的研发工作，目前的场景已经涵盖了交易搜索和部分推荐场景。线上支撑业务策略包括：新品保量、高UE产品权重、猎奇产品重复曝光/降低曝光率等业务需求。同时，为接入更多个性化流量渠道，监管还完成了非文本个性化多渠道召回等通用能力建设。基本完成总报表、审批流程、运营后台变更历史对比等基础建设。2.2工程环节：蓝框为2022年Q4新建，白框为Q3季度竣工功能。离线数据按小时更新到引擎后，整个系统的请求从左上场景进入，携带文本查询或用户特征触发器来到控制服务器，控制服务器将requestInfo与流控操作后台推送的计划列表（对于某些请求，将一组商品抽象成一个计划）列表。根据有效策略ID构造查询以调用规则引擎。召回结果与算法的中控输出(控制方式、强度)结合，向上游进行重新排序的细排序结果。同时，需要上游协助埋点的信息也同步上盘。实时数仓采集埋点后，根据相应的规则进行计算，反馈给中控和实时更新控制引擎。controlserver内部职责如下：各handler负责有效策略识别、召回策略分发、退出机制、AB分桶、埋点结构实时计算、调用算法中控等，具体实现将不被扩大。基于搜神自研引擎的流控召回逻辑：流控引擎目前支持搜索场景的文本召回和推荐的X2i召回。trigger->product、底层数据和自然召回之间的映射关系是一致的，候选集也是搜索和推送场景召回候选集的真实子集，可以保证关联分层、真假暴露的逻辑过滤等与每个场景对齐；品类预测、品号识别复用QP结果、推荐触发和用户行为序列也复用Upstream结果，所以单独的监管召回环节不会造成体验问题。另外，对于保量型新品的管控，我们借助Sogos自研的扩展能力，定制了目标达成过滤filter和优先级低于相关性的排序插件。发动机，在一定程度上缓解了罕见的新品召回问题。2.3其他模块：2.3.1实时数据：中控的平滑控制，实现目标的熔断机制，引擎排序/过滤插件依赖的实时数据如下：Tag名称描述，限额处理逻辑，光伏产品粒度有效调控，干预曝光，每日0点累计key为[planId_scenario_cspuId]，值为今日干预累计曝光（0点下线后归0每天点钟）。有效控制PV场景的粒度。key是[planId_scenario]，区分社区搜索和交易搜索，value是今天干预的累计曝光（每天0:00下线后归0），=所有item干预曝光和plandimensions有效控制PV运营计划粒度介入曝光每日0点累计，所有场景的曝光根据planid求和，key为[planId]，value为今日干预累计曝光（跌后归0每天0点下线），=所有项目干预曝光和子场景监管产品PV场景干预曝光在每天0:00累加，监管产品干预曝光的总keysceneis[planId_scenario_experimentalbucket]值是今天干预的累计曝光（每天0:00下线后归0），=item干预在odpstableExposure和plandimensioncontrolPV跨场景plan维度介入曝光，每天0点累加，所有场景控制项的曝光量根据planid求和。每天0:00返回0),=每天0:00累加所有项目和全站产品子场景PV场景介入曝光，介入曝光的sumkey场景中所有商品的为[planId_scenario_experimentalbucket_total]，区分搜索和推荐，value为今天干预的累计曝光（每天0:00下线后归0），=项目干预曝光在每天0:00全站商品指定流量下的odps表和PV运营计划粒度介入曝光累计，所有场景下所有产品的曝光按照planid求和。key为[planId_experimentalbucket_total]，值为item在今日odps表中累计曝光（每天0:00下线后归0），=所有item干预曝光和千川实时圈productpvplanId_scenario_experimentalbucket每个控制策略分实验控制不同场景的产品曝光数据，从0到24点累加，acm埋点得到planid：cstpl_1-2-3（1,2,3为planId），调整kafka获取实验桶，通过requestid关联千川实时圈产品子实验pvplanId_experimental桶，每个控制策略全渠道子实验控制产品曝光数据控制产品曝光总和，0-24积分积累，acm埋点获取planId：cstpl_1-2-3（1、2、3为planId），调整kafka获取实验桶，通过requestid关联全站产品子实验PVplanId_scenario_experimentalbucket_total覆盖各个控件strategy流量中，所有产品展示所有item的曝光总和，0-24点累加，根据曝光埋点统计，调整kafka得到实验桶和planId，关联全站产品子实验PV交叉-通过requestid进行场景子实验暴露。各控制策略覆盖流量中，所有产品在所有渠道的表现和所有item的曝光总和，0-24点累加，根据曝光埋点统计，调整kafka得到实验桶和planId，并关联以上指标根据客户端上报的埋点和服务requestid终端日志kafaka和odps维表由实时数仓团队计算。计算逻辑简化如下：2.3.2效果数据：产品效率报告，指的是实验组和对照组产品表现的绝对值和相对值差异，涵盖曝光、点击、交易、qvctr、cvr、pv值等指标。一个控制策略（方案）对这批产品的影响需要限定在受控产品，流量也必须在指定的场景、人群特征、实验、品类等。这部分不难理解项目等条件下的效率报告。AB实验导流，控制服务器承接各种来源的请求，统一二层正交AB，控制分层实验组控制组逻辑如下：a．独立实验i.对照组：独立实验对照组（固定）ii．实验组：策略（plan）配置的实验组，根据每个策略的配置确定b．公开实验（公开实验中一个流量组可以叠加多个实验，根据不同的产品范围查看每个实验对产品维度的影响）：i.对照组：公共实验对照组（固定）ii．实验组：策略（计划）配置的实验组。根据每个策略的配置，BI团队可以给出一些新产品的支持策略（方案）以可观察报表为例，类似如下：实时+离线的数据链路最终服务于监管引擎和算法中控2.3.3算法中控：为了满足量化目标的需求，算法中控依赖于实时反馈数据。PID计算逻辑如下：排序基础score=rs*weight+correlationscoreorscore=rs*pctr/median(pctr)*weight+correlationscoreweight=1+pid_score,weightinterval[0.1,10]pid_score=(当前目标曝光-当前累计曝光）/当前目标曝光*KI当前目标曝光=计划目标*当前时间曝光比例曝光比例类型的比例控制要求略有不同：当比例低于目标时，支持：当ratioishighSuppressionattarget:3.值得一提的是3.1借鉴广告系统的独立召回环节对比之前的工作经验和其他平台的研究成果，类似广告系统的独立召回环节有具有以下特点：（1）在新品支持等领域，依赖自然召回后判断是否为管制品的逻辑，没有特别好的解决方案“难以回忆”的问题。排的暴力干预、白名单上限和关联性差等问题都没有解决。在自主召回环节，我们自然将锅仅限于监管产品。如果关联层满足要求，监管产品的位置就不会被非监管产品占据。同时，依托搜神自研引擎定制的完成率逻辑，也可以避免部分监管产品挤占其他监管产品流量的问题。Online其实可以保证99%的新品都能获得监管带来的有效增量曝光（曝光位置超前），同时保证数量的整体目标达成率也能满足业务需求（2）判断incrementalexposure更准确：自然没有recall，只有regulation才有recall的概念，可以帮助我们判断无论这个产品的坑位有没有变化，onlyregulationlinkrecall一定是incrementalexposure。有利于继续推进基于运营集团预算管理的后台系统。(3)与后置过滤相比，前置过滤可以在有限的召回量内给其他产品更多的机会。（4）负向存在一定缺陷，独立链条召回数小于整体召回数，会导致抑制效果下降。这一点比较专业的是防作弊平台和风控系统的黑名单直接对接商品锅。3.2跨场景统一AB实验每个场景、每个服务独立接入AB平台，相互隔离，哈希规则也是自定义的。后续我们期待在多场景的联合调控中，增量目标的分配比例可以动态自动优化分配，同时恢复各个场景的ROI指标。熟悉该报告的同学可以看到，即使是去万三高客榜后的AB数据，在同一实验组多次实验的情况下，指标还是有差异的。独立统一调控和正交分层可以保证无论是搜索还是推荐的是同一个用户，命中的实验或策略都是一样的，联合调控可以以此分层数据为参考。4、后续方向（1）提升平台能力：基础能力建设，包括悦悦组件接入，打通圈产品集合信息，实现一站式圈产品和圈产品规则维护；接入众规平台，简化线上ServiceFeatureCondition的判别过程管控平台运营中心易用性和用户体验建设工作，从数据分析、跨平台信息对接、gadgets、冗余操作去除和预警通知等打磨产品，从“好用”到“好用”的长期目标后台添加配置中心，配置可视化方舟，降低复杂json的变更成本；后期实现一键降级等功能；增加debug工具，测试线上系统召回，权重是否达到预期，提高debug和线上问题定位效率，异常熔断机制完善，异常通知可以传达给业主和运维负责人，效果可以评估异常损失。(2)非商品监管能力建设：阴影词&搜索发现词、搜索框下拉推荐词等导购词场景覆盖，结合查询直达，可以通过更低成本的方式支持特定商品的业务支持社区-成本场景内容是得物的核心场景，目前社区内容中的商品标签和动态详情页商品卡片，建立了良好的内容引导交易机制。提醒等方向都有探索的空间和价值，期待未来探索社区&交易联合监管的落地场景。（3）支持场景扩展：支持更多推荐场景，未来有望在品牌落地页、分类标签等场景进行实验，探索不同类型商品在不同场景下的最优ROI方案。探索跨场景联控能力、跨场景目标配置、产品质量预估与评价、跨场景核心指标对接；帮助业务方在人货精细化匹配探索中取得成果。
