搜索排序权重怎么动态调?

这道题其实问的是在线学习，就是怎么根据用户的实时反馈，动态调整搜索排序里的特征权重，形成一个'投放、反馈、更新、再投放'的闭环。

先说方案选型。如果评分函数是线性加权，我会优先考虑 FTRL-Proximal，它稀疏性好，工程上也成熟，适合大规模特征。如果系统需要主动探索新策略，比如推一些冷门商品，那就要上 Contextual Bandit，像 LinUCB 或者 Thompson 采样，它能显式地处理探索和利用的权衡。深度模型的话，可以用在线梯度更新或者 [[蒸馏]]学习，轻量模型实时更新，大模型定期同步。

但真正落地，很少只用一种。比如电商搜索排序，我会用 FTRL 做主力，处理点击、停留时长这些短期反馈，同时叠一个轻量的 Bandit 模块，专门给新品或低曝光商品加探索权重。说白了，不同方案各有适用边界，混着用才能兼顾稳定性和灵活性。

再讲关键实现路径。首先是反馈信号，不能只看点击，还得看转化率、GMV 这些长期指标。这里有个坑：延迟奖励怎么归因？比如用户今天搜'冰箱'点了一个商品，七天后才下单，这个转化得归到当时的点击 query 上。我一般用固定窗口，比如 7 天，窗口内转化都算给那次点击。

然后是实时特征更新。架构上就是用户行为进 Flink 实时流，拼接特征后增量更新权重，再推送到排序服务。这里有个前提：特征工程得稳定，不然权重更新会被噪声带偏。

稳定性保障是上线前必须考虑的。我会用[[滑动窗口]]平均，防止单条样本剧烈扰动；权重裁剪也很关键，设置更新幅度上限，比如每次不超过 0.01，避免一次坏样本毁掉整个模型。另外，新特征刚上线时，先用离线预训练权重，积累到一定样本量再切入在线学习。

说到冷启动，其实还有一个更棘手的问题：用户行为反馈的延迟性。比如搜索后用户可能隔几天才转化，这期间权重已经更新了好几轮，很容易出现权重震荡。我一般会加一个延迟补偿机制，把未归因的转化缓存起来，等窗口关闭再统一更新。

最后说我的取舍。我更倾向 FTRL 加简单探索的组合，而不是一上来就上强化学习。因为 RL 的延迟太大，对工程要求高，而 FTRL 在大部分场景下已经够用，加上 Bandit 探路，性价比最高。所以我会把在线学习看成持续迭代的工具，不是一次性的优化，上线后还要持续监控权重分布和业务指标。