27个企业 AI 团队告诉我们的数据准备难题

我们在六个月内对受监管行业进行了27次需求发现访谈。对话涵盖了工程和建筑公司、医疗机构、律师事务所、金融服务团队、端侧 AI 初创公司，以及为企业客户构建解决方案的 AI 机构。

我们询问了 AI 采用目标、当前工具、障碍以及时间实际花在哪里。我们预期会得到各种各样的答案。我们得到的模式是如此一致，几乎令人不安。

九个不同的理想客户画像将数据准备命名为他们的头号 AI 痛点——在我们直接询问之前就主动提出了。具体问题各不相同：文件格式、监管限制、标注复杂性、基础设施限制。但根本原因始终相同。在原始业务数据和 AI 就绪训练数据之间存在一个缺失的层，没有人有好的解决方案来弥合它。

以下是他们告诉我们的。

我们交谈的团队

27次访谈的大致分布如下：

• **工程和建筑公司（4家）：**管理大量文档档案——工程量清单、规格说明书、工程图纸、项目报告——积累了多年的 PDF、扫描文件和遗留格式数据。
• **医疗机构（5家）：**临床笔记、患者记录、影像报告、计费数据。HIPAA 合规要求意味着云端工具实际上不可用。
• **律师事务所和法律科技公司（4家）：**合同库、案件文件、监管备案文件。数据特权和客户保密性产生了与医疗行业类似的限制。
• **金融服务和金融科技（3家）：**交易记录、合规文档、风险评估。监管审计追踪要求在标准 AI 工具之上增加了一层复杂性。
• **端侧和边缘 AI 公司（4家）：**构建设计在硬件上本地运行的 AI 产品。他们自己的数据准备管道正在阻碍产品开发时间表。
• **AI 机构（5家）：**为企业客户构建 AI 系统。他们报告的问题通常是客户问题的代理——他们自己在吸收数据准备的复杂性。
• **早期 AI 初创公司（2家）：**笔记、文档智能、知识管理。更小的团队但同样的数据问题，压缩到了创始人的时间中。

在所有这些团队中，9个团队将数据准备命名为 AI 项目的主要瓶颈——在模型选择、基础设施、合规审查之前。在大多数情况下，他们已经解决了其他领域。数据是剩下的问题。

"数据准备"对每个细分领域的实际含义

更有趣的发现之一是，"数据准备"对不同行业的含义确实不同——但痛苦的体验是相同的。

对于工程和建筑公司，数据准备意味着将700GB的 PDF 规格说明书、手绘工程文件和扫描工程量清单转换为结构化数据，以训练模型提取行项目、数量和成本估算。其中一家公司的 AI 负责人直言不讳地说：

"问题不在于微调，而在于清理和准备多样化的数据。"

多样性才是挑战。一个项目可能涉及嵌入表格的 PDF、扫描蓝图、专有格式的 Excel 文件和手写笔记。从这些数据到干净的、标注好的数据集需要解析、标准化、去重和专家标注——没有任何单一工具能处理整个链条。

对于医疗团队，数据准备意味着不同的东西：在任何处理开始之前进行 PHI 脱敏，然后从以非标准缩写书写的临床笔记中提取结构，然后由不是数据科学家的临床医生进行标注。合规要求不是附带的——它决定了哪些工具可以使用，哪些不行。

对于法律团队，挑战类似，但增加了特权的复杂性。你不能将客户文件发送到云端 API 来解析它们。你需要本地运行的解析工具、领域专家（律师，而非 ML 工程师）实际上能操作的标注工具，以及能够经受审查的审计追踪。

对于边缘 AI 公司，数据准备正在阻碍产品时间表。他们的问题是标注吞吐量——目标类别随产品发展而变化，标注工具需要 ML 工程来操作，而工程师对本质上是领域专家任务的依赖减慢了一切。一家边缘 AI 初创公司的团队告诉我们：

"数据标注是主要挑战——目标类别频繁变化。"

最后一点——目标类别频繁变化——被低估了。在企业 AI 中，标注模式不是固定的。它随着团队对问题了解的深入而演变。每次变化时，标注工具都需要重新配置，这需要 ML 工程时间。这使得问题是动态的，而不仅仅是大规模的。

对于 AI 机构，问题是他们自己在吸收客户的数据问题。一位机构创始人告诉我们：

"企业医疗和法律领域的客户更倾向于关注本地部署解决方案。"

该机构并非直接处理数据——他们在设计将要处理数据的系统。但他们客户的本地部署要求影响了每一个技术决策，而可用工具的碎片化格局使设计过程比需要的复杂得多。

五类数据准备问题

在27次访谈中，出现了五个不同类别的数据准备问题。大多数团队至少有两个。几个团队五个都有。

1. 摄入问题

原始数据以 AI 训练管道无法直接消费的格式存在。PDF、扫描图像、遗留数据库导出、专有文件格式、手写文件。在任何清理或标注之前，这些文件需要被解析为结构化文本或结构化数据。

这比听起来更难。对干净数字 PDF 有效的 PDF 解析对扫描文件无效。对印刷文字有效的 OCR 对手写笔记无效。对简单表格 PDF 有效的表格提取对复杂的多列工程规格说明书无效。典型企业文档档案中的文件格式种类繁多，没有单一的解析工具能可靠地处理所有格式。

2. 清理问题

原始解析文本充满噪声。OCR 错误、格式伪影、跨文档的重复段落、团队之间或时间段之间不一致的术语。在数据可以标注之前，需要清理——而企业规模的清理需要大量手工劳动或大多数团队不具备的复杂工具。

一家端侧 AI 公司的 CTO 很好地描述了标准期望：

"使数据清理过程显著更容易，即使只是80%自动化，也将是一个巨大的推动力。"

注意"80%"——这不是对完美自动化的请求。团队知道总是需要一些人工审查。他们需要的是前80%不需要 ML 工程师编写自定义 Python 脚本。

3. 标注问题

对于监督学习和指令调优，数据需要被标注。最适合标注的人——领域专家——通常技术水平不够，无法在没有大量设置和支持的情况下操作可用的标注工具。这创造了对 ML 工程师运行标注管道的依赖，而这些管道本应在领域专家的时间内运行。

我们在医疗（需要标注临床笔记的医生）、法律（需要标注合同条款的律师）和建筑（需要识别和分类工程量清单行项目的工程师）中都遇到了这种模式。在每种情况下，标注工具本身才是瓶颈，而不是标注者的专业知识。

4. 合规问题

在受监管行业中，数据不能移到云端处理。HIPAA、GDPR、法律特权和内部数据治理政策都对数据的去向和谁能看到它施加了限制。大多数商业 AI 数据准备工具是云原生的。这意味着受监管的企业要么接受合规风险，要么自建工具，要么退回到手动流程。

一家网络安全公司用明确的术语表达了这个限制：

"大多数 AI 工具通过云端处理推理，使数据本质上成为公开的。"

这不是边缘问题。这是大多数 AI 工具的设计方式与受监管企业数据存放位置之间的结构性不兼容。后果是，受监管的组织要么以不同的方式做 AI，要么根本不做 AI。

5. 集成问题

对于那些已经组装了工具链——这里一个解析器、那里一个标注工具、上面一个清理库——的团队来说，问题是将它们缝合在一起。没有共享的数据格式。没有共享的审计追踪。当任何一个工具更新时就会中断的自定义粘合代码。ML 工程时间花在维护管道而不是构建模型上。

这是从外部看似乎已解决但内部正在消耗资源的问题。一位笔记 AI 初创公司的创始人简单地告诉我们：

"数据是最大的问题。"

不是训练。不是推理。不是部署。是数据。而且他们已经尝试过碎片化工具方法。

为什么模型训练几乎从来不是被陈述的问题

这是当我们退后一步审视总体情况时最令我们惊讶的发现。

模型训练——在 AI 媒体中获得最多关注、最多风险投资和最多工程人才的活动——很少被提及为瓶颈。团队没有说"我们需要更好的基础模型「或」我们需要更好的训练基础设施。"他们在说的是：我们无法开始训练，因为我们的数据还没准备好。

这与更广泛的研究一致。行业共识将60-80%的 ML 项目时间归于数据准备，而非模型训练。Forrester 和 Capital One 对500名企业数据领导者的调查发现，73%将数据质量和准备确定为 AI 成功的头号障碍。我们在27次访谈中看到的模式与大规模研究显示的情况一致。

原因是结构性的：模型训练是一个在工具成熟、基础设施存在、流程被充分理解的意义上已经解决的问题。数据准备没有被解决。它在领域特异性、格式特异性、合规特异性和组织特异性方面，都是通用工具处理得很差的。

团队目前在做什么

当我们问团队目前如何处理数据准备时，答案分为三类：

**类别1：拼凑的工具链。**三到七个独立工具，每个处理管道的一部分，通过 ML 工程师编写和维护的自定义代码连接。最常见的技术栈：文档解析器（通常是 Docling 或 Unstructured.io）、标注工具（通常是 Label Studio）和清理库（通常是 Cleanlab 或自定义脚本）。需要时还会添加 Distilabel 或类似工具用于合成数据生成。每个工具都有自己的设置、自己的数据格式、自己的维护负担。

**类别2：手动流程。**在工具链方法遇到合规壁垒的受监管行业中，团队退回到电子表格、手动审查和逐文档处理。这有效但无法扩展到小型试点之外。

**类别3：尚未开始。**几个团队完全没有开始数据准备。他们有 AI 采用目标，对需要什么训练数据有大致了解，但在第一步就被阻住了。工具格局对他们来说太碎片化、太技术化或太依赖云端，无法找到入口点。

这些团队中没有一个将其当前方法描述为令人满意的。拼凑工具链的团队想减少工程开销。手动流程的团队想更快。尚未开始的团队想找到一个起点。

缺失的层

从27次访谈中浮现出的是企业 AI 工具格局中缺失内容的清晰画面：一个为受监管行业设计的统一、本地部署的数据准备环境。

各个组件都存在。文档解析器存在。标注工具存在。质量评分库存在。不存在的——或者在这些访谈时不存在的——是一个单一环境，处理完整的管道（摄入、清理、标注、增强、导出），而不需要 ML 工程来粘合工具，不需要将数据发送到组织外部，也不要求领域专家学习操作开发者工具。

这不是任何单个工具的功能缺口。这是生态系统尚未构建的一个层。

对企业 AI 采用的启示

这27次访谈描绘的图景是，企业 AI 格局中的限制因素很少是媒体关注的焦点。它不是模型能力。它不是计算可用性。它不是组织意愿。

它是组织拥有的数据与其 AI 系统所需的数据之间的差距——以及在受监管的本地环境中设计来弥合该差距的工具的缺失。

当前停滞的65%的企业 AI 部署大多停滞在这一层。成功的组织要么大量投资 ML 工程来构建和维护自定义管道，要么在云端工具可接受且数据已经相对干净的领域运营。

对于其余——受监管行业、拥有复杂文档档案的组织、需要领域专家参与标注的团队——工具差距是真实的。清楚地认识到这一点是弥合它的第一步。

---

相关阅读

• 企业 AI 项目在数据阶段失败——而非模型阶段 — 数据准备是大多数企业 AI 项目停滞的结构性原因
• 拼凑 Docling、Label Studio 和 Cleanlab 的隐性成本 — 运行碎片化工具栈的团队所支付的集成税的详细分析
• 你的 ML 工程师不应该做这些 — 为什么领域专家被排除在外正在减慢受监管行业的标注管道