Anthropic用Claude自动化95%数据分析查询

像刷新数据模型一样频繁地刷新技能

你可以使用技能来教Claude如何按照你的风格和要求完成一项任务，技能是一个带有自然语言指令和文件的markdown文件，Claude可以在需要时引用。

我们做出的最重要的架构决策是将技能文件视为服务内容，不断刷新，而不是一次性发布后就遗忘。

数据模型一天内可能多次变化。例如，列被重命名、指标定义被修正或表被弃用。这些变化中的每一个都需要在相对短的时间内落实到技能文件中。如果Claude读取的是上周二的技能副本，它会信心十足地给出上周二的错误答案。

这种倾向可能特别有害，因为数据消费者现在完全脱离了判断响应准确性所需的上下文。他们没有看到带有趋势线或相关指标的仪表板来指导他们的“直觉测试”。他们可能只在Slack中收到一两个数据点，如果这不是他们经常查看的数据，他们很可能会接受那个自信的错误答案。

为了控制这个不断变化的环境，Claude Tag的运行时挂载了我们数据仓库的skills/目录，并在每次对话时重新读取它。技能文件只是磁盘上的markdown；代理读取它们的方式与读取任何项目文件相同。

给代理超越查询知识的技能

我们最初部署使用Claude Tag的数据分析代理时，本能是创建一个“知识技能”，教Claude使用哪些表以及我们的语义层如何组织，然后就这样结束。我们很快确定这种方法会提供正确的 数字，但无法提供有用的 见解。

大多数数据消费者往往提出开放式、模糊的问题，如“是什么导致了这次下降？”或“你能预测月底会落在哪里吗？”或“把数据以漏斗形式展示给我。”回答这些问题需要代理不仅知道数据在哪里，还要知道分析师会如何处理它。

因此，除了这个知识技能之外，我们还为Claude Tag配备了额外的分析或运行手册技能，包括：

• 预测：何时以及如何拟合简单的趋势、季节性假设，以及何时因序列太短或太嘈杂而拒绝。
• 队列和留存分析：标准队列定义、报告给领导层的留存曲线模板，以及任何会让天真的实现陷入困境的注意事项（左截断、幸存者偏差）。
• 漏斗分析：关键产品漏斗的规范阶段定义，因此“用户在哪里流失于引导流程？”在回答中保持一致。
• 图表：可视化约定，如哪种图表类型用于哪种问题、调色板，以及何时表格比图形更清晰。
• 分析写作：如何构建发现（先写要点，数字，机制，注意事项），以及根据置信度适当的措辞程度。

每个数据团队很可能已经有这些约定；它们通常只存在于某人的头脑中，偶尔被记录下来。将它们写成技能确保Claude像你的数据科学家一样一致地应用它们。

连接业务上下文，而不仅仅是数据仓库

即使是知识技能和运行手册技能的组合也不总是足以回答一个问题。当有人问“为什么周二注册量下降？”，答案通常不在数据模型中，而是经常分布在Slack线程、事件跟踪器、发布说明和文档中。

为了弥补这些差距，我们将Claude Tag连接到我们的内部知识索引，该索引编目整个公司的文档、讨论和事件。当代理看到指标移动时，它可以搜索该索引以获取同期上下文：当天早上发生的事件、功能标志翻转、某人在频道中分享的竞争对手公告。

现在答案可能是“周二注册量下降了12%：当天上午9-11点有一个支付服务事件，下降集中在受影响的地区。”

如果你的组织有知识图谱、内部搜索，甚至只是组织良好的事件和变更日志提要，将Claude Tag连接到它们是在仓库本身之后可以添加的最高杠杆的信息。你还可以连接Claude Tag，以便它可以读取Slack中关键频道并获取上下文。

有意配置服务账户权限

Claude Tag以服务账户身份查询你的仓库，而不是以提问者的身份。虽然这是正确的设计（因为你不希望每个Slack用户都需要直接的仓库凭据），但所有能提及机器人的用户都具有机器人的数据访问权限。 没有按用户的行级安全性：服务账户能读取的任何数据，频道中的任何人都可以询问。

我们通过五种方式处理这个问题（我们建议认真对待，因为容易出错且难以撤销）：

1. 将服务账户限制为仅访问受治理的数据。 在Anthropic，Claude Tag的服务账户可以读取语义层的输出表和为其提供支持的整理数据集市。它无法读取原始事件流、暂存模式或个人沙箱中的任何内容。如果问题需要该边界之外的数据，代理会说明而不是猜测。这也是正确的用户体验，因为治理层之外的数据尚未经过验证。

2. 在列级别对PII进行分类，并拒绝服务账户的访问权限。 受治理的数据并不自动就是 PII 安全的数据（例如，一个精选表仍可能包含电子邮件地址）。我们维护了一个带有列级血缘的数据目录，因此每一列的来源和下游流向都是已知的。当新列出现时，Claude 会扫描它们并标记可能的 PII 候选供人工审查。然后，人工在列的元数据中应用分类，血缘将该标签传播到派生表。鉴于 Claude Tag 的服务账户没有 PII 权限，数据仓库的列级访问控制使代理无法看到任何 PII 列。它可以查询表，但敏感列根本不可读。

3. 在技能本身中记录连接路径。 我们的仓库技能有一个专门的部分，介绍如何代理连接（无论是通过 CLI、直接 API 还是 MCP 服务器），以及每种路径的确切认证方式。这个不起眼的功能使我们能够区分代理是干净地失败（“我无法从这个界面访问仓库；原因如下”）还是令人困惑地失败（对错误项目静默运行的查询，或中继到不应去之处的认证提示）。当连接机制在技能中时，代理可以解释自身的限制。

4. 将 Claude 的频道成员资格视为访问授权。 将 Claude Tag 添加到 Slack 频道，实际上就是授予该频道成员对代理可查询内容的读取权限。我们明确说明了这一点：Claude 由数据团队成员添加到频道，数据团队拥有频道列表。

5. 标记每个查询。 对于每个仓库查询，Claude Tag 都会携带标签，标识界面、对话和请求用户（在 Slack 提供的情况下）。这不会在查询时强制执行任何内容，但提供成本归属和审计跟踪（你可以事后确定是谁提出了扫描 4 TB 的问题）。

我们的总体立场是，Slack 中的数据分析代理是受治理仓库的共享只读副本，我们努力将其范围界定为如此。

为每个答案添加仪器

确定代理是否给出了足够的答案，你不能仅凭肉眼判断。

我们为 Claude Tag 处理的每个问题记录一个结构化事件。这包括：

• 加载了哪些技能文件及其版本；
• 用户是否通过 👍/👎 反应或回复更正；以及
• 它触及的表上的任何未决数据质量警告。我们还会在答案的页脚中显示任何数据质量警告，以便过时数据警报出现在数字旁边，而不是不可见。

这些遥测数据支持两个视图。一个跟踪采用率或代理查询通过治理层而非临时 SQL 的比例，按界面和领域分类。另一个跟踪正确性通过 👎 反应和更正的按领域比率来衡量。这是在评估运行之间准确性的在线代理。

采用率指标结果是我们跟踪的最可操作的数字。当某个领域的采用率下降时，几乎总是意味着技能文件已漂移，或者出现了语义层未覆盖的新类型问题。

这如何加速自助分析采用

Claude Tag 线程成为新的会议

我们最喜欢的、最有效的 Claude Tag 线程通常有多人参与。在这些情况下，我们看到人们贡献想法和背景，而 Claude 处理具体工作。

例如，数据团队成员问 Claude 为什么收入仪表板加载时间比平时长几分钟。Claude 发现查询结果未缓存，并且一个 bug 减慢了结果到达页面的速度。

Claude 通知了仪表板所有者，他决定立即修复缓存，同时单独处理 bug。

然后所有者问哪些其他仪表板变慢了，结果发现数十个仪表板受到相同的缓存错误影响。Claude 编写了缓存修复，数据团队成员审查了它，所有受影响的仪表板在不到一小时内恢复了全部功能。

这些线程是开放的，这出于多种原因是有帮助的。阅读的人能获得背景（发生了什么、为什么、如何修复），而无需有人为他们写总结。更重要的是，他们不必保持被动读者。任何知道有用信息的人都可以加入并贡献，就像上面的例子中团队成员所做的那样。

因此，将代理保留在共享频道中，并将工作保留在线程中，而不是私信中，因为线程可以作为可审查的历史记录。

Claude Tag 处理重复性任务

很多数据工作是重复的：管道健康检查、KPI 监控等。你可以让Claude 创建循环，按计划或响应异常变化处理周期性任务。我们已实现的一些数据特定示例包括：

• 主动读数: Claude 在每周站会前提供总结：上周发生了什么变化，与前一周相比如何，以及值得注意的内容。
• 测试监控: 当我们监控发布或实验时，Claude 每天提供多次读数。在最近一次实验中，它注意到设置中途发生了变化，并帮助我们及早发现和修复。
• 可观测性: 其他循环监控我们的管道和仪表板。如果管道失败，Claude 开始调查，起草修复，并通知当班人员。如果 KPI 意外变动，Claude 提供可能解释：假日效应？上游数据变化？并在任何人打开仪表板之前检查它们。
• 分流: 另一个循环跟踪我们的数据问题频道。对于每个新问题，它做出决定：直接回答，开始更深入的调查，或引入人工。到数据团队的人检查时，大部分工作已经完成。

Claude 还可以帮助设计循环。问 @Claude 它在你的频道中看到了哪些重复性工作，以及它如何帮助。

在需要时介入

你可以允许Claude在你选择的任何频道中更加主动，阅读并适时介入提供帮助。在过去一个月中，我们的一个数据频道里，Claude Tag回答了人们发布的超过75%的问题，通常在一两分钟内，即使没有被点名。

例如，一位Anthropic团队成员在一个公共频道询问一个仪表板是否包含一个新的使用类别。90秒内，Claude回答了数据如何定义，确认新段缺失，提出修复方案，并起草了一个PR。一位数据科学家审查并批准了。然后Claude合并了PR并刷新了仪表板。

入门

如果你已经完成了我们的第一篇文章中的工作，Slack部署主要是管道工作，尽管顺序很重要：

1. 先权限。 在编写任何代理代码之前，决定服务账户可以读取什么。以后扩大访问权限比收回容易得多。
2. 再分发。 选择挂载仓库或技能优先于MCP，并端到端验证新鲜度：更改一个技能文件，确认Claude Tag在SLA内获取它。
3. 从第一天起进行遥测。 你不会追溯性打点几个月前的对话。在第一个问题上就记录结构化事件。
4. 在可能时建立知识索引。 数据仓库回答是什么；你的内部文档和事件流回答为什么。一旦数据路径稳定，就接入它们。
5. 分析技能最后。 先创建数据访问技能，然后让真实问题告知你需要哪些分析师技能（预测、队列、漏斗）。

本文由Anthropic数据科学与数据工程团队的Clement Peng和Lily Zhao撰写，Josh Cherry和Michael Segner亦有贡献。

‍