1. 出餐口这个场景为什么值得单独做一套视觉质检出餐口是后厨和前厅之间最后一道关口也是整个餐饮链路里最容易被忽视的质检盲区。炒锅师傅把菜盛进盘子的那一刻菜品的最终形态就定型了之后无论传菜员多仔细、服务员多热情都改变不了这盘菜到底合不合格这个事实。我见过太多门店后厨装了十几个摄像头但全部用来做安防录像出了客诉才回去翻录像属于典型的事后取证而不是事中拦截。计算机视觉驱动的菜品质量自动检测核心目标就是把质检动作从人眼抽查变成摄像头全检。具体来说在出餐口上方架一台普通网络摄像头配合边缘计算盒子或者一台带独显的小主机对每一盘经过出餐口的菜品做实时分析判断它是否符合出餐标准。这个标准可以是多层次的摆盘是否完整、主料是否缺失、汤汁是否溢出盘沿、配菜颜色是否正常、分量是否明显偏少、有没有异物混入。一旦判定不合格出餐口的提示灯或者小屏幕立刻报警让传菜员在菜品离开后厨之前就拦下来。这套东西适合谁来参考三类人最需要。第一类是连锁餐饮的运营或品控负责人门店数量上了二三十家之后靠督导巡店根本管不过来需要一套能规模化复制的质检手段。第二类是餐饮SaaS或者智能硬件方向的开发者想找一个计算机视觉落地的垂直场景出餐口质检的边界清晰、数据闭环快、商业价值直接。第三类是做计算机视觉学习、想找一个完整项目练手的人这个场景同时涉及目标检测、实例分割、多模态大模型技术栈覆盖面广而且数据采集门槛比自动驾驶、工业质检低得多。我先把结论放在前面出餐口AI视觉质检在技术上完全可行但难点不在模型本身而在怎么定义不合格和怎么让模型适应每天变化的菜品。很多人一上来就想着训一个YOLO模型识别菜品训完发现准确率上不去问题往往出在需求定义阶段而不是算法阶段。下面我会把整个项目的拆解逻辑、技术选型、实操步骤和踩坑经验完整讲一遍。2. 把菜品合格翻译成机器能算的指标2.1 质检维度拆解从模糊标准到可计算特征餐饮老板说这盘菜不行背后其实是一组具体的视觉特征异常。做视觉质检的第一步就是把这些模糊描述翻译成机器能算的指标。我一般把出餐口质检拆成五个维度每个维度对应不同的视觉任务。第一个维度是完整性检测判断该有的东西在不在。比如一份宫保鸡丁鸡丁、花生米、葱段、干辣椒都应该是可见的如果花生米整盘缺失或者主料明显偏少就属于完整性问题。这个维度用目标检测就能解决检测各类食材实例的数量和面积占比。第二个维度是摆盘规范性判断位置和形态对不对。比如某些连锁品牌要求主料居中、配菜围边、酱汁不挂盘沿。这个维度需要实例分割把每个食材的像素级轮廓抠出来再计算质心位置、外接框比例、与盘沿的距离。第三个维度是色泽与新鲜度判断颜色是否正常。蔬菜炒过头会发黄发暗肉类不新鲜会发灰发褐。这个维度用图像分类或者颜色直方图统计就能做把菜品的HSV色彩空间分布和标准样本对比。第四个维度是分量估算判断够不够量。严格来说这需要深度信息或者参照物但出餐口场景有个天然优势盘子规格是固定的摄像头位置也是固定的所以可以用食材像素面积占盘子像素面积的比例来近似估算分量误差能控制在可接受范围内。第五个维度是异物与异常检测判断有没有不该出现的东西。头发、包装绳、飞虫这类异物用开放词汇目标检测或者多模态大模型做零样本识别比较合适因为异物样本太少训不出稳定的专用模型。2.2 为什么不能只用一个模型打天下新手最容易犯的错是想用一个YOLO模型把所有问题都解决了。我试过效果很差。原因很简单完整性检测需要的是食材类别数量摆盘检测需要的是像素级轮廓空间关系色泽检测需要的是颜色统计异物检测需要的是开放类别识别。这四类任务的输出形式完全不同硬塞进一个检测头里模型会顾此失彼。比较合理的架构是多模型流水线目标检测模型负责食材定位和计数实例分割模型负责摆盘轮廓颜色分析模块负责色泽多模态大模型负责异物和疑难样本复核。每个模块各司其职最后用一个规则引擎把结果汇总成合格/不合格的判定。这样做的好处是每个模块可以独立迭代某个模块升级不影响其他模块工程上也好维护。提示不要一上来就追求端到端的大模型方案。出餐口场景对延迟敏感一盘菜从出餐口到传菜员手里可能就十几秒端到端大模型的推理延迟往往扛不住。多模型流水线虽然工程复杂一点但每个环节都能做到实时。2.3 判定阈值怎么定和门店一起磨出来的模型输出的是概率和数值最终要变成合格/不合格的二元判定中间隔着一层阈值。这层阈值不能拍脑袋定必须和门店的实际标准对齐。我的做法是先采集一批门店认可的标准出品和品控判定为不合格的样本各几百张然后统计每个指标在两类样本上的分布找到区分度最高的切分点。举个例子假设主料像素面积占盘子面积比例这个指标标准出品样本的均值是0.42标准差0.05不合格样本均值是0.28标准差0.06。那么阈值可以定在0.35左右既能拦住大部分分量不足的又不会把正常波动误判。这个阈值还要根据门店反馈持续调整比如某段时间误报太多就把阈值往严的方向挪一点。3. 技术选型检测、分割、多模态各用什么3.1 目标检测选YOLO系列但版本要挑对食材检测是整条流水线的基础选型上我推荐YOLO系列工程成熟度高、部署方便、社区资料多。具体版本上YOLOv8和YOLOv11Ultralytics版本是目前比较稳的选择。YOLOv11在保持速度的同时精度有小幅提升而且Ultralytics的API统一从训练到导出ONNX再到部署一条龙很顺。为什么不选Faster R-CNN这类两阶段检测器因为出餐口场景对速度要求高单帧推理最好控制在50毫秒以内两阶段检测器普遍偏慢。为什么不选DETR这类Transformer检测器精度是不错但训练收敛慢、对小目标不友好而菜品里的花生米、葱花这类小目标恰恰是检测难点。YOLO系列在速度和精度之间平衡得最好而且对小目标的处理经过多代迭代已经比较成熟。训练数据方面食材检测的类别不用一开始就铺很大。我建议先聚焦门店销量最高的20到30道菜每道菜标注5到8类核心食材总共100到150个类别。类别太多会导致模型混淆比如青椒丁和黄瓜丁颜色相近标注时容易标错模型也学不明白。先把高频菜品做扎实再逐步扩展。3.2 实例分割用YOLO-Seg摆盘分析够用了摆盘规范性分析需要像素级轮廓这就轮到实例分割上场。YOLOv8-Seg和YOLOv11-Seg都是现成的选择和检测模型共享同一套训练框架数据标注格式也兼容检测是矩形框分割是多边形。对于摆盘分析来说YOLO-Seg的精度完全够用没必要上Mask R-CNN这种更重的方案。摆盘分析的核心是计算食材之间的空间关系。拿到每个食材的掩码之后可以算质心坐标、外接矩形、面积、与盘子中心的距离、与其他食材的重叠度。这些几何特征组合起来就能判断主料是否居中配菜是否围边有没有堆叠成一团。我实测下来只要分割掩码质量过关这些几何计算非常稳定比直接让模型判断摆盘好不好可靠得多。3.3 多模态大模型做异物复核和疑难样本兜底异物检测是传统检测模型的软肋因为异物种类无穷无尽训不完。这时候多模态大模型就派上用场了。把出餐口的菜品图像送给多模态大模型配上提示词让它判断图中是否有头发、塑料、飞虫等异物零样本就能跑起来。虽然单次推理成本比小模型高但异物检测不需要每帧都跑可以设定为检测模型置信度低时或者每隔N帧触发一次成本可控。多模态大模型还有一个用途是疑难样本复核。当检测模型和分割模型的判定结果矛盾时比如检测说主料齐全但分割发现主料面积偏小可以把图像和结构化结果一起送给大模型让它做综合判断。这种小模型初筛大模型复核的架构在成本和准确率之间取得了不错的平衡。3.4 边缘部署还是云端部署算一笔账出餐口质检的部署位置有讲究。纯云端方案延迟高网络抖动时体验很差纯边缘方案前期硬件投入大但长期看更划算。我的建议是边缘推理云端管理的混合架构。边缘侧放一台带入门级独显的小主机比如RTX 4060级别跑检测和分割模型单店硬件成本控制在几千块。云端只负责模型更新、数据汇总、报表生成这些非实时任务。这样既保证了实时性又保留了集中管理的便利。如果门店规模小、预算紧也可以先用一台高性能CPU做推理把模型量化到INT8速度虽然慢一点但能跑起来等验证了价值再升级硬件。部署方案延迟硬件成本运维复杂度适用场景纯云端高受网络影响低低单店验证、预算极紧纯边缘低高中连锁门店、实时要求高边缘云端低中中推荐方案兼顾实时和管理4. 从零搭建数据采集到模型上线的完整链路4.1 摄像头架设位置和光照决定成败很多人把精力全花在模型上结果摄像头随便一装后面怎么调都调不好。出餐口的摄像头架设有几个硬性要求。第一俯拍角度摄像头要在出餐口正上方偏前的位置俯角控制在45到60度之间这样能拍到菜品的完整俯视图摆盘分析才有意义。第二光照均匀出餐口往往有蒸汽、油烟光线复杂建议加装一个环形补光灯保证菜品区域亮度稳定。第三背景干净出餐台面尽量用纯色避免花纹干扰分割。我踩过的一个坑是摄像头装得太高菜品在画面里只占很小一块小目标检测效果很差。后来把摄像头降到离台面80厘米左右菜品占画面比例上来了检测精度明显提升。所以架设时一定要实际拍几张看看别凭想象定位置。4.2 数据标注类别体系设计比标注本身更重要数据标注是体力活但类别体系设计是脑力活。我的经验是标注之前先和门店厨师长坐下来把每道菜的标准出品拆解成食材清单明确哪些食材是必须可见的哪些是可有可无的。必须可见的食材单独设类别可有可无的合并成其他配菜。标注工具用LabelImg或者CVAT都行检测任务画矩形框分割任务画多边形。标注时要注意两点一是遮挡处理被其他食材压住的食材如果露出面积超过30%就标低于30%就不标避免模型学到不完整的特征二是边界一致性同一个食材在不同图片里的标注边界要统一比如鸡丁就标到鸡肉块边缘不要把旁边的酱汁也框进去。标注量方面每个类别至少300到500个实例高频菜品可以到1000以上。数据增强可以缓解数据不足但不要过度依赖翻转、亮度调整、轻微旋转就够了大幅度的形变增强反而会让模型学到不真实的特征。4.3 训练配置YOLOv11的实操参数以YOLOv11为例训练食材检测模型的配置大致如下。数据集按8:1:1划分训练集、验证集、测试集输入分辨率640×640如果小目标多可以提到960。批次大小根据显存定8GB显存用batch1616GB显存用batch32。训练轮数先设100轮观察验证集指标如果还在提升就继续训。from ultralytics import YOLO model YOLO(yolo11m.pt) # 中等规模速度和精度平衡 results model.train( datafood_detection.yaml, epochs100, imgsz640, batch16, lr00.01, lrf0.01, momentum0.937, weight_decay0.0005, warmup_epochs3, augmentTrue, mosaic1.0, mixup0.1, device0 )学习率用余弦退火策略初始0.01最终降到0.0001。Mosaic增强对小目标检测帮助很大但训练后期建议关掉让模型适应真实分布。训练过程中重点看mAP50和mAP50-95两个指标前者反映能不能检测到后者反映框得准不准。食材检测一般mAP50能到0.85以上就算可用摆盘分割的mask mAP50能到0.75以上就不错。4.4 规则引擎把模型输出变成质检结论模型输出的是检测框、掩码、类别、置信度这些原始结果要经过规则引擎才能变成合格/不合格。规则引擎的核心是一组可配置的判定规则每条规则对应一个质检维度。比如完整性规则检测到的必须可见食材类别数量是否等于标准清单数量缺失任何一个则判定不合格。分量规则主料像素面积占盘子面积比例是否低于阈值如0.35低于则判定分量不足。摆盘规则主料质心与盘子中心的距离是否超过盘子半径的30%超过则判定摆盘偏移。色泽规则菜品区域的平均色相是否落在标准色相区间内偏离超过阈值则判定色泽异常。规则引擎的好处是可解释、可调整。门店反馈误报多直接调阈值就行不用重新训模型。而且每条规则的触发都有据可查方便定位问题。5. 实测中那些文档不会告诉你的坑5.1 蒸汽和油烟是视觉系统的天敌出餐口最大的环境挑战是蒸汽和油烟。刚出锅的菜冒着热气摄像头拍出来一片朦胧检测精度断崖式下跌。我试过几种方案一是加装偏振镜能削弱一部分蒸汽反光但效果有限二是用吹风装置把蒸汽吹散简单粗暴但有效成本也低三是训练时加入模拟蒸汽的数据增强让模型适应模糊图像。实测下来吹风数据增强的组合最实用。吹风装置装在摄像头旁边往出餐台面吹把蒸汽往侧面引开。数据增强方面在训练时随机给图像叠加高斯模糊和半透明噪声层模拟蒸汽效果模型对轻度蒸汽的鲁棒性会明显提升。但要注意重度蒸汽下任何视觉系统都无能为力这时候只能靠物理手段解决。5.2 菜品更新换代比模型迭代快得多餐饮行业的菜品更新频率很高季节菜单、限时新品、配方调整可能每个月都有变化。如果每换一道菜就重新训模型运维成本受不了。我的应对策略是分层处理核心食材鸡、牛、猪、常见蔬菜的检测模型保持稳定不随菜品变化新菜品通过组合已有食材类别来定义比如新菜藤椒鸡丁就是鸡丁藤椒青椒的组合不需要新训模型。只有当出现全新食材时才需要补充训练。这个策略的前提是食材类别体系设计得足够通用。我在项目初期就把常见食材拆成了基础类别而不是按菜品设类别。这样菜品再怎么变底层食材检测模型都不用动只需要在规则引擎里配置新菜品的食材清单和判定规则。5.3 误报比漏报更致命质检系统有个反直觉的规律误报把合格判成不合格比漏报把不合格判成合格更影响系统存活。漏报顶多是没拦住问题菜品和人工质检的水平差不多但误报多了传菜员天天被无端报警很快就会对系统失去信任直接关掉不用了。所以阈值设定要偏保守宁可漏报也不要误报。具体做法是初期把阈值设得宽松一些只拦截明显不合格的样本等系统稳定运行一段时间、积累够反馈数据之后再逐步收紧。同时要提供误报反馈按钮传菜员遇到误报可以一键标记这些反馈数据用来持续优化阈值和模型。5.4 小目标检测的精度提升技巧菜品里的小目标花生米、葱花、芝麻检测一直是难点。除了提高输入分辨率还有几个实用技巧。一是切片推理把图像切成重叠的小块分别检测再合并结果对小目标效果明显但速度会慢。二是专门的小目标检测头在YOLO的基础上增加一个高分辨率特征图检测头专门负责小目标。三是数据层面标注时确保小目标的框足够精确不要因为目标小就随便画个大概。我实测下来把输入分辨率从640提到960小目标mAP能提升5到8个百分点代价是推理速度下降约40%。如果硬件允许这个 trade-off 是值得的。如果硬件紧张就用切片推理只在检测到该有小目标但没检测到时触发切片复核。6. 多模态大模型在质检链路里的正确打开方式6.1 不要用大模型替代小模型而是补位多模态大模型能力强但成本和延迟摆在那里用它做全量质检不现实。正确的定位是补位小模型搞不定的场景交给大模型。具体来说有三个补位点。第一是异物检测前面说过零样本识别异物是大模型的强项。第二是疑难样本复核当小模型判定置信度低或者多个模型结果矛盾时交给大模型做最终裁决。第三是规则生成辅助把门店的质检标准用自然语言描述给大模型让它帮忙生成规则引擎的配置初稿人工再微调。这种架构下大模型的调用频率可以控制在总帧数的5%以内成本完全可接受。而且大模型的输出可以作为银标签反哺小模型训练形成数据闭环。6.2 提示词设计把质检标准说清楚用多模态大模型做质检提示词设计很关键。不要简单问这盘菜合格吗大模型没有你的门店标准答不准。要把标准拆解清楚结构化地喂给它。比如你是一名餐饮品控专家。请检查这张出餐口菜品照片判断是否存在以下问题 1. 异物头发、塑料、飞虫、包装绳等非食材物体 2. 主料缺失菜品名称是宫保鸡丁标准食材包括鸡丁、花生米、葱段、干辣椒 3. 明显异常颜色发黑、汤汁大量溢出、摆盘严重散乱 请逐项判断输出JSON格式{异物: true/false, 主料缺失: [...], 异常描述: ...}这种结构化提示词能让大模型输出可解析的结果方便接入规则引擎。实测下来异物检测的召回率能到90%以上比专用小模型在零样本场景下强不少。6.3 成本控制缓存和批处理大模型调用成本要精打细算。两个实用技巧一是结果缓存同一道菜在相似条件下的质检结果可以复用比如连续几盘宫保鸡丁外观几乎一样没必要每盘都调大模型。二是批处理把多帧图像攒成一批一起送摊薄单次调用开销。这两个技巧结合能把大模型成本压到每店每月几十块的水平。7. 上线之后怎么让系统越用越准7.1 建立反馈闭环让传菜员成为标注员系统上线不是终点而是数据闭环的起点。传菜员每次拦截或放行都是一次标注。我在出餐口屏幕上设计了两个按钮确认不合格和误报传菜员点一下就行操作成本极低。这些反馈数据每天汇总到云端用来做两件事一是调整规则引擎阈值二是筛选出高价值样本补充训练集。这个闭环跑起来之后系统准确率会持续提升。我负责的一个项目上线第一个月误报率15%左右跑了三个月降到5%以下靠的就是这个反馈机制。7.2 模型更新策略小步快跑灰度发布模型更新不要搞大版本一次性替换风险太高。我的做法是小步快跑灰度发布。每次只用新增的反馈数据微调模型训练轮数控制在20轮以内避免灾难性遗忘。新模型先在1到2家门店灰度运行一周对比误报率和漏报率指标不劣于旧模型才全量推送。这样即使新模型有问题影响范围也可控。7.3 和门店运营的配合质检结果要能落地技术做得再好门店不用也是白搭。质检结果要能落地必须和门店的运营动作挂钩。比如每日质检报告推送给店长不合格率高的时段和菜品重点标注连续不合格的菜品触发厨师长复核质检数据纳入门店考核。只有让质检结果产生运营价值门店才有动力配合系统才能持续运转。我见过一个失败案例系统做得挺准但门店觉得多一事不如少一事把报警关了。后来调整策略把质检合格率和门店绩效挂钩配合每周的数据复盘会门店才真正用起来。技术之外运营配合同样重要。8. 一些关于成本和扩展的实在话整套系统的成本我按单店算一笔账。硬件方面摄像头加补光灯加吹风装置一千块以内边缘计算主机带入门独显的三千到五千如果多店共用云端管理云端成本摊薄到每店每月几十块。软件方面如果用开源模型自己训主要是人力成本如果采购现成方案按年付费单店每年几千到一万不等。总体下来单店一次性投入五千左右年运维成本一两千对于中大型门店是可以接受的。扩展性方面这套架构不局限于出餐口。同样的技术栈可以平移到中央厨房的半成品质检、外卖打包的完整性检查、甚至食材入库的新鲜度初筛。核心逻辑都是视觉检测规则判定反馈闭环换个场景只需要重新定义质检维度和采集数据。我目前正在把出餐口的经验往中央厨房复制遇到的挑战主要是半成品形态更不规则、光照条件更差但整体思路是通的。最后分享一个小心得做这类项目先跑通最小闭环再谈优化。不要一上来就追求95%的准确率先用最简单的模型和规则跑起来哪怕准确率只有70%只要能产生价值、拿到反馈后面就有迭代的基础。我见过太多项目卡在追求完美阶段数据采了一堆、模型训了无数版就是不上线最后不了了之。先上线再优化这是我在多个视觉质检项目里验证过的最有效的路径。