AI Data Product Management Playbook

定位: 面向 AI PM / AI BA / AI Solutions Architect 的数据产品管理手册。 目标: 从“数据能不能喂给 AI”升级为“数据作为产品支撑 AI use case、eval、RAG、model routing、governance 和 ROI”。 核心观点: AI data product 不是一个表、一个文档库或一个向量库, 而是一组有 owner、有 contract、有质量 SLO、有权限和治理边界、能被 AI 工作流稳定消费的数据能力。

---

1. 为什么 AI 时代需要 Data Product Management

传统数据项目常问:

• 数据在哪里?
• 能不能抽出来?
• 字段够不够?
• 能不能给模型训练或检索?

AI data product management 要问的问题更完整:

• 哪个 AI use case 依赖这份数据?
• 谁为数据定义、质量、权限和更新负责?
• 这份数据能不能支撑 RAG citation、eval、model routing、agent action 和 audit?
• 数据错误会造成什么业务风险?
• 数据质量下降时, AI 系统如何降级、拦截或升级人工?
• 数据投入如何转成 ROI: 节省工时、降低风险、提升转化、减少损失?

一句话:

AI data is not ready when it is available. It is ready when it is governed, measurable, trusted, usable and owned.

---

2. AI Data Product Definition

AI data product 是为一个或一组 AI use case 提供稳定数据能力的产品化资产。它包括数据内容、语义定义、质量目标、访问控制、更新机制、评测用途、反馈闭环和运营责任。

2.1 最小定义

2.2 与普通数据集的区别

---

3. AI Data Product Canvas

每个 AI data product 至少填写一张 canvas。它不是文档仪式, 而是让 PM/BA/Architect 对“数据如何成为 AI 能力”达成共识。

---

4. Core Concepts

4.1 Source-of-Truth

Source-of-truth 是 AI 系统引用事实的权威来源。对 AI PM 来说, 关键不是“哪个库有数据”, 而是“冲突发生时信谁”。

Source-of-truth 决策需要记录在 canvas 和 data contract 中, 否则 RAG、eval 和 audit 会在事实冲突时失去标准。

4.2 Data Contracts

Data contract 是数据生产者和 AI 消费者之间的契约。它保证数据变化不会悄悄破坏 AI workflow。

一个 AI-oriented data contract 应覆盖:

4.3 Metadata

Metadata 让 AI 系统知道数据是什么、能不能用、怎么用。没有 metadata, RAG 只能“搜到文本”, 不能“理解可信度、权限和上下文”。

4.4 Lineage

Lineage 是数据从 source-of-truth 到 AI 输出的证据链。AI 项目上线后, 问题通常不是“模型为什么错”, 而是“模型看到的证据从哪里来, 哪一步错了”。

flowchart LR
  S[Source system] --> C[Curated dataset]
  C --> M[Metadata enrichment]
  M --> Q[Quality checks]
  Q --> I[Index or feature store]
  I --> R[Retrieval / model input]
  R --> O[AI output]
  O --> F[User feedback]
  F --> L[Label / golden set update]

Lineage 至少要回答:

• 这个回答引用了哪些 source records?
• 这些 records 的版本和更新时间是什么?
• 检索时使用了哪些 filters 和权限条件?
• 哪些数据转换影响了最终上下文?
• 用户纠错会回流到哪个 label 或数据修复流程?

4.5 Quality SLO

Quality SLO 是数据产品对 AI 消费者的服务承诺。AI data quality 不只看准确率, 还要看是否足够新、足够完整、足够可解释、足够可检索。

示例质量目标:

4.6 PII / Consent / Retention

AI data product 必须把隐私和合规当成产品能力, 而不是上线前的审批附件。

高风险规则:

• 不把生产 PII 原样复制进低治理的实验环境。
• 不把用户对话日志默认用于模型训练。
• 不把无授权文档纳入企业 RAG index。
• 不让模型日志成为新的影子数据库。
• 不把 retention 到期数据继续保留在向量库、cache、eval set 或 synthetic seed 中。

4.7 Label Strategy

Label strategy 决定 eval 和监督学习是否可信。AI PM 要把 label 当成产品资产, 而不是临时外包任务。

Label 设计要明确:

• 标签定义: 每个 label 的业务含义和排他关系。
• 标注对象: 文档、交易、回答、case、证据片段还是完整 workflow。
• 标注粒度: field-level、span-level、document-level、case-level。
• 一致性标准: inter-annotator agreement 和仲裁规则。
• 质量抽检: 抽检比例、错误分级、返工规则。
• 版本管理: rubric、label schema、sample set 都要有版本。

4.8 Golden Set Management

Golden set 是 AI release gate 的核心资产。它不是一次性测试集, 而是持续维护的业务风险样本库。

Golden set 要分层:

4.9 Synthetic Data Policy

Synthetic data 可以补齐稀缺场景, 但必须有明确政策。它不能伪装成真实数据, 也不能替代真实业务验证。

4.10 RAG Knowledge Product

RAG knowledge product 是一种特殊 AI data product。它不只是“把文档切片进向量库”, 而是把知识源、权限、版本、有效期、引用和反馈闭环产品化。

4.11 Feature / Eval Dataset

AI 场景通常同时需要 feature dataset 和 eval dataset。

PM/BA 要避免两个误区:

• 把 feature dataset 的覆盖率当成 eval dataset 的代表性。
• 把 eval dataset 的高分当成线上业务效果的保证。

正确做法是把二者通过 feedback loop 连接:

Production case
-> AI output
-> user feedback / business outcome
-> error taxonomy
-> label queue
-> golden set candidate
-> data contract or feature fix
-> release gate

4.12 Feedback Data Loop

反馈数据闭环决定 AI data product 是否会越用越好。

反馈闭环的 PM 指标:

• feedback capture rate: 有多少 AI 交互留下可用反馈。
• feedback triage latency: 反馈进入队列到分流的时间。
• fix cycle time: 数据或知识问题从发现到修复的时间。
• regression recurrence rate: 已修复错误是否再次出现。
• eval uplift: 数据修复后 eval 指标提升幅度。

4.13 Data Owner Operating Model

没有 owner 的数据产品会退化成无人负责的共享文件夹。AI data product 至少需要以下角色:

RACI 示例:

---

5. AI Data Product Lifecycle

flowchart TB
  I[Use case intake] --> D[Data discovery]
  D --> C[Canvas and contract]
  C --> G[Governance review]
  G --> B[Build curated data product]
  B --> E[Eval and readiness score]
  E --> P[Pilot release]
  P --> M[Monitoring and feedback]
  M --> R[Review and roadmap]
  R --> C

5.1 Intake

输入不是“我们有一堆数据”, 而是一个可验证的 AI use case:

5.2 Discovery

数据 discovery 要同时看业务、技术和治理:

• 业务: 字段含义、流程状态、例外场景、人工判断依据。
• 技术: source systems、schema、API、batch/stream、历史数据覆盖。
• 治理: PII、consent、retention、cross-border、access model、audit。
• AI: prompt context、retrieval、features、labels、eval、feedback。

5.3 Readiness

进入 AI pilot 前至少满足:

5.4 Operate

上线后每月做一次 data product review:

---

6. 金融零售案例库

6.1 AML Evidence Data Product

PM 设计重点:

• 把“证据完整性”设为核心指标, 不只看摘要流畅度。
• 对 high-risk narrative 要求 citation 和 source record trace。
• 将 analyst 改写原因分类为 missing evidence、wrong fact、wrong tone、policy issue、access issue。

6.2 KYC Document Data Product

PM 设计重点:

• 把 document lifecycle 和 policy effective date 作为 metadata, 避免引用过期要求。
• 对低置信度字段采用 human-in-the-loop。
• eval set 覆盖模糊扫描件、多语言证件、地址格式差异和法人结构复杂样本。

6.3 客服知识库 Data Product

PM 设计重点:

• 知识库不是文档仓库, 是带生命周期、权限和 eval 的 RAG knowledge product。
• 统计“答案被采纳并减少后续联系”的业务效果, 不只统计 chatbot containment。
• 建立 knowledge gap queue: 无答案、答案过期、引用错误、政策冲突分开处理。

6.4 信贷 Underwriting Eval Dataset

PM 设计重点:

• 明确 AI 是 decision support, 不是自动信贷决策。
• eval dataset 需要按产品、风险等级、地区、渠道、exception type 切片。
• 把“解释是否符合政策”和“决策是否正确”分开评测。

6.5 支付争议 Evidence Pack Data Product

PM 设计重点:

• 把 deadline 和 reason code 作为核心 metadata, 直接影响排序和行动建议。
• Evidence pack 需要可审计: 每个证据项来源、时间、提交状态和权限边界清楚。
• ROI 可用 win rate、cycle time、manual assembly time 和 compliance defect rate 衡量。

6.6 零售库存 / 促销 Forecast Dataset

PM 设计重点:

• forecast dataset 不只是历史销售, 必须把库存约束、促销、价格、供应和异常事件放进同一语义层。
• eval 不只看整体 MAPE, 还要按高价值 SKU、促销期、缺货期、门店类型切片。
• planner override 是高价值 feedback, 要记录原因并回流到特征和评测。

---

7. Artifacts

7.1 Data Product Canvas 模板

# Data Product Canvas

## 1. Identity
- Data product name:
- Business domain:
- Owner:
- Version:
- Status: discovery / pilot / production / deprecated

## 2. Business Outcome
- Target workflow:
- Business outcome:
- Baseline:
- Success metric:
- Risk tier:

## 3. AI Consumption
- AI use cases:
- AI tasks:
- Human decision retained:
- Allowed AI use:
- Prohibited AI use:

## 4. Users and Consumers
- Human users:
- System consumers:
- Downstream dashboards / eval / models:

## 5. Source-of-Truth
- Source systems:
- Authoritative fields:
- Conflict resolution rule:
- Data lineage summary:

## 6. Contract
- Schema version:
- Critical fields:
- Refresh cadence:
- Freshness target:
- Completeness target:
- Accuracy checks:
- Change notice period:

## 7. Metadata and Governance
- Business metadata:
- Technical metadata:
- PII class:
- Consent status:
- Retention class:
- Access policy:
- Audit requirement:

## 8. Eval and Feedback
- Golden set:
- Label strategy:
- Evaluation metrics:
- Feedback capture points:
- Review cadence:

## 9. Operations
- Quality dashboard:
- Incident triggers:
- Escalation path:
- SLA / SLO:
- ROI metric:

7.2 Data Readiness Scorecard

评分建议: 1 = 不可用, 2 = 可探索, 3 = 可 pilot, 4 = 可 production, 5 = 可规模化复用。

Readiness gate:

7.3 Data Contract 模板

data_product: AML Evidence Data Product
version: 1.0.0
owner:
  business_owner: Financial Crime Operations
  data_owner: Financial Crime Data Office
  technical_owner: AI Platform Data Engineering
purpose:
  allowed_ai_use:
    - evidence_retrieval
    - case_summarization
    - eval
  prohibited_ai_use:
    - autonomous_case_closure
    - external_customer_communication_without_review
source_of_truth:
  systems:
    - transaction_monitoring
    - core_banking_ledger
    - case_management
schema:
  critical_fields:
    - case_id
    - customer_id_tokenized
    - alert_id
    - transaction_id
    - event_time
    - risk_typology
    - evidence_text
freshness:
  cadence: near_real_time
  p95_target_minutes: 30
quality:
  completeness_target:
    critical_fields: 0.99
  accuracy_checks:
    - transaction_id_must_exist_in_ledger
    - case_id_must_exist_in_case_management
permissions:
  row_level: assigned_case_only
  field_level:
    account_number: masked
    customer_name: role_restricted
logging:
  model_trace: redacted
  audit_retention: regulated_record_policy
change_management:
  schema_change_notice_days: 14
  backward_compatibility_days: 30
incident_triggers:
  - permission_filter_failure
  - freshness_breach_over_2_hours
  - critical_field_completeness_below_0_98

7.4 Golden Set Register

7.5 Labeling SOP

Label 错误分级:

7.6 Data Quality Dashboard

Dashboard 应分成 AI 消费者看得懂的指标, 而不是只展示 pipeline 成功率。

推荐视图:

• Executive view: ROI、风险、SLO 达标率、生产影响。
• Product view: use case 覆盖、feedback、adoption、eval uplift。
• Data owner view: freshness、completeness、schema drift、lineage issue。
• Risk view: PII、access、retention、audit、high-risk failures。

7.7 Data Incident Playbook

Incident postmortem 必须回答:

• 哪个 AI use case 受到影响?
• 用户是否看到错误输出或无权信息?
• 哪个数据 contract 或 SLO 失效?
• 为什么监控没有提前发现?
• 哪个 golden set 或 risk set 需要新增样本?
• owner operating model 是否需要调整?

---

8. PM / BA / Architect 分工

协作原则:

• PM 对价值、优先级、adoption 和产品边界负责。
• BA 对业务语义、流程事实、异常路径和验收标准负责。
• Architect 对可扩展架构、数据流、权限、可观测性和可靠性负责。
• Data owner 对 source-of-truth、数据定义、质量和访问授权负责。
• Risk / Compliance 对高风险用途、隐私、保留和审计要求负责。

---

9. 30 / 60 / 90 天学习与落地计划

前 30 天: 建立 AI Data Product 基础

目标: 能识别一个 AI use case 背后的数据产品需求, 写出 canvas 和 readiness scorecard。

30 天验收:

• 能解释普通 dataset 和 AI data product 的区别。
• 能为一个 AI use case 找出 source-of-truth 和主要 failure modes。
• 能写出 data contract 的关键字段和质量 SLO。

31-60 天: 连接 EvalOps、RAG 和治理

目标: 能把数据产品接入 eval、RAG、feedback loop 和 incident 管理。

60 天验收:

• 能把 requirements-to-eval 和 data readiness 连接起来。
• 能说明数据质量问题如何影响 AI release gate。
• 能把线上反馈转成 label、golden set 和数据修复 backlog。

61-90 天: 做成作品集级案例

目标: 完成一个可展示的金融零售 AI data product portfolio case。

90 天作品集应包含:

• 1 份 AI data product canvas。
• 1 份 data contract。
• 1 份 readiness scorecard。
• 1 份 golden set register。
• 1 份 labeling SOP。
• 1 份 data quality dashboard mock。
• 1 份 data incident playbook。
• 1 页 ROI 和 governance summary。

---

10. 面试表达

10.1 30 秒版本

AI data product 不是把数据给模型, 而是把数据产品化成可被 AI 稳定消费的能力。它需要 source-of-truth、data contract、metadata、lineage、quality SLO、权限、PII/consent/retention、label strategy、golden set 和 feedback loop。这样 AI use case 才能被 eval、治理、审计和 ROI 管起来。

10.2 2 分钟版本

在企业 AI 场景里, 很多失败不是模型能力不足, 而是数据没有产品化。比如客服 RAG 回答错, 可能是知识库混入草稿、文档过期、权限标签缺失、chunking 丢了上下文, 或者 citation 没有进入 release gate。

我会把关键数据资产定义成 AI data product。第一步确认业务目标和 AI 使用方式, 例如 RAG、eval、routing、summarization 或 decision support。第二步确认 source-of-truth 和 data contract, 包括 schema、语义、刷新频率、质量 SLO 和变更机制。第三步设计 metadata、lineage、权限、PII、consent 和 retention 控制。第四步建立 label strategy、golden set 和 eval gate。第五步把线上反馈、incident 和业务结果回流到数据修复和产品 roadmap。

这样 PM 能讲清楚价值和边界, BA 能讲清楚业务语义和异常路径, Architect 能设计可运行的数据流和治理控制, data owner 也有明确运营责任。

10.3 面试追问速答

---

11. 常见误区

---

12. Portfolio Case Study 结构

用于把一个 AI data product 做成求职作品集:

# [场景名] AI Data Product Case Study

## 1. Business Problem
- 业务流程:
- 当前痛点:
- AI opportunity:
- 风险等级:

## 2. Data Product Definition
- Data product:
- Users:
- AI use:
- Eval use:
- Source-of-truth:

## 3. Data Product Canvas Summary
- Business outcome:
- Data scope:
- Contract:
- Metadata:
- Lineage:
- Quality SLO:
- Access:
- PII / consent / retention:

## 4. Readiness Assessment
- Scorecard result:
- Top 5 gaps:
- Pilot gate:

## 5. Eval and Golden Set
- Evaluation dimensions:
- Golden set slices:
- Label strategy:
- Release threshold:

## 6. Operating Model
- RACI:
- Review cadence:
- Incident triggers:
- Feedback loop:

## 7. ROI and Governance Story
- Baseline:
- Expected impact:
- Risk controls:
- Adoption plan:

---

13. 一页总结

AI data product management 的核心是把数据从“可用资源”变成“可运营产品”。

真正成熟的企业 AI 能力不是“模型更聪明”, 而是每个关键 AI use case 背后都有可信、可控、可复用、可审计的数据产品支撑。