S52：OTel-like 属性、p50/p95 与 Cost per Success

内容类型：预习教材（不代表已完成）
日期：2027-01-13
阶段：P2 · AI Systems Engineering 90
总路线：Day 142 / 360
周次：W8 · Observability、Cost、SLO、Capacity
节奏：周三引导练习
状态：教材已备；学习未完成
标签：opentelemetry、semantic-attributes、percentile、tail-latency、cost-per-success

一句话定义

标准化属性让跨组件信号可以比较，分位数暴露延迟分布，cost per success 则把资源消耗与有效业务结果对齐，而不是只统计 token 单价。

学习目标

1. 将本地 trace 字段映射到资源、span 与 AI 特有属性。
2. 能手算或用小脚本计算 p50/p95，并说明小样本限制。
3. 区分请求延迟、排队、模型时间、工具时间和人工等待。
4. 能定义成功分母并计算一组示例 unit cost。

核心知识

• OTel resource 描述产生 telemetry 的实体，span attributes 描述操作，events 记录操作内瞬时事实。属性命名需要稳定语义与单位。
• 延迟分布常偏斜，平均值容易被少量极慢值影响，也可能掩盖尾部。p50 表示中位体验，p95 表示 95% 观测不超过的阈值，但估算方法与样本量要说明。
• End-to-end latency 可拆为 queue + retrieval + model prefill/decode + tool + retry + human wait。不同优化只影响其中一段。
• Cost per success 的 success 必须可判定且时间窗口对齐；若业务结果延迟，先报告 provisional cost，并注明尚未成熟。
• Slice 很重要：总体 p95 正常，某语言、长上下文、风险等级或工具路径可能异常。Slice 太细则样本不足和高基数问题加剧。
• 指标需要 exemplar 或 trace link，才能从聚合异常回到具体路径，同时遵循隐私边界。

机制与推导

对排序后的 (n) 个延迟值，可用 nearest-rank 简化计算：p95 位置 (k=\lceil0.95n\rceil)。不同库插值方式可能不同，因此要记录方法。只有 10 个样本时 p95 近似最大值，不能声称代表稳定尾延迟。

成本示例：10 个任务总模型成本 5、工具成本 2、人工成本 8，其中 8 个成功，则 cost/success=(5+2+8)/8=1.875。若只算模型 token，会报告 0.5/request，完全看不到人工成本是主要部分。

属性映射应避免自由生成：service.name、operation、model/provider、token usage、workflow id、tool name、outcome、error type 等分别有明确层次。若语义约定尚未覆盖某 AI 字段，可使用受控自定义命名并记录版本。

最小练习或观察步骤

1. 只读查看 attributeMap.ts 与 trace types，列出已有字段和缺失语义。
2. 取 10～20 个合成 duration，明确算法后计算 p50、p95 与平均值。
3. 将总时长拆成 queue/model/tool/human，找出尾部由哪段主导。
4. 给出模型、工具、人工三项成本和成功数，算 cost/request 与 cost/success。
5. 选择一个合理 slice，再说明样本不足时不能下何种结论。
6. 不要求接入 OTel collector；映射表与计算就足够。

常见误区与边界

• 比较不同工具算出的 p95，却不核对插值与窗口。
• 小样本 p95 被当作稳定 SLO 证据。
• 所有属性都成为 metric label，导致 cardinality 爆炸。
• 只有 token cost，没有失败重试、工具与人工成本。
• success 由“HTTP 200”定义，忽略正确性和业务完成。
• OTel-like 本地映射不等于符合全部官方语义约定或已生产接入。

系统 / 金融 / Web3 场景连接

AML 高风险案件可能天然耗时更长，不能与简单查询混为单一分布；应按路径解释而非惩罚复杂案件。Web3 交易的 RPC 延迟、区块等待和最终确认要分开，链上确认时间不应算作模型推理性能，却属于用户完成时间。

自检问题

1. p95 在 10 个样本上为何不稳定？
2. 哪些属性适合 span，哪些不适合 metric label？
3. cost/request 与 cost/success 的分母差异是什么？
4. 端到端慢时怎样定位是 queue、model、tool 还是 human？

专业课程对齐

• 阅读 OpenTelemetry 官方文档 的 resources、traces、metrics 与 semantic conventions，重点对照属性层次和 context propagation。
• 阅读 Google SRE 资源 中 latency、tail behavior、SLI/SLO 与 monitoring 章节，理解分位数为何比单一平均值更接近用户体验。
• 阅读 Stanford CS329S 的 deployment、monitoring 和 continual learning 课程结构，连接模型表现、系统指标和长期业务反馈。

深入学习提示

用两组平均值相同但尾部分布不同的数据建立直觉。再对 unit cost 做“分母审计”：谁算成功、结果何时成熟、失败和人工是否进入分子。深入到此即可，不需要为了几个合成数字搭建 dashboard。

学后填写区

• 属性映射表：
• p50 / p95 算法与结果：
• 成本分子与成功分母：
• 一个 slice 观察边界：
• 未验证部分：