S53：慢、贵、答错、工具错误与人工 Backlog 的信号差异

内容类型：预习教材（不代表已完成）
日期：2027-01-14
阶段：P2 · AI Systems Engineering 90
总路线：Day 143 / 360
周次：W8 · Observability、Cost、SLO、Capacity
节奏：周四案例与连接
状态：教材已备；学习未完成
标签：incident、diagnosis、quality、cost、tool-error、human-backlog

一句话定义

AI incident 诊断要先区分用户症状与系统原因：慢、贵、错误答案、工具失败和人工积压可能互为因果，却需要不同信号与处理动作。

学习目标

1. 能为五类症状选择可验证信号，而不是凭单一 dashboard 猜测。
2. 构建从用户影响→时间线→路径 slice→候选原因→验证的 incident walkthrough。
3. 理解降级、限流、回滚和人工接管会改变质量、成本与负担。
4. 在复盘中区分事实、推断和未知。

核心知识

• “慢”可能来自到达 burst、排队、长 context、模型、工具、重试或人工等待；端到端 p95 只能指出症状。
• “贵”可能来自 token 增长、cache miss、循环工具调用、失败重试、昂贵模型路由或人工返工。
• “答错”需要 eval、用户反馈、业务 outcome 或抽样复核；错误率上升也可能由数据 freshness、tool schema 或 policy 变化触发，而非模型版本。
• Tool error 要分 validation、auth、rate limit、dependency、timeout 和 unknown effect；聚合为 tool_failed 会妨碍恢复。
• Human backlog 由到达率、处理率、案件复杂度、班次和返工决定。自动把更多低置信任务送人工会保护质量，却可能使队列超载并延迟高风险任务。
• Incident response 先保护用户和业务，再恢复服务，再学习；不应为快速“全绿”删除异常证据。

机制与推导

可用排队近似建立 backlog 直觉：到达率 (\lambda) 持续高于处理率 (\mu)，队列就增长。Little's Law 在稳定条件下给出 (L=\lambda W)，把平均在制任务数与等待时间联系起来；非稳定 burst 时不要机械套用。

Walkthrough：

症状：p95 task time 上升
切片：仅 tool=case-search 且 model version 未变
时间线：tool schema v2 发布后 auth error 增多
连锁：retry 增加 -> token/cost 增加 -> fallback to human -> backlog 增加
处置：停止重试该错误、回退 schema route、保护高风险队列
验证：错误类型、队列、成功任务率恢复；保留残余未知

最小练习或观察步骤

1. 使用合成数据选择一个首发症状，例如 p95 变慢。
2. 列五类信号：traffic、latency、error、quality、cost/human workload。
3. 写一条包含版本变更和依赖异常的时间线。
4. 画因果假设并为每个箭头写可验证证据。
5. 选择一项临时处置，写出它可能转移到质量或人工的代价。
6. 用“已知事实 / 推断 / 未知”三栏结束，不虚构真实 incident。

常见误区与边界

• 看到模型延迟升高就直接换小模型，未检查 queue 和工具。
• 总错误率正常就忽略高风险 slice 的严重失败。
• retry 掩盖依赖故障，同时增加延迟与成本。
• 把所有低置信请求交给人工，却不观察人工容量。
• 复盘只写“增加监控”，没有说明要回答的问题和 owner。
• 本日是合成 walkthrough，不代表经历真实生产事件。

系统 / 金融 / Web3 场景连接

金融系统中，低风险查询变慢和高风险审批积压影响不同，incident 应优先保护决策权与时限。Web3 Agent 的 RPC 故障可能触发多节点重试，既增加成本又返回不同区块高度；诊断需记录 provider、chain、block 与一致性，而非只看 HTTP error。

自检问题

1. 同一个“慢”症状有哪些不同根因？
2. retry 怎样同时影响成本和人工 backlog？
3. 为什么 incident 时间线必须包含版本和配置变化？
4. 如何区分事实、推断与未知？

专业课程对齐

• 阅读 Google SRE 资源 中 incident response、monitoring distributed systems 与 postmortem 章节，映射检测、缓解、恢复和学习的顺序。
• 阅读 OpenTelemetry 官方文档 的 traces、metrics、logs 和 context propagation，关注怎样从聚合症状下钻到具体调用路径。
• 阅读 Full Stack Deep Learning 2022 的 troubleshooting、monitoring 与 data management 内容，理解 AI 故障可能来自数据、模型和系统多层。

深入学习提示

先写症状，至少列三种竞争性原因，再看信号；不要先选喜欢的根因。深入时为每个缓解动作写次生代价，例如降级模型对质量、切人工对队列、禁重试对可用性的影响。保持为一页案例，不扩成演练 gate。

学后填写区

• 合成 incident 症状：
• 时间线与关键 slice：
• 因果假设及证据：
• 处置与次生代价：
• 事实 / 推断 / 未知：