S50：AI Telemetry、Correlation、SLO 与 Unit Cost
AI 可观测性用关联的 trace、metric、log、eval、audit 与业务结果解释一次任务为何慢、贵、错误或需要人工介入；SLO 则把用户可感知目标变成有边界的运行承诺。
内容类型：预习教材（不代表已完成）
日期：2027-01-11
阶段：P2 · AI Systems Engineering 90
总路线：Day 140 / 360
周次：W8 · Observability、Cost、SLO、Capacity
节奏：周一概念与阅读
状态：教材已备；学习未完成
标签：telemetry、correlation、sli、slo、error-budget、unit-cost
一句话定义
AI 可观测性用关联的 trace、metric、log、eval、audit 与业务结果解释一次任务为何慢、贵、错误或需要人工介入；SLO 则把用户可感知目标变成有边界的运行承诺。
学习目标
- 区分 trace/span/event、metric、log、eval、audit 各回答的问题。
- 能定义包含可用性、尾延迟、质量、成本与人工负担的轻量 AI SLI。
- 理解 correlation 怎样把请求、模型、工具、人工和业务 outcome 串起来。
- 区分 token cost、request cost 与 cost per successful task。
核心知识
- Trace 表示一条因果执行路径，span 表示其中有起止的操作，event 表示 span 内瞬时事实；metric 适合聚合趋势；log 保存离散诊断文本；audit 强调决策责任和不可抵赖；eval 衡量输出质量；业务 outcome 可能延迟数天才出现。
- Correlation id 连接同一业务旅程，但 trace 可能因异步、重试和人工等待跨越多个技术 trace。需要同时保留 business/workflow id、trace id 与 causation。
- SLI 是测量方式，SLO 是目标范围，error budget 是允许未达目标的空间。SLO 必须有窗口、分母、排除条件与数据来源。
- AI 质量不是传统 uptime 的附属指标。服务可以 200 OK 却事实错误；也可以回答正确但人工复核队列已失控。
- Unit cost 应包括模型、检索、工具、平台、失败重试和人工时间。成本分母应对齐业务价值，例如成功解决的案件，而非总请求。
- 高基数属性（user id、prompt、完整错误）不适合直接做 metric label；敏感正文也不应默认进入 telemetry。
机制与推导
一个任务可拆为：
request span
├─ retrieval span
├─ model span (tokens/model/version)
├─ tool span (attempt/idempotency/result)
└─ human-wait span or linked human task
eval record -> links output/version/dataset
audit record -> links actor/policy/decision
business outcome -> links workflow later
成功任务单位成本：
[ C_{success}=\frac{C_{model}+C_{retrieval}+C_{tool}+C_{platform}+C_{human}+C_{retry}}{N_{successful\ tasks}} ]
若失败率从 5% 升到 25%，cost/request 可能几乎不变，而 cost/success 和人工 backlog 明显恶化。SLO 因此可采用组合视图，但不要把不同量纲硬加成一个神秘总分。
最小练习或观察步骤
- 选择一个合成 Agent 任务，列出 trace、metric、log、eval、audit 和 outcome 各一条记录。
- 为记录选择 workflow id、trace id、span id、version 与 actor 等关联字段。
- 定义三个轻量 SLI：p95 完成时间、有效任务率、人工等待时间或 cost/success。
- 为每个 SLI 写分母、窗口和不能证明的结论。
- 找出两个不应写入 telemetry 的敏感或高基数字段。
- 不要求建立 dashboard，也不填写未测得的数值。
常见误区与边界
- 将所有信号都写入日志，再靠全文搜索承担指标和审计。
- 只有 HTTP 状态和平均延迟，没有模型、工具、版本和业务结果关联。
- 用平均值掩盖 p95/p99 尾部和特定风险 slice。
- 把 token 数最少等同于任务最便宜，忽略错误与人工返工。
- 直接记录 prompt、客户标识、工具参数与模型回复全文。
- 本日目标是信号分类和指标语义，不做监控覆盖率 gate。
系统 / 金融 / Web3 场景连接
金融调查助手的成功可能是“分析师在证据充分条件下完成案件步骤”，不仅是模型回复。需要把模型版本、检索、工具错误、人工等待和最终案件结果关联。Web3 Agent 则要记录链、区块高度、RPC、simulation、签名和确认阶段；200 响应不能替代链上效果。
自检问题
- trace、metric、eval 与 audit 各回答什么？
- 为什么一个业务旅程可能跨多个技术 trace？
- SLO 的分母和窗口为何重要？
- cost/request 怎样掩盖失败和返工？
专业课程对齐
- 阅读 OpenTelemetry 官方文档 的 traces、metrics、logs、context propagation 与 semantic conventions 概览，把信号类型映射到本日分类表。
- 阅读 Google SRE 资源 中 SLI/SLO、error budget 与 monitoring 章节入口，重点学习目标、窗口和用户体验之间的关系。
- 阅读 Full Stack Deep Learning 2022 的 monitoring 与 ML operations 相关讲次，观察模型质量、数据变化和服务信号为何需要共同解释。
深入学习提示
先从“要回答的问题”选信号，不从 telemetry 字段清单出发。每个指标旁写一个它不能支持的结论。深入时画技术 trace 与长时 business workflow 的关联，特别标出人工等待和延迟 outcome；无需立即搭建观测栈。
学后填写区
- 信号分类表：
- 三个 SLI 及分母：
- 关联字段设计：
- 敏感数据边界：
- 尚未理解的问题：