消费者换了 — 仪表盘为什么喂不饱模型
这一章讲三件事: 一家买了二十年数据平台的公司,为什么大语言模型一接入就露馅; 「企业上下文缺口」具体指什么;以及这个缺口为什么不是钱或数据量的问题, 而是五个能点名的设计缺陷。 它是全书的地基:后面七章讲的所有模式,都是为了填这个缺口。 不需要任何基础,遇到的生词都当场解释。
1. 先看现象:这个问题,人和模型各会怎么答
想象你是这家公司的管理层,问了一个很普通的问题:
「如果客户流失的趋势继续下去,我们在亚太区的营收风险有多大?」
书里就拿这个问题开场1。先看人会怎么做:一个分析师会翻销售系统的客户记录, 调出支持工单里最近在抱怨什么,对照合同里哪些大客户今年到期, 再看看市场数据——来回用好几个系统,把散落的信息拼成一个答案。
再看模型怎么答。这里说的模型,是大语言模型(Large Language Model,缩写 LLM)——读过上亿篇文章、 能按文字续写和回答问题的 AI 系统。它答这类问题会栽跟头1。 栽在哪?不是不会说话——恰恰相反,它答得头头是道。它缺的是你公司内部的真实情况, 书里叫它「企业上下文」(即公司自己的客户、合同、工单这些内部实情):这家公司自己的客户、合同、工单、指标,这些从来没进过它读过的材料。
书里给这个状态打了个比方:一个才华横溢的顾问,但从没翻开过你公司的账本—— 聪明,有说服力,就是没有根基2。
本章的主走查:同一个问题,走一遍你的平台
这一章后面每节都会回到上面那个「亚太区营收风险」的问题。先把两种结局摆出来:
问题:「亚太区营收风险有多大?」
│
├─ 仪表盘时代的平台:只有按月汇总好的收入数字(如「亚太 Q2 收入 3.2 亿」)
│ → 没有任何一列数据叫「流失风险」→ 答不出来,或者硬编一个
│
└─ RAG 时代需要:销售记录 + 支持工单 + 合同到期日 + 宏观指标
→ 各源头取相关片段 → 拼成有出处的回答
图说:左边这条路,平台的货架上根本没摆那个商品;右边这条路,要的不是一个报表,
而是**跨五个源头按需取材**。这些数字是演示编的,不是书里的真实数值。
记住这张图。所谓「缺口」,就是左右两条路之间的距离。
2. 消费者换了:平台为谁建,就朝谁的方向打磨
这一节回答:为什么现有平台恰恰缺这些东西——不是运气差,是它本来就不是为这个建的。
过去二十年,企业数据平台的进化路线是:数据库 → 数据仓库(把全公司的业务数据汇总起来做分析) → 数据湖(什么格式的原始数据都先存下来)→ 再到各种「织网」式的一体化平台3。 每一代都更强大,但服务对象从来没变过:人。
人要什么?书里总结为旧时代的「北极星」:数字准确、更新及时、口径一致、图表好切4。 消费者是人,界面是可视化图表,问题大都是预先定好形状的——「上季度各 区卖了多少钱」 这种,报表早就画好了等着看。
模型要的完全不同。书里的原话值得记住:模型不要仪表盘,不消费关键绩效指标; 它要的是埋在数据里的、原始的、带上下文的知识——要能检索,不只是看聚合结果; 要能推理(自己一步步想出答案),不只是看图5。
回到主走查那个问题。回答它需要的是6:
| 需要的材料 | 存在哪个系统 | 仪表盘里有吗 |
|---|---|---|
| 客户流失迹象 | 销售系统的客户笔记、支持工单 | 没有 |
| 合同与定价 | 合同库(很多还是扫描件) | 没有 |
| 宏观环境 | 外部指标 | 没有 |
| 每个数字的出处 | 各源头 | 没有 |
同一个平台,旧消费者(人)用着很顺手,新消费者(模型)一上来就断粮。 书里把这个错位命名为企业上下文缺口:数据系统被建来交付的东西, 和生成式(能自己产出新内容的这类)AI 实际需要的东西之间的断裂7。(「生成式」指能自己产出新文字的这类 AI。)
还有一个容易被忽略的变化:界面变了。旧时代人通过点击图表交互; RAG 模式下,消费者是模型(以及它背后的人),界面是自然语言, 问题是开放式、跨领域、时效敏感的6。这意味着平台没法再靠「预先画好图表」来应对—— 你不可能为模型可能问到的每个问题预先画一张图。
3. 缺口的五个成因:全都能点名
这一节回答:缺口到底是抽象的「不匹配」,还是具体的、可以逐条检查的缺陷。 书给的答案是后者——五个成因,每一个都能拿去对号入座8。
| 成因 | 一句话 | 具体长什么样 |
|---|---|---|
| 碎片化 | 知识散落在各处 | 关键知识散布在数据仓库、数据湖、各种订阅制软件的数据孤岛、内部维基、PDF、邮件里 |
| 浅语义 | 「是什么意思」没有记录 | 同一个东西在各系统里叫法不同、重复、互相矛盾 |
| 治理为报表而建 | 审批走人的时距 | 季度签核、人工审批,跟不上毫秒级的检索请求 |
| 元数据只是文档 | 写了没人(没机器)能执行 | 出处、契约、政策都存在,但只是给人看的文档 |
| 质量在仪表盘不在代码 | 好坏是「看出来的」 | 检索的时候没有任何「新鲜不新鲜、全不全、可不可信」的信号可查 |
这五个词里有两个需要当场说清:
- 元数据:关于数据的数据。比如「这张表是谁、什么时候、从哪个源头、按什么口径算出来的」—— 表本身是数据,这些说明是元数据。
- 语义:一个词或一列数在业务上是什么意思。「活跃用户」这三个字是文字; 「登录过且做过一次有意义操作的用户」才是它的语义。
书里还点出了这五个成因叠加后的可预测结果:原型演示令人惊艳, 生产系统消耗信任,团队卡死在「演示天堂」里——demo 永远成功,上线永远失信9。
判断(我们的,不是书里的): 这张五成因表其实是全书的价值所在—— 它把一个容易被讲成玄学的问题(「我们的数据对 AI 不友好」)拆成了五张可执行的工单。 后面七章严格说就是在逐条还这五笔债:03-05 章还「浅语义」和「元数据只是文档」, 07-08 章还「质量在仪表盘不在代码」,02 章的信任层还「治理为报表而建」。 如果错,会错在: 如果碎片化(第一条)其实是主要矛盾, 那么还清后四笔也只得到一个语义清晰但仍然分散的平台——书对这一条着墨确实最少。
4. 这是谁在说话:四个从微软平台一线来的人
这一节交代作者凭什么写这本书——因为他们不是观察者,是当事人。
四位作者都在微软负责一个叫 IDEAS 的组织——一家企业内部的数据平台, 支撑 Microsoft 365、Copilot 和面向客户的分析服务,规模是数百 PB、 数万个数据源10。(PB 是存储单位,1 PB 约等于 25 亿张手机照片; 数百 PB 就是几百个这样的量级。)
他们的原话是:过去的工作是「建单一事实来源,把它当关键服务来运营」; 生成式 AI 一来,这个目标不够了,必须从「数据即服务」走向「数据即 AI 服务」11。
由此他们总结了四条带血的经验,全书的骨架就是这四条12:
- 语义从源头开始——核心概念(User、Tenant、订阅、合同)的含义在数据进来那一刻 就要抓住,事后到语义层去「修」对 RAG 来说太晚了;
- 元数据必须能编译——契约、出处、质量规则、政策不能只是文档, 必须机器可读、在创建时就被强制执行(「编译」是借用编程的说法:写错了直接不让通过);
- 信任是运行时信号——质量不是季度报表上的结论,是检索层随时能查到的活信号;
- 目的胜过权限——光管「谁能看什么」不够,还要说清「为了什么场景看」(即 SBAC,02 章讲)。
判断(我们的,不是书里的): 这四条教训全都指向同一个方向—— 把「靠人的自觉和事后检查」换成「靠平台在数据创建的那一刻强制执行」。 读这本书时要一直带着这个视角:它讲的所有模式,都是这条原则在不同环节的具体化。 如果错,会错在: 如果某些组织靠人的自律就能维持语义一致, 那这套重装备属于过度设计——但书里第 3 章的案例恰好是自律失败的真实记录。
5. 边界与局限:动笔前必须知道的三件事
这一节讲这本书没讲什么、以及读它之前要先打哪些折扣。
第一,这是一部没写完的书。 你手上的是 Early Release(早期试读版), 正式版计划的模式清单里还包括「质量作为检索信号」「策划好的接地样例与活术语表」「SBAC」 「企业级 RAG 栈」13,但本书只出到第 3 章。书里还两次向前指: 词汇问题「第 5 章讲」14、场景访问控制「第 6 章展开」15——这些章节都不存在。
第二,它不讲 RAG 本身。 检索怎么切块、向量(把文字变成的一串数,意思越近数越近)怎么算相似度、生成怎么防幻觉, 这些在 书架上的其他 RAG 书里;这本书管的是 RAG 的前置工程—— 数据在进入检索之前的那一大段路。一句话分工:别的书教你怎么把饭做熟, 这本书教你米在进厨房之前就得是干净的、标好产地的。
第三,作者全部来自微软,案例全部来自微软。 模式以微软内部系统命名 (IDEAS、UDM、Geneva 等),这既是可信度的来源(全是生产环境验证过的), 也是局限——「大型平台病」的处方,对一个几十人的数据团队未必按重量配。
6. 可带走的
全章那条走查,一行写完:「亚太区营收风险」这个问题,旧平台只有按月聚合的报表, 答不了;要答它,得跨销售记录、工单、合同、外部指标按需取材并给出处—— 两条路之间的距离就是企业上下文缺口。
- 数据平台的消费者换了:从「看报表的人」换成「检索数据的模型」, 旧的成功标准(聚合准、图表快)对新消费者无效;
- 缺口不是抽象口号,是五个可点名的成因:碎片化、浅语义、报表化治理、 元数据只是文档、质量在仪表盘不在代码;
- 「演示天堂」是缺口的标准症状:demo 惊艳、上线失信,根子在平台不在模型;
- 语义和元数据要当场解释:语义=一个词在业务上是什么意思;元数据=关于数据的说明数据;
- 作者的立场要知情:四个微软 IDEAS 负责人,「数据即服务 → 数据即 AI 服务」, 处方带大型平台前提;
- 这是一部 Early Release:许诺的模式只出了前三个,后面靠我 们自己的书架补位。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 开场问题、模型栽跟头 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:12(搜「Asia-Pacific」) |
| 顾问没翻过账本 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:14(搜「gifted consultant」) |
| 仓库→湖→fabric | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:16(搜「warehouses, then lakes」) |
| 旧北极星:仪表盘 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:18(搜「north star」) |
| 模型不要仪表盘 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:20(搜「don't want dashboards」) |
| RAG 改变交互、需要的材料 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:24(搜「churn risk」) |
| 企业上下文缺口定义 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:22(搜「enterprise context gap」) |
| 缺口五个成因 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:50(搜「Fragmentation」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:70(搜「demo purgatory」) |
| IDEAS 规模 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:76(搜「petabytes」) |
| 数据即服务→AI 服务 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:78(搜「data as an AI service」) |
| 四条教训 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:82(搜「start at the source」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:86(搜「compile」) |
| 全书模式清单 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:98(搜「curated grounding」) |
| 词汇问题留给第 5 章 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:34(搜「chapter 5」) |