凌晨两点，某连锁餐饮门店的后厨监控里，一位员工进入画面时没有佩戴帽子。传统摄像头只会录像，普通视觉模型能识别出"有人进入"，但回答不了"这个人是不是违反了操作规范"。就在那一刻，我们正在内测的Ostrakon-VL系统自动从视频帧中提取出关键画面，生成了一条带截图的安全问题工单，推送给当班值班经理。这个项目的全称是"Ostrakon-VL：面向餐饮服务和零售门店的领域专家多模态大语言模型"。它的目标很简单，让大模型不再只会聊天，而是成为真正看得懂门店摄像头、听得懂运营术语、判断得出合规与否的"门店专家"。
这篇文章是Ostrakon-VL从立项、数据收集、模型训练到门店部署整个过程的复盘。我尽量把核心经验、关键参数和踩过的坑都写清楚，适合正在做或准备做多模态落地、零售AI、门店数字化相关项目的朋友参考。如果你想了解的是怎么把一个大模型用到真实的餐饮零售场景里，而不是像演示Demo一样跑通就完事，那这篇内容应该能帮上忙。
1. 为什么餐饮零售需要专属的多模态大模型
先讲一个让我印象深刻的例子。通用大模型在互联网图片上见过无数漂亮货架，但给它看一张门店摄像头俯拍的真实货架照片，它经常分不清"缺货空位"和"正常陈列的留白"；给它看一段收银台视频，它分不清顾客是在刷脸支付还是在拿手机拍照。不是模型不够聪明，而是它训练时看到的画面和门店摄像头看到的画面，根本不是同一个世界。
1.1 通用模型在门店场景的"水土不服"
通用多模态模型确实很强，能识别物体、能描述场景，但放到餐饮零售门店环境里，问题很明显。
第一，视角差异大。通用模型的训练图像大多来自日常拍摄的平视画面、物体特写，甚至高清艺术图片，而门店摄像头是俯视、广角、低照度、鱼眼镜头，视角完全不一样。模型在平视视角学到的"货架层板"概念，遇到俯视画面就很容易认错。
第二，场景非常垂直。门店里有大量专业概念，比如"沽清""排班""损耗""效期管理""陈列面"。这些词在普通图文资料里出现少，通用模型根本不知道是什么意思。你跟它说"这张图里有哪些商品需要补货"，它可能只告诉你"这张图里有几瓶饮料"，却不知道某款饮料已经低于安全库存线了。
第三，细粒度动作判断能力弱。门店管理不只是"看到什么"，更重要的是"这个动作有没有违规"、"这个状态是否正常"。通用模型可以告诉你"有人在切菜"，但很难判断"切菜的人有没有按标准戴手套"。这类判断需要结合门店SOP，而SOP在互联网语料里几乎不存在。
从成本角度看，直接调用通用大模型接口来做门店场景分析，不仅单次调用贵，而且效果差，经常需要人工二次确认。所以项目组从一开始就定下方向：做一个"懂门店"的领域专家模型，而不是继续用通用模型硬凑。
1.2 餐饮零售场景的核心痛点是"识别+判断"的组合
餐饮服务和零售门店的AI需求，绝大多数不是"识别是什么"，而是"识别之后还要判断该不该处理"。我随手列几个真实场景：
- 食品安全类：后厨员工未戴帽子、生熟砧板混用、垃圾桶未盖盖、地面水渍未及时清理。
- 门店运营类：货架缺货、价签错位、促销物料过期未撤、冷柜温度异常。
- 顾客行为类：排队过长、人群异常聚集、顾客跌倒、入口拥堵。
- 员工操作类：收银漏扫、商品未扫码进系统、巡检路线遗漏。
这些场景没法用单纯的目标检测模型解决。目标检测模型能告诉你"画面里有一个垃圾桶"，但回答不了"垃圾桶盖子有没有盖好"。纯语言模型又没有视觉输入，无法看到画面。只有视觉和语言结合起来的多模态大模型，才能完成"检测到目标 -> 理解动作 -> 对照SOP -> 输出结果"这一整条推理链。
1.3 领域专家模型的边界：不是万能的
做领域专家模型不代表要把所有能力都塞进一个模型里。我们在项目里把Ostrakon-VL定位为"可交互的视觉大脑"，而不是"实时视频流处理器"。
门店的监控摄像头一般每秒25帧，如果每一帧都丢给大模型做自回归生成，就算有再好的GPU也撑不住，成本直接爆表。我们最终的架构是"传统检测器负责实时触发，Ostrakon-VL负责关键帧语义判断"：先用轻量级目标检测模型实时扫描视频流，当检测到特定目标或事件时，才截取关键帧，送到Ostrakon-VL里做深度推理。这个架构很多人一开始没想明白，总想着端到端一步到位，结果延迟和成本双双失控。
领域专家模型的另一层边界是"它只对它见过的场景负责"。不同业态的门店差别极大，奶茶店、便利店、快餐店、正餐店的货架和后厨完全不一样。Ostrakon-VL在正餐店学到的"砧板混用"判断逻辑，放到奶茶店并不适用。所以模型发布时必须按门店业态做版本管理，不能一个模型包打天下。
2. 数据工程：从门店视频到高质量训练集
业界总说"模型设计决定上限，数据质量决定下限"，这句话在Ostrakon-VL项目里得到了非常充分的验证。前期我们花在数据上的时间占了整个项目周期的一半，后面训练和调优反而很快。如果你的数据做不好，后面一定会用无数个加班的夜晚来还。
2.1 采集与脱敏：安全合规是第一道红线
做门店视频AI，第一个要过的不是技术关，而是合规关。人脸信息属于敏感个人信息，门店摄像头采集的视频在用于模型训练之前，必须完成脱敏处理。我们没有把原始人脸数据用于训练，统一在采集端做模糊框和像素化处理，同时限定采集区域，避开更衣室、卫生间等敏感隐私区域。
采集策略上，我们做了三件事。第一是视角覆盖，门店里有顶装摄像头、收银台平视摄像头、后厨吊顶摄像头、仓库高位摄像头，每种视角都不能漏，否则部署时换个角度模型就傻眼。第二是时间覆盖，早中晚、晴雨天、节假日、高峰与非高峰时段都采样。第三是门店业态覆盖，快餐、茶饮、便利店、商超各来一批，宁可每一类门店的数量少一点，也要保证业态多样性。
最终我们采集了300多家门店、累计上千小时监控视频，清洗后形成约12万张关键帧和6000条分钟级视频片段。这个数据量放到通用大模型面前不算大，但覆盖足够广，训练出来的模型在真实门店里表现相当稳。
2.2 指令数据设计：让模型学会"回答门店问题"
模型要能回答门店问题，首先得有配套的指令数据。我们构建了三类指令数据：
描述型指令，比如"描述这张图里货架上的情况"。这类指令让模型学会把像素转化为结构化文字，重点是"看到什么说什么"，不做过多的主观判断。
判断型指令，比如"根据这张图判断该员工是否佩戴了帽子""这个垃圾桶是否已经满溢"。这类指令直接对应业务场景，要求模型输出明确结论，最好还能给出置信度。
推理型指令，比如"如果发现后厨地面有水渍，可能会有什么风险？应该怎么处理？"这类指令训练模型的业务思维，让它不只做识别，还能做简单的风险评估。
三者的比例一开始我们设置得比较均衡，后来大量badcase显示推理型数据太多时，模型会输出很长的建议但抓不住重点，甚至产生幻觉。于是我们把判断型指令比例提上去，占总量60%，描述型占20%，推理型占20%。调整之后，模型输出变得克制，线上可用性明显提升。
这里有一个特别容易踩坑的细节：判断型指令的参考答案，不能光靠算法团队标。算法标注员会从"图像里能不能看到特征"出发，但门店SOP是允许业务弹性的。比如部分岗位在低峰期可以不戴帽子，有客人投诉风险时才强制；再比如垃圾桶半满在一些小店是可以接受的，但星级门店要求见底即清。如果我们不把这些业务规则写进标注规范，模型学到的是"非黑即白"的标准，实盘误报率会高到门店店长直接想关掉系统。
2.3 负样本与难例挖掘
门店场景里长尾问题极其严重。缺货、价签倾斜、垃圾桶满溢、促销物料过夜未撤，每一个具体问题出现的频率都不高，但加起来占运营问题的比例很高。模型如果只见过高频正样本，很容易对长尾问题视而不见。
我们用了两条腿走路的方案。第一，难例挖掘：先用初始模型在大量未标注视频上做预测，把"模型高置信度但其实是错分"的样本捞出来，人工标注后加入训练集。第二，人工构造困难样本：随机改变亮度、对比度，模拟摄像头污渍、雨雾天气，甚至加一点高斯噪声，让模型见过足够多"不清不楚"的画质。
数据增强幅度要控制好，不是越狠越好。我们把亮度扰动控制在正负20%，噪声方差控制在0.02以内。增强太猛会把"脏数据"引入训练，导致模型在画质稍差的场景里疑神疑鬼。这一点是用一次痛苦的回滚换来的。
3. 模型选型与训练框架
数据准备好之后，到了模型方案选择和训练的环节。Ostrakon-VL不是从零训练，而是基于现有的开源视觉-语言基座做领域微调。这样做省时省力，也符合绝大多数中小团队的资源现实。
3.1 基座模型怎么选：先看任务复杂度再看算力
我们对比了两条路线。一条是用单纯的目标检测模型，另一条是用视觉-语言多模态大模型。检测模型精度很高，在COCO这类数据集上刷点很快，但它不能理解语言指令，也无法回答"这个画面符不符合SOP"这种复合问题。多模态大模型能理解指令，但默认对门店场景不敏感。
最后我们选了多模态路线，具体基座选了参数量在70亿级别、视觉编码器与语言模型结构均衡的开源模型。为什么不选更大的？因为我们最终要在门店本地服务器部署，参数量越大，显存和延迟压力越大。而且大量实验证明，领域微调比堆参数更有效。与其上几百亿参数的模型然后费劲压缩，不如先用一个中等规模基座把领域能力做扎实。
3.2 训练方案：两阶段微调，别学别人堆阶段
常见的多模态模型训练流程会拆成三个阶段：预训练阶段对齐图文特征，指令微调阶段做对话能力训练，对齐阶段结合人类反馈调整输出。我们实际做下来发现，第三阶段在门店场景收益有限，反而容易把模型带偏，所以Ostrakon-VL主流程分成两个阶段：
第一阶段是领域视觉-语言对齐。目标是让模型适应"摄像头图像+门店术语"的分布，主要用门店图片和对应的描述文本做训练，这一步的收益是让模型不再把摄像头画面当成"陌生图片"。
第二阶段是指令微调。这是核心阶段，用大量带业务SOP的指令数据微调适配层，让模型学会"看什么、答什么、怎么判断"。我们试验过同时训练整个模型，也试验过只训练低秩适配器。结论是LoRA方式的训练更稳，既节省显存，又能保留基座模型的通用能力。
3.3 关键训练参数复盘
直接放一组我们最终稳定运行的关键参数，供参考：
- 视觉编码器权重冻结，只训练语言模型和连接部分的LoRA层。
- LoRA秩设为16，alpha设为32，作用目标是query、key、value和全连接层。
- 分层学习率：LoRA层用3e-4，语言模型其余层用1e-5，视觉投影层用2e-5。
- 优化器用AdamW，批大小16，训练轮数3个epoch。
- 上下文长度1024 tokens，对于门店指令完全够用。
- 采用早停法，验证集损失在第三个epoch后开始反弹就立即停止。
训练数据采样比例是另一个容易忽略的细节。我们对三类指令做了比例控制，描述型20%、判断型60%、推理型20%。如果推理型数据比例太高，模型会输出很多"正确的废话"；如果描述型数据比例太高，模型学会了写小作文，却答不对关键判断题。判断型指令做主体，线上体验是最稳的。
3.4 对齐策略：如何让模型理解"摄像头角度"
通用模型看到的图像大多是正常拍摄的照片，门店摄像头却是俯视、广角、低照度，甚至鱼眼镜头。最开始我们试过把鱼眼图展开成全景图，也试过对摄像头图像做透视校正，效果都不理想。后来发现，与其做那么多预处理，不如把原始门店图像直接放进训练集，让模型自己学镜头畸变和视角规律。
这个转变背后的逻辑很简单：预处理做多了，会丢失真实场景里的噪声特征，部署后遇到摄像头抖动或低照度画面，模型会不知所措。直接在原始分布上训练，模型会把"俯视货架""鱼眼畸变""低照度"当作正常的视觉规律来学习。实测下来，部署到真实门店后的鲁棒性比做了大量预处理的方案好了不止一个档次。
4. 落地部署与推理优化
模型在实验环境里跑出好效果只是第一步，真正让Ostrakon-VL产生价值的是部署到门店后的稳定表现。这一章节会讲到边缘部署怎么压性能、模型迭代怎么闭环、以及如何跟现有业务系统做集成。
4.1 边缘部署约束和优化路径
门店的算力环境比云端差很多，通常是一块消费级显卡或工业级工控GPU，显存普遍在8GB到24GB之间。如果把Ostrakon-VL的基座模型按16位浮点直接部署，显存压力非常大，推理延迟也扛不住。
我们做了三件事优化。第一，模型量化。最终采用4-bit量化，把模型体积压到接近原来的四分之一。量化不是无脑全量化，视觉编码器部分我们保留更高的精度，否则容易出现"模型能听懂话但看不清图"的问题。第二，推理加速。用支持连续批处理和KV Cache复用的推理加速框架，显著提高并发吞吐，避免排队导致的抖动。第三，请求过滤。不是所有请求都进大模型，前置用轻量级检测器把大部分无效画面过滤掉，只有触发了事件关键帧才调用Ostrakon-VL。
实测效果：单张图片的视觉问答在云端GPU服务器上约180毫秒，在门店工控机上约700毫秒。如果做视频事件分析，整体延迟可以控制在1到2秒内，因为不需要逐帧推理。
4.2 迭代闭环：从badcase到模型更新
模型上线后，badcase是必然存在的。重要的是建一条能快速吃进badcase、反哺模型训练的闭环。我们搭建的流程是：
- 门店端自动上报badcase，包括漏检的缺货图片、误报警的事件截图。
- 人工按业务影响度给badcase打标，分严重、一般、可忽略三档。
- 每周把新增badcase和难例挖掘数据合并，做增量训练，只更新适配层。
- 验证通过后灰度发布，先只对少量门店开启新模型，观察误报率变化。
- 确认没问题再逐步扩大范围，同时配置中心保留旧版本开关，随时可以回滚。
这里最痛的一个教训是"灰度发布"不能省。我们曾跳过灰度，直接全量更新了一版模型，结果某类门店由于装修风格和货架颜色差异，误报率飙升，店长群投诉爆炸。从那次以后，所有模型更新都必须走灰度流程。
4.3 与现有零售系统的集成
Ostrakon-VL不能只做成一个"AI玩具"，必须接入业务系统才能产生实际价值。我们做了三块集成：
- 视觉问答API：店员可以在移动端拍一张货架照片，直接问"这张图里哪些商品需要补货"，模型会返回带商品名称和位置的结果。
- 事件订阅推送：当模型判断出"后厨员工未戴帽""仓库门长时间未关"这类事件时，自动推送到摄像头系统、工单系统和值班经理手机。
- 日报表聚合：每天把各门店的事件类型、数量、发生时段聚合成运营日报，供区域经理查看趋势。
事件推送的时机很有讲究。刚开始我们所有告警都直接推给店长，结果店长一天收到几十条消息，产生了严重的"狼来了"效应，反而忽略了真正的风险。后来我们根据时段和事件重要度做了过滤：高峰期的食品安全类事件直接推送，低峰期的事件则汇总到早晚班报表里。告警量降了约七成，店长的响应度却明显提高了。
5. 踩坑记录与排查技巧
最后这部分，我整理了一些Ostrakon-VL落地过程中最常踩的坑和对应的排查方法。这些经验都是拿真实门店运营数据换来的，希望能帮你省掉一些不必要的加班。
5.1 五个高频问题与对策
我把问题、原因和解决方案整理成一张速查表，方便对照：
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 模型对未见过的摄像头视角泛化差 | 训练集视角覆盖不足 | 训练数据保留多种摄像头视角，包括鱼眼和俯视 |
| 推断时出现幻觉，把不存在的东西说成存在 | 视觉特征与文本指令错位，低光照下尤为明显 | 在提示词里加"仅根据图像事实回答"，提高判断型指令占比 |
| 误报率在部分门店特别高 | 新店装修风格、货架颜色与训练集差异大 | 按门店聚类做分层采样，为高风险门店单独补数据 |
| 微调后模型连基础常识都答不对 | 领域数据过多，导致灾难性遗忘 | 微调时混入5%通用对话数据，或用LoRA保留基座权重 |
| 高峰期推理服务延迟不稳定 | 没有做请求排队和并发限制 | 增加轻量级检测器前置过滤，限制大模型并发请求数 |
5.2 排查方法论：先看数据还是先看代码
遇到模型效果不好，很多人第一反应就是调学习率、改模型结构、加卷积层。我的经验是，先别急着改代码，先去看数据，把badcase拿出来，一帧一帧过。
我习惯把badcase分成五类：标注错误、指令描述歧义、图像质量问题、领域知识缺失、模型能力不足。前四类加起来往往占80%以上。有一次模型在商场店频繁把"促销海报"识别成"价签错误"，排查了很久，最后发现训练集里的红色海报样本标漏了，导致模型把红色元素当作异常来报。补了几百张海报样本之后，准确率直接提升了5个百分点。这类问题靠调模型参数是永远解决不了的。
5.3 项目复盘：三个最值钱的决定
复盘整个Ostrakon-VL项目，有几个决定现在看来最关键。
第一个决定是"不与通用大模型比广度，只在门店场景做到足够准"。这意味着我们愿意牺牲掉通用聊天能力，把模型做成一个"固执的门店专家"。
第二个决定是架构上采用"检测器+大模型"两级方案。没有一头扎进所谓的实时视频大模型，省了大量推理成本，也让项目能在门店现有硬件上跑起来。
第三个决定是让业务同学参与数据标注规范制定。算法同学闭门造车标注出来的数据，往往和真实SOP差着十万八千里。业务同学参与之后，判断型指令的答案才真正符合门店实际。
最后再分享一个小技巧。模型上线的第一个月，我们每天会挑一个门店，打开Ostrakon-VL的日志，把模型输出的判断与真实的视频回放做比对，用Excel手动标记对错。这个动作看起来非常原始，但比任何自动化指标都更能暴露问题。很多隐藏很深的badcase，就是在这样笨拙的人工比对里被发现的。如果你也在做类似的门店多模态项目，建议尽早让业务角色参与数据定义，尽早搭好badcase回收链路。模型能力固然重要，但真正决定项目价值的，是你对场景的理解深度，以及把错误样本快速吃回来的能力。
