AI 底层逻辑 / 经典论文

AI Architecture Views：C4 / arc42 / 42010

一句话:

445 行ai-foundations/papers/87-ai-architecture-views-c4-arc42-42010.md

AI Architecture Views / C4 / arc42 / 42010 解读

面向对象: AI Solutions Architect / Enterprise Architect / AI Product Architect / Platform PM / Senior BA。核心问题: 企业 AI 架构不能只靠一张“模型 + RAG + 工具”的大图。真正能进入评审、融资、审计和交付的架构表达, 必须面向不同 stakeholder 的 concern, 用多视图说明业务价值、系统边界、运行时行为、控制证据和演进策略。学习目标: 用 C4、arc42、ISO/IEC/IEEE 42010 的思路, 为 AI 产品建立可沟通、可评审、可追踪、可复用的 architecture view system。

Source Anchors

Source	Link	用途
C4 Model	https://c4model.com/	参考 context、container、component、code 四层架构表达, 将 AI 系统从企业边界到内部组件逐层展开
arc42	https://arc42.org/	参考结构化软件架构文档模板, 把需求、约束、上下文、构件、运行时、部署、质量和风险组织成文档
ISO/IEC/IEEE 42010	https://www.iso.org/standard/74393.html	参考 architecture description、stakeholder、concern、viewpoint、view 的概念关系
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	把 AI 架构视图连接到风险、治理、测量、监控和管理活动
OpenTelemetry	https://opentelemetry.io/docs/	为运行时视图、trace、metrics、logs、SLO 和证据链提供观测锚点

一句话:

AI Architecture Views 是把同一个 AI 系统按 stakeholder concern 拆成一组互相一致的视图: 给业务看价值流, 给工程看边界和依赖, 给风险看控制, 给平台看复用, 给审计看证据。

1. 为什么 AI 架构表达不能只有一张大图

很多 AI POC 的架构图看起来类似:

User -> UI -> LLM -> RAG -> Tools -> Backend

这张图能解释“系统大概怎么跑”, 但无法回答高级评审会真正关心的问题:

Stakeholder	真正关心的问题	单一大图的缺口
Business sponsor	为什么这个 AI capability 值得投资, 与流程收益如何连接	看不出 value stream、收益假设、采用路径
Product lead	MVP 边界、用户旅程、人工交接、失败体验是什么	看不出体验和运营设计
Solution architect	哪些组件可复用, 哪些是业务差异, 哪些接口需要契约	看不出 container/component 边界
Data owner	知识源、权限、freshness、数据血缘如何治理	看不出 data/knowledge view
Risk / compliance	哪些输出有风险, 控制在哪里执行, 谁复核	看不出 control view
Security	Prompt injection、tool misuse、data leakage 如何防	看不出 threat boundary 和 policy enforcement
Model risk / QA	怎么评测, 评测样本覆盖哪些需求和风险	看不出 eval view
Operations	线上如何监控、回滚、响应 incident	看不出 runtime observability
Audit	发布依据、批准记录、变更证据在哪里	看不出 evidence view

AI 架构表达的核心不是画更多漂亮图, 而是建立一个 viewpoint system:

Stakeholder concern
  -> viewpoint
  -> view
  -> model element
  -> decision / control / evidence

你的价值在于能把复杂 AI 系统翻译成不同人能决策的语言, 并保证这些视图不互相矛盾。

2. 42010 视角: Stakeholder, Concern, Viewpoint, View

ISO/IEC/IEEE 42010 的关键启发是: 架构描述不是一份万能文档, 而是围绕 stakeholder 和 concern 组织的 view 集合。

Concept	AI 架构中的解释
Stakeholder	业务 owner、用户、平台团队、数据 owner、模型风险、合规、审计、运维、开发团队
Concern	价值、体验、准确性、安全、隐私、可解释、成本、延迟、可审计、可恢复、可扩展
Viewpoint	用什么视角和规则表达 concern, 如 C4 context、runtime sequence、control evidence view
View	按 viewpoint 生成的具体图、表、矩阵或文档
Architecture description	这些 view 加上 ADR、约束、假设、风险、证据的整体集合

AI 系统可以建立如下 viewpoint catalog:

Viewpoint	主要 stakeholder	回答的问题	常见 artifact
Business Capability View	Sponsor、EA、Product	AI 支撑哪些能力和价值流	capability map、value stream map
Product Journey View	Product、Ops、Risk	用户如何使用、失败如何交接	service blueprint、journey map
C4 Context View	Business、Security、EA	系统边界、外部人和系统是谁	C4 context diagram
C4 Container View	Architect、Engineering	主要应用、服务、数据 store、网关如何协作	container diagram
C4 Component View	Engineering、Platform	编排、retrieval、tool、eval、policy 的组件边界	component diagram
Runtime / Sequence View	Engineering、Ops、Risk	一次请求如何流过模型、检索、工具、审批	sequence diagram
Data / Knowledge View	Data owner、Privacy、Risk	知识源、权限、lineage、freshness、retention	data flow、knowledge lineage
Tool / Action View	Security、Ops、Product	AI 能执行哪些动作, 如何审批和审计	tool contract map、side-effect matrix
Eval / Quality View	QA、Model Risk、Product	需求如何转成评测, 上线门槛是什么	eval contract、quality gate
Control / Evidence View	Compliance、Audit、Risk	控制在哪里, 证据如何产生和保存	control-evidence graph
Deployment / SLO View	Ops、Platform、FinOps	部署拓扑、延迟、成本、可用性和回滚	deployment diagram、SLO dashboard
Evolution View	EA、CTO、Platform PM	哪些能力会平台化、替换、退役	roadmap、ADR log

高级架构师不是把所有 concern 塞进一张图, 而是知道什么时候该拿出哪张 view。

3. C4 for AI Systems

C4 的强项是层级化表达。对 AI 系统, 重点不是机械套 context/container/component/code, 而是用每一层回答不同粒度的边界问题。

3.1 Context: AI 系统在业务生态中的位置

Context 图回答:

谁使用 AI 系统。
AI 是否 customer-facing。
它依赖哪些企业系统、知识源、工具、模型供应商。
哪些系统接收 AI 的输出或行动。
哪些外部监管、审计、第三方约束影响边界。

Customer-facing RAG/Agent 的 context 例子:

Customer
  -> Digital Banking App
  -> AI Service Assistant
       -> Approved Model Gateway
       -> Retail Policy Knowledge Base
       -> Case Management System
       -> Human Service Queue
       -> Observability / Evidence Platform
Risk Reviewer
  -> Evidence Binder
Auditor
  -> Control Evidence Index

Context 图要明确“AI 是建议、草稿、自动执行还是决策”。这会直接影响风险等级、评测门槛和人工复核设计。

3.2 Container: 主要运行单元和责任边界

AI container view 常见容器:

Container	责任
Experience App	UI、透明度提示、引用展示、人工交接、反馈
Orchestration Service	prompt assembly、workflow state、model call、tool routing
Model Gateway	approved models、routing、quota、logging、fallback
Retrieval Service	source selection、permission filter、hybrid search、rerank、citation
Tool Gateway	tool contract、policy check、approval、idempotency、audit
Eval Service	offline eval、regression eval、judge/human review、release gate
Policy Engine	allowed use、data boundary、action policy、exception
Observability Stack	trace、metrics、logs、cost、quality、safety signals
Evidence Binder	ADR、eval report、approval、monitoring、incident evidence

这一层最适合讨论:

哪些能力应进入企业 AI platform。
哪些是业务产品自己的差异化。
模型供应商替换会影响哪些边界。
工具调用和数据访问是否必须通过统一网关。

3.3 Component: 组件级职责和接口

以 Orchestration Service 为例:

Component	输入	输出	风险点
Request Classifier	user intent、context	route、risk tier	错分高风险请求
Context Assembler	user state、retrieval result、policy	prompt context	泄露无权限信息
Prompt Template Resolver	task type、locale、version	prompt version	prompt drift
Model Caller	prompt、model route	model response	latency、cost、model behavior change
Tool Planner	model response、workflow state	candidate tool calls	不安全工具选择
Policy Adapter	action、data、risk tier	allow/block/approve	策略缺口
Response Composer	answer、citation、confidence	user response	过度自信、引用错误
Telemetry Emitter	trace context	spans、metrics、events	证据缺失

组件图不要停留在“模块名”。每个组件要能说明:

它做什么决定。
依赖什么输入。
失败后如何降级。
哪个 eval 或 control 覆盖它。

3.4 Code: 只在必要时展开

对高级 PM/BA/Architect, C4 code level 不必每天画, 但在以下场景有价值:

关键 tool wrapper 的幂等、重试、审批、审计逻辑。
policy enforcement point 的实现方式。
retrieval permission filter 的安全实现。
telemetry context propagation 的代码结构。
eval runner 的数据集和阈值绑定。

如果 code level 不能连接到风险、质量或可运维性, 它就不该成为评审主图。

4. arc42 for AI Architecture Documentation

arc42 的价值是让架构文档结构化。AI 系统可以按以下方式改造:

arc42 Section	AI 系统写法
Introduction and Goals	业务 outcome、AI capability、非目标、风险等级
Constraints	法规、数据、模型供应商、预算、延迟、人工复核、审计
Context and Scope	C4 context、system boundary、external systems、trust boundary
Solution Strategy	RAG/agent/fine-tuning/routing/platform reuse 的核心取舍
Building Block View	C4 container/component, 平台服务和业务服务边界
Runtime View	request flow、tool call flow、HITL flow、incident flow
Deployment View	region、network、model endpoint、data store、observability、DR
Crosscutting Concepts	policy、identity、logging、eval、prompt/versioning、data lineage
Architecture Decisions	AI ADR, model choice, RAG design, tool gateway, human oversight
Quality Requirements	accuracy、groundedness、latency、cost、privacy、auditability、resilience
Risks and Technical Debt	prompt debt、data debt、eval coverage gap、vendor lock-in、control gap
Glossary	ubiquitous language、domain terms、model/eval/control terminology

对 AI 产品, arc42 最重要的不是模板完整性, 而是把以下内容从“会议讨论”变成持久资产:

关键约束。
取舍和理由。
质量属性场景。
运行时流程。
风险和证据。
未来演进触发条件。

5. AI-Specific View Set

5.1 Business Capability and Value View

回答:

AI 改善哪个业务能力。
这个能力属于 value stream 的哪一段。
收益假设是节省时间、提升转化、降低损失、增强合规还是改善体验。

Capability	AI role	Value hypothesis	Evidence
Customer service policy handling	RAG assistant + escalation	降低人工处理时间, 提高答案一致性	handle time、first contact resolution、citation accuracy
Payment dispute triage	Agent workflow	缩短 case routing, 减少人工分拣	cycle time、routing accuracy、review override
AML investigation support	Knowledge + graph retrieval	减少调查准备时间, 提高证据覆盖	analyst prep time、evidence completeness

5.2 Data and Knowledge View

AI 架构必须把知识视为受治理资产:

Element	需要表达
Source registry	文档 owner、权威等级、适用业务线
Permission boundary	谁能检索、谁能看到引用、是否有 row/document level filter
Freshness policy	更新频率、失效规则、stale source block
Chunking / indexing	切分策略、metadata、embedding model、rerank
Lineage	answer citation 到 source version 的可追踪关系
Retention	prompt、context、trace、feedback 的保存和删除

5.3 Tool and Action View

Agent 架构的分水岭是 tool/action:

Action type	示例	默认控制
Read-only	查询账户状态、读取 case	RBAC/ABAC、purpose logging
Draft	生成回复草稿、生成 case note	人工确认、版本记录
Low-risk write	更新标签、创建低风险任务	schema validation、audit
High-risk write	退款、冻结账户、提交监管报告	HITL、dual control、approval id
Irreversible action	资金移动、客户通知、永久删除	严格禁止或强人工授权

Tool view 要显示:

工具 contract。
side effect。
approval rule。
idempotency key。
rollback/compensation。
audit event。

5.4 Eval and Control View

AI 系统的“质量”不是单一准确率。Eval/control view 要把需求和风险转成门禁:

Requirement	Eval	Control	Release decision
回答必须基于批准知识源	citation correctness test	source allowlist、stale source block	未达阈值不能 customer-facing release
不提供个性化金融建议	red-team advice boundary	policy classifier、refusal template	high-risk advice bypass 为 hard stop
工具调用必须可审计	trajectory eval、tool argument test	tool gateway audit span	trace coverage 低于门槛不能 scale
高风险 case 必须人工复核	escalation eval	HITL queue + SLA	bypass count 为 0 才能上线

5.5 Runtime Observability View

运行时 view 要让事故调查和质量改进成为可能:

request span
  -> policy classification span
  -> retrieval span
  -> rerank span
  -> model call span
  -> tool planning span
  -> policy decision span
  -> HITL span
  -> response span
  -> feedback / outcome event

关键 telemetry:

trace completeness。
model route、prompt version、retrieval source version。
latency/cost per step。
safety block、policy exception、human override。
outcome feedback 和 incident link。

6. Financial Retail Case: Customer-Facing Policy Assistant

目标: 为银行客户解释费用、账户、贷款和争议流程, 支持客户自助和客服辅助。

6.1 Stakeholder-Concern Matrix

Stakeholder	Concern	View
Retail banking sponsor	降低客服成本, 提高一致性	capability/value view
Customer service lead	交接、纠错、培训和采用	service blueprint
Legal/compliance	不构成未经授权建议, 保留披露	control view
Data owner	知识源权威性和版本	knowledge lineage view
Security	客户数据和 prompt injection	threat/tool boundary view
Model risk	质量和漂移	eval/monitoring view
Audit	发布和变更证据	evidence view

6.2 View Set

View	内容
C4 Context	客户、数字银行 App、AI assistant、policy KB、case system、human queue、evidence binder
C4 Container	UI、orchestrator、model gateway、retrieval service、policy engine、HITL、observability
Runtime	ask question -> classify intent/risk -> retrieve approved policy -> generate cited answer -> policy check -> escalate if needed
Knowledge	source registry、effective date、document owner、permission filter、citation id
Control	advice boundary、PII handling、stale policy block、human escalation
Eval	groundedness、citation correctness、refusal、escalation、latency/cost
Evidence	ADR、eval report、risk signoff、launch approval、monitoring dashboard、incident log

6.3 Architecture Decision Examples

ADR	Decision	Why
ADR-001	Use RAG over fine-tuning for policy knowledge	政策变化频繁, 需要引用和版本控制
ADR-002	All tool actions route through Tool Gateway	统一权限、审批、幂等和审计
ADR-003	Customer-facing answers require citation and no-answer path	控制 hallucination 和过度自信
ADR-004	High-risk product suitability questions escalate to human	降低不当建议风险

7. Templates

7.1 Viewpoint Catalog

字段	内容
Viewpoint name	视角名称
Stakeholders	主要读者
Concerns	回答哪些 concern
Notation	C4、sequence、table、matrix、BPMN、ADR
Required elements	必须出现的系统、组件、控制、指标
Evidence link	关联的 ADR、eval、control、trace
Review cadence	discovery、pilot、release、scale、quarterly

7.2 AI C4 Checklist

Level	Checklist
Context	是否显示用户、外部系统、模型/供应商、数据源、人工队列、审计/监管角色
Container	是否显示 model gateway、RAG、tool gateway、policy、eval、observability、evidence
Component	是否显示关键决策组件、输入输出、失败路径、控制点
Code	是否只展开高风险或高复杂度实现, 如 tool wrapper、policy enforcement、permission filter

7.3 arc42 AI Section Map

Section	最小可交付
Goals	outcome、scope、non-goals、risk tier
Constraints	data、policy、latency、cost、vendor、human oversight
Context	C4 context + trust boundary
Building Blocks	container/component diagrams
Runtime	sequence diagrams for normal, exception, HITL, incident
Quality	quality attribute scenarios and eval gates
Risks	risk register, debt register, mitigation
Decisions	AI ADR list with reversal trigger

7.4 Portfolio Evidence Pack

Artifact	面试价值
Stakeholder-concern matrix	证明你能从业务、风险、工程多方建模
C4 context/container/component	证明你能讲清边界和依赖
Runtime sequence	证明你理解真实运行路径和失败点
Data/knowledge lineage	证明你能处理企业知识治理
Control/evidence view	证明你能把 AI 架构接到合规和审计
ADR set	证明你能做架构取舍, 不只是画图

8. Common Failure Modes

Failure mode	表现	修正
Everything diagram	一张图塞满所有组件、风险、数据和流程	拆成 stakeholder-specific views
Vendor diagram	图里只有模型供应商和 UI	加入企业控制面、数据面、工具面、证据面
No runtime	只有静态框图	增加正常路径、失败路径、人工交接和事故路径
No evidence	评审图和审计证据断开	每个关键控制连接 eval、trace、approval 或 ADR
No evolution	架构像一次性项目	加入 roadmap、deprecation、platform reuse、reversal trigger

9. 面试表达

30 秒版本:

我不会用一张大图表达 AI 架构。我会先列 stakeholder 和 concern, 再用 C4 表达系统边界和组件, 用 arc42 组织架构文档, 用 42010 的 viewpoint/view 思路保证每张图服务特定决策。对 AI 系统, 我会额外加 data/knowledge、tool/action、eval/control、observability/evidence 视图, 这样业务、工程、风险和审计都能看到自己需要的决策依据。

2 分钟版本:

以 customer-facing RAG 为例, context view 说明客户、数字渠道、AI assistant、政策知识库、人工队列和证据平台的边界; container view 说明 orchestrator、model gateway、retrieval、policy、HITL、observability; runtime view 说明一次请求如何分类、检索、生成、策略检查和升级; knowledge view 说明 source owner、版本、权限和引用; eval/control view 说明 groundedness、citation、refusal、escalation 的 release gate; evidence view 说明 ADR、eval report、approval、trace 和 incident 如何被审计。这样架构不只是工程图, 而是产品和治理的共同语言。

深挖追问:

追问	回答要点
C4 和 arc42 怎么配合	C4 负责分层图, arc42 负责结构化文档和决策上下文
42010 对 AI 架构有什么用	强制从 stakeholder concern 出发, 避免一图打天下
AI 系统额外需要哪些 view	data/knowledge、tool/action、eval/control、observability/evidence
如何避免架构文档过重	用 risk tier 决定视图深度, 高风险系统要求更多证据
如何证明架构有效	每个关键 view 连接 ADR、eval、control、runtime telemetry 和 release gate

10. Practice Assignment

选一个金融零售 AI use case, 例如 AML investigation copilot、payment dispute agent 或 credit policy assistant, 产出:

stakeholder-concern matrix。
C4 context diagram。
C4 container diagram。
一条正常路径和一条异常路径 sequence。
data/knowledge lineage table。
eval/control/evidence matrix。
3 条 ADR。
2 分钟面试叙事。

完成标准:

图能被业务、工程、风险三类读者理解。
每个关键风险至少有一个控制和一个证据来源。
每个关键架构取舍都有 ADR。
没有把 AI 简化成“接一个模型 API”。