# 发展路线图 均衡推进:模型能力与平台能力并进,按依赖关系分三阶段。每阶段结束都有可独立验证的增量。 ## Phase 1:数据与模型闭环 + 实时化 1. **难负样本微调落地** - 为 `data/fire-dataset`(train 395 / val 87,Pascal VOC XML + YOLO 标签)编写数据集配置 `configs/datasets/smoke_fire_hard_negative.yaml`,VOC XML→YOLO 转换脚本纳入 `src/yolo/data/` - 执行 `TrainConfig` 已预设的运行名 `smoke_fire_yolo11s_hard_negative_ft_v1`,与 v1-4 对比验证误报下降 2. **YOLO26n 评估补齐** - 对 `runs/detect/smoke_fire_yolo26n_v2-3/weights/best.pt` 跑一次 `fire-yolo val`,补齐 `args.yaml`、`results.csv` 与曲线图 - 更新 `docs/model_comparison.md`,完成部署选型对比(nano 对 CPU/边缘更友好) 3. **SSE 实时推送** - 后端新增 `GET /api/stream`(SSE,事件与机器人状态变更时广播) - 前端 `EventSource` 替代总览/告警中心的轮询刷新 ## Phase 2:并发产能 + 安全加固 4. **多路视频并发巡检** - 推理锁升级为单 worker 专用执行器 + 请求队列(当前 FastAPI 线程池在锁排队时可能饿死其他端点) - 前端多路视频格布局,每个视频独立会话 5. **ONNX / TensorRT 导出与加速** - `fire-yolo export` 已具备,补充部署文档与延迟/吞吐基准对比 6. **事件截图存档** - 告警触发时截图落盘 `data/screenshots/.jpg`(数据库存路径),前端事件详情弹窗展示 7. **鉴权收紧** - 简单 Bearer token + CORS 白名单;在对外/多用户访问需求出现前完成,避免带病部署 ## Phase 3:工程化 + 数据飞轮 8. **audit 集成进 CLI** - `fire-yolo audit` 参数化现有 `runs/audit/scan_missing_labels.py` 与 `render_missing_label_candidates.py`,输出保持 CSV/JSON 格式 9. **误报数据飞轮** - 前端"误报"按钮 → 截图+检测框入库 → 定期导出为增量难负样本 → 再微调 - 依赖 6 与 8,形成"数据 → 模型 → 数据"的复利闭环 10. **Docker 化** - CUDA 基础镜像 + uv + 卷挂载 `data/`,单机部署稳定后再固化 ## 排序逻辑 先"数据/模型闭环"(依赖最少、价值最大)→ 再"实时化"(值班体验增益)→ 后"并发/加速/安全"(相互依赖且依赖前两者)→ 最后"工程化与飞轮"(依赖前面所有组件)。