北京
Airbnb 把推荐系统里序列嵌入的陈旧时间，从接近两天压到了不到一分钟。典型更新在 10 到 30 秒内到达。这个数字来自 Airbnb 对开源特征平台 Chronon 的扩展：新增 Push Mode 和近实时（NRT）模型变换两项能力，让基于序列的推荐嵌入能在住客行为发生后几秒内完成更新。
先看这套系统原来是怎么跑的。Airbnb 的序列推荐器基于 JourneyFormer，用一个 Transformer 编码器来表示住客的预订、评价和浏览历史。这个编码器此前作为每日批处理任务运行，产出的嵌入被存进一个低延迟存储。搜索时，排序系统取出最新嵌入，与实时查询结合，Transformer 本身则被挡在对延迟敏感的 serving 路径之外。
问题出在批处理的间隙。每日批处理之后发生的活动，可能一直缺席于嵌入，直到下一次任务跑完才被补上。加上处理延迟，实际陈旧时间接近两天。对推荐来说，这意味着住客刚看过的房源、刚发生的搜索，可能要等上很久才会反映到排序结果里。
Airbnb 的解法是给 Chronon 加两项能力。Push Mode 让流式任务在某个特征值提交时发出通知，下游处理因此可以对更新后的住客活动作出反应，而不必轮询或等待定时任务。NRT 模型变换则允许一个已经部署的模型直接在那条流式管道里运行。
值得注意的是，近实时路径复用了同一个 Transformer 序列编码器。Airbnb 没有为流式工作流另写一套推理实现，这减少了线上线下行为不一致的风险。
整条管道的工作方式是：捕获搜索、房源浏览等事件，与住客已有的短期和长期序列数据结合，在更新后的特征状态可用时触发模型推理。生成的嵌入被写入批处理系统同样使用的那个低延迟存储。于是，在线排序路径基本不用改动，但它取回的表示变得更及时。
Airbnb 基础设施高级软件工程师 Pengyu Hou 这样描述这次平台改动，称其解决的是事件驱动数据与模型推理之间的落差：
“NRT 模型变换让 Chronon 可以直接从流式流程内部调用一个已经部署的模型。”
效果在离线指标和线上 A/B 测试里都有体现。Airbnb 报告离线 NDCG 提升 1.67%，在线 A/B 测试中未取消预订量提升约 0.33%。这两个数字对应的是同一套推荐排序的改进，而不是新增了某个独立功能。
这种做法对应一种更广的特征服务模式：预测可以在底层特征变化时更新，而不是在每次用户请求时重新计算。另一个开源特征平台 Feast 记录了缓存预测架构，推理由特征更新触发，用额外的写入和管道复杂度换取更低的 serving 延迟。Chronon 的选择不同，它把流式计算和模型变换整合进特征平台本身，并强调离线计算与在线计算之间的一致性。
Airbnb 已将 Push Mode 和 NRT 模型变换贡献到 Chronon 的公开仓库。Chronon 同时支持批处理和流式计算，并提供在线特征服务，设计目标是保持训练与生产推理之间的一致性。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
