AI DDD：通用语言与上下文边界
一句话:
AI Domain-Driven Design / Ubiquitous Language 解读
面向对象: Senior BA / AI Product Manager / Product Architect / Enterprise Architect / Domain Architect。 核心问题: 很多 AI 产品失败不是因为模型不懂自然语言, 而是团队没有定义业务语言、上下文边界和责任边界。AI 在一个上下文中正确的术语, 到另一个上下文可能变成错误解释。DDD 能把业务语言、系统边界、知识源、RAG、eval 和架构决策连接起来。 学习目标: 用 bounded context、ubiquitous language、context map、domain event、aggregate、anti-corruption layer 来设计 AI task boundary、knowledge boundary 和 eval vocabulary。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Domain Language / DDD | https://www.domainlanguage.com/ddd/ | 参考领域驱动设计、bounded context、ubiquitous language 和建模语言 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将领域边界与 AI risk mapping、measurement、management 连接 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 将领域知识、系统责任和管理体系连接 |
一句话:
AI DDD 是把业务语言和上下文边界显性化, 防止 AI 在错误上下文里检索、解释、推理和执行。
1. 为什么 AI 产品需要 DDD
AI 团队常说:
模型能读自然语言, 所以把业务资料放进去就行。
但金融零售里的术语常常高度上下文依赖:
case在 AML 是调查案件, 在客服是服务工单, 在信贷是申请档案。approval在信贷是授信决策, 在工具调用是人工放行, 在模型治理是 release sign-off。risk score在欺诈、信用、AML、模型风险中含义完全不同。customer harm在合规、体验、运营、财务损失中度量不同。
如果没有 bounded context:
- RAG 可能检索到错误政策。
- Agent 可能调用错误系统。
- Eval case 可能混用不同业务规则。
- PM 可能把一个上下文的成功指标迁移到另一个上下文。
- 架构师可能把不该共享的数据和工具做成共享能力。
DDD 的价值不是补软件工程理论, 而是建立 AI 产品的语义防火墙。
2. DDD-to-AI Mapping
| DDD 概念 | AI 产品映射 | 设计问题 |
|---|---|---|
| Bounded Context | AI 能正确理解和行动的业务语义边界 | 这个 AI task 属于哪个业务上下文 |
| Ubiquitous Language | prompt、UI、PRD、RAG metadata、eval 中一致使用的业务语言 | 术语是否有跨上下文歧义 |
| Aggregate | 一组需要一致性保护的业务对象 | AI 能否修改, 谁审批, 如何审计 |
| Domain Event | 业务状态变化事实 | Agent 行动后产生什么事件 |
| Policy | 业务规则和约束 | prompt 内还是 policy engine / DMN 外置 |
| Context Map | 上下文之间的关系和集成方式 | 哪些上下文共享, 哪些要隔离 |
| Anti-Corruption Layer | 防止外部模型/系统污染领域模型 | vendor output 如何转换、校验、拒绝 |
AI 系统需要把这些概念落实到:
- prompt vocabulary。
- RAG source registry。
- tool schema。
- event schema。
- eval taxonomy。
- audit evidence。
- product analytics。
3. AI Task Boundary
每个 AI task 都应明确:
| Boundary | 问题 |
|---|---|
| Domain boundary | 这个任务属于 AML、信贷、客服、财富、支付还是平台治理 |
| Decision boundary | AI 是解释、建议、分类、执行还是监督 |
| Data boundary | 哪些数据属于此上下文, 哪些只能通过 ACL/adapter 访问 |
| Tool boundary | AI 能调用哪些工具, 工具副作用属于哪个 aggregate |
| Language boundary | 哪些术语在本上下文有专门含义 |
| Evidence boundary | 哪些证据可以支持本上下文的回答 |
示例:
Credit policy explanation assistant
Context: credit underwriting / servicing
Can: explain approved policy and required documents
Cannot: give final credit decision or override adverse action reason
Data: application status, approved policy, reason code
Tool: read-only case lookup
Evidence: policy version, reason-code mapping, human approval when high impact
4. Knowledge / RAG Boundary
RAG 不是把所有文档放进一个向量库。DDD 视角下, RAG 需要 context-specific retrieval。
| RAG Boundary | 设计 |
|---|---|
| Source authority | 每个 bounded context 的权威来源和 owner |
| Term ambiguity | 同一术语在不同上下文的定义 |
| Policy version | 生效日期、地区、产品线、渠道 |
| Permission | 用户、员工、AI 任务对知识源的访问权限 |
| Citation | 引用必须显示 context 和 source version |
| Conflict handling | 多来源冲突时拒答、升级或显示差异 |
| Eval coverage | 每个 context 有自己的 gold cases |
如果一个企业 RAG 平台不支持 context metadata, 它最终会把语义风险转嫁给 prompt 和人工复核。
5. Eval Vocabulary
AI eval 必须使用业务语言, 否则评测会变成泛化语言质量测试。
| 领域词汇 | Eval 设计 |
|---|---|
| Reason code | 输出是否使用批准 reason code |
| KYC exception | 是否识别例外类型和补件路径 |
| AML typology | 是否引用正确 typology 和红旗信号 |
| Customer complaint | 是否区分 complaint、inquiry、dispute |
| Advice boundary | 是否越界到投资/信贷建议 |
| Case closure | 是否满足关闭条件和审批证据 |
Eval vocabulary 要进入:
- golden set。
- failure taxonomy。
- human review rubric。
- monitoring tag。
- incident postmortem。
6. Financial Retail Case: Context Map
Customer Service Context
-> Credit Servicing Context
-> Credit Underwriting Context
-> Model Risk Context
-> Compliance Context
问题:
客户问“为什么我的申请被拒了？”
客服上下文能做:
- 解释流程状态。
- 说明需要联系哪个渠道。
- 提供已批准的通用说明。
信贷服务上下文能做:
- 查看申请状态。
- 引用 approved reason code。
- 生成客户可理解解释。
信贷审批上下文能做:
- 分析申请材料。
- 支持 underwriter 判断。
模型风险上下文能做:
- 检查模型版本、性能、漂移、验证证据。
如果 AI assistant 混用这些上下文, 可能把内部审批逻辑直接暴露给客户, 或用客服知识解释授信决策。
7. Artifact Templates
AI Domain Model Canvas
| 字段 | 内容 |
|---|---|
| Bounded context | 上下文名称 |
| Core domain problem | 核心业务问题 |
| Ubiquitous language | 关键术语 |
| Domain events | 关键事件 |
| Aggregates | 关键业务对象 |
| Policies | 规则/约束 |
| AI tasks | AI 可做的任务 |
| Forbidden tasks | AI 不可做的任务 |
| Knowledge sources | 权威知识源 |
| Eval vocabulary | 评测术语和失败标签 |
RAG Boundary Matrix
| Context | Source | Owner | Version | Permission | Ambiguous Terms | Eval Set |
|---|---|---|---|---|---|---|
| 上下文 | 知识源 | owner | 版本 | 权限 | 歧义词 | gold cases |
8. ADR Draft
| 项目 | 内容 |
|---|---|
| 决策 | 高风险金融 AI use case 必须先定义 bounded context、ubiquitous language 和 RAG boundary, 再进入 solution design |
| 背景 | AI 系统容易跨上下文混用术语、知识源、规则和工具 |
| 替代方案 | 只写 PRD; 只做流程图; 统一企业向量库; 依赖 prompt 约束 |
| 选择理由 | DDD 能将业务语义、系统边界、知识治理、工具权限和 eval taxonomy 连接 |
| 影响 | 需要 domain owner、glossary、context map、source registry 和 context-specific eval set |
| 反转条件 | 低风险内部通用助手可使用轻量版 glossary + source boundary |
9. 面试表达
30 秒版本
AI 产品需要 DDD, 因为模型虽然会读自然语言, 但不自动理解企业里的上下文边界。同一个词在 AML、信贷、客服、模型风险里可能含义不同。我会先定义 bounded context 和 ubiquitous language, 再设计 RAG boundary、tool boundary 和 eval vocabulary, 防止 AI 在错误上下文里回答或行动。
2 分钟版本
我会把 AI task 放进 bounded context 里设计。每个任务都要说明它属于哪个领域、能用哪些知识源、能访问哪些数据、能调用哪些工具、哪些术语有专门含义、哪些输出需要人工复核。然后用 context map 处理跨系统和跨业务线协作。 比如客户问信贷拒绝原因, 客服上下文只能解释流程和通用说明, 信贷服务上下文可以引用 approved reason code, 信贷审批上下文涉及内部判断, 模型风险上下文涉及验证证据。AI 如果混用这些上下文, 就可能产生合规和客户权益风险。
Enterprise Architect 版本
从架构角度, DDD 是 AI reference architecture 的语义层。没有 bounded context, model gateway、RAG、tool gateway、policy engine 和 eval 都缺少业务边界。成熟做法是把 ubiquitous language 放进 metadata、schema、prompt、eval、audit trace 和 product analytics, 让架构能长期演进。