做门店数字化改造这几年我见过太多模型现场翻车的名场面。拿一个通用多模态大模型MLLM去识别货架上的某个具体SKU它会非常笃定地告诉你那是一瓶常温水但实际上那是一瓶气泡饮料让它读价签上的小字它把生产日期和保质期混到一块儿最离谱的一次让它核对堆头陈列数量它数出来的数字比实际多出一倍。问题根本不是模型不够聪明而是它压根没在门店这种环境里受过系统训练。这就是我推动 Ostrakon-VL 项目时最想解决的核心问题把多模态大模型打磨成餐饮零售领域的专家而不是一个什么都会一点、一落地就露馅的通才。这篇文章不打算堆概念我会把从技术选型、数据工程、训练流程、评测体系到部署落地这条链路里的关键决策和踩过的坑原原本本捋一遍。项目开发过程中踩的坑不少但回头看的经验都是有价值的值得认真沉淀下来这篇就当作一次系统复盘也希望能给正在做行业大模型落地的同行一些参考。1. 通用多模态大模型做餐饮零售时到底哪里不对劲1.1 视觉感知的颗粒度跟不上门店需求通用多模态大模型在互联网图文数据上训练擅长的是描述画面内容回答常识问题。但门店场景里大部分任务要求的是字段级的精确理解而不是语义级的概括理解。价签上的价格是¥12.50还是¥12.90差四毛钱就可能引发结算纠纷生产日期是20240908还是20240809数字顺序稍有差错就涉及食品安全合规冰柜里被霜雾盖住的标签、饮料瓶身被冷凝水模糊的批号这些都是通用模型训练数据里极少出现的脏样本。通用模型见惯了高清、干净、居中的商品图到了低对比度、小字号、遮挡的实拍场景性能断崖式下跌是必然的。一句话概括通用模型的视觉能力是看懂图门店要的是看清图里每一个字、每一个数字。这两种能力的训练目标完全不同数据分布也完全不同指望通用模型直接胜任是不现实的。1.2 业务语言和产品知识是硬缺口餐饮零售行业有自己的一套黑话和知识体系。门店员工说效期指的是保质期到期日先进先出是补货原则排面指货架陈列的规范状态。这些词在互联网公开语料里出现频率并不高通用模型很难准确理解它们的业务含义。更硬核的是商品知识缺口某个SKU是冷藏品还是常温品、某款调味酱是否含过敏原、某个品类的典型保质期是30天还是180天、同一品牌不同系列的包装差异在哪里。这些知识散落在商品资料库、供应商手册和门店运营材料里并不在通用模型的预训练语料覆盖范围内。我问过通用模型某品牌低温酸奶在0-4度条件下通常保质期多久它给了一个模糊的大约21天的答案而实际业务口径是18天。这种偏差在闲聊里无伤大雅在合规审查里就是事故。1.3 真实环境的干扰远超实验室想象实验环境用标准机位、均匀光照、干净背景测出来的效果到了真实门店基本都要打折重测。日光灯频闪、货架层板遮挡、标签贴歪、金属包装反光、热食区蒸汽、冷链区霜雾这些干扰因素组合起来会让同一件商品在不同门店、不同角度、不同时段成像出完全不同的样子。我们在项目早期犯过一个错误在样板间里把Demo跑得行云流水觉得这事成了。结果把同样的模型拿到三家真实门店一测识别准确率掉了将近20个百分点。这个教训让我们从此立下一条规矩跑通Demo不算成功能在真实门店五花八门的成像条件下扛住才算。整条技术路线的设计事实上都是围绕鲁棒性和精确性两个词展开的。2. Ostrakon-VL的技术选型基座模型、视觉编码与领域专家定位2.1 基座模型怎么选开源权重与训练成本的平衡项目启动时第一个被反复讨论的问题是为什么不用公开的通用多模态API而要自己训练一个模型答案有三个层面的考量。数据合规层面门店摄像头采集的画面里包含顾客走动、员工操作、后台收银等敏感内容频繁外发给云端API既不可控也有数据安全风险。定制空间层面做领域专家模型需要改数据分布、做偏好对齐、调输出格式闭源API只能通过提示词做浅层约束无法触达模型内部。成本层面门店摄像头每天产生海量画面按调用量计费的商业模型在规模化之后成本根本兜不住。所以基座只能选开源权重体系。选型时我们对比了当时主流的开源MLLM权重最终决策权重最大的三个因素中英文能力都要过硬因为门店标签经常是中英混排视觉编码器支持高分辨率输入社区生态完整方便做后续的量化部署。这里有个实战经验值得分享挑选开源基座不要只看综合榜单分数要看它在代理任务上的表现比如文档OCR、细粒度计数、小字识别。我自己建了一个几十条的门店小测试集把所有候选模型先跑一遍用分数说话比看任何榜单都靠谱。2.2 视觉分辨率与OCR能力的架构取舍通用MLLM为了控制算力成本通常会对输入图片做大幅降采样常见的是224×224或336×336。这个分辨率在识别价签小字、包装成分表、生产日期喷码时是致命的——字根本看不清再好的语言模型也白搭。Ostrakon-VL在视觉输入端做了针对性的分辨率增强对输入图片做区域切分和分块放大让每个局部块都获得充足的像素密度同时保留全局图用于理解版面结构。这个设计能有效提升细粒度文字识别能力代价是视觉token数量显著增加推理变慢。我们最后的折中方案是按任务调分辨率交互式任务比如门店员工拍一张照片问这个商品过期没有用较粗的分块保证响应速度批处理型任务比如货架盘点扫描用最细粒度分块换精度。这个策略在落地阶段帮我们同时保住了体验和效果。2.3 为什么走领域专家路线而不是通用助手这是项目定位层面最关键的决策。市面上不少团队做行业模型思路是做一个更通用的模型靠堆数据量取胜。我们的判断完全不同餐饮零售场景的容错率太低准确率要逼近99%才有商业价值而99%的准确率只能靠把模型的注意力收敛到一小簇核心任务上才能逼近。领域专家路线的含义很直白模型不需要会写诗、不需要知道各国的首都但它必须能精确识别几万个食品SKU、看清价签上的每一个字符、对熟食的熟度给出接近老店员水准的判断。术业有专攻这在AI落地里同样是铁律。通用助手面对一个模糊问题可以绕弯子、给免责声明但业务系统需要的是稳定、精确、可预测的输出哪怕代价是牺牲掉一部分泛能力。3. 数据闭环门店真实数据与合成数据如何配合3.1 真实数据的采集、脱敏与合规真实门店数据是项目的地基也是最难搞的部分。门店合作方要愿意开放场景采集设备要部署得低调、不能影响正常营业图像里还可能出现顾客人脸、员工操作、交易小票等敏感信息合规处理必须彻底。我们的做法是在合作门店的货架、收银台、后厨操作间部署摄像头连续采集若干自然周的影像然后做两阶段脱敏第一遍用程序自动打码人脸和交易小票上的敏感字段第二遍由人工抽检确认脱敏效果。所有数据只进入私有训练环境训练完的中间产物按周期销毁不进公共存储。这套流程听着繁琐但涉及真实业务数据时必须守住底线没有讨价还价的余地。3.2 用通用大模型造领域训练数据真实数据标注的成本高得惊人。一张堆满几十种商品的货架图完整的细粒度标注需要半小时以上人力开销根本撑不起几万条的量级。我们的补充手段是一条合成数据流水线。先把商品详情页图片和产品资料图整理成标准图库然后用程序化方式生成任务样本比如把价签文字用不同字体、字号、透明度合成到各种背景上批量生成读价签训练数据再比如把单个SKU抠图后随机贴到货架背景里生成SKU识别计数样本。另外我们还用通用MLLM对真实门店图片做弱标注初稿再由人工修正把标注成本压缩了将近一半。合成数据最大的风险是风格漂移——模型在干净的合成图上表现很好一到真实光线和噪声环境就失灵。为了对抗这个问题我们定了一条三七开原则合成数据负责扩充数量真实数据负责锚定真实分布两类数据必须在同一个batch里混合训练谁也不能偏废。3.3 任务模板体系把门店问题翻译成模型问题把五花八门的门店需求变成可训练、可评测的标准任务是数据工程里最见功力的环节。我们拆出了十几个标准任务模板核心的几个是SKU识别输入商品图输出标准商品名、品牌、类目价签标签OCR输入价签图分别抽取价格、生产日期、保质期、品名效期核验输入商品包装图判断是否临期或过期并输出判断依据堆头计数输入陈列图统计画面中某类商品的数量陈列合规输入货架图判断排面是否符合先进先出等管理规则菜品识别与属性抽取输入菜品图输出菜名、主要食材、可能致敏原。每个模板配了独立的提示词模板和JSON输出约束。好处是训练数据的格式高度规范模型输出能被业务系统稳定解析坏处是模型在开放式问答上会显得僵硬。所以我们在任务数据之外又混了一部分多轮闲聊式泛化数据让模型在完成标准任务的同时不至于失去对话能力。3.4 标注规范和质量控制标注是数据工程的最后一公里也是最容易翻车的一环。我们的实践包括三个层面每个任务模板都编写详细标注手册附正例和反例截图实行双层抽检制度标注员自检之后质检员按10%比例抽检抽检不通过就返工重标对价格、日期这类高风险字段做双人独立标注加不一致仲裁。这套制度听着不性感但它能把标注错误率稳定压在1%以下。数据质量不过关后面所有训练都是白搭这一点怎么强调都不过分。4. 训练全流程继续预训练、指令微调与偏好对齐4.1 领域继续预训练先把行业语言灌进去训练的第一步不是调多模态能力而是做文本侧的领域继续预训练语料包括三类商品百科和产品资料库覆盖数万个SKU的品名、规格、储存条件门店运营手册、食品安全规范、零售管理SOP行业论坛和问答社区里关于菜品、食材、库存管理的讨论内容。继续预训练的好处是成本相对可控只用文本数据不涉及视觉语言对齐但收益很直接。做完这一步模型在餐饮零售话术上的接续生成能力明显变好更重要的是为后续指令微调储备了领域知识底子。如果跳过这一步直接做多模态指令微调模型很容易出现会看图但说不清专业名词的半吊子状态。4.2 多模态对齐与指令微调接下来是两阶段的视觉语言训练。阶段A用大量图文配对数据做对齐让视觉编码器输出的特征与语言模型的嵌入空间更好对接数据主要是商品图加标题简介、门店场景图加场景描述。阶段B用第3节里的任务模板数据做指令微调让模型学会看图之后输出规定格式的JSON。训练中一个很实际的坑是损失函数类别不均衡OCR任务生成的字符序列很长loss占比天然偏高容易把SKU识别这类短输出任务压住。我们的解法是按任务分组加权的采样策略——每个任务根据上一轮loss做归一化后再作为采样权重让尾巴任务也能获得足够的训练比重。技巧本身不复杂但对最终多任务效果的均衡性影响非常大。4.3 偏好对齐减少胡编乱造的OCR结果无论是通用MLLM还是领域MLLM幻觉都是大问题。门店场景最不能忍的幻觉是读错数字还一本正经这比识别不出来更危险因为业务系统会把错误结果直接当成正确结果处理。我们引入了一轮偏好对齐训练构造偏好数据对对同一张图让模型生成多个回答人工把准确且完整的答案标为优选把缺字段或编造数字的答案标为劣选然后用DPO方法做一轮轻量对齐内部权重控制得很小防止破坏前面阶段学到的指令遵循能力。效果最明显的变化是模型在不确定某个字符时从硬编一个数字变成如实说无法确定并建议重新拍摄。这个行为转变在业务侧价值巨大因为它把模型从不可信的自动机变成了会自我怀疑的助手。4.4 训练稳定性与复现性的几个细节多模态训练的稳定性问题比纯文本训练更突出踩过几次坑之后总结出几个实测有效的要点学习率要设置得比同等规模纯文本模型明显更低否则视觉编码器容易发生灾难性遗忘混合精度训练时视觉编码器部分最好保持高精度权重更新能有效缓解小数字字段的数值精度损失checkpoint保存频率要短多模态训练下loss曲线可能突然出现尖刺能回滚到尖刺前一版省下来的重训时间相当可观。还有一条是对齐阶段的顺序不能乱先做文本侧继续预训练再做视觉语言对齐最后做指令微调。我们曾尝试把文本预训练和指令微调合并执行以节省时间结果模型学会了输出格式但领域知识明显薄弱最后只能推倒重来。5. 领域评测体系用数据证明专家而不是靠感觉5.1 评测集设计不能只挑好看的样例评测集是领域专家模型的质检尺设计得不好训练就被带偏。我们搭了一套三层评测体系。第一层是小而快的回归集约200条典型样本每次训练完快速跑一遍用来发现明显的性能回退。第二层是覆盖12个任务模板、约5000条样本的完整领域评测集一半来自真实门店采集一半来自刻意构造的对抗样本比如贴歪的标签、昏暗灯光下的价签、反光包装的特写。第三层是人工跟测每周从真实门店新场景中抽30条跑一轮人工打分防止模型在固定评测集上过拟合出虚高分数。5.2 指标定义与基准对比不同任务的指标不能一刀切这是评测设计里最容易被忽略的。价格和日期属于高风险字段必须按字段级F1来算SKU识别关注排序能力要用Top-1和Top-5计数任务用平均绝对误差陈列合规这类主观判断任务则与督导员判断一致性挂钩。任务核心指标合理目标SKU识别Top-1准确率 / Top-5召回率90%以上 / 97%以上价签OCR价格、日期、品名字段级F195%以上效期核验二元分类准确率98%以上堆头计数平均绝对误差不超过1陈列合规判断与督导员判断一致性92%以上和通用MLLM基线对比时结论并不意外通用模型在描述画面内容这类开放任务上表现尚可但在精确读取数值多物体计数行业术语输出上全面落后。差距最大的是价签OCR的字段级F1通用模型普遍比Ostrakon-VL低了20个百分点以上。这个差距也反向验证了领域专家路线的必要性。5.3 人工评测与bad case复盘只看指标会骗人。我们坚持每周做一次bad case复盘把评测中所有错误样本捞出来人工分类是OCR漏字、是领域知识错误、还是提示词歧义导致的输出格式错误。一个高频发现是不少所谓模型错误其实出在数据标注端——模型学对了数据标错了。这类样本修正后重新评测整体准确率往往能涨一到两个百分点。这一步的价值是双向的既磨模型也磨数据。评测体系的最终目的不是打一个高分交差而是形成评测—归因—修正—重测的飞轮让数据和模型一起滚起来。6. 部署落地量化推理、系统集成与业务兜底6.1 端云部署取舍与推理优化部署形态取决于门店的网络和设备条件。有稳定宽带的门店以云端推理为主模型热更新方便网络差或者断网时段边缘端小模型兜底只上传关键结果。我们在这两条线上都做了实践。边缘端部署的核心工作是量化。把权重压缩到INT8精度后模型体积缩减到原来的四分之一左右单次推理速度明显加快算力要求也降到了门店边缘设备可以接受的范围。量化带来的精度损失必须用完整评测集复测我们定的标准是关键指标下降超过一个百分点就退回高精度方案。另外还专门为了倾斜视角和广角畸变做了数据增强让模型对非标准机位拍摄的图片也能稳定输出。6.2 与门店管理系统的集成边界模型再好也要嵌进业务流程里才能产生价值。我们把Ostrakon-VL的输出接入了门店现有的管理模块效期核验结果自动写入货架管理流程临期商品生成下架或促销任务SKU盘点结果与库存记录做差异比对超过阈值自动发送复核工单价签OCR用于线上菜单和线下价签的一致性巡检。集成的时候划了一条清晰的边界模型的输出永远作为建议而不是决策。所有自动操作前面都加一道规则校验或人工确认环节。原因很朴素——模型在极端场景下罕见新包装、撕毁一半的标签、全新未录入的SKU还是会错业务链路必须能容忍这种小概率错误绝不能让模型输出直接触发资金操作或安全动作。6.3 实测中的典型误判与业务兜底上线后的数据盘点出几类高频误判写出来给大家做个参考反光透明瓶身导致OCR把0读成8价格字段出问题多个同系列不同口味的产品相邻摆放SKU识别互相串味堆头被顾客的手或身体挡住一部分计数持续偏低生鲜熟食的新鲜度判断与人工打分差异较大主观性太强。针对这些误判我们做了三层兜底。第一层是置信度阈值模型输出置信度低于设定值时直接转人工处理不让低质量结果流入业务流。第二层是多帧融合让摄像头连拍多帧再做投票或取众数显著降低单帧偶然误差。第三层是字段级规则校验OCR出的价格和日期先过正则和范围规则不符合常识就直接拒绝接收比如价格超过该类商品合理区间或者日期格式不符合业务规范。这套兜底组合上线后真正抵到业务侧的严重错误比例降了一个数量级。模型依然不是完美的但业务链路已经不太在意它是不是完美了——因为系统知道怎么和它的不完美共处。最后再分享一个我的实际体会。做领域专家MLLM最大的难点其实不在模型本身而在于能不能把业务场景翻译成一套可训练、可评测、可部署、可兜底的系统工程问题。Ostrakon-VL这个项目走下来我们反复确认的第一原则是模型只是整个工程闭环里的一环数据、标注、评测、部署兜底哪个环节掉链子模型再先进也白搭。如果你也在做类似的行业大模型落地建议从一开始就把这条闭环搭完整把评测当成头等大事而不是等训练完了再补课。
