实施人工智能：企业在扩展模型方面存在哪些错误

高管们正在向人工智能投入数百万美元，但 BCG 2025 年的一项研究发现，只有约5% 的公司从人工智能中大规模获得了可衡量的价值，而大多数公司却很少看到或根本没有。与此同时，多项调查显示，由于数据贫乏、治理薄弱和商业价值不明确，超过一半的人工智能项目从未投入生产或在概念验证后被放弃。

问题不在于缺乏聪明的模型。问题在于这些模型如何日复一日地运行、拥有和维护。换句话说，人工智能运营是最大的风险和最大的优势所在。

这篇客座文章探讨了为什么扩展人工智能如此频繁地失败，战壕中出现了什么问题，以及运营优先的方法如何改变轨迹。

为什么大多数企业扩展人工智能都失败了？

大多数大型组织都不缺乏人工智能实验。麦肯锡最新的人工智能现状调查显示，几乎所有受访者都表示在某些地方使用了人工智能，但只有一小部分人看到了持续的企业级影响。

实践中会发生什么：

• 跨业务部门启动了数十个概念验证
• 少数在演示中看起来很有希望
• 很少有人能够通过安全审查、集成工作和真实的用户反馈

在这种模式之下存在一些可预见的问题：

• 人工智能是一种一次性的“举措”而不是一种运营能力
  人工智能被视为一个有开始和结束日期的项目。有一个预算周期、一个供应商、一个仪表板、一个演示文稿。我们缺少的是把人工智能视为一种需要路线图、所有权和运行预算的产品的观点。
• 忽视生产环境的试点
  许多试点默默地依赖于手工整理的数据集、手动特征工程或单个高级用户。这些都不存在于实时生态系统中。当团队尝试将相同的工件投入生产时，从数据访问到延迟行为的一切都会立即发生变化。
• 没有扩大规模的经济观点
  董事会听说过有关生产力提高 10 倍的故事。他们很少看到的是基础设施、可观察性、模型更新和变更管理的成本视图。如果没有这一点，当第一波项目令人失望时，期望就会螺旋式上升，人工智能最终会被列入“失败的创新”名单。

大多数企业人工智能扩展手册仍然假设，一旦选择了正确的模型和平台，剩下的主要是执行细节。事实上，你设计和运行人工智能操作的方式通常比你首先选择哪种大型语言模型更重要。

常见的操作陷阱

当我查看失败或停滞的人工智能计划时，我几乎总是发现相同的操作模式。

你在野外看到的陷阱

在这些症状的背后，一些结构性问题不断显现：

• 碎片化的数据供应链
  用于训练、测试和服务的数据来自不同的路径，但数据管理服务统一这些管道以减少漂移和不稳定。模型在测试中表现良好，但在生产中表现不佳，因为输入分布和新鲜度完全不同。
• 跨界协作
  数据科学家拥有笔记本。平台团队拥有自己的集群。企业主拥有 KPI。没有人拥有从概念到退休的整个生命周期。每次交接都会带来延误、返工和与期望的微妙不匹配。
• 操作风险被视为事后考虑
  一旦产品即将推出，法律、合规性和安全性就会被纳入讨论范围。他们看到了完整的解决方案，提出了合理的担忧，然后项目陷入停滞。感觉就像“治理正在阻碍人工智能”，而真正的问题是后期参与。

如果没有人工智能运营策略，飞行员就会陷入困境。你最终会得到一些有趣的工作，但这些工作永远不会融入公司的运作方式。

MLOps 是人工智能操作中缺失的一环

MLOps 通常被描述为“机器学习的 DevOps”。这个定义在技术上是正确的，但它低估了正在发生的事情。在实践中，MLOps 是将模型转变为可运行的系统并将其与实际业务成果联系起来的学科。

您可以将AI 操作视为 MLOps 必须结合在一起的三个层：

• 资产

对 MLOps 采用的研究表明，工作流程编排、可重复性、版本控制和监控等实践都与更高的用户满意度和更好的结果相关。这听起来很抽象，直到您注意到缺少这些实践时故障模式是多么具体。

MLOps 不是一次性购买的工具类别。它是让您的数据科学、平台和产品团队作为一个系统运行的运营支柱。这就是为什么它是严肃的人工智能运营计划的核心。

在现实生活中发挥作用的治理和监控

许多企业通过编写长篇政策文件来应对人工智能风险。很少有人能够将这些文档转化为构建和运行模型的团队的日常工作。

成熟的人工智能运营倾向于将治理构建为三个实际循环：

• 技术监控回路

最近的行业分析指出，糟糕的数据治理和薄弱的人工智能监管已经成为许多人工智能项目预计在未来 1-2​​ 年内失败或被取消的主要原因。

我合作过的最成功的组织将这些循环视为其人工智能运营手册的一部分，而不是单独的“风险举措”。他们尽可能地实现自动化（数据沿袭、访问控制检查、偏差检测），并在需要判断的地方花费人力。

成功扩展人工智能的案例​​研究

为了具体说明这一点，让我们看一下两种经常出现的匿名模式。

案例研究 1：从概念验证剧场到 AI 制作

一家全球零售商在各个试点阶段拥有 40 多个人工智能用例：需求预测、动态定价、营销个性化和商店运营。任何时候都只有两个处于活动状态，并且都需要持续的人工干预。

关键问题：

• 每个团队都建立了自己的管道和基础设施模式
• 没有监控、数据访问或模型部署的共享标准
• 企业主将人工智能视为“IT 项目”，而不是其损益表的一部分

该公司改变策略，成立了一个小型中央人工智能运营小组，负责三项职责：

• 定义和维护参考 MLOps 堆栈（数据摄取模式、训练和服务管道、实验跟踪、模型注册）。
• 制定并执行可观察性、治理和成本报告的标准。
• 指导业务团队将人工智能用例视为具有所有者、成功指标和路线图的产品。

18 个月内：

• 从想法到首次产品发布的时间从 9-12 个月缩短至约 8 周
• 超过 20 个模型使用共享工具运行，而不是定制脚本
• 季度审查将每个用例与对利润和库存的可衡量影响联系起来

有趣的部分是没有改变的部分。底层模型保持相当相似。这一步骤的变化来自于通过共享操作进行规范的企业人工智能扩展，而不是来自奇异的新算法。

案例研究 2：工业人工智能在与现实接触中仍能生存

一家工业制造商尝试对关键设备使用预测维护模型。第一次尝试失败了。根据历史传感器数据训练的模型在离线测试中看起来很准确，但在生产中却产生了太多的误报。技术人员不再关注。

内部审查发现了三个根本原因：

• 训练数据的清理方式并未反映真实的传感器噪声
• 实时管道缺少训练中出现的两个关键信号
• 没有人描绘出模型预测将如何改变技术人员的工作流程

在第二次尝试中，团队将这项工作重新定义为企业人工智能扩展问题，而不是数据科学竞赛。

他们：

• 为传感器流定义了明确的“数据契约”，并保证采样频率、单位和丢失数据处理
• 实施了从摄取到服务的统一 MLOps 管道，因此重新训练的模型可以以最小的摩擦投入生产
• 让技术人员参与设计，并根据实际情况调整阈值和警报格式

现在的监测包括漂移指示器和现场反馈。当模型开始退化时，再训练是通过相同的标准化管道进行的，而不是一次性的救援项目。

一年之内，目标资产类别的计划外停机时间大幅减少。最重要的变化是整个管道的可靠性，而不是模型准确性的大幅跃升。

从这里到哪里去？

如果您认真对待扩展模型，请首先将人工智能操作视为一流学科：

• 绘制 2-3 个高价值用例从数据摄取到报废的完整生命周期
• 确定使模型保持活力的每个手动步骤、交接和“影子流程”
• 决定 MLOps 堆栈的哪些元素将被共享，固执己见的默认值
• 将治理和监控构建到这些默认设置中，而不是将它们置于顶层

在下一波人工智能浪潮中发挥重要作用的组织并不是那些拥有最华丽演示的组织。他们能够月复一月地悄悄地运行和发展数十种生产模型，而不会出现戏剧性的情况。如果你能让人工智能操作达到那种成熟程度，那么你的故事的其余部分就会开始水到渠成。