AI Runtime Evidence / Observability Architecture 解读

面向对象: AI Product Architect / Platform PM / EvalOps Lead / SRE / Senior BA / Audit Evidence Owner。 核心问题: AI 系统上线后, 不能只靠聊天记录和用户投诉判断质量。生产级 AI 需要 runtime evidence architecture, 覆盖 prompt、context、retrieval、tool call、policy decision、human approval、output、feedback、cost、latency 和 incident。 学习目标: 用 OpenTelemetry、OpenLineage、W3C PROV、CloudEvents 和 AI RMF 思维, 设计可观测、可审计、可复盘、可持续改进的 AI evidence plane。

---

Source Anchors

一句话:

Runtime evidence is the AI product's black box, audit trail and learning loop.

---

1. 为什么 AI Observability 不等于 Logging

普通 logging 常回答:

request time, status code, error

AI runtime evidence 要回答:

• 用户问了什么。
• 系统给了什么指令。
• 检索到了哪些来源。
• 哪些 context 被放进 prompt。
• 模型和参数是什么。
• 调用了哪些工具。
• 哪个 policy gate 允许或拒绝。
• 人类是否审批。
• 输出是否被用户采纳。
• 后续是否产生投诉、错误、损失或返工。

如果没有这些证据, 事故复盘会停留在:

AI 好像答错了, 但我们不知道为什么。

---

2. Evidence Object Taxonomy

不是所有内容都要原文保存。高风险字段可以 hash、mask、tokenize 或按 retention policy 保存。

---

3. Reference Architecture

AI app / agent
  -> instrumentation SDK
  -> trace/span/events
  -> policy/eval annotations
  -> evidence lake
  -> dashboards + audit queries + incident workbench

核心平面:

---

4. AI Span Model

一次 agent run 可以拆成:

root span: ai.workflow.run
  child span: ai.policy.precheck
  child span: ai.retrieval.query
  child span: ai.model.generate
  child span: ai.tool.call
  child span: ai.human.approval
  child span: ai.policy.postcheck
  child span: ai.output.deliver

Span attributes:

---

5. 金融零售案例

5.1 AML copilot trace

需要证据:

• 被总结的交易和 alert。
• 使用的 typology / policy source。
• 生成 narrative 的 prompt/config。
• analyst 修改内容。
• final case disposition。
• 后续 QA finding。

5.2 Payment dispute agent trace

需要证据:

• 交易数据来源。
• dispute reason code。
• agent 推荐的下一步。
• 人类是否批准客户通知。
• 退款/拒绝动作是否由人执行。
• 客户投诉是否回流到 monitoring。

5.3 Lending policy RAG trace

需要证据:

• policy repository version。
• retrieved policy sections。
• citation support。
• low-confidence escalation。
• reviewer override。
• fair lending / adverse action boundary。

---

6. Metrics / SLO / KRI

高级产品指标要避免只看:

DAU, message count, token usage

这些不能证明 AI 系统安全、有效或可审计。

---

7. Failure Modes

---

8. Evidence Event Contract

{
  "id": "event_id",
  "source": "ai.customer_service_agent",
  "type": "ai.tool.call.completed",
  "time": "timestamp",
  "subject": "case_id",
  "data": {
    "run_id": "run_id",
    "agent_id": "agent_id",
    "human_actor": "user_id",
    "risk_tier": "high",
    "tool": "crm.case.note.create",
    "policy_decision": "allow",
    "approval_id": "approval_id",
    "evidence_hash": "hash"
  }
}

CloudEvents 思维的好处是: 事件先有稳定 envelope, 再扩展 data schema。

---

9. 面试表达

30 秒版本:

我会把 AI observability 设计成 runtime evidence architecture, 不只是日志。每次 AI run 都要有 trace, 记录 prompt/config、retrieval、tool call、policy decision、human approval、output、feedback、cost、latency 和 incident link。这样上线后可以做 SLO/KRI 监控、审计查询、事故复盘和持续改进。

2 分钟版本:

对金融零售 AI, 我不会只看聊天记录或模型分数。我要能回答一次输出从哪里来、基于哪些 source、用了哪个 prompt 和模型、调用了什么工具、谁批准了动作、是否触发 policy gate、最后是否产生客户影响。 架构上我会参考 OpenTelemetry 的 trace/span, 用 CloudEvents 做关键事件 envelope, 用 W3C PROV / OpenLineage 思维组织来源和转换链路。证据进入 evidence lake, 但要有隐私分级、masking、retention 和 access control。 运营上 dashboard 要覆盖 quality、grounding、safety、human control、latency、cost、incident 和 evidence completeness。这样 AI 产品才能被治理、被审计、被持续优化。

---

10. Portfolio Exercise

为 lending policy assistant 设计:

1. AI span tree。
2. evidence event contract。
3. dashboard spec。
4. audit query catalog。
5. retention matrix。
6. incident replay checklist。

最终输出:

• 一张 runtime evidence architecture 图。
• 一张 SLO/KRI dashboard 草图。
• 一个事故复盘查询例子。