楼宇消防这块视觉烟雾检测这两年确实热起来了。我前后参与过几个园区和办公楼的算法落地项目从最早拿开源模型直接跑通、误报多到运维想拔电到后来把每路每天误报压到个位数、真正接入消防值班室中间踩的坑比想象中多得多。这个标题讲的“高精度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 大小按显存上限来训到验证集指标不再提升为止。第三步针对性地做微调如果小目标召回差就调高小样本权重和输入分辨率如果误报多就补负样本做增量训练。第四步蒸馏和量化。我在一个项目里做过完整记录初始模型在自建的验证集上全类别 mAP0.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 秒的片段进样本库每周做一次增量训练和评估通过的版本才推送到现场。增量训练有个坑要提醒新版本必须在完整的历史测试集上回归不能只看新样本上的提升。我吃过一次亏模型在补了某类负样本之后那类误报确实没了但在另一个场景下漏报率涨了不少原因是过度拟合了新增分布。所以现在我坚持每次更新都跑全量回归全部指标不退化才发版。最后分享一个我在多个项目里反复验证过的小体会这套系统能不能用好八成取决于前期的点位勘察和数据规范两成才是算法调优。我见过算法很一般但点位选得好、负样本收得勤的项目跑得又快又稳也见过用了很新的模型但点位随便装、没人维护的项目三个月就被甲方停用。如果你正准备做类似的事情建议把时间预算的一半留给现场和数据别全压在模型上。