你在 Airbnb 上找住处，很少一次就定下来。可能先看旧金山的几十套房，隔天改日期，再回来继续挑。问题是：搜索结果该把你刚才的浏览当真，还是参考你过去几年的预订习惯？Airbnb Engineering 介绍了一套基于 Transformer 的序列模型，试图把跨会话、多年的访客行为放进搜索排序。它值得关注，因为推荐系统开始从“你点了什么”转向“你走到了旅程哪一步”。本文事实均来自 Airbnb Engineering 的单篇官方文章，尚无独立信源或量化实验可供交叉验证。
旧办法为什么不够了？
搜索排序可以分成两步：系统先找出一批候选房源，再由排序模型判断哪些更符合当前需求，决定结果页上的先后顺序。
据 Airbnb Engineering 作者 Daochen Zha 等人介绍，Airbnb 过去主要靠手工聚合特征理解访客。例如，一个人历史上订过多少次房、看过的房源平均价格是多少。这些统计量有效，却会把一段旅程压成几个数字。随着特征增长到数百个，维护和扩展也越来越困难。
更关键的是，同一个人的长期兴趣与当前意图并不相同。过去常订某个价位，可能说明稳定偏好；这次旅行的地点、目的和预算却可能完全变化。只看历史总数，难以判断人此刻在找什么。
把行为当成一段旅程
Airbnb 的新思路是采用序列模型——把行为及其先后关系作为整体处理，而不是分别统计。一次旅程可能是“浏览城市—查看房源—调整日期—再次搜索”；顺序本身就能透露用户处于探索、比较还是接近决定的阶段。
模型采用 Transformer。这是一类利用“注意力机制”挑选相关上下文的神经网络：它原本可以处理一串词，这里的一串元素则变成浏览、预订、评价和取消等行为。Airbnb 称，这套系统编码了访客多年积累的旅程信号，用来为搜索排序生成更丰富的偏好表示。
不过，标题里的“完整旅程”不能理解为把每一次原始操作原封不动塞进模型。官方文章明确指出，房源浏览占事件的绝大多数，部分用户甚至积累了数十万次浏览；如此长的原始序列在计算上无法直接建模。现有材料没有继续披露系统如何筛选、压缩或组织这些事件。因此，更准确的理解是：模型覆盖多年、跨会话和多种行为，而不是毫无取舍地读取全部记录。
难点不只是序列太长
Airbnb 搜索主要优化 booking conversion——用户最终完成预订的比例，而不是社交平台常见的 engagement，也就是停留、点击或互动。浏览很多，预订却少，而且预订通常是更审慎的决定。一次查看房源可能代表明确意图，也可能只是随手看看。
这让训练信号天然不均衡：数量最多的行为未必最能说明需求，最有价值的预订又相对稀少。序列模型的意义，正是在大量轻微信号和少量关键决定之间寻找联系，同时区分长期偏好与眼前任务。
为什么值得关注
这不是简单地给排序模型再加几个特征。变化在于建模单位：旧办法先把历史压成总预订量、平均价格等统计值；新办法则试图保留行为之间的时间关系，把用户视为正在推进一段旅程的人。
如果这种方向成立，搜索排序关注的就不只是“这个人通常喜欢什么”，还包括“这次旅行进行到哪一步”。这也是推荐系统从单次点击预测走向长期旅程建模的生产级案例。只是目前公开节选主要说明了问题与总体思路，还不足以证明实际收益。
局限与未知
- 官方文章节选没有给出离线指标、A/B 测试增益、统计显著性或上线范围，不能把“更个性化”写成已经量化证明的效果。
- 材料未披露超长序列如何压缩，以及浏览、预订、评价和取消分别如何进入模型。
- “绝大多数”“数百个”和“部分用户数十万次”都缺少精确比例、样本范围与统计口径。