TensorFlow召回模型训练中动态上下架物品的数据构造问题

这是推荐系统领域物品存在上下架生命周期场景的标准处理流程，核心原则是负样本只能从用户交互发生时刻实际可访问的物品集合里采样，具体落地分3个环节：

1 预处理物品生命周期元数据 #

先基于全量物品的上下架日志，给每个物品生成唯一的有效曝光时间区间：

• 字段格式为(item_id, list_ts, delist_ts)，其中list_ts是物品上架时间戳，delist_ts是物品下架时间戳，统计周期结束时仍在架的物品，delist_ts统一赋值为统计周期的截止时间戳
• 所有时间戳精度和交互日志对齐即可，比如日志精确到天就用日期戳，精确到秒就用秒级时间戳

对前述示例日志，三个物品的生命周期元数据为：

item_A: (item_A, Jan1_ts, Jan13_ts)
item_B: (item_B, Jan10_ts, 周期截止_ts)
item_C: (item_C, Jan11_ts, 周期截止_ts)

2 为每条正交互样本绑定专属采样池 #

对每一条用户正交互记录（即(user_id, item_id, interact_ts)格式的浏览/点击/成交记录），以交互时间interact_ts为过滤条件，从全量物品中筛选所有满足list_ts <= interact_ts < delist_ts的物品，构成这条正样本对应的负样本采样池。

以上述示例中Jan14发生的user_2交互记录为例，筛选后只有item_B、item_C满足时间条件，item_A因为已经下架直接被排除在采样池外，从根源上避免将不可见物品误判为负样本的逻辑错误。

工程落地时不需要对每条样本实时遍历全量物品做过滤，用时间分桶预生成快照的方式就能把性能损耗降到最低：

• 按业务精度要求将统计周期切分为等长的时间桶（常见粒度为小时/天）
• 预计算每个时间桶对应的可访问物品ID集合，序列化后存为查找表
• 训练时根据正样本的交互时间戳直接映射到对应时间桶，拉取预存的物品集合作为采样池即可
  按小时粒度切分、单物品ID占8字节计算，百万级物品规模下全周期快照的内存占用不超过5G，常规训练集群完全可以承载。

3 适配自定义采样逻辑 #

如果使用TensorFlow检索组件的内置采样能力，不要直接使用默认基于全量物品池的均匀/加权采样器，替换为自定义采样逻辑：

• 将样本的交互时间戳作为特征字段和用户ID、正样本物品ID一起送入模型
• 采样前先根据时间戳查找对应时间桶的可访问物品池
• 在该池内完成负样本采样（可选择均匀采样、热度加权采样、in-batch采样等任意符合业务需求的采样策略）
  整体代码改动量极小，和原有训练流程完全兼容。

常见避坑提示 #

• 不要为了省事用全周期在架的固定物品池做采样：会漏掉部分时段上架的短生命周期物品，模型无法学到这类物品的嵌入，上线后对应时段会出现推荐漏召回问题
• 无特殊业务要求（如已购物品永久不推）不要提前把用户历史交互过的物品从采样池硬过滤，正常靠训练梯度自动区分正负样本即可，硬过滤容易引入新的分布偏差
• 新上架的冷启物品不需要额外处理，从它上架的时间桶开始自动进入对应时段的采样池，模型会在后续训练轮次中自然学到它的嵌入表示

内容的提问来源于stack exchange，提问作者noobie