离线指标过了，问题才刚开始
很多视觉项目在验收时都会盯着同一个数字：mAP。训练集切好，验证集跑完，曲线足够漂亮，模型就像已经完成了最难的部分。
但真正把模型接进产线、监控或业务系统之后，mAP 往往只是一个起点。线上图像的光照、角度、压缩、遮挡、相机抖动、设备老化，都不会按验证集的分布来排队。离线表现稳定，不代表系统上线后稳定。
我越来越觉得，视觉模型工程化最容易被低估的部分，不是训练技巧，而是 上线后的可观测性和回退设计。如果一个模型只能在 notebook 里证明自己准确，却不能在线上解释自己什么时候失效，那它还不是一个可靠系统。
mAP 回答不了所有工程问题
mAP 很重要，它能衡量模型在标注数据上的整体检测质量。但它天然是一个离线、平均化、数据集内的指标。工程现场关心的却常常是另一组问题：哪一类误报最贵？漏检发生在哪些班次？某台摄像头的误差是不是突然变多？阈值调高之后，会不会把人工复核队列压垮？
这些问题不是 mAP 的错，而是它本来就不负责回答。把 mAP 当作唯一答案，就像只看 CPU 平均使用率来判断一个后端服务是否健康。平均值可能很好看，但尾部延迟、错误率和依赖抖动已经在报警。
- 平均指标会掩盖局部风险 —— 某个小类别、某条产线或某种光照条件可能已经明显退化
- 离线集无法覆盖线上变化 —— 设备、环境和操作流程都会缓慢改变输入分布
- 业务成本不等于检测分数 —— 同样一次误检，在告警系统、质检系统和自动分拣系统里的代价完全不同
上线后应该看哪些信号
我更倾向于把视觉模型当成一个线上服务来监控，而不是一个静态文件。除了传统服务指标，还要补上和图像、检测框、置信度分布相关的信号。
- 输入分布 —— 亮度、模糊度、分辨率、压缩质量、摄像头来源和采集时间是否偏离训练期
- 输出分布 —— 每类目标数量、框大小、置信度直方图、空结果比例是否突然变化
- 人工复核反馈 —— 哪些误报被频繁驳回，哪些漏检来自相同设备或相同场景
- 系统级后果 —— 告警量、复核队列长度、处理延迟和下游动作失败率是否被模型输出放大
这些信号不一定都要做成复杂平台。哪怕先把关键统计按天落表、按摄像头分组、按类别画趋势，也比只保存一个模型权重文件要可靠得多。
灰度上线比一次性替换更重要
视觉模型的升级不应该像替换一张静态图片。新模型离线分数更高，也可能在线上制造新的误报模式。尤其是工业质检、安防告警、医疗辅助这类场景，模型行为的变化本身就是风险。
更稳妥的方式是把模型上线做成 灰度实验：同一批输入同时跑旧模型和新模型，先比较输出差异，再逐步放量。不要只问“新模型准不准”，还要问“它和旧模型在哪些场景下判断不一致”。
- 影子模式 —— 新模型先不影响业务，只记录预测和旧模型差异
- 分场景放量 —— 先从低风险摄像头、低价值告警或可人工兜底的流程开始
- 明确回退阈值 —— 误报、漏检、延迟或人工复核压力超过阈值时，自动切回旧版本
数据闭环才是长期护城河
一个视觉系统能不能长期变好，最终取决于它能不能把线上问题带回训练流程。没有闭环，模型每次迭代都像重新抽奖；有闭环，错误样本会变成下一轮提升的燃料。
这里的闭环不是简单地“把线上图片全扔回训练集”。更关键的是给样本打上足够有用的上下文：来源设备、时间、环境、模型版本、阈值、人工裁决、下游影响。这样下一次复盘时，团队才能知道问题是数据漂移、标注口径、模型结构，还是业务阈值设置错了。
模型上线不是研发终点，而是数据系统开始呼吸的地方。谁能更快发现失效、更准定位原因、更稳定地把错误样本变成训练资产，谁就更接近真正可持续的 AI 视觉工程。
写在最后
如果只用 mAP 来判断视觉模型是否成功，我们很容易把问题简化成“训练得够不够好”。但工程现场真正难的，是模型在不断变化的世界里还能不能被观察、被解释、被控制。
一个成熟的视觉模型上线方案，至少应该同时回答三个问题：它现在是否还在面对熟悉的数据？它的错误会造成什么业务后果？一旦它开始失效，系统能不能快速发现并回退？
mAP 是一张入场券，不是终点线。上线后的监控、灰度、回退和数据闭环，才决定一个视觉模型到底是 demo，还是生产系统。