AI Architecture Diagram Playbook

定位: 面向 AI Architect / AI PM / AI BA 的架构图谱训练手册。 目标: 把 AI 系统从“我知道大概怎么做”提升到“我能画出来、讲清楚、评审得动、落地可控”。 使用方式: 每做一个 AI case, 至少输出 3 张图: 业务流程图、系统容器图、eval/risk/control 图。

---

Source Anchors

这些资料作为本 playbook 的方法基线。学习时不需要背标准, 但要能把图和标准的关注点对齐。

---

为什么 AI 架构师必须会画图

AI 项目最常见的问题不是没有模型, 而是没人能把业务问题、用户流程、数据边界、模型能力、系统集成、风险控制和运营责任放到同一个可讨论的画布上。

传统系统图通常回答“服务如何调用”。AI 系统还必须回答:

• 模型基于什么证据回答?
• 用户输入、检索结果、工具调用和模型输出分别在哪里被控制?
• 哪些动作可以自动执行, 哪些必须 human-in-the-loop?
• 错误答案、幻觉、越权、数据泄露、prompt injection 如何被发现和阻断?
• 评测集、线上监控、人工反馈如何影响发布门禁?
• 成本、延迟、准确率、可解释性和合规性如何权衡?

好的 AI 架构图不是装饰, 而是决策工具。它让业务方看到价值, 让工程方看到边界, 让风控合规看到控制, 让管理层看到投资逻辑。

---

图谱总览

---

1. Capability Map

什么时候用

当你还没有进入具体系统设计, 需要说明“AI 会改造哪些业务能力”时使用。能力图特别适合金融零售场景, 因为银行/支付/财富/零售运营通常有明确能力域。

回答什么问题

• 哪些业务能力直接产生价值?
• 哪些能力只是支撑能力?
• AI 应优先进入哪个能力域?
• 哪些能力属于高风险, 需要更强治理?
• 能力之间的依赖是什么?

最小元素

• Business capability name
• Current maturity
• AI opportunity
• Data readiness
• Risk level
• Owner
• Target artifact

常见错误

• 把系统模块当成业务能力, 例如把“向量数据库”画成能力。
• 只画 AI 能做什么, 不画业务价值和风险。
• 没有 owner, 导致能力图无法转成行动。

金融零售例子

AML 运营能力可以拆成:

• Alert intake
• Entity resolution
• Transaction pattern review
• Case narrative drafting
• SAR recommendation
• Quality assurance
• Audit evidence retention

AI 不一定端到端替代全部能力。更现实的是先增强 entity resolution、case narrative drafting 和 evidence summarization。

Mermaid 示例

flowchart LR
  A[Financial Crime Operations] --> B[Alert Intake]
  A --> C[Entity Resolution]
  A --> D[Transaction Pattern Review]
  A --> E[Case Narrative Drafting]
  A --> F[QA and Audit Evidence]

  C --> C1[AI opportunity: match customer, account, merchant signals]
  D --> D1[AI opportunity: summarize transaction anomalies]
  E --> E1[AI opportunity: draft investigator narrative]
  F --> F1[Control: citation, reviewer approval, immutable log]

面试讲法

“我不会一开始就画模型架构。我会先画 capability map, 把业务价值、数据 readiness 和风险等级放在一起, 这样可以避免团队把 AI 投到低价值或数据不成熟的地方。”

---

2. C4 Context Diagram

什么时候用

当你需要向管理层、业务方或跨团队说明系统边界时使用。Context 图不深入组件, 只说明系统与用户、外部系统、监管/审计方的关系。

回答什么问题

• 我们要建设的 AI system 是什么?
• 谁使用它?
• 它依赖哪些系统?
• 它向哪些外部方提供证据或报告?
• 哪些系统不在本次范围内?

最小元素

• Primary users
• AI system boundary
• Core upstream systems
• Core downstream systems
• External actors
• Trust boundary

常见错误

• Context 图里塞太多微服务。
• 没有标明系统边界, 导致 scope creep。
• 没有区分人类用户、系统用户和监管/审计用户。

AML Copilot 示例

flowchart LR
  Investigator[AML Investigator]
  Manager[QA Manager]
  Core[Core Banking]
  Txn[Transaction Monitoring System]
  KYC[KYC Platform]
  Policy[Policy Repository]
  Audit[Audit and Compliance]

  subgraph Boundary[AML Investigation Copilot]
    Copilot[Case Review and Narrative Assistant]
  end

  Investigator --> Copilot
  Manager --> Copilot
  Core --> Copilot
  Txn --> Copilot
  KYC --> Copilot
  Policy --> Copilot
  Copilot --> Audit

面试讲法

“Context 图的重点是边界而不是技术细节。我会用它先对齐哪些系统参与、哪些动作仍由人负责、哪些证据要进入审计链路。”

---

3. C4 Container Diagram

什么时候用

当方案进入架构评审, 需要说明主要应用、数据存储、模型服务、检索服务、策略服务和审计服务如何协作时使用。

回答什么问题

• 系统由哪些可部署单元组成?
• 用户请求如何进入 AI 工作流?
• RAG、Agent、Eval、Policy、Audit 分别在哪里?
• 哪些数据落库?
• 哪些服务需要权限控制?

最小元素

• Web/App UI
• API gateway or backend
• Orchestrator
• Model gateway
• Retrieval service
• Vector store / search index
• Tool connector service
• Policy and guardrail service
• Evaluation service
• Audit log

常见错误

• 只画 LLM, 不画权限、检索、审计和评测。
• 把 vector DB 当成事实来源, 忽略原始系统和数据 lineage。
• 让 UI 直接调用模型和工具, 缺少服务端控制。

Customer Service Copilot 示例

flowchart TB
  User[Service Agent] --> UI[Agent Desktop Plugin]
  UI --> API[Copilot Backend API]
  API --> Auth[AuthZ and Entitlement]
  API --> Orch[Workflow Orchestrator]
  Orch --> Guard[Policy and Guardrails]
  Orch --> RAG[Retrieval Service]
  RAG --> Search[Hybrid Search Index]
  Search --> KB[Product and Policy Knowledge Base]
  Orch --> Tools[Tool Connector Service]
  Tools --> CRM[CRM]
  Tools --> Account[Account System]
  Orch --> Model[Model Gateway]
  Model --> LLM[LLM Provider or Private Model]
  Orch --> Eval[Online Eval and Quality Rules]
  Orch --> Audit[Prompt, Evidence, Output, Action Log]

面试讲法

“Container 图里我会强制把 Model Gateway、Retrieval、Policy、Eval 和 Audit 画出来。企业 AI 不是 UI 加模型, 而是一套受控的业务执行系统。”

---

4. C4 Component Diagram

什么时候用

当工程团队要拆任务、评审服务边界、写 ADR 或安排迭代时使用。

回答什么问题

• Orchestrator 内部有哪些组件?
• Prompt assembly、retrieval ranking、tool execution、policy check 如何分层?
• Eval 在同步路径还是异步路径?
• 哪些组件可替换?

最小元素

• Input normalizer
• Intent classifier
• Context builder
• Retrieval planner
• Prompt composer
• Tool planner
• Policy checker
• Response validator
• Human review router
• Audit writer

常见错误

• 组件按照技术名而不是责任命名。
• 没有画失败路径。
• 同步和异步组件混在一起。

Lending Assistant 组件示例

flowchart LR
  A[Application Question] --> B[Input Normalizer]
  B --> C[Intent and Risk Classifier]
  C --> D[Context Builder]
  D --> E[Policy Retrieval Planner]
  E --> F[Prompt Composer]
  F --> G[Model Gateway]
  G --> H[Response Validator]
  H --> I{High risk?}
  I -->|Yes| J[Human Review Router]
  I -->|No| K[Advisor Response]
  H --> L[Audit Writer]

面试讲法

“Component 图可以证明我知道 AI 系统内部不是一个 prompt。尤其在 lending 和 wealth 场景, policy checker、human review router 和 audit writer 是核心组件。”

---

5. BPMN AS-IS / TO-BE

什么时候用

BA 做需求发现时必须先画 AS-IS, 再画 TO-BE。不要直接从 solution 开始。AI 项目的问题往往藏在返工、等待、审批、信息查找和异常分支里。

回答什么问题

• 当前流程谁做什么?
• 哪些步骤等待时间长?
• 哪些环节重复录入?
• 哪些判断没有证据?
• 哪些异常导致返工?
• AI 改造后责任是否改变?

最小元素

• Pools / lanes
• Events
• Tasks
• Gateways
• Data objects
• Manual review points
• Exceptions
• SLA and pain metrics

常见错误

• 只画 happy path, 不画异常流。
• 把 AI 节点画成万能自动化, 没有保留人类责任。
• 没有量化 pain point, 例如 cycle time、touch time、error rate。

KYC Remediation TO-BE 示例

flowchart TB
  Start([KYC review due]) --> A[Collect customer profile and documents]
  A --> B[AI extracts missing fields and inconsistencies]
  B --> C{Risk level}
  C -->|Low| D[Generate customer outreach draft]
  C -->|Medium| E[Analyst reviews evidence and outreach]
  C -->|High| F[Escalate to compliance specialist]
  D --> G[Send approved request]
  E --> G
  F --> H[Manual remediation decision]
  G --> I[Update KYC record]
  H --> I
  I --> End([Audit evidence retained])

面试讲法

“我会先用 BPMN 找出 AI 介入点, 而不是先讨论模型。AI 适合处理证据汇总、草稿生成和一致性检查, 但高风险判断要保留人工审批。”

---

6. Sequence Diagram

什么时候用

当你需要解释一次任务从用户点击到模型返回再到系统动作的完整路径时使用。Sequence 图特别适合暴露隐藏风险: 权限是否在检索前检查? 工具调用前是否审批? 审计日志是否记录了证据?

回答什么问题

• 用户请求经过哪些服务?
• 每一步的输入输出是什么?
• 权限检查发生在哪里?
• 模型是否能直接执行动作?
• 失败时如何降级?

最小元素

• User
• UI
• Backend
• AuthZ
• Retrieval
• Model Gateway
• Tool Service
• Policy Service
• Audit Log
• Human Reviewer

Payments Exception 示例

sequenceDiagram
  participant Ops as Payment Ops User
  participant UI as Ops Portal
  participant API as Exception Copilot API
  participant Auth as Entitlement Service
  participant RAG as Evidence Retrieval
  participant LLM as Model Gateway
  participant Tool as Payment Case Tool
  participant Audit as Audit Log

  Ops->>UI: Ask why payment failed
  UI->>API: Submit case id and question
  API->>Auth: Check case access
  Auth-->>API: Allowed
  API->>RAG: Retrieve payment messages, rules, prior cases
  RAG-->>API: Evidence with citations
  API->>LLM: Compose answer with evidence
  LLM-->>API: Explanation and suggested next action
  API->>Audit: Log prompt, evidence, output
  API-->>UI: Show answer and require user approval
  Ops->>UI: Approve action
  UI->>API: Execute approved action
  API->>Tool: Update case status
  Tool-->>API: Success
  API->>Audit: Log user-approved action

面试讲法

“Sequence 图能显示控制点。我会刻意画出检索前的 access check、工具执行前的人类审批和完整 audit log。”

---

7. Data Flow Diagram

什么时候用

当涉及敏感数据、客户隐私、跨系统共享、模型供应商、日志留存或训练数据时使用。

回答什么问题

• 哪些数据进入模型上下文?
• 哪些数据被写入日志?
• 是否有 PII、PCI、敏感金融信息?
• 是否跨境或进入第三方服务?
• 数据保留多久?
• 数据是否用于训练?

最小元素

• Data source
• Data type
• Classification
• Transformation
• Storage
• Access control
• Retention
• External transfer
• Logging path

常见错误

• 不区分 source data、derived data、prompt data、model output、audit data。
• 没有标注数据分类。
• 忽略 embeddings 也可能泄露语义信息。

示例

flowchart LR
  A[CRM customer profile - PII] --> B[Data Minimization Layer]
  C[Policy docs - internal] --> D[Chunking and Indexing]
  D --> E[Vector and Keyword Index]
  B --> F[Prompt Context Builder]
  E --> F
  F --> G[Model Gateway]
  G --> H[Generated Answer]
  F --> I[Audit Store: prompt metadata and evidence ids]
  H --> I

面试讲法

“AI 数据流图里我会单独标出 prompt context 和 audit data。很多风险不是来自原始系统, 而是来自把敏感数据拼进 prompt、日志或 embedding 管道。”

---

8. RAG Pipeline Diagram

什么时候用

当系统需要基于企业知识、政策、产品文档、监管解释或客户案例回答时使用。

回答什么问题

• 知识如何进入索引?
• 检索如何做权限过滤?
• 召回和重排如何工作?
• 证据如何进入 prompt?
• 答案如何引用来源?
• 如何评测 groundedness?

最小元素

• Content ingestion
• Document parsing
• Chunking
• Metadata tagging
• Embedding / indexing
• Access control filter
• Hybrid retrieval
• Reranking
• Prompt composition
• Generation
• Citation rendering
• Eval

常见错误

• 只画 query -> vector DB -> LLM。
• 没有 ingestion quality control。
• 没有权限过滤和文档版本。
• 没有引用和答案可追溯。

Product Knowledge RAG 示例

flowchart TB
  subgraph Ingestion[Knowledge Ingestion]
    D1[Product docs]
    D2[Fee schedules]
    D3[Policy exceptions]
    P[Parser and chunker]
    M[Metadata: product, region, version, entitlement]
    IDX[Hybrid index]
    D1 --> P
    D2 --> P
    D3 --> P
    P --> M --> IDX
  end

  subgraph Runtime[Answer Runtime]
    Q[User question] --> AC[Access control filter]
    AC --> R[Retriever]
    R --> RR[Reranker]
    RR --> PC[Prompt composer with citations]
    PC --> LLM[Model gateway]
    LLM --> V[Groundedness validator]
    V --> A[Answer with sources]
  end

  IDX --> R

面试讲法

“RAG 图必须分 ingestion 和 runtime。很多企业 RAG 失败不是模型问题, 而是文档版本、元数据、权限和评测没有设计好。”

---

9. Agent Tool-Use Loop Diagram

什么时候用

当 AI 不只是回答, 还要查询系统、创建记录、更新状态、生成工单、调用风控规则或触发工作流时使用。

回答什么问题

• Agent 能调用哪些工具?
• 如何选择工具?
• 工具权限由谁控制?
• 哪些动作必须审批?
• 失败后如何重试或回滚?
• 如何记录 action trace?

最小元素

• Goal
• Planner
• Tool registry
• Policy checker
• Tool executor
• Observation
• State store
• Human approval
• Action log
• Stop condition

常见错误

• 把 tool calling 当成无限权限。
• 没有 action allowlist。
• 没有幂等性和回滚。
• 没有 step budget 和 timeout。

Merchant Risk Monitoring 示例

flowchart LR
  Goal[Review merchant risk alert] --> Plan[Agent planner]
  Plan --> Policy[Policy and permission check]
  Policy --> Tool{Select allowed tool}
  Tool --> T1[Fetch merchant profile]
  Tool --> T2[Fetch transaction anomalies]
  Tool --> T3[Compare peer benchmark]
  T1 --> Obs[Observation store]
  T2 --> Obs
  T3 --> Obs
  Obs --> Decide[Draft recommendation]
  Decide --> Human{Human approval required?}
  Human -->|Yes| Review[Risk analyst review]
  Human -->|No| Close[Close low-risk alert]
  Review --> Action[Approved case action]
  Action --> Log[Action and evidence log]

面试讲法

“Agent 图的重点不是让模型自由行动, 而是把 planner、tool registry、policy check、human approval 和 action log 画出来。”

---

10. Eval Architecture Diagram

什么时候用

当你要说明 AI 系统如何上线、如何回归测试、如何监控质量、如何处理反馈时使用。PM/BA 如果不会 eval, 很难管理 AI 产品质量。

回答什么问题

• 什么样的回答算好?
• 测试集从哪里来?
• 哪些指标是自动评测, 哪些需要专家评审?
• 发布门禁是什么?
• 线上失败如何进入改进循环?

最小元素

• Golden dataset
• Scenario taxonomy
• Rubric
• Automated graders
• Human review
• Regression suite
• Online feedback
• Failure case library
• Release gate
• Model/prompt/config versioning

常见错误

• 只看用户点赞, 没有离线回归。
• 只测通用 benchmark, 不测业务场景。
• 没有高风险样本和 adversarial tests。
• 没有把失败案例回流到需求和控制设计。

示例

flowchart TB
  A[Production conversations] --> B[Sample and label failure cases]
  C[Expert-authored test cases] --> D[Golden dataset]
  B --> D
  D --> E[Automated eval: groundedness, policy compliance, action accuracy]
  D --> F[Human eval: domain correctness, judgment quality]
  E --> G[Release gate]
  F --> G
  G -->|Pass| H[Deploy prompt/model/config]
  G -->|Fail| I[Fix prompt, retrieval, policy, workflow]
  H --> J[Online monitoring]
  J --> B

面试讲法

“我会把 eval 设计当成需求的一部分。每条 AI 需求都要对应测试样本、评分规则、阈值和上线门禁。”

---

11. Risk / Control Architecture

什么时候用

高风险 AI 场景必须画风险控制架构。尤其是金融零售里的 AML、KYC、信贷、欺诈、财富建议、投诉处理。

回答什么问题

• 风险类型有哪些?
• 控制点在哪里?
• 谁审批?
• 控制证据如何保存?
• 什么时候拒答、降级或升级?

最小元素

• Risk taxonomy
• Preventive controls
• Detective controls
• Corrective controls
• Human review
• Audit evidence
• Control owner
• Residual risk

常见错误

• 把风险控制都写在 prompt 里。
• 只画安全风险, 不画业务风险和合规风险。
• 没有 owner, 没有 evidence。

Wealth Advisory Compliance 示例

flowchart LR
  Q[Client question] --> Classify[Advice risk classifier]
  Classify --> R1{Personalized advice?}
  R1 -->|No| Edu[Educational response with disclosure]
  R1 -->|Yes| Suit[Suitability data check]
  Suit --> R2{Required profile complete?}
  R2 -->|No| Refuse[Do not provide recommendation; request advisor review]
  R2 -->|Yes| Advisor[Licensed advisor review]
  Advisor --> Output[Approved response]
  Edu --> Audit[Audit evidence]
  Refuse --> Audit
  Output --> Audit

面试讲法

“风险控制架构要区分 preventive、detective、corrective controls。高风险建议不能靠模型自觉, 必须通过分类、权限、审批和审计证据管理。”

---

12. Observability / Runbook Architecture

什么时候用

上线前必须画。AI 系统会出现传统系统之外的质量漂移、知识过期、prompt injection、异常成本、模型供应商波动和评测退化。

回答什么问题

• 线上看哪些指标?
• 谁收到告警?
• 如何判断是否回滚?
• 哪些失败自动进入 review queue?
• 供应商或模型失败如何降级?

最小元素

• Request volume
• Latency
• Cost per task
• Retrieval hit rate
• Citation coverage
• Groundedness score
• Policy violation
• Tool failure
• Human override rate
• Escalation queue
• Rollback switch

常见错误

• 只监控基础设施, 不监控 AI 质量。
• 没有按业务场景分层看指标。
• 没有 runbook owner。

示例

flowchart LR
  Runtime[AI runtime events] --> Metrics[Metrics pipeline]
  Runtime --> Logs[Prompt/evidence/output/action logs]
  Metrics --> Dash[AI Ops dashboard]
  Logs --> Review[Failure review queue]
  Dash --> Alert{Threshold breach?}
  Alert -->|Yes| Runbook[Incident runbook]
  Runbook --> Rollback[Rollback prompt/model/retrieval config]
  Runbook --> Owner[Notify product, risk, engineering owner]

面试讲法

“AI observability 要覆盖 quality、risk、cost 和 adoption。只看 latency 和 error rate 不够, 因为 AI 可能技术成功但业务上错误。”

---

13. Deployment Topology

什么时候用

当进入安全、平台和供应商评审时使用。它说明系统部署在哪里、网络边界在哪里、密钥怎么管、模型服务如何访问。

回答什么问题

• 模型在公有云、私有云、SaaS 还是本地?
• 哪些组件在受控网络内?
• 是否有跨境数据传输?
• 密钥和 secrets 如何管理?
• 环境如何隔离?

最小元素

• User network
• Application tier
• Data tier
• Model provider boundary
• Secret manager
• Private endpoint
• Logging and SIEM
• CI/CD path

常见错误

• Container 图替代部署图。
• 没有画供应商边界。
• 没有画非生产环境和测试数据策略。

面试讲法

“Deployment topology 不是所有面试都要画, 但一旦涉及金融数据、供应商模型和跨境处理, 它就是架构评审的关键图。”

---

14. Cost / Latency Model

什么时候用

当管理层问“这个方案贵不贵、慢不慢、能不能规模化”时使用。PM 和架构师都要能说清楚 unit economics。

回答什么问题

• 每次任务成本多少?
• 哪一步最慢?
• 哪些请求需要大模型?
• 哪些可以 cache 或走小模型?
• 质量、成本、延迟如何权衡?

最小元素

• Token input/output
• Retrieval cost
• Reranker cost
• Tool call cost
• Human review cost
• Latency budget
• Cache strategy
• Model routing strategy

示例

flowchart LR
  Q[Request] --> Cache{Cache hit?}
  Cache -->|Yes| A[Return cached policy answer]
  Cache -->|No| Small[Small model intent classifier]
  Small --> Route{Risk and complexity}
  Route -->|Low| Fast[Fast model response]
  Route -->|High| Strong[Strong model + RAG + human review]
  Fast --> Metrics[Cost and latency metrics]
  Strong --> Metrics

面试讲法

“我会把模型路由和人审成本一起算。便宜的 AI 不只是换小模型, 还包括缓存、检索优化、prompt 压缩、任务分级和流程设计。”

---

15. Operating Model / RACI

什么时候用

AI 从 pilot 进入规模化时使用。很多 AI 项目失败不是技术失败, 而是没有 owner、没有反馈闭环、没有变更治理。

回答什么问题

• 谁定义业务需求?
• 谁维护知识库?
• 谁审批 prompt/model/config change?
• 谁负责评测集?
• 谁处理线上失败?
• 谁签署上线风险?

最小元素

• Roles
• Responsibilities
• Decision rights
• Approval flow
• Review cadence
• Escalation path
• Evidence artifacts

示例 RACI

面试讲法

“AI 产品上线后还会持续变化, 所以 operating model 和 RACI 很重要。Prompt、知识库、评测集、模型版本和控制策略都需要变更治理。”

---

金融零售场景图谱组合

不同 case 不需要画所有图, 但至少要覆盖业务、系统、风险、运营四类视角。

---

与 ABPA 模板的连接

---

与经典论文学习的连接

学习论文时不要只写摘要。每篇论文至少转成一张图:

• Transformer: token -> embedding -> attention -> logits -> enterprise constraints.
• RAG: ingestion -> retrieval -> prompt -> generation -> citation -> eval.
• ReAct: thought/action/observation -> tool registry -> policy -> audit.
• RLHF: preference data -> reward model -> alignment behavior -> residual risk controls.

---

图的质量标准

1. 读者明确

一张图只服务一个主要读者。给高管看的图不要塞组件细节, 给工程看的图不要只写价值口号。

2. 边界明确

每张架构图都要有边界:

• System boundary
• Trust boundary
• Data boundary
• Vendor boundary
• Human responsibility boundary

3. 风险可见

AI 系统图必须让风险看得见:

• Prompt injection
• Sensitive data exposure
• Hallucination
• Unauthorized tool action
• Outdated knowledge
• Bias or unfair outcome
• Model drift
• Cost runaway

4. 控制可验证

控制不是一句“加 guardrails”。要画出:

• 控制点在哪里
• 谁负责
• 输入输出是什么
• 证据在哪里保存
• 失败后怎么处理

5. 可追问

好图经得起追问:

• 如果检索不到证据怎么办?
• 如果模型输出和政策冲突怎么办?
• 如果用户没有权限怎么办?
• 如果工具调用失败怎么办?
• 如果评测下降怎么办?
• 如果成本翻倍怎么办?

---

Diagram Review Checklist

业务视角

• 是否说明业务目标和用户?
• 是否区分 AS-IS 和 TO-BE?
• 是否标出 pain metric?
• 是否能解释 ROI 或价值假设?

架构视角

• 是否标出系统边界?
• 是否标出主要容器或组件?
• 是否区分同步路径和异步路径?
• 是否显示外部系统和供应商边界?
• 是否说明关键 ADR?

数据视角

• 是否标出数据来源?
• 是否标出数据分类和敏感性?
• 是否标出访问控制?
• 是否说明日志和留存?
• 是否说明 embedding / prompt / output 的数据路径?

AI 质量视角

• 是否有 eval architecture?
• 是否有测试集来源?
• 是否有 rubric 和 threshold?
• 是否区分自动评测和人工评审?
• 是否有 failure case feedback loop?

风险控制视角

• 是否标出主要 AI 风险?
• 是否有 preventive / detective / corrective controls?
• 是否有 human-in-the-loop?
• 是否有 audit evidence?
• 是否有 rollback / escalation?

运营视角

• 是否有 owner?
• 是否有 RACI?
• 是否有上线后监控?
• 是否有 incident runbook?
• 是否有变更管理?

---

10-Day Diagram Practice Sprint

Day 1: 选定 case 和读者

选择一个 case, 建议从 AML Copilot 或 Customer Service Copilot 开始。

输出:

• 一句话业务问题
• 主要用户
• 主要风险
• 需要的 5 张图

Day 2: Capability Map

输出:

• 业务能力树
• AI opportunity 标注
• value/risk/data readiness 打分

Day 3: BPMN AS-IS

输出:

• 当前流程
• pain metrics
• 异常分支
• 手工判断点

Day 4: BPMN TO-BE

输出:

• AI 介入点
• human review 点
• 责任变化
• 目标指标

Day 5: C4 Context + Container

输出:

• 系统边界
• 用户和外部系统
• 主要容器
• 模型/检索/工具/审计边界

Day 6: Data Flow + RAG

输出:

• 数据源和分类
• ingestion pipeline
• runtime retrieval
• 权限和引用机制

Day 7: Sequence + Agent Loop

输出:

• 一次完整任务序列
• 工具调用路径
• 审批和失败路径

Day 8: Eval + Risk Control

输出:

• eval pipeline
• golden set taxonomy
• risk/control architecture
• release gate

Day 9: Observability + Operating Model

输出:

• 线上 dashboard 指标
• incident runbook
• RACI
• 变更治理路径

Day 10: Portfolio Story

输出:

• 5 分钟讲解稿
• 10 个追问答案
• 图谱索引页
• 下一轮改进清单

---

面试讲解结构

面对 AI 架构或 AI PM/BA 面试, 不要直接从模型开始。建议用这个顺序:

1. Business problem: 业务痛点、用户、现状指标。
2. Workflow: AS-IS 和 TO-BE, 说明 AI 介入点。
3. Architecture: C4 Context/Container, 说明系统边界。
4. Data: 数据来源、权限、RAG、日志、留存。
5. AI behavior: 模型、检索、工具、prompt、human review。
6. Eval: 测试集、rubric、阈值、发布门禁。
7. Risk: 主要风险、控制点、审计证据。
8. Operations: 监控、反馈、incident、RACI。
9. ROI: 时间节省、质量提升、风险降低、成本模型。

一句话模板:

“我先从业务流程和能力图确定 AI 应该改造哪里, 再用 C4 和数据流图确定系统边界, 用 RAG/Agent 图解释 AI 行为, 用 Eval 和 Risk 图证明它可控, 最后用 Operating Model 说明上线后谁维护和如何持续改进。”

---

常见反模式

反模式 1: Model-first architecture

表现: 图的中心只有 LLM, 周围是几条箭头。

修正: 先画业务流程、系统边界、数据流、评测和控制, 再放模型。

反模式 2: Prompt-as-control

表现: 认为 prompt 里写“不要泄露数据”就等于安全。

修正: 把权限、数据最小化、输出校验、工具 allowlist、审计、HITL 画成外部控制。

反模式 3: RAG-as-database

表现: 把向量库当成权威数据源。

修正: 画出 source system、document version、metadata、index lineage 和 citation。

反模式 4: Happy-path-only

表现: 图里没有失败路径、升级路径、回滚路径。

修正: 每张 sequence 和 BPMN 至少包含一个异常流。

反模式 5: No operating owner

表现: 上线后没人维护 eval、知识库、prompt 和失败案例。

修正: 画 Operating Model / RACI, 把 owner、cadence、decision rights 说清楚。

---

Portfolio 输出标准

每个 AI case 最少形成一个 8 页 portfolio pack:

1. One-page executive summary.
2. Capability map and value/risk score.
3. AS-IS / TO-BE BPMN.
4. C4 Context and Container.
5. RAG / Agent / Data Flow diagram.
6. Eval architecture and metrics.
7. Risk/control architecture and RACI.
8. ROI, rollout plan, interview story.

每页都要能回答一个问题:

• Why this problem?
• Why AI here?
• Why this architecture?
• Why is it safe enough?
• How do we know it works?
• Who owns it after launch?

---

练习评分 Rubric

目标不是画得漂亮, 而是让图能支持决策、评审和落地。

---

下一步学习建议

建议按以下顺序练习:

1. 用 AML Copilot 画完整图谱, 因为它覆盖高风险、证据、审计和人审。
2. 用 Customer Service Copilot 练 RAG、知识治理和 adoption。
3. 用 Payments Exception Handling 练 agent tool-use 和 sequence。
4. 用 Lending Assistant 练公平性、政策解释、human review。
5. 用 Wealth Advisory Compliance 练拒答、升级和持牌责任边界。

每完成一个 case, 都回到 docs/abpa/templates/12-portfolio-evidence-map.md 做资产登记, 确保学习不是散文式笔记, 而是可展示的职业证据。