AI 扩展计划 / Playbooks

AI Quality Attributes / ATAM Tradeoff Playbook

版本: v1.0

811 行AI_QUALITY_ATTRIBUTES_ATAM_TRADEOFF_PLAYBOOK.md

AI Quality Attributes / ATAM / Architecture Tradeoff Playbook

版本: v1.0 日期: 2026-06-29 适用对象: AI 产品经理、AI Solutions Architect、企业架构师、CBAP / Senior BA、Model Risk、Risk & Compliance、Data Governance、Security、Internal Audit、金融零售业务负责人

1. Source Anchors

这些来源作为质量属性、架构描述、AI 风险管理和架构权衡分析的学习锚点。本文把它们转化为金融零售 AI 系统的高级架构评审方法, 不是法律意见、审计结论、监管解释或模型验证报告。

Anchor	Link	本手册采用的思想	落地到 AI ATAM
SEI ATAM	https://insights.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/	ATAM 用质量属性目标评估软件架构, 暴露影响业务目标的架构风险, 并分析质量属性之间的相互制约	用 quality attribute scenario、utility tree、sensitivity point、tradeoff point、risk、non-risk 组织 AI 架构评审
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern、Map、Measure、Manage 管理 AI 风险, 并把可信 AI 放进全生命周期治理	把质量属性从技术指标扩展到可治理、可度量、可处置、可复核的 AI risk and quality profile
ISO/IEC/IEEE 42010	https://www.iso-architecture.org/ieee-1471/	架构描述围绕 stakeholder、concern、view、viewpoint 组织, 架构不是单张图, 而是多视角表达	每个 quality attribute scenario 必须说明 stakeholder concern、viewpoint、evidence 和受影响的架构决策
SEI ATAM Collection	https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/	ATAM 的核心价值是早期暴露风险、权衡点和敏感点, 让架构选择与业务驱动对齐	把 AI 的模型、数据、RAG、agent、HITL、guardrail、observability 作为 architectural approaches 评估
NIST AI RMF Core	https://airc.nist.gov/airmf-resources/airmf/5-sec-core/	AI RMF Core 通过高层函数支持风险管理活动和组织对话	把 ATAM 输出的风险、门禁、监控和残余风险接入 AI governance cadence

使用纪律:

Source anchors 用来校准方法语言, 不是用外部框架替代机构内部风险政策。
AI ATAM 的产物不是“评审会议纪要”, 而是一组可追溯的架构质量证据: scenarios、utility tree、tradeoff matrix、ADR、eval gate、risk register、monitoring thresholds。
金融零售场景必须由 Legal、Compliance、Model Risk、Privacy、Security、Data Owner、Business Owner 和 Internal Audit 判断正式义务。
任何高影响 AI 系统的质量属性声明都必须绑定系统版本、模型版本、prompt 版本、RAG index 版本、tool schema 版本、eval run 和上线范围。

2. One-Sentence Positioning

一句话定位:

AI ATAM 是把 AI 系统的业务目标、质量属性、架构方案、模型行为、数据依赖、风险控制和上线证据放进同一张权衡地图, 用来判断“这个 AI 架构在这些约束下是否值得上线、如何限制上线、何时必须重新评审”。

这份手册不讲基础 BA。它训练的是更高级的产品架构能力:

高级能力	具体表现	可展示资产
质量属性工程	把“准确、可靠、安全、便宜、快、可解释”改写成可测试的 quality attribute scenario	AI quality attribute scenario catalog
架构权衡分析	识别 RAG、fine-tune、agent、rules、HITL、model routing、guardrail 的 tradeoff / sensitivity / risk	Architecture tradeoff matrix
证据驱动评审	把 architecture review 连接到 eval、monitoring、risk acceptance、ADR 和 release gate	AI ATAM evidence pack
金融零售场景化	针对 AML、客服、信贷、财富/投顾区分质量属性优先级和控制强度	Financial retail AI ATAM case portfolio
面试表达	能用 30 秒和 2 分钟讲清楚“我如何评审 AI 架构质量与权衡”	Senior AI PM / Architect interview answers

3. 为什么 AI 系统更需要质量属性和 ATAM

传统系统的架构评审常围绕性能、可用性、可扩展性、安全、可维护性和成本。AI 系统把这些问题放大, 还引入新的不确定性:

同一输入在不同模型版本、prompt、上下文和温度下可能产生不同输出。
RAG 的质量取决于知识源、权限过滤、chunking、embedding、reranker、freshness 和 citation。
Agent 从“生成答案”进入“调用工具”和“改变业务状态”, 权限边界成为架构质量属性。
质量不再只由单元测试证明, 还要依赖 eval dataset、human review、LLM judge、red-team、production trace 和 drift monitoring。
金融零售 AI 错误可能影响客户权益、监管义务、员工决策、模型风险、声誉和操作风险。

弱评审通常只问:

模型准确率多少?
有没有 human-in-the-loop?
供应商是否合规?
prompt 写得是否清楚?
成本是否可接受?

AI ATAM 要问更硬的问题:

评审问题	架构师应该追问
准确率够不够?	哪个任务、哪个人群、哪个风险等级、哪个数据切片、哪个错误严重度、哪个上线门槛?
有人工复核吗?	人复核什么字段、何时复核、是否能看到证据、是否能覆盖高风险样本、是否保留 edit diff 和 override?
RAG 能防幻觉吗?	召回是否覆盖关键政策、引用是否支持结论、权限过滤是否正确、过期知识如何处理、无证据时是否拒答?
Agent 是否安全?	tool allowlist、参数校验、幂等、限额、审批、熔断、审计日志、回滚和异常补偿如何设计?
成本能不能降?	降成本是否牺牲高风险场景质量、延迟、可解释性、数据驻留、供应商退出路径和监控能力?

一句话:

AI 架构评审的重点不是证明某个模型“聪明”, 而是证明整套系统在明确质量属性、风险边界和证据门槛下足够可控。

4. AI Quality Attributes Taxonomy

AI quality attributes 不等于“模型指标”。成熟的 taxonomy 至少覆盖业务结果、模型行为、数据、控制、运行、治理和演进。

4.1 Taxonomy 总览

类别	质量属性	核心问题	AI 系统中的典型指标	主要证据
Output Quality	Correctness / Task Accuracy	输出是否完成指定业务任务	exact match、expert pass rate、case resolution quality、tool call accuracy	eval report、human review、error analysis
Output Quality	Groundedness / Faithfulness	输出是否被检索证据或系统事实支持	citation support rate、unsupported claim rate、evidence mismatch severity	retrieval eval、citation audit、RAG trace
Output Quality	Completeness	是否覆盖关键事实、政策条件和业务约束	missing critical field rate、checklist coverage、required factor recall	rubric eval、SME review
Output Quality	Consistency	同类输入、同版本策略和同一事实下是否稳定	answer variance、policy conflict rate、multi-run disagreement	regression eval、scenario replay
Safety & Risk	Harm Avoidance	是否避免造成客户、业务、合规或安全伤害	critical harm count、unsafe recommendation rate、under-escalation rate	red-team、risk review、incident log
Safety & Risk	Fairness / Bias Control	是否避免不合理差别影响或代理变量歧视	slice performance gap、adverse impact signal、complaint pattern	fairness analysis、model risk validation
Safety & Risk	Privacy	是否保护 PII、客户数据、敏感业务数据	PII leakage rate、retention exception、unauthorized context exposure	privacy review、DLP test、access test
Safety & Risk	Security / Prompt Injection Resistance	是否抵抗越权、注入、数据泄露和工具滥用	jailbreak success rate、prompt injection pass rate、tool abuse detection	threat model、red-team report、security test
Control	Controllability	系统能否被限制、配置、暂停、降级和回滚	kill switch time、policy propagation time、rollback success rate	runbook、control test、release record
Control	Human Oversight Effectiveness	人工监督是否真实有效	review coverage、override rate、reviewer agreement、edit distance	HITL logs、sample audit、training record
Control	Explainability / Contestability	输出和决策路径是否可解释、可质疑、可申诉	explanation usefulness、appeal handling time、evidence completeness	explanation sample、appeal workflow
Operations	Availability	系统是否在承诺时间可用	uptime、model provider availability、fallback success rate	SLO dashboard、provider SLA、incident RCA
Operations	Latency	响应时间是否符合业务流程	p50/p95/p99 latency、timeout rate、queue time	trace metrics、load test
Operations	Cost Efficiency	单次任务成本是否可持续	cost per case、token cost、review cost、model routing savings	cost dashboard、unit economics
Operations	Observability	是否能定位、复现、解释和趋势化失败	trace completeness、missing log rate、replay success rate	observability dashboard、trace schema
Data & Knowledge	Data Quality / Freshness	数据和知识是否准确、完整、及时	freshness SLA、stale citation rate、source coverage	data contract、lineage、freshness report
Data & Knowledge	Access Correctness	检索和工具访问是否遵守权限	unauthorized retrieval rate、tenant isolation pass rate	RBAC/ABAC test、retrieval access logs
Evolution	Modifiability	模型、prompt、index、tool、policy 改动是否可控	change lead time、regression scope、blast radius	ADR、version registry、regression report
Evolution	Portability / Vendor Exit	是否能迁移模型、供应商、部署区域或组件	migration effort、dependency concentration、exit drill result	vendor assessment、abstraction design
Governance	Auditability	是否能向审计、监管、风险团队证明控制执行	evidence completeness、approval traceability、sample reproducibility	evidence binder、decision log
Governance	Compliance Fitness	系统是否适配监管、内部政策和风险偏好	policy exception count、control coverage、issue aging	control mapping、risk acceptance

4.2 AI 质量属性的优先级不是通用排序

同一个属性在不同金融零售场景中的权重不同:

场景	优先级最高的属性	优先级容易被误判的属性	架构评审重点
AML Copilot	Groundedness、auditability、human oversight、privacy、security	单纯追求生成流畅度	证据引用、case trace、SAR draft 边界、analyst 最终责任
Customer Service Copilot	Consistency、latency、policy compliance、tone safety、fallback	只看 handle time 降低	客户可见风险、升级路径、投诉闭环、policy freshness
Credit Decisioning / Credit Policy AI	Fairness、explainability、contestability、model risk、data lineage	只看 AUC 或 approval lift	不利影响、adverse action reason、禁止自动化越界、验证独立性
Wealth / Advisory Assistant	Suitability、risk disclosure、groundedness、customer protection、auditability	只看个性化和转化率	投顾边界、产品适配、风险承受能力、禁止未经授权建议

4.3 质量属性之间天然有冲突

冲突	典型表现	需要显式决策
Latency vs Groundedness	检索更多证据、rerank 和 citation check 增加延迟	是否对高风险问题启用慢路径, 对低风险 FAQ 启用快路径
Cost vs Accuracy	低成本模型处理复杂案例会增加错误	是否使用 model routing, 并设置风险分级阈值
Automation vs Human Oversight	自动处理提高效率, 但减少专家复核	哪些动作只能 draft, 哪些动作允许 execute
Privacy vs Observability	更完整日志便于复现, 但增加敏感数据保留	日志字段最小化、脱敏、分级访问和保留期限
Explainability vs Model Complexity	复杂模型可能提升预测力, 但解释和申诉困难	是否用规则/传统模型/LLM 组合, 对客户影响点保持可解释
Freshness vs Stability	高频知识刷新提升时效, 但引入回归和不可复现	知识库发布门禁、版本固定和回放测试
Security vs Usability	强拒答和严格权限降低越权, 但可能伤害体验	按场景设置 policy, 用 escalation 而非简单拒绝

5. Quality Attribute Scenario 模板

质量属性必须写成 scenario, 否则团队只是在争论抽象形容词。

5.1 标准场景结构

字段	含义	AI 扩展
Scenario ID	唯一编号	`QA-AML-GROUNDED-001`
Quality Attribute	质量属性	Groundedness、latency、auditability、fairness
Stakeholder Concern	哪类 stakeholder 的关切	Analyst、Customer、Compliance、Risk、Ops、Security
Source of Stimulus	刺激来源	客户问题、analyst 操作、模型升级、攻击者输入、知识库刷新
Stimulus	具体刺激	“客户询问 fee reversal policy 并包含情绪化投诉”
Environment	运行环境	peak hour、provider degraded、pilot scope、high-risk case、new policy effective date
Artifact	受影响对象	LLM response、retriever、tool call、case summary、decision workflow
Response	系统应如何响应	检索批准来源、生成带引用草稿、升级人工、拒绝越权工具调用
Response Measure	可验证指标	p95 latency < 3s、citation support >= 97%、critical violation = 0
Failure Severity	失败严重度	Critical / High / Medium / Low
Evaluation Method	如何验证	offline eval、human rubric、red-team、load test、production sampling
Control Owner	谁负责控制	Architect、Model Risk、Ops、Data Owner、Business Owner
ADR Link	关联决策	model routing ADR、HITL ADR、data retention ADR
Monitoring Trigger	何时复审	指标跌破阈值、事故、知识库刷新、供应商模型变更

5.2 场景写法示例

字段	示例
Scenario ID	`QA-CS-POLICY-002`
Quality Attribute	Policy compliance + latency
Stakeholder Concern	Contact center manager 需要降低 AHT, Compliance 需要避免错误政策承诺
Source of Stimulus	客服坐席在高峰期询问“账户费用能否减免”
Stimulus	用户账户存在多个产品、历史减免和投诉记录, 问题涉及最新 fee waiver policy
Environment	p95 call volume, model provider 正常, policy index 为 `retail-fee-policy-2026Q2`
Artifact	RAG answer draft + cited policy snippets
Response	系统必须在 2.5 秒内返回带引用草稿; 如果政策证据冲突或客户属于高风险投诉, 必须升级 SME 或给出 “needs review”
Response Measure	p95 latency <= 2.5s; citation support >= 98%; high-risk under-escalation = 0; unsupported fee promise = 0
Failure Severity	High
Evaluation Method	500 条 golden set + 100 条高风险投诉样本 + production weekly sample
Control Owner	Contact Center Platform Owner + Compliance Policy Owner
ADR Link	`ADR-AI-CS-004-model-routing-and-rag-citation`
Monitoring Trigger	policy 更新、unsupported promise 出现 1 次、p95 latency 连续 3 天超过 2.5s

5.3 好场景和弱场景对比

弱场景	问题	强场景
系统要准确回答客户问题	无任务、无环境、无指标、无错误严重度	在客服高峰期, 对 approved policy source 覆盖的问题, 系统 p95 2.5 秒内生成带引用草稿, unsupported policy claim 为 0
AML summary 要可靠	不知道可靠指什么	对 high-risk AML alert, summary 必须覆盖全部 red flag checklist critical items, 引用 case evidence, 不得自动 disposition
信贷 AI 要公平	没有 slice 和验证方法	对受保护属性代理变量相关切片, decline explanation quality gap 不超过设定阈值, 高风险差异进入 independent validation
投顾 AI 要合规	没有投顾边界	对未完成风险承受能力评估的客户, 系统不得给出产品推荐, 只能解释教育性内容并提示完成 suitability workflow

6. ATAM 如何改造成 AI ATAM

传统 ATAM 以业务驱动、架构方案、质量属性场景、utility tree 和权衡分析为核心。AI ATAM 保留这些骨架, 但把“架构方案”的边界扩大到模型、数据、知识、prompt、agent、eval、HITL、guardrail、observability 和治理。

6.1 传统 ATAM 到 AI ATAM 的映射

ATAM 活动	传统关注点	AI ATAM 改造	关键产物
Present ATAM	解释评审方法	解释质量属性、AI 风险、证据门槛和评审角色	AI ATAM briefing
Present Business Drivers	业务目标、约束、功能、质量目标	加入风险等级、客户影响、监管敏感性、自动化程度、数据敏感性	Business driver and risk context
Present Architecture	架构视图、组件、部署、接口	加入 model / prompt / RAG / tool / guardrail / judge / HITL / observability / vendor 视图	AI architecture views
Identify Architectural Approaches	架构风格和设计策略	识别 RAG、fine-tune、model routing、agent workflow、rules、HITL、policy engine、logging strategy	Architectural approach catalog
Generate Utility Tree	质量属性优先级	结合 NIST AI RMF 和金融场景建立 AI utility tree	AI utility tree
Analyze Approaches	场景驱动分析	用 eval、threat model、data lineage、cost model、SLO 和 red-team 证据分析	Scenario analysis worksheet
Brainstorm and Prioritize Scenarios	stakeholder 场景补充	让 Compliance、Model Risk、Security、Ops、Data Owner、Frontline user 共同补充失败场景	Prioritized scenario backlog
Analyze High-Priority Scenarios	深入风险、敏感点、权衡点	输出 tradeoff point、sensitivity point、risk、non-risk、risk theme、mitigation、ADR candidate	Tradeoff / sensitivity / risk log
Present Results	汇报风险和建议	形成 go / limited go / no-go、ADR、eval gate、release condition、monitoring trigger	AI ATAM final report

6.2 AI ATAM 参与角色

角色	评审中必须贡献什么	不能只做什么
Business Owner	业务目标、风险偏好、客户影响、可接受人工成本	只说“要提效”
AI PM / Senior BA	use case 边界、流程插入点、质量属性场景、上线范围	只写功能列表
Solution / Enterprise Architect	架构视图、组件关系、关键决策、演进路径	只画一张 C4 图
ML / AI Engineer	模型、prompt、RAG、agent、eval 可行性和实验结果	只给 benchmark
Data Owner	数据源、血缘、权限、freshness、数据质量 SLO	只确认“能取到数据”
Security	threat model、prompt injection、tool abuse、logging 和 access control	只做上线前扫描
Privacy	数据最小化、保留、脱敏、跨境、第三方处理	只审批隐私声明
Model Risk / Validation	risk tier、independent challenge、validation scope、issue severity	只看模型分数
Compliance / Legal	监管敏感点、禁止用途、披露、客户权益、审查证据	只在最后签字
Ops / Frontline SME	真实工作流、异常、人工复核能力、使用行为	只参加 UAT
Internal Audit	证据可追溯性、控制可测试性、职责分离	只在事后抽查

6.3 AI ATAM 输入材料

输入	最低要求
Use case card	业务目标、用户、流程节点、AI 作用边界、禁止用途、risk tier
Architecture views	Context、container、data flow、model/RAG/tool view、runtime view、control view、evidence view
Quality attribute scenarios	覆盖高风险和高价值场景, 每个场景有 response measure
AI component inventory	model、prompt、embedding、index、retriever、reranker、tools、judge、guardrails、vendor
Eval evidence	dataset card、eval run、error analysis、red-team、human review、production sample strategy
Data evidence	lineage、quality SLO、access policy、retention、freshness、source owner
Risk evidence	threat model、privacy review、model risk assessment、compliance mapping
Operations evidence	SLO、monitoring、incident runbook、rollback、fallback、cost model

6.4 AI ATAM 输出材料

输出	用途
Utility tree	把质量属性从口号转成优先级和场景
Scenario analysis log	记录每个高优先级场景的架构响应和证据
Sensitivity point log	识别微小变化会显著影响质量的设计变量
Tradeoff point log	识别同时影响多个质量属性且方向冲突的决策点
Risk / non-risk log	区分已缓解风险、残余风险和当前可接受假设
Risk theme	汇总跨场景系统性风险, 如 “RAG freshness governance weak”
ADR backlog	把关键权衡转成可追溯架构决策
Eval gate update	把质量属性场景转成上线门禁和回归套件
Monitoring trigger	把上线后复审条件接入生产监控

7. Utility Tree 模板

Utility tree 是 AI ATAM 的核心工作产品。它把抽象质量属性拆成可评估场景, 并用业务重要性和实现/风险难度排序。

7.1 评分规则

维度	评分	含义
Business Importance	H / M / L	该场景对业务目标、客户权益、监管风险或运营目标的重要程度
Architecture Difficulty	H / M / L	当前架构实现该场景的难度、不确定性或风险
Evidence Strength	Strong / Partial / Weak	现有证据是否足以支持判断
Review Priority	P1 / P2 / P3	P1 必须在 release gate 前关闭或正式接受残余风险

7.2 通用模板

Utility
├── Output Quality
│   ├── Correctness
│   │   └── [Scenario ID] [BI=?, AD=?, Evidence=?] ...
│   ├── Groundedness
│   │   └── [Scenario ID] ...
│   └── Consistency
│       └── [Scenario ID] ...
├── Safety and Risk
│   ├── Privacy
│   ├── Security / Prompt Injection Resistance
│   ├── Fairness
│   └── Harm Avoidance
├── Human and Control
│   ├── Human Oversight Effectiveness
│   ├── Controllability
│   └── Contestability
├── Operations
│   ├── Availability
│   ├── Latency
│   ├── Cost Efficiency
│   └── Observability
├── Data and Knowledge
│   ├── Freshness
│   ├── Access Correctness
│   └── Lineage
└── Evolution and Governance
    ├── Modifiability
    ├── Vendor Exit
    └── Auditability

7.3 Utility Tree 工作表

Level 1	Level 2	Scenario ID	Scenario 简述	BI	AD	Evidence	Priority	评审结论
Output Quality	Groundedness	`QA-RAG-GROUND-001`	对高风险政策问题, 答案必须由 approved source 支持, unsupported claim 为 0	H	H	Partial	P1	需要 citation audit 和 no-evidence refusal eval
Safety and Risk	Security	`QA-AGENT-SEC-001`	遇到 prompt injection 要求泄露系统提示或越权查询时, agent 必须拒绝并记录事件	H	H	Weak	P1	需要 red-team 和 tool permission test
Operations	Latency	`QA-CS-LAT-001`	客服高峰期 p95 响应小于 2.5 秒, 超时自动降级到 policy search	H	M	Strong	P2	当前架构可接受, 需生产 SLO
Data and Knowledge	Freshness	`QA-KB-FRESH-001`	政策生效后 24 小时内进入索引, 旧版本不可被默认引用	H	H	Partial	P1	需要 index release gate 和 stale citation monitoring
Governance	Auditability	`QA-AUDIT-001`	任一客户影响输出可重放 prompt、retrieval context、model version、tool trace 和 reviewer decision	H	M	Partial	P1	需日志字段和保留策略 ADR

7.4 Utility Tree 评审纪律

每个 P1 scenario 必须连接到 eval、ADR 或 risk acceptance, 不能只留在会议记录。
Business Importance 高但 Architecture Difficulty 高的场景, 是架构评审的主战场。
Evidence Weak 的高风险场景不能用“上线后观察”替代上线前门禁。
Utility tree 不是一次性产物, 模型升级、知识库刷新、工具权限扩大、市场扩展、监管变化后必须复审。

8. Sensitivity / Tradeoff / Risk 分析

ATAM 的价值在于发现架构选择背后的敏感点、权衡点和风险。AI 系统尤其需要把这些点显式化。

8.1 Sensitivity Point

Sensitivity point 指某个架构参数或设计选择的小变化会显著影响质量属性。

Sensitivity Point	影响属性	为什么敏感	需要的证据
top-k retrieval 数量	Groundedness、latency、cost	top-k 太低漏证据, 太高增加噪声和延迟	retrieval recall@k、citation accuracy、latency test
chunk size / overlap	Completeness、citation accuracy、cost	条款切断会造成错误引用, 过大降低检索精度	chunking experiment、SME citation audit
model temperature	Consistency、creativity、safety	温度变化影响稳定性和格式遵守	multi-run variance eval
confidence threshold	Automation、human workload、risk	阈值过低放过风险, 过高造成大量人工队列	precision/recall、queue simulation
model routing rule	Cost、accuracy、latency、fairness	错误路由让复杂案例走弱模型	slice eval、routing confusion matrix
knowledge freshness SLA	Compliance、correctness、stability	过期政策会引发错误承诺, 高频刷新会引发回归	index release test、stale citation monitoring
logging granularity	Auditability、privacy、cost	日志不足无法复现, 日志过细增加敏感数据风险	trace completeness test、privacy review
tool permission scope	Automation value、security、controllability	权限扩大后错误和攻击影响升级	threat model、tool abuse test、approval workflow

8.2 Tradeoff Point

Tradeoff point 指某个决策同时影响多个质量属性, 且无法同时最大化。

Tradeoff Point	方案 A	方案 B	受益属性	受损属性	推荐治理方式
客服回答路径	单模型直接回答	RAG + citation check	A 提升延迟和成本; B 提升 groundedness 和 auditability	A 损害证据和合规; B 增加延迟	低风险 FAQ 走快路径, 政策/费用/投诉走 RAG 强路径
AML 处理自动化	Copilot draft-only	Agent 自动更新 case fields	B 提升操作效率	B 增加越权、错误写入、审计和监管风险	pilot 阶段 draft-only, 写操作必须 human approval + idempotency
信贷模型解释	黑盒模型提升预测力	可解释模型/规则约束	A 提升预测性能; B 提升 explainability 和 contestability	A 增加模型风险和申诉难度; B 可能降低预测力	高影响决策保留可解释 reason code, 黑盒仅作辅助特征或 challenger
投顾个性化	深度个性化推荐	限制在教育和 suitability-gated 建议	A 提升转化和体验	A 增加不适当建议和监管风险	未完成 suitability 前只允许教育性内容, 推荐必须绑定客户画像和披露
生产日志	全量 prompt/context 保存	最小化脱敏日志	A 提升可复现和审计	A 增加隐私和数据保留风险	分级日志、敏感字段脱敏、break-glass 访问和保留期限

8.3 Risk / Non-Risk

类型	定义	示例	处理方式
Risk	当前架构可能无法满足质量属性场景, 且证据不足或控制不足	RAG 对过期政策无 stale citation detection	必须缓解、限制上线或风险接受
Non-risk	已有架构机制和证据足以满足场景	客服低风险 FAQ p95 延迟有压测证据, 且有 fallback	记录证据和监控条件
Sensitivity Point	参数变化会显著影响质量	confidence threshold、top-k、temperature	记录实验范围和变更门禁
Tradeoff Point	架构决策在质量属性之间形成冲突	成本路由 vs 高风险准确性	用 ADR 记录选择和后果
Risk Theme	多个风险指向同一系统性问题	“知识库发布治理不足”影响 AML、客服、信贷	升级为平台能力或治理改进项

9. 金融零售案例

9.1 AML Copilot

项目	内容
AI 作用边界	汇总 alert、交易模式、KYC profile、历史 case notes; 生成 investigation summary、red flag checklist、SAR draft
禁止用途	自动关闭 alert、自动提交 SAR、绕过 analyst disposition、把 draft 当监管事实
高优先级质量属性	Groundedness、auditability、human oversight、privacy、security、data lineage
关键 tradeoff	自动化效率 vs regulatory defensibility; 证据完整性 vs 处理速度; 日志完整性 vs 隐私最小化
P1 scenario	高风险 alert 中, Copilot summary 必须覆盖关键 red flags, 每个重大结论引用 case evidence, 不得生成无证据 SAR narrative
Sensitivity point	evidence retrieval recall、case note freshness、SAR draft prompt、analyst confidence UI
Risk	引用错误交易或 KYC 信息导致 SAR narrative 失真; analyst 过度采纳 AI 草稿
Controls	draft-only、mandatory analyst approval、citation audit、reviewer edit diff、red-team、case replay、model/prompt/index version log
Eval gate	high-risk unsupported allegation = 0; critical red flag omission = 0; citation support >= 97%; analyst override reviewed weekly
ADR candidates	`ADR-AML-001-draft-only-boundary`; `ADR-AML-002-case-evidence-retention`; `ADR-AML-003-high-risk-review-gate`

9.2 Customer Service Copilot

项目	内容
AI 作用边界	为坐席生成政策答案、下一步建议、话术草稿、case summary, 支持投诉和升级
禁止用途	自动承诺费用减免、自动发送客户可见回复、绕过投诉升级规则
高优先级质量属性	Latency、policy compliance、groundedness、consistency、tone safety、fallback、observability
关键 tradeoff	AHT 降低 vs policy compliance; 快速回答 vs 引用检查; 个性化语气 vs 一致承诺
P1 scenario	对 fee waiver、投诉、欺诈相关问题, 系统必须检索 approved policy, 引用支持结论, 冲突证据时升级人工
Sensitivity point	routing risk tier、policy index freshness、answer length、citation check threshold
Risk	坐席按 AI 草稿向客户做出错误承诺; policy 更新后旧答案继续被引用
Controls	high-risk intent classifier、policy-only RAG、stale policy blocker、SME escalation、weekly production sample
Eval gate	unsupported customer promise = 0; p95 latency <= 2.5s for low-risk; high-risk under-escalation = 0
ADR candidates	`ADR-CS-001-risk-tier-routing`; `ADR-CS-002-policy-citation-required`; `ADR-CS-003-fallback-to-search`

9.3 Credit / Lending AI

项目	内容
AI 作用边界	政策查询、underwriter copilot、文档摘要、reason code draft、申请资料 completeness check
禁止用途	未经批准自动批准/拒绝贷款; 生成无法解释或无法申诉的客户影响决策; 使用未授权数据
高优先级质量属性	Fairness、explainability、contestability、data lineage、model risk validation、auditability
关键 tradeoff	预测性能 vs 可解释性; 自动化效率 vs 客户申诉权; 替代数据价值 vs 隐私和公平风险
P1 scenario	对 decline reason draft, 系统必须基于 approved policy 和可解释特征生成, 不得引入受保护属性或不可用代理变量
Sensitivity point	feature inclusion policy、reason code mapping、threshold、human override process
Risk	LLM 生成与实际决策依据不一致的 adverse action explanation; 模型在特定客群切片性能显著退化
Controls	model inventory、independent validation、reason code rules、fairness slice eval、human final decision、appeal evidence retention
Eval gate	prohibited factor reference = 0; reason-code mismatch = 0; slice performance gap reviewed by Model Risk
ADR candidates	`ADR-CREDIT-001-llm-as-explanation-draft-only`; `ADR-CREDIT-002-feature-governance`; `ADR-CREDIT-003-validation-gate`

9.4 Wealth / Advisory Assistant

项目	内容
AI 作用边界	客户教育、产品资料检索、advisor copilot、风险揭示摘要、portfolio discussion preparation
禁止用途	对未完成 suitability / KYC / risk profile 的客户给出个性化推荐; 承诺收益; 绕过持牌顾问
高优先级质量属性	Suitability、groundedness、risk disclosure、human oversight、auditability、customer trust calibration
关键 tradeoff	个性化体验 vs suitability control; 解释简洁 vs 风险披露完整; advisor productivity vs 监管可证明性
P1 scenario	当客户要求“推荐一个高收益低风险产品”时, assistant 必须拒绝收益承诺, 检查 suitability 状态, 提供教育性解释并提示顾问复核
Sensitivity point	customer profile freshness、product metadata quality、risk disclosure prompt、advisor approval workflow
Risk	AI 输出被客户视为正式投资建议; 产品风险等级或费用披露遗漏
Controls	suitability gate、product catalog source of truth、advisor approval、disclosure checklist、conversation audit
Eval gate	unauthorized recommendation = 0; missing required disclosure = 0; hallucinated product feature = 0
ADR candidates	`ADR-WEALTH-001-suitability-gated-advice`; `ADR-WEALTH-002-product-source-of-truth`; `ADR-WEALTH-003-advisor-approval`

10. Tradeoff Matrix

10.1 通用 AI 架构权衡矩阵

决策维度	选项	优势	代价	适合场景	不适合场景	必备证据
RAG vs Fine-tune	RAG	知识可更新、可引用、便于权限控制	检索链路复杂、延迟增加、召回失败	政策、流程、产品资料、监管解释	需要稳定风格或隐含能力迁移但知识不变	retrieval eval、citation audit、freshness test
RAG vs Fine-tune	Fine-tune	可提升特定任务格式和风格稳定性	数据治理、重训成本、知识更新慢	分类、抽取、固定格式生成	高频变更政策、需要逐条引用	training data card、regression eval
Agent vs Workflow	Agent	动态规划、跨工具任务能力强	可控性、安全和可测试性更难	低风险内部任务、明确工具边界	客户权益、资金、信贷、AML disposition	tool test、red-team、approval logs
Agent vs Workflow	Deterministic workflow + LLM steps	可控、可审计、易门禁	灵活性低、对复杂任务适应慢	金融零售高风险流程	开放式探索任务	workflow test、state machine review
Model routing	Single strong model	质量稳定、实现简单	成本高、供应商集中	pilot、高风险案例	大规模低风险 FAQ	eval baseline、cost model
Model routing	Risk-tiered routing	成本优化、可分级控制	路由错误会放大风险	客服、知识查询、内部 copilot	风险分类不稳定的场景	routing eval、slice analysis
HITL	Mandatory review	风险控制强、审计友好	成本高、延迟大、人工队列瓶颈	AML、信贷、投顾、投诉	低风险高频 FAQ	review capacity model、sample audit
HITL	Exception-based review	效率更高	阈值错误会漏掉风险	中风险运营辅助	高影响自动化决策	confidence calibration、override analysis
Logging	Full trace	可复现、可审计、利于调试	隐私、保留、访问控制压力	内部高风险 pilot	高敏感客户自由文本无脱敏	retention matrix、access control
Logging	Minimized trace	降低数据风险	复盘和审计能力弱	低风险场景或强隐私约束	监管敏感输出	replay test、evidence sufficiency review

10.2 金融零售优先级矩阵

用例	质量属性优先级	可牺牲项	不可牺牲项	典型上线策略
AML Copilot	Auditability > Groundedness > Human oversight > Latency	生成速度、自动化深度	证据引用、analyst 最终责任、case trace	draft-only pilot, high-risk mandatory review
客服 Copilot	Policy compliance > Latency > Consistency > Observability	开放式生成能力	错误承诺、投诉升级、policy freshness	risk-tier routing, low-risk fast path, high-risk citation path
信贷 Policy / Underwriting Copilot	Fairness > Explainability > Data lineage > Accuracy	黑盒性能最大化	reason code 一致性、禁止变量、客户申诉证据	narrow scope, independent validation, release condition
财富 / 投顾 Assistant	Suitability > Disclosure > Groundedness > Trust calibration	个性化强度和营销转化	未授权建议、收益承诺、产品事实准确性	education-first, advisor approval, suitability gate

11. ADR / Eval 连接

AI ATAM 不能停在白板讨论。高优先级权衡必须转成 ADR, 高风险质量属性必须转成 eval gate。

11.1 从 Scenario 到 ADR

Scenario 发现	ADR 问题	ADR 必须记录
RAG 引用检查增加延迟, 但降低错误承诺	是否对高风险问题强制 citation check?	适用范围、风险分级、延迟代价、fallback、eval 结果、残余风险
Agent 写权限提高效率, 但错误操作影响客户账户	是否允许 agent 执行写操作?	tool allowlist、审批、限额、幂等、审计、回滚、red-team
全量日志支持审计, 但包含敏感数据	prompt/context/tool trace 保存什么?	字段、脱敏、访问控制、保留期、break-glass、隐私评审
低成本模型可处理多数请求, 但复杂场景错误率高	是否采用 risk-tiered model routing?	路由规则、错误路由风险、切片评估、成本节省、监控
高频知识刷新提升时效, 但增加回归	知识库如何发布和回滚?	source owner、index version、freshness SLA、eval gate、stale blocker

11.2 从 Scenario 到 Eval Contract

Quality Attribute	Eval 问题	Dataset	Evaluator	Gate
Groundedness	答案是否被证据支持?	golden set + no-answer set + conflicting policy set	citation support checker + SME audit	unsupported high-risk claim = 0
Fairness	不同切片是否有不可接受差异?	historical cases with approved attributes / proxy analysis	statistical slice analysis + Model Risk review	material gap requires remediation or risk acceptance
Security	prompt injection 是否能越权?	red-team set + tool abuse scenarios	deterministic policy check + security review	unauthorized tool call = 0
Latency	高峰期是否满足流程需求?	load profile + production-like traffic	load test + trace metrics	p95/p99 threshold by channel
Auditability	输出是否可重放?	sampled production traces	replay test + evidence checklist	trace completeness >= threshold; critical fields missing = 0

11.3 ADR 模板片段

## ADR-AI-[DOMAIN]-[NUMBER]: [Decision Title]

Status: Proposed / Accepted / Conditionally Accepted / Superseded
Date: YYYY-MM-DD
Scope: [use case, user group, channel, region, model/prompt/index/tool version]

### Context
- Business driver:
- Quality attribute scenarios:
- Risk tier:
- Constraints:

### Decision
- We will:
- We will not:

### Options Considered
| Option | Benefits | Costs | Risks | Evidence |
|---|---|---|---|---|

### Tradeoffs
- Quality attributes improved:
- Quality attributes weakened:
- Sensitivity points:

### Evidence
- Eval run:
- Red-team:
- Data lineage:
- Security/privacy review:
- Cost/latency test:

### Consequences
- Operational impact:
- Monitoring trigger:
- Reversal condition:
- Residual risk owner:

11.4 Release Gate 连接

Quality attribute scenario
-> eval contract
-> eval run and error analysis
-> ATAM risk / tradeoff log
-> ADR decision
-> release gate condition
-> monitoring trigger
-> production sample review
-> ADR reopen if assumptions break

12. AI ATAM 评审清单

12.1 Discovery Gate

检查项	合格标准
Use case 边界	明确 AI 做 draft、retrieve、classify、recommend、execute 中哪一种, 并写出禁止用途
Stakeholder concerns	至少覆盖业务、客户、前线用户、Risk、Compliance、Security、Privacy、Data Owner、Ops
Risk tier	说明客户影响、自动化程度、数据敏感性、监管敏感性和可逆性
初始质量属性	已选出 5-8 个最重要质量属性, 并有初版 scenario
No-AI baseline	说明没有 AI 或规则/搜索/流程优化方案的效果和代价

12.2 Architecture Review Gate

检查项	合格标准
Architecture views	至少有 context、runtime、data flow、AI component、control、observability view
Utility tree	P1/P2 场景完成优先级排序, 质量属性有 response measure
Architectural approaches	RAG、fine-tune、rules、agent、HITL、guardrail、model routing 等方案有取舍说明
Sensitivity points	关键参数和阈值已登记, 有实验或验证计划
Tradeoff points	冲突质量属性已形成 ADR candidate
Risk log	风险、非风险、风险主题、残余风险 owner 清楚

12.3 Eval Gate

检查项	合格标准
Dataset coverage	覆盖常规、边界、高风险、无答案、冲突证据、攻击和历史失败案例
Evaluator calibration	LLM judge 不单独决定高风险门禁, 有专家校准或抽样复核
Critical failure	对客户权益、监管、安全、隐私类 critical failure 设置硬门槛
Slice analysis	对客户类型、渠道、产品、语言、地区、风险等级做切片分析
Error analysis	不只给平均分, 还解释失败模式、严重度、根因和修复计划

12.4 Release Gate

检查项	合格标准
ADR accepted	P1 tradeoff 决策已记录并批准
Residual risk	残余风险 owner、到期日、触发条件和补偿控制明确
Monitoring	质量、安全、成本、延迟、漂移、人工复核、投诉/申诉指标已上线
Fallback / rollback	模型降级、RAG index 回滚、tool disable、kill switch 经过演练
Evidence binder	能追溯到版本、eval、审批、日志、风险接受和上线范围

12.5 Post-Release Review

检查项	合格标准
Production sample	定期抽样真实 trace, 进入 human review 或 judge screening
Drift	数据、知识、prompt、模型、用户行为和成本漂移有阈值
Incident loop	事故样本进入 eval dataset 和回归测试
ADR reopen	触发条件发生时重新评审, 不把旧决策永久化
Business value	价值指标与风险指标一起看, 不用效率收益掩盖控制失败

13. 反模式

反模式	表现	风险	修正方式
把 accuracy 当唯一质量属性	只报一个平均准确率	掩盖安全、隐私、公平、审计和可运营性失败	建立 utility tree 和 critical failure gate
把 HITL 当万能控制	文档写有人复核, 实际 reviewer 看不到证据或没有时间	人工监督失效, 责任转移给一线员工	定义 review task、capacity、sample audit、override metrics
RAG 被当作防幻觉保证	有检索就认为不会编造	检索错误、引用不支持、过期文档造成错误结论	做 retrieval eval、citation audit、stale source monitoring
Agent 权限扩张无 ADR	从 read-only 逐渐变成 write/execute	越权、重复执行、错误写入、审计缺口	每个写权限必须有 tool ADR、approval、limit、rollback
平均分掩盖严重失败	总分提高, 但 high-risk case 出现 critical miss	小概率高损失风险被忽略	critical failure 单独作为 hard stop
只在上线前评审	模型、prompt、知识库变了但不复审	旧证据不再支持新系统	设定 ADR reopen trigger 和 continuous eval
评审只有技术团队	Risk、Compliance、Data、Ops、frontline 缺席	stakeholder concerns 不完整	按 ISO 42010 思路组织 concerns 和 viewpoints
日志越多越好	全量保存敏感 prompt/context	隐私、保留、访问和泄露风险	最小化、脱敏、分级访问、保留期和 replay sufficiency 平衡
成本优化先行	低成本模型覆盖高风险场景	质量和风险不可接受	risk-tiered routing + slice eval + fallback
ADR 与 eval 脱节	决策说通过评估, 但找不到 eval run	审计不可追溯, 决策不可挑战	ADR 必须链接 eval report、dataset version、gate memo

14. 30 天训练计划

目标: 30 天内形成一套可展示的 AI ATAM 作品集, 覆盖质量属性、utility tree、tradeoff matrix、ADR、eval gate 和金融零售案例。

Day	主题	训练任务	产出
1	ATAM 方法校准	阅读 Source Anchors, 摘出 ATAM、AI RMF、42010 的共同语言	1 页方法摘要
2	AI quality taxonomy	为 AML、客服、信贷、投顾各列 8 个质量属性	taxonomy matrix
3	Stakeholder concerns	按 ISO 42010 思路列 stakeholder / concern / viewpoint	concern map
4	Scenario syntax	写 10 条 quality attribute scenario	scenario catalog v1
5	Response measure	为每条 scenario 加指标、阈值和失败严重度	scenario catalog v2
6	AML utility tree	建 AML Copilot utility tree	AML utility tree
7	AML tradeoff	分析 AML draft-only vs agent write 的权衡	AML tradeoff log
8	AML eval gate	把 AML P1 scenarios 转成 eval contract	AML eval gate
9	AML ADR	写 2 份 AML ADR	ADR-AML pack
10	客服 utility tree	建客服 Copilot utility tree	CS utility tree
11	客服 latency vs compliance	做 fast path / RAG path / escalation matrix	CS routing decision
12	客服 eval gate	设计 policy compliance 和 latency eval	CS eval contract
13	客服 ADR	写 policy citation 和 fallback ADR	ADR-CS pack
14	信贷 utility tree	建 Credit AI utility tree	Credit utility tree
15	信贷 fairness scenario	写 fairness、reason code、contestability scenarios	Credit scenario pack
16	信贷 tradeoff	分析 black-box performance vs explainability	Credit tradeoff matrix
17	信贷 eval gate	设计 slice analysis、reason-code consistency gate	Credit eval contract
18	信贷 ADR	写 LLM explanation draft-only ADR	ADR-Credit pack
19	财富 utility tree	建 Wealth Assistant utility tree	Wealth utility tree
20	投顾边界	设计 suitability-gated advice scenario	Wealth boundary scenario
21	财富 tradeoff	分析 personalization vs suitability control	Wealth tradeoff matrix
22	财富 eval gate	设计 unauthorized recommendation 和 disclosure eval	Wealth eval contract
23	横向 sensitivity	总结 top-k、threshold、routing、logging、tool permission 等敏感点	sensitivity catalog
24	横向 tradeoff	建通用 AI tradeoff matrix	enterprise tradeoff matrix
25	Risk theme	从四个案例提炼 5 个系统性风险主题	risk theme report
26	Evidence binder	建 ATAM evidence pack 目录结构	evidence binder outline
27	Review deck	做 8 页架构评审汇报	AI ATAM review deck
28	面试答案	准备 10 道高级面试题 30 秒/2 分钟答案	interview answer pack
29	作品集打磨	把四个案例整理成 portfolio narrative	portfolio case study
30	模拟评审	用 45 分钟讲一遍, 记录追问和改进	final AI ATAM pack

15. 面试答案

Q1: 你如何评审一个金融 AI 系统的架构质量?

30 秒版本:

我不会只看模型准确率, 而是用 AI ATAM。先明确业务驱动、风险等级和 stakeholder concerns, 再把质量属性写成可测试 scenario, 建 utility tree 排优先级, 对 RAG、agent、HITL、model routing、guardrail 等架构方案做 sensitivity、tradeoff 和 risk 分析。最后把 P1 权衡转成 ADR, 把高风险场景转成 eval gate 和生产监控。

2 分钟版本:

我的评审会分五步。第一, 定义 use case 边界和禁止用途, 例如 AML Copilot 是 draft-only 还是能更新 case disposition。第二, 建立 quality attribute taxonomy, 不只包括 accuracy, 还包括 groundedness、auditability、privacy、security、human oversight、latency、cost、fairness、modifiability。第三, 用 quality attribute scenario 写清楚 stimulus、environment、response 和 response measure, 比如 high-risk AML alert 必须引用 case evidence, unsupported allegation 为 0。第四, 建 utility tree, 按业务重要性和架构难度找 P1 场景, 分析 sensitivity point 和 tradeoff point。第五, 把结论接到 ADR、eval gate、release condition、monitoring trigger 和 residual risk owner。这样评审结果可以被工程、风险、合规和审计复核。

Q2: AI quality attribute scenario 和普通非功能需求有什么不同?

30 秒版本:

普通非功能需求常写成“系统要可靠、快速、安全”。AI quality attribute scenario 要写清楚谁触发、在什么环境、哪个 AI artifact 受影响、系统如何响应、用什么指标验证、失败严重度是什么, 以及用哪个 eval 或生产监控证明。

2 分钟版本:

AI 系统的不确定性更强, 所以质量属性必须场景化。例如“客服 AI 要合规”太弱。我会改写成: 在高峰期, 当坐席询问 fee waiver policy 且客户有投诉历史时, 系统必须检索 approved policy, 在 2.5 秒内返回带引用草稿; 如果证据冲突或属于高风险投诉, 必须升级人工; unsupported promise 为 0, high-risk under-escalation 为 0。这个 scenario 可以直接连接 RAG eval、citation audit、latency test 和 release gate。

Q3: 你如何解释 sensitivity point 和 tradeoff point?

30 秒版本:

Sensitivity point 是一个参数小变化会显著影响质量, 比如 top-k、confidence threshold、tool permission。Tradeoff point 是一个架构决策同时改善某些质量属性并伤害另一些, 比如全量日志提升审计但增加隐私风险。

2 分钟版本:

在 AI ATAM 中, sensitivity point 帮我找到必须受控的设计变量。比如 RAG top-k 太低会漏掉政策证据, 太高会引入噪声和延迟, 所以它需要 retrieval eval 和变更门禁。Tradeoff point 则需要 ADR, 因为它涉及价值判断。比如客服 Copilot 要不要强制 citation check: 强制后 groundedness 和 auditability 提升, 但 latency 和成本变差。我的处理不是抽象争论, 而是按风险分层: 低风险 FAQ 走快路径, 费用、投诉、欺诈等高风险问题走 RAG citation 强路径, 并设置 fallback 和监控。

Q4: RAG、fine-tune、agent 和 HITL 如何放进同一个评审框架?

30 秒版本:

我把它们都视为 architectural approaches, 而不是孤立技术选型。每个 approach 都要回答它改善哪些质量属性、伤害哪些质量属性、敏感参数是什么、需要什么 eval 证据、残余风险谁接受。

2 分钟版本:

例如金融政策问答中, RAG 改善 knowledge freshness 和 auditability, 但增加 latency 和 retrieval failure 风险; fine-tune 改善格式和风格稳定性, 但不适合高频更新政策; agent 改善跨系统操作效率, 但引入 tool abuse、幂等和回滚问题; HITL 改善客户保护和监管可证明性, 但增加成本和队列延迟。AI ATAM 会把这些方案放进 utility tree 和 tradeoff matrix, 最终用 ADR 记录采用组合, 用 eval gate 证明质量门槛, 用监控触发复审。

Q5: 金融零售 AI 中哪些质量属性最容易被低估?

30 秒版本:

最容易被低估的是 groundedness、auditability、human oversight effectiveness、data freshness、contestability 和 controllability。团队常关注准确率和成本, 但事故往往来自证据不支持、人工监督失效、过期政策、无法复现和无法回滚。

2 分钟版本:

以 AML 为例, 生成得流畅没有意义, 如果 narrative 无证据或引用错误 case data, 风险更高。以信贷为例, 模型表现提高也不够, 还要解释、申诉、公平切片和模型风险验证。以客服为例, 降低 AHT 不能以错误政策承诺为代价。以投顾为例, 个性化推荐必须受 suitability gate 限制。所以我会把这些属性前置到 utility tree, 并设置 critical failure hard stop。

Q6: 评审后如何确保结论不会停留在 PPT?

30 秒版本:

我会把 ATAM 输出落到四个系统: ADR 记录权衡决策, eval contract 记录验证门槛, release gate 记录上线条件和残余风险, monitoring trigger 记录何时复审或回滚。

2 分钟版本:

我的做法是建立 traceability: quality attribute scenario 连接 eval dataset 和 evaluator; tradeoff point 连接 ADR; risk 连接 risk owner 和 mitigation; non-risk 连接证据和监控; release gate 连接上线范围、版本和审批。上线后, production trace、incident、drift、cost、human override 和投诉样本会进入 continuous eval。如果模型、prompt、RAG index、tool schema 或业务范围变化, 对应 ADR 必须 reopen。

16. 作品集交付物

16.1 最小作品集包

交付物	内容	展示价值
AI ATAM One-Pager	方法定位、输入输出、角色、流程	说明你能主持高级架构评审
Quality Attribute Taxonomy	金融零售 AI 质量属性分类和指标	说明你能把 AI 风险转成工程语言
Scenario Catalog	20-30 条 AML、客服、信贷、投顾 scenario	说明你能写可验证的高级需求
Utility Trees	4 个场景 utility tree	说明你能排序质量属性和评审重点
Tradeoff Matrix	通用矩阵 + 场景矩阵	说明你能做架构权衡而非单点选型
ADR Pack	每个场景 2-3 份关键 ADR	说明你能记录决策、证据和后果
Eval Gate Pack	每个场景的 eval contract 和 release gate	说明你能把架构质量接到测试与上线
Risk Register	risk、non-risk、sensitivity、tradeoff、risk theme	说明你能做有效挑战和残余风险治理
Review Deck	8-12 页高管/架构委员会汇报	说明你能向 CTO、CRO、产品和合规沟通

16.2 文件结构建议

portfolio/ai-atam-quality-architecture/
├── 00-ai-atam-one-pager.md
├── 01-quality-attribute-taxonomy.md
├── 02-scenario-catalog.md
├── 03-aml-copilot-utility-tree.md
├── 04-customer-service-copilot-utility-tree.md
├── 05-credit-ai-utility-tree.md
├── 06-wealth-advisory-assistant-utility-tree.md
├── 07-tradeoff-matrix.md
├── 08-adr-pack.md
├── 09-eval-gate-pack.md
├── 10-risk-register.md
└── 11-review-deck-outline.md

16.3 面试展示叙事

我用 AI ATAM 做了四个金融零售场景的架构质量评审: AML、客服、信贷和财富投顾。我的核心方法是把质量属性写成可验证 scenario, 建 utility tree 找 P1 风险, 用 tradeoff matrix 分析 RAG、agent、HITL、model routing、logging 等架构选择, 再把结论落到 ADR、eval gate 和 release monitoring。这个作品集展示的是我不只会定义 AI 产品, 还能把 AI 系统推到可审查、可治理、可上线、可持续运营的架构状态。

17. 最终检查表

在提交任何高影响 AI 架构评审前, 用这张表做最后自检:

问题	合格答案
是否有明确 Source Anchors?	ATAM、AI RMF、42010 的方法语言已被转成评审产物
是否有 One-Sentence Positioning?	能一句话解释 AI ATAM 的价值
是否有 taxonomy?	覆盖输出质量、安全风险、控制、运行、数据、演进和治理
是否有 quality attribute scenarios?	每条有 stimulus、environment、response、response measure 和 eval method
是否有 utility tree?	P1/P2 场景按业务重要性和架构难度排序
是否有 sensitivity / tradeoff / risk?	参数敏感点、架构权衡点、风险和非风险被区分
是否覆盖金融零售案例?	AML、客服、信贷、财富/投顾都有场景化分析
是否连接 ADR?	关键权衡被记录为可追溯决策
是否连接 eval?	高风险质量属性进入 eval contract 和 release gate
是否连接运营?	监控、回滚、复审触发器和残余风险 owner 明确
是否避免基础 BA 化?	文档聚焦高级 AI 产品、架构、质量属性和权衡治理

18. 结论

AI 架构质量不是模型供应商、benchmark 或 demo 效果能单独证明的。它必须通过 stakeholder concerns、quality attribute scenarios、utility tree、tradeoff analysis、ADR、eval gate、release condition 和 production monitoring 共同证明。

对金融零售 AI, 最成熟的表达不是“我们用了先进模型”, 而是:

我们知道哪些质量属性最重要, 知道哪些架构选择会互相牵制, 知道哪些参数最敏感, 知道哪些风险仍然存在, 知道用什么证据放行, 也知道什么条件下必须暂停、回滚或重新评审。