用生成式 AI 降噪：IoT 告警到智能工作流

每天 20 条摄像头通知，最后真正有用的可能只有 1 条。更糟的是：当“噪声”长期轰炸用户时，人会本能地关闭提醒——真正的风险就被埋掉了。Swann 在 11.74 million（1174 万）联网安防设备上遇到的“告警疲劳”，其实也是很多小企业在客服、运维、销售线索分配里天天上演的同一件事：信息太多，判断太少，自动化反而让人更忙。

这篇文章把 Swann 基于 Amazon Bedrock 的案例，重新放到“AI 语音助手与自动化工作流”的视角里讲清楚：你不需要先做一个“全知全能的 AI”，你需要的是一套分层、可控、可监控的自动化决策链路，把重复判断交给机器，把少数关键事件准确推到人面前。

同时，它也属于「人工智能在通信与 5G/6G」系列的一部分：当设备数量上到百万级，网络链路更复杂（5G/6G、边缘节点、跨区域数据合规），低时延、可扩展的智能运维不再是锦上添花，而是体验与成本能否成立的底线。

告警疲劳不是“通知太多”，而是“上下文太少”

最直接的结论：要降低告警数量，靠“阈值调高一点”没用；必须让系统理解上下文。 Swann 之前的检测逻辑基本只能区分“人/宠物”，但无法知道“这个人是快递员还是可疑闯入者”，也无法让用户定义“我认为重要的是什么”。结果就是大量无关事件（车辆经过、树枝晃动、宠物活动）不断触发。

这件事对小企业的映射非常清晰：

• 客服系统把所有来电都当成同等级“工单”，结果值班人员被低价值咨询淹没。
• 销售线索系统把所有表单提交都推给同一组人，结果高意向客户被延迟响应。
• 运维告警系统对每次 CPU 抖动都报警，结果真正的链路故障没人接。

问题不在“有没有自动化”，而在“自动化有没有判断力”。 生成式 AI（尤其是多模态模型）擅长的正是把碎片化信号整理成“可执行的判断”。

Swann 的方法：多模型分层 + 业务预过滤，先省钱再提准

Swann 这个案例之所以值得抄作业，不是因为它用了某个模型，而是因为它把“架构和成本”当成一等公民来设计。

他们每月大约要做 275 million（2.75 亿）次推理。如果所有请求都用高能力模型处理，成本会爆炸、延迟也会失控。Swann 的关键动作有两个：

1) 业务预过滤：先把 65% 的垃圾挡在门外

他们在调用生成式 AI 之前，做了三层“便宜的判断”：

• 运动检测与区域规则（zone-based analysis）
• 重复帧消除（duplicate frame elimination）
• 在 GPU EC2 上跑的自定义预过滤模型，直接剔除树枝晃动、车辆经过等误触发

数据很硬：他们把调用频率从 17,000 RPM 降到 2,000 RPM（减少 88%）。

把这一步翻译成业务工作流语言：

生成式 AI 不应该接管所有请求，它应该接管“通过基础规则筛选后仍需要判断的那一小部分”。

2) 多模型路由：让“便宜模型”干体力活，“强模型”做难题

Swann 用 Amazon Bedrock 做统一入口，通过不同模型承担不同复杂度任务：

• Nova Lite（87% 请求）：高吞吐、低成本、做常规筛查
• Nova Pro（8%）：做威胁验证，提升精度
• Claude Haiku（2%）：极低时延，支撑“Notify Me When”这类强时效需求
• Claude Sonnet（3%）：处理复杂边界案例，需要更强推理

结果同样硬：整体准确率达到 95%，同时把“全部用高阶模型”的预估月成本从 $2.1 million 降到 $6 thousand（降低 99.7%）。

我很认同这里的立场：省钱不是靠选一个更便宜的模型，而是靠把请求分层。

一套可复制的架构：从 IoT 告警到语音助手工作流

Swann 的云上链路大致是：设备接入 → 事件总线与队列 → 视频抽帧与过滤 → Lambda 调 Bedrock → 动态通知。

你不做安防，也能照着搭一套“上下文自动化”流水线，尤其适合小企业把语音助手、工单、线索、运维告警串起来。

事件驱动骨架：别让系统靠“轮询”和“人工转发”运转

Swann 使用的组合非常典型：

• AWS IoT Core：设备连接与消息
• EventBridge + SQS：事件路由与削峰填谷（高峰期摄像头同时触发）
• S3：存储视频帧（或你的业务里：录音、图片、附件）
• Lambda：无服务器执行，按量计费
• Cognito：用户认证与授权
• Bedrock：多模型统一调用

对于“AI 语音助手与自动化工作流”，把它替换成下面这类输入也成立：

• 语音通话录音（呼叫中心）
• WhatsApp/企业微信对话（客服）
• 现场照片（巡检/质检）
• 设备遥测（智能运维）

关键是：让每个事件进入同一条“判断管道”，输出标准化的结构化结果，再由工作流分发给人或系统。

把输出做成机器可读：别让后续系统去猜

Swann 的提示词优化很实用：用结构化键值对替代长文本，例如：

• threat:LOW|type:person|action:delivery

他们把单次请求 tokens 从 150 降到 18（减少 88%），同时降低成本和时延。

把这招用在语音助手工作流里，效果也很直接。比如电话摘要别输出“自然语言作文”，而是输出：

• intent:refund|sentiment:negative|urgency:high|next_step:call_back|owner:cs_team

后续自动分配、SLA 计时、提醒策略都能立刻落地。

面向 5G/6G 与智能运维：你需要监控的是“p95”，不是平均值

在「人工智能在通信与 5G/6G」语境下，最容易被忽略的一点是：网络与推理链路的尾部延迟（tail latency）决定体验。

Swann 把系统做到 p95 < 300 ms，并强调监控 p50/p95/p99，而不是看平均值。原因很现实：平均 200ms 可能掩盖了 5% 请求 2 秒以上——对安防、对语音助手实时交互、对智能运维的告警闭环都是灾难。

如果你在做面向 5G/6G 的智能运维（AIOps），建议从一开始就把这些指标写进仪表盘：

• 推理时延：p50 / p95 / p99
• 令牌消耗：tokens per request（直接对应成本）
• 单次推理成本：cost per inference
• 准确率：按业务定义（误报率/漏报率/命中率）
• 限流与重试：throttling events、队列堆积长度

一句话：你优化的不是“模型有多聪明”，而是“系统在最差时刻还能不能稳”。

小企业怎么落地：从“告警”做起，而不是从“全自动”做起

如果你正在考虑把生成式 AI 引入语音助手或自动化工作流，我建议照这个顺序推进，最快产生业务价值。

1) 先选一个可量化的“降噪指标”

Swann 的指标很清楚：告警量下降、相关性提升、满意度提升。你的业务也要一样具体：

• 客服：每日工单量下降 20%，但一次解决率不下降
• 销售：高意向线索响应时间从 2 小时降到 10 分钟
• 运维：误报率降低 50%，但重大故障漏报为 0

2) 先做预过滤与分层路由，再谈“更大模型”

可复制的分层策略：

1. 规则/轻量模型：快速筛掉明显无关事件
2. 便宜多模态模型：批量理解与分类
3. 强推理模型：只处理升级事件（疑似风险、用户自定义条件、边界案例）

这也是控制预算的唯一靠谱办法。

3) 把提示词当成“版本化的产品资产”管理

Swann 会给 prompt 打版本并做小流量 A/B（5%–10%）验证。你也应该这样做，并记录三组元数据：

• 准确率（或误报/漏报）
• 平均 tokens（成本）
• p95 时延（体验）

只要你做到了这三件事，生成式 AI 就不再是“玄学”，而是工程。

观点很明确：没有 prompt 版本管理的 AI 自动化，迟早变成不可控的成本黑洞。

从 Swann 学到的真正经验：自动化要“懂情境”才省人

Swann 的系统把告警量降低 25%，通知相关性提升 89%，满意度提升 3%。这些数字背后不是“AI 更强了”，而是“工作流更聪明了”：先过滤、再分层、只把关键事件推给人。

如果你的目标是用 AI 语音助手与自动化工作流带来线索与转化（LEADS），最值得借鉴的是这一点：让 AI 承担“判断与分流”，让团队把精力花在真正需要沟通与决策的地方。

接下来一个更值得思考的问题是：当 5G/6G 把终端和边缘节点继续推向“超密集连接”，你要把多少判断放在云端，多少放在边缘？你的系统在断网、限流、跨区合规时，是否还能“优雅降级”而不误报、不漏报？这会决定你能否把智能自动化从试点做成常态。