返回首页

AI

把 AI 业务战略与日常应用,连接到负责任的采用与工作负载工程实践。

我如何看待 AI

把 AI 当作工程实践而不是演示:有用、可治理、可度量。

我用做云平台的方法来做 AI:从工程师真实遇到的问题出发,建立在受治理的基础之上,并依据可度量的结果持续改进。日常工作中,这意味着构建能减少工程摩擦的 AI 工具与智能体,并确保它们运行在清晰的身份、数据与成本边界之内。

CAF for AI (Microsoft Learn,在新标签页打开)

Cloud Adoption Framework 的 AI 场景描绘了组织层面的路径:战略、规划、就绪,再把 AI 的治理、管理与安全作为持续实践。

Well-Architected for AI (Microsoft Learn,在新标签页打开)

Well-Architected AI 指南把五大支柱应用到非确定性的工作负载上,覆盖模型训练、托管、推理与评估。

框架提供的是问题;具体工具的选择取决于平台、数据敏感度以及团队的真实需求。

组织如何采用 AI

以 CAF AI 采用指南(Microsoft Learn,在新标签页打开) 为参照。无论选择哪家模型或平台,这条路径都适用。

采用 AI 不是买一个模型,而是一系列决策:AI 在哪里创造价值,组织又如何让它始终受控。与云采用一样,前几步按顺序推进,运营环节则持续进行。

AI 采用 · 顺序推进

  1. 01AI 战略
  2. 02AI 规划
  3. 03AI 就绪

运营 · 并行持续

  • 治理 AI
  • 管理 AI
  • 保护 AI
改编自 CAF AI 场景:按顺序打好基础,然后在 AI 运行的整个周期内持续治理、管理与保护。
  1. AI 战略

    哪些场景值得做?选择价值可度量的问题,在 SaaS、PaaS 与 IaaS 形态的 AI 之间做取舍,并制定数据与负责任 AI 策略。

  2. AI 规划

    组织是否具备交付所需的技能、数据与访问?评估就绪度、补齐技能短板,并确定概念验证的优先级。

  3. AI 就绪

    是否有可依托的基础?建立 AI 着陆区,提前规划网络、身份、模型访问与配额。

  4. 治理 AI

    风险是否受控?为模型与数据使用制定策略,用护栏强制执行,并跟踪合规与成本。

  5. 管理 AI

    AI 是否被当作产品来运营?标准化部署,监控质量与漂移,并管理模型与提示词的生命周期。

  6. 保护 AI

    AI 能否抵御新的威胁?通过身份、网络与内容控制,防范提示注入、数据泄露与模型滥用。

大多数 AI 风险是带着新攻击面的普通平台风险:复用云着陆区、身份与成本控制,而不是为 AI 另起一套体系。

负责任的 AI

以 微软负责任 AI 原则(Microsoft Learn,在新标签页打开) 为参照。原则只有落到交付流程中的检查项,才真正有意义。

我把这六项原则当作每个 AI 功能的评审问题:发布前作答,并随着系统与用户的变化持续复查。

公平性 Fairness

系统是否以相同方式对待相似的人?跨用户群体评估输出,修正数据或提示词中的偏差。

可靠与安全 Reliability & Safety

面对意外输入,它是否仍按预期工作?测试边界情况、过滤有害内容,并在关键操作中保留人工确认。

隐私与安全 Privacy & Security

数据是否被端到端保护?最小化个人数据,在检索中遵守访问边界,并防范提示注入。

包容性 Inclusiveness

是否人人可用?为不同语言、能力与场景而设计,包括像我们这样的双语团队。

透明度 Transparency

用户是否知道自己在与 AI 交互、它的能力边界在哪?披露 AI 的使用、注明来源,并记录局限性。

问责 Accountability

谁对结果负责?明确责任人,保留审计记录,并定义问题的上报与修复流程。

落地方式:把答案写进设计评审,能自动化测试的就自动化,其余作为明确、有人负责的检查清单。

设计 AI 工作负载

以 Well-Architected AI 工作负载指南(Microsoft Learn,在新标签页打开) 为参照。同样的五个支柱,用于非确定性的系统。

AI 工作负载行为具有非确定性,并把代码与数据融合为模型,因此质量需要持续度量,而不是一次验证。下面按支柱整理了 WAF 在模型训练、托管与推理上的设计原则。

可靠性 Reliability

5
  • 消除单点故障

    为所有关键组件构建冗余,优先选择自带容错与高可用能力的平台。

  • 开展故障模式分析,复用成熟模式

    用隔舱模式隔离故障,用重试与断路器处理限流等瞬时错误。

  • 在依赖组件之间平衡可靠性

    推理端点、数据存储与服务 API 采用一致的可靠性目标,必要时使用可用区或多区域。

  • 为运营可靠性而设计

    通过及时、自动化的重新训练保持模型输出新鲜;离线训练依据成本收益分析决定。

  • 为可靠的用户体验而设计

    在并发高峰下做压测,在界面中提示等待时间,并采用异步模式。

安全性 Security

6
  • 赢得用户信任

    在整个生命周期落实内容安全,从存储、索引与缓存中清除不必要的个人数据,并对输入输出双向审核。

  • 保护静态、传输中与使用中的数据

    加密所有数据存储,每一跳都使用 TLS,并把模型本身视为可能泄露训练数据的高价值资产。

  • 投资身份与访问管理

    在控制面与数据面实施 RBAC 或 ABAC,并做身份隔离,让用户只能访问被授权的内容。

  • 通过分段保护设计完整性

    以私有网络访问镜像、数据与代码仓库,并将推理节点池与其他工作负载隔离。

  • 持续开展安全测试

    每次变更都测试不当行为,把推理端点纳入常规测试,并进行红队演练。

  • 缩小攻击面

    所有推理端点(包括系统间调用)都需认证,优先采用受约束的 API 设计。

成本优化 Cost Optimization

4
  • 建立成本模型

    评估数据量、查询量、所需吞吐,以及索引技能集等隐藏的依赖成本。

  • 只为需要的能力付费

    按真实用量选择层级,可中断的训练使用竞价实例,GPU 只用于 AI 任务,并对 SKU 做基准测试。

  • 用好已付费的资源

    监控利用率,探索分析与训练算力空闲即停止,存储采用一次写入多次读取,并明确成本责任人。

  • 优化运营成本

    自动化重新训练,在精度允许时接受稍旧的数据,并清理特征库中无用的特征。

卓越运营 Operational Excellence

6
  • 培养持续实验的文化

    建立在 DevOps、DataOps、MLOps 与 GenAIOps 之上,尽早就“可接受的模型表现”达成共识。

  • 降低运营负担

    优先选择托管平台服务而非自建,简化编排与日常运维。

  • 自动化监控、告警与审计

    尽早与数据科学家定义质量指标,追踪实验过程,并给出可执行的告警。

  • 自动检测并应对模型衰减

    自动化测试漂移,输出偏离预期时告警,并随用例变化调整数据处理与训练。

  • 安全地部署

    选择并行部署或原地更新,发布前对照质量目标测试,并准备应急预案。

  • 在生产中评估用户体验

    收集用户反馈,并在获得同意后记录对话,用真实交互衡量质量。

性能效率 Performance Efficiency

4
  • 建立性能基准

    为模型质量与平台性能建立基线,并持续复评,而不是一次性测试。

  • 按性能目标评估资源

    通过压测选择平台与 SKU:训练与微调使用 GPU,编排使用通用算力。

  • 采集指标、定位瓶颈

    追踪数据管道吞吐、搜索延迟与相关性、编排耗时与用户参与度,包括多模态带来的延迟。

  • 用生产信号持续改进

    自动化指标采集、告警与重新训练,让模型长期保持有效。

设计领域

技术
应用设计 · 应用平台 · 训练数据 · 落地数据 · 数据平台
运营
工作负载运营 · MLOps 与 GenAIOps · 测试与评估 · 负责任的 AI

取舍:最高等级的安全控制会限制对加密数据的检查与日志记录,GPU 带来的性能也必须与成本权衡;应持续调整规格并记录这些决策。