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 插件依赖的实时数据如下：
以上指标基于客户端上报的埋点、服务端日志 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=rspctr/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）欠缺平台能力：
a；根本能力建设，包含捞月组件的接入，买通圈品集信息，实现一站式圈品及圈品规定保护；人群规定平台的接入，简化在线服务 FeatureCondition 的判断流程
b：调控平台经营核心易用性及应用体验上的建设工作，从数据分析、跨平台信息的买通、小工具、去除冗余操作及预警告诉等方面打磨产品，从“能用”到“好用”的长期指标
c：后盾减少配置核心，ark 配置可视化，缩小简单 json 的变更老本；前期实现一键降级等性能；减少 debug 工具，测试在线零碎召回、权重是否合乎预期，晋升 debug 及线上问题定位效率
d：异样熔断机制欠缺，异样告诉可能传达到 owner 及经营负责人，异样损失成果可评估。
（2）非商品调控能力建设：
a：底纹词 & 搜寻发现词、搜寻框下拉举荐词等词导购场景笼罩，与 query 中转相结合，可能通过更多低成本的场景反对业务搀扶指定货品的诉求
b：社区内容作为得物的外围场景，且以后社区内容中的商品标签、动静详情页商品卡片曾经建设了内容疏导交易的良好机制，无论是针对商品标签的内容调控，还是定向为作者推送待搀扶商品的提醒等方向，都存在着摸索的空间和价值，期待后续能够摸索社区 & 交易联结调控的落地场景。
（3）撑持场景扩大：
a：反对更多举荐场景，冀望后续可能在品牌落地页、分类 tab 等场景进行试验，开掘不同类型的商品汇合在不同场景的 ROI 最优计划。
b：跨场景联结调控能力摸索，跨场景指标调配、商品质量预估及评估、跨场景外围指标对齐等角度进行摸索；帮忙业务方在精细化人货匹配上的摸索拿到后果。