从视频到根因：基于证据的检测如何阻止缺陷重复发生
发现缺陷很有价值，阻止缺陷重复发生则会带来质变。
区别就在于证据。
大多数工厂都有视频，很多也设有检验工序。但当缺陷率飙升时，团队依然会陷入同样的局面：争论到底发生了什么、四处寻找缺失的上下文，并在班次结束后才去猜测原因。
基于证据的检测带来不同的结果：每一件产品都会产生结构化的事实记录。再结合闭环根因分析，你就不只是发现缺陷——而是消除导致缺陷的条件。
四层本地根因分析架构
我们构建了一套完全运行在边缘算力上的四层根因分析引擎。不依赖云端，无需等待 API 响应，在工厂车间即可获得实时洞察。
第 1 层：缺陷模式累加器
每一次检验事件都会输入到运行在 Jetson 边缘节点上的本地模式检测器：
- 存储：以 SQLite WAL 模式保存最近 30 天的滚动窗口
- 数据结构：timestamp、defect_type、severity、station_id、shift、confidence、SOP 判定标准、unit_id
- 分析：按工位、按缺陷类型，在 4 小时滚动窗口上做 Z 分数异常检测
- 识别：频率变化、聚集现象、时间相关性
当 3 号工位的划痕缺陷在过去 4 小时内增加 3 倍时，系统会先于班组长察觉。
第 2 层：工艺参数关联器
仅凭缺陷激增无法说明原因。第 2 层将缺陷与工艺参数关联起来：
- 输入：第 1 层的缺陷异常 + 工艺参数（温度、转速、时序）
- 传感器集成：通过 MQTT 或 OPC UA 自动采集；未装传感器的工位由操作员手动录入
- 关联方法：在时间对齐的 30 分钟窗口上计算皮尔逊相关系数（统计方法而非机器学习——可解释、可审计）
- 输出：包含缺陷模式、相关参数、漂移幅度、置信度与时间窗口的 JSON
当关联器识别出砂轮转速在划痕激增的同一时段比目标值低了 5%，你就得到了一个值得调查的假设。
第 3 层：用于解释的小语言模型
统计相关性需要上下文才能转化为行动。第 3 层使用本地小语言模型（Qwen-2.5 3B INT4）生成自然语言解释：
- 输入：缺陷模式 + 工艺关联 + SOP 参考 + 缺陷分类体系
- 输出：中英双语的根因假设，附带置信度与建议的纠正措施
- 推理预算：每次生成根因分析 2–4 秒（仅在异常时触发，而非逐帧运行）
第 4 层：闭环措施推荐器
最后一层将分析转化为行动：
- 输出形式：与 SOP 关联的纠正措施——不是"检查砂轮"，而是"3 号工位转速 2,847（目标 3,000 ±50），请按 SOP 4.2.3 重新校准。"
- 操作员界面：本地 React 看板，展示建议 + 证据链接 + 接受/驳回/修改按钮
- 反馈闭环：操作员的动作以因果三元组形式记录：{defect, cause, outcome, operator_id, disposition, timestamp}
- 安全护栏：仅通知。智能体只提建议，绝不执行。不自动修改参数，不自动停线。
第 1 步：把视频变成决策
加入实时 AI 缺陷检测后，摄像头画面就不只是"远程可视"：
- 识别缺陷类别（划痕、崩缺、错位、缺件、变色）
- 通过 DefectIQ 规则引擎应用 SOP 阈值
- 给出合格/不合格/复核的判定
当检测运行在经 TensorRT 优化的 NVIDIA Jetson 边缘算力上时，它能以产线节拍完成——延迟低于 25ms——且不依赖网络。
第 2 步：把决策变成持久记录
仅有决策还不够。系统必须为每一次检验事件保存持久记录：
| 证据层级 | 存储内容 | 保存期限 | 存储位置 |
|---|---|---|---|
| 所有事件 | 元数据 JSON：event_id、timestamp、工位、SKU、判定、置信度、模型版本 | 永久 | 边缘 SQLite |
| 不合格 + 复核 | 缺陷帧、边界框、检测 JSON、rule_result.json、audit.json | 本地 90 天，之后归档 | 边缘 NVMe → MinIO |
| 根因分析事件 | 完整因果三元组：缺陷 + 原因 + 结果 + 操作员处置 | 永久 | 边缘 SQLite → 厂区 PostgreSQL |
| 可选 | 每个工位最近 7 天的生产视频环形缓存 | 7 天（循环覆盖） | 边缘 NVMe |
这让质量从口头讨论变成审计追踪。当客户问起某一件具体产品时，你有证据可查。
第 3 步：尽早发现模式
事件一旦结构化，就能在问题演变成批量问题之前发现它：
- 换刀之后某个工位出现缺陷激增
- 置信度漂移，预示照明老化或模型过时
- 复核比例上升，提示工艺不稳定
- 与某个班次、供应商批次或设备设定时段相关的良率下降
缺陷模式累加器持续运行，在 4 小时滚动窗口上进行 Z 分数异常检测。一旦有变化，几分钟内就能知道——而不是几天后。
第 4 步：用可引用的证据解释根因
"根因"是大多数软件开始"编故事"的地方。"检查设备"或"复查流程"之类的模糊建议，在车间里毫无用处。
唯一可接受的根因输出，是有证据支撑的：
- 哪些产品受影响：事件 ID、时间戳、数量
- 系统看到了什么：真实的图像帧与检测产物
- 发生了什么变化：时间窗口、工位、操作员、批次、工艺参数
- 假设为何成立：统计相关性、模式匹配
- 应采取什么措施：具体的 SOP 条款与步骤
这就是质量团队从"也许"走向"立即执行"的方式。
第 5 步：用因果三元组闭合循环
当措施与结果被记录为缺陷因果三元组时，循环就闭合了：
| 字段 | 类型 | 示例 |
|---|---|---|
| defect_id | UUID | evt_20260213_143022_s3_001 |
| defect_type | 枚举 | scratch_surface |
| cause_parameter | JSON | {grinding_rpm: 2847, target: 3000, drift_pct: 5.1} |
| cause_confidence | 浮点数 | 0.87 |
| recommendation | 文本 | SOP 4.2.3：重新校准砂轮 |
| operator_action | 枚举 | accepted / rejected / modified |
| outcome_measured | JSON | {scratch_rate_after: 0.8pct, time_to_baseline: 45min} |
随着时间推移，你的工厂会建立起内部的质量知识库：不仅是缺陷计数，还有与真实事件、真实原因和已验证结果相关联的缺陷解释。
为什么边缘优先对根因分析至关重要
如果系统依赖云端连接，证据链恰恰会在工厂承压时断裂。质量危机中网络中断了？那正是最需要根因分析的时候——也正是依赖云端的系统失灵的时候。
边缘优先架构让检测与证据采集持续不断：
- 互联网中断 → 本地全功能照常运行。SQLite 缓存事件，根因分析使用本地小语言模型，看板由本地提供。
- 厂区服务器宕机 → 边缘节点独立运行，本地证据存储持续进行。
- 相机断开 → 该工位暂停检测，相邻工位不受影响，看门狗程序尝试重连。
工厂绝不会因为断网而停止检测。
预约演示，亲眼看看四层根因分析架构如何运作。