美宿在途垂直大模型针对酒店场景做了哪些专项微调

我们把大模型，带进了酒店前台

我们是美宿在途，一支专注酒店场景的团队。我们做的事说起来很简单：让大模型听懂酒店这门生意，成为员工手上真正好用的工具。通用大模型很聪明，但它没在酒店住过一天。我们要做的，是把它带进前台、带进客房、带进夜班那张值班表里。

我们为什么从酒店这一个场景切进来

酒店是一个很特别的行业。它不是标准品生意，一间房卖出去，背后是房型、早餐、加床、连住、企业协议、渠道佣金、退款规则、发票政策层层叠叠的组合。一位新员工从入职到能独立处理这些，往往要几周；旺季人手一紧，前台就容易卡在同一个问题上反复被客人问。

我们从创立第一天起就只盯着这一件事：酒店里的每一个问答、每一次报价、每一张工单，能不能被更快、更准地处理掉。所以我们的模型不是"能聊天"就够，而是要在酒店的语境里说得对。

针对酒店场景，我们做了这几类专项微调

通用模型直接拿来用，在酒店里会露出几个短板：不懂房态、算不清价格、说不准政策、接不住口语。我们的微调就是一条一条补这些短板。

1. 房态与库存的语言对齐

我们把"还有没有房""能不能加床""连住三晚中间那晚满房"这类真实提问，和 PMS 里的房型、库存、入住规则对应起来训练。模型学的不是房态数据本身，而是客人怎么问、员工怎么答、系统怎么查这一整套动作链条。这样它就不会把"有房"和"可售"混为一谈。

2. 报价与政策的口径校准

房价从来不是一个数字。含早不含早、是否可退、押金怎么收、企业协议价能不能叠券、渠道价格与前台价差多少——每一家酒店的口径都不一样。我们在微调时把价格构成拆成可校验的要素，让模型输出报价时说明这笔钱由哪几部分组成，而不是给一个孤零零的总额。政策类问题同理：酒店自己的退改规则优先于任何通用常识。

3. 口语、方言化与错别字容错

真实场景里的提问很少工整。"明儿个还有房吗""带娃能加个小床不""退了能全退不"——这些句子在通用模型里容易被打回重问，在酒店场景里却是日常。我们专门收了一批口语化、带错别字、混着方言表达的问法做对齐，减少"请您重新描述"这种让人泄气的回复。

4. 多语言接待的一致性

入境游回暖后，前台经常要在中英日韩之间切换。多语言不是把中文翻过去就算完，房型名称、酒店设施、当地交通、早餐时间这些表述要在几种语言里指同一个东西。我们的做法是把同一批酒店事实作为共享底稿，让不同语言的回答保持一致口径，避免客人拿着两版说法来对质。

5. 工单与运营动作的落地

客人的需求最后都要变成一条工单：几号房、什么问题、谁去、多久回。我们让模型不只回答，还能把对话整理成结构化的工单要素，交给对应的岗位。这一步看着不起眼，却是把"聊得好"变成"办得成"的关键。

微调之外，我们同样在意的事

• 模型不知道的，就说不确定。涉及具体房价、具体政策的回答，一律以酒店系统里的实时数据为准，不靠推测补齐。
• 每家酒店有自己的说法。同一句"能不能提前入住"，不同酒店的答案不同，模型按门店配置回答，不套用统一模板。
• 人工永远在环上。拿不准的判断，转给当班员工，而不是硬答一个看起来漂亮的答案。

这些微调，最后落在谁身上

落在一位刚上夜班的前台身上。凌晨一点，客人在电话里问能不能换个安静点的房间、早餐能不能晚点收，她不用翻三本手册、也不用去敲经理的门，系统给她一个可以直接照着说的话术和一条能提交的工单。这比任何参数指标都更能说明我们做对了没有。

写在最后

模型再大，也只服务一件事：让住店的人被好好接住，让值班的人少一点手忙脚乱。这是美宿在途的出发点，也是我们持续做微调的理由。想看看它在真实酒店里怎么工作，欢迎来聊聊。