高精度AI火灾烟雾检测算法：楼宇消防视觉预警与误报抑制实战

楼宇消防这块，视觉烟雾检测这两年确实热起来了。我前后参与过几个园区和办公楼的算法落地项目，从最早拿开源模型直接跑通、误报多到运维想拔电，到后来把每路每天误报压到个位数、真正接入消防值班室，中间踩的坑比想象中多得多。这个标题讲的“高精度AI火灾烟雾检测算法”，核心并不在于模型本身有多花哨，而在于能不能在真实的楼宇环境里把“早期、少量、远景、遮挡、逆光”的烟雾稳稳认出来，同时把水蒸气、油烟、扬尘、逆光这些天天出现的东西摁住不动。它解决的是一件事：让摄像头从“事后取证”变成“事前预警”。适合谁参考？做智慧楼宇、园区安防、消防物联网的算法和工程同学，以及想给现有视频系统加一层“烟雾哨兵”的集成方。下面我按实际做项目的顺序，从问题定义、算法设计、数据、训练、部署、现场联调一路讲下来，能抄的部分直接抄。

1. 楼宇消防场景下，视觉烟雾检测到底解决什么问题

1.1 传统点式感烟探测器的物理局限

先说清楚为什么要多此一举。点式感烟探测器靠的是烟雾颗粒进入迷宫式腔体、散射红外光来触发，它对“烟到了探测器头顶”这件事很敏感，但对“烟还在三十米外的大厅里飘”毫无感知。楼宇里几个典型失效场景我列一下：一是大空间中庭、挑高展厅、地下车库，层高超过 8 米，烟羽上升过程中被空调气流横向带走，等浓度到顶时火已经烧起来了；二是吊顶被造型包住、探测器装在回风口附近，气流把烟直接抽走；三是机房、档案室这类有洁净要求的地方，探测器被人为屏蔽或维护不到位；四是长走廊和连廊，线性空间里烟雾扩散路径长，点位密度不够就有盲区。这些不是设备质量问题，是物理原理决定的覆盖边界。

我在一个挑高十几米的项目里做过实测：用发烟装置在中庭地面附近放烟，顶部的点式探测器从起烟到报警用了将近三分钟，而同一位置的摄像机在第 8 秒就看到了明显的烟雾团块在扩散。这三分钟在消防里是很要命的差距。所以视觉方案的价值定位从来不是替代点式探测器——那是合规底线，不能动——而是做一层“更早、更远、更直观”的补充预警，把确认时间往前压。

1.2 视觉方案补位的能力边界

摄像机能做的是“看见”，看见之后还得能判断。这里面有几层能力：一是远距离发现，在烟雾还没扩散到探测器之前就从画面里识别出异常团块；二是空间定位，直接告诉值班人员“三楼东侧连廊靠近电梯厅”，而不是只报一个回路号；三是可视化确认，报警同时弹出画面，值班员两秒内就能判断是真烟还是误报，这在半夜人手少的时候特别关键；四是覆盖已有设备，直接复用现有的监控摄像头，不用重新布线打孔，改造成本压得很低。

但边界也得说清楚。视觉看不到被墙体挡住的区域，所以点位规划本质上是一次“视线覆盖设计”，跟消防点位设计不是一回事；烟雾在纯黑环境、浓雾环境、镜头被遮挡时基本失效；对已经进入猛烈燃烧阶段、产生大量黑色浓烟充满画面的场景，检测框会变得非常大、边界模糊，这时候反而不如感温感烟可靠。我一般会跟甲方讲：这套东西是“把预警时间往前挪”，不是“把消防系统换掉”。

1.3 这套东西适合谁上、不适合谁上

适合上的场景我总结成几类：大空间（中庭、展厅、礼堂、地下车库）、长线性空间（连廊、管廊、隧道式通道）、有贵重设备或重要资料的房间（机房、档案库、配电间）、以及户外与半户外区域（垃圾堆放点、充电棚、屋顶设备区、施工围挡内）。这些地方的共同点是：点式探测器覆盖成本高或者效果打折扣，而摄像头本来就有。

不太建议硬上的场景：一是摄像头点位本身就稀疏且无法加装的存量楼宇，几个球机转来转去覆盖不了多少面积；二是粉尘浓度常年很高的车间，扬尘和烟在视觉上高度相似，误报很难压；三是镜头前常年有水汽、油污的厨房排烟区域，画质劣化太快；四是预算极低、只想买个盒子上墙就完事的项目，这类项目最后往往因为没人调、没人维护而烂尾。我在一个预算紧张的老旧改造项目上就吃过这个亏，算法本身没问题，但现场没有一台像样的边缘设备、点位也没法调整，最后效果口碑很差。

2. 算法整体架构与选型思路拆解

2.1 把“报警”拆成检测加确认两级

很多人一上来就想训一个端到端的“报警/不报警”二分类网络，我不建议。原因很实际：分类网络给不出位置，值班员看到报警却不知道看哪；而且分类网络对“画面里同时有烟和蒸汽”这种混合场景很难解释。我的做法是把整条链路拆成两级。

第一级是单帧目标检测，输出烟雾和明火的候选框与置信度，这一级追求的是高召回，阈值放得比较松，宁可多报一些。第二级是时序确认，对同一路视频的一个滑动窗口做统计判决：比如 25fps 下取最近 15 帧（约 0.6 秒），要求命中帧数不少于 8 帧、且框的空间位置有重叠，才升级为一次报警。这一层能把大量单帧偶发的误检（比如一瞬间的反光、飘过的塑料袋）直接过滤掉。实测下来，单帧召回 92% 左右的模型，加上时序确认后整链路召回还能保持在 88% 以上，但每路每天的误报从几十次降到个位数。这个投入产出比非常划算，而且第二级几乎不占算力，纯逻辑判断。

2.2 骨干网络的轻量化取舍

楼宇场景的现实约束是：一台边缘盒子要跑 4 到 16 路视频，成本还得压。所以骨干网络不能上重型。我试过的路线有三条：一是直接用量化后的轻量检测器（宽度和深度都缩过的版本），参数少、推理快，边缘设备上单路 640 输入能跑到 30fps 以上；二是中等规模骨干配轻量检测头，精度高一档，但算力需求翻倍；三是大模型只在服务端跑，边缘只做抽帧上传，这个方案对网络依赖太强，断网就瞎了，我一般不推荐给消防场景。

最终我在多数项目里选的是第一条路线再加两处改造：一是把骨干末端的下采样节奏放缓，保留一个 stride 8 的高分辨率特征层，因为早期烟雾在画面里就是一小块，下采样太狠就没了；二是在特征融合部分加一个轻量的通道注意力模块，让网络更关注低饱和度的灰白区域——烟雾在色彩上和墙面、天空、地面非常接近，靠颜色几乎分不开，靠的是纹理的“絮状、翻涌、边界逐渐虚化”这些特征。这个改动带来的参数量增加不到 5%，但小目标召回提升明显。

2.3 烟雾形态建模的三个关键点

烟雾这个目标跟行人车辆完全不是一类东西，有三个特性必须在建模时考虑。第一是无固定形状，同一场火从起火到猛烈燃烧，烟雾的面积可能从几十像素涨到占满整个画面，长宽比、轮廓、内部纹理全在变。所以锚框（anchor）的尺寸分布必须拉得很开，我在聚类锚框时会特意加入大量小面积样本，否则早期烟雾根本匹配不上。第二是边界模糊，标注的时候人和人之间的框差异很大，模型学到的回归目标本身就是有噪声的，所以回归损失不能设得太激进，我通常会把框回归的权重调低一点，让分类分支占主导。第三是半透明，烟雾后面的背景是透出来的，同一团烟在不同背景下外观差异极大，这决定了数据增强里背景替换比单纯的颜色抖动更有价值。

还有一个容易忽略的点：烟雾和火焰经常同时出现，但两者的检测难度完全不同。火焰色彩饱和、边界清晰，模型很容易学；烟雾灰白、半透明，难得多。如果两类混在一起训，损失会被火焰样本主导。我的做法是分支处理，火焰单独用一个更小的子头，避免它抢走烟雾的学习信号。

2.4 单帧与多帧：什么时候该引入时序

时序信息用不用，取决于你要抓的是“瞬时”还是“过程”。烟雾的本质特征之一就是运动——它是往上飘、往外扩、边界缓慢翻涌的。单帧模型看到的是一团灰白色的静态区域，天然容易和水汽、白墙、雾霾混淆；一旦引入时序，很多误报会自动消失：水蒸气是持续喷射、位置固定、形态高频抖动；烟雾是整体缓慢膨胀、边缘向外推进。这两种运动模式差异非常大。

我试过三种时序方案：一是最简单的帧差或背景建模做前置过滤，只把有运动的区域送进检测器，速度快但容易漏掉缓慢渗出的烟；二是双流结构，一路 RGB 一路光流，精度最好但算力翻倍，边缘跑不动；三是折中的做法，单帧检测加跨帧的框关联统计，把连续多帧的框位置和面积做趋势分析，面积单调增长且中心缓慢上移的，置信度加权。第三条路在很多项目里是性价比最高的，实现也简单，本质上是把时序判断从网络里挪到了后处理里。

3. 数据集构建：决定精度上限的隐形工程

3.1 采集规范与场景覆盖矩阵

模型上限基本由数据决定，这句话在烟雾检测里体现得淋漓尽致。我见过太多团队拿网上找的几百张火灾图训一版，demo 视频里效果惊艳，一上现场就崩。原因很简单：网图多是猛烈燃烧阶段的大面积浓烟，而现场需要的是早期的小面积淡烟，两者的数据分布差了一个数量级。

我的采集规范是这样的：按场景类型建覆盖矩阵，行是场景（地下车库、中庭、走廊、机房、楼梯间、屋顶、垃圾堆放点、充电区），列是条件（白天正常光、夜间灯光、逆光、雨雾天、镜头有污渍、有人走动遮挡）。每个交叉格至少要有一定量的正样本和负样本，宁可不均衡，也不能缺格。正样本里早期淡烟（占画面面积 1% 以下）的比例我要求不低于三成，这是最难的也是最值钱的部分。采集手段上，正规做法是用发烟装置在受控场地实拍，配合已归档的历史火情录像；另外可以收集真实的烟雾视频做切片，但要注意不同分辨率、不同编码质量的分布差异，别让模型只适应高码率画面。

3.2 烟雾标注的特殊处理

标注是这件事里最耗人力也最容易出问题的环节。烟雾边界虚，我定的规则是：标“可见烟雾主体”，也就是人眼能明确判断为烟雾的那部分，边缘的半透明扩散区不强求画满；框统一用最小外接矩形，允许略微外扩一点，避免模型学到过紧的边界。同时要求标注员对同一团烟的多帧画面保持一致，不能这帧画大那帧画小。

为了验证一致性，我会抽 10% 的样本做双人重复标注，算一下框的 IoU 一致性，低于 0.6 的样本要重新讨论规则。这件事听起来繁琐，但效果立竿见影——我做过对比，规范标注规则并做一致性校验之后，同一个模型架构的验证集表现提升了接近 4 个点，纯粹是因为标签噪声少了。另外强烈建议加一个“不确定”类别，让标注员遇到实在判断不了的（比如远处一小团模糊白影）直接标为忽略，不要硬猜，硬猜出来的标签比没有还糟。

3.3 困难负样本的挖掘逻辑

说实话，烟雾检测项目里七成的工作量花在负样本上。误报压不下去，精度再高也没人用。我整理的常见困难负样本清单：蒸汽管道和暖气片泄漏的白汽、食堂和餐饮排烟口的油烟、施工扬尘和道路扬尘、晨雾和霾、逆光下的空气悬浮物、白色墙面和天花板的局部反光、飘动的白色塑料袋和窗帘、雨水打在镜头上的水痕、摄像头自动增益变化引起的画面整体泛白、以及视频压缩块效应在平坦区域产生的伪纹理。

挖掘方法上，我不用随机采样，而是用上线后的误报回流：把现场每一次被值班员判定为误报的片段截取下来，人工确认为负样本后加入训练集，这个过程我们叫 badcase 回流。一个项目运行三个月，回流几百到上千条真实负样本是很正常的，它们带来的收益远超同数量的随机负样本。这里有个细节要注意：回流样本的分布会越来越偏向那些“容易误报”的场景，长期只加这类样本会让模型在其他场景上退化，所以每次增量训练都要保留一定比例的历史数据做混合，比例大概 1:3 到 1:4。

3.4 合成烟雾与数据增强配方

真实早期烟雾样本永远不够，合成是必要的补充手段。我的做法是用噪声场生成半透明的絮状团块，通过透明度混合贴到真实背景上，同时给团块加缓慢的形变和位移做成序列。这样能批量造出“小面积、淡、位置随机”的样本，正好补上最缺的那部分。合成样本的缺陷是纹理偏假，模型可能学到合成痕迹，所以合成样本在训练集里的占比我控制在两到三成，且必须和真实样本混在同一批次里，不能单独成组。

常规增强方面，我的配方是按重要性排序的：随机缩放和裁剪（最重要，直接扩充尺度分布）、HSV 色调饱和度和亮度扰动（模拟昼夜和灯光色温）、运动模糊和高斯模糊（模拟抖动和对焦不准）、随机擦除（模拟遮挡）、以及一定概率的灰度化（强迫模型不依赖颜色，这对烟雾特别有用，因为烟雾和背景在色彩上区分度太低）。Mosaic 类的小图拼接增强对烟雾我持谨慎态度，它会把多张图的小烟拼成大烟，误导尺度学习，所以我把它关掉或者降低概率。

4. 训练调参与精度打磨实操

4.1 输入分辨率的账怎么算

输入分辨率是最影响效果也最影响成本的一个参数，值得算清楚。假设现场是 1920×1080 的枪机，覆盖一条 30 米长的走廊。按透视关系，走廊尽头一个 0.5 米见方的烟雾团，在画面里大概只有 40×40 像素。如果模型输入是 640×640 且保持长宽比做 letterbox，横向缩放系数是 640/1920≈0.333，那么这个烟团缩到画面里只有约 13×13 像素。在 stride 8 的特征图上只有不到两个格子，几乎不可检测；即使 stride 4 也只有 3 个格子。这就是为什么很多人模型在验证集上 mAP 挺好看，一到现场远景烟雾全漏。

解法有两条。第一条是把输入分辨率提上去，比如 960×960 或 1280×1280，代价是算力按面积平方增长——640 到 960 是 2.25 倍，到 1280 是 4 倍。第二条是切片推理，把 1080p 画面切成 2×2 有重叠的子图，每张缩放到 640 分别推理再合并结果，等效分辨率提升明显，代价是单帧变成四次推理。我在实际项目里通常采用混合策略：主路用 960 输入跑常规检测，同时对重点区域（走廊尽头、楼梯口）额外做一次局部裁切推理，只在这些区域报警时提升置信度。这样平均算力增加不到 50%，但远景小烟的召回提升非常可观。

4.2 损失函数与正负样本失衡

正负样本失衡在烟雾检测里比常规检测更严重，因为一帧画面里绝大多数格子都是背景。分类损失我用的是带焦点加权的形式，把大量易分背景的损失压下去，让模型聚焦在难样本上。回归损失用带距离惩罚的形式，比传统形式收敛更快，框的位置更准。这里有个经验：烟雾框的回归不用追求特别精确，因为标签本身就模糊，把回归损失的权重设得比分类低一些（我一般用 0.5 左右的比例），让模型把精力放在“是不是烟”这个判断上，实测比两边权重相等的配置效果好。

另外要处理烟雾和火焰的类别竞争。如果画面里既有火又有烟，两者的框经常重叠，模型容易把烟框判成火框。我的处理是在训练时对重叠严重的情况做样本重采样，保证烟雾类的梯度不被火焰样本稀释，同时在推理后处理阶段允许烟和火共存，不做类间抑制。

4.3 针对早期小烟的优化手段

针对小目标这几招我基本都会上。一是提高高分辨率特征层的权重，在特征金字塔的融合里给 stride 8 那层加权，不要让深层语义完全盖住浅层细节。二是训练时用尺寸敏感的采样策略，把小面积正样本的采样概率提高，因为它们在数据里天然稀少。三是测试时增强，对同一帧做原图和轻微放大两路推理再融合，代价是算力翻倍，通常只在夜间低码流或者重点点位开启。四是降低置信度阈值并配合时序确认，单帧阈值放到 0.2 到 0.25 之间，靠后面的多帧确认把误报挡住，这个组合比单帧阈值设 0.5 的效果好得多。

有一个坑要提醒：不要盲目追 mAP。烟雾检测里 mAP 高但实际漏报多的模型太常见了，因为这个指标被大面积的猛烈燃烧样本拉高了。评估时我要求单独看“小面积烟雾子集”的召回，这个数字才是真正决定现场能不能用的指标。

4.4 一轮完整的训练记录与调参顺序

调参顺序我固定成一套流程，避免乱试。第一步是先用小分辨率（比如 512）快速跑通训练流程，确认数据管道没 bug、损失能正常下降，这一步一般几个小时。第二步用目标分辨率做正式训练，学习率从 0.01 量级开始配合预热，batch 大小按显存上限来，训到验证集指标不再提升为止。第三步针对性地做微调：如果小目标召回差，就调高小样本权重和输入分辨率；如果误报多，就补负样本做增量训练。第四步蒸馏和量化。

我在一个项目里做过完整记录：初始模型在自建的验证集上，全类别 mAP@0.5 是 0.86，但小面积烟雾子集召回只有 0.61。经过提高输入分辨率到 960、加权融合浅层特征、小样本重采样三步之后，mAP 升到 0.89，小面积子集召回升到 0.79。这 18 个点的提升几乎全部来自小目标优化，而 mAP 只涨了 3 个点——这正好说明为什么不能只看 mAP。

5. 边缘部署：把模型塞进楼宇弱电箱

5.1 算力预算与硬件选型

算力预算要按最坏情况算。假设一台盒子要接 8 路 1080p，每路抽帧 5fps 做检测，总需求就是 40 帧每秒。如果单帧模型在 640 输入下需要约 8 到 9 GFLOPs，那理论峰值算力需求约 350 GFLOPS，考虑到推理效率和余量，实际选型至少要 3 到 5 倍冗余。如果开了切片推理或者提高分辨率，需求再乘 2 到 4。所以一台 8 路设备我通常按 6 TOPS 以上的定点算力来配，并且要求设备支持硬件编解码多路视频，否则解码本身就会把 CPU 吃满。

选型时几个硬指标要卡：一是是否支持多路视频硬件解码，这是最容易踩的坑；二是内存带宽，模型不大但特征图大，带宽不够推理速度上不去；三是散热和功耗，弱电箱里常年不通风，风扇设备故障率高，我倾向于选无风扇被动散热的工控级盒子，功耗控制在 15 瓦以内；四是双网口，一路接摄像头网段一路接业务网段，物理隔离比较省心。

5.2 量化压缩的实操步骤与掉点控制

量化这一步目标很明确：把浮点模型转成定点推理，速度通常能提升两到三倍，模型体积缩小到四分之一左右。流程是：先在训练框架里导出通用交换格式，再用量化工具做定点转换，最后部署到设备上用推理引擎跑。

关键是校准集的选择，这决定了掉点多少。校准集不能随便拿几百张图凑数，必须是能代表现场分布的真实帧——不同时段、不同点位、不同天气、有烟的和没烟的都要有，我一般要求不少于 500 帧，并且正样本占比不能太低，否则量化参数会偏向背景。实测下来，校准做得好的话，定点模型的 mAP 掉点在 1 到 2 个点以内，小目标召回掉点稍大一些，通常 2 到 3 个点。如果掉点超过 5 个点，基本可以断定是校准集或者算子支持出了问题。

还有一个细节：烟雾检测里有些算子对量化不友好，比如某些归一化和注意力里的运算。我在转模型之前会做一次算子兼容性检查，把不支持的算子替换成等价实现，避免转换失败或者自动回退到浮点导致速度不升反降。

5.3 多路视频流的调度策略

多路并发时调度策略比模型本身更影响体验。我的做法是三条。第一，抽帧而不是逐帧，烟雾扩散是秒级过程，5fps 完全够用，一秒钟里没有任何一帧能提供额外信息。第二，动态分配算力，平时匀速轮询所有通道，一旦某通道的置信度超过一个较低的门限，自动把该通道临时提升到 15fps 做密集确认，确认完毕再降回来，这样总体算力不变但关键事件的分辨率提高了。第三，优先保底，确保任何一路的检测间隔不超过一秒，不能出现某路长时间排队的情况，因为漏掉的那一秒可能正好是起火初期。

另外，解码和推理要分线程流水线化，一边解码下一帧一边推理当前帧，避免串行等待。这个优化在 8 路场景下能把有效吞吐提高三成左右。

6. 现场落地：点位、联动与工程细节

6.1 摄像头点位与安装规范

点位这事，算法再好也救不了糟糕的安装。我总结的规范：俯角控制在 15 到 30 度之间，太平看不到地面火情，太陡看不到远处空间；镜头尽量避开正对窗户和大面积玻璃门，逆光会让烟雾和背景一起过曝成一片白；避开空调出风口、新风口的正对方向，气流会把烟吹散成稀薄的一片；避开蒸汽管道、厨房排烟口、加湿器这些常驻白汽源，实在避不开就在算法侧配屏蔽区；安装高度尽量高于人流视线，减少遮挡，但也不能贴顶棚太近，否则烟雾上升过程中正好从画面顶部飘出，只能在很短暂的时间里被看到。

还有一个常被忽略的问题：镜头污染。地下车库、施工区、厨房附近的镜头两三个月就糊一层油污，画质劣化后模型表现断崖式下跌。所以我在方案里一定会加镜头遮挡和画质劣化的检测逻辑，一旦画面清晰度指标下降就报“设备异常”而不是继续用它做判断，避免因为脏镜头造成大量误报或漏报。

6.2 报警分级与联动逻辑设计

报警不能一刀切，得分级。我的设计是三级：一级是“疑似”，单帧置信度超阈值但时序确认未通过，只在后台标记、不入报警队列，用于 badcase 分析；二级是“确认烟雾”，时序确认通过，推送到值班室弹窗、声光提示、并记录短视频片段；三级是“确认烟雾且扩散趋势明显”（框面积在若干秒内持续增长），这一级才会触发对外的联动动作。

联动要非常谨慎。可视化弹窗、值班室语音播报、手机端推送这些是安全的；对消防广播、电梯迫降、防火卷帘这些绝对不能由视觉算法直接触发，这是安全底线，视觉只能作为提示，最终动作必须由人工确认或由合规的消防系统执行。这一点我在每个项目里都会写进方案，也会跟甲方反复确认，因为总有人想“干脆全自动”。

6.3 误报抑制的工程手段

除了模型侧，工程侧还能做很多。一是屏蔽区配置，把画面里的常驻白汽源、反光面、屏幕区域、人员密集走动区画成多边形屏蔽，只在这些区域外做判断；二是时间段策略，比如食堂后厨在备餐时段内对油烟类报警做降级处理，只记不报；三是多摄像头交叉验证，相邻点位的画面在同一时间段都检测到烟雾才升级为确认报警，这个对单点偶发误检特别有效；四是与环境数据联动，如果接了温湿度或者空气质量传感器，可以作为加权因子。

我在一个地下车库项目里做过统计：纯模型侧优化把每路每天误报从 45 次降到 12 次，加上屏蔽区和相邻点位交叉验证之后降到 3 次以内。工程手段的收益在后期往往比继续调模型更大，而且成本低得多。

7. 常见问题排查实录

7.1 误报排查速查表

误报是最常见的问题，我整理了一张按现象定位原因的表，基本能覆盖八成情况。

排查顺序我一般是：先看画面截图确认是不是真烟，如果画面里什么都没有那就是模型问题；再看是不是特定时段或天气，这能快速定位是不是分布问题；最后看是不是某个点位独有，点位独有基本就是现场环境问题，跟模型关系不大。这个顺序能把大部分问题在十分钟内定性。

7.2 漏报排查思路

漏报比误报更危险也更难发现，因为它不会主动暴露。我的做法是建立定期回溯机制：每周抽一部分历史录像，人工快进看一遍，跟算法结果对齐，找出算法没报但人眼能看出烟雾的片段。这类片段就是最宝贵的漏报样本。

常见的漏报原因有几种：一是烟雾太小太淡，超出模型的分辨能力，解法是提高分辨率或加切片推理；二是烟雾颜色和背景几乎一致，比如白烟对着白墙，解法是加强灰度增强训练和纹理特征；三是烟雾出现在画面边缘被裁掉一半，解法是调整点位或者对边缘区域单独处理；四是烟雾上升太快从画面顶部飘出，在视野里停留时间太短，解法是调整俯角或换广角镜头；五是镜头脏污导致对比度下降，属于设备问题。

7.3 联调阶段踩过的坑

说几个我实际踩过的。第一个是时间戳对不上，算法报警时间和录像回放时间差了十几秒，原因是设备本地时钟没同步，排查了半天还以为是算法延迟，后来统一做时间同步才解决。第二个是网络抖动导致视频流断续，模型对着花屏画面疯狂报警，加了花屏和绿屏检测之后才好。第三个是设备过热降频，夏天弱电箱里温度到了五十多度，盒子自动降频，帧率掉一半，表现是“白天好好的晚上就延迟”，最后加了散热改造。第四个是配置漂移，运维为了压误报私自把阈值调到很高，结果漏报严重，这个只能靠配置变更留痕和定期巡检来管。

这些问题跟算法一点关系都没有，但在项目里花的时间比调模型多。所以我现在的习惯是：算法开发阶段就把设备状态监控、时间同步、流质量检测这些“非算法”模块一起做进去，别等到联调时才发现。

8. 效果评估、影响范围与持续迭代

8.1 该看哪些指标

指标要分两层。算法层看三个：小面积烟雾子集的召回率、整体误报率（用每路每天误报次数衡量，比 FPR 更直观）、以及检测延迟（从画面出现可辨识烟雾到报警输出的时间）。工程层看两个：设备在线率和平均无故障运行时间。我给自己的验收线大概是：小面积烟雾召回不低于 0.75，每路每天误报不超过 5 次，端到端延迟不超过 3 秒。这三个数字在不同项目里会根据点位条件浮动，但量级基本如此。

要特别强调，别用单一 mAP 做验收。我见过验收报告写着 mAP 0.9 但值班室天天被误报折磨的项目，指标和体验完全脱节。

8.2 影响范围：能覆盖哪些区域、替代不了什么

这套算法的实际影响范围，我分三层看。第一层是时间维度，把发现时间从“烟到顶棚”提前到“烟刚成型”，在一些大空间场景里能提前几分钟，这几分钟对初期处置很关键。第二层是空间维度，让原本没有探测覆盖的区域（户外堆放点、屋顶设备区、施工围挡内）有了低成本的监测手段。第三层是管理维度，报警带画面、带位置、带短视频，值班流程从“接警—派人去看”变成“接警—看画面确认—直接处置”，效率提升明显。

但它替代不了什么，这点要说透。它替代不了合规的消防探测系统，那是法定要求；它替代不了灭火设施和疏散设计；它也替代不了人的判断，尤其在复杂场景下，视觉给出的永远只是“疑似”，最终定性还是要靠人。把它定位成“值班员的一双不知疲倦的眼睛”是准确的，定位成“自动消防系统”就危险了。

8.3 灰度上线与 badcase 回流

上线绝对不能一次性全量铺开。我的做法是先选三到五路代表性点位，跑两周影子模式——只记录不报警，把算法的判断和实际发生的情况做对齐，看看误报率和漏报率在真实环境里是什么水平。这两周的数据是后续优化的金矿。

影子模式跑通之后开始灰度报警，但只推给内部值班群，不接入正式流程，再跑两周。等误报稳定在可接受范围才正式接入。接入之后建立固定的回流机制：值班员每标记一次误报，就自动截取前后各 10 秒的片段进样本库，每周做一次增量训练和评估，通过的版本才推送到现场。

增量训练有个坑要提醒：新版本必须在完整的历史测试集上回归，不能只看新样本上的提升。我吃过一次亏，模型在补了某类负样本之后那类误报确实没了，但在另一个场景下漏报率涨了不少，原因是过度拟合了新增分布。所以现在我坚持每次更新都跑全量回归，全部指标不退化才发版。

最后分享一个我在多个项目里反复验证过的小体会：这套系统能不能用好，八成取决于前期的点位勘察和数据规范，两成才是算法调优。我见过算法很一般但点位选得好、负样本收得勤的项目，跑得又快又稳；也见过用了很新的模型但点位随便装、没人维护的项目，三个月就被甲方停用。如果你正准备做类似的事情，建议把时间预算的一半留给现场和数据，别全压在模型上。