数据不是软件

LLM 的生成能力是一把双刃剑：让模型能创造性解决复杂问题的机制，同样也会产生幻觉式的错误输出。要充分理解数据分析 Agent 面临的挑战，不妨将其与编程 Agent 做个对比。

编程是一个开放式的解空间，模型的创造力在此受到奖励，而文档和测试则提供了对抗幻觉的天然护栏。相比之下，对于分析场景，通常只有一个正确答案和一个正确数据源，且没有确定性的方式来证明结果的正确性。

对于自助式 Agent 商业分析，复杂性主要来自数据的歧义性。核心问题归结为：我们能否将用户的问题映射到数据模型中特定的、最新的实体，并知道正确的处理方式。如果能做到，后续的执行和 SQL 就变得轻而易举。

我们识别出了导致错误回答的三个主要属性：

  1. 概念-实体歧义：数据模型中有数百个可选字段（总计可能数百万个），Agent 无法选出最匹配用户问题的正确字段。例如在衡量"活跃用户数"时——什么行为算"活跃"？是否包含欺诈用户？用什么回看窗口？
  2. 数据陈旧：数据源、业务定义和 Schema 在不断变化；资产和 Agent 知识会变得过时，开始返回微妙错误的答案。
  3. 检索失败：正确信息可能确实存在于数据模型中且标注完善，但鉴于搜索空间巨大，Agent 就是找不到它。

Agent 分析技术栈

在 Anthropic，我们主要通过 Agent 数据技术栈来最小化这三种错误。每一层主要针对其中一个或多个问题：

  1. 实体歧义：数据基础和事实来源缩小了可能的实体空间，直到只剩一个受治理的答案。
  2. 陈旧性：维护和验证流程确保一切不会随着业务变化而腐化。
  3. 检索失败：Skill 确保 Agent 可靠地找到并正确使用那个答案。

数据基础

确保分析 Agent 准确的最重要方面是强大的数据基础，包括数据仓库中的数据模型、转换、测试和表，以及描述它们的元数据。标准的数据工程和数据质量实践——维度建模、左移测试、关键管道的新鲜度和完整性检查——仍然适用（我们不再赘述）。

真正改变的是，你的数据模型的终端用户不再是数据专家（如数据科学家），而是代表不同数据专业程度用户的 Agent。这种转变带来了一个挑战：结果不能要求用户验证底层的正确性，因为终端用户并不知道如何验证。

数据基础层主要针对歧义性：例如，如果"收入"解析到一个受治理的数据集而非四十个可能的候选者，这个问题在 Agent 搜索之前就基本消失了。它也是第一道陈旧防线的所在，因为定义规范模型的同一个仓库，正是强制保持它们更新的天然场所。

我们发现几个实践特别有效：

  • 创建规范数据集：最常见的失败是 Agent 无法将概念（"产品 X 的收入"）映射到正确的表、列和指标定义，通常是因为有多个看似合理的候选者且实现方式微妙不同。解决方案是更少、更重度治理的逻辑模型：策划一小组规范的、单一事实来源的数据集，明确归属、可直接使用、易于发现，然后积极淘汰近重复项。物理汇总和缓存对成本和性能仍然重要，但它们应该从规范模型机械派生，而不是作为替代品并列存在。目标是当 Agent 搜索一个概念时，它找到一个受治理的答案。
  • 强制执行标准：我们发现，只有当规范模型和指标定义通过工具（Agent 在结构上被优先路由到它们）、CI（绕过它们的变更在评审中失败）和制度（下游团队在治理层上构建或解释原因）来强制执行时，这些基础才能保持。没有强制执行的治理会迅速退化回多候选问题。
  • 共置产物：我们对抗不断变化的数据模型和业务逻辑的主要防御是共置。几乎所有数据代码（即建模、语义层、参考文档、规范仪表板定义）都在一个仓库中，CI 检查保护跨层完整性。如果一个建模变更会破坏下游仪表板或使文档化的指标失效，CI 会标记它，修复随同一个 PR 发布。
  • 将元数据视为一等产品：编程 Agent 表现良好的部分原因是代码库是可读的：README、类型签名、文档字符串等。你的仓库也可以同样可读，但前提是列和表描述、规范指标定义、粒度文档、有效值范围、血缘、归属和模型分级要与转换本身保持同等的维护力度。

事实来源

如果数据基础是数据仓库本身，那事实来源就是 Agent 用来导航它的参考界面。这一层减少了概念-实体歧义，将利益相关者问题中的"周活跃用户"转化为数据模型中一个特定的、受治理的实体。按信任度从高到低排列：

  • 语义层：编译后的指标和维度定义。如果一个问题能干净地映射到一个已定义的指标，Agent 调用一个函数就得到一个数字——与公司所有其他界面产生的数字相同。我们的 Agent 在结构上被要求（通过 Skill 指令）优先使用语义层。我们尝试过但失败的一个方案：用 LLM 从原始表和查询日志自动生成指标定义来引导语义层。它产生了看似合理的定义，却编码了我们正试图消除的歧义，对我们的评估净负面影响。因此我们推荐用 Claude 生成文档，但由人类拥有定义。
  • 血缘和转换图：当语义层不能覆盖一个问题时，血缘和表排名（基于引用数量）让 Agent 能推理哪些上游模型喂给了一个概念，哪些已废弃，哪些共享粒度。这将"我不知道这个指标"转化为"我知道该从哪个受治理模型聚合"。
  • 查询语料库：来自仪表板、笔记本和先前分析的历史 SQL。直觉上，这应该是高价值的——它记录了每个已经正确回答过的问题。但在实践中，我们发现给 Agent 对数千个先前查询的原始检索访问权限，准确率提升不到一个百分点。非结构化检索无法将新问题映射到正确的先例。真正有效的是将语料库蒸馏为按领域组织的结构化参考文档和可复用的分析模式。把查询历史当作策划的原料，而不是 Agent 直接读取的事实来源。
  • 业务上下文：大多数团队跳过的层，也是我们低估最久的。不了解你业务的 Agent 会回答用户问的问题，而不是用户想问的问题。它不会知道"Q2 发布"指的是一个具体产品，两个团队对同一个术语有不同的定义，或者一个问题被提出是因为周四有董事会。我们引入了公司知识图谱，由索引文档、路线图、决策日志和组织结构组成，让 Agent 能解析上下文引用并提出更好的澄清问题。

所有四层的共同失败模式与数据基础层相同：糟糕或过时的文档。Claude 在弥合差距方面非常有用（起草列描述、从查询模式提议指标文档、在 CI 中标记未文档化的模型），但策划和归属由人类管理。

Skill

如果事实来源是 Agent 的声明性知识（即指标意味着什么），那么 Skill 就是它的程序性知识：以什么顺序查阅哪些来源，如何导航模糊数据，以及完成的分析长什么样。

Skill 是 Agent 按需读取的一组 Markdown 文件。在 Anthropic，我们开发的 Skill 价值巨大。没有 Skill 时，Claude 准确回答分析问题的能力在我们的评估中没有超过 21%。加入 Skill 后，这些数字在总体上持续超过 95%，在某些领域经常达到 99%。

一些最佳实践：

  • 创建配对 Skill：一个知识 Skill 作为轻量级顶层路由器，允许按需加载额外的领域细节。它说"先试语义层，如果没有覆盖，这里有约 30 个该领域的参考文件，描述了相关的表、列、连接和陷阱。"这个路由器实际上就是我们应对检索失败的答案：不让 Agent 在百万字段的数据仓库中搜索，它在查询写入之前就将空间缩小到几十个策划的文件。分析 Skill 编码了高级分析师会遵循的流程：澄清问题、找到来源（通过知识 Skill）、运行查询，然后将结果通过对抗性审查子 Agent 循环。它还打包了一打可复用的分析模式（留存曲线、比率分解、漏斗分析），这样常见请求不用每次重新发明。
  • 创建适当的参考文档：为 LLM 检索而写。我们的参考文档描述表（粒度、范围和排除项）、陷阱的机制（如"排除已知免费邮箱域名，但保留像 anthropic.com 这样的自定义域名"）和显式路由触发器（如"如果问题关于实验提升……不要用于原始事件计数"），没有会过时的规定性配方。
  • 将 Skill 维护视为一等公民：Skill 文档描述着一个每天都在变化的数据模型，所以没有主动维护，它们几周内就会出错。我们眼睁睁看着离线准确率从发布时的约 95% 在一个月内漂移到约 65%，直到我们把这当作工程问题对待。这意味着将 Skill Markdown 文件与转换模型共置于同一仓库，这样改变模型的 PR 就是更新描述文档的 PR。代码评审钩子会标记任何不触及 Skill 文件的报告模型变更。我们大约 90% 的数据模型 PR 现在在同一 diff 中包含 Skill 变更。我们还随着模型改进定期修剪 Skill 脚手架。
  • 在所有界面创建一致且无缝的体验：同一个 Skill 必须在各种工具和独立 Agent 会话中为问题提供相同的答案。我们通过确保一个规范来源（数据仓库）和 Skill 变更自动同步来实现这一点。合并时，Skill 同步到插件市场、云存储 blob，并直接作为 MCP 资源提供。

验证

最后，验证是发现三种失败模式中哪个仍在泄漏的方式。

离线评估

我们经常看到的模式是，数据团队搭建了精心的分析环境，却没有任何流程来了解其分析 Agent 的准确率。

解决这个差距的一种方式是通过离线评估，即简单的问答对。你可以把离线评估类比为 ML 模型的离线测试——它们不告诉你在线 Agent 的性能，但确实让你对是否存在关键缺陷有个好判断。

我们在 Anthropic 部署两种离线评估。基于仪表板的评估由 Claude 自动生成（然后人工验证），覆盖最常见的利益相关者问题。长尾评估是我们将业务上下文（路线图、表文档）喂给 Claude，让它在该领域的其余部分生成合理问题。每当利益相关者在对话线程中纠正 Agent 时，我们也会持续收集——那次纠正就是一个候选评估。

其他最佳实践包括：

  • 锚定真值使其不会漂移：基于实时数据写的评估会随着底层数字变化而过时。将每个评估固定到一个快照日期，对一个稳定的事实表编写，或者让评分者评判 Agent 的查询而非数字。将评估套件接入 CI，这样触及依赖的 PR 会重新运行受影响的评估。
  • 像遥测一样存储结果，而非测试日志：每次运行的结果进入仓库表，包含 Skill 版本、git SHA、模型 ID、每断言通过/失败、token 计数和挂钟时间。"那个变更有帮助吗？"变成了一个查询，你可以得到时间序列来捕获单次 CI 运行无法发现的缓慢回归。
  • 按领域门控发布：领域负责人不能向利益相关者宣布 Agent，直到其领域的评估子集清除某个阈值（我们最初使用约 90%）。这迫使参考文档修复在用户看到失败之前发生。
  • 创建适当数量的评估：你应该拥有的评估数量取决于业务领域的复杂性和底层数据模型的复杂性。通过跟踪离线准确率预测在线准确率的效果来校准：我们发现每个话题（如"增长"）超过几十个后收益递减，且这个上限随着每个新一代模型而下降。
  • 离线评估准确率应约为 100%；每个正确答案也应该命中你的语义层（如果有的话）。这种准确率水平不告诉你系统不会产生错误答案，只是没有明显的缺陷——前提是评估覆盖得当。

消融技术

关于 Skill 的每个结构决策（如暴露哪些来源、子 Agent 是否值得其延迟开销、是否将两个 Skill 合并为一个）都是通过固定离线评估集来做的。

我们恰好变化一个组件并比较通过率。每次运行只需要一个小时，但取代了大量争论。方法论比任何单一结果都重要：

  • 为空结果而设计。 我们最有用的消融是一个阴性结果。我们给了 Agent 对整个仪表板、转换和分析师笔记本 SQL（数千个文件）的直接 grep 访问权限。然后我们在转录中验证它确实在每次回答前都读取了它们。准确率在两个方向上移动不到一个百分点。我们接着检查了明显的混淆因素：那些答错的问题，答案真的在语料库中吗？大约 80% 的时间，是的。"答案存在"是否预测"现在能答对"？不，翻转率是平的。信息就在那里，Agent 看到了，但它仍然没有使用它。那个单一实验告诉我们，瓶颈不是对先前工作的访问，而是结构（即将问题映射到正确实体）。那个洞察重新定向了数月的路线图。
  • 在 PR 粒度上消融。 每个有意义的 Skill 编辑都在相关评估切片上做前后运行，差异写在 PR 描述中。这让"我改进了文档"变得诚实，并捕获了出人意料常见的情况——善意的添加反而让事情变糟。
  • 保留一个失败清单。 我们的失败案例：超过某个点后叠加额外的文档精炼轮次（我们连续三次净负向迭代：文档变长了，而不是变好了），以及将对抗性审查器换成更便宜的模型以降低延迟（它失去了大部分准确率收益，没有真正的加速）。记录阴性结果成本低，能防止下一个人重跑同样的实验。

在线验证

最后一步是确保实际在线系统的性能尽可能准确。我们采取的一些步骤包括：

  • 对抗性审查：我们发现使用 Claude Skill 激进地挑战潜在最终答案的所有底层假设，在评估集中将准确率提高了 6%，但代价是多消耗 32% 的 token 和 72% 的延迟增加。
  • 溯源页脚：每个响应都带一个页脚，包含来源层级（语义层 > 策划参考 > 原始表）、底层数据的新鲜度，以及模型归属者。它不会让答案更正确，但帮助消费者判断对响应的信任程度。"原始表，新鲜度未知"的页脚是在向上游转发之前需要验证的信号，也是我们对静默失败为数不多的缓解措施之一。
  • 数据质量检查：Agent 可能在以正确方式使用正确字段，但数据本身是错误的。添加基本的数据质量检查以确保引用的字段是最新的、完整的、没有异常。
  • 被动监控：我们持续跟踪的两个生产信号是 Agent 查询通过语义层解析的比例，以及使用纠正语言（"那是错误的表"、"你漏了欺诈过滤器"）的响应比例。两者都汇入一个与离线通过率一起每周评审的仪表板。
  • 主动纠正收集：闭环的部分。一个定时 Agent 每隔几小时扫描利益相关者频道寻找类似的纠正语言，起草对相关参考文档的一行修复，并打开一个标记领域负责人的 PR。修复路径故意很无聊——编辑 Markdown 文件、合并、到处自动同步——这样领域负责人不会在这项任务上花太多时间。同样的纠正会回馈到离线评估集。

所有这些都无法完全捕获的失败模式是静默错误。答案是错的，但看起来合理，且在无异议的情况下被使用。我们的缓解措施是溯源页脚、对任何面向领导层的内容要求明确人工签字，以及每个领域 Top KPI 的常设评估每天对官方仪表板进行健全性检查，尽管我们还没有稳健的解决方案。

如何开始

如果你从零开始，少数几个规范数据集、几十个离线评估和一个轻量级知识 Skill 就能捕获大部分价值；本文中的其他内容都是在这些建好之后添加的。

我们也分享了很多最佳实践，并非所有都适合每个数据团队。与你的组织对齐几个会影响你方法的原则：

  • 今天正确 vs 未来正确有多重要？ AI 模型正在快速进步。我们经常看到公司为当前模型的不足构建大量基础设施，而当模型改进后这些就变得多余了。知道模型的短板在哪里，等待模型改进来填补差距，开销显著更低，但可能不适合你公司的风险承受能力。
  • 你预期业务复杂性如何随时间变化？ 如果你产出不多数据、只有少数消费者、数据模型可能保持简单，我们讨论的一些流程可能就过了。
  • 输出的目标受众技术程度如何？ 换个说法，如果你是为能识别错误答案的数据科学家构建分析系统，你可能比面向不熟悉底层数据模型的受众更能容忍错误。
  • 你愿意为提高准确率花多少钱？ 我们发现对抗性验证等某些流程可以显著提高准确率，但通常成本和延迟更高。
  • 你对访问控制和内部数据隐私的舒适度如何？ Agent 通常在拥有更多上下文时显著表现更好；然而，广泛的数据访问与大多数公司的治理立场相悖。这决定了你是构建一个 Agent 还是多个范围受限的 Agent。

无论你走哪条路，我们最大的收益来自于解决三种失败模式的每一种：将歧义折叠为单一受治理答案、使答案易于发现、并在任一出问题时发出标记。