13 数据质量、血缘与契约

本章产出： 一套从源数据、知识表示到 Agent 回答的端到端可观测模型，以及面向生产者与消费者的数据契约。

企业通常已经有数据质量规则：主键不能为空、金额不能为负、日期不能超出范围。Agent 引入了新的质量链路。一份维修手册在源库中完整存在，可能因 OCR 错误丢失数字；解析后的段落正确，可能因分块把警告与步骤分离；索引及时更新，可能因型号过滤错误召回不适用版本；证据正确，模型仍可能在组织语言时加入未被支持的结论。

因此，AI Ready 的信任不能由一个“数据质量分”概括。要把事实质量、语义质量、知识表示质量、检索质量、回答质量和业务结果串成可观察链路，并能从一次错误回答回到真正的责任点。

13.1 质量是一项任务属性

同一数据对不同任务有不同门槛。客户电话号码缺失可能不影响故障原因分析，却会阻止现场联络；库存延迟一天对月度报表影响较小，对即时备件承诺则不可接受。质量规则应从任务风险和数据契约倒推，而不是给全平台设置一套最高标准。

可以从六个维度描述基础质量：

完整性：完成任务所需字段和对象是否存在；
准确性：值是否与现实或权威来源一致；
一致性：跨系统、跨时间、跨表示是否冲突；
唯一性：实体和事件是否重复；
有效性：格式、范围、单位和规则是否符合约束；
及时性：数据年龄和处理延迟是否在允许范围。

还要增加面向知识与 Agent 的维度：文档适用性、解析完整性、引用可达、证据覆盖、权限正确、拒答可靠和动作可恢复。每项指标都应绑定具体资产、消费端口和任务，而不是悬空展示。

13.2 端到端质量链

flowchart LR
    A[源事实] --> B[采集与转换]
    B --> C[语义与产品]
    C --> D[解析与索引]
    D --> E[检索与工具]
    E --> F[回答与行动]
    F --> G[业务结果]
    G --> H[反馈与改进]

13.2.1 源事实质量

检查权威系统中的实体、字段、版本和业务状态。设备序列号覆盖、现场变更记录、手册发布日期、工单结论审核都属于这一层。源端问题不能通过下游“清洗”永久隐藏，应反馈给业务流程和生产者。

13.2.2 管道与转换质量

检查采集水位、记录对账、重复、乱序、模式变化、转换异常和血缘。管道成功只说明代码执行完成，不代表数据完整。需要把源端数量、摘要、事件时间和目标结果对账。

13.2.3 语义与数据产品质量

检查实体连接、术语、指标、有效时间、输出模式和 SLO。一个字段有值，但单位错误，技术检查可能通过，语义质量仍然失败。产品端应公开质量状态和已知限制。

13.2.4 知识表示质量

检查 OCR、版面、分块、表格、图片说明、Embedding 和索引同步。可建立抽样检查、规则检测和人工黄金样本。例如安全警告必须与操作段落保持关联，文档版本和页码必须能追溯，撤回文档不能继续召回。

13.2.5 检索与工具质量

检查实体识别、过滤、召回、排序、引用与工具返回。需要区分“没有召回正确证据”和“召回了但模型没有使用”。工具质量还包括接口新鲜度、参数校验、幂等与业务结果确认。

13.2.6 回答与行动质量

检查事实正确、证据支持、规则遵守、结构合规、拒答、越权和动作结果。高风险错误应单独计权，不能被大量简单问答的正确率稀释。

13.3 血缘从表扩展到回答

传统血缘连接表、字段和任务。AI 链路还要连接文档、块、向量、索引、检索结果、提示上下文、工具调用、回答结论和业务动作。无需保存模型不可解释的内部思维，但要保存外部可验证的证据和版本。

一次山城精工诊断可形成如下记录：

回答结论 → 引用块 → 手册版本 → 原始文件 → 发布流程与所有者

备件建议 → 库存工具响应 → 库存服务版本 → ERP 交易状态

设备配置 → 上下文 API → 标准化实体 → MES 与现场变更记录

当手册被撤回，反向血缘可以找到相关索引和受影响回答；当某批设备映射错误，可以识别哪些评测、建议和工单需要复查。血缘由此从文档功能变成运营和风险控制能力。

血缘节点要携带时间。今天的回答引用当时有效的规则，即使规则明天更新，也不能简单判定当时错误。双时态或版本快照使系统能够重放“在那个时间点，Agent 能看到什么”。

13.4 数据契约的结构

契约让生产者、数据产品和消费者对可依赖内容形成共同承诺。它可包括：

组成	示例
范围	设备上下文产品、适用用户与任务
模式	字段、类型、必填、枚举、单位
语义	定义、粒度、有效时间、冲突优先级
质量	完整、唯一、准确、适用覆盖
服务	刷新频率、最大延迟、可用性、响应时间
安全	分类、读取范围、目的、保留、使用条款
变更	版本、兼容规则、通知、迁移与弃用
责任	业务、技术、质量、安全和支持负责人
失败	告警、降级、补偿和升级路径

契约不是生产者单方面发布的 SLA，也不是消费者无限要求。双方要基于业务风险和成本协商。库存查询可以承诺秒级响应，历史案例产品未必需要；首期两类设备的手册覆盖不应被写成全品类承诺。

13.5 契约即代码，但不止于代码

可自动验证的内容应进入持续交付：模式兼容、必填、枚举、质量阈值、刷新、权限策略和接口测试。源团队提交变更时，系统提前检查是否破坏消费者；运行期持续监测 SLO；失败触发事件并沿血缘通知受影响产品。

然而语义变化难以只靠代码发现。“完成时间”字段仍是时间戳，但从工程师提交变为客户验收，技术模式完全兼容，业务含义却破坏。关键语义需要人工评审、版本说明和消费者确认。契约自动化的目标是减少意外，不是取消协作。

契约也要版本化。兼容新增可以在同一主版本演进，删除、改义、改变单位等破坏性变化需要新版本和迁移窗口。消费者应声明依赖的版本，平台通过血缘分析通知，而不是依靠群消息。

13.6 质量事件与影响管理

发现异常后，系统需要的不只是红色图标。质量事件至少包含资产、规则、发生时间、严重度、影响范围、责任人、当前状态、临时措施和根因。严重度从业务任务倒推：导致高风险错误建议的问题优先级高于不影响使用的可选字段缺失。

可以将响应流程分为：

检测并去重，确认不是监控噪声；
利用血缘识别受影响产品、索引、Agent 和用户；
按契约决定继续、降级、停止或转人工；
通知责任人和消费者，展示数据状态；
修复源、管道或语义并进行重放；
验证恢复，复查受影响动作；
记录根因和预防措施。

例如手册索引延迟超过 SLO，助手可继续查询设备事实，但不应给出确定维修步骤；它说明资料状态并引导工程师使用正式文档入口。透明降级比返回旧答案更可信。

13.7 质量门禁与风险分级

不是所有质量失败都阻断服务。可以按任务和数据重要度设置：

信息级：记录趋势，不影响当前任务；
警告级：降低可信提示，允许用户确认后继续；
阻断级：关键输入或策略失效，必须拒答或转人工；
事故级：已产生潜在错误行动，需要停止、通知和复查。

门禁应在数据发布、索引构建、Agent 上线和业务执行多个位置生效。发布前阻止不合格数据，运行时识别陈旧，回答前检查证据，行动前再确认权威状态。多层门禁避免把所有信任寄托在最后一步。

13.8 SLO、SLI 与错误预算

SLI 是实际观察指标，SLO 是目标，错误预算允许系统在一定范围内不完美。关键是把目标写成可度量窗口，例如“过去七天，百分之九十九的设备上下文请求在两秒内返回，且配置数据年龄不超过一小时”。

错误预算有助于平衡创新与可靠性。当质量或可用性持续耗尽预算，团队暂停扩功能，优先修复；预算充足时，可以进行受控实验。高风险事件不能被平均错误预算掩盖，严重越权或安全错误应采用零容忍门禁。

数据产品的 SLO 与 Agent 任务 SLO 要连接。某产品达标却不足以保证端到端任务达标，但一旦任务下降，可以从依赖 SLI 寻找原因。

13.9 山城精工的质量控制

首期可选择少量关键规则：

设备标识与型号匹配率达到约定门槛；
有效手册对范围内设备的覆盖可验证；
每个检索块可回到正式文档版本和页码；
库存结果展示查询时间，超时不作确定承诺；
已确认案例必须有最终原因和实际处置；
高风险排查步骤必须引用安全规则；
权限过滤与引用访问保持一致；
证据不足的样本必须正确拒答或澄清。

这些规则直接连接售后任务，比“所有字段完整率达到九成”更有意义。随着范围扩大，再根据失败数据增加规则，而非一开始建设庞大且无人响应的检查库。

13.10 本章交付物：端到端信任矩阵

对每个关键任务，建立一张矩阵：

链路	对象	质量指标	血缘	契约与负责人	失败行为
源	设备、手册、工单	准确、完整、有效	权威系统	领域所有者	修复或标记
处理	实体、规则、块	对账、关联、解析	任务与版本	数据产品团队	隔离、重放
服务	API、索引、工具	新鲜、可用、权限	产品与消费者	平台/服务团队	降级、熔断
Agent	证据、回答、动作	支持、拒答、风险	会话与业务结果	Agent 产品团队	澄清、转人工

企业无法通过一组检查保证永远正确，但可以让质量状态可见、变化可协商、失败可定位、影响可控制、修复可验证。数据质量、血缘与契约共同构成的不是一套治理装饰，而是 Agent 在真实企业中取得信任的证据系统。

当这种证据系统进入日常运营，质量也不再只是数据团队的责任。业务生产者修正源头流程，产品经理按照任务价值安排优先级，架构团队维护可追溯链路，Agent 团队验证最终行为。每个角色都能看见自己的改变如何影响下游，企业才真正形成质量闭环。