Data Lineage / Data Contracts / AI Data Quality 解读

面向对象: AI Data Product Manager / AI Product Architect / Data Architect / Governance / Model Risk。 核心问题: AI 产品为什么经常不是模型坏，而是数据定义、血缘、质量、标签、版本和权限坏？OpenLineage、DataHub、OpenMetadata、Great Expectations 代表的元数据和质量能力如何成为 AI 生产底座？ 学习目标: 理解 data contract、lineage、metadata、quality SLO、schema evolution、training/eval/RAG corpus lineage，并映射到 KYC、AML、信贷、客服 trace、推荐特征和政策 RAG。

---

Source Anchors

一句话:

AI 数据平台的核心不是“把数据放进湖里”，而是证明每个模型、eval、RAG 答案和业务决策使用的数据是什么、从哪里来、谁负责、质量如何、何时变更。

---

1. AI 数据问题的真实形态

常见生产事故:

• KYC 文档模型突然退化，因为 OCR 上游字段改名。
• AML 标签延迟导致训练样本错误。
• 信贷模型训练使用了未来才知道的字段。
• RAG 政策库引用了过期文件。
• 客服 trace 被用于训练，但没有目的限制和保留策略。
• 推荐特征口径变更导致排序偏差。
• eval dataset 被污染，模型升级看起来变好。

这些不是单纯工程 bug，而是数据产品治理缺口。

AI 需要三类 lineage:

---

2. Data Contract 是产品契约

Data contract 不只是 schema。它应该包括:

没有 contract 的数据不应进入高风险 AI 系统。

---

3. OpenLineage 的核心直觉

OpenLineage 关注运行中的 lineage 事件:

job run
  -> input datasets
  -> transformation
  -> output datasets
  -> facets / metadata

对 AI 的价值:

• 记录训练集如何生成。
• 记录特征表和标签表来源。
• 记录 RAG corpus ingest pipeline。
• 记录 eval dataset 生成流程。
• 支持事故时追溯上游变更。

AI lineage 需要扩展 metadata:

• model version。
• prompt version。
• embedding model。
• chunking strategy。
• label policy。
• privacy classification。
• feature availability timestamp。
• eval rubric version。

---

4. Data Quality SLO

质量不是“偶尔跑测试”，而是服务承诺。

Quality gate 示例:

block model training if:
  missing_rate(customer_id) > 0.1%
  label_delay_unresolved > threshold
  policy_corpus_outdated_docs > 0
  eval_set_unknown_source > 0

---

5. 金融零售案例

5.1 RAG 政策库 Lineage

需要记录:

• source system。
• policy owner。
• effective date。
• jurisdiction。
• product applicability。
• ingestion time。
• chunk version。
• embedding model。
• access policy。
• citation ID。

如果答案引用过期政策，lineage 能追溯:

answer -> chunk -> document version -> ingest job -> source owner -> approval record

5.2 AML Labels

AML 标签复杂:

• SAR filed 不等于一定真实犯罪。
• case closed false positive 也可能是信息不足。
• 标签有长延迟。
• analyst 风格不同。

标签 contract 要说明:

• label definition。
• source workflow。
• confirmation level。
• delay window。
• reviewer quality。
• permitted model use。

5.3 KYC 文档数据

KYC pipeline:

document upload
  -> OCR
  -> field extraction
  -> validation
  -> rules
  -> human review

每步都需要 lineage，否则错误字段进入模型训练后很难追。

---

6. AI Data Incident Response

数据事故例子:

• 上游 schema breaking change。
• RAG corpus ingest 错误。
• eval set 被重复样本污染。
• PII 被放入不该进入的训练集。
• 标签口径变更未通知模型团队。

响应流程:

detection
  -> classify impacted AI assets
  -> pause training/release if needed
  -> identify downstream models/RAG/evals
  -> rollback or rebuild dataset
  -> replay affected decisions
  -> update contract and tests

关键证据:

• 影响了哪些模型。
• 影响了哪些客户或决策。
• 是否需要通知 risk/compliance/privacy。
• 是否需要重新评估或回滚。

---

7. Architecture Checklist

---

8. 面试表达

30 秒版本

AI 数据治理不是把数据目录建起来，而是让模型、RAG、eval 和决策都能追溯到数据来源、定义、版本、质量和 owner。Data contract 定义数据产品承诺，lineage 记录数据如何流动，quality SLO 决定数据是否可以进入训练和上线。没有这些，高风险 AI 事故很难定位和审计。

2 分钟版本

我会把 AI 数据资产分成 training data、eval data、RAG corpus、feature data 和 trace data。每类都有 contract: schema、语义、freshness、quality、allowed use、privacy class、change policy 和 incident path。OpenLineage 类能力记录 job/run/dataset 关系，DataHub/OpenMetadata 管 owner、schema、lineage 和 governance，Great Expectations 类工具做质量验证。金融场景中，RAG 政策库要能追溯到文档版本和有效期，AML 标签要有标签定义和延迟说明，KYC 抽取要能追踪 OCR 到人工复核的链路。

架构师版本

AI data platform 需要 metadata store、lineage collector、contract registry、quality engine、schema change gate、asset impact graph、privacy metadata 和 release evidence。它是 EvalOps、Feature Store、RAG 和 Model Risk 的共同底座。

---

9. 作品集任务

做一个“RAG 政策库 data contract + lineage”:

1. 写 policy document data contract。
2. 定义 chunk metadata 和 citation ID。
3. 画 source -> ingest -> chunk -> embedding -> answer lineage。
4. 写 freshness 和 permission quality SLO。
5. 设计 breaking change approval。
6. 写一个过期政策事故响应 playbook。