Skip to content
工程

执行洞察:AI 工作流的自动异常检测

JieGou 的执行洞察面板检测 AI 配方的故障模式、成本峰值、延迟异常和错误聚类——带有严重性排序的洞察和可操作建议,直接在运营中心中。

JT
JieGou Team
· · 4 分钟阅读

运行一个配方很简单。跨 8 个部门运行 50 个配方,每个调用不同的 LLM 供应商,具有不同的成本特征和延迟特性,这是一个运营问题。标准监控工具可以告诉您服务器是否宕机。它们无法告诉您合同审查配方从上周二开始成本增加了 3 倍令牌,或者三个不同的配方正在以语义相似的错误失败,指向同一个上游问题。

执行洞察是专门为 AI 工作流运营构建的异常检测系统。它位于运营中心的 /operations/landscape 页面,持续分析执行数据以浮现您否则会错过的问题。

四种检测模式

执行洞察运行四个专门的检测器,每个设计用于捕获不同类别的运营问题。

故障模式检测

故障检测器标记错误率在配置的时间窗口内超过 20% 的配方。在 100 次运行中失败 1 次是正常的。在 100 次运行中失败 25 次有系统性问题——损坏的 API 集成、在新输入模式上失败的提示,或开始拒绝某些请求的模型。

检测器不仅仅计算故障。它检查故障轨迹。在过去 48 小时内从 2% 故障率升至 22% 的配方比数周来一直在 21% 左右徘徊的配方更紧迫。洞察包括哪些特定配方受影响、检测到模式的时间范围以及调查建议。

成本峰值检测

LLM 成本与令牌使用量成比例,令牌使用量可以在没有任何代码更改的情况下改变。模型更新可能产生更长的输出。上游数据源可能开始返回更大的文档。提示优化可能意外删除了长度约束。

成本检测器标记令牌使用量与基线相比增加超过 50% 的配方。基线从配置时间窗口内的历史执行数据计算。当通常每次运行使用 2,000 个令牌的配方开始平均 3,500 个令牌时,检测器浮现它——连同受影响的配方、增加幅度和估计成本影响。

这是通用监控工具不提供的信号。CPU 和内存看起来正常。HTTP 状态码都是 200。但您的账单增长速度比使用量快 50%,原因埋在只有 AI 特定监控系统跟踪的令牌级执行数据中。

延迟异常检测

延迟检测器将最近的执行时间与 p95 基线进行比较,并标记超过该阈值 2 倍的配方。p95 延迟为 4 秒的配方开始经常花 10 秒有问题——即使它技术上成功完成。

AI 工作流中的延迟异常通常表示上游问题:模型供应商正在经历降级、MCP 工具响应更慢,或知识库查询走了慢路径。洞察包括基线 p95、当前观察到的延迟以及哪些配方受影响,为您提供足够的上下文立即开始诊断。

错误聚类

单个错误是噪音。三个或更多配方以语义相似的错误消息失败是模式。错误聚类检测器跨配方分组错误,并在时间窗口内标记 3 个或更多相似错误的聚类。

这捕获了按配方监控遗漏的横切故障。如果您的 Anthropic API 密钥过期,五个不同的配方将开始以类似的认证错误失败。没有聚类,您看到五个独立的故障。有了聚类,您看到一个根本原因影响五个配方——建议指向共享依赖。

严重性排序和建议

每个洞察被分为三个严重性级别之一:

  • 严重 —— 需要立即关注。高故障率、极端成本峰值或表示系统性问题的大型错误聚类。
  • 警告 —— 检测到降级但尚未严重。适度的成本增加、升高的延迟或新出现的故障模式。
  • 信息 —— 值得了解但不紧急。轻微偏差、单配方异常或趋向阈值但尚未跨越的模式。

每个洞察包含结构化建议——不仅仅是”调查这个配方”而是具体的下一步。成本峰值洞察可能建议检查配方的提示是否缺少长度约束,或比较最近模型更改前后的令牌使用量。故障模式洞察可能建议审查配方的错误日志以找到最常见的故障原因。

洞察按严重性排序显示在 ExecutionInsightsPanel 中,因此严重问题始终在顶部。每个洞察卡片显示类型、严重性、标题、描述、受影响的配方、时间范围、建议和支持数据点。

时间范围配置

异常检测的好坏取决于您查看的窗口。在 7 天内令人担忧的峰值在 90 天内可能是正常的季节性变化。执行洞察支持三个可配置的时间范围:

  • 7 天 —— 最适合捕获急性问题。短基线、高灵敏度。
  • 30 天 —— 平衡视图。平滑每日变化,同时仍能捕获周环比变化。
  • 90 天 —— 长期趋势。最适合识别成本或延迟的渐进漂移。

切换时间范围同时更新所有四个检测器,因此您可以快速交叉引用 7 天异常是否在 30 天也可见(真实问题)或在更宽窗口消失(临时波动)。

运营中心集成

执行洞察与其他运营中心视图并列:自动化全景、治理、收入分析、可用性监控和安全监控。这种布局是有意的。异常检测不是独立工具——它是运营感知的一部分。

洞察 API 可通过 /api/insights/execution 访问,需要 audit:read 权限。这意味着任何具有运营可见性的团队成员都可以编程查询洞察——将它们输入 Slack 警报、外部仪表板或自动修复工作流。

为什么 AI 特定监控很重要

通用应用监控观察 HTTP 状态码、响应时间、错误率和资源利用率。这些指标很重要,但它们遗漏了 AI 工作流独有的信号。

**令牌成本对 APM 工具不可见。**配方可以返回 HTTP 200 并带有正确输出,但因为模型生成不必要的冗长响应而成本是应有的 3 倍。执行洞察在配方级别跟踪令牌使用并检测成本偏离基线。

**模型延迟不是服务器延迟。**对于使用 50,000 令牌上下文窗口调用 Claude Opus 的配方来说,12 秒的响应时间可能是正常的。对于通常 2 秒完成的 Haiku 配方来说,相同的 12 秒响应是危险信号。执行洞察维护按配方基线而不是应用一刀切的延迟阈值。

**语义错误聚类需要理解错误消息。**传统监控按 HTTP 状态码或错误类分组错误。执行洞察按语义相似性分组错误,将”rate limit exceeded”和”too many requests”作为同一底层问题捕获,即使它们是不同的字符串。

这些是告诉您 AI 自动化是否健康的信号——不仅仅是您的服务器是否在运行。

执行洞察在 Team 和 Enterprise 计划上可用。探索运营中心开始免费试用

operations monitoring anomaly-detection observability insights
分享这篇文章

喜欢这篇文章吗?

在您的信箱中获取工作流程技巧、产品更新和自动化指南。

No spam. Unsubscribe anytime.