地铁售票机要不要接大模型?荷兰工作室 Continker 用一份 955 用例的基准测试给出了目前最完整的证据链。论文 9 月 9 日挂上 arXiv(编号 2609.10016),代码、数据集、微调模型全部开源,Apache 2.0 协议。
测的是什么
MetroLLM-Bench 把语言模型放进售票机的位置:读一段自然语言写成的运营策略,通过工具调用处理路线规划、票价计算、故障应对、无障碍服务和对抗输入,最后输出机器可校验的终端状态。覆盖亚特兰大、多哈、旧金山、台北、芝加哥、北京六座真实地铁系统,站点数从 37 到 414,计费模型分单一票价、里程计价、混合计价三类,共 11 个类别的用例。评分分两层:Tier 1 有 14 个确定性组件,核路线、票价、工具调用对错,不需要任何 API key;Tier 2 有 8 个语义组件,其中 6 个由 Claude Haiku 当裁判。955 个用例按 75/25 分层切分,238 个用例严格留出,只用来报告成绩。26 个来自 6 家厂商的模型参赛,23 个上榜。
核心数字
留出集上,一个 2.6GB 的 Qwen 3.5 4B 学生模型(PEFT 微调,Q4_K_M 量化)拿到 Tier 1 91.32 分,超过 GPT-5.6 两档(luna 中等推理 90.63、sol 最大推理 90.00),与 GPT-5.4 全量版最大推理只差 0.05 分。更扎眼的是对照线:一个纯规则的确定性基线拿到 84.6。也就是说,大模型对规则系统的净优势只有 6.7 分左右,且集中在策略适配、复合场景、无障碍和时间推理这些"规则写不完"的地方。综合榜前六里只有两个 OpenAI 专有模型,榜首是 Muse Glimmer 30B 的 92.03。
PEFT 的边际递减
这份测试最有价值的可能不是榜单,而是微调增益随基座变大而单调衰减的曲线:2B 基座微调后平均涨 7.03 分,4B 涨 2.00,9B 涨 1.65,到 27B 反而跌 0.91——基座越强,适配器能做的越少,甚至帮倒忙。955 全量矩阵的 bootstrap 置信区间证实了 4B 的增益(+1.72)和 27B 的回退(-1.09)都显著。复现门槛也压得很低:一台 M2 Max 跑 15 用例探针约 62 tok/s、占用 7GB 内存,README 给了从 llama.cpp 部署到全量复现的三档路径。
两点保留
一是 Hugging Face 社区里已有讨论指出:基准主要打分最终状态,工具调用失败后的恢复行为(查询超时、返回脏数据、读卡器重刷)没有单独计分层,而真实售票机恰恰死在这些地方。二是 Tier 2 的 LLM 裁判与人工标注只有 82% 完全一致,论文自己也把比较性结论压在确定性的 Tier 1 上。另外 serving 配置本身就能让 Qwen 3.5 与 3.8 的对比移动 2.7 分——部署细节的权重不亚于选型。
结论可以这样收:在范围收窄、规则密集的垂直任务上,2.6GB 的本地模型已经够用,数据主权场景(公交、医疗、政务)的端侧 AI 采购可以拿这份基准当谈判起点;但"打平旗舰"的边界也在数字里——离开地铁这个沙盒,优势未必还在。
参考:arXiv:2609.10016(https://arxiv.org/abs/2609.10016);GitHub:continker/metrollm-bench(https://github.com/continker/metrollm-bench)