AI Observability / Cost / SLO Playbook

目标：训练把 AI 系统从 demo 变成可运营服务的能力。一个可上线的 AI service 不只要“能回答”，还要能解释每次回答经历了什么、花了多少钱、慢在哪里、质量是否稳定、风险是否被拦截、用户是否真的采用、业务结果是否改善。

---

1. 定位：把架构、平台、推理优化和 EvalOps 连起来

这份手册是四类学习资产之间的运营层连接器：

一句话定位：

AI observability 是 AI 系统的运营控制面。它让 PM/BA/Architect 能够回答：这次输出为什么是这样、证据来自哪里、模型和工具有没有失败、成本是否合理、SLO 是否违反、用户是否采用、业务是否真的变好。

在金融零售场景，AI service 的上线证据不能停留在 prompt 截图或离线 eval 分数。真正的运营证据要覆盖：

• request trace：一次用户请求从入口到输出的完整链路。
• prompt / retrieval / tool / judge span：每个关键 AI 行为的输入、输出、版本、耗时、错误和风险标签。
• token / cost ledger：按 use case、team、customer segment、model、route、知识库、工具归因。
• latency：TTFT、total latency、queue wait、retrieval latency、tool latency、judge latency、human review turnaround。
• quality：answer quality、retrieval quality、groundedness、citation correctness、policy compliance、judge score、expert review result。
• safety：policy block、PII leakage block、unsafe tool attempt、high-risk escalation、human override。
• adoption：target user activation、repeat use、accepted suggestion、workflow completion。
• business outcome：resolved case、AHT reduction、false positive reduction、first contact resolution、dispute cycle time、forecast accuracy、ROI。

---

2. Source Anchors

---

3. 为什么 AI Observability 不等于普通 APM

普通 APM 关注服务是否可用、接口是否慢、错误率是否高。AI service 的核心风险不止这些。

同一个 HTTP 200 可能代表完全不同的结果：

• 回答很快，但引用了错误政策。
• 模型没有报错，但检索召回了过期知识。
• 工具调用成功，但 action policy 不应该允许。
• judge 给出高分，但 judge prompt 版本漂移。
• 用户看到答案后没有采纳，业务流程没有改善。
• 单次成本看似正常，但长上下文让高峰期预算失控。

所以 AI observability 要从“系统运行是否正常”升级为“AI 行为是否可解释、可验收、可治理、可优化”。

核心差异：

---

4. AI Observability Stack

一个生产级 AI service 至少需要九类可观测对象。

4.1 Request Trace

Request trace 是一次 AI 请求的完整时间线。它回答：

• 谁在什么工作流里触发了请求？
• 请求属于哪个 use case、risk tier、tenant、customer segment？
• 使用了哪些 prompt、model、retriever、index、tool、judge、policy？
• 哪一步耗时最多、花费最高、质量下降、被安全策略拦截？
• 输出是否被用户接受、编辑、覆盖、升级人工？

最小字段：

4.2 Model Call Span

Model call span 记录每次模型调用。它不是只记录模型名字，而要记录“为什么选它、输入输出规模、版本、延迟、成本和质量信号”。

关键字段：

• model.provider：模型供应商或内部服务。
• model.name：模型或部署名。
• model.version：供应商版本、deployment version 或 internal alias。
• prompt.template_id / prompt.version：prompt registry 中的模板和版本。
• input_tokens / output_tokens / reasoning_tokens：token 规模。
• ttft_ms：time to first token。
• total_latency_ms：完整响应耗时。
• temperature / top_p / max_output_tokens：生成参数。
• route_reason：fast_path、high_risk_route、fallback、budget_route、quality_retry。
• cache_status：hit、miss、bypass、stale_blocked。
• cost_usd：本次模型调用成本。
• finish_reason：stop、length、tool_call、content_filter、error。

4.3 Retrieval Span

Retrieval span 让团队知道 RAG 是不是召回了对的证据，而不是只看最终答案。

关键字段：

• knowledge_base_id / index_version：知识库和索引版本。
• chunking_policy_version：chunk 策略版本。
• embedding_model：向量模型版本。
• query_rewrite_version：查询改写策略版本。
• retrieval_top_k：召回数量。
• reranker_model：rerank 模型。
• filter_policy：权限、地区、产品、客户类型、日期过滤。
• retrieved_doc_ids：召回文档标识。
• citation_doc_ids：最终引用文档标识。
• retrieval_latency_ms：检索耗时。
• retrieval_quality_score：离线或线上 judge/专家抽样评分。
• freshness_days：证据距离当前日期的时间差。
• permission_filter_result：allowed、filtered、blocked。

4.4 Tool Call Span

Tool call span 用于观测 agent 或 workflow 调用外部系统的行为，尤其是金融零售中的高风险动作。

关键字段：

• tool.name：如 case_lookup、payment_dispute_status、aml_case_notes、policy_search。
• tool.risk_level：read_only、write_low、write_high、irreversible。
• tool.schema_version：工具输入输出 schema 版本。
• tool.input_hash：输入摘要，避免泄露敏感明文。
• tool.latency_ms：工具调用耗时。
• tool.error_code：业务或技术错误。
• policy_decision：allowed、blocked、requires_human_approval。
• approval_id：人工审批记录。
• side_effect：none、draft_created、case_updated、message_sent、payment_action_requested。

4.5 Judge Span

Judge span 记录自动评测发生了什么。它是 eval cookbook 在线化的关键。

关键字段：

• judge.type：deterministic、llm_as_judge、expert_sampling_trigger、hybrid。
• judge.model / judge.prompt_version：LLM judge 的模型和 rubric 版本。
• eval_requirement_id：对应需求到评测矩阵中的 requirement。
• rubric_id / rubric_version：评分规则。
• score：数值评分。
• pass_fail：是否通过阈值。
• severity：S0 / S1 / S2 / S3。
• judge_latency_ms：评测耗时。
• judge_cost_usd：评测成本。
• failure_reason：unsupported_claim、bad_citation、unsafe_advice、tool_policy_violation。

4.6 Human Review Span

金融场景的 AI 不应假装“全自动即成熟”。Human review span 让人工审批、抽样 QA、专家复核可量化。

关键字段：

• review.type：pre_send_approval、post_hoc_qa、expert_review、risk_escalation。
• reviewer_role：QA、compliance、AML lead、credit policy owner、branch supervisor。
• review_decision：approved、edited、rejected、escalated。
• edit_distance：人工修改幅度。
• review_latency_ms：从进入复核到完成的耗时。
• override_reason：wrong_policy、missing_evidence、tone_issue、regulatory_risk、customer_context_missing。
• linked_eval_case：是否转成 golden set 或 regression case。

4.7 Cost Ledger

Cost ledger 是成本账本。它不能只按模型汇总账单，而要按业务价值归因。

成本项：

• input token cost。
• output token cost。
• reasoning token cost。
• embedding cost。
• vector DB / retrieval cost。
• rerank cost。
• tool/API cost。
• judge/eval cost。
• human review cost。
• cache storage / invalidation cost。
• monitoring and trace storage cost。
• peak capacity / idle capacity cost。

归因维度：

• use case。
• business unit。
• workflow step。
• customer segment。
• model route。
• risk tier。
• prompt version。
• knowledge base。
• tool。
• user role。
• success / failure outcome。

4.8 Quality Dashboard

Quality dashboard 不是一次性 eval report，而是上线后的质量趋势。

至少展示：

• pass rate by requirement。
• groundedness score trend。
• citation correctness。
• retrieval recall / precision proxy。
• unsupported claim rate。
• policy violation rate。
• judge disagreement rate。
• human rejection / edit / override rate。
• quality by model route。
• quality by knowledge base version。
• quality by customer segment / product line。

4.9 Incident Timeline

AI incident timeline 记录从异常出现到恢复、复盘、回归测试更新的全过程。

时间线节点：

• detection：由 dashboard、user feedback、QA sampling、risk alert、cost anomaly 发现。
• triage：判断影响范围、风险等级、是否停用。
• containment：禁用 prompt/model/tool route、切换 fallback、升级人工、冻结高风险动作。
• diagnosis：定位到 model、prompt、retrieval、tool、policy、judge、data freshness 或用户流程。
• correction：修复配置、知识库、prompt、routing、policy、工具 schema 或用户教育。
• validation：离线回归、shadow run、canary release。
• postmortem：补充 golden set、SLO、dashboard、runbook、owner。

---

5. Reference Architecture：从一次请求到运营闭环

flowchart LR
  U[User / Workflow] --> GW[AI Gateway]
  GW --> POL[Policy and Risk Tiering]
  POL --> TRACE[Trace Context]
  TRACE --> RET[Retrieval Span]
  RET --> MC[Model Call Span]
  MC --> TOOL[Tool Call Span]
  TOOL --> JUDGE[Judge Span]
  JUDGE --> HR[Human Review Span]
  HR --> OUT[Response / Action]
  OUT --> FB[User Feedback and Adoption]
  TRACE --> LEDGER[Cost Ledger]
  JUDGE --> QD[Quality Dashboard]
  FB --> BO[Business Outcome Metrics]
  LEDGER --> CR[Cost Review]
  QD --> INC[Incident Timeline]
  BO --> QR[Quarterly AI Review]

设计原则：

1. Trace context 必须从入口开始，不要等模型调用时才补日志。
2. 所有 span 必须携带 use case、risk tier、owner、version 和 outcome。
3. 质量信号要能回链到 requirement id 和 eval case。
4. 成本账本要能解释“成功一次业务结果花了多少钱”，而不是“本月调用了多少 token”。
5. 高风险 action 的 tool span 必须和 human approval / policy decision 绑定。
6. Dashboard 要同时服务 PM、BA、Architect、SRE、Risk、Finance，不同角色看同一事实的不同视角。

---

6. Metrics Taxonomy

AI metrics 要分层，不要把所有指标堆在一个 dashboard。

6.1 Latency Metrics

6.2 Token and Context Metrics

6.3 Cache Metrics

金融场景的 cache key 至少包含：

• tenant / business unit。
• user role / permission scope。
• customer segment。
• product / jurisdiction。
• policy version。
• knowledge base version。
• risk tier。
• prompt version。
• tool permission profile。

6.4 Retrieval Quality Metrics

6.5 Judge and Quality Metrics

6.6 Tool and Agent Metrics

6.7 Safety and Risk Metrics

6.8 Adoption Metrics

6.9 Business Outcome and ROI Metrics

---

7. Metric Tree：从业务结果倒推观测指标

不要从“我们能采集什么”开始，而要从业务目标倒推。

示例：Customer Service RAG

Business outcome
  First contact resolution 提升
  Average handling time 降低
  Complaint escalation 降低
  Compliance incident 为 0

Operational outcomes
  Answer accepted by agent
  Answer has correct citation
  High-risk answer escalated
  Response visible within workflow SLA

AI quality drivers
  Retrieval recall@k
  Citation precision
  Groundedness score
  Unsupported claim rate
  Judge pass rate
  Human edit distance

System drivers
  TTFT
  Total latency
  Retrieval latency
  Tool error rate
  Cache hit rate
  Token per answer
  Cost per successful answer

PM/BA/Architect 的关键判断：

• 如果业务指标没改善，但 AI 指标好看，说明 AI 可能没有嵌入真正工作流。
• 如果 adoption 高但质量下降，说明用户可能在用一个有风险的捷径。
• 如果质量高但成本不可控，说明 scale gate 还没准备好。
• 如果 latency 达标但 human review turnaround 慢，真正的瓶颈在 operating model。

---

8. SLO / SLA：AI SLO 不能只写 Uptime

8.1 为什么 uptime 不够

一个 AI service 可以 99.9% 可用，但仍然不能上线：

• 它持续给出无证据答案。
• 它在高风险场景没有升级人工。
• 它成本超预算，单 case 不具备经济性。
• 它 p95 latency 满足 API SLA，但用户要等人工复核 24 小时。
• 它没有违反技术错误率，但违反了合规话术。

所以 AI SLO 要覆盖五类目标：

1. Availability：服务可用。
2. Latency：在业务工作流允许时间内返回。
3. Quality：输出满足需求和 eval 阈值。
4. Safety：风险行为被阻止或升级。
5. Cost：单位经济性在预算内。

SLA 是对外或跨团队承诺，通常更少、更稳定、更保守。SLO 是内部运营目标，可以更细、更快迭代。AI 系统建议先建立 SLO，再谨慎形成 SLA。

8.2 Risk-Tiered AI SLO Matrix

8.3 AI SLO 设计步骤

1. 定义 use case 和 workflow step。
2. 标记 risk tier。
3. 把需求转成 eval requirement id。
4. 为每个 requirement 设计线上可观测信号。
5. 为 latency 拆分预算：queue、retrieval、model、tool、judge、human review。
6. 为 cost 设定单位指标：successful answer、resolved case、accepted recommendation。
7. 定义 safety escape：哪些错误必须为 0。
8. 定义 error budget policy：什么时候限流、回滚、降级、暂停 scale。
9. 定义 review cadence：daily pilot review、weekly ops review、monthly cost review、quarterly AI review。

8.4 Error Budget 在 AI 场景中的含义

普通 error budget 关注可用性错误。AI error budget 要分桶：

• quality budget：允许多少低严重度质量失败。
• latency budget：允许多少请求超过 p95/p99。
• cost budget：允许多少预算偏差。
• safety budget：高风险逃逸通常没有预算，目标为 0。
• adoption budget：如果 adoption 低于阈值，说明功能没有产品化成功。

例子：

---

9. Cost Management：从 Token 账单到 Unit Economics

9.1 成本公式

AI cost 不等于模型账单。更完整的公式：

cost per request =
  input token cost
+ output token cost
+ reasoning token cost
+ embedding / retrieval / rerank cost
+ tool and downstream API cost
+ judge / eval cost
+ human review cost
+ trace and monitoring storage cost
+ cache storage / invalidation cost
+ peak capacity and fallback cost

业务决策更关心：

cost per successful answer =
  total AI service cost for accepted answers
/ number of answers that pass quality threshold and are accepted

cost per resolved case =
  total AI + operation cost for resolved cases
/ number of cases resolved without rework or escalation beyond threshold

AI ROI =
  measurable business benefit - incremental AI operating cost
/ incremental AI operating cost

9.2 Unit Economics

9.3 Budget Guardrail

预算 guardrail 要在运行时生效，而不是月底看账单。

建议机制：

• 每个 use case 有 monthly budget、daily burn alert、per-request soft limit、hard stop。
• 每个 risk tier 有可用模型集合和最大上下文策略。
• 高成本 route 必须记录 route_reason。
• 低风险高频请求优先 cache / small model / batch。
• 高风险请求允许更高成本，但必须有业务 owner 和风险 owner 批准。
• 对异常 token 增长设置自动拦截：输入 token 超出历史 p95 的 2 倍时触发压缩或人工提示。
• 每次 prompt、retrieval、model、judge 版本变更都要比较 cost delta。

9.4 Model Routing

Model routing 是成本、质量、延迟、风险的共同控制点。

示例策略：

Routing 记录必须回答：

• 为什么选这个模型？
• 是否因为风险、质量、延迟、成本或 fallback？
• 选路后质量和成本是否符合预期？
• 哪些请求被降级，是否影响业务结果？

9.5 Cache

Cache 是成本和延迟优化，也是风险控制对象。

可缓存：

• 公开或低风险 FAQ。
• 已版本化政策片段。
• 检索结果候选集。
• 高频 embedding。
• 低风险 judge 结果。

谨慎缓存：

• 包含客户个人信息的上下文。
• 高风险决策建议。
• 依赖实时费率、账户状态、案件状态的答案。
• 需要权限过滤的跨租户知识。

缓存策略必须记录：

• cache key。
• knowledge version。
• permission scope。
• expiry。
• invalidation trigger。
• bypass reason。
• hit/miss 对 latency 和 cost 的影响。

9.6 Batch

Batch 适合异步、低交互、可排队任务：

• 批量工单分类。
• 夜间 AML case summarization。
• 零售需求分析报告。
• 大规模知识库 eval。
• 月度 policy drift 检查。

不适合：

• 坐席实时对话建议。
• 需要即时风控拦截的支付动作。
• 用户等待中的交易争议处理。

Batch 指标：

• throughput。
• queue wait。
• batch size。
• cost per batch。
• failed item rate。
• retry rate。
• completion before business deadline。

9.7 Long-Context Cost

长上下文不是免费能力。FlashAttention 等 IO-aware 技术能缓解 attention 的内存读写瓶颈，但不能消除长上下文带来的 token、KV cache、延迟和质量问题。

PM/BA/Architect 要避免三种误区：

• 误区 1：模型支持 128K context，就应该把全部文档塞进去。 修正：先做 retrieval、chunking、context budgeting 和 evidence selection。

• 误区 2：长上下文能替代知识治理。 修正：版本、权限、freshness、source of truth 仍然需要管理。

• 误区 3：延迟只是工程问题。 修正：需求设计、证据范围、输出长度、复核策略都会影响 latency。

长上下文控制指标：

• input tokens by request。
• context utilization。
• evidence token ratio。
• irrelevant context rate。
• KV cache memory pressure。
• p95 prefill latency。
• cost per long-context request。
• quality delta compared with RAG route。

9.8 FinOps / RiskOps 关系

FinOps 关注云和 AI 成本可见、可归因、可优化。RiskOps 关注风险可见、可控制、可审计。AI service 需要两者共同工作。

---

10. 金融零售场景 Observability Blueprint

10.1 AML Copilot

用途：帮助 AML analyst 汇总案件、解释可疑模式、生成 SAR draft 或 investigation narrative。

运营重点：

• 每个 narrative 必须有 evidence map。
• analyst edit distance 是质量信号，不是“用户挑剔”。
• false positive reduction 要小心定义，不能鼓励漏报。

10.2 Customer Service RAG

用途：给客服坐席提供政策、流程、产品条款和回答草稿。

运营重点：

• 高 adoption 但高 edit distance 表示“可用但不可信”。
• 高频 FAQ 应该推动 cache 和知识库产品化。
• 质量 dashboard 要按产品线和政策版本切片。

10.3 Credit Policy Assistant

用途：帮助信贷运营、分行、风控团队查询政策、解释 reason code、准备合规一致的说明。

运营重点：

• Trace 中必须记录 jurisdiction、product、policy effective date。
• 用 judge 初筛，但高风险样本需要 expert review。
• 每次政策更新必须触发 regression eval。

10.4 Payment Dispute Assistant

用途：辅助坐席或后台运营处理支付争议、收集证据、生成下一步建议和客户沟通草稿。

运营重点：

• Tool call span 比 model span 更关键，因为争议流程依赖核心系统状态。
• Incident timeline 要覆盖“错误建议是否已执行”。
• 成本要包含下游系统 API 和人工审批。

10.5 Retail Demand Analyst

用途：帮助零售团队分析销售、库存、促销、天气、节假日和供应链信号，生成需求洞察。

运营重点：

• 这类场景不应只评估文本质量，必须评估数据和计算正确性。
• Business outcome 应追踪库存周转、缺货、毛利或 markdown。
• Tool span 要记录 SQL、数据版本和计算结果摘要。

---

11. PM / BA / Architect 输出物

11.1 Metric Tree

用途：把业务目标、AI 行为、系统指标和成本指标连成一棵树。

内容结构：

• North-star business outcome。
• 目标用户和 workflow step。
• AI 成功定义。
• Quality drivers。
• Safety controls。
• Latency drivers。
• Cost drivers。
• Adoption drivers。
• Leading / lagging indicators。
• 指标 owner 和 review cadence。

好指标树的标准：

• 能解释为什么这个 AI use case 值得做。
• 能定位问题发生在数据、模型、检索、工具、用户流程还是运营。
• 能让 CFO 看到单位经济性，让 Risk 看到控制，让 SRE 看到稳定性，让 PM 看到 adoption。

11.2 Dashboard Spec

用途：让团队知道要建哪些 dashboard、给谁看、如何行动。

必须包含：

• Dashboard name。
• Audience。
• Decision supported。
• Refresh cadence。
• Data sources。
• Filters。
• Tiles / charts。
• Alert rules。
• Drill-down trace link。
• Owner。
• Runbook link。

Dashboard 类型：

11.3 Trace Schema

用途：统一所有 AI trace/span 字段，避免各团队随意打日志。

必须包含：

• trace-level common fields。
• span-level common fields。
• model span fields。
• retrieval span fields。
• tool span fields。
• judge span fields。
• human review span fields。
• cost fields。
• outcome fields。
• privacy and retention rules。

11.4 SLO Doc

用途：定义 AI service 的运营目标、阈值、error budget 和 violation action。

必须包含：

• Use case and workflow scope。
• Risk tier。
• Business objective。
• Availability SLO。
• Latency SLO。
• Quality SLO。
• Safety SLO。
• Cost SLO。
• Adoption SLO。
• Measurement method。
• Exclusions。
• Alert threshold。
• Error budget policy。
• Review cadence。
• Owner。

11.5 Incident Playbook

用途：让团队在 AI 事故发生时知道如何检测、分级、止血、修复和复盘。

必须包含：

• Incident severity。
• Detection sources。
• Triage owner。
• Immediate containment。
• Customer / internal communication。
• Rollback / fallback。
• Data and trace collection。
• Root cause categories。
• Regression eval update。
• Postmortem template。
• Governance follow-up。

11.6 Cost Review Memo

用途：让 PM/Finance/Platform/Risk 定期评审 AI 成本是否匹配价值。

必须包含：

• 本周期总成本。
• cost by use case / team / model / route / risk tier。
• cost per successful answer。
• cost per resolved case。
• cache savings。
• long-context cost。
• judge and human review cost。
• budget variance。
• quality and safety impact。
• optimization actions。
• decision request。

---

12. 21 天 Lab：AI Service Operations Pack

目标：用 21 天为一个真实或模拟 AI use case 形成完整 operations pack。建议选择一个金融零售场景，例如 Customer Service RAG 或 AML Copilot。

最终 pack 目录建议：

AI Service Operations Pack
  01-use-case-brief.md
  02-workflow-and-risk-tier.md
  03-requirements-to-eval-matrix.md
  04-trace-schema.md
  05-latency-and-cost-model.xlsx
  06-slo-matrix.md
  07-dashboard-spec.md
  08-incident-playbook.md
  09-cost-review-memo.md
  10-executive-summary.md

---

13. 模板 1：AI Trace Schema

13.1 Trace-Level Fields

13.2 Span-Level Common Fields

13.3 Example Trace Summary

{
  "trace_id": "trc_customer_service_20260629_001",
  "request_id": "ticket_849201",
  "use_case_id": "customer_service_rag",
  "risk_tier": "medium",
  "user_role": "contact_center_agent",
  "workflow_step": "answer_draft",
  "route_policy_version": "route_v12",
  "eval_profile": "customer_facing_medium_risk",
  "outcome": "accepted_with_edit",
  "latency_ms": 6420,
  "cost_usd": 0.038,
  "quality": {
    "groundedness_score": 0.94,
    "citation_correct": true,
    "judge_pass": true,
    "human_edit_distance": 0.12
  },
  "business": {
    "case_resolved": true,
    "agent_accepted": true
  }
}

---

14. 模板 2：AI SLO Matrix

SLO doc 应附带：

• why this SLO matters。
• data source。
• sampling strategy。
• exclusions。
• dashboard link。
• runbook link。
• review cadence。
• last review decision。

---

15. 模板 3：Cost Unit Economics Sheet

15.1 Sheet Columns

15.2 Review Questions

• 成本增长来自请求量、token、route、judge、human review 还是 cache miss？
• cost per successful answer 是否下降，还是只是总成本下降？
• 便宜模型是否导致 reject / rework / escalation 上升？
• 高风险场景的成本是否经过 business owner 和 risk owner 接受？
• 哪些长上下文请求应该改成 RAG 或分段总结？
• cache savings 是否建立在正确权限和版本控制上？

---

16. 模板 4：Dashboard Spec

# Dashboard Spec: Customer Service RAG Quality and Cost

## Audience
Contact Center PM、QA Lead、AI Platform、Risk、Finance。

## Decisions Supported
- 是否可以扩大 pilot 流量。
- 哪些产品线需要知识库修复。
- 成本是否符合 unit economics。
- 是否触发 incident 或 SLO violation。

## Data Sources
- AI trace store。
- Cost ledger。
- QA review system。
- Ticketing system。
- Knowledge base version registry。

## Filters
- Date range。
- Product line。
- Region。
- Risk tier。
- Model route。
- Prompt version。
- Knowledge base version。
- User role。

## Tiles
1. p50/p95 TTFT and total latency。
2. Request volume by route。
3. Citation correctness trend。
4. Groundedness score by product line。
5. Unsupported claim rate。
6. Agent acceptance and edit distance。
7. High-risk escalation rate。
8. Cost per successful answer。
9. Cache hit rate and estimated savings。
10. Open incidents and SLO violations。

## Alerts
- Citation correctness below 95% for one business day。
- High-risk escalation below 99%。
- Cost per successful answer 20% above approved target for one week。
- Unsupported claim rate above 3% for low-risk and above 0 for high-risk regulated answers。

## Drill-Down
Every chart links to sampled traces with model, retrieval, tool, judge and human review spans.

## Owner and Cadence
Dashboard owner: AI Platform PM。
Review cadence: daily during pilot, weekly after release, monthly cost review。

---

17. 模板 5：Incident Postmortem

# AI Incident Postmortem: Incorrect Policy Citation in Customer Service RAG

## Incident Summary
On 2026-06-29, the customer service RAG assistant generated answers citing an outdated fee waiver policy for checking accounts in one region. The service remained technically available, but quality and compliance SLOs were violated.

## Severity
S1: Customer-facing regulated policy error with limited scope and no irreversible financial action executed.

## Detection
- QA sampling found citation mismatch.
- Quality dashboard showed citation correctness drop from 96.4% to 91.2%.
- Trace drill-down linked failures to knowledge base version `kb_fee_policy_v31`.

## Impact
- 184 answer drafts generated under affected policy version.
- 73 drafts accepted by agents.
- 16 customer conversations required follow-up clarification.
- No fee reversal action was automatically executed.

## Timeline
- 09:10: QA reviewer flags first mismatch.
- 09:25: Risk owner opens incident.
- 09:40: AI Platform disables affected KB route and falls back to previous approved policy page.
- 10:15: Contact center supervisors receive correction guidance.
- 12:30: Knowledge owner publishes fixed index version.
- 14:00: Regression eval passes affected policy cases.
- 15:00: Traffic restored to normal route.

## Root Cause
The policy source was updated, but the RAG index refresh completed before metadata effective-date validation. Retrieval returned a superseded document because the filter did not enforce active policy status.

## Contributing Factors
- Dashboard tracked KB version but not policy effective-date mismatch.
- Golden set had fee policy cases but did not include this region.
- Agent UI showed citation title but not effective date.

## Containment
- Disabled affected retrieval route.
- Required human review for fee waiver questions during incident window.
- Sent supervisor guidance for follow-up conversations.

## Corrective Actions
1. Add `policy_effective_status` to retrieval filter.
2. Add effective date to UI citation display.
3. Add regional fee waiver cases to golden set.
4. Add dashboard tile for stale or superseded policy retrieval.
5. Add SLO alert for citation correctness by policy region.

## Regression Evidence
- 40 new regional policy cases pass deterministic date validation.
- LLM judge groundedness pass rate returns to 97.1%.
- QA sample of 60 answers shows 0 outdated policy citations.

## Governance Follow-Up
- Knowledge owner added to weekly AI ops review.
- Release gate updated: policy KB refresh requires metadata validation before production route.

---

18. 面试表达

18.1 30 秒版本

我不会把 AI observability 理解成普通日志。生产 AI 服务必须能追踪一次请求里的 prompt、model、retrieval、tool、judge、human review、token、cost、latency、quality、safety 和 adoption。SLO 也不能只写 uptime，而要按 use case risk tier 同时定义质量、成本、延迟和安全阈值。这样 demo 才能变成可运营、可审计、可优化的服务。

18.2 2 分钟版本

我会从业务 workflow 开始设计 AI observability。以客服 RAG 为例，一次请求要有完整 trace：用户问题、风险分类、检索到哪些文档、使用哪个 prompt 和模型、是否调用工具、judge 如何评分、坐席是否采纳或修改、最终工单是否解决。指标分成几层：latency 看 TTFT 和 total latency；token 和 cache 看成本；retrieval 看 recall、freshness 和 citation；quality 看 groundedness、unsupported claim、judge pass 和 QA review；safety 看 high-risk escalation 和 policy block；adoption 看目标用户激活、采纳率、edit distance；business outcome 看 FCR、AHT、cost per resolved case 和 ROI。

SLO 要按风险分层。低风险 FAQ 可以强调低延迟和低成本；客服草稿要强调 citation correctness 和升级人工；AML、信贷、支付争议这类高风险场景要设定 S0 failure 为 0，禁止 AI 做最终决策，并保留 human review 和 audit trail。成本管理也不是月底看 token 账单，而是做 unit economics：cost per successful answer、cost per resolved case、judge 和 human review 成本、cache savings、long-context cost。最终交付物包括 metric tree、trace schema、dashboard spec、SLO doc、incident playbook 和 cost review memo。

18.3 CTO 深挖

Q: 你如何设计 AI trace schema？

A: 我会先定义 trace-level 公共字段：trace id、request id、use case、risk tier、tenant、user role、workflow step、route policy version、eval profile 和 outcome。然后按 span 拆 model、retrieval、tool、judge、human review。Model span 记录模型、prompt 版本、token、TTFT、total latency、route reason、cache、cost。Retrieval span 记录 KB、index、chunking、filter、doc ids、freshness、citation。Tool span 记录 tool risk level、policy decision、approval 和 side effect。Judge span 记录 requirement id、rubric、score、severity。这样可以从一次业务结果回溯到模型、知识、工具和评测版本。

Q: OpenTelemetry 在这里怎么用？

A: 我会用 OpenTelemetry 的 trace/span 思路和 GenAI semantic conventions 作为命名和属性锚点，但不会只照搬技术字段。我会在平台层扩展业务字段，例如 use case、risk tier、workflow step、cost center、eval requirement id、human review decision。标准化的好处是跨模型、跨应用、跨团队比较 latency、tokens、errors 和 cost；业务扩展的好处是能支持 release gate、risk audit 和 ROI。

Q: 如何定位 AI 服务变慢？

A: 先把 total latency 拆开：queue wait、retrieval、model prefill、decode、tool、judge、human review。TTFT 高可能是队列、冷启动或长 prompt prefill；total latency 高可能是输出过长、工具慢、judge 同步执行或人工复核瓶颈。再看 route distribution、input tokens、cache hit、top_k、rerank 和 provider error。不要直接换更快模型，因为可能真正瓶颈在检索或工具。

18.4 CFO 深挖

Q: 你如何证明 AI 成本值得？

A: 我不会只报 token 账单。我会报 unit economics：cost per successful answer、cost per resolved case、cost per accepted recommendation，并把模型、retrieval、tool、judge、human review、observability 都算进去。然后和业务收益比较，例如 AHT 降低、返工减少、误报减少、库存改善或损失减少。只有质量达标、安全可控、目标用户采用的请求，才算 successful answer。这样能避免用低成本但低质量的模型制造返工。

Q: 成本超预算怎么处理？

A: 先归因：是请求量增长、input token 膨胀、长上下文、cache miss、强模型 route 过多、judge 过重、工具/API 成本，还是人工复核过多。然后按风险分层优化：低风险高频请求用 cache、小模型、batch 和 prompt compression；中风险用 fast model + judge + selective retry；高风险保留强模型和人工审批，但要明确业务 owner 接受成本。任何成本优化都不能降低高风险 safety SLO。

18.5 SRE 深挖

Q: AI incident 和普通 incident 有什么不同？

A: 普通 incident 常见是服务不可用或错误率上升。AI incident 可能是 HTTP 200 但答案错误、证据过期、工具越权、judge 漂移、成本异常或用户误用。处理上除了 rollback，还要能禁用 prompt、model route、retriever index、tool action 或 judge version；要回收受影响输出、通知业务 owner、补充 golden set 和 regression eval。Postmortem 不只问系统为什么坏，还要问为什么 eval、dashboard、human review 或 gate 没提前发现。

Q: 哪些 alert 最有用？

A: 我会组合技术和业务 alert：p95 TTFT/total latency、tool error、provider fallback、cache miss spike、cost anomaly、unsupported claim、citation correctness drop、high-risk escalation drop、human override spike、S0 failure、adoption sudden drop。Alert 必须能 drill down 到 trace，否则只能制造噪音。

---

19. 作品集转化方式

这份手册可以转成三类作品集材料。

19.1 一页 Executive Memo

标题：From AI Demo to Operated Service

核心内容：

• 问题：AI demo 缺少 trace、质量、成本、SLO 和 incident loop。
• 方法：建立 AI observability stack、risk-tiered SLO、unit economics 和 dashboard。
• 场景：Customer Service RAG / AML Copilot / Payment Dispute Assistant。
• 产出：trace schema、dashboard spec、SLO matrix、cost review memo、incident playbook。
• 价值：降低生产风险、控制成本、提升 adoption、证明 ROI。

19.2 面试案例讲述

结构：

1. 背景：金融零售 AI 从 pilot 到 release 的常见断点。
2. 诊断：只看 uptime 和 token 账单不够。
3. 方案：trace + metrics taxonomy + SLO + cost ledger + incident loop。
4. 风险：高风险场景保留 human review 和 audit。
5. 结果：用 cost per resolved case、quality pass、safety incidents、adoption 和 business outcome 证明。

19.3 可画的架构图

图中必须包含：

• AI gateway。
• policy and risk tiering。
• model gateway。
• retrieval service。
• tool gateway。
• judge/eval service。
• human review queue。
• trace store。
• cost ledger。
• quality dashboard。
• incident timeline。
• business outcome store。

---

20. 自检清单

上线前或作品集提交前，用下面问题检查：

• 是否每个 use case 都有 risk tier？
• 是否每次请求都能追踪到 prompt、model、retrieval、tool、judge、human review？
• 是否记录 token、latency、cost、cache、route reason？
• 是否能回答“这次答案引用了哪些证据”？
• 是否能回答“这次成本为什么这么高”？
• 是否能回答“用户有没有采纳，业务有没有改善”？
• 是否有 quality dashboard，而不只是 eval report？
• 是否有 cost ledger，而不只是供应商账单？
• 是否有 SLO matrix，而不只是 uptime SLA？
• 是否有 safety escape 目标，例如高风险最终决策 by AI = 0？
• 是否有 incident playbook 和 postmortem 模板？
• 是否把 incident 结果回写到 eval golden set？
• 是否能向 CTO 解释 trace schema？
• 是否能向 CFO 解释 unit economics？
• 是否能向 SRE 解释 alert、rollback 和 error budget？

---

21. Final Principle

AI demo 证明“模型可能有用”。AI observability、cost management 和 risk-tiered SLO 证明“这个能力可以被运营”。

对金融零售 AI 来说，真正的成熟不是让模型回答更多问题，而是让每一次回答都能被追踪、计量、评估、审计、复盘和优化。