做售货柜项目最容易被低估的就是“从摄像头到最终识别结果”这整条链路。很多人把精力全压在模型训练上觉得只要YOLO跑通、精度够高就完事了结果一上真机画面卡顿、识别延迟、偶发漏检问题全堆在流水线上。这篇就基于我实际做售货柜识别的经历把“IPC拉流 → 抽帧 → YOLO识别”这条完整流水线从头到尾拆开讲一遍包括为什么这么设计、每一步怎么落地、以及那些不跑真实场景根本发现不了的坑。这套方案适用的场景很明确你手头有一个或多个网络摄像头IPC需要实时分析画面内容而且分析结果直接影响业务动作——比如售货柜判断顾客拿了什么商品、放了什么商品进而触发结算。和纯离线分析不同这里的核心指标不只是“准”还有“快”和“稳”。如果你是做边缘计算盒子、智能货柜、或者任何“摄像头本地推理”项目的开发者这篇内容应该能帮你少走不少弯路。1. 项目整体设计与思路拆解1.1 售货柜识别为什么不是“训练个模型”那么简单售货柜的业务逻辑看起来直白顾客扫码开门 → 拿走商品 → 关门 → 系统识别拿了什么 → 自动扣款。但真正决定体验的是识别结果够不够快。顾客关门后几秒钟内没收到扣款通知焦虑感立刻上来了识别错了客诉和运维成本直接拉满。所以整个流水线的目标不是“能识别”而是“在极短时间内稳定识别出正确结果”。这里面有两层含义。第一层是模型层面的准确率第二层是工程层面的实时性和稳定性。你模型训得再好如果视频流卡顿、抽帧时机不对、推理队列堆积最终效果照样拉胯。我见过不少项目死在工程环节摄像头画面有延迟顾客都关门了识别还在处理几分钟前的画面抽帧没有策略关键动作被跳过漏判了商品推理线程和拉流线程耦合在一起一卡全卡。所以我做这个项目时的总设计原则是每层解耦只管好自己那一件事。拉流只管拉流抽帧只管抽帧推理只管推理中间用队列把数据传递解耦开每层都可以独立调整参数不影响其他层。这样不管是排查问题还是做性能优化思路都清晰得多。1.2 整条流水线的核心链路与关键指标流水线的主链路非常清晰就四段IPC通过RTSP推流 → 设备端拉流解码 → 按策略抽帧 → YOLO推理输出结果。链路短但每一段都有讲究。拉流解决“怎么看”的问题核心是把摄像头的视频流稳定地拉下来不花屏、不卡顿、延迟可控。抽帧解决“看多少”的问题因为售货柜里的商品拿取动作是短时间内的连续行为抽帧不能太稀疏错过关键画面也不能太频繁让算力跟不上。YOLO识别解决“看到什么”的问题这一步要结合业务做取舍不是单纯追求mAP。我给自己定了几项硬指标作为整条流水线的验收标准从顾客关门到收到识别结果端到端延迟不超过3秒目标是2秒以内。推理端单帧处理时间含前后处理不超过100ms。流水线连续运行7天不掉线、不卡死断流后能自动恢复。商品级别的识别准确率不低于95%关键商品被误判成本高的单独验证。后面所有设计和优化都是围绕这几条指标展开的。指标定清楚做什么决策都有依据否则很容易陷入“哪块都改一下、哪块都没改好”的状态。2. IPC 拉流环节完整解析2.1 先从 RTSP 协议说起IPC 怎么把画面“送”出来市面上绝大多数IPC都支持RTSPReal Time Streaming Protocol协议简单理解就是摄像头开了一个“视频直播地址”播放器或程序拿着这个地址去请求视频流摄像头把编码后的画面一帧一帧推过来。RTSP是控制协议真正传视频数据的是RTP一般RTSP地址长这样rtsp://username:password192.168.1.100:554/Streaming/Channels/101不同厂商的路径规则不一样海康的常见格式是/Streaming/Channels/101主码流和/Streaming/Channels/102子码流大华的是/cam/realmonitor?channel1subtype0还有一些厂商直接用/live这种简写。接入新设备第一件事就是去查官方文档确认RTSP路径或者用VLC播放器直接测试能放出来就说明地址没问题。这里有个重要概念主码流与子码流。主码流分辨率高、码率大画质好但占用带宽和处理资源子码流分辨率低、码率小适合预览和轻量分析。售货柜这种场景货道隔层里的商品标签、小体积商品需要看得清所以识别一般用主码流但如果柜子内部空间窄、摄像头离商品近主码流足够了没必要用子码流牺牲画质。2.2 拉流库怎么选OpenCV、FFmpeg、还是厂商SDK拉流方式主流有三种选择各有适用场景方案优点缺点适用场景OpenCV VideoCapture简单几行代码就能读帧内部缓冲不可控、断流重连逻辑弱、CPU占用偏高快速验证、原型开发FFmpeg命令行或libav库解码性能强、协议支持全、可精细控制缓冲封装接口复杂需要自己处理解码循环生产环境、性能敏感场景厂商SDK官方保障、支持私有协议、对接PTZ等功能耦合厂商、不同品牌API不统一单一品牌且需要高级功能时我的建议是原型阶段用OpenCV验证通了再切换到FFmpeg或基于FFmpeg的封装库。直接拿OpenCV做生产最大的问题是你管不了它内部的缓冲行为——后面会讲到这个问题在售货柜场景里是致命的。如果不想从零封装FFmpeg也可以直接调用FFmpeg命令行通过管道输出原始帧或者用Python的ffmpeg-python等封装库但本质上还是绕不开对解码过程的理解。2.3 拉流缓冲导致的“识别延迟”这个问题必须根治这是我踩过最深的坑值得单独拿出来说。OpenCV的VideoCapture在读RTSP流时内部会有一个缓冲队列。它解码出来的帧如果程序处理不及时会堆在缓冲里。这意味着你拿到的“当前帧”其实是几百毫秒甚至几秒前的画面。售货柜场景最怕这个顾客已经拿完商品关门了识别系统还在分析人家开门时的画面结果当然是完全错误的。解决办法是把OpenCV的缓冲压到最小import cv2 cap cv2.VideoCapture(rtsp_url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 把缓冲压到最小但实测下来CAP_PROP_BUFFERSIZE的设置对不同摄像头、不同后端表现不一致并不可靠。更稳的做法是用FFmpeg自己实现拉流解码后只保留最新帧旧帧直接丢弃。思路是这样import ffmpeg import cv2 import numpy as np import threading class RTSPStream: def __init__(self, rtsp_url, target_fps15): self.rtsp_url rtsp_url self.target_fps target_fps self.latest_frame None self.lock threading.Lock() self._stop_event threading.Event() def start(self): self._thread threading.Thread(targetself._read_frames) self._thread.start() def _read_frames(self): probe ffmpeg.probe(self.rtsp_url) # 获取原始分辨率这里省略具体解析 process ( ffmpeg .input(self.rtsp_url, rtsp_transporttcp) .output(pipe:, formatrawvideo, pix_fmtbgr24, rstr(self.target_fps)) .run_async(pipe_stdoutTrue, pipe_stderrTrue, buffer_size10**7) ) while not self._stop_event.is_set(): in_bytes process.stdout.read(self.width * self.height * 3) if not in_bytes: break frame np.frombuffer(in_bytes, np.uint8).reshape(self.height, self.width, 3) with self.lock: self.latest_frame frame.copy() def get_frame(self): with self.lock: return self.latest_frame实际写的时候有几个参数需要重点关注。rtsp_transporttcp建议固定UDP在很多网络环境下会丢包花屏TCP虽然延迟略高一点但非常稳定。r参数用来控制解码输出的帧率如果不需要高帧率这里直接限制住能省不少解码CPU。buffer_size给大一点防止高码率主码流下管道读溢出。注意FFmpeg pipe方式需要手动处理好进程退出和断线重连。简单做法是在_read_frames里捕获读取超时或异常然后关闭进程、sleep几百毫秒、重新启动整个拉流流程思路是“坏了就重启别在原地纠结”。3. 抽帧策略什么时候抽、抽多少、怎么抽最划算3.1 无脑每秒抽25帧算力再强也不够这么造很多第一次做视频识别的人上来就是“每帧都识别”。如果是25fps的摄像头每秒要对25帧跑YOLO推理哪怕用Jetson Orin级别的板子也得掂量掂量更别说现在很多边缘设备用的还是Jetson Nano、RK3588这种级别的算力。售货柜场景根本不需要每帧都识别。顾客从伸手到拿完商品动作再怎么快也得持续几百毫秒商品从货道掉出来到被拿走也是一个可观测的过程。我们的目标是“抽到足够代表关键动作的帧”而不是“抽到所有帧”。这就引出一个核心问题抽帧的密度要和动作的持续时间匹配。太稀疏可能正好错过商品被拿起或放下的那一刻信息丢了无法挽回太密集算力成本上去了收益却有限。我实测下来对售货柜场景3到5帧每秒就能覆盖95%以上的关键动作配合后面的触发机制可以做到不漏检。3.2 从固定间隔抽帧到事件触发抽帧纯固定间隔抽帧有个天然缺陷动作发生在两帧之间时你只能拿到动作开始前和结束后的画面中间的“决定性瞬间”丢了。比如顾客手里拿着商品伸进柜里固定抽帧可能只拍到空手伸入和手拿商品缩回丢掉了手在货道上的位置信息导致判断商品具体从哪个货道取出时出错。所以我采用“基线抽帧 事件触发加帧”的两级策略平时处于待机状态每500ms2fps抽一帧做轻量检测主要判断柜门状态、是否有人手伸入。一旦检测到“柜门打开”或“人手伸入”信号立刻切换到高频抽帧模式每200ms5fps抽一帧持续到关门或人手离开后约5秒为止。这个策略的优点是兼顾了算力和关键事件覆盖率。待机时算力占用极低一旦进入事件窗口识别密度立刻提升确保拿取动作被完整记录。事件信号从哪里来两个来源一是我自己的识别结果第一层轻量模型判断柜门/人手二是硬件IO信号柜锁状态、门磁传感器。如果柜子支持门磁建议直接接入门磁信号作为最可靠的事件源识别结果作为辅助如果没硬件信号就用轻量模型判断。3.3 抽帧参数怎么定给一组可以直接抄的配置以Jetson Nano级别算力、单个货柜、固定枪机为例我实测过一组比较稳的配置参数配置值说明拉流分辨率1920×1080主码流确保小商品清晰抽帧频率待机2 fps用于柜门状态判断抽帧频率事件中5 fps覆盖拿取动作推理输入尺寸640×640YOLO标准输入兼顾精度与速度推理线程数1避免多线程争抢GPU输出帧率上限5 fps后处理完成即可输出不额外积压这里有个小技巧抽帧的坐标可以加一点随机性。不是精确等间隔抽而是在目标间隔附近随机抖动10%。因为商品拿取动作有时候是有节奏感的如果抽帧频率和动作频率偶合可能每个动作周期都在同一位置抽帧导致某些位置永远拍不到。加随机抖动虽然不严谨但实测能减少这种“拍不到”的偶发情况。提示抽帧本身不要搞“复杂逻辑”。真正稳定可靠的方案是“在高频抽帧时简单地丢帧”即解码器输出5fps我全收输出25fps我只取最靠近目标时间点的那一帧。不要做智能选帧——那个复杂度高、收益不稳定。4. YOLO 识别从模型选型、训练数据到业务后处理4.1 轻量级模型怎么选速度和精度如何平衡YOLO目标检测流程这条路目前已经非常成熟。从YOLOv5、YOLOv8到现在的YOLO11官方持续在更新每一代都在速度和精度的平衡上有改进。但在售货柜这种边缘设备上我的选型出发点完全不同——不是“哪个版本最新用哪个”而是“哪个版本在自己的板子上跑得动、准确率满足业务需求”。我的判断标准是单帧推理时间含预处理、后处理必须小于100ms目标是在Jetson Nano级别设备上达到50ms左右。模型大小不超过50MB方便部署和更新。能够通过TensorRT、ONNX Runtime等工具进一步加速。基于这个标准YOLOv5s和YOLOv8n是首选。YOLOv5生态成熟、部署资料多YOLOv8n体积更小、API设计更现代。实际项目里我最终用了YOLOv8n原因是它的训练和导出流程更顺畅还自带实例分割能力如果后面要做更精细的位姿判断同一套体系可以直接升级。如果算力稍微好点RK3588、Jetson Orin等可以试YOLOv8s或YOLO11s精度会有明显提升。但别一开始就追求大模型先跑通流水线后面再迭代升级模型这样风险小得多。4.2 训练数据是最重要的“隐藏瓶颈”不要拿通用数据集糊弄YOLO训练数据标记这件事直接决定了模型的上限。很多售货柜项目用了COCO 80类预训练权重就跑结果发现各种问题商品没训练过的类别不识别同一种商品在不同光照、不同角度下的表现天差地别玻璃柜门反光直接误检成商品。我的经验是至少要自己采集目标场景的数据来微调。具体来说分三步走第一采集真机数据。把摄像头装在实际柜子里在不同时段、不同光照条件白天自然光、晚上柜内灯下拍摄视频。一个格子一个格子的角度都要覆盖到。这一步非常重要因为只有真机数据包含了柜内反光、货道遮挡、摄像头位置偏移等真实干扰训练出来的模型才有实际用武之地。如果项目初期柜子还没就位也可以用IPC模拟器产生带干扰的测试视频但最终模型必须用真实柜内数据验证。第二标注和转换格式。用LabelImg或AnyLabeling这类工具对每一帧里出现的待识别商品画框、打类别标签。售货柜一般就十几二十类商品类别多的话几十类工作量大但必须做好。标注完成后导出YOLO格式每张图片对应一个同名的txt文件里面每行是class x_center y_center width height坐标都用比例值表示。如果是KITTI标注格式转YOLO格式只要做个坐标换算小脚本就好核心是搞清楚两种格式的换算公式纯几何变换不复杂。第三数据增强要有针对性。通用的翻转、旋转、缩放都要做但针对售货柜场景更重要的是模拟真实干扰光照扰动模拟柜内灯不同色温、模糊模拟轻微运动模糊、透视变化模拟摄像头安装角度偏差。我做数据增强时会把同一帧生成几个亮度不同、稍微旋转的版本让模型对真实环境中的微小变化更鲁棒。4.3 一次完整的训练与部署流程参数调优经验直接给YOLOv8的训练流程很标准数据准备好以后配置文件指到数据集路径跑训练脚本就行# 准备数据和配置后命令行直接开训 yolo train modelyolov8n.pt datagoods.yaml epochs150 imgsz640 batch16 device0训练参数里几个关键项我说一下我的经验。epochs别拍脑袋定建议配合Early Stopping使用。如果loss连续20个epoch不下降果断提前停止避免浪费时间还过拟合。batch要看显存定显存不够就调小别硬撑。imgsz用640就行不要为了那点精度上1280推理时间会成倍增加边缘设备扛不住。训练完以后导出ONNX或TensorRT格式用于部署# 导出ONNX格式 yolo export modelbest.pt formatonnx dynamicTrue # 再用TensorRT工具从ONNX转换生成engine文件 trtexec --onnxbest.onnx --saveEnginebest.engine --fp16如果板子是Jetson系列--fp16这步几乎必做推理速度能提升好几倍。要是对精度有信心还可以试INT8量化但激进的量化策略可能导致精度明显下降建议先跑FP16确认精度没问题再考虑INT8。4.4 YOLO后处理不能照搬开源代码必须加业务逻辑YOLO模型输出的原始结果是一个张量需要经过后处理才能得到可用的检测框列表。标准后处理流程包括阈值过滤 → NMS非极大值抑制 → 输出检测框、类别、置信度。但纯标准后处理在业务里不够用我会额外加两层业务逻辑。第一层是类别和位置过滤。售货柜里每个货道能放的商品是提前知道的如果模型在某个位置检出了“不可能出现在这里的商品”要么是误检要么是真有异常。这层过滤很简单维护一个“货道 → 允许商品类别”的映射表推理结果落在某个货道区域时只保留该货道允许的类别。这一步能干掉大量离谱误检。第二层是时序平滑。单帧检测结果跳动很正常前一帧检出商品A置信度0.9后一帧同样的位置检出商品B置信度0.88对于单帧来说都“合理”但从业务角度看就是不稳定。我的做法是对连续帧的检测结果做“类别投票”同一位置的检测框在最近几帧里被识别成哪种类别次数最多就认为是哪个类别。这个轻量级的时序平滑策略能显著降低识别结果来回跳动的现象。YOLO后处理流程在网上有很多开源实现但拿来做内部测试可以上线之前务必要根据自己业务场景做裁剪和增强这是模型能真正落地和只跑通demo的分水岭。5. 整条流水线的工程化实现与性能调优5.1 多线程流水线结构把各环节解耦开前面设计阶段提过“每层解耦”落到代码上就是多线程的流水线结构。我的实现是四线程模型拉流线程负责从IPC读取视频帧写入待处理队列。抽帧线程从待处理队列取帧根据抽帧策略决定是否进入推理队列。推理线程从推理队列取帧执行YOLO检测输出检测结果到结果队列。业务线程从结果队列取结果执行业务逻辑判断拿取了哪些商品、计算扣款金额。线程间通信用队列注意队列长度要设置上限。比如推理队列最多放10帧放满了就丢新帧或者丢最旧的帧不能让请求无限堆积。无限堆积意味着延迟无限增加这在实时系统里绝对不允许出现。队列长度可以根据延迟目标倒推推理速度50ms一帧如果队列里允许积压20帧那一帧从进队列到被处理要等1秒钟这还没算拉流和解码的延迟。所以队列宁短勿长我一般控制在5到10帧之间。5.2 TensorRT加速与性能优化实操性能优化这块TensorRT是绕不开的核心工具。同样的YOLOv8n模型用PyTorch直接推理在Jetson Nano上是200ms级别转成TensorRT FP16后能压到40到50ms用INT8优化后理论上能进30ms。差了近5倍边缘设备上这就是“能用”和“好用”的区别。除了推理加速还有几个容易忽略的优化点第一预处理不要用Python循环。把图像从BGR转RGB、归一化、resize这些操作尽量用numpy向量化或CUDA加速库一次搞定。别一个像素一个像素地处理几百毫秒就没了。第二NMS要选对实现。YOLO后处理的NMS是CPU计算密集操作如果检测目标多纯Python实现会明显拖慢整体速度。用PyTorch自带的torchvision.ops.nms或ONNX Runtime内置的后处理速度能快很多。第三减少内存拷贝。视频帧从解码输出到推理输入尽量复用同一块内存区域。每帧都重新分配、拷贝内存累积起来非常可观。用“帧池”的模式提前分配好N块内存循环使用能明显降低内存抖动。我用TensorRT自带的trtexec工具做模型转换后推理流程简化为“加载engine → 绑定输入输出Buffer → 执行推理 → 取结果”整条链路的CPU占用率明显降下来了。5.3 部署到 Jetson Nano 的避坑清单做边缘部署时最容易踩的坑我整理成了一个清单每个都付过学费Python要用虚拟环境用python3 -m venv建一个专属于项目的环境不要让系统Python环境变成一团乱麻。所有pip包尽量用requirements.txt锁定版本某些包升级后行为变了线上跑着跑着就不对劲了。Jetson上装PyTorch、TensorRT都有专门的版本匹配关系直接pip装容易装到CPU版本速度慢好几倍还不报错。模型更新流程要设计好建议版本号写进文件名部署脚本里指定版本方便回滚。日志要记录拉流帧率、推理帧率、队列积压、推理耗时这几个关键指标出现问题能快速定位是哪个环节掉了链子。5.4 竖屏柜子怎么抽帧、识别和硬件的协同做售货柜项目还会碰到一类特殊需求竖屏柜子比如饮料柜摄像头是竖着装的画面宽高比和普通横屏不一样。这种情况下抽帧和识别依然按完整画面处理但要注意几个点。第一竖屏意味着画面里的商品在垂直方向排列YOLO检测框的高度信息对判断“商品位于哪个货道”更关键。所以后处理里计算货道归属时要优先看检测框的y坐标x坐标作为辅助。第二竖屏画面的像素信息更密集如果分辨率不够小商品可能模糊。这种情况下不建议降低分辨率抽帧硬要保持主码流原始分辨率推理输入尺寸可以考虑保持640不变但注意在预处理时做等比缩放不要直接拉伸变形否则检测框的位置会不准确。第三如果摄像头角度不是正的比如倾斜安装要考虑做一个简单的ROI转换把检测框映射到柜子的标准坐标系里再关联货道。这个映射可以用四点变换实现算法不复杂但能省掉很多“检测到了但算不出是哪个货道”的麻烦。6. 常见问题与排查技巧实录6.1 拉流断线重连、GPU内存泄漏等高频故障跑得久了一些故障会反复出现。这里挑几个典型问题以及排查思路做成速查表现象可能原因排查思路画面卡住不动日志无报错拉流线程死锁或阻塞检查RTSP连接状态确认网络和摄像头在线确认拉流线程是否设置了超时保护运行几小时后内存暴涨帧内存没释放检查是否每帧都新建了numpy数组或Tensor改用帧池循环复用内存推理耗时越来越长GPU显存泄漏或频率下降用nvtop或jetson_clocks查看GPU状态确认TensorRT引擎有没有被反复重建断网后无法自动恢复拉流重连逻辑没写好确保拉流线程能捕获连接异常并实现指数退避重连算法误检率突然飙升光照变化或镜头被遮挡查看抽帧日志判断是否画面质量问题必要时触发重新标定GPU内存泄漏是我踩过最久的坑。排查了很久发现是每帧预处理时创建的Tensor没释放积累了几千帧以后直接OOM。后来改成所有中间Tensor都从预分配的缓存池取问题彻底解决。6.2 抽帧丢帧与“关键动作没拍到”的排查思路如果发现识别结果里漏了某个商品第一反应往往是“模型漏检了”但很多时候是抽帧把关键时刻漏掉了。排查思路是把每次事件的抽帧时间戳和原始视频对比看看关键动作发生时到底有没有抽到对应的帧。我的做法是在推理结果里打上frame_time标签这个时间取自摄像头RTSP流的RTCP时间戳和IPC的系统时间对齐。排查时把同一时间段的原始视频和识别结果放在一起回放一眼就能看出是抽帧丢了还是模型没识别出来。如果确认是抽帧丢了不要盲目提高帧率。先算一下推理队列平均深度如果队列经常空着说明抽帧频率不是瓶颈问题可能在拉流端的解码帧率上。真正要调的是拉流的输出帧率上限把这个提上去抽帧策略不变效果就出来了。6.3 低光环境与反光干扰补光、图像增强与模型侧应对售货柜里低光、反光、玻璃柜门折射这类问题在模型侧也有应对空间。先说明显的低光照下YOLO精度下降是必然的SPP和C2f模块也救不了曝光不足。硬办法是给柜内装补光灯或者把摄像头调成低照度模式。软办法是在训练数据里加入足够多的低光照样本让模型学会在暗光下找商品特征。如果摄像头支持HDR模式打开它动态范围提升后对反光、明暗对比强烈的场景帮助很大。玻璃反光的误检我给出的实际建议是不要试图用模型“认识反光”而是要在ROI上做文章。柜门的反光出现在固定区域直接在抽帧后做ROI掩膜把反光区域抹掉或屏蔽模型根本看不到那里误检自然消失。这比训一堆“反光样本”高效得多。6.4 模型抖动的工程解法类别投票与置信度时序平滑前面提了时序平滑这里展开讲一讲我的实现方法。对每个检测框我维护一个长度为5的滑动窗口记录最近5帧这个位置的类别判断。判断“同一位置”用IoU如果两个框的交并比超过0.5就认为是同一个目标。每来一帧新结果窗口里对应位置加入当前帧的类别投出一票。最终输出的是窗口里票数最多的类别如果票数打平取置信度高的那一票。这个方法解决了一个很烦人的问题置信度阈值设低了误检来回闪烁设高了真目标又稳不住。用时序平滑后阈值可以放宽一些让“不同类别在同一位置反复横跳”这个情况被抑制掉单帧小概率误检会被邻近帧的正确判断“拉回来”整体输出稳定很多。代价是延迟增加了约窗口长度帧的时间。对于售货柜场景5帧约1秒在接受范围内。如果对延迟更敏感的应用可以缩短窗口到3帧效果会减弱一些但延迟更可控。7. 最后分享一个版本管理的经验流水线跑起来以后版本管理这件事千万别忽视。我见过不少人训练了新版模型直接替换线上文件跑不好再换回旧版来回折腾还把日志搞乱了。我的做法是每个模型版本单独建档包含四个文件——权重、配置文件、训练数据说明、验证集评估报告。文件名统一带上版本号比如yolov8n_v3_goods_20250115.engine。部署脚本读这个版本号日志里也打上版本号哪里出问题直接通过日志定位是哪个版本、哪批参数的锅。数据版本也一样。训练数据的图片、标注文件全部放在Git仓库里哪怕数据量大了也尽量用Git LFS管理。这样每次模型迭代数据和代码都能对上号实验可复现性才有保障。别小看这个习惯项目跑半年以后想回顾“上一版指标为什么比这版好”有完整的版本记录一查就清楚没有记录只能靠脑子硬回忆基本等于没有。售货柜识别这件事从外面看是“一个摄像头加一个模型”的事真正做起来是拉流、抽帧、推理、业务逻辑层层叠叠的工程问题。把每一层做扎实、做清晰整个系统的稳定性和准确率自然就上去了。实测下来这套方案的端到端延迟能稳定控制在2秒左右连续运行的稳定性也过了七天以上的验证可以作为同类项目的参考起点。
