Data Lineage / Data Contracts / AI Data Quality 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_DATA_CONTRACTS_LINEAGE_QUALITY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

核心问题: AI 产品为什么经常不是模型坏，而是数据定义、血缘、质量、标签、版本、权限和用途边界坏？如何把 data contract、lineage、quality SLO 和 metadata graph 建成 AI 生产底座？

---

Source Anchors

核心导读

AI 数据平台的核心不是“把数据集中到湖仓”，而是证明每个模型、eval、RAG 答案、特征和业务决策使用的数据是什么、从哪里来、谁负责、质量如何、何时变更、被允许用于什么目的。

Data contract 定义数据产品承诺，lineage 记录数据如何流动，quality SLO 决定数据是否可以进入训练、评估或推理。三者合在一起，构成 AI 系统的 evidence layer: 出现问题时能定位影响范围，上线前能阻断不合格数据，审计时能解释决策来源。

问题定义

金融零售 AI 的生产事故常以“模型退化”表现出来，但根因往往在数据控制面:

• KYC 文档模型突然退化，因为 OCR 上游字段改名。
• AML 标签延迟导致训练样本和评估样本口径错误。
• 信贷模型训练使用了未来才知道的字段，离线效果虚高。
• RAG 政策库引用过期文件或无权限文件。
• 客服 trace 被用于训练，但没有用途限制、保留策略和 consent 记录。
• 推荐特征口径变化，排序策略无声偏移。
• Eval dataset 被污染，模型升级看起来变好但真实能力下降。

AI 数据治理要回答的是:

某个 AI 资产使用了哪些数据、经过哪些转换、满足哪些质量承诺、
是否被允许用于当前目的、变更时会影响哪些下游决策？

需要同时覆盖三类 lineage:

核心原理

Data contract 不是 schema 文件，而是跨业务、数据、技术和风险的服务契约。它至少应包含:

OpenLineage 的核心抽象是运行事件:

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

放到 AI 场景，需要扩展记录 model version、prompt version、embedding model、chunking strategy、label policy、feature availability timestamp、privacy class 和 eval rubric version。否则只能知道数据表如何流动，无法知道 AI 决策证据如何形成。

系统/架构模型

AI data control plane 可以抽象为:

source systems
  -> contract registry
  -> lineage collectors
  -> metadata graph
  -> quality validation engine
  -> privacy and usage policy
  -> AI asset impact graph
  -> release gates and incident workflow

关键组件:

这种架构的关键是“数据变更可传播”。当一个字段、文档、标签口径或特征生成逻辑变化时，系统应能自动识别下游 AI 资产和业务动作，而不是依赖人工群聊通知。

关键机制与取舍

一个成熟判断是: 没有明确 contract 的数据可以用于探索，但不应进入高风险训练、自动决策、客户触达或监管证据。

证据与控制

Quality SLO 应被当作服务承诺:

质量门禁示例:

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

数据事故响应要能沿 lineage 快速回答:

• 哪些模型、RAG corpus、eval、dashboard 和业务流程受影响。
• 哪些客户、决策或员工动作可能被影响。
• 是否需要暂停训练、冻结发布、回滚数据集或重放决策。
• 是否需要通知 risk、compliance、privacy 或安全团队。
• contract、tests、owner 和变更流程如何修正。

AI产品/金融零售场景

RAG 政策库 Lineage

每个可检索 chunk 应记录 source system、policy owner、document version、effective date、jurisdiction、product applicability、ingestion time、chunk version、embedding model、ACL 和 citation ID。

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

如果答案引用过期政策或无权限政策，lineage 必须能定位是哪次 ingest、哪个文档版本、哪个 ACL 决策造成的。

AML Labels

AML 标签天然复杂: SAR filed 不等于真实犯罪，case closed false positive 可能只是证据不足，标签有长延迟，analyst 风格会影响一致性。标签 contract 需要定义 label meaning、confirmation level、delay window、review quality、permitted use 和禁止用途。

KYC 文档数据

document upload
  -> OCR
  -> field extraction
  -> validation rules
  -> human review
  -> decision and feedback

每一步都需要 lineage 和质量指标，否则一个 OCR 字段漂移可能悄悄污染训练集、eval set 和生产决策。

Feature Store 与 Point-in-Time Correctness

信贷、欺诈、营销和催收特征必须记录 availability timestamp。训练时使用在决策时不可见的字段，会让离线模型看起来优秀，但上线后失效。

反模式

• 把数据目录当成治理，以为能搜索数据就等于可用于 AI。
• 只做 schema test，不治理业务语义、用途、标签定义和时效。
• Lineage 只到表级，无法追踪 RAG chunk、feature、eval sample 和 prompt trace。
• 上游 breaking change 靠邮件或群聊通知，没有自动 impact analysis。
• 质量异常只告警不阻断，导致坏数据进入训练和发布链路。
• 把客服 trace、敏感字段或受限数据默认用于训练，没有 allowed use 和 retention 控制。
• Eval dataset 没有来源、版本和污染检测，导致模型升级证据不可信。

最终心智模型

AI 数据治理的本质是把数据从“可访问资源”升级为“有契约、有血缘、有质量承诺、有用途边界的产品”。Data contract 定义承诺，lineage 证明流动路径，quality SLO 决定是否可用，impact graph 支持变更和事故响应。

判断一个 AI 数据底座是否成熟，只看一个场景: 当某个上游字段、标签口径或政策文档错误时，能否在分钟级找出影响了哪些模型、答案、评估、客户决策和上线证据。如果不能，平台还停留在数据集成阶段，没有进入 AI 生产治理阶段。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。