AI Runtime Evidence：可观测证据架构
AI observability 不等于把聊天记录和错误日志存起来。生产级 AI 需要 runtime evidence architecture：既要看见一次 AI run 的技术执行链，也要证明它使用了哪些来源、遵循了哪些策略、谁批准了哪些动作、输出是否被采纳、是否产生后续风险信号。
AI Runtime Evidence / Observability Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_RUNTIME_EVIDENCE_OBSERVABILITY_ARCHITECTURE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| OpenTelemetry | https://opentelemetry.io/docs/ | 参考 trace、span、metrics、logs 的可观测性模型（持续更新的活文档，访问日期: 2026-07-01） |
| OpenLineage | https://openlineage.io/docs/ | 参考 lineage event、job、dataset、run 的数据血缘思维（访问日期: 2026-07-01） |
| W3C PROV | https://www.w3.org/TR/prov-overview/ | 参考 entity、activity、agent 的 provenance 图谱（访问日期: 2026-07-01） |
| CloudEvents | https://cloudevents.io/ | 参考事件 envelope、source、type、id、time、subject（访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 measure/manage 变成运行时证据和风险反馈（访问日期: 2026-07-01） |
| NIST CSF | https://www.nist.gov/cyberframework | 参考 identify/protect/detect/respond/recover 的运营控制思维（访问日期: 2026-07-01） |
核心导读
AI observability 不等于把聊天记录和错误日志存起来。生产级 AI 需要 runtime evidence architecture：既要看见一次 AI run 的技术执行链，也要证明它使用了哪些来源、遵循了哪些策略、谁批准了哪些动作、输出是否被采纳、是否产生后续风险信号。
对金融零售 AI 来说，runtime evidence 是三件事的交汇点：产品学习回路、运营监控系统、审计和事故复盘的证据平面。没有证据平面，AI 系统上线后只能凭用户投诉、人工抽查和零散日志猜测质量。
1. 问题定义：AI 运行时证据不是普通 logging
普通应用日志通常回答：
request time, status code, error
AI 系统上线后，真正需要回答的是：
| 问题 | 证据需求 |
|---|---|
| 用户或系统提出了什么任务 | request、purpose、risk tier |
| 系统给模型什么指令 | system prompt version、policy profile |
| 检索到了哪些来源 | source ids、index version、retrieval scores |
| 哪些 context 被放进 prompt | context window、memory keys、redaction state |
| 模型如何生成结果 | model id、parameters、output hash |
| 是否调用工具 | tool name、args hash、policy decision、result summary |
| 谁批准或修改 | human approval、reviewer decision、edit distance |
| 输出是否有效 | schema validation、citation support、expert score |
| 是否造成后续影响 | complaint、incident、loss、rework、override |
如果没有这些证据，事故复盘会停留在“AI 好像答错了，但不知道为什么”。这不是技术可观测性的不足，而是产品和治理不可运营。
2. 架构模型：把 trace、event、provenance 和 evidence 分层
2.1 Reference architecture
AI app / agent
-> instrumentation SDK
-> trace / span / events
-> policy and eval annotations
-> evidence lake
-> dashboards
-> audit queries
-> incident workbench
-> validation and improvement loop
Runtime evidence architecture 不是单一日志管道，而是多个平面的组合：
| Plane | 作用 |
|---|---|
| Trace plane | 串起一次 AI run 的步骤、耗时、错误和父子关系 |
| Event plane | 记录关键业务、风险、审批、工具调用和事故事件 |
| Provenance plane | 解释 output 的来源、转换链路和责任主体 |
| Metrics plane | 监控 SLO、KRI、质量、安全、成本和延迟趋势 |
| Evidence plane | 支撑审计、监管、模型验证、事故复盘和持续改进 |
| Retention plane | 控制隐私、访问、保留期限、删除和脱敏策略 |
2.2 Evidence object taxonomy
不是所有运行时数据都叫日志。Evidence object 应按复盘目的建模。
| Evidence object | 示例字段 |
|---|---|
| Request | user_id、role、tenant、channel、purpose |
| Prompt/config | system prompt version、policy profile、model、temperature |
| Context | memory keys、retrieved chunks、tool observations |
| Retrieval | query、index version、top_k、source ids、scores |
| Tool call | tool name、args hash、policy decision、result summary |
| Human approval | approver、decision、rationale、timestamp |
| Output | response hash、citation ids、schema validation |
| Feedback | thumbs、edit distance、reviewer score、override |
| Cost/latency | token count、model cost、wall time、queue delay |
| Safety signal | refusal、escalation、red-team hit、policy violation |
| Incident link | incident id、severity、containment action |
高风险字段不一定保存原文。PII、敏感金融信息、客户沟通内容可以按 classification 做 hash、mask、tokenize、加密或按 retention policy 分层保存。
2.3 Span model
一次 agent run 可以用 OpenTelemetry 风格拆成 span tree：
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
关键 attributes 应能支撑诊断、审计和产品优化：
| Attribute | 用途 |
|---|---|
| ai.use_case | 区分业务场景 |
| ai.risk_tier | 关联控制强度 |
| ai.agent_id | 识别 Agent 身份和版本 |
| ai.model_id | 跟踪模型与供应商行为 |
| ai.prompt_version | 支撑 prompt 变更复盘 |
| ai.index_version | 支撑 RAG 结果复盘 |
| ai.tool_scope | 识别工具授权边界 |
| ai.policy_decision | 记录 allow/deny/escalate |
| ai.human_decision | 记录 approve/reject/edit |
| ai.output_schema_valid | 证明结构化输出质量 |
| ai.citation_support | 证明 grounding |
| ai.cost_usd | 追踪单位经济性 |
| ai.latency_ms | 追踪体验和运营瓶颈 |
3. 关键机制与生命周期
3.1 Evidence lifecycle
AI 证据不是事后补日志，而要在运行链路中内生采集。
| 阶段 | 需要捕获的证据 |
|---|---|
| Intake | request、purpose、risk tier、actor claims |
| Pre-check | policy decision、data boundary、tool entitlement |
| Context build | retrieved sources、index version、context selection |
| Generation | model config、prompt version、output hash |
| Tool execution | tool call、scope、args hash、result summary |
| Human control | approval、rejection、edit、rationale |
| Delivery | final output、customer/system impact |
| Feedback | user adoption、override、correction、complaint |
| Incident | severity、containment、affected runs、root cause |
| Improvement | eval case、prompt/model/policy change、revalidation result |
3.2 Event contract
CloudEvents 风格的事件 envelope 可以让 AI 平台、业务系统、审计系统和事故平台共享稳定事件语义。
{
"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"
}
}
事件先稳定 envelope，再扩展 data schema。这样做可以避免每个 AI use case 各自发明日志格式，导致组合级审计和 incident query 无法复用。
3.3 Provenance and replay
AI output 的可解释性不能只依赖模型回答中的 citation。Provenance 要能复盘：
| Provenance 问题 | 证据 |
|---|---|
| 输出来自哪些来源 | source ids、document version、retrieval score |
| 来源如何进入上下文 | chunk id、ranking、filter、redaction |
| 谁或什么活动生成了输出 | agent id、model id、prompt version |
| 哪些工具改变了状态 | tool call event、args hash、result summary |
| 谁最终批准 | human decision、approval id、timestamp |
| 是否可重放 | config version、index version、policy version |
Replay 不一定重跑原模型生成完全相同输出，而是要重建足够的上下文，解释当时系统为什么做出该输出或动作。
4. 证据与控制
4.1 Metrics、SLO 和 KRI
高级 AI 产品指标不能只看 DAU、message count 或 token usage。它们能说明使用量，却不能证明系统安全、有效或可审计。
| Category | Metric |
|---|---|
| Quality | task success、expert score、correction rate |
| Grounding | citation support、unsupported claim rate |
| Safety | refusal quality、policy violation、harmful completion |
| Human control | approval rate、override rate、escalation miss |
| Reliability | error rate、retry、timeout、fallback usage |
| Cost | cost per case、token per workflow、cache hit |
| Latency | p50/p95/p99 end-to-end and per span |
| Risk | incident rate、complaint linkage、drift alert |
| Adoption | active users、accepted suggestions、review load |
| Audit | evidence completeness、missing trace rate |
4.2 Controls
| 风险 | 后果 | 控制 |
|---|---|---|
| Missing trace | 出事无法复盘 | instrumentation gate、trace completeness SLO |
| PII in logs | 隐私和合规风险 | masking、classification、field-level retention |
| Broken lineage | 不知道 output 来源 | source ids、index version、document registry |
| Unverifiable tool action | 无法证明谁做了什么 | tool event contract、actor chain claims |
| Dashboard theater | 图很多但不支持决策 | audit query catalog、decision-linked metrics |
| Non-replayable incident | 无法重建上下文 | config/version capture、evidence snapshot |
| Over-retention | 保存过多敏感数据 | retention matrix、purpose-based access |
| Under-retention | 审计或投诉时证据缺失 | risk-tiered retention policy |
4.3 Evidence access model
证据越完整，越需要访问控制。AI evidence lake 应区分：
| 访问主体 | 可见内容 |
|---|---|
| Product analytics | 聚合质量、采用、延迟、成本指标 |
| Operations | case-level run summary、approval、failure signals |
| Model validation | eval cases、prompt/model/index version、quality scores |
| Audit/compliance | evidence completeness、policy decision、approval chain |
| Incident response | affected runs、tool actions、context snapshot、containment |
| Engineering | traces、errors、latency、dependency failures |
同一份 evidence 不应对所有团队暴露同样粒度。运行证据需要“可复盘”和“最小可见”同时成立。
5. 金融零售与 AI 产品场景
5.1 AML copilot trace
AML copilot 的证据重点包括：被总结的交易和 alert、使用的 typology/policy source、生成 narrative 的 prompt/config、analyst 修改内容、final case disposition、后续 QA finding。
如果 narrative 后续被 QA 或监管质疑，系统需要证明某段结论来自哪些交易、哪些红旗规则、哪些政策来源，以及 analyst 做过哪些确认或修改。
5.2 Payment dispute agent trace
Payment dispute 场景需要捕获交易数据来源、dispute reason code、Agent 推荐的下一步、人类是否批准客户通知、退款/拒绝动作是否由人执行、客户投诉是否回流到 monitoring。
这里的重点是把 customer-facing outcome 与 AI run 关联起来。否则 dispute 结果出错时，只能在业务系统看到最终状态，看不到 AI 推荐、审批和工具动作链。
5.3 Lending policy RAG trace
贷款政策 RAG 需要保存 policy repository version、retrieved policy sections、citation support、low-confidence escalation、reviewer override、fair lending/adverse action boundary。
贷款场景对 provenance 的要求高于普通知识问答。系统不只要答得像政策，还要证明引用的是有效政策版本，并且没有把解释性输出越界成自动信贷判断。
5.4 Customer service quality loop
客服 AI 的 evidence 不能只停在对话内容。更关键的是：AI 草稿被客服采用还是大量修改、哪些类型问题触发 escalation、哪些输出后来导致投诉、哪些政策来源被反复引用但质量差。
这类证据可以把 AI 产品从一次性上线变成持续学习系统：问题分类、prompt、RAG 来源、审批 UI 和人工培训都能基于 evidence 迭代。
6. 反模式
| 反模式 | 问题 |
|---|---|
| 只保存聊天全文 | 缺少 prompt、context、retrieval、tool、approval 和 policy evidence |
| 只做技术日志 | 无法回答客户影响、风险结果和业务责任链 |
| 指标只看使用量 | DAU 和 token usage 不能证明安全性、有效性或合规性 |
| 把 PII 原文全量写入日志 | 提升复盘能力的同时制造隐私和合规风险 |
| 每个 use case 自定义日志格式 | 组合级审计、跨系统事故查询和治理指标无法统一 |
| Dashboard 很丰富但没有查询场景 | 监控变成展示，无法支撑 incident、audit 和 validation |
| 没有版本化上下文 | 模型、prompt、index 或政策变化后无法解释历史输出 |
| Evidence lake 没有访问分层 | 证据集中后成为新的敏感数据风险点 |
7. 最终心智模型
AI runtime evidence 是 AI 产品的 black box、audit trail 和 learning loop。Trace 让你看见过程，event 让你捕获关键事实，provenance 让你解释来源，metrics 让你运营趋势，retention 和 access control 让证据可用但不失控。
一个成熟 AI 系统上线后应能持续回答：
What happened?
Why did it happen?
Which sources and policies were used?
Who approved or changed it?
What customer or system state changed?
Can we replay enough context to explain it?
What should be improved or contained?
SOTA 检查 (2026-07-01)
- OTel GenAI 语义约定已成为本主题事实标准但仍为 Development/experimental 状态（截至 2026-03 状态复查）：覆盖范围已从 LLM client span 扩展到 agent span、MCP 工具调用、prompt/completion 内容事件与质量评估等六层（OpenTelemetry 官方博客 2026 与 Greptime 解读 2026-05）。本篇 §2.3 的
ai.*attribute 命名是自拟示意，落地时应对齐官方gen_ai.*命名（如gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.response.finish_reasons），细节见库内笔记docs/aipa/day22-otel-genai-semconv.md（AIPA D22, 2026-06）。 - 工具面 2026 年主流格局：开源自托管首选 Langfuse（Docker/K8s 自部署、tracing+evals+prompt 管理一体），LangSmith 绑定 LangChain/LangGraph 生态，Helicone 走代理接入+成本追踪，Arize/Phoenix 面向企业级；OpenLLMetry（Traceloop）提供 vendor-neutral 的 OTel instrumentation，可对接任意 OTel 后端（SigNoz/Datadog/New Relic）。本仓库已实践 Langfuse 自托管路线：
docs/aipa/day25-langfuse-self-host.md（2026-06）。 - 本篇主线仍成立：evidence plane 分层（trace/event/provenance/metrics/evidence/retention）、evidence object taxonomy、按 risk tier 的 retention/访问分层，属于不随工具版本过时的框架性结论；2026 年生态变化主要发生在「用什么 attribute 命名、用哪家采集器」这一层，而不是「要不要证据平面」这一层。CloudEvents envelope 与 W3C PROV 心智模型同样稳定。
- 审计轨迹的 OTel 落地已在本库验证：AML Copilot 的 evidence pipeline 与 audit trail 实现见
docs/aipa/day64-evidence-pipeline-design.md、docs/aipa/day74-audit-trail-otel.md（AIPA P3, 2026-06），运营指标/SLO/成本侧的操作手册见docs/AI_OBSERVABILITY_COST_SLO_PLAYBOOK.md。 - 合规时间线更新：EU AI Act Annex III 高风险系统义务（含 logging/record-keeping，即本篇 evidence plane 的监管对应物）已经由 Digital Omnibus（2026-05-07）推迟至 2027-12-02 适用；不要再引用旧的 2026-08 时间线。这延长了落地窗口，但金融机构的模型风险管理与审计要求（NIST AI RMF measure/manage）不受该推迟影响。