AI Quality Attributes / ATAM：架构权衡
AI 架构评审不能停在“RAG 还是 fine-tune”“用哪个模型”“要不要 agent”。这些都是方案层问题。真正决定系统能否上线和长期运营的, 是质量属性在具体业务场景中的可接受边界: 准确性、groundedness、延迟、成本、隐私、安全、审计、可变更性、韧性和人工控制如何同时成立, 又在哪些地方必须取舍。
AI Quality Attributes / ATAM / Architecture Tradeoff 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_QUALITY_ATTRIBUTES_ATAM_TRADEOFF_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| SEI Architecture Tradeoff Analysis Method | https://insights.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/ | 参考 ATAM 的质量属性、架构策略、风险、权衡点和效用树方法（ATAM 原始论文发表于 1998, IEEE ICECCS；访问日期: 2026-07-01） |
| ISO/IEC/IEEE 42010 | https://www.iso-architecture.org/ieee-1471/ | 参考 stakeholder、concern、viewpoint 的架构描述思想（现行版为 ISO/IEC/IEEE 42010:2022；访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将质量属性连接到 AI 风险的 Map / Measure / Manage（AI RMF 1.0 发布 2023-01，2025-2026 处于修订周期；访问日期: 2026-07-01） |
| NIST GenAI Profile | https://www.nist.gov/itl/ai-risk-management-framework/generative-artificial-intelligence-profile | 参考生成式 AI 特有风险, 如 hallucination、data leakage、harmful output、overreliance（NIST AI 600-1 发布 2024-07） |
核心导读
AI 架构评审不能停在“RAG 还是 fine-tune”“用哪个模型”“要不要 agent”。这些都是方案层问题。真正决定系统能否上线和长期运营的, 是质量属性在具体业务场景中的可接受边界: 准确性、groundedness、延迟、成本、隐私、安全、审计、可变更性、韧性和人工控制如何同时成立, 又在哪些地方必须取舍。
ATAM 的价值在于把架构争论从偏好变成证据化分析: 先定义业务驱动和 stakeholder concern, 再写 quality attribute scenarios, 形成 utility tree, 识别 architecture tactics、tradeoff point、sensitivity point、risk 和 non-risk, 最后把结论沉淀为 ADR、eval evidence 和 release gate。AI 场景下, ATAM 不是旧方法套新词, 而是把模型、RAG、agent、工具调用、数据权限和人工复核放进同一个质量属性系统中审视。
1. 问题定义
AI 系统最容易被功能演示误导。一个 demo 能回答问题、接入知识库、调用工具、生成报告, 并不意味着它可以进入金融零售的真实工作流。上线判断需要回答更难的问题:
- 在什么任务分布下准确, 在什么长尾场景下退化。
- 哪些错误是可接受的返工, 哪些错误会造成客户权益、合规或财务损害。
- 知识源过期、权限过滤失败、模型升级、prompt injection 或工具不可用时, 系统如何表现。
- 输出如何被引用、解释、复盘、申诉和审计。
- 自动化节省的时间是否被复核、异常处理和补救成本抵消。
- 人工控制是真正能接管, 还是只是 UI 上的确认按钮。
功能决定系统“能做什么”; 质量属性决定系统“在什么约束下值得做、能不能扩展、出了问题能不能解释和恢复”。AI 架构评审的基本对象不应是单个组件, 而应是业务能力、模型行为、数据边界、工作流控制和运营证据共同形成的系统。
2. 核心原理 / 架构模型
2.1 AI 质量属性体系
| 质量属性 | AI 场景中的含义 | 常见证据 |
|---|---|---|
| Task Accuracy | 对目标任务的正确程度 | task accuracy、F1、exact match、human acceptance |
| Groundedness | 输出是否受授权来源支持 | citation precision、unsupported claim rate |
| Calibration | 置信表达是否匹配真实可靠性 | confidence-error correlation、escalation appropriateness |
| Robustness | 对噪声、长尾、攻击和分布变化的稳定性 | adversarial pass rate、drift impact |
| Safety | 是否避免客户、财务、合规和操作伤害 | critical failure rate、unsafe action rate |
| Privacy | 是否保护个人、敏感和机密数据 | PII leakage rate、data minimization evidence |
| Security | 是否抵抗 prompt injection、tool abuse、data exfiltration | attack success rate、policy bypass rate |
| Explainability | 是否能让用户和审计者理解依据 | rationale quality、citation coverage |
| Auditability | 是否能重建输入、版本、决策和输出 | trace completeness、log retention evidence |
| Latency | 用户工作流可接受的响应时间 | p50/p95/p99 latency |
| Cost Efficiency | 单次任务成本和规模化成本 | cost per case、monthly burn、unit economics |
| Modifiability | 业务规则、知识、模型、prompt 变化的成本 | change lead time、regression effort |
| Resilience | 依赖失败、模型退化、流量峰值下的恢复能力 | fallback success、MTTR、rollback time |
| Human Controllability | 人能否理解、纠正、拒绝、接管 | override success、review load、handoff completion |
| Fairness | 对不同群体是否产生系统性不利影响 | disparity metrics、impact analysis |
这些属性不能全部最大化。更强模型可能提升 accuracy, 也可能增加成本、延迟、供应商依赖和数据风险。更严格 guardrail 可能降低违规输出, 也可能增加误拒和业务摩擦。更高自动化可能提高吞吐, 也可能削弱人工控制和错误可恢复性。架构工作的核心, 是让这些取舍被看见、被度量、被业务和风险 owner 接受。
2.2 AI ATAM 的分析链路
Business Driver
-> AI Capability Boundary
-> Quality Attribute Scenario
-> Architecture Tactic
-> Eval Evidence
-> Risk / Tradeoff / Sensitivity Point
-> ADR and Release Gate
其中最关键的是 quality attribute scenario。它把抽象质量属性落到可测试场景:
Source:
谁触发场景
Stimulus:
什么事件发生
Environment:
正常、高峰、模型升级、知识过期、攻击、人工忙碌等上下文
Artifact:
模型、RAG、agent、API、工作流、数据源、日志等被影响对象
Response:
系统应如何响应
Response Measure:
用什么阈值判断响应可接受
金融零售中的 AML copilot 场景可以写成:
Source:
AML analyst
Stimulus:
请求 AI 总结高风险 alert 的交易链路和可疑点
Environment:
客户历史资料完整, 但部分交易备注为空; alert 属于高风险 typology
Artifact:
AML Copilot RAG + case summarizer
Response:
输出事实摘要、引用交易证据、标注推断, 并提示必须人工复核
Response Measure:
critical fact omission rate <= 1%
citation precision >= 96%
high-risk escalation recall >= 98%
p95 latency <= 6s
2.3 Utility Tree
Utility tree 用来对质量属性排序, 不是列愿望清单。以客服 copilot 为例:
Business Goal:
降低处理时长, 提升政策一致性, 不增加投诉和合规风险。
High Priority
Safety
- 不输出未经授权退款承诺
- 高风险投诉必须升级
Groundedness
- 政策回答必须引用授权知识源
Human Controllability
- 客服可编辑、拒绝、升级、反馈
Medium Priority
Latency
- p95 <= 4s
Cost Efficiency
- cost per case <= target
Explainability
- 展示政策依据和更新时间
Lower Priority
Tone Optimization
- 语气更自然
Personalization
- 根据客户历史定制表达
排序原则是先客户权益和合规风险, 再任务正确性与可控制性, 再效率、成本和体验优化。风格自然、表达个性化等能力可以重要, 但不应压过 safety、groundedness 和 auditability。
3. 方法机制
3.1 评审流程
AI ATAM 可以组织为一次结构化架构评审:
- 明确业务驱动: outcome、约束、风险等级、目标用户和不可接受损害。
- 展示架构概览: model、RAG、tools、data flow、human workflow、monitoring 和 deployment pattern。
- 提炼质量属性: 从业务、风险、运营、数据、安全、工程和用户体验关注点中抽取 top concerns。
- 生成场景: 覆盖 normal、edge、adversarial、incident、scale、change、drift。
- 构建 utility tree: 按重要性、难度和风险对场景排序。
- 分析架构策略: 把 RAG、fine-tune、routing、HITL、guardrail、tool gateway、cache、shadow mode、canary 等策略映射到场景。
- 识别风险和权衡: 记录 tradeoff point、sensitivity point、risk、non-risk。
- 制定证据计划: 明确 eval、pilot、monitoring、audit evidence 和 owner。
- 形成上线建议: pass、conditional pass、redesign、reject。
3.2 架构策略矩阵
| 架构策略 | 改善 | 代价 / 风险 |
|---|---|---|
| RAG with citations | groundedness、freshness、auditability | latency、retrieval quality、权限复杂度 |
| Fine-tune | 风格一致、领域表达、低延迟 | 数据治理、更新成本、遗忘风险 |
| Model routing | 成本、延迟、任务适配 | 行为一致性、测试复杂度 |
| Human-in-the-loop | safety、control、accountability | 运营成本、处理时长、人工负载 |
| Guardrail layer | safety、policy compliance | false positive、用户摩擦、维护成本 |
| Tool allowlist | agent safety、least privilege | 自动化能力受限 |
| Immutable audit log | auditability、incident review | 存储成本、隐私和访问控制 |
| Cache | cost、latency | stale answer、个性化风险 |
| Shadow mode | 风险降低、证据积累 | 上线周期变长 |
| Canary release | 控制爆炸半径 | 运维复杂度 |
3.3 Tradeoff 与 Sensitivity
Tradeoff point 是一个架构选择同时正向和负向影响多个质量属性的地方。例如长上下文可以提升召回, 也会增加成本、延迟、隐私暴露面和无关信息干扰。Sensitivity point 是结果对某个参数或假设特别敏感的地方, 例如 retrieval top-k、citation threshold、人工复核容量、模型版本、知识源更新时间、agent 工具权限。
成熟的评审不会只写“风险: 模型可能幻觉”, 而会写:
- 哪个场景触发。
- 哪个质量属性被破坏。
- 哪个参数或架构策略最敏感。
- 当前证据是否足够。
- 需要在 release gate 前补什么验证。
- 残余风险由谁接受。
4. 证据与控制
AI ATAM 的输出应进入上线控制, 而不是停留在会议纪要。高风险能力至少需要以下证据:
| 控制点 | 证据 |
|---|---|
| 质量属性场景 | 每个关键能力覆盖 normal、edge、adversarial、drift |
| Eval contract | 指标、阈值、golden set、failure taxonomy、human review 标准 |
| Risk register | risk、tradeoff、sensitivity、owner、mitigation、residual risk |
| ADR | 关键架构选择、备选方案、选择理由、反转条件 |
| Release gate | eval pass/fail、pilot result、monitoring readiness、rollback plan |
| Monitoring | quality、latency、cost、safety、drift、incident、review load |
| Audit trail | 输入、检索证据、模型版本、prompt、工具调用、人工操作 |
评审清单可以压缩成七个判断:
| 问题 | 通过标准 |
|---|---|
| 是否有质量属性场景, 而不是只有功能清单 | 每个高风险能力至少 3 个可测试场景 |
| 是否区分 normal / edge / adversarial / drift | eval set 和 pilot 覆盖四类 |
| 是否明确 tradeoff point | 每个关键策略写出收益和牺牲项 |
| 是否有 sensitivity point | 找出对阈值、模型、知识源、流量、人工容量敏感的参数 |
| 是否有 owner | 高优先级属性绑定业务、风险、数据或工程 owner |
| 是否连接 release gate | 质量属性有对应 eval、monitoring 和 rollback |
| 是否记录 ADR | 关键权衡可追溯, 未来可反转 |
5. AI产品/金融零售场景
5.1 AML Copilot
AML 场景的最高优先级不是生成流畅报告, 而是不遗漏关键事实、区分事实与推断、引用可审计、高风险强制复核, 并能在调查链路中保留证据。RAG 引用交易和政策可以增强 auditability 和 groundedness, 但会带来 retrieval latency 和权限过滤复杂度。禁止自动关闭 alert 会降低效率上限, 却能保护监管可辩护性。这里的目标不是最大自动化, 而是在调查质量和吞吐之间找到可证明的平衡。
5.2 信贷 Decision Support
信贷支持系统不能只优化 approval prediction accuracy。质量属性必须覆盖 explanation consistency、fairness impact、adverse action reason accuracy、override auditability、policy update modifiability。若系统生成拒绝原因或额度调整建议, 每个输出都需要可追溯到政策、数据和人工决策边界, 否则准确率提升可能被解释风险和公平风险抵消。
5.3 Wealth Advisor Assistant
财富顾问助手的关键权衡是个性化与合规边界、建议深度与 suitability review、实时市场信息与数据许可、对话体验与 disclosure/audit record。架构上需要区分 education、preparation、recommendation 和 execution, 并对不同自动化层级设置不同的证据和人工控制要求。
5.4 Customer Service Copilot
客服场景看似低风险, 但错误承诺、投诉升级遗漏和政策过期会快速变成客户权益问题。Utility tree 应把 unauthorized promise、complaint escalation、policy citation 放在前面, 再谈语气优化和个性化。客服能编辑和拒绝输出只是起点, 系统还需要采集修改原因、监控误导话术、把真实错误回流到 eval。
6. 反模式
| 反模式 | 表现 | 后果 |
|---|---|---|
| Model-first architecture | 先选模型, 再补业务约束 | 质量属性和风险控制被动拼接 |
| RAG vs fine-tune 口味之争 | 把架构选择变成技术偏好 | 忽略 freshness、latency、audit、modifiability 等真实约束 |
| Average accuracy trap | 只看平均准确率 | 长尾、高风险和少数群体场景被掩盖 |
| Fake HITL | 有人工确认, 但没有证据、时间和权限 | 责任转移, 风险未下降 |
| Guardrail theater | 只加输出过滤 | 工具权限、数据权限、工作流控制仍然暴露 |
| Eval detached from architecture | eval 指标不对应架构权衡 | 无法支撑 release gate 和 ADR |
| No sensitivity analysis | 不知道系统对哪些参数敏感 | 模型升级、知识变化或流量变化时不可预测 |
7. 最终心智模型
AI ATAM 的核心不是多写一份评审文档, 而是建立一种架构判断方式:
AI architecture quality
= business-critical scenarios
+ explicit quality attributes
+ architecture tactics
+ evidence thresholds
+ tradeoff ownership
+ release and monitoring controls
当讨论 AI 架构时, 先把“系统能做什么”转成“系统在什么场景、什么阈值、什么风险边界下可接受”。再把方案选择转成可追溯的权衡: 哪些质量属性被提升, 哪些被牺牲, 哪些参数最敏感, 哪些证据还不足。能做到这一点, 架构图才不只是组件连接图, 而是业务价值、风险控制和系统演进之间的契约。
SOTA 检查 (2026-07-01)
- ATAM 方法本身（SEI, 1998 提出）仍是架构权衡评审的事实标准, 未被替代——SEI 至今维护 ATAM Collection；2025 年的新变化不是换方法, 而是用 LLM 辅助执行 ATAM: arXiv 2506.00150《Supporting architecture evaluation for ATAM scenarios with LLMs》(2025-06) 验证了 LLM 生成/评估质量属性场景的可行性。本篇「scenario → utility tree → tactic → tradeoff/sensitivity → ADR」的分析链路是框架性结论, 不随模型版本过时。
- AI 风险侧的锚点已从 AI RMF 1.0 (2023-01) 细化为 GenAI Profile (NIST AI 600-1, 2024-07): 其 12 个 GAI 风险类别（confabulation、information security、human-AI configuration、value chain 等）可直接映射到本篇 §2.1 的 groundedness/security/human controllability/供应链属性; 2025-2026 社区已在此之上推进 agentic 扩展（如 Cloud Security Alliance 的 Agentic AI NIST RMF Profile）, 说明本篇把 agent 工具权限纳入质量属性体系的方向与行业一致。
- 可认证治理层已经补齐: ISO/IEC 42001:2023（2023-12 发布, 首个可认证的 AI 管理体系标准）+ ISO/IEC 42005:2025（2025-06 发布, AI 系统影响评估指南）。本篇 §4 的「证据进 release gate、残余风险有 owner」正是这两个标准落地时的核心控制点; 做金融机构评审时应显式引用 42001 控制项。
- LLM/Agent 系统的质量属性研究在 2025 年已有实证基线: arXiv 2511.08475 (2025-11) 对 LLM multi-agent 系统的设计模式统计显示 functional suitability (94.7%)、performance efficiency (51.1%)、maintainability (50.0%) 是最常被设计考虑的属性, 而 security 仅 10.6%——印证本篇反模式「guardrail theater / model-first」的判断; arXiv 2411.13768 (2024-11) 的 evaluation-driven development 参考架构与本篇「eval evidence 绑定架构权衡」同构。
- 仍未收敛的开放问题（2025-2026 文献共识）: autonomy vs controllability、latency vs reliability、capability vs safety 这类系统级 tradeoff 在跨领域/跨部署形态下尚无统一度量——正是本篇 tradeoff point / sensitivity point 记法要填的空。
- 库内配套实践（已验证路径存在）: 本篇 §4 的 eval contract / release gate 在
docs/aipa/day19-blocking-ci-eval-gate.md（2026-07 体例, 五道递进 CI eval 闸门）与docs/aipa/day53-risk-gateway.md中有可运行的工程化版本, 可作为 ATAM 结论落到流水线的模板。