跳到主要内容

阅读笔记 — rag-ready-patterns-for-data-platforms

Early Release,只有 3 个正文章(ch1/ch2/ch3)。导航章(01 标题页/02 版权页/03 简要目录)跳过。 07 是作者简介(四位都是 Microsoft IDEAS 的人,写进总纲第 2 节,不引用)。

Ch1 The Pillars of RAG Readiness(text/04-…txt,472 段)​

  • L12:开场问题「亚太区营收风险,若客户流失趋势继续」——LLM 答不了,缺企业上下文
  • L14:比喻「从没翻过公司账本的顾问」:聪明、有说服力,但没有根基
  • L16:仓库→湖→fabric 的演进史;L18:旧北极星=仪表盘/报表,消费者是人,界面是可视化,问题是预定形的
  • L20:LLM 不吃仪表盘不吃 KPI;要检索不要聚合,要推理不要可视化
  • L22:「企业上下文缺口」定义;L24:RAG 改变三件事:消费者=模型、界面=语言、问题=开放式跨域(流失风险问题需要 CRM 工单/遥测/合同/定价跨源+可引用)
  • L26:分析时代的成功标准:性能/准确/治理/成本;RAG-ready 定义
  • L28-34:RAG-ready 四能力:机器可懂的知识表示(embeddings/ontology/semantic layer)、跨结构化+半结构化+非结构化的弹性检索、对话式推理、可辩护可审计的 lineage+trust
  • L48-70:缺口五成因:碎片化(L52)、浅语义(L56)、为报表建的治理(L60)、元数据只是文档(L64)、质量在仪表盘不在代码(L68);结果=「demo purgatory」演示天堂、生产失信(L70)
  • L76:IDEAS:数百 PB、数万源、服务数千内部团队+数百万外部用户;支撑 M365/Copilot
  • L78:从 data as a service 到 data as an AI service
  • L82-96:四条血泪教训:①语义从源头开始(L84,User/Tenant/Subscription/Partner/License/Product);②元数据必须能编译(L88,metadata as code);③信任是运行时信号(L92,freshness/completeness/confidence);④目的胜过权限(L96,SBAC,与 RBAC/ABAC 并用)
  • L98:全书 pattern 清单:实体内核+分层语义、metadata-first 管道工程、质量作为检索信号、curated grounding+活术语表、SBAC、企业级 RAG 栈——后面几章只出了 3 章,这是 notCovered 的依据
  • L116-128:三支柱:Data Assets / Infrastructure / Trust Layer
  • L134-165:表 1-1 自检清单(✅⚠️❌)
  • L171-175:支柱一:RAG 要连通的知识;数千系统各定义「用户」不同→LLM 缝不起来→幻觉或浅答
  • L177-191:实体内核:9 个例实体;三层:source(ID 神圣)/conformed(语义契约)/product(fit-for-purpose 投影);术语表绑内核;ontology「lite」不是博士练习
  • L193-205:案例:三个「用户」定义(计费=按 SKU 授权;身份=目录对象;遥测=发事件活跃用户)→AI 问「德国活跃用户+流失风险」→检索层把三路切片混进上下文窗口→分子分母重叠错乱→败在数据资产层不在 LLM
  • L207-233:Entity Kernel Pattern:声明式、集中治理、联邦扩展;五要素:标识符/属性/关系/隐私分级/所有权;微软内核=User/Tenant/Device/Subscription/License/Partner/SKU
  • L235-274:表 1-2 成熟度:1 Ad Hoc→2 Glossary Only→3 Federated Kernel→4 Semantic Fabric;「多数组织在 1 或 2 级;3 级是第一个真正的拐点」(L274)
  • L276-314:支柱二:转换会侵蚀语义(L278);传统平台把语义藏进代码、元数据当副产品(L280);「metadata must compile」(L282);前一代手写 ETL(L284);四原则:契约第一工件(L300)/管道即执法者(L302)/质量即服务(L306)/统一索引+按语义边界切块并绑回 lineage(L310)
  • L316-318:案例:每小时刷新仍出陈旧用量数;根因=新鲜度只存在于仪表盘不在代码;修复=新鲜度时间戳+检索时阈值,过期查询直接丢弃
  • L320-361:表 1-3:1 Scripted ETL→2 Contracted→3 Compiled Metadata→4 Autonomous Trust Engine;「3 级是 RAG-ready 运营的入场券」(L361)
  • L363-381:支柱三:信任是运行时属性(L365);人类时距(审批/审计)vs 毫秒时距(L367);SBAC(RBAC=角色,ABAC=属性,SBAC=显式业务场景;短签名策略记录;检索时评估 purpose+person+policy→allow/transform/deny)(L373-375);质量信号进检索:filter/rerank/augment(L377-379)
  • L383-387:案例:连 AI 后想「反正内部数据」给宽权限→几周内日志 PII 进上下文→一个月内落 SBAC,每个 Copilot 功能一张 scenario card→下季度零隐私事故;「信任不是合规税,是功能」
  • L389-430:表 1-4 信任成熟度;L432-463:跨支柱自检;L465-473:结论+引出 ch2

Ch2 Data Foundations: A Semantic Backbone(text/05-…txt,574 段)​

  • L12-28:「聪明实习生」思想实验:会所有查询语言、懂所有库,但不懂你的业务词汇、不懂你的资产目录→成功率极低;资产重复蔓延、僵尸资产无人下线、低代码工件不受变更管理(L26-28)
  • L30-32:实习生类比=RAG:基础模型训练语料不代表企业平台;对业务行话和数据资产同样盲
  • L34:词汇挑战留给第 5 章(最终版);本章管资产可发现性——最终版有至少 6-7 章,Early Release 只给 3 章
  • L36:元数据缺口:超越 schema 和报表文档;在管道中捕获、可移植声明式定义受治理、每个源都有语义;=「semantic backbone」
  • L38-42:微软数百数据专业者/数千源;GenAI 前元数据靠人维护:每个洞察引到源、两报表不一致必须解释(L40);GenAI 后同样的元数据撑起数千用户的 RAG 应用(L42)
  • L46-84:模式一 实体内核:OLTP/OLAP 数据建模传统(L48); durable identifier(L54);决策者对话围绕关键实体(L56:Commercial Customers/Tenants/Commercial Users;Consumer Users);资产在数据湖、medallion silver 层(L60);必须 authoritative(L62);逻辑视图可跨多工件(L64);接口可扩展(L66);七类元数据:核心实体粒度工件/补充工件/维度表/每属性语义/质量监控+跨工件不变式/来源/可传递的隐私合规注记(L68-82)
  • L86-151:IDEAsTenantProfile 例子:core=TenantId GUID 不可变+DisplayName/CreatedDate/IsTest/两个 DIM key;扩展 1 AvailableUnits(SkuId/席位/AsOfDate);扩展 2 MonthlyActiveUsers(TeamsMAU 付费/免费拆分);扩展 3 EduTenantPooledStorage(配额/用量/利用率);扩展 4 RegulatoryClassification(IsGovernment/IsEducation);扩展 5 TopParentAccountDetails(TPID/战略客户标志)——主走查素材:一个 TenantId 串起五张扩展表
  • L152:元数据与数据同等重要;事后独立生成会过期失真;引出 ch3
  • L154-193:模式二 源头语义:源=变更流/外部提供商/遥测(L156);数据契约=服务契约的延伸,通常只有 SLA/schema/ready tracker(L160);管道代码的独特性:代码的意义取决于数据的意义(L164);schema vs semantics 之辨(L166);CreateCopilot_Intent 例子(L168-184):schema 7 个字段;语义=仅当登录用户显式发起(点击/快捷键)且 prompt 面加载时发;hover/tooltip 不发;实习生看不到隐藏语义假设(L185);只捕获「刚好够写业务逻辑」的语义(L187);遥测契约要跟 instrumentation owner 签(功能改动会无意改变事件结构和含义)(L189); discourage 契约里没写假设的管道代码(L191);指标变动要能向决策者解释(L193)
  • L195-243:ESA(Event Source Agreement)模板:Owner/版本 1.3.0/生效 2025-10-15/双周变更窗口+破坏性变更提前 2 周(L197-202);Purpose=只记用户主动发起并导向 LLM API 调用的动作(L204-205);Sink Geneva→Cosmos;新鲜度≤60 分钟;粒度=事件级不许预聚合(L207-210);三个 canonical events:Intent/PromptSubmitted/ResponseReceived 各带语义+必填字段(L213-230);版本管理 minor/major+ContractDoctor(L232-234);可测性:每天 200 条采样做一致性检查+CI 合成样例(L236-238);所有权 DRI(L240-243)
  • L244-267:事件 JSON schema($schema/enum/required)
  • L269-337:模式三 安全治理地扩展:没有硬执法的原则迟早被绕过(L271);文档「有」易查、「好」难查(L273);治理天然拖慢执行,要平衡,治理火力集中在实体视图与数据契约两层(L275);实体工件变更治理清单 8 组:资格与意图/命名与版本/键与可连接性/演进与退役/性能与规模/隐私安全合规/数据质量与运营就绪/元数据完整性(L279-335)
  • L339-397:模式四 分层保单一事实来源:快跑导致同一指标不同管道近乎相同逻辑→同指标不同值(L341);无界分层→循环依赖,连解释怎么算的都难(L343);七层:Semantic Core(实体粒度,L347-353)/Dimensions(静态枚举,集中化避免昂贵的 restatement,L355-363)/Metric Bases(严格从 Core+Dims 派生,业务逻辑只编码一次,L365-367)/Metrics(报表上的度量,不许依赖其他 Metrics,L369-373)/Segments(实体 ID 清单,L375-379)/Event Sinks(契约底座,L381-389)/References(预测/LTV/目标这类孤儿表纳入轻治理,L391-395);依赖规则:Core 内互依,Metrics 只准依赖 Metric Bases(L397)
  • L399-478:模式五 可移植声明式定义:用例=对比两指标差异/拆解复用(L401);读代码费时,人还得核 AI 的解释(L403);声明式(SQL/JSON)语义明确,优于过程式 Java/C#(L405);可移植=跨工具不语义漂移(L407);UDM JSON 例子(L411-455):udmEnvelope(assetType MetricBase/entity Tenant/inputs core+extensions+dims/constraints/metadata citations pharos://)+plan(read TenantUsageExt.v4→join CountryDim→join SegmentDim→filter→aggregate dau=count_distinct userId)(L456-474);provenance 挂上(L476)
  • L480-575:模式六 元数据 API:/taxonomy(assetTypes+dependencyMatrix)/semanticEntity/{id}(user.core,SCD Type 2)/dimensions/{id}(geo.country 2025.10)/metric-bases/{id}(sources+columnarProvenance)/metric-bases/{id}/definition/assets/{id}/governance(approved/Confidential/EUDB)/assets/{id}/lineage——支撑发现、定义查询、治理合规、影响分析

Ch3 Metadata-First Pipeline Engineering(text/06-…txt,880 段)​

  • L12-16:上章建了语义模型;本章管执法:地图不保证旅人不偏路(L14);路线:执法缺口→心态→管道契约→管道即代码→活元数据(L16)
  • L20-32:语义定义不够:一个月一个月买来的共识,一条不合规管道就悄悄漂移(L20);目录是事后扫描,查不出 partner_segment 列的推导逻辑对不对(L28);执法缺口(Enforcement Gap)定义(L30):组织以为标准化了的语义 vs 平台实际日复一地产出的东西之间的距离;RAG 在缺口里自信地输出「措辞漂亮但完全失准」的答案
  • L34-54:当数据说谎:未经验证的接地数据(L36):句法有效+语义不可靠;LLM 能把劣化输入变成流畅权威的回答;LLM 是语言引擎不是事实引擎,RAG 的前提=检索到的数据为真,模型完全信任(L38);UAU 走查(L40-48):定义=登录+有意义动作;两个团队,第二个只数登录;BI 时代:报表评审发现、提 bug、影响可控(L44);RAG 时代:PM 问 AI 助手→检索层取回虚高指标→模型合成连贯叙事「采用在加速,建议追加投资」→进战略 deck→错误成了组织内的新现实(L46-48);「AI 没有幻觉,它基于坏事实完美推理」(L50);必须在写入前保证(L52-54)
  • L56-76:元数据优先心态:metadata-last 传统流程(L60);代码与元数据脱钩→漂移=执法缺口根因(L62);翻转:元数据是规格不是文档(L66);软件工程左移类比:安全扫描→预防不安全代码被写出来(L68-70);目标从「描述希望正确的数据」变成「证明数据在写入前符合定义」(L72)
  • L78-178:管道契约:机器可读规格,生产者与平台之间的约束协议(L80);schema 描述形状,契约描述身份(L82);四组件:
    • 组件一 Schema+语义定义(L86-96):湖仓 schema 即约束,违反类型/约束/必填→写入当场拒绝(L88-90);Example 3-1(L96-158):usage_metrics.yml:date+active_users 两列,active_users 挂 semantic_definition: Metrics.UniqueActiveUsers;SQL:user_logins CTE→user_actions CTE→qualified_logins join 条件 action_time>login_time 且 ≤login_time+INTERVAL '30 minutes'→count(distinct user_id) group by date;主走查素材
    • semantic_definition 不是注释是机器可解释引用(L160);三重执法:治理路由到 definition steward/lineage 校验上游/强制单测证明「有意义动作」逻辑正确(L162-172);「有人想只数登录的捷径,执法拦在第一行写入之前」(L174)
    • 组件二 运营保证(L180-229):Example 3-2(L186-215):schedule daily 08:00 UTC;sla.freshness=4 小时;accountability owner+alert_severity 3;quality_monitors:active_users IS NOT NULL、day_over_day_change<0.20;retention 180 天;平台发布实时健康指标,RAG 运行时可评估:迟到/挂了就换源或拒答(L227)
    • 组件三 治理(L231-275):Example 3-3(L237-265):加 user_id 列 privacy_tag PII;classification Confidential;scenarios 两个 UUID;列级 tag→字段级遮蔽/删改(L269);资产级分类→防止 Confidential 进群聊(L271);场景=按意图而非身份授权,第 6 章展开(L273)
    • 组件四 lineage(L277-346):四个问题:退役会断什么/指标错了查哪里/敏感数据怎么流的/修复后要重算什么(L283-289);Example 3-4(L293-316):inputs app_events v2,rolling 1 day,三列;执法不是记录:平台据 lineage 块自动生成连接代码,工程师写不了契约外的查询(L318-322);五能力:可解释检索/自动 restatement/安全部署/分钟级根因/影响感知的告警抑制(L324-344);契约=完整身份:结构/意义/行为/安全/来源(L346)
  • L348-494:管道即代码:静态 YAML 的四缺点:变大难维护/复制即漂移/类型安全测试复用弱/DX 差(L356-364);契约=TS/Python 类(L366-370);表 3-1 对照(L372-408);Why Code Wins:①类型安全:import { UniqueActiveUsers } from "@semantics/Metrics",同事改名→编译失败→设计时关闭缺口(L416-421);②复用:dayOverDayChange("active_users",0.20)/("revenue_total",0.05) 导入即用,改一处全更新(L423-429);③可测试:Example 3-5(L437-458):mock 4 条事件(u1 login 10:00/action 10:05;u2 login 10:00/action 10:06),run pipeline,expect.semantic;只数登录→断言失败→永不部署(L460);DX:Example 3-6 拼错 UniqeActiveUsers→红波浪线 Property 'UniqeActiveUsers' does not exist on type 'Metrics',没保存没执行编译器就知道了(L472-488);AI 编码助手读 imports 和类型,建议完整合规结构(L490);合规成为阻力最小路径(L492)
  • L496-607:Example 3-7 完整 TS 工件:imports→UsageMetricsSchema 类→usageDataProduct StructuredStream(governance/operational)→UsageMetricsActivity(read app_events→filter→join→groupBy→agg→write)→ScheduledPipeline→workspace.add
  • L609-825:Managed Data Fabric:契约只是意图,fabric 负责验证/运行/监控/暴露健康(L611-617);四职责:验证(编译+语义存在+lineage 匹配)/部署(构建+回滚)/编排(按运营保证调度)/监控(每次运行评质量规则+路由告警)(L619-635);五步工作流:①Connector(AppEventsSchema:user_id privacy PII)(L655-683)②Activity(filter login/action→join where action_time>login_time→groupBy date→countDistinct→write usageMetrics)(L685-749)③View(UsageParams 窗口参数,export true)(L751-776)④内存单测(mock 2 条事件→输出 [{date:"2025-04-01",active_users:1}])(L778-800)⑤注册 ScheduledPipeline→workspace.add(L802-819);fabric 发布实时健康指标=RAG 的动力机制(L821-823)
  • L827-873:活元数据:fabric 每次运行产出 lineage/质量结果/SLA 状态/治理规则的实时可查询服务(L831);更聪明的检索(L835-857):多数组织的检索建立在「存在即正确」的危险假设上(L837);四问:可信(质量监控全绿?)/新鲜(SLA 满足?)/解释正确(语义定义防同名混淆)/安全(privacy tag+classification);检索从被动查询变成知情决策(L857);自愈上下文(L859-873):传统 restatement=工单+邮件+祈祷(L861-863);fabric 有保证的 lineage→标记受影响分区→不是盲目重跑数千管道:先算依赖图出 restatement plan(影响面/算力成本/业务影响)→关键修复走 HITL 审批(L869)→按序执行→更新向量索引(L871);知识库自动修复,平台外无人察觉(L873)
  • L875-880:下一章(最终版):质量检查变成实时信号、检索时解读信号

② 类锚候选(已核对)​

  • frontier/llamaindex#02-ingestion-chunking.md:切块优先在「人类自然边界」(段落>句子>从句>词)断开——对应书 L310「按语义边界切块」
  • frontier/graphrag#02-graph-extraction.md:实体抽取(entity_name/type/description+关系+强度)——对应实体内核/ontology-lite 的重型对照
  • frontier/ragas#01-metrics-engine.md:faithfulness=拆原子陈述→NLI 判定→聚合 0~1——对应信任层「evaluation loops」
  • protocol/mcp-spec#03-server-primitives.md:Resources=应用控制的上下文数据、Tools=模型控制的动作——对应「retrieval APIs that serve context in real time」/数据作为 AI 服务
  • frontier/phoenix、graphiti、haystack 亦可;essential-graphrag/rag-python-cookbook/rag-with-python-cookbook 未读,不能当锚

关键判断(写作用)​

  • 这本书是「数据平台侧的 RAG 前置工程」书,不讲 RAG 本身(检索/生成机制 0 涉及)——与书架里 RAG 书(讲检索/切块/评测)互补
  • 利益相关:作者全是微软 IDEAS 负责人,案例全部来自 IDEAS;模式以微软内部命名(IDEAS/UDM/Geneva/Cosmos/ContractDoctor/pharos)
  • Early Release:最终版至少 6 章(质量即检索信号、curated grounding+活术语表、SBAC、企业级 RAG 栈在 ch1 L98 被许诺;ch2 提到 ch5 词汇、ch3 提到 ch6 SBAC)——notCovered 的重要依据
  • 三个案例(三个用户/昨天的数/PII)是全书最生动的部分,都要进走查或案例段