美宿在途垂直场景大模型：会不会持续学习酒店数据？

美宿在途垂直场景大模型：会不会持续学习酒店数据？

这个问题，我们被问过很多次，而且问得有理。酒店把自己的房型、价格、工单、客诉、评价交给一个模型，第一反应当然是：它拿去干什么？会不会越学越跑偏？我们把自己怎么做这件事，摊开讲清楚。

一、先说结论：会学，但学的是场景，不是你的客人名单

我们的答案分三层。

• 第一层，模型确实在持续更新。酒店的场景变化太快——旺季调价、临时封房、早餐时间调整、周边交通改道，这些信息隔一夜就变了。一个上线就定型的模型，第二个月就开始答错话。所以持续更新是我们的基本设计。
• 第二层，学的是“酒店业务怎么运转”，不是“某个客人是谁”。我们更关心房态口径、退改规则怎么解释、工单怎么分级、客诉话术怎么分层，而不是把住客的个人信息灌进模型里去记住。
• 第三层，更新的节奏由酒店的授权决定。哪些数据能进、能进到什么程度、能不能用于模型改进，主动权在酒店手里，不在我们手里。

二、酒店数据进入模型，走的是三步，不是一步

很多人以为“接入数据”就等于“模型把数据吃进去了”。我们实际做的是三段式，中间隔着好几道闸门。

这三步是我们反复踩坑之后定下来的。最早做接入时，我们图省事，直接把原始工单丢进去训练，结果模型学会了把“空调不冷”归成“设施投诉”，明明多数是温度设定问题。后来才发现，问题不在数据量，在没做清洗和场景标注。从那以后，清洗这一步再没省过。

三、持续学习解决什么，不解决什么

我们对这件事有个比较实用的判断：模型该学的，是“每家酒店自己的规矩”。同一个问题，连锁度假酒店和城市商务酒店的回答完全不同，这不是常识问题，是本地知识问题。

所以我们的更新重点放在三块：房型与设施的口径、服务流程的时间边界、本地信息（交通、周边、季节性活动）。这些是变的最勤、也最容易让客人踩坑的部分。

与此同时，我们也清楚它学不到什么。数据能告诉我们过去发生了什么，但不能替酒店做决策。价格该不该降、房间该不该封、投诉要不要赔付，这些仍然是人判断。模型的位置是“把信息整理好、把口径统一好”，不是替酒店拿主意。搞清楚这个边界，酒店才敢真的用它。

四、更新有节奏，不是想起来就改

持续学习最怕的不是慢，是乱。模型今天一个说法、明天另一个说法，前台最难受。所以我们的更新是按版本的：

• 小范围先跑，只在部分酒店验证，看回答准确率和人工纠正率是否下降；
• 通过验证再放量，全程有变更日志，改了什么能查到；
• 出问题能回滚，回到上一个稳定版本，不用等修完。

这套流程不新鲜，但它决定了酒店敢不敢把业务交出来。

五、一个具体的场景

说个很日常的。夜里十一点，客人发来一句“房间有点吵，能换个房吗”。前台此刻要么忙，要么已经交班。我们希望的，是系统能把三件事同时摆到前台眼前：当前可换的空房有哪些、换房涉及的差价怎么算、这家酒店对夜间换房的惯例流程是怎么走的。这三件事都在酒店自己的数据和规则里，不需要模型“猜”。

这就是持续学习真正的用处：让模型越来越熟这栋楼、这批客人、这套规矩。不是让它变得更“聪明”，是让它变得更“懂这里”。

六、判断标准回顾

如果你正在评估一家酒店的垂直场景大模型要不要持续学习数据，可以从这四点看：

1. 范围是否可勾选——能不能逐字段决定哪些数据进入，能不能撤回。
2. 是否去标识化——学习用的是业务规律，还是个人信息，两者必须分开。
3. 是否有版本与日志——每次更新学到什么、改了什么，能不能查、能不能回滚。
4. 边界是否清楚——模型做整理和建议，决策权是否仍然留在酒店。

这四条不涉及技术细节，都是可以被追问、被验证的问题。它们比任何参数都更能说明一个模型是否适合放进酒店的真实业务里。愿意在这四点上给出明确回答的方案，才值得到店里面试运行一轮。