图 1 矿区智能安全系统架构1. 起点指标问题不一定是模型问题项目面向人员、安全帽、反光背心、工程车辆、拖鞋和吸烟六类目标。数据来自多个独立来源而每个来源通常只标自己的关注类别拖鞋数据可能只标拖鞋吸烟数据只标手和烟图片中真实存在的人员、安全帽和背心却没有标签。这不是“少了一条标注”这么简单。目标检测训练会把未标注的真实目标当作背景形成错误负监督。联合场景越多监督冲突越严重最终可能表现为不戴安全帽时能检测吸烟戴上安全帽后反而漏检或者拖鞋单独出现能检出与人员、安全帽同时出现时召回下降。因此第一步不是继续调学习率而是确认数据、模型和部署链路各自承担了什么责任。2. Multi-Teacher模型提出证据不修改真值我们从完整六类数据中构建六个单类别训练集并加入一定比例的其他类别图片作为负样本。六个专用 Teacher 分别扫描全量数据降低多类别竞争并允许对吸烟、拖鞋等弱势类别单独校准。图 2 标签证据闭环预测框不会凭置信度直接写入标签。系统先枚举GT0_AUTO0、GT1_AUTO0、GT0_AUTO1、GT1_AUTO1再联合判断IoU两个框整体重叠程度IoS小框被大框包含时比 IoU 更敏感归一化中心距离消除分辨率和目标尺寸差异面积比例区分同目标尺度差异和真正独立目标同类重复与跨类冲突避免把合理嵌套当成重复框。这样才能区分“已经标过”“同一目标框大小不一致”“新的漏标目标”和“Teacher 自己的重复预测”。3. 全量扫描为什么会爆显存和内存六个模型扫描 N 张图片本质上需要完成约6 × N次推理。我们接受总工作量但把峰值资源控制住一次只加载一个 Teacher图片按批次流式读取CUDA 使用 FP16Windows workers0 避免多进程复制OOM 时 Batch 32 → 16 → 8 动态回退每个已提交批次立即写 CSV 与断点状态关键不是“把所有图片装入显存”。显存保存模型参数和当前 Batch 的张量内存保存解码图片、预取数据和临时结构磁盘保存原图、CSV、可视化和断点。把三层资源混为一谈就很难定位 OOM。自适应 Batch 也必须像小事务失败批次不能留下半截 CSV、重复候选或错误断点。只有整个 Batch 成功后状态才提交。4. 从桌面审核到 Spring Boot Vue 多人平台单人使用 CSV 和桌面 GUI 可以工作但多人同时修改 CSV 缺少事务、锁、权限和审计。因此我们把候选任务导入 MySQL并开发了 Spring Boot Vue 3 审核平台。图 3 平台登录页图 4 项目总览平台采用三种互补机制数据库行锁领取任务的短事务中保证同一任务不会被两人同时领取租约与心跳用户关闭页面或断网后任务不会永久占用乐观版本旧页面提交时拒绝覆盖别人已经完成的决定。角色权限之外还需要项目成员关系。一个账号能登录不代表自动拥有所有项目的数据访问权。5. 审核体验也是工程问题最初的“选择决定 → 再确认 → 手动下一条”看起来更安全但每条任务增加两次操作审核量一大就严重拖慢效率。最终工作台采用一键提交、自动前进并以“最近审核可修订”补偿误操作。图 5 真实多人审核工作台图 6 审核生产力设计同一图片的候选框在左侧聚合显示审核员可以在联合场景中判断 person、helmet、smoking 是否属于合理嵌套而不是在割裂的截图里逐框猜测。图片支持适应窗口、原始尺寸和缩放但默认不铺满整个画布避免工具栏和上下文被挤出屏幕。6. 安全写回接受也不等于直接 append审核完成后系统仍然不会修改源数据。写回阶段会检查是否存在未完成或UNCERTAIN决定复制或硬链接形成派生数据集校验类别、归一化坐标和目标标签路径对新增框重新做同类重复检查对替换操作确认源 GT 没有在审核后发生漂移输出应用日志与新数据版本。源数据只读、派生数据可回滚是整个流程最重要的不变量之一。7. 已有运行证据当前协作链路已经完成30,183个候选任务导入平台4,465条历史桌面审核决定幂等迁移两个独立账号在校园网内同时领取和审核真实图片、租约心跳、最近决定修订和按图聚合均完成联调。图 7 生产验证摘要这些证据证明工作流可运行但不能直接证明新版模型指标一定提升。模型收益仍需使用固定 test、分类别 Precision/Recall/mAP以及安全帽吸烟、人员拖鞋等联合场景专项集验证。8. 放回在线矿区监控系统20 路 RTSP 不能按“逐帧同步推理”实现。推荐每路独立拉流只保留最新待处理帧经共享有界队列进入单 GPU 模型实例并使用动态 Batch 提高吞吐。队列满载时主动丢弃旧帧而不是让用户看到几分钟前的“实时视频”。每个结果都必须携带device_id frame_id captured_at。如果前端没有对应帧缓存就不能把旧坐标画到当前画面最稳妥的方式是后端在完成检测的同一帧上画框再推送标注流。吸烟和拖鞋不能单帧即告警。更合理的事件链是局部框与 person 轨迹做空间关联→ 20 秒窗口内多次有效命中→ 严格进入、宽松维持、长时间无命中退出→ 冷却时间与唯一键去重→ 形成告警和工单因此模型 mAP、单帧延迟、事件召回率和端到端告警延迟是四类不同指标。9. RAG没有证据就不要给高风险指令规程文档入库前需要哈希去重、OCR、标题恢复和条款级切片并保留版本、章节、条款号和页码。检索采用向量召回与 BM25 关键词召回再用 RRF 融合和 Cross-Encoder 重排序。高风险答案必须关联有效规程原文证据不足时系统返回“需要人工确认”而不是让大模型补全看似合理的处置步骤。答案同时返回规程名称、章节、页码和原文片段支持追溯。10. Agent大模型负责理解业务代码负责执行Agent 不能直接写数据库。模型只能调用后端暴露的受控工具例如查询规程、读取设备、创建工单和升级告警。Spring Boot 仍负责 JWT、RBAC、状态机、参数校验、事务与审计。所有有副作用的工具调用携带幂等键。高风险动作进入人工审批状态网络超时后先查询执行结果不能盲目再次创建工单。RAG 文档、设备名称和用户输入都视为不可信数据不能改变工具白名单。11. 为什么没有一开始就上 Redis、Kafka 和微服务当前规模下模块化单体和 MySQL 更容易保证事务一致性。演进顺序应该由瓶颈驱动模块化单体 MySQL→ 独立 GPU 推理服务 对象存储→ Redis 承载心跳、事件窗口和热点状态→ Kafka 解耦告警通知、统计和困难样本回流→ 按扩容与团队边界拆分微服务引入 Kafka 时需要 Transactional Outbox 和消费者幂等不能简单“双写数据库和消息队列”。技术栈越多不代表系统越成熟能解释为什么暂时不用同样是一种工程能力。12. 面试时怎么讲30 秒版本核心观点我负责矿区视觉模型的数据治理和多人审核平台。针对多来源六类 YOLO 数据中的联合场景漏标我训练六个单类别 Teacher 全量扫描用 IoU、IoS、中心距离和面积比例识别疑似漏标再通过 Spring Boot、MySQL、Vue 多人平台安全审核与回写形成可追溯的数据闭环。不要夸大的边界当前可以说完成多人协作和双账号验证不能直接说“高并发生产平台”Redis、Kafka、Kubernetes 是演进方案不是当前已落地技术单帧推理延迟不等于 20 路端到端延迟mAP 不等于事件级告警准确率补标完成不等于模型一定提升最终仍由固定测试集证明。结语这个项目真正有价值的地方不是把模型预测自动写成标签而是建立了清晰的权力边界模型提供证据规则解释关系人工授权变化数据库维护协作一致性派生数据集保证可回滚固定评测决定模型是否值得部署。当一套视觉模型具备数据回流、可追溯审核、可靠告警和证据约束后它才从一次训练实验走向可以长期迭代的工程系统。