企业 AI 数据管道构建的前 30 天

企业 AI 时间表在幻灯片上看起来很整洁。简洁的阶段、平滑的箭头，一切按计划进行。现实要混乱得多。数据的格式没有人记录过。访问权限配置需要一周而不是一天。本应全职参与的领域专家只在周四有两个小时可用。

这是构建企业 AI 数据管道前 30 天的每周实际进展。不是理想化的版本——而是真实的版本，包括出错的部分和如何应对。

---

第一周：数据审计和范围界定

预计发生的事情

前线部署工程师到达（实际或虚拟到场），与团队见面，并对数据环境进行彻底审计。目标是回答三个问题：存在哪些数据？它们在哪里？它们的状态如何？

同时，工程师与 IT 部门合作获取环境访问权限：计算资源、网络凭证、存储访问、安全许可。

实际发生的事情

第 1-2 天：介绍和访问请求。 工程师与利益相关者见面，参观系统，提交访问请求。在大多数企业中，这是第一个延迟发生的地方。安全审查、背景调查和受监管环境中的访问权限配置可能需要 2-5 个工作日。良好的项目会预见到这一点，在正式开始之前就启动访问请求。

第 3-4 天：数据发现。 工程师开始映射数据源。这几乎总是出乎意料的。客户在销售过程中描述的数据只是实际存在数据的子集。还有额外的数据库、遗留文件共享、三年前已停用系统的导出，以及某人桌面上包含关键参考数据的电子表格。

常见发现：

• 数据分布在比任何人意识到的更多的系统中
• 即使在单一来源内，文件格式也不一致
• 元数据不完整或不可靠
• 数据量是估计的 3-10 倍
• 某些数据的格式需要专门的解析器（扫描的 PDF、专有数据库导出、大型机提取）

第 5 天：范围调整。 基于销售过程中客户描述而定义的原始范围，根据数据审计的实际发现进行修订。这不是范围蔓延——这是范围修正。工作一直是这么大的；只是估算当时不知道而已。

出现的问题

访问延迟是第一周最常见的问题。如果工程师无法访问数据系统，一切都会停滞。缓解措施是在项目正式开始之前就启动访问权限配置。

第二个最常见的问题：主要利益相关者（购买项目的人）对数据的理解与实际操作数据的人不同。利益相关者说，"我们的合同都在一个 SharePoint 文件夹里。「合同团队说，」嗯，最近的在 SharePoint 里。2022 年之前的在旧文档管理系统里。修改件在邮件里。"

---

第二周：管道架构和数据摄入测试

预计发生的事情

基于第一周的审计，工程师设计管道架构并开始构建数据摄入层——从源系统将数据拉入准备环境的部分。

实际发生的事情

第 6-7 天：架构设计。 工程师规划管道：源连接器、转换步骤、标注工作流、导出格式。这会与客户的技术团队一起审查。本周做出的架构决策——在哪里处理、如何处理错误、记录什么——决定了管道的长期可维护性。

第 8-9 天：摄入构建和测试。 第一批连接器被构建和测试。这是数据格式问题变得具体的地方。PDF 解析器在 90% 的文档上工作正常，但在 10% 的扫描图像上失败。数据库连接器成功拉取记录，但时间戳有三种不同的格式。CSV 导出有嵌入的换行符导致解析器崩溃。

每个问题都是可解决的。但每个都需要时间，而且会累积。有经验的工程师不会感到惊讶。第一次做的工程师会低估工作量 2-3 倍。

第 10 天：首次端到端数据流。 到第二周结束时，原始数据应该从至少一个源系统流入准备环境。它不会是干净的。它不会被标注。但它在流动，这是后续一切的基础。

出现的问题

与遗留系统的集成问题是第二周最常见的问题。现代 API 是可预测的。遗留数据库导出、专有文件格式和没有文档的系统则不是。如果你的数据存在于超过 10 年的系统中，需要额外预留时间。

性能也可能带来惊喜。处理 100 个测试文档只需几秒的管道，可能在处理 100,000 个生产文档时卡住。第二周是这些瓶颈变得可见的时候。

---

第三周：清洗规则、标注模式和领域专家培训

预计发生的事情

数据流入管道后，重点转向转换：标准化数据的清洗规则，以及领域专家将用于标注模型训练数据的标签模式。

实际发生的事情

第 11-13 天：清洗和转换规则。 工程师构建清洗原始数据的规则：去重、归一化、处理缺失值、格式标准化、PII 检测和脱敏（如适用）。这是迭代的——规则被编写、在样本数据上测试、改进，然后再次测试。

关键洞察：清洗规则编码了领域知识。一条说"如果日期字段包含'待定'，则视为空值"的规则是领域决策，而不是技术决策。这就是为什么领域专家需要参与，而不仅仅是工程师。

第 14-15 天：标签模式设计。 工程师与领域专家合作定义标签模式——将应用于数据的类别、标签或注释。这是项目中智力要求最高的部分。

好的标签模式是：

• 穷尽的（覆盖数据中的所有情况）
• 互斥的（没有模糊的重叠）
• 实用的（标注者可以一致地应用标签）
• 与下游模型任务对齐的

坏的标签模式事后看来是显而易见的，但在设计期间是看不到的。"合同类型「似乎是一个清晰的标签，直到你遇到一份既是修改又是续签的文件。」严重性「似乎很直观，直到两个领域专家对某个发现是」中等「还是」高"意见不一。

第 15 天续：领域专家培训。 领域专家接受标注界面和标签模式的培训。他们标注一个样本集。测量标注者间一致性。如果一致性低，模式需要修订。

出现的问题

领域专家的可用性是第三周的关键风险。如果领域专家太忙无法参与，标签模式将由不了解领域的工程师设计，结果训练数据质量平庸。

另一个常见问题：标签模式分歧。不同的领域专家有不同的心智模型。资深律师对合同的分类方式与初级律师不同。心脏病学家和放射科医生对同一份影像报告的解读不同。解决这些分歧需要时间和沟通技巧。

---

第四周：验证、质量指标和合规设置

预计发生的事情

管道已完成。第四周是关于测试、衡量和记录。

实际发生的事情

第 16-18 天：管道验证。 完整管道使用生产规模数据进行端到端运行。衡量质量指标：

• 摄入完整性： 源记录中有多大比例被成功摄入？
• 清洗准确性： 转换中有多大比例产生了正确的结果？
• 标签质量： 标注者间一致性是多少？在黄金标准样本上的精确率/召回率是多少？
• 导出完整性： 输出格式是否匹配规范？下游 ML 框架能否无错误地摄入它？

目标因用例而异，但典型基准是：99%+ 摄入完整性、95%+ 清洗准确性、85%+ 标注者间一致性（Cohen's kappa 大于 0.7）。

第 19 天：合规文档。 对于受监管行业，管道的审计轨迹被审查和记录：数据血缘报告、访问日志、转换历史、PII 处理记录。此文档是合规团队最关心的交付物——也是最常被跳过或仓促完成的。

第 20 天：交接和培训。 工程师进行结构化交接：管道演练、配置文档、维护程序、故障排除指南。客户的技术团队在此会议后应能独立运行、监控和修改管道。

出现的问题

验证通常会发现需要修改管道的问题。在样本数据上有效的清洗规则在规模化时产生不正确的结果。设计期间看似清晰的标签类别在实践中变得模糊。导出格式有下游框架无法处理的边缘情况。

这不是失败。这就是验证的目的。风险不在于问题会浮出水面——而在于第四周没有足够的缓冲来解决它们。好的项目会在第四周计划至少 2 天的返工时间。

---

第 30 天之后

管道已上线。你的团队拥有它。供应商的工程师在 30-60 天内可提供远程支持，但系统由你来运营。

前 30 天是最难的。数据的意外已经过去。集成问题已解决。领域专家知道如何使用系统。从这里开始，工作从构建转向运营——运行管道、监控质量，以及随着需求演变将其扩展到新的数据源或用例。

---

规划你的前 30 天

如果你正在准备 AI 数据管道构建，想了解第一个月对于你的具体数据和环境是什么样的，预约与 Ertas 的发现通话。我们将逐步了解你的数据环境，标记可能的第一周意外，并给你一个真实的时间表——而不是幻灯片版本。