垃圾分类这事看着简单落地做系统的时候才知道水有多深。传统摄像头加人工盯屏的方式在垃圾投放量大的社区和转运站基本属于“看不过来也管不住”。我接到这个智慧城市垃圾分拣系统项目的时候第一反应就是不能只靠单一模型硬扛识别——垃圾类别多、形态杂、场景光照乱纯视觉模型很容易栽在易混淆物上。最后敲定的方案是 YOLO 目标检测负责快速锁定目标DeepSeek 大模型负责结合场景做二次推理一快一慢组成“视觉认知”双引擎。这篇文章把我从架构设计到实际部署踩过的坑完整整理出来给准备做类似识别检测系统的朋友一个可参考的闭环范本。1. 项目整体设计与方案选型1.1 一组模型解决不了的垃圾分类问题垃圾分类检测如果只是简单归类最常见的结果就是识别率在测试集上很好看一上真实场景就崩。我在这类项目上吃亏的次数不少总结下来核心矛盾有三个类别粒度细、场景差异大、样本分布极不均匀。先说类别粒度。生活垃圾里“纸盒”和“纸袋”是两个类别“塑料瓶”和“塑料罐”也不能混为一谈。目标检测模型擅长找“目标在哪”和“目标像什么”但要精准区分高相似度子类需要投入大量精细化标注数据。社区投放点往往是居民手里拎着垃圾袋直接丢袋子把里面的东西遮掉大半模型只能看到一个鼓鼓囊囊的黑袋子——这种场景下别说子类区分主类别都难判断。再说场景差异。上午九点阳光直射投放点、傍晚路灯下的黄暖光、阴天时雨棚内的散射光同一瓶矿泉水在不同光照下对模型来说可能就是两种东西。再加上居民投放姿势多变、垃圾在桶内堆积重叠模型能持续稳定输出的难度非常大。最后是样本分布。容易误分类的“易腐垃圾包装物”组合、黏着食物残渣的塑料盒、沾了饮料的纸杯这些恰恰是实际分类督导中最高频的纠错对象。可这类“脏样本”在网络公开数据集里极少需要自己补采才有效。单一视觉模型做成全品类的想法在实验室跑通很容易扔到现场就撑不住。这是我在技术选型阶段最深刻的一条体会。1.2 YOLO 负责“看见”DeepSeek 负责“思考”既然单模型搞不定就需要分工。我的做法是让 YOLO 承担目标检测这一层负责从画面里找出垃圾目标输出检测框、类别标签和置信度。DeepSeek 则作为认知推理层接收 YOLO 的结构化检测结果结合投放点场景、垃圾特征描述、督导规则做语义层面的分类校准和处置建议。这个分工的底层逻辑是视觉模型缺乏“常识推理”能力。YOLO 看到一个“白色塑料瓶状物”它只知道这在视觉特征上接近某个训练类别并不知道“矿泉水瓶”和“饮料瓶”在可回收物体系里大概率归同一类也不知道如果瓶子里还有半瓶液体时应该提示先清空再投放。而 DeepSeek 这类大模型具备的知识推理能力刚好能补上这一环。举个例子。YOLO 的输出是“类别塑料瓶置信度0.82”。如果只靠视觉模型这个结果就是终点。但接上 DeepSeek 之后系统会拼出这样一段上下文“在小区集中投放点摄像头检测到透明塑料瓶瓶内有残留液体标签为塑料瓶。请结合城市生活垃圾分类标准判断该物品归属分类并输出投放指引。若存在预处理需求请明确说明。”DeepSeek 会回答“属于可回收物需清空内容物后投放至可回收物容器”并且可以继续追问容器颜色、投放口编号等具体督导信息。这已经不是单纯的目标检测而是从“识别”走向了“辅助决策”。我选择的组合是 YOLOv8s 系列模型加 DeepSeek 的在线 API 调用。原因有三个YOLOv8s 在边缘设备上推理速度与精度比较均衡DeepSeek 的开放接口成本可控、文本推理质量稳定两者结合不需要自己训练大模型工程成本最低。1.3 端边云三层协同架构整个系统我没有做成“摄像头直连大模型”的形态那样对网络带宽和推理成本都是灾难。实际落地的架构是标准的三层协同边缘层部署 YOLO 模型完成实时目标检测。摄像头画面在本地直接推理输出结构化检测结果。云端层部署 DeepSeek 大模型调用服务接收边缘层上传的检测结果与必要图像信息完成二次分类决策。应用层大屏看板、督导员工作台、告警推送、数据统计报表。边缘层用本地算力消化视频流解决了大模型处理视频流的延迟和成本问题。云端层只在边缘层判定“存在疑似垃圾目标”时启动单次调用拉起的文本推理延迟可以控制在两秒内。对于投放点督导场景受众本来就是投放后等待反馈的居民这个延迟是完全可以接受的。三层架构的另一个好处是容错。极端情况下云端不可用边缘层直接返回 YOLO 的原始分类结果顶多是细分类精度下降系统不至于全瘫。2. 数据集准备与 YOLO 模型训练细节2.1 垃圾数据收集与标注重点模型训练之前数据这块我把总时间的三分之一以上都砸进去了。垃圾分类检测的数据准备有两个关键覆盖面要广、脏样本要够。公开数据集我融合了三个来源加起来有效图片大概一万六千张涵盖塑料瓶、玻璃瓶、纸箱、纸袋、易拉罐、塑料袋、果皮、剩饭、烟蒂、电池、灯管、药品等二十八类常见垃圾。但公开数据集普遍存在一个通病——太干净了。要么是单目标居中构图要么是背景纯色直接拿这样的数据训练出来的模型到现场就是睁眼瞎。所以我额外做了一个动作补采实景脏样本。找了一个实际运营中的社区投放点用项目装的摄像头视角连续采集了一周素材每天覆盖早中晚三个时间段专门保留那些光照复杂、垃圾挤压变形、包装与内容物混合的场景。补采了大约三千张实景图片标注工作量不小但对模型落地贡献最大。标注工具用的开源标注软件类别体系严格按照项目立项时的垃圾分类目录来定没有用网络数据集自带的标签体系。这一步非常关键如果标签命名不规范后面模型评估和 DeepSeek 联调都会很痛苦。我建议所有类别同时维护“代码标签”和“中文别名”比如recyclable_bottle_pet对应“可回收塑料瓶”做映射表统一管理。每类样本量我控制在最低八百张、核心易混淆类别两千张以上。没有做人为的类别数量平均化垃圾数据天然就是长尾分布塑料瓶、纸箱这类高频目标数据多反而是好事烟蒂、药品这类低频目标数据少也符合真实频率重点是通过难例挖掘提升低频类别的检出率。2.2 数据增强与难例挖掘策略数据增强这一块遵循“适度原则”用得太狠反而有害。我启用了以下几项增强策略每一项都有明确的目的马赛克增强模拟垃圾堆积时多目标互相遮挡的情况提升模型对拥挤场景的适应力。随机仿射变换与透视变换贴近居民投放时垃圾从各个角度进入镜头的实际情况。亮度与色彩扰动覆盖白天黑夜、晴天阴天、日光灯与暖光灯下的色偏差异。随机擦除模拟部分遮挡防止模型过度依赖局部纹理特征。单项都很常规重点说一下难例挖掘。模型训练到第一轮结束之后把验证集里置信度低于 0.5 的检测结果全部导出人工筛查哪些是真正的难例——比如被塑料袋半遮半掩的纸箱、堆叠在一起的两个同色饮料瓶。这些难例单独建一个难例集在第二轮训练时调高采样权重效果比盲目增加总数据量明显更好。加得太多会伤害模型的特征学习尤其是马赛克增强如果训练数据里拼接痕迹太重模型容易学到“拼接边界”这种假特征反而降低真实场景的泛化能力。所以增强比例不是越高越好巡回测试后我基本把增强强度和图像质量压在一个平衡点。2.3 关键训练参数与评估口径YOLOv8s 是我最终选定的型号训练参数按长期迭代的实践经验来定仅供参考。输入分辨率用 640对投放点这种中近距离监控场景足够batch size 取 16配合单一训练卡epochs 设置 200但启用了早停机制验证集 mAP 连续三十个 epoch 不上升就提前结束初始学习率 0.01配合余弦退火策略优化器用 SGD模型收敛更稳定。实际训练时有效 epoch 大约在一百四十轮左右就形成了收敛。最终评估结果mAP0.5 达到 0.913mAP0.5:0.95 超过 0.672。这个数字在公开测试集上已经能用但真正让我放心的是混淆矩阵——易混淆类别的交叉率控制在了低水平比如纸盒被误判成纸袋、塑料瓶被误判成易拉罐的情况明显减少。最后一步我把模型导出为 ONNX 格式再转到 TensorRT 做 FP16 量化部署。量化之后推理精度几乎无损速度提升却非常可观换来了边缘端实时性的大幅改善。整个过程踩了不少坑后面会用一整节专门讲。3. YOLO 与 DeepSeek 协同实现3.1 视觉结果如何“翻译”成大模型输入YOLO 输出的原始结果是结构化数据类别编号、置信度、四个坐标值。这种格式大模型没法直接用必须转换成自然语言描述。我写了一个专门的结果组装模块功能是按业务场景把单帧检测结果拼成一段标准化的文本描述。组装逻辑分成三个部分。首先是场景信息固定前置提示词说明当前频道对应的投放点位置和摄像头角度。然后是检测目标列表按置信度降序排列记录每个目标的数量、类别、相对图像位置。最后是交互指令明确提出“请判断可回收物类别、投放容器类别以及是否需要预处理”三项任务。一个实际拼出来的 Prompt 长这样当前场景为社区东门垃圾分类投放点。摄像头检测到以下垃圾目标 - 塑料瓶 x2置信度 0.84位于图像中央偏右 - 牛皮纸袋 x1置信度 0.78位于图像左下角 - 一次性塑料餐盒 x1置信度 0.62位于图像右上角内含食物残渣 请基于生活垃圾分类标准完成以下任务 1. 判断上述每一类垃圾的回收属性可回收物/厨余垃圾/有害垃圾/其他垃圾 2. 给出对应的投放容器颜色或名称 3. 若需要预处理清空、冲洗、拆解等逐类说明 4. 输出格式为每个目标的独立条目不要汇总这段 Prompt 写清楚之后DeepSeek 的返回质量稳定非常多。最开始我舍不得让 YOLO 输出包含位置信息以为大模型用不上坐标。后来发现在某些组合场景里位置信息很重要——比如两个目标重叠时模型可以通过位置关系判断哪个物体被遮挡推理结果更准确。所以坐标信息建议保留哪怕只是粗略的方位描述。3.2 并发调用与结果缓存机制投放点高峰期是早晨七点到九点和傍晚六点到八点这两个时段摄像头可能在一分钟内连续触发十几次检测。如果每个检测结果都同步调用一次 DeepSeek API延迟会叠加接口也容易被限流。我的方案是三层处理第一层边缘端做结果合并。同一目标在连续十帧内被检测到且类别没变化就视为一次稳定检测只向上汇报一条消息。这样就过滤掉了大量重复调用。第二层云端做短时缓存。两分钟内收到相同类别、相同来源地点不同摄像头则重新判断的重复消息直接返回缓存结果。缓存键由“点位编号目标类别置信度分档”三个字段拼接命中率大概在百分之四十上下。第三层做异步批量封装。触发数量多且缓存未命中的场景改为批量组装 Prompt一次请求同时推理多个目标接口返回结果再拆分。实测单次批量请求处理四个目标与逐个请求四种情况相比总耗时减少约一半费用也低很多。3.3 大模型“兜底”规则与降级策略大模型能力再强也不能轻信它每次返回的格式。我在对接 DeepSeek 时还做了一层硬编码规则兜底专门应对两种情况一类是接口异常另一类是返回格式错误。接口异常用的策略是单次调用超时时间设置为三秒失败后重试两次重试间隔按指数退避。如果三次都失败系统直接采用 YOLO 的原始分类输出作为结果并标记“低置信度-离线模式”推送到督导员工作台。这样无论云端怎样波动投放点的基本交互能力不会断。格式错误更麻烦。比如 DeepSeek 返回的内容里本该输出“塑料瓶可回收物”它却输出一段完整的自然语言段落“根据某某分类标准塑料瓶通常属于可回收物建议投放至蓝色可回收物容器”。这种回答信息是对的但成文格式不适合直接做结构化解析。我补充了一个结果解析层用关键词匹配加正则提取把答案转成统一的 JSON 结构解析不成功时强制走默认规则。这里提醒一句把大模型输出直接当结构化数据用是最容易翻车的设计。必须有解析层和默认值兜底两头都锁死。4. 部署实录与智慧城市落地场景4.1 边缘端硬件选型与性能实测我做了三轮硬件选择测试。第一轮用普通 PC 工作站跑 TensorRT性能完全够但体积和功耗不适合点位安装。第二轮用树莓派级小主机功耗是降下来了但 YOLOv8s 在 FP16 下推理一帧要两百毫秒以上高峰期并发不够用。第三轮换到了 Jetson 系列边缘计算设备视频流推理稳定在一百毫秒内的水平最终锁定这个方向。选型时重点看三个指标算力、显存、视频解码能力。测试用的配置是 8GB 内存版本的 Jetson 模组。实际表现TensorRT FP16 优化后的 YOLOv8s 模型单帧推理耗时约 55 到 80 毫秒接入摄像头实时流后端到端检测延迟在三百毫秒以内。如果是两个摄像头同时接入会通过分时复用处理高峰时段少量丢帧但核心检测能力稳定。4GB 内存版本也测过速度略慢预算紧张时可以考虑但单摄像头没问题、双摄像头会吃紧。摄像头这块反倒是最容易忽略的部分。投放点的摄像头安装高度我建议控制在两米五到三米俯视角度三十到四十五度。太高了目标太小YOLO 对小目标的检出率会明显下降太平了又会拍到大量无关背景增加误检。焦距方面用 4 毫米或 6 毫米定焦都可以优先保证目标大小占画面比例不低于百分之五。4.2 社区投放点与中转站的两种落地形态我在项目里同时跑了两种场景玩法完全不同。社区投放点是“面向居民”的引导模式。摄像头在投放口上方实时检测居民拎垃圾袋靠近时系统自动识别袋内可见物品在屏幕上显示分类建议。识别到可回收物时会提示“请投放至蓝色容器”识别到厨余垃圾时会提醒“请破袋后投放”。这个场景要求反应快、提示直白居民停留时间往往只有几秒拖沓的交互流程完全不行。DeepSeek 在这里主要做误差修正和知识增强比如 YOLO 识别为“陶瓷碗碟”时DeepSeek 会补上“该物品不属于常规生活垃圾分类请投入其他垃圾”的处理结果。环卫中转站是“面向运营”的审计模式。垃圾车卸料时上方摄像头连续抓拍系统统计各类垃圾占比评估前端分类质量。这个场景不追求单个目标的实时推理而是要在几分钟内完成数百个目标的统计汇总。我的做法是抓拍帧做抽样检测每三十秒抽一帧积累一小时数据进行聚合。被检测到的目标全部批量上报给 DeepSeek 做细分类审计输出一份“本时段误投比”报表。运营人员据此调整前端宣传策略和督导点位。4.3 数据闭环从识别结果到督导工单分类识别不是终点把识别结果变成运营动作才是闭环。我给系统设计了一套简单的工单生成规则如果 DeepSeek 判定某类目标属于“高价值可回收物混入其他垃圾”系统自动生成一条督导工单记录投放时间、点位编号、检测类别、置信度。督导员在手机端看到工单之后可以选择“已现场处理”或“标记无效”。所有工单数据回流到统计报表作为点位分类质量的评估依据。这个规则跑起来之后的价值远超我预期。它不只能做实时反馈还能做趋势分析——比如某点位连续一周傍晚时段频繁出现“塑料瓶混入厨余垃圾”的情况系统会自动提高该点位该时段的督导优先级。让识别系统从“监控工具”变成了“管理抓手”。隐私这块也必须做。摄像头只保留触发检测前后两秒的缩略图用于审计超过二十四小时自动删除完整视频流不存储。所有上报到大模型的文本内容只包含类别、位置、置信度等级不附带人脸或可辨识个体的图像信息。这个做法既符合数据合规要求也减少了居民对隐私的顾虑。5. 常见问题与排查技巧实录5.1 YOLO 目标漏检、误检高频根因现场跑起来之后排障最多的还是视觉模型的漏检和误检。我把高频原因归成三类对应给了不同的解法。第一类是光线不足导致漏检。夜间时段摄像头补光不足目标特征整体变暗YOLO 的置信度会直线下降。解决思路是加装红外补光灯并给摄像头切换成黑白夜视模式对比度反而比强行保留彩色更高。同时针对夜间的检测阈值适当降到 0.35白天保持 0.5两个时段采用不同阈值。第二类是目标过大或过小导致的误检。居民整袋投放时垃圾袋占据了画面近一半YOLO 对过大的目标反而会裁剪出局部特征把一整袋混合垃圾识别成其中一种。处理办法是把大目标按网格切分成多个子区域分别检测再汇总结果而不是直接整袋判断。这个逻辑在垃圾袋场景下特别好用。第三类是类别靠得太近导致的混淆。饮料瓶和易拉罐、纸盒和牛皮纸袋视觉特征有时极其接近。我的方法是给模型加一个“相似类别分组”逻辑YOLO 输出置信度低于 0.6 且命中的目标恰好属于相似组内类别就转给 DeepSeek利用材质、重量、图像上下文和投放习惯做二次判断而不是让视觉模型硬扛。5.2 DeepSeek 接口超时与限流的实战对策高峰期被限流是最常见的问题。第一次上线时没有做限流保护直接十分钟内触发了一百多次请求结果回落稳后系统五分钟内基本瘫痪。后来我实现了限流前置策略思路是“边缘端能决策的不上云云上能批量的不单发”。具体做法是调整级联触发条件。只有置信度介于 0.5 到 0.8 之间的“灰色地带”结果才发送给大模型置信度高于 0.8 的强置信结果直接采用 YOLO 的识别结论置信度低于 0.5 的结果标记待人工复核不上云。这样大模型的调用量直接砍掉六成以上同时不影响准确率。超时方面也做了细调。DeepSeek 接口在高峰期响应时间可能从平时的一秒多涨到五秒以上如果按三秒超时去设就会频繁走降级。我的做法是把超时上限放宽到八秒但调用改为异步边缘端先返回 YOLO 原始结果给客户展示大模型结果出来后再通过消息队列补充推送。用户看到的结果不会因为等待大模型而延迟大模型的修正建议在后续几秒内静默叠加。5.3 部署性能从 TensorRT 到帧推送策略部署阶段性能优化的核心就是 TensorRT这步不做边缘端实时性就是空谈。导出 TensorRT 引擎时最容易犯的错是用固定尺寸导出导致模型输入只能接受 640x640一遇到其他分辨率输入就报错。我建议直接导出动态 batch 和动态尺寸版本虽然构建时间稍长但现场接不同摄像头时灵活多了。推流这块我吃过亏。最初视频流是“每帧都推理”结果边缘端负载直接拉满设备温度过热掉性能。后来改成“目标区域触发推理”先用轻量级背景建模判断画面是否有变化有变化才启动 YOLO没有变化直接跳过。这个策略让推理负载降了约百分之七十长时间运行时设备温度稳住了。还有一个小技巧抓拍时间戳一定要统一。不同通道传上来的检测结果时间戳如果不一致批量统计时会出现同一个目标被重复算作两个的情况。我在边缘端统一用本地时钟校准再上传云端聚合风控和数据口径从此干净了。6. 落地经验这些细节让我少走了很多弯路做完整套系统之后体会最深的是“视觉模型和大模型的划分边界”要提前想清楚。YOLO 做不好的是细粒度语义区分DeepSeek 做不好的是视觉空间定位。强行让任何一方干对方的活都会得到糟糕的体验。我最后画了一条清晰的边界所有需要“看”的交给 YOLO所有需要“想”的交给 DeepSeek中间用标准化的 JSON 结构传递结果。内容解释层值得花时间打磨。我第一次做接口语义化时只传类别名大模型回答质量飘忽不定。后来把置信度、位置、数量甚至疑似遮挡信息都加进去DeepSeek 给出的分类建议就明显更有针对性。大模型不是不能干活是你要给它足够上下文它才能给你高质量回答这对做视觉语言融合项目的人来说尤其重要。最后再说一条分布式部署下所有组件都要有降级方案。我见过不少项目把宝全押在大模型接口上接口一抖整个系统跟着瘫。其实大模型在这个架构里是“增强层”而不是“依赖层”跑不起来时系统回到传统视觉模式跑起来时锦上添花。这个思路让整个系统在真实环境里扛住了几个月的高强度运行还没有发生过一次全链路中断。目前这个项目已经在几个投放点连续运行了大半年日均处理识别请求上千次高峰期实时响应稳定垃圾分类准确率达到预期。系统结构做好了后续要扩展到建筑垃圾监管、河道漂浮物识别这类场景也就是换数据集和换 Prompt 模板的事骨架完全不需要重搭。这也是我对这套“视觉大模型”架构最满意的地方。
