AI 底层逻辑 / 经典论文
Conway / Team Topologies：AI 平台组织模型
一句话:
265 行ai-foundations/papers/69-conway-team-topologies-ai-platform-operating-model.md
Conway's Law / Team Topologies / AI Platform Operating Model 解读
面向对象: Enterprise Architect / AI Platform Lead / AI PM / Engineering Manager / Senior BA / Transformation Lead。 核心问题: AI 架构失败常被解释为技术问题, 但根因经常是组织拓扑问题: 数据团队、平台团队、业务团队、模型风险、合规、安全和运营各自优化, 最终系统接口、责任和反馈也碎裂。 学习目标: 用 Conway's Law 和 Team Topologies 的思维, 设计企业 AI 平台与 AI 产品团队的边界、认知负载、交互模式和 operating model。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Conway's Law / Melvin Conway | https://www.melconway.com/Home/Conways_Law.html | 参考系统设计会反映组织沟通结构的核心思想 |
| Team Topologies | https://teamtopologies.com/ | 参考 stream-aligned、platform、enabling、complicated-subsystem team 和 interaction modes |
| Team Topologies Key Concepts | https://teamtopologies.com/key-concepts | 参考 cognitive load、team API、interaction modes、fast flow 的实践语言 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把组织拓扑连接到 AI 风险治理、角色、责任和持续管理 |
一句话:
AI 平台 operating model 的关键不是画组织图, 而是让团队边界、认知负载和交互模式支持安全、快速、可治理的 AI 价值流。
1. Conway's Law 对 AI 的含义
如果组织结构是:
业务团队 -> 数据团队 -> AI 平台 -> 安全 -> 合规 -> 模型风险 -> 运维
且沟通只通过工单、会议和审批, 系统很可能变成:
业务 UI -> 数据接口 -> 模型 API -> 安全网关 -> 合规检查 -> 风险审批 -> 运维脚本
问题不是分工本身, 而是:
- 责任边界按职能切开, 但 AI 风险按端到端工作流发生。
- 反馈从生产回到 eval 和需求的路径太长。
- 平台团队不了解 domain semantics。
- 业务团队不了解模型和数据约束。
- 风险团队只在上线前出现, 无法参与 design-time control。
AI 架构要和团队拓扑共同设计。
2. Team Types 迁移到 AI
| Team Type | AI 语境 | 主要责任 |
|---|---|---|
| Stream-Aligned Team | AML Copilot、客服 Copilot、信贷决策产品团队 | 端到端业务价值、用户流程、domain eval、adoption |
| Platform Team | AI Gateway、RAG Platform、EvalOps、Tool Gateway | 降低其他团队认知负载, 提供 self-service 能力 |
| Enabling Team | AI governance enablement、prompt/RAG enablement、risk enablement | 帮助业务团队掌握新能力, 临时嵌入和 coaching |
| Complicated-Subsystem Team | 模型优化、搜索排序、隐私计算、图模型、实时特征 | 处理高专业复杂度组件 |
错误组织方式:
- 让平台团队直接拥有所有 AI use cases。
- 让每个业务团队自建完整 AI stack。
- 让模型风险团队只做上线前审批。
- 让安全团队只审查结果, 不参与 tool gateway 设计。
3. Cognitive Load
AI 产品团队需要同时理解:
- 业务流程。
- 用户体验。
- 数据权限。
- RAG。
- prompt。
- model behavior。
- eval。
- risk controls。
- observability。
- incident response。
- change management。
认知负载过高时, 团队会:
- 绕过平台。
- 只做 demo。
- 不写 eval。
- 忽略监控。
- 把风险转给人工。
平台团队的目标不是控制所有事, 而是降低 stream-aligned team 的认知负载:
| 平台能力 | 降低的负载 |
|---|---|
| Model Gateway | 模型接入、路由、成本、供应商差异 |
| RAG Platform | ingest、chunk、index、permission、citation |
| EvalOps | dataset registry、judge、release gate、regression |
| Tool Gateway | tool schema、auth、policy check、audit |
| Observability | trace、latency、cost、quality、incident |
4. Team API
AI 平台团队需要定义 Team API:
# AI Platform Team API
## Services
- Model Gateway
- RAG Indexing
- EvalOps
- Tool Gateway
- Observability
## How to Consume
- SDK / API:
- Self-service portal:
- Golden path:
- Support hours:
## Responsibilities
- Platform owns:
- Product team owns:
- Risk team owns:
- Data owner owns:
## Service Levels
- Availability:
- Latency:
- Incident response:
- Change notification:
## Governance
- Required gates:
- Evidence artifacts:
- Escalation:
没有 Team API, 平台会变成“找人问”的内部咨询团队。
5. Interaction Modes
| 模式 | AI 场景 | 适用 |
|---|---|---|
| Collaboration | 新高风险 use case 早期探索 | AML agent、信贷解释、客户 facing AI |
| X-as-a-Service | 成熟平台能力消费 | model gateway、embedding service、trace dashboard |
| Facilitating | enabling team 帮业务团队掌握方法 | eval contract、HITL design、red-team |
成熟路线:
Collaboration -> Facilitating -> X-as-a-Service
例如 RAG:
- 早期平台和业务共同设计知识源、权限和 eval。
- enabling team 帮业务团队建立 knowledge governance。
- 成熟后业务团队通过 self-service ingestion 和 eval gate 使用平台。
6. 金融零售案例
6.1 AML Copilot
推荐拓扑:
- Stream team: AML Copilot product team。
- Platform: AI gateway、RAG、EvalOps。
- Complicated subsystem: graph/entity resolution。
- Enabling: model risk + AI governance coach。
关键接口:
- AML team owns typology and golden set。
- Platform owns retrieval pipeline and trace。
- Model Risk owns validation criteria and review cadence。
- Ops owns analyst workload and feedback。
6.2 客服知识平台
如果每个渠道团队自己做 RAG, 会产生:
- 政策版本不一致。
- 权限模型不一致。
- citation quality 不一致。
- feedback 无法汇总。
更好的拓扑:
- Platform owns knowledge ingestion and retrieval service。
- Customer service product team owns intent taxonomy and response policy。
- Compliance owns approved language and escalation criteria。
- Ops owns adoption and coaching。
7. AI Operating Model Patterns
| 模式 | 适合 | 风险 |
|---|---|---|
| Central AI Factory | 早期能力集中、稀缺专家 | 远离业务, 交付瓶颈 |
| Federated AI Teams | 多业务线并行创新 | 重复建设、治理不一致 |
| Platform + Stream Teams | 规模化企业 AI | 需要强平台产品能力 |
| Risk-Embedded Model | 高风险金融场景 | 决策慢, 需要明确 interaction mode |
| Enabling Guild | 快速扩散方法 | 如果无 owner, 容易变社区活动 |
推荐目标状态:
Stream-aligned AI product teams
consume AI platform golden paths
supported by enabling teams
governed by embedded risk/security/privacy patterns
with complicated subsystem teams for hard domains
8. 反模式
| 反模式 | 表现 | 后果 |
|---|---|---|
| AI Center owns everything | 所有 AI 需求都排队给中心团队 | 速度慢, 业务责任弱 |
| Business teams own full stack | 每个团队自建 RAG/LLM/eval | 成本高, 风险失控 |
| Risk as final approver only | 风险只在上线前审 | 控制补丁化, 返工大 |
| Platform without product thinking | 平台只交付 API | adoption 低, golden path 不清 |
| Guild without decision rights | 大量分享, 无实际标准 | 方法不一致 |
9. 面试回答
Q: AI 平台组织应该集中还是分散？
30 秒版本:
我会避免二选一。企业 AI 通常需要平台 + stream-aligned team 的混合拓扑: 平台团队提供 model gateway、RAG、EvalOps、tool gateway 和 observability, 业务产品团队拥有用户、流程、domain eval 和风险结果。高复杂组件由 specialist team 支撑, enabling team 帮助方法扩散。
Q: Conway's Law 如何影响 AI 架构？
30 秒版本:
如果组织沟通被职能墙切开, AI 系统也会在数据、模型、风险、运营之间形成脆弱接口。AI 架构要和团队拓扑一起设计, 确保端到端反馈、owner 和控制路径清晰。
10. 作品集交付物
- AI Team Topology Map。
- AI Platform Team API。
- Stream Team Responsibility Matrix。
- Cognitive Load Assessment。
- Interaction Mode Design。
- AI Operating Model RACI。
- Conway Risk Review。
这套材料能证明你不只是会画系统架构, 还懂组织结构如何塑造 AI 系统质量、交付速度和治理能力。