执法缺口 — 数据是怎么说谎的
这一章讲三件事: 执法缺口——语义设计与日常产出之间的那段距离; 它为什么在 RAG 时代变得格外危险(错数会被包装成自信的叙事); 以及关掉它的唯一思路:把元数据从「事后文档」翻转为「事前规格」。 承上:03-05 章建了语义模型;这一章解释为什么光「建」不够——没人执法它会漂。
1. 顶层全景:地图不等于路
设计层: 语义模型(03-05 章的成果)
│ 「组织以为大家认同的定义」
│ ← 这里有一段谁都没管的空隙
▼
现实层: 平台每天实际产出的数据
│ 「赶工期工程师写出来的东西」
▼
RAG 应用: 把现实层数据包装成流畅自信的回答
图说:书用的比喻——语义模型是地图,但地图不保证每个旅人都走在该走的路上。
这段空隙,就是本章的主角。
2. 目录为什么救不了:事后扫描的天花板
这一节先排除一个最常见的误会:「我们买过数据目录,不是有治理了吗」。
先看缺口怎么形成。书描绘的链条是:AI 变成业务核心后,治理成了地基需求—— 治理依赖关于数据本身的可靠信息:从哪来、代表什么、谁负责、现在可不可信。 这些上下文不跟着数据走,碎片化和重复就渗进来,同一个问题出现不同的答案, 信任稳步流失;工程师背锅修不是自己造成的差异,分析师开始怀疑自己的数据, 领导层开始怀疑整个平台1。
到了这一步,多数组织的直觉反应是:「我们的数据目录不就是干这个的吗?」
(目录:盘点全公司有哪些数据、各自说明书的工具。)书的回答是不行,原因一句话:
传统目录是事后扫描——它能扫出表和列长什么样,却查不出一段转换逻辑
有没有偏离语义。书举的例子很具体:一个叫 partner_segment(合作伙伴分群)的列,
从目录的角度看完全正常,哪怕推导它的逻辑从一开始就是错的2。
这个错位,书命名为执法缺口:组织以为已经标准化的语义, 与平台日复一日实际产出的东西之间 的距离。书对它的后果描述得毫不留情: 就在这个缺口里,不一致开始滋生、信任悄悄蒸发,而 RAG 系统自信地给出 看似可信、措辞漂亮、却完全失准的回答3。缺口不关,语义模型就始终停在理论, 理论保不住任何人可依赖的数据3。
3. 主走查:一个指标,两个实现,一整个组织的错误决策
这一节把执法缺口的杀伤过程从头到尾走一遍。书里这个例子值得逐帧看。
主角是一个企业里最普通的指标:独立活跃用户(Unique Active Users; 「独立」=同一个人数一次)。组织对它的语义定义很清楚:只有登录过、 并且在所选时间段内完成过至少一次有意义操作的用户才计数—— 这是全公司公认的「采用与留存」信号,高管紧盯着的一个数4。
现在,两个团队各自实现它(下面的具体数值是演示编的,书里给的是定性描述):
团队 A(照定义实现):
登录 且 30 分钟内有一次有意义操作 → 6,100 人
团队 B(赶工期,砍掉「有意义动作」):
只要登录过就算 → 8,400 人 ← 比真实口径虚高约 38%
两个数都「看起来合理」。但它们已经在回答两个不同的问题。
这套错数在 BI 时代会怎样? 书描写的流程:报表评审会上有人发现 两个报告的月活对不上,提一个问题,立一个 bug。错得早、发现得早、影响被圈在会议 室里,调查清楚之前错误传不远5。
同样的错数进到 RAG 时代,流程完全变样6:
第 1 步 产品经理问 AI 助手:「新功能本月有多少活跃用户?这对采用意味着什么?」
第 2 步 检索层取回的,恰好是虚高的那个数:8,400
第 3 步 模型围绕它合成一段连贯的叙事:「采用正在加速,
建议加大投入」——语法完美,口吻自信
第 4 步 这段话被复制进战略幻灯片、贴进管理层频道
第 5 步 决策开始围着它转。错误不再是「一处不一致」,
它成了组织内部的一个「新现实」
图说:第 2-5 步里没有任何一步会停下来问「这个数对吗」——
每一步都在往前传,而且越传越像真的。
书对这一幕的定性,是全书被引用价值最高的一句话:「数据就是在此时说谎。 AI 没有发生传统意义上的幻觉——它基于坏事实做出了完美的推理(每一步都合乎逻辑)。 故障不在 AI,在我们喂给它的数据。」 谎言裹着流畅的外衣、带着自信送达, 而且恰好送到团队最需要清醒的时刻7。
这个失败模式有个名字:未经验证的接地数据——检索到的数据在格式上完全合法, 含义上却不可靠。书特别强调它不是又一个数据质量问题的新标签, 而是一种结构性故障:因为模型能把哪怕劣化的输入,变成流畅权威的回答, 所以缺口本身就成了一台制造高置信度错误信息的机器8。它的根源在于 RAG 的 前提假设:LLM 是语言引擎,不是事实引擎;整套检索增强的赌注就是 「检索来的数据是真的」——模型不知道管道有没有漂,它对我们给的数据, 百分之百信任9。
由此推出本章的结论,也是下一章的全部出发点:人不可能在人机界面这一端 拦住每一个似是而非的错数——等有人看出不一致,损害已经在路上。 要保证的只能是一件事:数据在被写入之前就可信。这需要重造管道的建法10。
4. 元数据优先:把文档翻转为规格
这一节讲关掉缺口的思路转变。处方本身(管道契约)留给第 07 章。
书先诊断现状——元数据最后的工作模式,多数人身在其中而不自知:需求来了 → 找源数据 → 写复杂的转换代码、把数字凑到对 → 管道跑起来了,才有人要求补文档。 元数据成了「有空再补」的东西。在这个模式里,元数据描述的是已经发生的事, 代码和元数据完全脱钩,然后立刻开始漂移——这就是执法缺口的根因11。
翻转后的模式叫元数据优先:元数据是规格,不是文档;是第一件写的东西, 不是最后一件;是系统在写下任何一行业务逻辑之前就能验证的正式意图声明12。
书说这个翻转在软件工程里发生过一次,可以原样类比:质量和安全曾经也排在 生命周期末尾(上线前扫一次安全),后来行业学到——末端测不出来, 要在源头就阻止不安全的代码被写出来。数据工程正在经历同一步: 不是管道跑完再扫质量问题,而是用元数据当规格,让不合规的管道根本建不起来13。
目标也随之改变,书用的是这组对照14:
| 元数据最后 | 元数据优先 | |
|---|---|---|
| 元数据是 | 事后描述 | 事前规格 |
| 平台在什么时机介入 | 数据坏了之后报警 | 写入之前拦截 |
| 团队在追求 | 描述自己「希望」正确的数据 | 证明数据在写入前符合定义 |
5. 作者的判断与证据、边界
有推理撑的: UAU 双实现的走查逻辑严密,且 BI 与 RAG 两条时间线的对照 来自可复核的机制差异(人眼评审 vs 毫秒检索)56;「LLM 是语言引擎不是事实引擎」 与书架上 RAG 文献对「接地」的定义一致。
作为主张提出的: 「人工拦不住」是一个强断言——书没有给出 「事后告警+人工复核能拦截 X% 错数」的测量;「目录没用」针对的是语义统一这一件事, 不是说目录在盘点、发现上没有价值,引用时不要扩大化。
边界: 本章只立了问题,「证明数据在写入前符合定义」的具体机制(契约、单测、 平台执法)全在第 07-08 章——这是 Early Release 里前后衔接最紧的一对章节。 另外,走查里的虚高 38% 是我们为演示编的数;书给的是机制,不是量级。
6. 可带走的
全章走查合起来一行: 同一个 UAU 定义,两个实现差出 38%(演示值)→ 在 BI 时代被报表评审拦下,在 RAG 时代被模型包装成「采用在加速,建议加投」 直接进战略 deck——错在哪一环?数据写入之前,没有任何一环问过「这个数对吗」。
- 执法缺口 = 以为标准化了的语义 与 实际产出的数据 之间的距离;
- 目录是事后扫描:扫得出形状,查不出
partner_segment的推导逻辑对不对; - 数据在此时说谎:AI 没有幻觉,它基于坏事实做了完美推理——责任在数据侧;
- RAG 的前提是「检索来的为真」,模型对坏数据百分之百信任;
- 未经验证的接地数据是结构性故障,不是普通数据质量问题的别名;
- 人机界面端拦不住错数;唯一可靠的关法是写入之前就保证;
- 元数据从「事后文档」翻转为「事前规格」,与软件工程的质量左移同构;
- 目标从「描述希望正确的数据」改成「证明写入前符合定义」。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 地图不等于路 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:14(搜「map does not keep」) |
| 治理依赖数据自身的信息 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:24(搜「where it originated」) |
| 工程师/分析师/领导层的连锁反应 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:26(搜「skeptical」) |
| 「不是有目录吗」与事后扫描 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:28(搜「data catalog」) |
| 执法缺口定义 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:30(搜「Enforcement Gap」) |
| 理论保不住数据 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:32(搜「remains theoretical」) |
| 未经验证的接地数据 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:36(搜「unverified grounding」) |
| 语言引擎不是事实引擎 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:38(搜「linguistic engine」) |
| UAU 定义 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:40(搜「meaningful action」) |
| 双实现 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:42(搜「two different pipelines」) |
| BI 时代的拦截 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:44(搜「dashboard review」) |
| RAG 时代的流程 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:46(搜「coherent narrative」) |
| 成为新现实 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:48(搜「strategy deck」) |
| 「数据就是在此时说谎」 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:50(搜「bad facts」) |
| 必须在写入前保证 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:54(搜「before the data is written」) |
| 元数据最后的传统流程 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:60(搜「metadata-last」) |
| 脱钩与漂移=根因 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:62(搜「drift apart」) |
| 元数据是规格不是文档 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:66(搜「specification」) |
| 软件工程左移类比 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:68(搜「security」) · text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:70(搜「prevent」) |
| 目标改变 | 元数据优先的管道工程 | text/06-ch03-chapter-3-metadata-first-pipeline-engineering.txt:72(搜「proving」) |