AI Architecture Decision Records / Decision Governance 解读

面向对象: Enterprise Architect / AI Architect / AI PM / AI BA / Governance Lead。 核心问题: AI 项目的关键决策很多: RAG 还是微调、单模型还是路由、是否存 memory、是否允许 agent 执行动作、eval 门槛怎么定、vendor 如何退出。如果这些决策只留在会议和聊天里，后续团队无法理解、审计或反转。 学习目标: 理解 Michael Nygard 的 ADR 思路、Architecture Decision Records、architecture knowledge management、ISO/IEC/IEEE 42010 的 architecture description 思想，并扩展成 AI-specific ADR 治理。

---

Source Anchors

一句话:

AI ADR 是把“为什么这样设计 AI 系统、什么条件下要反转、用什么证据证明可接受”写成可版本化、可审计、可复盘的决策记录。

---

1. 为什么 AI 更需要 ADR

AI 系统的决策比普通软件更容易被遗忘:

AI ADR 要回答:

• 决策背景是什么？
• 约束和替代方案是什么？
• 为什么当前选择可接受？
• 会带来哪些风险和成本？
• 什么指标或事件会触发复盘？
• 哪些证据支持这条决策？

---

2. AI ADR Taxonomy

---

3. AI ADR Template

# ADR-XXX: [Decision]

Status:
  Proposed / Accepted / Superseded / Deprecated

Context:
  Business goal:
  AI capability:
  Risk tier:
  Stakeholders and concerns:
  Constraints:

Decision:
  We will ...

Alternatives considered:
  Option A:
  Option B:
  Option C:

Consequences:
  Positive:
  Negative:
  Neutral:

Evidence:
  Eval report:
  Risk assessment:
  Data/model/prompt versions:
  Cost/latency:
  Security/privacy review:

Reversal triggers:
  Metric threshold:
  Incident:
  Cost:
  Regulatory / policy change:
  Vendor change:

Review cadence:
  Owner:
  Date:

AI ADR 和普通 ADR 的差异:

• 必须绑定 evidence。
• 必须写 reversal trigger。
• 必须写 risk tier。
• 必须连接版本化 artifact。
• 必须考虑生产监控和人类监督。

---

4. 决策治理流程

use case intake
  -> identify architecture-significant decisions
  -> draft ADR
  -> architecture / risk / product review
  -> accepted ADR linked to release bundle
  -> implementation and gate checks
  -> production monitoring
  -> ADR review or supersede

4.1 谁写 ADR

4.2 哪些决策必须写 ADR

满足任一条件就写:

• 影响客户权益、资金、合规或投诉。
• 影响核心架构边界或平台复用。
• 引入第三方模型或供应商依赖。
• 改变数据使用、保留或权限。
• 允许 agent 调用有副作用工具。
• 改变 release gate、eval threshold 或 HITL。
• 有明显成本、延迟、韧性或安全权衡。

---

5. 金融零售 ADR 示例

ADR A: Customer Service RAG 不使用 Fine-Tune

Decision:

We will use RAG with source authority and citation support instead of fine-tuning for policy Q&A.

Reason:

• 政策更新频繁。
• 需要引用和版本。
• 客户可见答案要可追溯。

Reversal trigger:

• 检索召回达不到门槛且问题类型稳定。
• 成本/延迟无法满足 SLO。
• 权威知识库结构足够稳定可训练 specialist model。

ADR B: Fraud Agent 不允许自动冻结账户

Decision:

Agent may recommend account hold but cannot execute freeze without human approval.

Reason:

• 高客户影响。
• false positive 成本高。
• 申诉和补救要求高。

Evidence:

• 模型校准报告。
• 历史 false positive 分析。
• 人工队列容量。
• 客户影响评估。

ADR C: LLM Judge 不能单独作为 Release Gate

Decision:

LLM judge may be used as screening signal, but final release gate requires golden set and human calibration.

Reason:

• judge drift。
• rubric ambiguity。
• 高风险场景需要独立验证。

---

6. ADR 与网站/作品集

AI ADR 是作品集里很强的证据，因为它展示:

• 你能识别关键决策。
• 你能比较替代方案。
• 你能写清约束和后果。
• 你能把产品、架构、风险和证据连接起来。
• 你知道何时反转，而不是固执守旧。

每个 flagship case 至少准备 5 条 ADR:

1. Model strategy。
2. Knowledge / RAG strategy。
3. Human oversight。
4. Eval gate。
5. Vendor / platform boundary。

---

7. 常见失败模式

---

8. 面试表达

30 秒版本

AI ADR 用来记录关键 AI 架构决策，例如 RAG vs fine-tune、模型路由、HITL、eval gate、供应商和数据保留。相比普通 ADR，我会要求它绑定 risk tier、evidence、artifact versions、reversal triggers 和 monitoring。这样决策可追溯、可审计、可复盘。

2 分钟版本

以客户服务 RAG 为例，我会写一条 ADR 说明为什么选择 RAG 而不是 fine-tune: 政策更新频繁，需要引用、权限和版本追踪；替代方案包括 long context、fine-tune 和人工知识库检索；后果是要投入知识治理和 retrieval eval；反转条件是检索长期达不到召回门槛或成本延迟不可接受；证据链接到 RAG eval、source authority、risk assessment 和 release memo。这样半年后换团队、换模型或监管问询时，大家知道当时为什么这么设计，也知道什么时候可以改。

CTO 追问

如果问 ADR 会不会拖慢团队，我会回答: 低价值文档会拖慢，高质量 ADR 会加速。它减少重复争论，降低新人理解成本，把隐性风险显性化，并让 AI agent 或工程团队在明确约束下实现。关键是只写架构显著决策，保持轻量和可复盘。

---

9. Portfolio Task

做一个 “AI ADR Governance Pack”:

最终要能讲清楚: AI 架构能力不是只会画图，而是能把关键决策、证据和反转条件留下来，让系统长期可演进。