6  最小可行数据产品与度量

本章产出： 最小可行数据产品（Minimum Viable Data Product，MVDP）的边界、产品画布和一棵从数据质量连接到业务结果的指标树。

很多 AI 项目在试验阶段进展迅速：团队导入一批文档，接入一个模型，几天内便做出可以对话的演示。进入真实业务后，问题却接连出现：文档更新无人负责，答案无法说明依据，权限沿用共享账号，接口变更没有通知，业务人员尝鲜之后不再使用。演示证明了技术能够运行，却没有证明企业能够长期提供可信的上下文。

从演示走向生产，需要把数据看成产品。数据产品不是数据仓库里的一张表，也不是给数据集换一个漂亮名字。它是一项面向明确消费者、解决明确任务、由明确团队持续负责的服务承诺。数据、语义、接口、质量、安全、文档、运营和反馈共同构成产品，缺少其中任何一项，Agent 都可能在最需要它时失去燃料。

6.1 什么才算数据产品

一个数据对象要成为产品，至少要回答七个问题：

  1. 谁是消费者，他们在完成什么任务；
  2. 产品提供什么数据、语义或决策上下文；
  3. 通过什么方式消费，例如 SQL、API、事件、检索或 MCP 工具；
  4. 对新鲜度、质量、可用性和响应时间承诺到什么程度；
  5. 谁拥有它，谁负责日常运营和变更；
  6. 如何申请权限、发现问题、获得支持；
  7. 如何证明它被使用，并对业务结果产生价值。

这一定义与 OpenMetadata 对数据产品的建模思想相呼应：产品不仅有所有者、域和生命周期，还可以表达输入输出端口、协议、格式、端点以及新鲜度、质量、可用性等服务等级；数据契约则进一步承载模式、质量保证、访问政策和使用条款(OpenMetadata Contributors, 不详)。工具的具体字段会演进，但背后的原则稳定：可发现不等于可消费，可消费不等于可依赖。

在山城精工案例里，“全部维修文档向量库”不是一个合格的数据产品，因为它没有清晰消费者、输出契约和价值边界。“设备售后上下文产品”则可以被完整描述：它服务于售后工程师和诊断 Agent，按设备标识聚合有效配置、适用手册、故障历史、保修规则与备件状态，通过检索接口和结构化 API 提供，承诺关键字段覆盖率与刷新时限，并由售后数据产品小组负责。

6.2 为什么要强调“最小可行”

企业很容易把 AI Ready 误解成先治理全部数据，再开放给所有 Agent。这样的计划范围大、反馈慢，往往在价值出现之前就消耗了组织耐心。另一种极端是只做一次性脚本，把几份文件塞入向量数据库，只要演示能回答问题便宣布成功。这种方案反馈快，却没有生产可靠性。

MVDP 位于两者之间。“最小”意味着只包含首个任务闭环不可缺少的对象、规则和服务；“可行”意味着它已满足真实环境的基本质量、安全和运营门槛；“产品”意味着它不是一次性交付，而有消费者、所有者、契约、指标和反馈。

判断范围是否足够小，可以使用三个问题：

  • 如果删除某项数据，核心任务还能否安全完成？
  • 如果暂不覆盖某类用户，是否仍能验证主要价值假设？
  • 当前建设能否在一个短周期内形成从使用到结果再到改进的闭环？

如果答案表明某项能力只是“未来也许有用”，就应移出首期。最小不是字段越少越好，而是学习回路最短。山城精工首期只选择两个主力设备系列、一个服务区域和近两年已确认的高频故障案例；库存仅提供查询和推荐，不自动锁定；工单只生成草稿，不自动结案。这些限制让团队能够在风险可控的条件下验证诊断时间和一次解决率是否改善。

6.3 MVDP 的六个组成部分

6.3.1 一、消费者与价值主张

先描述消费者当前如何工作、最痛的等待发生在哪里，再描述数据产品改变什么。不要写“提升智能化水平”，而应写“让现场工程师在一次入口中获得设备、手册、案例和备件证据，将跨五个系统搜索的时间从基线值降低到目标值”。价值主张越接近工作动作，后续指标越容易建立。

6.3.2 二、输入与来源边界

列出产品依赖的数据对象、来源系统、同步方式和责任团队，并明确不在范围内的内容。输入不仅是数据库表，还包括规则文档、业务事件、人工确认和外部参考。对每项输入要区分权威来源与辅助来源；发生冲突时，必须有优先级和升级路径。

6.3.3 三、转换与语义

说明如何识别实体、清洗数据、解析文档、处理版本、建立关联和生成语义。对 Agent 而言，文本分块策略、有效期过滤、实体连接、单位转换和同义词管理都属于产品逻辑。转换不能成为无人解释的黑盒，应能够追踪一个输出由哪些输入和规则生成。

6.3.4 四、输出与消费端口

同一数据产品可以拥有多个输出端口：面向分析人员的查询视图，面向 Agent 的检索接口，面向业务系统的结构化 API，面向实时流程的事件流。每个端口需要独立说明模式、认证方式、限流、错误码、版本和示例。不要让所有消费者直接读取内部表，否则任何内部调整都会变成外部事故。

6.3.5 五、服务承诺与治理

为关键数据定义新鲜度、完整性、准确性、一致性、可用性和响应时间。服务等级不是越高越好，而应与任务风险和成本匹配。还要包括所有者、值班与支持、权限审批、敏感数据分类、保留期限、变更通知和退役规则。这些看似“不智能”的内容，决定了智能系统能否被依赖。

6.3.6 六、反馈与运营

记录谁在使用、哪些查询失败、哪些证据被采纳、人工修改了什么、最终业务结果如何。产品团队要有固定节奏审查质量异常、消费变化、用户反馈和成本，并把改进写入待办。没有运营机制的数据产品，会随着源系统和业务规则变化而自然腐化。

6.4 先画产品边界，再选技术

MVDP 画布可以用一页完成：

区域 山城精工首期示例
消费者 一线售后工程师、诊断 Agent
核心任务 设备识别、故障排查、备件建议、工单草稿
输入 设备主数据、有效手册、已确认工单、保修规则、库存状态
输出 设备上下文 API、证据检索、备件查询工具
范围限制 两个设备系列、一个区域、只读建议、人工审批
SLO 关键设备匹配率、文档适用覆盖率、库存延迟、服务可用性
所有者 售后业务负责人、数据产品经理、平台技术负责人
反馈 证据采纳、原因修订、实际备件、结案结果
成功假设 缩短诊断时间，提高一次解决率且不增加安全事故

产品边界明确后，团队才能讨论应该使用批处理还是事件流、搜索还是知识图谱、自建还是采购。反过来先选向量数据库或 Agent 框架，容易让产品边界受工具能力牵引。

6.5 指标不能停在数据质量

数据产品常见的误区是用行数、表数、文档数和接口调用量证明成功。这些指标反映建设活动，却未必代表用户得到了价值。另一种误区是只看最终营收或成本，因为业务结果还受到人员能力、市场环境和流程变化影响，无法直接定位数据产品的问题。

更有效的方法是建立五层指标树：

flowchart LR
    A[数据健康] --> B[Agent 任务质量]
    B --> C[工作流程采用]
    C --> D[业务结果]
    D --> E[风险与单位经济性]

6.5.1 第一层：数据健康指标

它回答产品提供的燃料是否合格，包括设备匹配成功率、关键字段完整率、有效手册覆盖率、库存新鲜度达标率、数据契约通过率、权限策略覆盖率、血缘可追溯率和接口可用性。这一层是原因指标，异常时能够定位到具体数据对象和责任人。

6.5.2 第二层：Agent 任务质量

它衡量 Agent 是否在目标任务上正确使用数据，包括证据召回率、引用正确率、答案有据率、规则适用正确率、拒答准确率、工具调用成功率、结构化输出合规率和高风险错误率。通用语言模型分数不能替代任务评测；评测集必须来自真实业务的常见、困难和边界案例。

6.5.3 第三层：流程采用指标

技术正确不代表被采用。需要观察符合条件的工单中有多少调用了助手、工程师是否展开和采纳证据、建议被修改的比例、从提问到采取动作的时间、回访使用率以及转人工原因。采用率下降可能是答案质量问题，也可能是入口割裂、响应太慢或用户不信任。

6.5.4 第四层：业务结果指标

山城精工可以跟踪平均诊断时长、首次修复率、重复上门率、平均备件等待时间、工单处理周期、客户停机时间和培训新人达到独立作业所需周期。指标必须有基线、统计口径和观察窗口，不能只展示上线后的一个漂亮数字。

6.5.5 第五层：风险与单位经济性

包括越权访问次数、错误承诺、需要召回的错误建议、安全事件、单次成功任务成本、每减少一小时停机的成本、平台固定成本和人工审核成本。AI 场景如果只证明效果而不核算风险与单位成本，很难从试点走向规模化。

6.6 建立可解释的因果链

指标树的价值不是多做一个仪表盘，而是形成可检验的因果假设。例如：

提高手册版本和设备配置的匹配覆盖率，将提升适用证据召回率；召回率提升会减少工程师跨系统搜索；搜索时间减少并且建议准确，才可能缩短诊断时长；诊断更快并不必然提高首次修复率，仍需备件可得和执行规范配合。

这条链提醒团队，不要把相关性直接当作功劳。可采用分阶段上线、同类区域对照、上线前后同口径比较和用户队列分析，尽量隔离其他因素。对于样本量较小的早期阶段，可以同时收集定量结果和结构化访谈证据，但必须明确哪些是已验证事实，哪些仍是假设。

指标还应绑定决策阈值。如果高风险错误率超过门槛，停止扩量并回到影子模式；如果数据健康达标但采用率低，优先研究流程和体验；如果业务效果明显但单次成本过高，优化检索、缓存和模型路由；如果核心价值指标连续多个周期没有改善，则重新评估场景，而不是无限追加功能。

6.7 警惕虚荣指标与指标博弈

“接入一百万份文档”可能意味着噪声更多；“回答率百分之百”可能意味着 Agent 从不拒答；“用户满意率很高”可能来自只邀请支持者试用；“准确率达到九成”如果没有说明样本、风险权重和口径，也没有决策价值。

好的指标必须能引导正确行为。对于高风险任务，与其追求总体回答率，不如分别衡量可回答问题上的正确率、不可回答问题上的拒答率和严重错误为零的持续周期。满意度要与任务完成、实际采纳和业务结果交叉验证。成本指标要按成功任务而非单次调用计算，避免用减少调用次数换来更低的完成率。

同时要设置护栏指标。缩短诊断时间不能以增加错误换件为代价，提高自动化率不能以绕过审批为代价，提高召回率不能把无权访问的信息送入模型。主指标与护栏指标共同构成上线门槛。

6.8 MVDP 的完成定义

一个最小可行数据产品可以在满足以下条件时进入受控生产：

  • 至少一个真实用户群在真实流程中消费，而非只在演示环境使用；
  • 核心输入有权威来源、负责人和冲突处理规则；
  • 输出端口具备版本、认证、文档和错误处理；
  • 关键质量与服务等级能够自动监测并告警；
  • 权限在检索和工具执行前生效，关键过程可审计；
  • 任务评测集覆盖正常、困难、对抗和越权案例；
  • 用户修订与业务结果能够回流，且回流有审核；
  • 价值指标有上线前基线、目标、观察周期和停止条件；
  • 团队知道出现故障时如何降级、转人工和恢复。

“完成”并不意味着产品不会变化，而意味着它已经具备负责任地变化的能力。MVDP 的真正成果也不是某个模型分数，而是一条可重复的学习链：用有限范围进入真实工作，用数据观察结果，用反馈辨别问题，再有依据地扩大范围。

6.9 本章交付物：产品画布与指标树

项目评审时，应同时提交 MVDP 画布和指标树。画布回答“我们在为谁提供什么承诺”，指标树回答“我们如何知道承诺产生了价值”。两者缺一不可：没有画布，指标会失去产品边界；没有指标，画布会停留在主观叙事。

对于山城精工，首期北极星指标可以设为“在安全护栏内由助手支持完成的有效诊断任务数”，而不是对话次数。其下连接诊断时长和一次修复率，向上受业务价值解释，向下由设备匹配、证据召回、建议采纳和人工修订等驱动指标支撑；高风险错误、越权访问和单位成功成本则作为护栏。

当团队能够从一条错误建议一直追到错误数据、规则版本和负责人，也能够从一项数据改进一直观察到任务与业务结果，数据才真正成为产品。此时，AI Ready 不再意味着“拥有许多可以给 AI 使用的数据”，而意味着企业拥有一套能够持续向智能应用交付可信上下文、度量价值并承担责任的产品机制。