面向AI的数据管道与治理实务指南

为什么AI需要数据管道和治理

所有机器学习模型都用数据训练、用数据评估。Datasheets for Datasets（paper）指出，数据集的特性从根本上决定了模型的行为。如果实际使用环境与训练和评估数据不匹配，或者数据中含有不希望出现的社会偏见，模型在实际场景中就无法正常工作。该论文警告，在招聘、金融、刑事司法等后果严重的领域，这种错位可能造成严重危害。

在生成式AI中，问题又多了一层。Google Cloud的文章（w4）列举了缺乏治理时的风险：被困在多个系统中的数据（数据孤岛）、不准确数据导致AI智能体产生幻觉、敏感数据通过回答泄露给无权限的人，以及违反GDPR、CCPA等法规。IBM的文章（w5）也说明，如今治理还必须覆盖RAG（检索增强生成）系统、向量数据库以及作为AI智能体输入和输出的结构化与非结构化数据。

因此，面向AI的数据工作分为两条主线。一条是实际搬运和加工数据的管道，另一条是决定谁对数据负责、如何衡量质量、谁可以查看数据的治理。如果前者是道路，后者就是交通规则。IBM的文章（w5）把治理比作“空中交通管制塔”，让经过验证的数据通过安全的管道流向可信的用户。

组成部分：采集→清洗→存储→索引

采集阶段是从多个来源获取数据。AWS的文章（w1）以支付和CRM（客户关系管理）系统、库存系统、IoT传感器、社交媒体、公司内部人事系统为例。获取的原始数据先放在名为暂存区（landing zone）的临时存储空间中。获取方式有三种：由源系统通知已变更记录的“变更通知”，按固定周期只获取变更部分的“增量抽取”，以及无法得知变更时全部重新获取的“全量抽取”。AWS建议，全量抽取传输量大，只用于小表。

在清洗（转换）阶段，要删除错误、用规定值填补空缺、去除重复记录，并把日期、单位和字符集统一为一种格式。比如AWS文章（w1）中的例子，把千克与磅混用的食谱数据统一为一种单位。在此之上，还可以加入按业务规则从现有值计算新值的“派生”等高级转换。

ETL（Extract·Transform·Load）是在放入存储系统之前完成这些转换的方式。AWS的文章（w1）把ETL定义为：将多个来源的数据汇集到名为数据仓库的中央存储库，并按业务规则整理原始数据，为分析和机器学习做好准备的过程。ELT则调换顺序，先把原始数据加载到存储系统，需要时再在存储系统内部进行转换。由于保留了原始数据，日后更容易为其他用途重新加工，但需要防止存储系统中堆积未经整理的数据。

面向AI的管道还多一个索引阶段。根据Anthropic的工程文章（w6），RAG把文档切分成几百个token以内的片段（分块），用嵌入模型把每个片段转换成承载语义的向量，然后存入可按语义相似度检索的向量数据库。收到问题后，系统找出最接近的片段，附加到提示词中发送给模型。

存储与组织：数据仓库·数据湖·湖仓一体·数据网格

数据仓库是汇集按表和列整理好的数据的中央存储库（w1）。Databricks的文章（w2）说明，数据仓库长期用于决策支持和BI（商业智能，即报表和仪表盘），但不适合处理非结构化、半结构化数据或量大且变化快的数据，或者处理成本很高。数据湖是不预先定义结构、按原样存放结构化和非结构化数据的存储库（w1）。它可以把原始数据堆放在低成本存储中，因而被用于数据科学和机器学习；但根据Databricks的文章（w2），数据湖不支持事务、也不强制质量，缺乏管理就会变成“数据沼泽（data swamp）”。

因此，许多组织一直采用同时设置数据湖和数据仓库的两层架构：先从业务数据库ETL到数据湖，再只把重要数据ETL到数据仓库。Databricks的文章（w2）指出，这种架构会带来数据重复、额外基础设施成本、安全问题，以及数据不是最新的状态（staleness）。湖仓一体是试图合并两者的设计：在低成本的数据湖存储之上加一层元数据（例如Parquet文件之上的Delta Lake），提供ACID事务、模式强制以及查询历史版本的“时间旅行”。Databricks表示，时间旅行和审计记录也有助于机器学习的可复现性。不过，这是销售湖仓一体的公司的说法，是否适合自身组织的规模和现有系统，还需另行判断。

数据网格不是存储技术，而是组织原则。Zhamak Dehghani的文章（w3）认为，技术进步解决了数据量和计算规模的问题，却没有解决另一维度的规模问题：来源和用户的增加、用途的多样化以及变化速度。作为解决方案，她提出四项原则：以领域为中心的分布式数据所有权、数据即产品、自助式数据平台、联邦计算式治理。也就是说，由最了解数据的业务团队像对待“产品”一样对数据负责，而通用平台和政策由中心以代码形式提供。

设计原则：治理与数据集文档化

治理是在从采集、加载到分析乃至安全销毁的整个生命周期中，有原则地管理数据的方法（w4）。IBM的文章（w5）把它视为数据管理的一部分，概括为关注质量、安全和可用性。各来源共同提到的组成部分可归为四类。第一是质量。Google Cloud的文章（w4）从准确性、完整性、一致性、及时性、有效性、唯一性六个维度看待质量。第二是血缘（数据从哪里来、经过怎样变化的谱系）和元数据。IBM的文章（w5）列举的治理工具共同功能包括元数据管理、数据目录、血缘追踪和业务术语表。

第三是访问权限。IBM的文章（w5）介绍了一种分工：对于个人身份信息等敏感数据，由治理团队制定政策，由管理团队通过基于角色的访问控制（RBAC）来实施。它还建议划定“数据范围”，让用户和应用只能访问所需的数据。IBM（w5）和Google Cloud（w4）也都指出，随着读取数据的不再是人而是AI智能体的情况增多，权限设计变得更加重要。第四是责任结构。IBM的文章（w5）把角色分为指导委员会、数据所有者（负责各领域的准确性和质量）、数据管理员（负责日常管理）和利益相关者。

数据集文档化是把治理以人能阅读的形式留存下来。Datasheets for Datasets（paper）提出，就像每个电子元件都附有规格说明书一样，每个数据集都应附上记录动机、构成、采集过程、建议用途等内容的文档。目的是让创建方认真回顾创建、发布和维护过程，让使用方选择合适的数据集并避免意外误用。该论文表示，问题清单并不是标准答案模板，应根据领域和组织进行调整，并强调不要将文档编写自动化。自动化虽然方便，却会剥夺创建者思考的机会。

Data Cards（paper）把这一思路改进得适合大规模产业场景。Data Card是对数据集整个生命周期中的关键事实进行结构化汇总的文档，包含来源、采集与标注方法、预期用途等无法从数据本身推断出的背景信息。研究者说明，他们把它设计成供多个职能的读者共同查看的“边界对象（boundary object）”。

分步实施方法

刚开始时，建议按以下顺序进行。第一，确定用途和范围。这些数据是用于分析、模型训练还是 RAG 检索，决定了存储库和转换方式的不同。Anthropic 的文章（w6）指出，如果知识库小于 20 万个 token（约 500 页），不用 RAG、直接把全部内容放进提示中会更简单，因此要先确认是否真的需要 RAG。第二，确定数据源清单和负责人。写明从哪些系统获取什么数据，以及每份数据由谁负责。即使不完全采纳数据网格的领域所有权原则（w3），最好也从一开始就明确“这份数据由谁来修改”。

第三，搭建采集和清洗流程。根据数据源是否提供变更通知、能否进行增量抽取来选择方式（w1）。制定去重、格式统一和空值处理规则，并从质量的六个维度（w4）中选出对自身用途重要的项目作为衡量指标。第四，选择存储库。如果以结构化分析为主，选数据仓库；如果原始数据保存和多样化加工更重要，则考虑数据湖或湖仓一体。如果是训练数据，要确认版本管理功能，以便能重新找到训练时使用的是哪个版本（w2）。

第五，如果是 RAG，就要建立索引。Anthropic 的文章（w6）介绍了同时使用嵌入检索和精确匹配词语的 BM25 并合并结果的方法。这是因为嵌入擅长捕捉语义，但可能漏掉像“TS-999”这类错误代码那样需要精确匹配的字符串。此外，为减少块丢失文档上下文的问题，文章提出了 Contextual Retrieval：用模型为每个块生成 50~100 个 token 的上下文句子，说明它在整篇文档中的位置，并加在块的前面。Anthropic 表示，这种方法使检索失败减少了 49%，与重排序器结合使用时减少了 67%。第六，加上权限和文档。对敏感数据设置基于角色的访问控制，并为每个数据集编写 Datasheet 或 Data Card。最后，把审计和改进纳入定期日程（w5）。

检查清单

在采集阶段，确认每个数据源是否都有指定负责人，抽取方式（变更通知、增量、全量）是否符合数据源的特点，以及是否已决定暂存区中的原始数据要保留多久以便追踪问题（w1）。

在清洗和存储阶段，检查去重和格式统一规则是否有文档记录，是否真的在衡量质量指标（准确性、完整性、一致性、及时性、有效性、唯一性，w4），是否把同一份数据复制到多个存储库而产生了不同的值（w2），以及能否重新查询过去的版本。

在索引和 RAG 阶段，确认是否只用了语义检索，是否单独测试过错误代码、产品编号这类需要精确匹配的问题，以及块是否丢失了文档上下文（w6）。在治理阶段，检查敏感数据是否设置了基于角色的权限，AI 智能体是否无法越过用户权限读取数据并在回答中输出（w4、w5），数据血缘和数据目录是否为最新，以及每个数据集是否有记录动机、构成、采集过程和建议用途的文档（paper）。

常见错误与局限

最常见的错误是不断往管道上叠加。Dehghani 的文章（w3）把为连接运营数据和分析数据而不断失败的 ETL 作业、以及日益复杂的管道迷宫，描述为许多组织都熟悉的景象。Databricks 的文章（w2）也指出，经过多次 ETL 的两层架构需要持续维护，并会让数据变得陈旧。在增加环节之前，先看看是否在把同一份数据搬运两次。

第二个错误是把数据湖当作“先全部放进去再说”的地方。不强制质量、权限各不相同的数据湖会变成数据沼泽（w2）。越是像 ELT 这样先加载原始数据的方式，越需要同时做好元数据和权限管理。

第三个错误是把文档编写变成填表。Datasheets 的研究者（paper）花了约两年时间打磨问题，修改问题以免产品团队只回答“是”或“否”；他们还发现，法律和伦理问题与其单独归在一起，不如放进生命周期的各个阶段，回答效果更好。在 Data Cards（paper）的案例研究中，编写过程也促使团队追问为什么“未知”值很多，从而暴露出改进数据设计的机会。文档只有作为引发思考的工具时才有价值。

也存在局限。治理框架因组织而异，没有标准答案，旧的框架也会很快过时（w5）。多数网络来源是介绍自家平台的公司文章，功能说明可以参考，但产品选择需要在自己的环境中另行验证。此外，Contextual Retrieval 的数据是 Anthropic 在自身实验中报告的数值（w6）。

延伸学习

如果是初次建立概念，可以先通过 AWS 的 ETL 介绍（w1）熟悉采集、转换、加载的基本术语，再通过 Databricks 的湖仓一体文章（w2）了解数据仓库、数据湖、湖仓一体分别是为解决什么问题而出现的。如果在考虑组织结构，可以阅读 Dehghani 关于数据网格原则的文章（w3）。这篇文章重在建立共同语言而非开具工具处方，适合在做技术选择之前阅读。

关于治理，IBM 的文章（w5）对角色、政策、审计和工具的划分最为系统，Google Cloud 的文章（w4）则简要总结了 AI 时代的风险和质量的六个维度。关于数据集文档，先看 Datasheets for Datasets（paper）的问题清单；如果想了解大型组织的实际应用经验，再接着读 Data Cards（paper）。如果要亲手搭建 RAG 文档管道，Anthropic 的 Contextual Retrieval 文章（w6）把分块、嵌入、BM25 和重排序串成了一条完整流程。