实时召回与质量监控

为什么需要实时召回

用户刚刚点赞或快速划走的视频，应该影响后续推荐——不是等离线任务跑完，而是下一次 Feed 请求就生效。

实时召回的典型场景

实时特征的存储

实时特征通常存在 Redis 或在线特征服务中，保证低延迟：

• 近期行为列表（最近 N 个完播 / 跳过）。
• 实时负反馈集合（不感兴趣、举报）。
• 会话级上下文（本次启动后的行为）。

实时 vs 离线的分层

• 实时：处理最近几分钟 / 本次会话的行为，响应快、覆盖面窄。
• 近线：分钟级 / 小时级聚合，折中。
• 离线：日级重算画像与 embedding，稳定、覆盖面全。

三层叠加：实时保新鲜，离线保全面。

实时召回的约束

实时召回也有代价：

• 存储和查询要快，不能拖慢 Feed。
• 状态一致性问题：行为还没落库，召回已经用了——可接受，但要幂等。
• 过度实时化会让推荐抖动：用户误点也可能瞬间改变推荐，要有保护。

召回质量监控

召回阶段要持续监控：

• 每个通道的命中率（召回内容被后续消费的比例）。
• 候选去重后数量（是否过少 / 过多）。
• 召回内容的新鲜度与多样性。
• 后续排序中的入选率（召回质量的风向标）。

一句话

实时召回让「刚发生的行为」立即影响「下一次推荐」，靠在线特征服务支撑；它与离线分层配合，兼顾新鲜与全面。召回的质量决定了排序的上限，要持续监控。

下一章进入排序：从候选集中决定用户实际看到什么。

上一章节

候选合并与配额

下一章节

排序优化