回答项目问题时始终遵循四段：业务风险、技术取舍、失败边界、验证证据。不要把技术栈逐项背诵，也不要把规划能力说成已经上线。
我负责矿区视觉模型的数据治理和多人审核平台。针对六类 YOLO 数据中 person、helmet、smoking、slipper 等联合场景漏标，我训练六个单类别 Teacher 全量扫描，用多几何量和分类别阈值生成候选，再通过 Spring Boot、MySQL、Vue 平台进行原子领任务、租约续期、版本校验和审计式纠错，最终安全生成派生数据集，源标签始终不变。
- 漏标不仅是少一个框，还会把真实目标作为背景参与训练，形成错误监督。
- 多类别模型本身受不完整标签影响，因此使用单类别 Teacher 分别发现候选，但不把预测当真值。
- 候选通过 IoU、IoS、中心距离、面积比、重复和跨类冲突分类，再按分类别阈值进入审核。
- 全量推理采用单模型串行、流式图片、FP16、动态 batch 和事务式断点，解决显存与内存峰值。
- 多人平台用行锁防同时领取、租约防永久占用、乐观锁防旧页面覆盖、唯一键防重复导入、审计日志支持纠错追溯。
- 已在 30,183 条任务和双账号校园网协作中验证工作流；模型收益仍必须用固定测试集和联合场景专项集证明。
多类别模型正是从不完整标签训练出来的，容易继承类别竞争和漏标偏差。单类别 Teacher 能独立生成每类证据并分别校准阈值，特别适合小目标和联合场景。但单类 Teacher 也会受域偏移影响，所以仍需要几何关系、人工审核和固定测试集。
置信度是模型内部排序信号，不是正确概率。域偏移、重复框、框尺度分歧和跨类别合理嵌套都会产生高置信错误。项目把高置信度看作更强证据，AUTO 也先经过统计校准和可选共识门控；最终写回权限由审核决定和安全写回阶段控制。
当小框完全位于大框中时，交集很大但并集由大框主导，IoU 可能偏低。IoS 用交集除以较小框面积，可以发现包含关系；中心距离判断两个框是否围绕同一位置；面积比区分轻微尺度偏差和严重不一致。四者联合后，能更稳地区分已标、同目标歧义和真正不同目标。
是，计算量约为 K x N。优化目标不是消灭必要计算，而是控制峰值资源并保证可恢复：显存一次只保留一个模型和一个 batch；内存保存路径、当前 batch 和当前类别标签缓存；候选持续落盘。这样牺牲部分切换时间，换来可预测的显存上限和失败隔离。
失败 batch 在候选 CSV、标签和断点全部提交前不算完成。OOM 后清理当前结果、减半 batch 并重跑，成功后才推进状态。如果输出已经写完但断点未更新，稳定候选键和精确标签行会让重放保持幂等。
- 行锁保护领取事务的毫秒级竞争，防止两人同时拿到同一行。
- 租约保护跨请求的分钟级临时所有权，浏览器退出后任务会过期回收。
- 乐观锁保护提交时的旧状态覆盖，客户端必须携带当前版本。
三者解决不同时间尺度的问题，不能只说“用了数据库锁”。
这个规模对 MySQL 并不大，关键在查询路径、约束和事务边界。领取使用 (project_id, state, lease_until, id) 复合索引和短事务；同图候选、最近审核有对应索引；唯一键承担最终幂等。当前瓶颈更可能在审核吞吐和图片读取，不应为了技术栈丰富过早引入 Redis 或 Kafka。
核心界面不是通用 CRUD，而是图像画布、同图多框、快捷键、一键保存、租约和历史纠错组成的专用交互。整体迁移会增加依赖和回归成本，却不会自动提高审核吞吐。管理后台未来出现复杂表格和表单时，可以按页面选择性引入组件库。
不能用训练损失或几张可视化证明。必须固定 train/val/test，比较新旧模型的全局和分类别指标，并建立安全帽+吸烟、人员+拖鞋、远距离小目标专项集。还要检查误报、漏报和阈值敏感性，确保 val/test 没被补标过程静默污染。
先排查数据划分泄漏、重复图片、评测标签质量和类别映射；再看分类别与场景级指标，判断收益是否被全局均值掩盖；抽查新增标签是否引入重复框或错误框；最后才考虑训练超参。继续盲目加 epoch 无法修复错误监督。
常见原因是逐帧串行处理、无界队列积压、每路重复加载模型，或把旧坐标画到新帧。正确架构是每路独立拉流、只保留最新帧、共享 GPU 动态 batch、结果按 frame_id 对齐，事件层再做时间窗口。单帧模型延迟低不代表 20 路端到端延迟低。
RAG 保留规程版本、条款和页码，使用混合检索与重排序，高风险问题证据不足时拒答。Agent 只能调用固定工具，服务端负责权限、参数、状态机、事务和审计；有副作用调用使用幂等键，高风险动作要求人工审批。Prompt 不是安全边界。
不是“训练了六个模型”，而是把不确定的模型预测转化为可审计证据，再用数据治理、人工授权、数据库一致性和固定评测闭环控制风险。它展示了模型工程、后端并发、前端生产力和交付复现如何围绕同一业务问题协作。
当前仓库已经充分实现和验证数据治理、候选审核与多人协作；20 路 RTSP、RAG、Agent 和边缘部署是完整系统的演进方向，需要继续用真实代码、负载测试和专项指标补齐。明确边界不是减分，而是证明你能区分原型、验证和生产。