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

30 秒回答

1. 短期：点击、CTR、停留时长
2. 长期：转化率、GMV、用户留存
3. 设计延迟奖励归因（如7天转化归因到点击query）
4. 滑动窗口平均：防止单条样本扰动

回答与解析

核心思路

搜索排序的动态权重调整本质是在线学习问题：利用实时用户反馈持续优化评分函数，形成"投放→反馈→更新→再投放"的闭环。

技术方案选型

关键实现路径

1. 反馈信号构建

• 短期：点击、CTR、停留时长
• 长期：转化率、GMV、用户留存
• 设计延迟奖励归因（如7天转化归因到点击query）

2. 实时特征更新

用户行为 → Flink实时流 → 特征拼接 → 增量更新权重 → 推送到排序服务

3. 稳定性保障

• 滑动窗口平均：防止单条样本扰动
• A/B测试桶：小流量验证新权重，全量前回滚机制
• 权重裁剪：设置更新幅度上限

4. 冷启动处理

• 新特征先用离线预训练权重，积累一定样本后切入在线学习

工程权衡

• 延迟 vs 时效性：流式更新（分钟级）通常足够，秒级需考虑一致性
• 个性化层级：全局权重 → 用户群体权重 → 个体权重，逐层细化

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

• 一句话定位：在线学习问题
• 方案选型：FTRL、Bandit、深度模型，落地常混合
• 关键实现：反馈信号、实时流、稳定性保障
• 风险与前提：延迟、冷启动、权重裁剪
• 工程师取舍：倾向FTRL加简单探索

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

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

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

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

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

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

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

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

关键一句:用户行为反馈的延迟性会导致权重震荡，需要延迟补偿机制。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你负责电商搜索排序，用户搜索后点击了某个商品但没下单，系统怎么根据这个行为自动调整后续排序中价格、销量这些特征的权重？

2. 问法 2 · 层层追问

   搜索排序的评分函数通常靠人工调权，怎么让它自动学习？……如果特征是线性组合，用户反馈来了你用什么算法更新权重？……那FTRL具体怎么处理特征稀疏性和收敛速度？

3. 问法 3 · 直球架构

   请设计一个方案，能根据用户点击、转化等实时反馈动态调整搜索排序特征权重，说明反馈信号怎么构建、权重更新用哪种在线学习算法，以及如何保证系统稳定。