门店要不要养一个自己的小模型

先看真实的问题清单

「给门店配一个能问答的助手」这个需求，落到具体场景，通常是三类问题混在一起：

• 查得到答案的：这个商品的保质期几天、退货要带什么、盘点表在哪填。
• 要组织语言的：给新品写一句推荐语、把总部通知改成店员看得懂的说法、把顾客的投诉整理成一条记录。
• 需要判断的：这筐菜还能不能上架、这单该不该退。

第一类不需要模型，需要检索。第三类多半是识别或规则问题，也不是生成模型擅长的。真正落到「语言模型」上的，主要是第二类，以及第一类里那些问法千奇百怪、关键词搜不到的情况。

把清单摊开看一遍，往往会发现：真正需要生成能力的问题，比你想象的少很多。

三条路，三笔账

第一条：云端通用大模型。 起步最快，按调用付费，不用管设备。代价是断网就不能用、数据要出店、答案泛——它不知道你们公司的退换货规则，除非你每次都把规则塞进提示里，而那笔 token 成本会一直存在。

第二条：本地领域小模型。 一次性投入大：要整理领域语料、要标注指令数据、要建评测集、要跑通量化与部署。换来的是断网可用、数据不出店、单次调用没有边际成本。代价是更新——规则改了要重新训、重新发版、重新到店。

第三条：规则加检索。 最便宜，也最可控。答案就在文档里，模型只负责把检索到的段落组织成人话，甚至不组织，直接展示原文。覆盖面窄，但窄得有边界，错了能追到出处。

大多数连锁的实际情况是第三条打底、第二条补位：能查到原文的直接给原文，查不到或者问得太散的，才交给模型组织语言。

容易被漏算的成本

预算表上通常只写「模型训练」和「设备」。真正吃掉工期的是另外几项。

标注数据的质量。 五百条高质量的问答对，比五万条爬来的文本有用。而这五百条要由懂业务的人写，不是外包能批量产的。

评测集。 一百到两百道题，覆盖常见问题，还要有三分之一是「本来就该答不上来」的超范围问题。没有这批题，你无法判断模型是变好了还是只会说得更好听。

版本与分发。 模型是文件，文件要更新。更新怎么到店、什么时候生效、出问题怎么退回上一版，这些流程的成本往往超过训练本身。

多门店的差异化。 如果每家店的促销、商品结构不同，是训一个通用模型加检索，还是每家店一个模型？后者听起来贴心，实际上是给自己造了一堆要维护的版本。

什么情况下别做

问题一年问不了几次。 一张打印出来贴在仓库门后的操作说明，比任何模型都可靠。

答案每周都在变。 价格、活动、库存这些进不了权重，硬训进去第二天就过期。这类信息走检索。

没有维护人。 领域模型是有生命周期的资产，需要有人负责更新语料、跑评测、处理bad case。没有这个人，上线三个月后它就是一个自信的过期文档。

数据量根本不够。 一个只有几十家门店、问题类型不到二十种的连锁，把预算花在识别准确率和收银速度上，回报比养一个模型高得多。

真要做的验收

用领域考卷，不用通用榜单。 一百多道题，从真实问题里挑，标好标准答案。跑分只看这套。

单列拒答。 超范围的问题，它答「不知道」还是硬编一个？这一项比准确率更能说明能不能上线。

测更新。 改一条规则，从改完到店里生效要多久。这个时间决定了这套东西能不能跟上业务。

测断网和连续运行。 拔掉网线还能不能答；连续跑一天，内存曲线是不是往上走。

问清边界。 供应商要说清楚：这个模型能答哪几类问题，答不了的时候走什么路径。说不清的，多半没在真实门店跑过。

一句话

门店不需要一个大模型，也不一定需要一个小模型，它需要的是一个答案找得到、找不到时说得清的系统。模型只是其中一环，前面那层检索和后面那层兜底，往往才是决定好不好用的部分。