企业 AI 项目在数据阶段失败——而非模型阶段

65%的企业 AI 部署正在停滞。这个数字已经大致保持恒定三年了，这意味着问题是结构性的，而非偶然性的。新一代基础模型没有解决它。更好的 MLOps 工具、更多的 ML 工程师人数或更多的高管支持也没有。

传统的诊断归咎于错误的阶段。当企业 AI 项目未能交付时，事后分析通常关注模型选择（"我们应该使用不同的架构「）、基础设施（」我们的云端设置不对「）或组织准备度（」我们需要更多的 AI 素养"）。这些并非总是错的。但它们几乎总是不完整的——而且经常在为真正的罪魁祸首开脱。

企业 AI 项目停滞的真正原因几乎总是相同的：数据没有准备好，也没有人分配时间或工具来使其准备好。

数字并不含糊

研究是一致的，而且已经一致多年了。

行业共识——跨越 MIT、McKinsey、Gartner 和大规模实践者——将60到80%的 ML 项目时间归于数据准备，而非模型训练。不是部署、不是评估、不是基础设施配置。数据准备。

Forrester 在2024年与 Capital One 联合对500名企业数据领导者进行的调查中发现，73%将数据质量和准备确定为 AI 成功的头号障碍。不是模型质量。不是计算成本。不是治理。数据质量和准备。

IBM 和 MIT 的研究一致发现，80到90%的企业数据是非结构化的——文档、电子邮件、图像、PDF、手写记录、遗留数据库导出。这些是大多数企业 AI 系统需要学习的数据，也是在任何训练或检索系统使用之前需要最多准备的数据。

只有30%的组织使用 AI 进行自动化数据准备。其余70%在手动处理、使用自定义脚本或根本没有处理。

这些数字汇成一幅清晰的图景。大多数企业组织的大部分数据都是 AI 无法直接消费的格式。他们大部分 ML 项目时间都在试图解决这个问题。而且他们大多数仍然未能按时交付可工作的 AI 系统。

团队对自己讲的故事

企业 AI 团队解释失败或停滞项目的方式有一个可预测的模式。故事经历几个阶段。

**阶段1：乐观。**试点获批。用例明确。数据源已确定。团队选择模型、搭建基础设施，然后开始。

**阶段2：摩擦。**数据比预期的更混乱。文件格式是管道无法解析的。标签不一致。领域专家无法操作标注工具。合规审查标记了基于云的工具。时间表滑动。

**阶段3：转向。**面对缓慢的进展，团队尝试不同的方法：不同的模型、不同的提示策略、更多计算、更多工程师。这些感觉像是行动。它们很少解决实际问题。

**阶段4：停滞。**经过几次转向后，项目超预算、超时间表、低于预期。原始数据问题没有被解决——它被绕过了，产生了技术债务和可靠性问题。

**阶段5：事后分析。**结论通常是关于组织准备度、模型局限性或基础设施挑战。底层的数据问题如果被提及的话，也只是简要地承认。

数据问题在事后分析中被低估的原因是它感觉不像战略失败。它感觉像执行失败——一个肮脏的、不光彩的问题，团队中的某个人应该已经解决了。承认数据准备阶段是瓶颈感觉像是承认你没有做好基本工作。所以团队寻找更复杂的解释。

为什么数据是原因时模型被归咎

模型性能是最常见的错误诊断有一个原因。

模型质量是可衡量的。你可以计算准确率、F1分数、BLEU分数、人类偏好评分。当模型表现不佳时，指标清楚地告诉你。数据质量更难衡量——尤其是在训练之前，问题是潜在的。

质量差的训练数据会产生看起来在工作直到它们不工作的模型。在不一致标注的数据上训练的模型会显得在学习，并产生看似合理的输出。不一致性表现为性能上限——无论超参数如何更改，模型都不会超过某个点。但从外部看，这个上限看起来像模型限制。团队转向更大的模型、不同的架构或更多的训练计算。这些都不起作用，因为它们都没有解决根本原因。

数据量也是如此。认为自己有数据质量问题的团队有时试图用数据数量来解决：收集更多样本、生成合成数据、运行更多标注轮次。如果底层数据嘈杂或标注不一致，更多的数据只会放大问题。模型在更大但质量相同的数据集上训练，产生相同的（有时更差的）结果。

五种失败模式

在我们合作和交谈过的组织中，数据阶段的企业 AI 失败分为五种可识别的模式。

1. 在数据准备好之前就开始

最常见的模式是在训练数据被充分准备之前就开始模型训练。这通常是时间线压力问题：里程碑要求可展示的进展，而"我们仍在准备数据"对利益相关者来说不像进展。

结果是可预见的。团队在不完美的数据上训练，看到不完美的结果，在训练而非数据上迭代，花数月在由数据质量而非模型能力设定的上限上做边际改进。

MIT Sloan 的研究发现，成功的 AI 项目会反转典型的支出比例，在任何训练开始之前将50到70%的项目时间线用于数据准备。这令人不舒服，因为它延迟了可见的输出。它也显著提高了成功率。

2. 碎片化工具栈

大多数企业团队使用三到七个工具进行数据准备：用于摄入的文档解析器、用于标注的标注平台、用于清理的质量评分库、可能用于增强的合成数据工具。每个工具在隔离使用时都很有能力。失败存在于它们之间的集成中。

没有共享数据格式意味着在每个转换点都需要自定义转换代码。没有共享审计追踪意味着你无法用单一血缘报告证明合规性。当任何一个工具更新时，自定义粘合代码就会中断。本应用于构建模型的 ML 工程时间花在了维护管道上。

3. 没有审计追踪

在受监管行业——医疗、法律、金融服务、国防——AI 系统需要可证明的数据来源。这个训练样本来自哪里？谁标注的？是否被修改过？标注时使用的标注模式是什么版本？

大多数数据准备工具栈无法在整个管道中回答这些问题。各个工具可能有内部日志，但没有跨越摄入到导出的统一血缘记录。这不仅是合规风险——它也是质量信号。无法将训练数据追溯到其来源的团队无法自信地确定错误在管道的哪个位置引入的。

4. 领域专家差距

最适合生成高质量标签的人是领域专家：医疗数据的医生、法律文档的律师、技术规格的工程师。可用的标注工具是为数据科学家和 ML 工程师构建的——它们需要 Python 环境、Docker 设置、命令行熟练度或复杂的 Web 应用配置。

结果是领域专家要么被完全排除在标注过程之外（被那些判断领域特定正确性资质较低的 ML 工程师取代），要么他们需要大量支持来使用工具，以至于领域专业知识的吞吐量优势被设置和操作开销吃掉了。

5. 合规阻碍

对于受监管行业，云原生工具通常是不允许的。HIPAA 限制了患者数据可以在哪里处理。GDPR 控制跨境数据传输。法律特权规则限制客户文件的处理。内部信息安全政策增加了额外的限制。

大多数商业数据准备工具是云原生的。受监管行业的团队要么接受合规风险（接受他们可能不完全理解的责任），要么自建工具（昂贵且缓慢），要么退回到无法扩展的手动流程。

改变方法是什么样的

成功驾驭企业 AI 采用的组织有几个共同特征，使它们与停滞的组织区分开来。

**他们将数据准备视为主要项目阶段，而非初步步骤。**不是将项目时间线的10%用于数据、90%用于模型开发，而是反转这个比例。数据准备是里程碑。训练是数据准备好后发生的事情。

**他们在训练之前衡量数据质量。**这意味着对标注数据集运行质量审计，检查标签一致性率，验证训练数据分布与预期生产分布匹配，以及验证解析质量在所有范围内的文档格式上是否足够。

**他们从一开始就让领域专家参与标注。**这需要领域专家无需 ML 工程支持即可操作的工具——像应用程序一样安装的工具，而不是像开发环境一样安装的工具。领域专家标注的生产力和质量收益持续超过工具设置投资。

**他们在整个管道中建立统一的审计追踪。**这不仅仅是合规要求——它是工程卫生要求。能够将任何训练样本从源文档追溯到导出，并记录应用的每个转换，对于调试模型故障和满足监管审计员至关重要。

**他们在受监管环境中使用本地工具。**这对医疗、法律和金融服务组织来说不是可选的。它是从一开始就塑造每个工具选择决策的约束。

关于企业 AI 时间表的不舒服的事实

企业 AI 项目的时间表预期系统性地校准不当。

当一个组织开始一个以在内部文档上微调模型为目标的企业 AI 项目时，典型的初始估计是三到六个月。考虑到数据准备阶段的现实估计通常是九到十八个月——额外的时间几乎完全在数据准备上。

这不是绝望的建议。这是前置工作的论据。为数据准备分配现实时间并投资于使准备高效的工具的团队可以在九到十二个月内完成项目。试图压缩数据准备并过早开始训练的团队通常花费十二到二十四个月才能达到相同的质量门槛——或者他们永远达不到。

数学并不复杂。按正确顺序做事的纪律才是难的。

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →