AI Traceability Graph / Requirements-Eval-Control-Evidence 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_TRACEABILITY_REQUIREMENTS_EVAL_CONTROL_GRAPH_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

核心问题: AI 需求如果只停留在 user story 或 PRD 段落, 很难证明系统上线后真的满足业务目标、风险控制、评测门槛和审计要求。高级 AI 需求工程要把 business outcome、requirement、eval、control、ADR、implementation、telemetry 和 evidence 连接成 traceability graph。

---

Source Anchors

核心导读

AI Traceability Graph 是把“为什么做、要满足什么、如何评测、如何控制、如何实现、线上发生了什么、证据在哪里”连接成一张可查询的关系图。

传统 traceability matrix 往往只追踪 requirement 到 test。AI 系统需要更深的链路: business outcome 要连接 requirement; requirement 要连接 eval、metric、threshold、control、architecture decision、component/config; runtime trace 和 evidence 要能回连到 release decision、incident 和 remediation。

这套能力的价值不在于文档更完整, 而在于支持三类高价值判断: 上线前发现覆盖缺口, 上线后定位漂移和事故影响, 审计时证明每个高风险需求如何被测试、控制和复核。

问题定义

普通 user story 可能写成:

As a customer service agent, I want AI to answer customer policy questions, so that I can respond faster.

对传统功能而言这可以作为开头, 但对 AI 系统远远不够:

成熟的 AI 需求表达应形成链路:

Business outcome
  -> requirement
  -> acceptance criterion
  -> eval case / metric / threshold
  -> control
  -> architecture decision
  -> implementation/config
  -> telemetry
  -> evidence
  -> release decision

如果需求无法追踪到 eval 和 control, 它只是愿望; 如果控制无法追踪到 runtime evidence, 它只是宣称。

架构模型/核心原理

Graph nodes

AI traceability graph 可以用节点和边表达。节点类型包括:

Graph edges

Example graph

场景: Customer-facing fee policy assistant。

Graph 不一定一开始就用图数据库。表格、YAML、spreadsheet、markdown 矩阵都可以作为早期实现。关键是关系明确, 能查询覆盖、影响和证据。

关键机制

Requirements-to-eval

AI requirement 必须写到可评测:

高级要求:

• Eval case 覆盖 normal、edge、adversarial、regulatory、segment-specific cases。
• Eval result 映射回 requirement、risk、control。
• Eval failure 可追踪到 component、config、source、prompt 或 tool。
• Release decision 必须引用 eval evidence。

Requirements-to-control

AI requirement 还必须写到控制:

成熟控制要说明发生在哪里、是预防/检测/纠正哪一类、是否自动化、由谁负责、如何测试有效性、产生什么证据。

Requirements-to-architecture

Traceability graph 能暴露架构决策的必要性。

如果架构元素无法回连到需求或风险, 它可能是过度设计; 如果需求无法落到架构元素, 它可能无法交付。

Impact queries

Traceability graph 的价值体现在查询能力:

这些查询把 traceability 从文档维护变成产品和架构决策工具。

证据与控制

Evidence object

Evidence 不应是散落附件, 而应是结构化对象:

这让 evidence 成为可查询、可复用、可审计的治理资产, 而不是项目结束时临时整理的材料。

Release decision memo

Release memo 是 traceability graph 的人类可读摘要:

Release decision 不应只是“评测通过”。它应明确哪些需求被覆盖、哪些风险仍残留、哪些例外被接受、哪些运行信号会触发 rollback 或 review。

Runtime linkage

线上 trace 应带足够标签, 才能回连到需求和控制:

trace_id
use_case_id
requirement_id
control_id
prompt_version
model_route
retriever_version
source_version
tool_contract_version
policy_decision
approval_id
eval_sample_flag
incident_id

没有 runtime linkage, traceability 会停在上线前; 有了 linkage, incident、drift、quality sampling、cost review 都能回到同一张图。

AI产品/金融零售场景

AML investigation copilot

目标: 帮助 AML analyst 汇总客户、交易、实体关系和监管规则证据, 生成 investigation brief 草稿。AI 不做最终 SAR 决策。

Traceability matrix:

关键链路示例:

BO-AML-001 Reduce investigation prep time
  -> REQ-AML-003 Generate evidence-grounded brief
  -> EVAL-AML-007 Evidence coverage eval
  -> CTRL-AML-004 Approved source and graph allowlist
  -> ADR-AML-002 Use graph retrieval + RAG
  -> COMP-AML-005 Investigation retrieval service
  -> TRACE tag req=REQ-AML-003 ctrl=CTRL-AML-004
  -> EVD-AML-018 Eval report + trace sample
  -> REL-AML-002 Limited pilot release

这个场景中, traceability graph 不只是合规资产, 也是产品改进工具: 如果 analyst override 上升, 可以查是 source coverage 不足、retrieval 配置漂移、prompt 版本变化, 还是某类交易模式缺少 eval case。

反模式

最终心智模型

AI traceability 的核心不是“把文档连起来”, 而是把不确定系统变成可证明、可复盘、可演进的系统:

Outcome asks why.
Requirement defines what.
Eval measures behavior.
Control constrains risk.
Architecture implements tradeoff.
Telemetry observes reality.
Evidence supports decision.
Incident drives remediation.

成熟 traceability graph 应能持续回答七个问题:

当这张图存在时, AI 产品、架构、风险、运营和审计不再各自维护一套叙事, 而是在同一条证据链上做 release、scale、rollback、exception 和 remediation 决策。

---

SOTA 检查 (2026-07-01)

• Runtime linkage 已有事实标准可对齐：OpenTelemetry GenAI 语义约定在 2025 年底稳定了 client spans/metrics，主流 agent 框架 2026 Q1 已出货 emitter；截至 2026-03 大部分 GenAI semconv 仍标记 experimental，但范围已扩展到 agent 编排、MCP 工具调用和 quality-evaluation span hook（OpenTelemetry 官方博客 2026；Greptime 解读 2026-05）。本篇「Runtime linkage」一节的自定义 trace tag（requirement_id/control_id/prompt_version 等）应作为 GenAI semconv 之上的业务扩展属性实现，而非平行体系——Datadog/Google Cloud/AWS/Azure 均已原生消费该约定（2025 年底起）。
• NIST AI RMF 主线仍现役且在加密度：GenAI Profile（NIST AI 600-1，2024-07 发布）于 2026-04-08 更新，提供 200+ 条 GenAI 专属 action，可直接作为本篇 requirement→control 映射表的控制词表；NIST 2026-04-07 发布关键基础设施 AI RMF Profile concept note，CAISI 于 2026-02 启动 AI Agent Standards Initiative（Agent Interoperability Profile 计划 2026 Q4）。本篇引用 AI RMF 作为治理锚点的结论仍成立。
• 审计侧双框架格局（2026）：ISO/IEC 42001 认证与 NIST AI RMF 并行为主流组合，NIST AIRC 已有 72 行 crosswalk 将 AI RMF subcategory 逐条映射 ISO 42001；ISO 42001 审计的核心交付 Statement of Applicability（控制清单+纳入/排除理由+管理层签核）与本篇 evidence binder / release memo 结构同构——本篇的 graph 即是把 SoA 从静态文档升级为可查询资产。
• 监管时间线已变：EU AI Act Annex III 高风险义务经 Digital Omnibus 推迟至 2027-12-02（Omnibus 2026-05-07 确认），traceability/logging 类合规硬截止顺延；但 2026 年主流实践仍是提前建 evidence graph 而非等截止日期。引用旧的「2026-08 生效」时间线属过时信息。
• 研究前沿印证 graph 模型：LLM agent 执行溯源已成独立研究方向——综述 "From Agent Traces to Trust: A Survey of Evidence Tracing and Execution Provenance in LLM Agents"（arXiv 2606.04990，2026-06）指出现有标准（含 W3C PROV、OTel）尚未完整覆盖 retrieval/tool use/memory/multi-agent 通信的 provenance，需要把执行事件与语义证据关系连接起来——这正是本篇 graph edges（emits/evidenced_by/violated_by）的方向。
• 不随版本过时的框架性结论：requirement→eval→control→evidence 十段链路、impact query 清单、evidence object 元数据结构、release memo 十节模板均与具体模型/框架版本无关；随版本演化的只有两类内容——telemetry 字段命名（应跟随 OTel GenAI semconv 演进）和监管合规截止日期（跟随 EU AI Act/州法变动，如 Colorado SB 24-205 已于 2026-05-14 被 SB 26-189 取代）。