计算机视觉与生成式AI赋能的工作场所安全自动化监控

概述

工作场所安全监控正从依赖人工抽查向持续、自动化的实时监控演进。本文描述的系统利用计算机视觉（CV）和生成式AI，通过部署在AWS上的无服务器、事件驱动架构，对分布式摄像头网络拍摄的图像进行近实时分析，检测个人防护装备（PPE）违规和区域安全风险（如物品摆放不当）。对于SRE团队而言，这个系统本身就是一个需要高可用、可扩展且可观测的关键安全基础设施。理解其架构、扩展模式与可靠性设计，对于运维和支持此类基于AI的监控系统至关重要。

核心概念

系统架构概览

该解决方案采用分层的、事件驱动的无服务器架构，核心组件包括：

图像收集与匿名化：从授权摄像头周期性采集图像，使用Amazon Rekognition检测人脸并进行模糊化处理以保护隐私，原始图像在保留数天后依策略清除。
训练管道：利用Amazon SageMaker Ground Truth进行数据标注，并通过Amazon SageMaker AI Pipelines构建自动化模型训练、评估和注册流程。模型的更新通过CI/CD管道与应用基础设施代码解耦。
推理管道：每个用例（如PPE检测、5S现场管理）拥有独立的推理流。图像触发后，经由SQS队列路由至专门的SageMaker推理端点，进行风险检测。
风险管理与告警：通过Lambda函数聚合风险，避免告警疲劳。系统按需检查风险是否持续，并跟踪解决SLA，通过多渠道（Slack、邮件等）进行分级通知。
Web应用与数据分析：基于React的前端应用供安全经理查看和响应风险。风险数据定期导出至Amazon Redshift，供BI团队通过Amazon QuickSight进行趋势分析。

系统通过在多个AWS账户中部署不同组件（训练、推理、应用、分析）来实现安全隔离和职责分离，这是云原生安全架构的重要实践。

智能告警检测：四阶段流程

为确保告警的准确性并减少误报，系统对每张图像执行四阶段验证：

目标检测：模型识别图像中的设备、材料及工人安全装备，并区分物体的视觉轮廓与其实际地面投影。
基于区域的“数字胶带”分析：计算检测到的物体地面投影与预设安全区域（“胶带”定义）的重叠百分比。超过阈值（如50%）即判定为违规。对于PPE检测，系统具备上下文感知能力，能根据不同区域确定所需的PPE类型。
“逗留时间”算法：通过跨时间间隔的分析和掩码相似性算法，追踪同一违规物体的持续时间，避免因短暂经过触发的误报。高风险区域设置更短的逗留时间阈值。
多层验证与告警生成：应用置信度阈值、RLE掩码一致性检查和区域上下文验证后，生成包含物体类型、位置、违规时长、置信度及可视化标注图像的结构化告警。

无服务器驱动-工作者模式（Driver-Worker Pattern）

这是应对大规模摄像头处理的核心架构模式。驱动器负责任务编排，工作者并发处理图像。该模式实现了组件解耦和故障隔离，允许独立扩展，并利用ML推理层作为“智能过滤器”，仅将检测到风险的图像传递给下游处理，防止数据库（如Amazon Aurora）被海量原始图像数据淹没。

实践

从PoC到生产扩展的关键技术决策

推理基础设施升级：从SageMaker Serverless推理（内存和GPU限制）迁移至SageMaker有状态推理端点（使用ml.g6实例族），并配置自动扩展策略，以支持大规模并发处理。
Lambda与SQS的极限优化：为支持数千并发Lambda执行，需申请提高服务限制。同时优化内存分配、采用多线程处理、重构错误处理逻辑以最小化失败容器，并调整SQS批处理大小以在内存约束内最大化吞吐量。
数据驱动的地面真值管理：摒弃“每日每站点”全量标注的不可持续方式。转而使用Amazon Athena大规模分析推理结果和用户反馈数据，识别模型性能不佳的摄像机类型或部署条件，优先针对高错误率的图像源进行重标注和重训练。同时利用Amazon Bedrock上的Claude多模态LLM分析误分类样本，发现训练数据中未充分代表的类别，以指导数据收集策略。

利用生成式AI（GLIGEN）解决数据稀缺问题

对于稀有安全违规（如地板液体泼溅）或数据多样性不足（如PPE颜色单一）的场景，传统手动标注效率低下。解决方案是构建合成数据生成管道：

使用GLIGEN（一个基于扩散的生成模型）作为SageMaker批处理作业部署。
输入指定物体位置的边界框坐标，生成带有真实背景和自动嵌入真实标注的合成图像（512×512）。
输出的原始图像流式传输至S3，解码并转换为YOLO标注格式，形成训练就绪的数据集。
此方法成功生成了包含75,000张图像的PPE数据集（3类）和房屋管理数据集（7类），并在不使用任何手动标注真实图像的情况下训练出高精度模型。

SRE要点

与可靠性、可观测性、事件响应的关联

可靠性：系统的架构设计充分考虑了可靠性。多账户隔离保障了环境独立性；驱动-工作者模式和SQS队列提供了故障隔离和缓冲能力；智能过滤减轻了下游数据库压力；DLQ（死信队列） 用于捕获和处理处理失败的消息。SLO（如从图像捕获到告警送达的时间）需要被明确定义和监控。
可观测性：系统内置了多层次的可观测性。业务层面，风险记录存储在DynamoDB中，支持快速查询；BI层通过Redshift和QuickSight提供趋势分析仪表板。技术层面，需要对ML推理端点的延迟、错误率、SQS队列积压、Lambda执行失败率等核心指标进行监控，这些是典型的slo-sli-error-budgets应用场景。
事件响应：系统本身就是一个自动化事件响应系统，能够检测风险、聚合告警、跟踪解决状态并升级通知。对于SRE团队，需要建立针对该监控系统本身的事件响应计划，例如：当推理管道延迟激增、模型准确率下降或大规模摄像头数据流中断时的应对流程。

最佳实践与常见反模式

最佳实践：

关注数据质量而非仅模型：投资于高质量、准确标注的地面真值数据（并辅以合成数据）是模型成功的根本。
解耦科学与工程：通过事件驱动的管道将模型训练/批准与端点更新部署解耦，允许数据科学家和软件工程师协同工作。
实施分层角色访问控制：定义清晰的用户角色（超级用户、站点管理员、区域所有者等）和权限，确保操作安全。
为规模而设计：从一开始就采用无服务器和事件驱动模式，并为处理大规模并发（Lambda限制、SQS批处理优化）做专门设计。

常见反模式：

忽视隐私保护：未对图像中的个人身份信息（PII）进行有效匿名化处理。
过度依赖人工标注：在数据规模扩大后仍采用不可持续的标注策略，未利用数据驱动或合成数据方法进行优化。
低估运维复杂性：将ML系统视为“黑盒”，未为其建立完善的可观测性、告警和事件响应流程。
单体架构：将所有用例的推理和数据处理耦合在一起，导致扩展困难和故障影响面大。