这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
算法升级之后效果变差，但没人能证明「变差了」，只能靠用户投诉
同一路视频要跑多个算法，算力不够时不知道砍哪个
不同厂商的算法封装方式各不相同，接入一个要改一次代码
算法参数被现场人员随意调整，出了问题无法复现
项目背景：算法越上越多，越管越乱
视频 AI 在项目里是这么长起来的：一开始只有一路周界入侵检测，后来加了人群聚集、车辆违停、烟火识别、安全帽检测、离岗检测。每个算法来自不同厂商，每个厂商有自己的管理后台。
半年之后的典型状态是：
- 五个厂商、六个后台、七套账号密码。
- 同一个摄像头，在三个平台里配置了三遍。
- 某个算法升级了，用户反馈「最近误报变多了」，但没人知道升级前后到底差多少。
- 算力吃紧的时候，不知道该关哪个算法，最后是「谁叫得响就关别人的」。
这些问题看起来是管理问题，实际都需要平台能力来支撑。所以这个平台的定位不是「又一个配置界面」，而是**算法这个资源的账本和开关**。
第一层：算法注册，先把异构封装抹平
不同厂商的算法接入方式差别很大：有的提供 SDK，有的提供 HTTP 接口，有的只给一个 Docker 镜像加配置文件，还有的要求视频流推到它指定的地址。
如果每接一个算法就改一次平台代码，平台很快就没法维护。所以第一层要做的是**统一的算法描述模型**：
| 描述项 | 内容 | 作用 |
|---|---|---|
| 算法标识 | 唯一 ID、名称、厂商、类型 | 区分与检索 |
| 输入要求 | 视频流协议、分辨率、帧率 | 判断摄像头是否满足 |
| 输出结构 | 事件字段、置信度、图片 | 统一事件格式 |
| 资源需求 | GPU/CPU、内存、单路算力 | 算力核算依据 |
| 参数定义 | 可调参数及取值范围 | 限制现场乱调 |
| 版本信息 | 版本号、发布时间、变更说明 | 升级与回滚依据 |
这套描述模型落成一份**算法包规范**：厂商按规范提交算法包，平台按规范加载。新算法接入变成「填表 + 上传」，不再改代码。
「参数定义」这一项容易被忽略，但很重要。它规定了哪些参数允许现场调整、可调范围是多少。**没有这个约束，现场人员会把置信度阈值调到 0.1，然后抱怨误报太多。**
第二层：版本管理，升级必须可回滚
这是整个平台最核心的价值点，也是最多项目做漏的一环。
算法升级的现实是：**厂商说「新版本准确率提升了」，但你的场景里可能变差了。** 因为算法训练用的数据集跟你的现场环境不一样——光照、角度、遮挡、季节，全都不一样。
所以升级不能是「覆盖式」的，必须是**并存 + 可切换**：
- 1新版本上传后不自动生效，先进入「待评估」状态。
- 2选择若干路摄像头做小范围灰度，新旧版本并行跑一段时间。
- 3对比两版在同一批视频上的检出量、误报量、响应时延。
- 4数据支持升级，则逐步扩大范围；不支持，直接下线新版本。
「并行跑」这一步在技术上要求同一路视频能被两个算法实例同时消费。如果视频流是单播推送的，就要平台做一次分发。这是平台架构上必须提前考虑的点。
回滚要细到单个任务
回滚粒度是个设计选择。粗粒度是「整个算法回滚到旧版本」，细粒度是「某个摄像头上的任务回滚」。
项目选了细粒度。原因是实际场景里经常出现「新版本在 A 类场景更好、在 B 类场景更差」的情况。整体回滚会丢掉改进，细粒度回滚能保住好的部分。
代价是版本组合变多，管理复杂度上升。所以配套要有**任务-版本关系视图**：一眼能看出当前哪些任务跑的是哪个版本。
每次升级都要记录「改了什么」，不能只写「优化性能」。实际排查时，需要知道「这次改动是否涉及夜间场景」，因为现场问题恰好发生在夜间。没有变更说明，版本号只是一串数字。
第三层：效果评估，误报率比准确率高
算法评估最常见的错误是用「准确率」做指标。在视频 AI 场景里，准确率是个很容易被做高的数字，因为**负样本（没事件的画面）太多了**。一个永远输出「无事件」的算法，准确率能到 99%。
真正决定这个算法能不能用的，是三个指标：
| 指标 | 含义 | 为什么重要 |
|---|---|---|
| 误报率 | 报出来的事件里，有多少是假的 | 直接决定值班人员的工作量 |
| 漏报率 | 真实事件里，有多少没报出来 | 决定这个系统能不能被信任 |
| 日均报警量 | 每天产生多少条告警 | 决定能不能处理得过来 |
第三个指标最实在。**一个误报率 5% 但日均报警 500 条的算法，比误报率 15% 但日均报警 20 条的算法更不可用。** 因为人处理不过来，最后全部忽略。
误报怎么统计
误报率不能靠算法厂商自己报，要靠**人工标注反馈**：值班人员处理告警时，点一下「真实」或「误报」，这个动作就是标注。
设计上做了两件事降低标注负担：
- **只对已处理的告警要求标注**，未处理的不管。
- **默认值不给「真实」**，必须主动选择，避免手滑全点真实。
积累一段时间后，系统能算出每个算法在每个场景下的误报率，形成一张**场景-算法效果矩阵**。这张表是后续选型和新项目报价的依据，比任何宣传材料都可靠。
第四层：算力调度，不够时砍谁
算力永远不够。一个中等项目几十路视频，跑三四个算法，GPU 很快就满了。这时候必须有明确的取舍规则。
平台的做法是给每个任务配**优先级和时段**：
| 维度 | 设置方式 | 典型应用 |
|---|---|---|
| 业务优先级 | 高/中/低 | 消防通道占用 > 周界入侵 > 离岗检测 |
| 时间策略 | 按时段启停 | 夜间开启周界，白天关闭 |
| 抽帧策略 | 降低分析帧率 | 非重点区域 1 秒 1 帧 |
| 分辨率策略 | 降低分析分辨率 | 远景摄像头降到 720p 分析 |
「时段策略」是最有效的。很多算法不需要 7×24 跑：离岗检测只在工作时段有意义，烟火检测夜间反而更重要。按时段调度，算力利用率能提高不少。
「抽帧」和「降分辨率」是最后手段，因为会直接影响检出效果。**这两项调整必须记录在案**，否则事后发现漏报，查不出是因为当时降了配。
算力不够时的调度不能是「谁先来谁占着」。平台按优先级排队，高优先级任务抢占低优先级任务的资源，被抢占的任务挂起并记录。**这个抢占动作要通知到人**，否则用户会以为算法坏了。
几条可以带走的判断
- **算法平台的核心是账本，不是配置界面。** 要能说清「现在有多少算法、多少任务、占多少算力、跑在哪些摄像头上」。
- **升级必须并存和灰度，不能覆盖。** 厂商说的准确率提升，在你的场景里可能正好相反。
- **回滚粒度要细到单任务。** 新版本常常是「某类场景更好、某类更差」，整体回滚会丢掉改进。
- **变更说明比版本号重要。** 「优化性能」这种说明等于没写，要写清改了哪个场景。
- **评估看误报率和日均报警量，不看准确率。** 负样本太多的场景，准确率是个骗人的指标。
- **误报要靠人工标注反馈统计，不能听厂商的。** 只对已处理告警要求标注，默认值不给「真实」。
- **算力调度优先用时段策略，最后才降帧降分辨率。** 后者影响检出效果，且必须留记录。
- **参数可调范围要在算法包里定义死。** 否则现场会把阈值调到 0.1 然后抱怨误报。
用到的技术
这些技术在其他项目里也用过，完整的协议支持清单和已实测规模见技术能力
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。