to be completed.tips: 重排是相近的任务, 详见另一篇 blog, 见参考[1].“混排” 和 “重排” 在实际系统中并非完全割裂而是存在功能重叠与协同。比如当混排需要考虑 item 之间的影响和约束时, 本质上就进入了重排的范畴.1. 混排场景两种不同类型的 doc 队列, 来自不同的上游, 其 score 逻辑不同, 难以直接对比.这是一个工业级推荐/搜索系统中的核心问题当自然商品Organic与广告Ads由不同 CTR 模型预估甚至不同特征、不同目标时如何将它们的打分对齐到同一尺度实现公平混排1.1 分数对齐首先约定符号:s 原始打分CTR 预估值μ 该队列自然 or 广告的近期平均打分σ 该队列的标准差有不同的做法:z-score 标准化(推荐).s s μ s\frac s \musμs均值缩放, Mean Scaling.s s − μ σ s\frac{s-\mu}{\sigma}sσs−μ推荐前者是因为 均值缩放有两个局限:若某类广告平均 CTR 极低如 μ0.001则所有广告 s/μ 都很大如 0.002/0.0012可能过度放大噪声无法反映打分的离散程度两个队列可能均值相同但一个集中、一个分散。1.2 统一价值分被不同的 ctr预估模型打分.2. 流控场景问题特点:无法事先拿到所有请求, 离线统一求解. 因此叫 online-matching.应用于在线服务, 求解rt不能高于50ms2.1 CIKM 22’, 阿里广告动态定坑见参考[1].2.1 问题建模,动态背包略, 详见论文2.2 求解, pidbeam search思考: beam search 有用的前提是, 有些情况下, 上一层占优的排列, 到了下一次反而落后了. 比如下图中两个橙色对号标记的排列.自己举了具体的例子作代入:归纳下,如果不考虑坑位位置的曝光衰减, 不考虑广告的位置约束(不能出现在顶部, 间隔不能太小), 就不再需要 beam search.如果没有位置约束, 哪怕有位置曝光衰减, 也可以直接按\delta v展开后的 utility 表达式 倒排, 就可以了.参考我的 blog, app信息流中的重排与强化学习paper, CIKM 22’, Hierarchically Constrained Adaptive Ad Exposure in Feeds
