你想找“滑雪场附近的浪漫木屋”，这句话对人很自然，对一套尚未上线的搜索系统却很棘手：它既没见过用户会怎么提问，也不知道哪些房源算好答案。没有查询，就训不出模型；没有模型，又很难吸引用户产生查询。Airbnb把这个“先有鸡还是先有蛋”的问题，变成了一条先造训练数据、再等真实流量到来的管线。
这套框架叫 CASTLE，全称是 Contrastive And Seed-guided Training for natural Language sEarch。以下方法与结论均来自 Airbnb 工程博客这一单一机构信源；博客节选没有提供效果指标或上线范围，因此这里讨论的是它的训练思路，而不是已经得到独立验证的搜索提升。
搜索上线前，先把考题和答案一起造出来
自然语言搜索允许旅客直接描述需求，例如“可带宠物、能住八人的海边房子”，不必逐项操作筛选器。但训练搜索模型需要成套样本：一句查询、若干候选房源，以及每套房源与查询有多匹配。
最后一项叫“相关性标签”——可以理解为训练时的参考答案。模型反复对照它，才会学到该把哪些房源排在前面。问题在于，新系统还没有真实查询，自然也无法从查询推断这些标签。这就是冷启动（cold start）：系统刚上线，没有足够的用户历史可学。
Airbnb的做法，是利用去标识化的预订与搜索信号，同时合成查询和相关性标签。预订、搜索等行为会间接留下旅客偏好的线索；“去标识化”则指去掉或处理可识别个人的信息。CASTLE把这些行为信号当作原料，生成近似用户表达的查询，并为查询与房源的匹配关系生成标签。换句话说，它不只编考题，也同时编参考答案。
妙处在于，不把两件事拆开
Airbnb称，此前一些方案通常把查询生成和标签生成分成两步。例如 InPars先让大型语言模型（LLM——能理解和生成文字的模型）根据单篇文档生成查询，再请模型判断相关性。博客认为，第二次判断会再引入一处误差来源。
Promptagator则用少量示例引导模型生成更多样的查询，但Airbnb认为，模型“想象”出的提问方式与真实用户行为之间仍可能存在差距。CASTLE换了一个角度：不只从房源文本猜用户可能问什么，而是让Airbnb自身的预订与搜索信号参与生成，并把查询和标签放进同一套过程。
这很像在一家新餐厅开门前排演点单。只凭菜单编顾客问题，容易得到整齐却不真实的句子；参考过去顾客如何选择菜品，至少能让模拟更贴近实际偏好。这个类比只解释数据管线的直觉，并不意味着合成数据能够替代真实用户反馈。
为什么值得关注
CASTLE最有借鉴价值的地方，不是某个模型名称，而是它对冷启动的处理方式：当目标产品还没有直接训练数据时，先寻找已有业务行为中与目标相关的信号，再联合构造“输入”和“答案”。这比单独生成一批看似自然的查询更完整，因为搜索训练需要的本来就是查询、候选对象与相关性标签之间的对应关系。
这也延续了Airbnb对搜索入口的调整。2022年，Brian Chesky曾公开表示，传统搜索框一开始就问“你要去哪里”，会把用户限制在少数能想起来的热门城市。Airbnb随后推出按城堡、洞穴、树屋等类别浏览房源的改版。如今让用户直接描述“想住什么”，可以看作继续弱化“先确定目的地”的思路。
局限与未知
- Airbnb博客节选没有披露样本规模、离线指标、基线对比或在线 A/B 测试，因此不能据此判断 CASTLE 是否提升了搜索效果。
- 材料没有说明系统的实际发布范围，也不能把“从一开始就表现良好”当作已经证实的结果。
- 去标识化不等于不存在隐私风险；现有材料也不足以评估其具体处理方式。博客还称相关论文获第35届 CIKM 接收为 full research paper，但供稿中的会议名称被截断，本文不据此补写会议年份或更多细节。