把大模型接进数仓、让它自己查，听起来顺理成章。但在几千名员工、几百 PB、几万张表的规模下，真问题不是能不能查出个数，而是这个数能不能可信到直接支撑董事会、审计、KPI 这类高风险决策。Anthropic 的答案里，藏着一个反直觉的取舍。
自然语言问数被"解决"过很多轮。过去两年，内部数据分析一直是个老大难。
一种做法是把数据摊成又宽又大的表，方便不懂技术的同事取用，可业务一扩张，口径就开始打架，同一个指标冒出好几个版本。另一种做法是给每个团队圈一块独立环境，结果长尾问题覆盖不到，看板越堆越多。大模型出来后，很多人以为终于有了第三条路：不用学 SQL，直接用大白话问。
但真照这个思路搭，会掉进一个陷阱。Anthropic 在官方博客里说得很清楚：这套做法制造的是一种虚假的精确感。模型把使用者跟底层的基础设施、文档和专家经验隔开了，而正是这些东西，以前一直在替使用者把关，提醒他们"该用哪张治理好的表"。一开始从临时取数请求里解放出来的轻松感，很快被另一种不安取代：这个数到底对不对，没人能确认。
所以问题不在于能不能查出个数来。在 Anthropic 这种几千名员工、几百 PB 数据、几万张表的规模下，真正的问题是：一个 AI 算出来的数，能不能可信到直接支撑董事会、审计、KPI 这类高风险决策？这篇博客，就是它在自己的真实数仓上跑过一轮之后，给出的答案。它给的数字很硬：公司内部 95% 的业务分析查询已由 Claude 自动完成，整体准确率约 95%。
把大模型指向数仓、让它自己执行，制造的是一种虚假的精确感。它把使用者和底层的基础设施、文档、专家经验隔开了。— Anthropic 数据科学与数据工程团队 "
要理解分析 agent 难在哪，Anthropic 给了一个很好的参照系：跟写代码的 agent 比一比。
写代码是一个开放的解空间，有无数种正确写法，模型的创造力在这里是优势。更关键的是，代码天然带护栏：文档说明意图，测试验证结果，一段代码跑没跑对，运行一下就知道。模型就算"幻觉"出一个错误方案，测试会把它挡下来。
数据分析正好相反。对一个具体的业务问题，往往只有唯一正确的答案，而且要用唯一正确的那个数据源算出来。麻烦在于，没有一种确定的办法能证明这个答案是对的。SQL 跑通了不代表数对了，它可能用错了表、漏了个过滤条件，照样返回一个看起来很合理的数字。代码错了会报错，数据错了不会，它会安安静静给你一个错的数。
Anthropic 原文：一旦能把问题对到正确的实体上，"the resulting execution and SQL becomes trivial"。这把 text-to-SQL 直接判成了简单部分。
这也解释了一件很多团队没想明白的事：为什么换一个更强的模型解决不了。找对表、把指标算对，这两件难事都是结构问题，不是模型智商问题。模型再强，面对四十张口径微妙不同的"营收表"，它也没办法凭空知道哪一张是公司认账的那张。这个信息不在模型里，在组织的治理结构里。
Anthropic 把导致绝大多数错误答案的根源，归成三个具体的失败模式：
Anthropic 把它的"agentic 分析栈"分成四层。它特意说明，每一层主要是为了对付前面那三个失败模式里的某一个。
让分析 agent 准，最重要的还是地基扎实。Anthropic 特意强调，维度建模、把测试左移、对关键管道做新鲜度和完整性检查这些标准实践，在 agent 时代一点没过时，反而和以前一样重要。真正变了的是数据模型的终端用户：以前是能自己判断对错的数据科学家，现在是 agent，而 agent 背后那个人可能完全不懂底层数据。这就带来一个硬约束：结果不能要求用户自己去验证对错，因为他根本没这个能力。
这一层主要冲着"歧义"去。如果"营收"能干净地指向唯一一个治理过的数据集，而不是四十个看着都行的候选，那么这个问题在 agent 开始搜索之前就基本消失了。最管用的做法是建立规范数据集：精选一小批单一真相来源的数据集，产权清晰、开箱即用，然后狠心把近似的重复表废弃掉。
canonical/
fct_orders ← 唯一认账的订单事实表
grain: 一行 = 一个已支付订单
owner: growth-data
tier: gold（规范层，可直接消费）
口径: 已支付 / 排除内部测试账号 / 排除已退款
dim_customer ← 唯一认账的客户维表
--- 以下为已废弃，不应再被引用 ---
orders_v2_wide [DEPRECATED → 用 fct_orders]
orders_finance_copy [DEPRECATED → 用 fct_orders]
光建不够，还得靠工具、CI、制度三重强制：agent 在结构上被先路由到规范模型，绕开规范层的改动评审通不过，下游团队要么建在治理层之上、要么解释为什么不。没有强制的治理，很快会退化回"多个候选"的老问题。此外把所有数据代码（建模、语义层、参考文档、看板定义）放在同一个代码仓，用 CI 保护跨层一致性；改模型若会搞坏下游看板，修复就在同一个 PR 里发出去。最后，把元数据当成一等公民：列和表的描述、指标定义、粒度、血缘、产权，都要用跟写转换逻辑同等的严谨度去维护。
如果数据地基是数仓本身，那"真相来源"就是 agent 用来导航这个数仓的参考面。这一层把一个干系人嘴里的"周活跃用户"，变成数据模型里那个确切的、治理过的实体。Anthropic 按可信度从高到低排了四种。
语义层，可信度最高。这是编译好的指标和维度定义。如果一个问题能干净地对到一个已定义的指标，agent 就调一个函数，拿到一个数，而且是公司里其他所有界面都会算出来的同一个数。Anthropic 的 agent 在结构上被强制要求优先走语义层。
metric: gmv label: "成交总额 (GMV)" owner: finance sql: SUM(fct_orders.amount_paid) filters: [已支付, 排除退款, 排除内部账号] 维度: [date, country, product_category, channel] 口径声明: 含税 / 不含运费 # agent 问 "上季度美国 GMV" → 调用 gmv(country=US, date=last_quarter) # → 返回唯一一个数，和财务看板、董事会材料里的完全一致
这里 Anthropic 记了一个失败的尝试：它们曾想让 LLM 从原始表和查询日志里自动生成指标定义。结果生成出来的定义看着挺像样，却把它们正想消除的那些歧义又编码了进去，在评测上反而更差。结论是：用 Claude 生成文档，但定义要由人来拥有。
往下三层依次是：血缘和转换图（语义层没覆盖时，靠它推理哪些上游模型喂养了某个概念、哪些已废弃）；查询语料（历史 SQL，直觉上极有价值，但实践中给 agent 开放原始检索权限，准确率连一个百分点都没动，后面验证那节会讲为什么）；以及业务上下文，最被低估的一层。一个不懂业务的 agent 会回答用户字面上问的，但不是他真正想问的：它不知道"Q2 那次发布"指的是哪个产品，不知道某个问题被问出来是因为周四要开董事会。Anthropic 接入一张公司知识图谱（文档、路线图、决策记录、组织架构）来补这一层。
这四层有一个共同的失败模式：文档差或文档过期。Claude 在补这个缺口上极其有用（起草列描述、提议指标文档、在 CI 里标出没文档的模型），但策展和产权始终由人来管。
如果真相来源是 agent 的陈述性知识（一个指标是什么意思），那 skill 就是它的程序性知识：该按什么顺序查哪些来源、怎么在有歧义的数据里导航、一份完成的分析长什么样。在 Claude Code 里，一个 skill 就是一个文件夹的 markdown，agent 按需读取。
这一层的价值大到惊人。没有 skill 时，Claude 回答分析问题的准确率从没超过 21%；加上 skill 后，整体稳定在 95% 以上，某些领域经常做到 99% 左右。同一个模型，差距全在 skill。这正好印证了核心论点：卡点不在模型，在结构。
做成配对的 skill。一个"知识 skill"充当很薄的顶层路由器：先试语义层，没覆盖就指向这个领域的几十个参考文件。这个路由器就是对"检索失败"的答案：与其让 agent 在上百万字段里搜，不如先把空间收窄到几十个策展过的文件。另一个"执行 skill"把资深分析师的流程编码下来，还打包了留存曲线、比率拆解、漏斗分析等可复用模式。
knowledge-skill（薄路由器）
└─ "先走语义层；没覆盖再看下面的领域参考"
references/
orders.md ← 订单域：表、列、join、坑、路由触发器
users.md ← 用户域
marketing.md ← 营销域
… 几十个领域文件，每个问题只载入相关的几个 …
execution-skill（资深分析师流程）
1. 澄清问题 2. 找来源（走 knowledge-skill）
3. 跑查询 4. 丢给对抗性评审子 agent
+ 打包：留存曲线 / 比率拆解 / 漏斗 等可复用分析模式
---
name: [warehouse-skill]
description: "IF 用户要查[公司]数仓的任何[业务域]问题 → THEN 调用本 skill；
DO NOT 用于相邻工程任务、或与数仓无关的问题。"
---
# 语义层（REQUIRED · 必走第一步）
治理过的语义层是每个数据问题的强制默认路径；原始 SQL 仅兜底，
只有在确认语义层覆盖不了之后才用。
## 必走流程：Load → Discover（务必查 segments）→ Compile+run → Fallback
> 别提前放弃。不要拿这些理由退回原始 SQL：
> "要自定义日期 / cohort" → 时间维度 spec 已覆盖
> "需要 join" → 指标层已封装好 join
> [再 3-4 条 agent 常用来跳过语义层的借口，逐条预先驳掉]
# PART 1 必知：红旗检查 / 越界升级 / 澄清业务决策 / 实体消歧 / 数据完整性铁律
# PART 2 怎么做：技术执行 / 分析规范 / 强制对抗性 SQL 评审 / 带出处页脚汇报
# PART 3 数据参考（多级索引，逐层下钻，单次只载相关的几个）
references/_index.md ← L0 顶层域索引（先读这一个）
├─ 用户域 → user/_index.md 关键词：注册 / 画像 / DAU / MAU / 分群
│ └─ user/tables.md L2 表级：user / device / membership
├─ 交易域 → transaction/_index.md 关键词：订单 / 支付 / 退款 / GMV
│ └─ transaction/tables.md
└─ 营销域 → marketing/_index.md 关键词：活动 / 优惠券 / 推送 / 核销
metrics/_index.md ← 指标路由：DAU / 留存 → core；GMV / LTV / ROI → kpi
relationships.md ← 跨域 JOIN 关系（多表关联时再载）
原文附录的知识库导航是单层（每个业务域一个参考文件）；大库实践里常把它做成多级索引：顶层域索引 → 域内 _index → 表级文档，逐层把搜索空间收窄。上面的 frontmatter、语义层强制、PART 1-3 脊椎沿用原文骨架，多级索引那层是按大库实践的扩展。
写为 LLM 检索而生的参考文档。描述表的粒度、范围、排除项，坑的机制（"排除已知免费邮箱域名，但保留 anthropic.com 这样的自定义域名"），以及明确的路由触发器，而不写会过期的菜谱式步骤。Anthropic 在附录里给了一个骨架。
# [领域] 表 ## Quick Reference ### 业务上下文 — [这个领域用大白话讲是什么] ### 实体粒度 — [一行代表什么] ### 标准清洗过滤 — [这个领域每条查询都要套的过滤] ## 维度 · 关键表 · Gotchas（坑） - [一个资深分析师会提醒你的那些"出错模式"] ## 最佳实践 / 常见查询模式 · Cross-References - [默认选择、标准切法；相邻领域文档谁负责哪些相邻问题]
把 skill 维护当成一等公民。Skill 文档描述的是一个每天都在变的数据模型，不主动维护几周内就会过时。Anthropic 亲眼看着离线准确率从上线时的约 95% 一路漂到一个月后的约 65%，直到把它当成工程问题来治：skill 文件和转换模型放进同一个仓，改模型的 PR 就是更新文档的 PR，一个 code-review hook 标出任何"改了报表模型却没碰 skill"的改动。现在大约 90% 的数据模型 PR，在同一个 diff 里就带着一个 skill 改动。此外保证所有界面体验一致：同一个 skill 在 Slack、IDE、看板工具、独立会话里对同一个问题给同一个答案，靠唯一规范源 + 合并时自动同步（插件市场、云存储 blob、MCP 资源）。
验证是用来搞清楚那三个失败模式里，到底还有哪一个在漏。分三块。
离线评测。简单的问答配对，类似给 ML 模型做离线测试。Anthropic 部署两种：看板类（Claude 自动生成、人验证）和长尾类（喂业务上下文让 Claude 生成问题），每次干系人纠正 agent 也被收集成候选评测。几条关键做法：把基准答案锚死在快照日期防漂移；结果像遥测一样存进数仓表（带 skill 版本、git SHA、模型 ID、通过率、token、耗时），让"那个改动有没有用"变成一条查询；按领域设发布门槛（初始约 90%）；离线准确率应做到约 100%，且每个正确答案都应命中语义层。
消融实验。关于 skill 的每个结构性决定，都在固定评测集下只改一个组件、比较通过率。Anthropic 最有用的一次消融是个否定结果：它给 agent 开放了对几千个 SQL 文件的直接 grep 权限，还核实了 agent 确实每次都读了它们，准确率却没动过一个百分点。对答错的问题，正确答案约 80% 的时候就在语料里，但"答案在不在"预测不了"答对没"。信息就在那儿，agent 也看到了，它就是没用。这告诉它们：瓶颈不是拿不到过往成果，而是结构，把问题对到正确实体的能力。这个洞见改变了之后好几个月的路线。
在线验证。用对抗性评审激进挑战候选答案的所有假设（准确率 +6%，代价是 +32% token、+72% 延迟，第四节细说）；每个回答带一个出处页脚，说明来源层级、新鲜度、负责人；持续监控"经语义层解析的查询占比"和"出现纠正语言的回答占比"；一个定时 agent 每隔几小时扫频道找纠正语言、起草一行文档修复、开 PR 给领域负责人，修复路径刻意做得很无聊（改 markdown、合并、自动同步）。
> Source: 语义层 | 治理表 | 原始探索 > Confidence: [层级] Reviewed: [评审者 ✓, 第 N 轮] > Freshness: [数据里的最大日期] Owner: [负责团队]
这套组合拳唯一没法完全兜住的，是那个静默失败：答案是错的，但看着合理，没人提异议就被用掉了。Anthropic 的缓解手段是出处页脚、对任何要交给领导层的东西强制人工签字、给每个领域的头部 KPI 立常驻评测每天对账。它坦承这块还没有稳健解法。
四层架构里，最值得单拎出来讲的是一个反直觉的取舍。它藏在语义层那句"被强制要求优先走"里，分量却撑得起整篇文章。
通常的 text-to-SQL 思路是：给模型足够的上下文，然后让它自己写出最终那条 SQL，模型越强写得越准。Anthropic 没走这条路。它的 agent 在结构上被 skill 指令强制：只要一个问题能对到语义层里一个已定义的指标，就必须调那个指标函数，而不是自己拼 SQL。模型不被允许在最后算数这一步自由发挥，原始 SQL 只是兜底。
为什么要这么自缚手脚？因为它要的不是"大概率算对"，是"错了能被发现"。同一个问题"上季度美国 GMV"，两条路的结局完全不同：
这就是这个决策的核心。一个会报错的系统，错误是显性的，你当场就知道它答不了，可以转人工、可以澄清。一个总能给你一个数的系统，错误是隐性的，它把"我不知道"伪装成"这是答案"，而这恰恰是高风险决策里最危险的东西。当一个数要拿去支撑董事会、审计、KPI 时，"看着对其实错"比"明确说我答不了"破坏力大得多。
所以这个载重决策可以一句话概括：用确定性的语义层，把错误从隐性逼成显性。模型的创造力在写代码时是资产，在最后算数这一步是负债，因为这一步只有唯一正确答案、且没有测试能当场证伪。Anthropic 的选择是，在这一步把创造力关掉。
用 text-to-SQL，失败长得像一个合理但错误的答案；用语义层，失败长得像一条错误信息。— dbt《Semantic Layer vs. Text-to-SQL》（竞品来源，见文末） "
Anthropic 是基于自己内部系统讲的，这些数字外人没法复核。但"结构性鸿沟真实存在、确定性语义层确实能补上它"这个方向，2026 年有一批行业证据可以印证。
需要先把话说在前面：这批 benchmark 大多来自语义层和治理层厂商（dbt、Looker、Atlan 这类），按本文的来源标准属于竞品博客，可信度最低，有让语义层"赢"的商业动机，具体百分比大概率挑选过。下面只用它们下"方向"判断，每个数字都标来源，不当定论。方向之所以可信，是因为三类来源指向一致：有动机的竞品、一个中立的学术基准（Spider 2.0）、加上 Anthropic 自己的内部数字。
把这三条合起来，有一个被反复提到的概括很贴切：准确率是个上下文问题，不是模型问题（"Accuracy is a context problem, not a model problem"，第三方）。这跟 Anthropic 的核心论点，是同一句话的两种说法。
Anthropic 给了一条务实的起步建议：如果从零开始，几个规范数据集、几十个离线评测、加一个薄薄的知识 skill，就能拿到大部分收益；这篇文章里其余的东西，都是在这三样建好之后才加上去的。
但要把这套东西跑得久，得认清它的代价。把全篇的硬数字摆在一起，代价就清楚了。
这几条凑在一起，指向同一个结论：这套架构的真正成本不在搭建，在维护。它不是一个搭好就能放着的系统，而是一个要持续喂养的活物。数据模型天天在变，文档会过期，评测会漂移，纠正要被不断收集回流。把这套维护机制建起来，比第一次把 agent 跑通，难得多，也值得多。
Anthropic 还提了几个原则性问题，建议每个团队先和自己的组织对齐，因为不是每条实践都适合所有人。
这套打法对其他团队的启示是清楚的：在 agent 时代搭自助分析，真正的工程量不在"接个模型让它查"，而在前面那三件事：治理出唯一答案、让它可被检索、给它建一套持续纠偏的免疫系统。换个更强的模型代替不了这些，因为它们解决的根本不是模型能力问题，而是组织的数据结构问题。
claude.com · 2026-06-03 · 数据科学与数据工程团队（Chen Chang、Clement Peng、Justin Leder、Johanne Jiao、Josh Cherry）。本文第一到第四节、第六节的全部论点、数字、架构、附录骨架均出自此文。所有内部准确率数字（95% 自动化 / ~95% 整体准确、无 skill <21%、加 skill >95% 及某些领域 ~99%、离线准确率一月内 95%→65%、对抗性评审 +6% / +32% token / +72% 延迟、~90% PR 带 skill、发布门槛初始 ~90%）均为 Anthropic 自报，外部无法独立复核。文中标"示意"的数据结构块是据原文描述用通用电商例子重建的演示，不涉及任何具体公司的内部表结构。
dbt（text-to-SQL 32.7%→64.5%；裸 schema ~40% vs 语义层 83%；"failure looks like an error message"）、Looker（NL→LookML 平均 97% vs NL→SQL 平均 80%）、Atlan（522 查询，治理上下文 +38%）的数字来源本身就是卖语义层或治理层的厂商，有商业动机，具体百分比大概率挑选过；本文只用它们支撑"方向"判断。Spider 2.0（GPT-4o 86%→6%，企业级峰值 38–59%）为中立学术基准，是上面自利来源的非自利交叉印证。Pinterest 检索命中率 40%→90%、"Accuracy is a context problem, not a model problem"为第三方中立向来源。方向之所以可信，在于竞品基准 + 中立学术 + Anthropic 内部数字三类指向一致；任何单个百分比都不应被当成定论。