TabPFN+Gemma打造汽车旅馆防No-Show助手

小型汽车旅馆最怕的不是没客人订房，而是客人订了房却悄无声息地不出现——如果没提前收取押金，这一晚的收入就彻底打了水漂。一位开发者为此构建了 No-Show Desk：每天早晨筛选出最可能取消的到店客人，用大白话解释原因，并起草一封简短的"您还来吗"确认邮件，由老板决定发还是不发。

值得关注的是技术选型：预测用 TabPFN（专为小表格数据设计的预训练模型），写作用 Gemma 4（Google 的开源模型，直接在浏览器里本地跑），事实核对交给纯代码。作者围绕一条原则构建了整个系统：代码负责计算，模型负责措辞。

为什么小旅馆需要"未到预测"

每次客人不打招呼就不来，旅馆就损失一晚的房费。而在很多情况下，如果提前问一句，客人会说明计划变化，房间还能转售给他人。No-Show Desk 的目标就是让老板每天早上花一分钟，知道该问谁，从而把可能空置的房间提前释放出来。

作者原本在向旅馆推销"无人值守时接电话的语音助手"，但本周 Hacktoberfest 的主题要求做一个"小企业真正愿意付费"的东西。于是他转向更小的切口：每天一份名单、一封邮件，简单到几家老板愿意试用。定价逻辑也很清晰——演示日当天被标记的7位客人中有4位真的取消，涉及776.60美元订单，而当地一晚房价在67到107美元之间。只要每月救回一晚，这套工具就回本了。

数据与预测：小样本下的TabPFN优势

公开的汽车旅馆数据并不存在，作者使用了 Hotel booking demand 数据集（Antonio、Almeida 与 Nunes，2019）：来自两家葡萄牙酒店的119,390条真实预订，时间跨度为2015至2017年。所有1,207条 no-show 都被标记为取消，因此模型同时预测两种结果。每次测试都在"汽车旅馆规模"的数据切片上进行：约3,000条历史预订，每天早晨20位到店客人。

数据清洗里有个关键陷阱：部分字段只有客人到店后才填写，会直接泄露答案——比如记录了停车位的预订取消率为 0.0%，因为车位是车到了才登记的。作者删掉了六个这类字段，并且所有测试只从某个日期之前的预订中学习，在该日期之后的预订上评分，完全模拟真实使用方式。此外，模型只对未收押金的预订打分，因为预付后取消对老板没有损失（该数据中不可退款预订的"取消"率高达99.4%）。

TabPFN在旅馆规模下全面胜出

一家20间房的旅馆最多也就几千条历史预订。TabPFN 在海量合成表格上预训练过，面对新表格只需一步就能学习，无需作者自己跑训练。作者让 TabPFN、梯度提升（表格数据的常用工具）和普通逻辑回归分别学习300、1,000、3,000条历史预订，每种历史各三份，然后在2017年的同一批5,000条预订上评分，指标是 ROC-AUC。

结果 TabPFN 在全部9次运行中排名第一：300条历史时0.721，1,000条时0.766，3,000条时0.778；梯度提升分别为0.682、0.702、0.747。逻辑回归比预期更接近（0.699、0.741、0.749），所以诚实的总结是：TabPFN 在每个规模上都赢，但只领先回归模型0.02到0.03。

用没见过的年份验证阈值

作者的初版把风险线设在50%。结果第一个演示早晨，20位客人里只标出1位，而且没取消，4位真正取消的客人都漏掉了——因为大约只有三成客人会取消，极少有分数能超过50%。于是作者在2017年的30个早晨上把阈值定为 30%，随后因为"选阈值和报告用同一批数据属于偷看"，又在2016年从未参与选择的30个早晨上做了验证。

在2016年的数据上，30%线依然比"风险最高的5位"规则或50%线抓到更多取消，而50%线有两个早晨一个人都没标出。25%能抓到更多，但被标记客人中真正取消的比例更低。

ROC-AUC 是评估二分类模型排序能力的常用指标，全称“受试者工作特征曲线下面积”。它衡量的是：随机抽取一个正样本和一个负样本，模型给正样本打高分概率。取值0.5相当于随机猜测，1.0为完美排序。在本文场景中，正样本是最终取消的预订，负样本是正常到店的预订。AUC只关心相对排序而非绝对概率，因此特别适合“每天挑出最可能取消的N位客人”这类排序任务。0.72到0.78的AUC意味着模型有较好的区分度，但并非完美，这也解释了为何30%阈值下仍会漏掉部分取消。

梯度提升（Gradient Boosting） 是一类基于决策树的集成学习方法，通过逐步拟合前一轮的残差来提升预测精度，XGBoost、LightGBM 是其代表实现。它在中等规模表格数据上长期是“默认最强”的基线，但需要足够的样本量和调参才能发挥优势。本文中它在300条历史时AUC仅0.682，明显落后于TabPFN的0.721，说明小样本下预训练先验的价值。

规则能不能替代模型？

演示日被标记的7位客人全部通过同一家旅行社（数据编号#9）预订，那老板能不能自己定条规则？作者让每条规则使用与模型相同的每日邮件数量做对比：

每日相同邮件数	172次取消中抓到的数量
TabPFN，30%线	111
逻辑回归，按当日历史拟合	106
在线旅行社优先，再按提前预订时长	99
旅行社#9优先，再按提前预订时长	94
提前预订时长优先	81

作者能想到的最好规则抓到99次，TabPFN 通过综合权衡所有因素抓到111次。

可读的解释与"代码计算、模型措辞"

TabPFN 只给概率，不给理由，所以解释来自简单的计数：如果某位客人所属群体（提前预订时长、旅行社、渠道、餐食计划）的取消率比所有无押金预订高出至少5个百分点，且该群体至少有30条记录，才会被点名说明。理由描述的是群体，排序仍然是 TabPFN 的。

写作环节最能体现作者的核心理念。他把同样的50条预订、每条两份草稿交给 Gemma：一次给原始记录（"到达2017-08-23，2个周末夜，5个工作夜，均价160.2"），一次给代码算好的事实（"8月23日周三到达，8月30日周三离开，7晚，1,121.40美元"）。结果显示，让 Gemma 自己推算日期和金额时，100份草稿中有13份日期、晚数或总额出错；由代码提供事实时，错误为0份。

从原始记录出发，Gemma 曾给客人 Grace 写道："您的预订确认于2017年8月23日至8月25日，共2晚，总计320.40美元。"实际是7晚、1,121.40美元。另一份草稿甚至写"可免费取消至4月0日"。而这些草稿全都流畅又友好。

纯 Python 校验器会逐份比对草稿中的日期、晚数和金额。作者还分享了三次人工阅读发现的问题：校验器最初误报了25份，实际13份是格式识别不了的正确答案；系统曾提供已经过去的免费取消日期；他给 Gemma 的指令"如果有日期就提一下"导致模型写出"[Insert Date Here]"占位符，而所有数字都正确，校验器当时放行了。修复方式同样遵循原则：由代码决定这句话是否存在，校验器现在也能捕获占位符。

本地浏览器里跑Gemma

在8GB内存的 Mac 上，通过 Ollama 运行 Gemma 每份草稿约需30秒。Google 还发布了同一个 Gemma 4 小模型的2GB版本，可在网页内通过 WebGPU 使用电脑显卡运行。作者让浏览器版处理同样的100份草稿和同一个校验器，结果没有任何事实错误，中位耗时 3.25秒，而 Ollama 为31.4秒。

不过人工阅读发现了校验器覆盖不到的问题：少数草稿遗漏了事实，比如一晚住宿没写晚数——浏览器版6份，Ollama 版5份，但没有一份陈述了错误信息。真实设备还让页面改了两次：iPhone 15 Pro 下载完整个模型后 Safari 重新加载页面（很可能是内存不足），所以手机端改为显示预写好的消息；8GB Mac 在 Gemma 加载后短暂卡死过一次。

WebGPU 是浏览器暴露底层显卡能力的现代标准接口，取代了此前的 WebGL 计算路径，允许 JavaScript 直接调度 GPU 做并行矩阵运算。这使得几GB参数的小型语言模型可以在浏览器标签页内完成推理，无需后端服务器。配合 Ollama 这类本地模型运行时（一条命令拉取并托管模型，通过本地HTTP接口调用），开发者可以在“完全本地”与“浏览器内本地”两种形态间选择。前者依赖本机CPU/内存，后者可借GPU加速，这正是本文3.25秒与31.4秒差距的来源；但浏览器运行受标签页内存上限约束，iPhone 上因内存不足导致Safari重载页面即是典型表现。

开源与本地化为何重要

一条 no-show 消息包含客人姓名、日期和金额。Gemma 在老板自己的电脑上起草，这些信息不会离开本地磁盘。同时没有按条计费——测试日平均每天标记约7位客人，若使用付费写作 API，成本会每天累积；而这里模型只是老板磁盘上的一个文件。对只有几千行数据的小企业来说，TabPFN 无需训练、无需数据科学家，正好匹配真实旅馆的数据体量。

作者也坦诚了一处尚未本地化的环节：TabPFN 的打分目前通过 Prior Labs 的 API 完成，因此预订细节（不含姓名，该数据本身也没有姓名）每天早晨会离开电脑一次。不过 TabPFN v2 的权重可以本地运行，其许可证允许带署名的商业使用。作者实测：在8GB Mac 上每天早晨约23秒，v2 在30个测试早晨上同样抓到172次取消中的111次，标记205位客人而非210位（ROC-AUC 0.787，API 为0.792）。这是付费版本的可行路径。

TabPFN 的核心思想是“先验拟合数据”（Prior-Data Fitted Network）：在海量人工合成的表格任务上预训练一个Transformer，使其学会“给定训练集，直接输出测试样本的预测分布”。使用时无需梯度训练，只需把训练集作为上下文输入，一次前向传播即可完成推断，因此对小表格极其友好。其v2版本权重可下载本地运行，许可证允许带署名的商业使用。本文中本地v2在8GB Mac上每天早晨约23秒完成打分，AUC 0.787与API的0.792几乎持平，说明“本地化不牺牲精度”，只是需要一次性部署成本。

真实的部分与未验证的部分

作者明确区分了边界：预订数据、TabPFN 分数、解释理由、Gemma 草稿和每一次校验都是真实的；但"发消息是否能让客人回复、房间是否真能转售"并未测量——这只有真实旅馆才能验证。他的第一位潜在用户是一位曾被他推销过语音助手的旅馆老板，对方表示如果有更多取消会用，并认为它比语音助手更方便、省钱、易部署，但目前取消不多，所以还没试用。第二位老板正在接洽中，作者说第一个要问的问题就是：回复是否曾经早到足以把房间转售出去。

项目已在 GitHub 开源（MIT 许可），提供在线演示，包含61个逻辑测试，所有测量结果都由脚本生成并存档。对于想做小生意 AI 工具的开发者，这个项目提供了一个值得借鉴的范式：用小样本专用的预训练模型做预测，用本地小模型做表达，用确定性代码守住事实底线。