用生成式 AI 把告警噪声降到最低的工作流

Swann 的摄像头用户平均每台每天收到约 20 条通知，而其中大部分都没价值：路过的车、摇晃的树影、宠物活动……结果很现实：用户开始“免疫”，甚至把通知直接关掉，真正的安全威胁反而更容易被错过。

这不是“智能家居才会遇到的问题”。如果你在做运营、客服、IT 运维、门店管理、物流调度，甚至只是管理一个小团队的共享邮箱，你大概率也在被同一种东西折磨：告警/通知/工单太多，信息密度太低。而当“噪声”长期占据注意力，团队就会用最原始的方式自保：忽略、延迟、关掉。

我更愿意把 Swann 这个案例看成一份可迁移的蓝图：他们用 Amazon Bedrock 把数百万 IoT 设备的告警系统做成了“会思考的过滤器”，把“看见动静就叫”升级为“理解情境才打扰”。对小企业来说，这个思路同样适用——只是你的输入不一定是视频帧，可能是电话录音、客户消息、设备状态、网络指标，或者一堆重复的审批请求。

告警疲劳的本质：不是模型不够强，是工作流太粗糙

告警疲劳（alert fatigue）从来不只是“误报多”。真正的问题是：系统把所有事件都当成同一等级的事件。

Swann 以前的检测能力只到“人/宠物”这个粒度，缺少上下文：快递员和潜在入侵者都算“人”。对用户来说，这种通知没有决策价值，只是在打断。

把它翻译成企业场景会更直观：

• 客服工单：所有“退款咨询”都进同一个队列，不管客户是不是高价值、是否已多次投诉
• IT 运维：CPU 抖一下就报警，不管是不是发布窗口、是不是短暂尖峰
• 销售线索：所有表单提交都推给销售，不管是否重复、是否不符合画像

结论很明确：你需要的不是更多提醒，而是更少但更准的提醒。

在“人工智能在通信与 5G/6G”这条主线里也是一样：网络智能运维（AIOps）真正难的不是采集更多指标，而是把海量 telemetry、告警、日志变成可执行的行动建议。5G/6G 时代连接数更大、边缘更分散，粗暴的告警策略只会更快失效。

从 IoT 到小企业自动化：Swann 的三步法可以直接抄

Swann 的系统能在 11.74 million（1174 万）连接设备规模下运行，并且达到p95 小于 300ms的时延指标。你不需要同样的规模，但你可以抄同样的方法论。

1）先用“便宜逻辑”过滤，再用“贵智能”判断

Swann 的关键改造不是一上来就调用大模型，而是做了大量前置过滤：

• 运动检测
• 区域（zone）分析
• 重复帧消除

他们把 API 调用量从 17,000 RPM 降到 2,000 RPM（减少 88%）。这句话对小企业的含义是：

先写业务规则，再上 AI。先减少输入，再提升判断。

例如：

• 邮箱自动分流：只把“包含订单号 + 付款截图”的邮件送去 AI 判定，其余先走规则
• 运维告警：先聚合 5 分钟窗口内同类告警、去重、合并上下游依赖，再交给模型做根因归类
• 语音助手：先做关键词/意图粗分（比如“报修/投诉/咨询/催单”），再把少量复杂样本交给更强模型

2）用“分层模型路由”，别用同一个模型干所有活

Swann 在 Amazon Bedrock 上使用了四个基础模型，并按场景分配请求比例：

• Nova Lite（87%）：高吞吐、低成本，用于日常筛查
• Nova Pro（8%）：需要更高准确度的威胁验证
• Claude Haiku（2%）：极低延迟、用于时间敏感的定制提醒
• Claude Sonnet（3%）：复杂边界场景，需要更强推理

他们最终达到了总体 95% 准确率，更重要的是：用分层路由把成本压到夸张的程度——相比“全部用 Sonnet”，月成本从预计 $2.1M 降到 $6K（减少 99.7%）。

小企业也完全可以做“轻重分流”：

• 80% 的任务只需要“分类 + 结构化输出”（用更便宜更快的模型）
• 15% 需要“跨字段核对 + 规则解释”（中等模型）
• 5% 才需要“复杂推理 + 多轮澄清”（更强模型或人工复核）

把模型选择当作工作流路由策略，而不是采购决策，往往是成本和体验的分水岭。

3）把输出变成“可执行的结构化字段”，别让模型写小作文

Swann 把每次请求的 token 从 150 降到 18（减少 88%）。其中最值得学习的一点是：他们用机器可解析的结构化输出替代冗长自然语言，比如：

threat:LOW|type:person|action:delivery

这在自动化里非常关键。因为一旦输出能被解析，你就能让系统自动做动作：分派、合并、升级、通知、写入工单。

在“AI 语音助手与自动化工作流”里，我最常见的失败模式就是：模型回答很好看，但后续无法自动执行。要改很简单：

• 规定响应 schema（JSON、key-value、枚举字段）
• 固定字段含义与可选值
• 输出必须包含“下一步动作”字段（如 action:notify|ignore|escalate）

一套可落地的参考架构：把“通知”变成“自动化决策”

Swann 的 AWS 架构里出现了几块典型组件：AWS IoT Core、S3、SQS、Lambda、EC2（GPU）、EventBridge、Cognito、Bedrock。你未必需要全套 AWS，但逻辑可以照搬。

我建议把“告警智能化”拆成 6 个模块，方便你在任何云或自建环境复刻：

1. 事件入口（Edge/渠道）：摄像头帧、系统日志、客服消息、电话录音、网络 KPI
2. 事件总线/路由：统一接入与分发（对应 EventBridge 的角色）
3. 存储与回放：保留原始证据用于追溯（对应 S3）
4. 队列与削峰：峰值时不崩（对应 SQS）
5. 预过滤层：规则、去重、聚合、低成本模型
6. 推理与决策层：按复杂度选择模型，输出结构化决策，触发通知/工单/机器人

这一套对通信网络运维同样成立：在 5G/6G 网络里，边缘节点更多、流量波动更剧烈，队列削峰和“分层推理”会直接决定你的 MTTR（平均修复时间）能不能降下来。

你可以直接照做的 7 条实操清单（小团队版）

下面这份清单的目标只有一个：让自动化先跑起来，再谈“更聪明”。

1. 先选一个可量化的痛点：比如“每天 200 条告警，真正需要处理的不超过 20 条”。否则你会做成一场 AI 展示。
2. 给告警做分级：至少分成 ignore / notify / escalate 三档，并定义升级条件（如金额、VIP、连续出现次数）。
3. 做去重与聚合：同类告警 5 分钟内合并；同一来源重复只保留最新一条。
4. 用结构化输出协议：固定字段，比如：
   • severity（LOW/MED/HIGH）
   • category（payment/network/login/etc.）
   • confidence（0-1）
   • next_action（ignore/notify/escalate）
5. 设定“模型路由”规则：便宜模型先跑；低置信度或高风险再升级到更强模型或人工。
6. 盯住 4 个指标（比“平均值”更有用）：
   • p95/p99 时延（别只看平均）
   • 每天通知量
   • 误报率/漏报率
   • 每条决策成本（token + 调用次数）
7. 灰度发布：像 Swann 一样在 5–10% 流量上 A/B 测试，再全量推。

一句狠话：没有灰度和监控的 AI 自动化，不是工程，是赌博。

“Notify Me When” 对应到企业：让业务用自然语言定义规则

Swann 的 Notify Me When 很有代表性：用户用自然语言说“如果狗进入后院就提醒我”“孩子靠近泳池就提醒我”。这类能力对小企业的意义在于：把规则配置从工程师手里还给业务人员。

把它迁移到你的场景：

• 财务： “当本周退款金额超过 5 万且集中在同一商品时提醒我”
• 运营： “当某个渠道的转化率连续 3 小时低于 1% 时提醒我”
• 网络运维： “当某小区 5G 掉线率上升且同时出现回传链路丢包时升级为高优先级”

自然语言不是为了“更酷”，而是为了让规则更贴近业务变化频率。尤其在 5G/6G 网络优化、流量预测、故障诊断这种高频迭代场景里，规则需要能快速调整，不能每次都等开发排期。

你真正要学的不是 Bedrock，而是“成本工程”

Swann 的结果很硬：

• 告警量下降 25%
• 通知相关性提升 89%
• 威胁检测准确率从 89% 提升到 95%
• 客户满意度提升 3%

这些数字背后最关键的能力是：把 token、RPM、时延、准确率当作可运营的指标，持续优化，而不是一次性上线。

如果你正在做 AI 语音助手或自动化工作流，我建议把预算花在三件事上：

1. 前置过滤（减少调用）
2. 分层路由（匹配任务复杂度）
3. 结构化输出（让自动化可执行）

模型当然重要，但它通常排在第四位。

接下来如果你要在团队里做一个 PoC，最好的起点是：选一个“每天吵你最多”的通知源（客服、运维、审批、门店异常），用两周时间把它改造成“少打扰，但更靠谱”的提醒系统。等你把这一条线跑通，再扩到第二条、第三条。

你希望 AI 帮你过滤掉哪一种“每天都在浪费注意力”的噪声？