Anthropic 如何用 Claude 做自助数据分析

很多团队第一次把大模型接到数据仓库时，都会有一种短暂的兴奋：业务方终于可以自己问问题，数据团队似乎也能从无穷无尽的 ad-hoc 需求里解放出来。

但 Anthropic 在这篇文章里泼了一盆很必要的冷水：让 Claude 会写 SQL 并不等于它会做分析。数据分析里的错误往往不是语法错误，而是「看起来很对，但其实用了错表、错口径、错时间窗口」。

这篇文章没有把自助数据分析讲成一个“接上数据源就能跑”的产品故事。Anthropic 把它拆成了一套工程系统：数据基础、可信来源、Skills、评估和线上校验。

Anthropic 给出的结果很亮眼：内部 95% 的业务分析查询已经由 Claude 自动化，汇总准确率约为 95%。原文把实践重点放在上下文和验证上，而不是把问题简化成模型能力本身。

数据分析不是写代码

Anthropic 先做了一个区分：代码生成和数据分析看起来都需要推理，但它们的正确性环境完全不同。

写代码通常有测试、类型、运行结果和用户反馈。即便模型给出一个创造性的解法，只要测试能覆盖关键路径，就有办法把幻觉压住。数据分析则不同。很多业务问题只有一个正确答案，而且往往依赖一个正确来源、一个正确口径和一个正确时间窗口。

比如“活跃用户数”这个问题本身就不完整。活跃是登录、发消息、下单，还是完成某个核心动作？要不要排除欺诈账号？时间窗口是过去 7 天、自然周，还是业务定义里的结算周期？如果这些问题没有被显式编码到系统里，模型越自信，风险越大。

原文把主要错误归为三类：

概念和实体的歧义：一个业务概念可能对应多个表、字段或指标定义。
数据和知识过期：数据源、业务定义、Schema 都会变化，文档和 Agent 知识很容易腐烂。
检索失败：正确答案也许存在，但模型没有在巨大的搜索空间里找到它。

这个判断把问题从“让模型写 SQL”拉回到数据系统本身：用户问题必须先映射到最新、可信、可验证的数据语义上。

Anthropic 的 Agentic Analytics Stack

Anthropic 用一个分层的数据栈处理这些问题：减少可选答案，让 Agent 按固定路径找答案，再用评估和线上反馈持续修正。

flowchart TD
    A["业务问题"] --> B["业务上下文"]
    B --> C["Sources of Truth"]
    C --> D["语义层 / 血缘 / 结构化参考文档"]
    D --> E["Claude Skills"]
    E --> F["查询与分析"]
    F --> G["离线评估"]
    F --> H["线上校验"]
    G --> I["文档与 Skill 维护"]
    H --> I
    I --> C

1. Data foundations：先把数据地基变窄

第一层是数据基础：数据模型、转换逻辑、测试、表结构，以及描述这些资产的元数据。

Anthropic 强调，传统数据工程实践并没有因为 Agent 出现而过时。维度建模、Shift-left testing、关键链路的新鲜度和完整性检查仍然重要。变化在于，数据模型的直接消费者不再只是数据科学家，而是代表不同用户行动的 Agent。

这会带来一个新的要求：系统不能默认最终用户有能力验证底层正确性。一个销售、运营或产品经理问出问题后，看到的是自然语言答案，而不是完整 SQL 审阅流程。因此，数据基础必须让 Agent 更容易走到唯一的、被治理过的答案。

原文给出的做法包括：

建立更少、更强治理的 canonical datasets，减少近似重复的数据集。
用工具、CI 和组织规则强制优先使用标准口径。
把建模代码、语义层、参考文档和看板定义放在同一个仓库里。
把表描述、列描述、指标定义、粒度、取值范围、血缘、Owner 都当成产品来维护。

这其实是在把“数据治理”从人类 analyst 的经验，前移成 Agent 可以读取和遵守的系统约束。

2. Sources of truth：让 Agent 先找可信来源

数据基础是仓库本身，Sources of truth 则是 Agent 用来导航仓库的参考表面。Anthropic 按信任程度列了几类来源。

语义层排在最前面。只要问题能映射到已定义的指标和维度，Agent 就应该调用语义层拿到统一数字，而不是手写一段看似合理的 SQL。Anthropic 还提到一个失败经验：他们尝试过让 LLM 基于原始表和历史查询自动生成指标定义，但生成物会把原有歧义重新编码进去，效果反而不如小而人工维护的语义层。

语义层覆盖不到问题时，血缘和转换图接手。Agent 可以通过表之间的依赖关系判断哪个上游模型更可信、哪个模型已经废弃、不同表的粒度是否匹配。

历史查询语料看起来很有价值，但 Anthropic 的实验结果比较克制：直接让 Agent 检索数千个历史 SQL，对准确率的提升不到 1 个百分点。更有效的方式是把历史查询提炼成结构化领域文档和可复用分析模式，让查询历史成为整理材料，而不是 Agent 直接消费的真相来源。

业务上下文也要进入系统。很多问题如果脱离组织语境就会答错，例如“Q2 launch”具体指哪个产品发布、两个团队是否对同一术语有不同定义、某个问题是不是为了周四的董事会准备。Anthropic 会接入由文档、路线图、决策记录和组织结构组成的公司知识图谱，帮助 Agent 解析这些隐含语境。

Skills 是过程知识，不只是提示词

原文里最有启发的一部分，是 Anthropic 对 Claude Code Skills 的使用。

在他们的定义里，如果 Sources of truth 是“某个指标是什么意思”的声明性知识，那么 Skill 就是“遇到这个问题该按什么顺序查、如何处理歧义、最终分析应该长什么样”的过程性知识。

效果差异很明显：没有 Skills 时，Claude 在他们评估集上的分析准确率不超过 21%；加入 Skills 后，汇总准确率稳定超过 95%，某些领域接近 99%。

Anthropic 的 Skill 设计有几个细节值得借鉴。

第一，使用成对 Skills。一个知识 Skill 作为顶层路由，告诉 Agent 优先使用语义层；如果语义层没有覆盖，再按领域加载几十个参考文件。这是在主动缩小搜索空间，而不是让 Agent 在百万字段级别的数据仓库里自由发挥。

第二，把 senior analyst 的流程写进 Skill。Anthropic 提到的 unbook skill 会要求 Agent 澄清问题、寻找来源、运行查询，并让结果经过对抗式 review sub-agents。它还包含留存曲线、漏斗分析、rate decomposition 等常用分析模式，避免每次都重新发明。

第三，参考文档要为 LLM 检索而写。好的文档不只是给人看的字段说明，还要明确表的粒度、适用范围、排除条件、常见陷阱和路由触发条件。比如某类问题应该用实验提升口径，另一类问题不能用这张表做原始事件计数，这类边界要直接写出来。

第四，Skill 需要和数据模型一起维护。Anthropic 观察到，如果不把 Skill 维护当成工程问题，离线准确率会从约 95% 在一个月内漂移到约 65%。后来他们把 Skill Markdown 和转换模型放在同一个仓库里，用 code-review hook 检查 reporting model 变更是否同步修改 Skill 文件。现在大约 90% 的数据模型 PR 都会包含 Skill 变更。

这点很现实：Agent 的知识一旦不跟着数据模型更新，就会变成另一种过期文档。

评估不是上线前动作，而是系统的一部分

Anthropic 把验证分成离线评估、消融实验和线上校验。

离线评估是最基础的一层。它们使用两类问题：一类来自看板，覆盖常见业务问题，由 Claude 生成后再由人验证；另一类覆盖长尾问题，由 Claude 基于业务上下文、路线图和表文档生成。每当业务方在线程里纠正 Agent，这个纠正也会成为候选 eval。

为了避免评估本身漂移，他们建议把 ground truth 固定住：要么锚定到某个快照日期，要么基于稳定事实表，要么让 grader 判断查询逻辑而不是动态数值。评估结果也应该像遥测数据一样入仓，记录 Skill 版本、Git SHA、模型 ID、断言通过情况、Token 数和耗时。这样“这次改动有没有帮助”就可以被查询，而不是靠感觉争论。

消融实验用于判断系统设计是否真的有效。原文里一个反直觉结果是：他们给 Agent 直接 grep 整个看板、转换和 notebook SQL 语料，准确率几乎没有变化；对错误题做检查时，约 80% 的情况下答案其实就在语料里。问题不是信息不存在，而是 Agent 没有把新问题映射到正确实体。

线上校验则更接近真实使用。Anthropic 提到，对抗式 review 在评估集中带来了 6% 的准确率提升，但代价是 32% 更多 Token 和 72% 更高延迟。这个数字提醒我们，准确率不是免费的，团队需要按场景决定哪些问题值得更贵的验证。

他们还会在回答里加入 provenance footer，说明答案来自语义层、结构化参考还是原始表，数据新鲜度如何，Owner 是谁。这不会让答案自动正确，但能让读者知道什么时候应该谨慎转发。

对数据团队的启发

如果从零开始，Anthropic 的建议并不复杂：先准备少量 canonical datasets、几十个离线 eval，以及一个轻量 knowledge skill。其他机制可以在系统跑起来后逐步增加。

这篇文章反对两种极端。

一种极端是把 LLM 当成万能 BI，让它直接连仓库、自由写 SQL、自由解释结果。这样容易制造“准确的幻觉”：语法没错、数字也像真的，但口径错了。

另一种极端是把所有问题都变成重型平台工程，先建完整语义层、完整评估平台、完整知识图谱，再允许业务方使用。Anthropic 的经验更像一条中间路线：先把最常见、最重要的业务域治理好，用评估证明它有效，再把纠错和文档维护接入日常工程流程。

普通团队可以先借鉴这几件事：

给每个核心业务概念明确一个首选数据来源。
把指标定义、表粒度、过滤条件和常见陷阱写成 Agent 可检索的参考文档。
为每个重点领域维护几十个高质量 eval，而不是只看 demo 效果。
把文档和 Skill 维护纳入 PR，而不是上线后靠人记。
在分析结果里暴露来源层级、新鲜度和 Owner。

自助数据分析不该让每个人都跳过数据团队。它更适合把数据团队的判断力沉淀成系统，让业务问题更快、更一致地得到回答。