1、研发背景
1.1 我们想要解决什么问题？
我们期望平台能够覆盖的三类运营诉求如下：
（1）突发事件的应对：包括不限于外部的不可抗力影响，网络上的热点事件、爆仓等突发事件，在搜索&推荐等个性化流量场景下，单纯依靠算法模型的学习来适应，时间上不被业务方接受。
（2）新品/新人等缺少数据的情况：在扶持新品、留存新人等问题上，新品召回难、个性化分数低导致排名靠后无法曝光，而新人缺少画像也会对推荐效果造成影响。因此对于新品的加权、新人定向投放需要频繁调整的情况，往往需要人工进行变更。
（3）平台的实验/探索项目：如品类价格带分布控制，一些探索尝试性的实验，需要先小流量定向推送指定商品进行实验，取得一定结果、经验后，再进行优化、推全等情况。需要在圈品、圈人、AB实验、数据大盘等多角度进行分析；频繁的调整策略打法，也需要技术侧进行迭代升级。
1.2 为什么要做成平台？
不搭建平台，我们也快速地落地过高UE商品加权、价格力商品扶持等业务方诉求，做法一般是通过对召回引擎中的商品打上标记，在上游系统识别到某次请求复合业务的定向投放规则时，对有标记的商品进行加权。同时统计埋点数据，评估商品实验组与基准对照组的diff，确保扶持的力度符合业务预期。而平台化在初期投入大量研发成本的原因主要是针对以下两点：
（1）研发&时间成本：每个策略的新增都需要从商品打标到引擎，在线链路对指定流量的判别、算法加权、实时数据反馈、离线数据报表等环节进行迭代，需要BI、引擎dump、召回层、预估算法、实时数仓等多个团队投入合计至少10~12人日的研发资源，同时PMO、各团队leader及PM、项目联调、测试资源、线上变更CR等间接投入也会积少成多。
（2）多场景问题：不同场景重复建设也会带来成本的增加不再赘述，更多的是相同的用户在不同场景有各自的分流规则，如何统一的进行AB实验和数据统计分析也存在着一定问题。一部分商品加权也必然会挤占其他商品自然曝光的流量，这部分被挤占的流量是我们的运营成本。如何评估各场景的ROI，在单个场景效果不尽如人意的情况停止投放如何复盘该场景的资源投入，也是我们需要面对的问题。
1.3我们是怎么做的？
上述的三类问题其实可以统一抽象为：用户随时可以选择一个商品集，在指定的流量下(人群标签、query类目、品牌、AB实验分组、时间段等)进行某项扶持（加权、保量、曝光占比、按比例提升等）。我们大体将实现该能力的系统划分为5个模块，如下图所示：
（1）流量运营中心：支持运营同学自由配置策略，更换商品集、调整投放条件、完整的审批流程、报表的查阅等等运营操作；策略的新增及变更不再需要需求排期和研发周期的漫长等待。
（2）流量服务中心：用于将运营配置的流量规则与在线请求做匹配，同时负责串联算法中控、调控商品召回、埋点上报、容灾限流等工作，是调控链路的枢纽。
（3）数据计算中心：主要是两部分职责，其一是将运营配置的商品集、站内基础数据，商品增量目标完成情况等离线数据全量更新至搜索引擎。另一部分则是在线链路的分钟级统计实时数据，商品的分实验、分策略、分场景实时累计数据同步给算法中控做决策，及搜索引擎实时更新召回过滤条件的依据。
（4）流量算法中控：调控链路召回的商品需要由中控根据商品特征、用户画像、预估分、目标达成进度及增长速度等系数，实时调整每个被调控品的调控力度，负责平滑控制和过量熔断等职责，是整个调控系统的大脑。
（5）保障设施：围绕着稳定性、问题定位效率等角度建设的基础设施，不做赘述。
下面对技术链路进行展开。
2、技术链路
2.1 业务架构：
经过2022 Q4季度的研发工作，当前场景已经覆盖了交易搜索及部分推荐场景。线上支持业务策略包括：新品保量、高UE商品加权、重复曝光/猎奇商品曝光比例下调等业务诉求。同时调控为了更多个性化流量通道的接入也完成了非文本个性化多路召回等通用能力的建设工作。运营后台的通用报表、审批流程、变更历史对比等能力基本建设完成。
2.2 工程链路：
· 蓝色框为新2022 Q4建设，白色框为Q3季度已完成功能
当离线数据小时级更新至引擎后，整个系统的request从左上方各场景进入，携带文本query或用户特征trigger来到调控server，调控server将根据requestInfo与流控运营后台推送的plan（针对某些请求调控某商品集抽象为一个plan） list进行匹配。结合生效的策略ID构建query进行调控引擎召回。召回结果配合算法中控产出<action, weight> (调控方式，力度)，给到上游对精排结果进行重排序，同时需要上游协助埋点的信息也同步落盘。实时数仓采集埋点后按照相应规则进行计算，反馈给中控及实时update调控引擎。
调控server内部职责如下：
各handler分别负责生效策略判别、召回策略分发，退场兜底机制、AB分桶、实时计算埋点构造，调用算法中控等，详细实现不做展开。
基于搜神自研引擎的流控召回逻辑：
流控引擎当前支持面向搜索场景的文本召回及面向推荐的X2i两类召回，trigger -> 商品的映射关系、底层数据与自然召回保持一致，候选集也是搜推场景召回候选集的真子集，可以确保相关性分层、真假曝光过滤等逻辑与各场景对齐；类目预测、货号识别复用QP结果，推荐trigger和用户行为序列也是复用的上游结果，因此单独的调控召回链路并不会导致体验问题。
另外针对于保量类型的新品调控，我们借助搜神自研引擎的扩展能力，定制了目标达成过滤filter以及优先级低于相关性的sort插件，一定程度上缓解了新品召回难得问题。
2.3 其他模块：
2.3.1 实时数据：
中控的平滑控制、目标达成熔断机制以及引擎sort/filter插件依赖的实时数据如下：
标签名 | 描述 | 限制 | 处理逻辑 |
有效调控pv | 商品粒度干预曝光 | 每日0点累计 | key为[planId_场景_cspuId]，value为今日干预曝光累计(每天0点落离线后归0) |
分场景有效调控PV | 场景粒度干预曝光 | 每日0点累计，场景内所有商品的干预曝光求和 | key为[planId_场景]，区分社区搜索、交易搜索，value为今日干预曝光累计(每天0点落离线后归0)，=所有item干预曝光和 |
计划维度有效调控PV | 运营计划粒度干预曝光 | 每日0点累计，所有场景下的曝光按照计划id求和 | key为[planId]，value为今日干预曝光累计(每天0点落离线后归0)，=所有item干预曝光和 |
分场景调控品PV | 场景干预曝光 | 每日0点累计，场景内调控商品的干预曝光求和 | key为[planId_场景_实验桶] value为今日干预曝光累计(每天0点落离线后归0)，=odps表中的item干预曝光和 |
计划维度调控PV | 跨场景计划维度干预曝光 | 每日0点累计，所有场景下的调控品曝光按照计划id求和 | key为[planId_实验桶]，value为今日odps表中的item曝光累计(每天0点落离线后归0)，=所有item干预曝光和 |
全站商品分场景PV | 场景干预曝光 | 每日0点累计，场景内所有商品的干预曝光求和 | key为[planId_场景_实验桶_total]，区分搜索、推荐，value为今日干预曝光累计(每天0点落离线后归0)，=odps表中的item干预曝光和 |
全站商品指定流量下PV | 运营计划粒度干预曝光 | 每日0点累计，所有场景下所有商品的曝光按照计划id求和 | key为[planId_实验桶_total]，value为今日odps表中的item曝光累计(每天0点落离线后归0)，=所有item干预曝光和 |
千川实时圈品pv | planId_场景_实验桶 | 各调控策略在不同场景分实验调控商品曝光数据 | 调控品曝光和，0-24点累计，acm埋点得到planid：cstpl_1-2-3 (1,2,3为planId)，调控kafka得到实验桶，通过requestid关联 |
千川实时圈品分实验pv | planId_实验桶 | 各调控策略全通道分实验调控商品曝光数据 | 调控品曝光和，0-24点累计，acm埋点得到planId：cstpl_1-2-3 (1,2,3为planId)，调控kafka得到实验桶，通过requestid关联 |
全站商品分实验PV | planId_场景_实验桶_total | 各调控策略覆盖的流量中，所有商品表现 | 所有item曝光和，0-24点累计，根据曝光埋点统计，调控kafka得到实验桶和planId，通过requestid关联 |
全站商品分实验PV | 跨场景分实验曝光 | 各调控策略覆盖的流量中，所有商品在所以通道的表现 | 所有item曝光和，0-24点累计，根据曝光埋点统计，调控kafka得到实验桶和planId，通过requestid关联 |
以上指标基于客户端上报的埋点、服务端日志kafaka、odps维表经实时数仓团队计算所得，计算逻辑简化如下：
2.3.2 效果数据：
商品效率报表，指商品在实验组对照组的表现的绝对值、相对值差异，涵盖曝光、点击、成交、qvctr、cvr，pv 价值等指标。某个调控策略(plan)对这一批商品的影响则需要限制商品是被调控品，流量也必须是在指定的场景、人群特征、实验、类目等条件下的效率报表，这部分不难理解。
AB实验分流，由调控server承接各个来源的请求，并进行统一两层正交AB，调控分层实验组对照组逻辑如下：
a. 独立实验
- i. 对照组：独立实验对照组（固定）
- ii. 实验组：策略(plan)配置的实验组，根据每个策略的配置决定
b. 公共实验（公共实验一个流量分组可能叠加多个实验，根据不同的商品范围查看各自对品维度的影响）：
- i. 对照组：公共实验对照组（固定）
- ii. 实验组：策略(plan)配置的实验组，根据每个策略的配置决定
以上，BI团队可给出针对部分新品的某个扶持策略(plan)为例，可观测的报表类似如下：
实时+离线的数据链路最终服务于调控引擎和算法中控
2.3.3 算法中控 ：
应对定量目标的保量需求，算法中控依托实时反馈数据进行的PID计算逻辑如下：
- 排序依据的score=rs*权重+相关性分 或者 score=rs*pctr/median(pctr)*权重 +相关性分权重= 1+ pid_score，权重区间 [0.1,10]
pid_score=(当前目标曝光-当前累计曝光量)/当前目标曝光*KI
当前目标曝光=计划目标*当前时间曝光比例
应对曝光占比类型的比例调控需求稍有差异：
占比低于目标时扶持：
占比高于目标时打压：
3、值得一提的
3.1 借鉴广告体系的独立召回链路
相比于之前的工作经验和其他平台的调研结果来看，类似广告投放体系的独立召回链路有如下几点特征：
（1）在新品扶持等领域，依赖于自然召回后再判断是否为调控品的逻辑，在针对“召回难”问题上并没有特别好的方案，往往是通过粗排白名单等方式对粗排进行暴力干预，白名单存在上限以及相关性差的问题并没有被解决。而独立的召回链路中，我们天然的将底池限定为有且仅有调控商品，在相关性分层符合要求的情况下，调控商品的位置不会被非调控品挤占。同时依赖搜神自研引擎定制的达成率逻辑，也能防止部分调控商品挤占其他调控商品流量的问题。线上实际可保障99%的新品能够获得调控带来的有效增量曝光(曝光位置提前)，同时整体保量目标达成率也可以满足业务要求
（2）在增量曝光的判断上更为准确：自然未能召回，仅调控有招回的概念，可以帮助我们判断，无论这个商品的坑位是否发生变化，仅调控链路召回必然是增量曝光。有助于后续继续推进基于运营分组预算管理的后台系统
（3）前置过滤对比后置过滤，可以在有限的召回量内，给予其他商品更多机会
（4）负向上有一定缺陷，独立链路召回的数量小于整体召回数量，会导致打压效果下降。这一点还是反作弊平台及风控系统黑名单直接对接商品底池的方式更为专业。
3.2 跨场景统一的AB实验
各场景各服务单独对接AB平台，相互之间是隔离的，哈希规则也是定制化的。后续我们是期望多场景联合调控中，增量目标的分配比例可以动态自动最优调配，同时回收各场景的ROI指标。熟悉报表的同学可以看到，即便是去万三高客单后的AB数据，同一个实验组多个实验的情况下，指标仍有差异。独立统一的调控正交分层可以保证无论是搜索还是推荐过来的同一个用户，命中的实验或者说策略是相同的，联合调控可据此分层数据做参考。
4、后续方向
（1）完善平台能力：
- 基本能力建设，包括捞月组件的接入，打通圈品集信息，实现一站式圈品及圈品规则维护；人群规则平台的接入，简化在线服务FeatureCondition的判别流程
- 调控平台运营中心易用性及使用体验上的建设工作，从数据分析、跨平台信息的打通、小工具、去除冗余操作及预警通知等方面打磨产品，从“能用”到“好用”的长期目标
- 后台增加配置中心，ark配置可视化，减少复杂json的变更成本；后期实现一键降级等功能；增加debug工具，测试在线系统召回、权重是否符合预期，提升debug及线上问题定位效率
- 异常熔断机制完善，异常通知能够传达到owner及运营负责人，异常损失效果可评估。
（2）非商品调控能力建设：
- 底纹词&搜索发现词、搜索框下拉推荐词等词导购场景覆盖，与query直达相结合，能够通过更多低成本的场景支持业务扶持指定货品的诉求
- 社区内容作为得物的核心场景，且当前社区内容中的商品标签、动态详情页商品卡片已经建立了内容引导交易的良好机制，无论是针对商品标签的内容调控，还是定向为作者推送待扶持商品的提示等方向，都存在着探索的空间和价值，期待后续可以探索社区&交易联合调控的落地场景。
（3）支撑场景扩展：
- 支持更多推荐场景，期望后续能够在品牌落地页、分类tab等场景进行实验，挖掘不同类型的商品集合在不同场景的ROI最优方案。
- 跨场景联合调控能力探索，跨场景目标分配、商品质量预估及评估、跨场景核心指标对齐等角度进行探索；帮助业务方在精细化人货匹配上的探索拿到结果。
