AI Architecture Decision Records 与决策治理

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

Source Anchors

核心导读

AI ADR 的核心不是多写一份架构文档，而是把关键 AI 决策的背景、取舍、证据、风险、后果和反转条件保存为组织记忆。AI 系统中很多选择会长期影响成本、风险、客户体验和可演进性：RAG 还是 fine-tune，是否保存 memory，Agent 能否执行动作，LLM judge 能否作为门禁，vendor model 如何退出，哪些数据能进入 prompt。

ADR 的系统价值在于让这些决策不再留在会议和聊天记录里，而是能被后续团队理解、审计、挑战并在条件变化时安全反转。好的 AI ADR 不只记录“选了什么”，还记录“基于哪些假设和证据选择、会产生哪些后果、哪些信号说明这个选择已经过期”。

核心问题

AI 项目中最关键的决定经常不是代码提交，而是设计取舍。为什么客户服务系统选择 RAG 而不是 fine-tune。为什么 AML Copilot 只能建议下一步，不能自动提交报告。为什么 agent 不能直接冻结账户。为什么 LLM-as-judge 只能作为筛选信号，不能单独作为 release gate。为什么不把客户对话用于模型训练。为什么选择某个供应商模型，退出计划是什么。为什么 prompt 和知识库版本必须绑定。这些决定通常发生在会议、聊天、白板和临时评审中。项目上线后，团队成员变动，供应商升级，监管要求变化，成本压力上升，新团队会重新问同样的问题。如果没有决策记录，组织只能依赖记忆。记忆会丢失背景。丢失背景后，团队容易犯两种错误。一种是重复争论，浪费时间。另一种是错误反转，在不知道原始风险和约束的情况下推翻决策。AI ADR 要解决的核心问题是：如何记录“为什么当时这样设计”，以及“什么条件下应该重新设计”。对金融零售机构来说，这不仅是架构知识管理，也是风险治理和审计证据。

方法贡献

Michael Nygard 的 ADR 思想强调 lightweight decision record。ADR 不需要像大部头架构文档那样覆盖所有系统细节。它记录的是 architecturally significant decision。也就是那些难以轻易改变、影响多个团队、改变质量属性、引入关键依赖、影响风险边界或决定长期演进路径的选择。经典 ADR 包含 status、context、decision 和 consequences。status 说明决策是 proposed、accepted、deprecated 还是 superseded。context 说明当时的背景、约束和问题。decision 说明选择了什么。consequences 说明正面、负面和中性后果。ISO/IEC/IEEE 42010 的架构描述思想提醒我们，架构不是单纯技术结构，而是围绕 stakeholder concerns 组织。不同干系人关心不同问题：客户影响、合规、成本、延迟、安全、可维护性、供应商锁定、运营负载、可解释性和审计。AI ADR 需要吸收这点。它不能只写“我们选择模型 X”，还要写这个选择如何回应不同 concern。AI 系统让 ADR 需要扩展。普通 ADR 记录决策和后果。AI ADR 还必须绑定 evidence、risk tier、artifact versions、monitoring 和 reversal triggers。因为 AI 决策的可接受性经常依赖评测、数据、模型行为和生产表现。

AI ADR 的机制原理

ADR 的基本机制是把隐性判断显性化。一个架构决策如果只存在于会议中，后续团队只能看到结果，看不到取舍。ADR 把背景、替代方案、证据和后果留在系统旁边。AI ADR 可以理解为：

decision context
  -> options considered
  -> selected decision
  -> evidence supporting decision
  -> consequences and trade-offs
  -> monitoring and reversal triggers
  -> status changes over time

其中最关键的是 context。没有 context，decision 会变成教条。“我们不用 fine-tune”本身没有意义。有意义的是：

当前场景是客户服务政策问答。
政策更新频繁，需要引用和版本追踪。
客户可见回答必须能回到权威来源。
历史问题分布仍在变化。
因此当前选择 RAG，而不是 fine-tune。
如果检索长期无法达到召回和延迟目标，或问题类型稳定到适合训练 specialist model，再复盘。

这条 ADR 保存的是推理。后续团队可以同意，也可以反驳。但他们必须基于同一组 concern 和证据反驳，而不是凭感觉重来。

AI ADR 与普通 ADR 的差异

AI ADR 需要比普通 ADR 多记录几个要素。第一，risk tier。同样的架构选择在低风险内部工具和高风险客户决策中含义不同。第二，evidence。AI 决策必须连接 eval report、risk assessment、data review、security review、cost/latency measurement、human review 或 production monitoring。第三，artifact versions。AI 系统行为由 model、prompt、data、knowledge、policy、threshold 和 evaluator 共同决定。决策记录应能追到相关版本。第四，reversal trigger。AI 决策不应写成永久真理。它应说明什么指标、事件、成本、供应商变化或政策变化会触发复盘。第五，monitoring owner。许多 AI 决策的风险只会在生产中显现。如果没有 owner 观察触发条件，反转条件只是文字。因此，一个 AI ADR 不只是记录“选择了什么”，而是记录“在什么证据和假设下选择，如何知道这个选择过期”。

哪些 AI 决策值得记录

不是所有实现细节都需要 ADR。ADR 太多会变成噪音。应记录那些架构显著、风险显著或长期影响显著的决策。常见类型包括：

判断标准可以更简单：如果这个决定半年后会有人问“为什么”，就值得记录。如果错误改变它会影响客户、风险、成本、合规或系统边界，就值得记录。如果它需要多方达成共识，就值得记录。

AI ADR 的内容结构

AI ADR 可以保持轻量，但要覆盖关键推理链。

Title:
  记录具体决策，不写泛泛主题。

Status:
  Proposed / Accepted / Superseded / Deprecated.

Context:
  业务目标、AI 能力、风险等级、干系人 concern、约束和当前问题。

Decision:
  明确选择什么，不选择什么。

Alternatives:
  至少记录主要替代方案和为什么未选。

Consequences:
  正面收益、负面成本、中性影响和需要补偿的控制。

Evidence:
  eval、risk assessment、data review、security review、cost/latency、pilot result。

Reversal triggers:
  指标、事件、成本、监管、供应商或业务条件。

Review:
  owner、复盘日期、监控来源和关联 release bundle。

这个结构不是为了填满表格。它的作用是保留决策的因果关系。尤其要避免只写结论。“We will use RAG”不是 ADR。“在政策频繁更新、需要引用和权限过滤、问题分布仍不稳定的条件下，选择 RAG 而不是 fine-tune，并通过 retrieval eval、citation precision 和 knowledge freshness 监控该决策是否仍成立”才是 ADR。

证据与反转条件

AI ADR 最容易缺失的是 evidence 和 reversal triggers。没有 evidence，ADR 只是主张。没有 reversal trigger，ADR 会变成教条。例如，选择 vendor LLM 时，证据应包括：

• quality eval。
• latency 和 cost。
• data handling 和 privacy review。
• security review。
• model update policy。
• fallback 或 exit plan。
• pilot user feedback。

反转条件可能包括：

• 成本超过预算阈值。
• p95 latency 超过 SLO。
• 供应商改变数据使用条款。
• 模型更新后高风险 eval 退化。
• 监管要求禁止某类数据出域。
• 内部小模型达到相同质量并降低风险。

反转条件不是失败预言。它是理性更新机制。好的 ADR 不是让团队永远坚持当前选择，而是让团队知道什么时候应该改变。

ADR 如何接入 AI 生命周期

AI ADR 不应是项目结束后的总结。它应该嵌入 use case intake、架构评审、风险评估、发布和生产监控。

use case intake
  -> identify architecture-significant decisions
  -> draft ADR
  -> evaluate options and evidence
  -> architecture / risk / product review
  -> accept ADR and link release bundle
  -> implement and test
  -> monitor reversal triggers
  -> review, supersede or deprecate ADR

ADR 与 release bundle 的关系很重要。ADR 说明为什么这组设计可接受。release bundle 说明哪一组 artifact 被实际发布。monitoring 说明生产中这个决策是否仍然成立。如果监控触发 reversal condition，应创建新 ADR 或 supersede 旧 ADR，而不是静默修改系统。这样，架构决策形成历史线索。后续团队可以看到系统为什么演进到今天。

为什么有效

AI ADR 有效，是因为它降低了组织遗忘和决策漂移。AI 系统的关键取舍通常跨越产品、架构、数据、模型、风险、合规、安全和运营。这些取舍如果不被记录，后续团队只能看到一个“现在这样”的系统。他们不知道哪些限制是临时的，哪些是监管要求，哪些是供应商限制，哪些是成本选择，哪些是为了保护客户。ADR 还减少重复争论。当团队再次争论 RAG vs fine-tune，可以先看旧 ADR 的假设是否仍成立。如果政策仍频繁更新、引用仍必须可追溯，旧决策可能仍成立。如果问题分布稳定、成本压力上升、知识结构成熟，反转可能合理。ADR 也帮助审计和监管沟通。金融零售机构面对问询时，不只需要说“我们有控制”，还要说明为什么某个自动化边界、模型选择或人工复核设计是合理的。ADR 提供的是决策证据，而不是单纯结果证据。

局限和误用

第一类误用是把 ADR 写成会议纪要。会议纪要记录讨论过程，ADR 记录决策、背景、取舍和后果。第二类误用是记录太多低价值决策。如果每个小实现都写 ADR，团队会停止阅读。第三类误用是没有替代方案。只写最终选择，看不出权衡。第四类误用是没有反转条件。这样 ADR 会阻碍演进，而不是支持演进。第五类误用是脱离证据。AI 决策必须连接 eval、risk、data、security、cost 或 production evidence。第六类误用是过度技术化。AI ADR 应让业务、风险、运营和审计能理解。如果只写模型参数和库版本，却不写客户影响和风险边界，就不能支撑企业决策。第七类误用是不更新状态。旧 ADR 如果已经被新决策覆盖，应标记 superseded 并链接新 ADR。否则旧记录会误导团队。

架构和产品价值

AI ADR 的产品价值在于把 AI 方案的边界和承诺说清楚。它让产品团队能解释为什么某些能力不自动化、为什么某些回答要拒答、为什么某些场景需要人工。AI ADR 的架构价值在于保存系统演进逻辑。模型、RAG、agent、数据、供应商和治理边界都会变化。ADR 让这些变化有轨迹。在金融零售中，ADR 还可以连接到以下资产：

• AI inventory。
• risk tier。
• eval contract。
• model card。
• dataset card。
• release bundle。
• control library。
• incident record。
• management review。

一个成熟系统中，ADR 不是孤立文档。它应该像这样连接：

AI use case
  -> key decisions
  -> ADRs
  -> evidence artifacts
  -> release bundle
  -> monitoring signals
  -> review or supersede

这种连接让架构治理从“评审一次”变成“决策可持续管理”。

金融零售 ADR 示例

客户服务 RAG 不使用 Fine-Tune

决策可以写成：

For customer-facing policy Q&A, we will use RAG with source authority,
permission filtering and citation support instead of fine-tuning.

背景是政策更新频繁、回答客户可见、引用和版本必须可追溯、知识权限需要过滤。替代方案包括 fine-tune、long context 和纯人工知识库检索。选择 RAG 的正面后果是可更新、可引用、可按权限过滤。负面后果是需要投入知识治理、retrieval eval、index freshness 和 citation monitoring。反转条件可以是：

• retrieval recall 长期无法达到门槛。
• p95 latency 无法满足服务体验。
• 问题分布稳定且 specialist model 能以更低成本达到同等质量。
• 权威知识结构变化，使现有 RAG 无法维护。

这条 ADR 的价值不是“RAG 好”，而是记录 RAG 在当前约束下为什么可接受。

Fraud Agent 不允许自动冻结账户

决策可以写成：

Fraud agent may recommend account hold and prepare evidence,
but cannot execute account freeze without human approval.

背景是账户冻结属于高客户影响动作，false positive 伤害大，申诉和补救要求高。替代方案包括全自动冻结、自动冻结低金额/高置信 segment、只做人工建议。当前选择可能是“只做人工建议，未来考虑低风险动作自动化”。证据包括历史 false positive 分析、队列容量、客户投诉、模型校准、人工复核 SLA。反转条件可以是低风险 segment 经过 shadow 和 canary 后 false positive 稳定低于阈值，且申诉/补救机制成熟。这条 ADR 保护的是自动化边界。

LLM Judge 不能单独作为 Release Gate

决策可以写成：

LLM judge may be used as a screening and diagnostic signal,
but final release gate requires golden set metrics and calibrated human review.

背景是 LLM judge 会漂移，rubric 可能歧义，高风险场景需要独立验证。替代方案包括完全人工评审、完全 LLM judge、混合 gate。混合 gate 的好处是效率和覆盖率较高，缺点是需要维护 judge rubric、校准样本和人工抽检。反转条件可以是 judge 与人类专家长期一致、低风险场景证明可靠，或成本压力要求调整评审策略。这条 ADR 说明 eval 不是一个模型打分，而是一套证据体系。

Vendor Model 选择与退出

供应商模型 ADR 不应只写“选择某某模型”。它要记录：

• 为什么不自建或用开源模型。
• 数据是否出域。
• 日志是否保留。
• 模型更新是否可控。
• 成本和延迟是否满足 SLO。
• 退出计划是什么。
• 哪些功能必须支持 fallback。

如果没有退出条件，vendor dependency 会变成长期架构债。反转条件可能是数据条款变化、成本失控、质量退化、监管限制或内部模型达到目标。

学习验证

读完这一篇后，应能完成以下验证任务：

1. 为客户服务 RAG 写一条 ADR，比较 RAG、fine-tune、long context 和人工检索，并写出证据和反转条件。

2. 为 fraud agent 的 tool permission 写一条 ADR，说明哪些工具可调用、哪些动作必须 HITL、为什么。

3. 为 LLM judge release gate 写一条 ADR，说明它能做什么、不能单独做什么、如何校准。

4. 为 vendor model 选择写一条 ADR，包含数据、成本、延迟、质量、供应商更新、退出计划和 fallback。

5. 从一个已有 AI 系统中识别 5 个 architecture-significant decisions，并判断哪些需要 ADR。

6. 将一条 ADR 连接到 eval report、risk assessment、release bundle 和 monitoring trigger。

7. 设计 ADR 状态流转：proposed、accepted、superseded、deprecated，以及何时创建新 ADR。

关键结论

AI ADR 的本质是决策记忆。它保存的不只是“选了什么”，而是为什么在当时的业务目标、技术约束、风险等级和证据条件下这样选择，以及什么条件会让这个选择失效。金融零售 AI 系统尤其需要 ADR，因为模型、数据、供应商、自动化边界和监管约束都会变化。掌握 AI ADR 的标志，不是会套模板，而是能识别关键 AI 取舍，记录替代方案和后果，绑定证据与版本，设计反转条件，并让决策随着生产监控和业务环境变化持续演进。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。