夜雨聆风SELF-SERVICE ANALYTICS/DATA RELIABILITY
从权威指标、Skills 到持续评测，Anthropic 的自助式数据分析方法
从自然语言问题到可信答案，中间需要经过数据定义、来源路由与验证。
员工在 Slack 里问一句“上周有多少活跃用户”，模型很快就能生成 SQL。真正困难的是，它是否理解“活跃”的正式定义，是否使用了最新数据，是否遗漏欺诈过滤，以及答案能否被追溯。Anthropic 的实践说明，自助式数据分析的核心工程并不是查询生成，而是把业务问题稳定地连接到唯一、最新、可验证的数据口径。
约 95% 业务分析查询自动完成 | 约 95% 整体准确率 | 21% → 95%+ 加入 Skills 前后 |
01DATA PRACTICE
数据分析不是另一种代码生成
企业一直希望让不懂 SQL 的员工也能直接使用数据。传统做法通常是建设更宽、更扁平的数据表，或者为不同团队准备彼此隔离的分析环境。随着业务扩大，前一种做法容易制造定义重叠的视图，后一种做法又会带来指标、仪表盘和分析逻辑的重复增长。大语言模型提供了新的入口：员工可以在 Slack、IDE 或分析工具中直接提出业务问题，由智能体寻找数据并完成查询。
但把模型连接到数据仓库，并不等于获得了可靠的自助分析。代码生成允许多种正确实现，文档、编译器和测试也能暴露很多错误；业务分析往往只有一个符合公司口径的答案，却缺少能够自动证明答案正确的确定性测试。SQL 即使顺利执行，也可能选择了错误的表、口径、过滤条件或时间范围。
因此，分析智能体的主要难题不是生成查询语句，而是把一句自然语言问题准确映射到最新的数据实体，并知道应该怎样使用这些实体。只要这一步正确，SQL 通常并不复杂；一旦映射错误，结果越完整、表达越流畅，反而越容易制造一种危险的精确感。
自助式分析最难防范的，不是查询失败，而是一个看起来足够专业的错误答案。
02DATA PRACTICE
大多数错误来自三个地方
第一类错误是概念与实体之间的歧义。用户询问“活跃用户”时，模型需要判断什么行为算活跃、是否排除欺诈用户、观察窗口多长，以及应该使用哪张表中的哪个字段。大型数据模型可能包含数百万字段，多个候选项看起来都合理，只有少数真正符合业务定义。
第二类错误是陈旧。数据源、字段名称、业务定义和组织结构持续变化，几周前正确的说明可能已经失效。智能体不会因为文档过期而停止工作，它更可能基于旧信息生成一条能够运行、但口径已经偏移的查询。
第三类错误是检索失败。正确资料可能已经存在，也有清晰标注，但搜索空间太大，模型没有在需要时找到它。Anthropic 后来的消融实验进一步说明，仅仅让模型看到更多历史文件，并不能自动解决这一问题。瓶颈通常不是资料缺失，而是缺少把问题路由到正确资料的结构。
歧义决定模型选什么，陈旧决定资料是否还成立，检索决定正确答案能否被找到。
分析智能体的主要失真来源：概念歧义、数据陈旧和检索失败。
03DATA PRACTICE
先减少答案候选，再让模型搜索
Anthropic 的第一道防线仍然是传统数据工程：维度建模、转换逻辑、测试、数据新鲜度检查和完整性检查。变化在于，这些数据模型的直接使用者正在从数据专家变成代表普通员工工作的智能体。最终用户没有能力逐项验证底层查询，数据基础必须让错误选择更难发生。
具体做法是减少彼此近似的数据集，为收入、用户数、留存率等重要概念建立少量、强治理、明确归属的权威模型。物理汇总表和缓存仍然可以存在，但应该从权威模型机械派生，而不是与它们并列成为新的答案候选。理想状态是：智能体搜索某个业务概念时，只会找到一个受治理的定义。
治理还需要工具和流程执行。绕过权威模型的变更应在 CI 或评审阶段被发现；数据模型、语义层、参考文档和权威仪表盘定义尽量放在同一个代码库中。一项模型变更如果会破坏下游仪表盘，或者让指标说明失效，相关修复应在同一个 PR 中完成。
元数据也不再是附属说明。表与字段描述、数据粒度、有效值范围、血缘、负责人和模型等级，都是智能体理解仓库的接口。代码智能体依赖 README、类型和文档字符串理解代码库，分析智能体同样需要一个可读的数据仓库。
可靠分析的第一步不是让模型变得更会搜索，而是让它不必在四十个相似答案中猜一个。
数据基础、事实来源、Skills 与验证共同构成分析智能体的可靠性结构。
04DATA PRACTICE
事实来源有优先级，不能混在一个搜索框里
在坚实的数据基础之上，智能体还需要一套有优先级的事实来源。最高优先级是语义层：其中包含已经编译的指标和维度定义。只要问题能够映射到现有指标，智能体就调用统一接口，得到与其他分析工具一致的结果。Anthropic 要求智能体首先尝试语义层，确认没有覆盖后才能退回原始 SQL。
语义层不适合完全交给模型自动生成。Anthropic 曾尝试根据原始表和查询日志批量生成指标定义，结果只是把原有歧义包装成看似合理的新定义，在内部评测中反而不如规模更小、由人维护的语义层。模型可以协助起草说明，但业务定义仍需要明确的人类负责人。
如果语义层没有覆盖问题，下一层是数据血缘和转换图。它们帮助模型判断某个概念由哪些上游模型产生、哪些表已经废弃、哪些表拥有相同粒度。历史 SQL 则更适合作为整理参考文档的原材料，而不是直接作为真相来源。成千上万条旧查询包含过期假设，缺少结构时，模型很难把新问题映射到正确先例。
最后一层是业务背景。产品代号、路线图、决策记录、团队分工和即将发生的会议，都会改变用户一句话的实际含义。Anthropic 将内部文档、路线图、决策日志和组织结构编入公司知识图谱，使智能体能够理解环境中的指代，并在必要时提出澄清问题。
信息越多不一定越可靠；明确先查什么、何时回退，通常比扩大搜索范围更重要。
从语义层开始，沿数据血缘、参考文档和业务背景逐层补充信息。
05DATA PRACTICE
Skills 保存的不是答案，而是分析方法
事实来源提供陈述性知识，例如一个指标是什么意思；Skill 提供程序性知识，规定应该按什么顺序使用资料、怎样处理歧义，以及一份完成的分析应包含哪些内容。在 Claude Code 中，Skill 是模型按需读取的一组 Markdown 文件。Anthropic 把分析能力拆成相互配合的知识 Skill 与执行手册 Skill。
知识 Skill 是一个轻量路由器。它要求模型先尝试语义层；如果没有覆盖，再从大约几十份领域参考文件中选择需要加载的内容。搜索范围由数百万字段缩小到少量经过整理的文件。执行手册 Skill 则编码资深分析师的工作流程：澄清问题、确认来源、执行查询、检查结果，并将查询交给对抗性审查子智能体。留存曲线、漏斗分析和比率拆解等常见分析模式也可以在这里复用。
参考文档需要按照检索需求编写。它们应清楚说明一行数据代表什么、表的适用范围和排除条件、必须使用的过滤器、连接键、常见陷阱，以及什么情况下不要使用某张表。比起一段完整但容易过期的查询教程，明确的触发条件和边界更不容易随着数据模型变化而失效。
这套结构带来了明显差异。Anthropic 的内部评测显示，没有 Skills 时，Claude 回答分析问题的准确率不超过 21%；加入 Skills 后，整体稳定超过 95%，部分领域经常接近 99%。但这些数字依赖数据治理、文档和评测体系，不能理解为单个 Skill 文件本身带来的普遍能力提升。
Skills 的价值不是替模型背答案，而是把专家判断压缩成一条可重复执行的路径。
知识 Skill 缩小检索范围，执行手册 Skill 规定分析和复核流程。
这些数字应如何理解 • 自动化比例和准确率来自 Anthropic 的内部业务分析环境。 • 不同领域的数据质量、Skill 完整度和评测覆盖范围并不相同。 • 准确率提升来自整套数据治理和执行结构，不能归因于单一提示词。 |
06DATA PRACTICE
文档必须跟着数据一起发布
Skill 描述的数据模型每天都在变化。如果维护机制缺失，系统会在上线后迅速退化。Anthropic 曾观察到离线准确率在一个月内从约 95% 下降到约 65%。这并不是模型突然变差，而是数据模型和业务逻辑已经前进，Skill 文档仍停留在旧版本。
团队后来把 Skill 文件与转换模型放入同一个代码库，并用代码审查钩子检查文档是否随报表模型一起更新。如今大约 90% 的数据模型 PR 会在同一份差异中修改 Skill。某些旧的失败模式被模型或数据层解决后，相应说明也会被删减，避免文档不断堆积而降低检索质量。
同一份 Skill 还需要跨入口保持一致。代码合并后，它会同步到 IDE 使用的插件市场、托管应用读取的云存储，以及通过 MCP 暴露的资源。这样员工无论在 Slack、IDE、仪表盘还是独立智能体会话中提问，底层使用的指标定义和分析过程都来自同一个版本。
分析文档不是项目结束后的说明书，而是数据产品的一部分，必须和模型代码一起变更。
07DATA PRACTICE
评测不是发布前的一次考试
Anthropic 使用两类离线评测。第一类从现有仪表盘中的常见问题生成，再由人工确认答案；第二类把路线图和数据说明等业务背景提供给 Claude，让它为更长尾的领域生成合理问题。利益相关者在线程中纠正智能体时，这类案例也会被持续收集，成为新的候选评测。
评测真值必须被固定。实时数据每天变化，如果直接把某个数值写成答案，测试很快就会失效。可行做法包括固定快照日期、使用稳定事实表，或者评价模型生成的查询而不是最终数字。每次运行的 Skill 版本、Git SHA、模型编号、各项判断、token 消耗和执行时间也需要写入数据仓库，使评测结果成为可查询的遥测数据。
领域上线应设置单独门槛。Anthropic 初期采用约 90% 的通过要求，迫使负责人先补足参考文档和常见失败案例，再把能力开放给使用者。评测数量并非越多越好：在单个主题上，几十个高质量案例之后往往出现边际收益递减，模型能力提高后需要的数量还可能下降。
系统结构也通过消融实验决定。团队曾让智能体直接搜索仪表盘、转换代码和分析笔记中的数千份 SQL，准确率变化不到一个百分点。对于仍然答错的问题，大约 80% 的正确信息其实已在这些文件中。资料存在且模型读过，并不意味着它会正确使用；这个结果促使团队把重点从扩大访问转向建立结构化路由。
评测的意义不是证明系统已经可靠，而是持续发现歧义、陈旧和检索失败从哪一层漏了出来。
08DATA PRACTICE
线上纠错能够闭环，静默错误仍然棘手
在线环境中，Anthropic 会让另一个 Skill 对候选答案的假设和 SQL 进行对抗性检查。这在内部评测中把准确率提高了约 6%，代价是 token 消耗增加 32%、延迟增加 72%。这项机制适合对准确性要求较高的分析，但并不适合所有低价值、低风险查询。
每个回答还会附带来源层级、数据新鲜度、模型负责人和审查状态。来源说明不能直接使答案变正确，却能帮助使用者判断是否需要进一步验证。团队同时监控通过语义层完成的查询比例，以及 Slack 等工作线程中“表用错了”“遗漏了某个过滤器”之类的纠正语言。定时智能体会扫描这些纠错，起草对参考文档的修改，并向领域负责人提交 PR。
这套闭环仍然无法完全捕获最危险的情况：答案是错的，却足够合理，没有任何人提出异议。当前的缓解方式包括为发送给管理层的结论设置人工确认，以及每天把各领域核心指标与权威仪表盘进行校验。Anthropic 明确承认，对这种静默错误还没有稳健的通用解法。
对于刚开始建设的团队，最小可行系统不需要复制全部架构。少量权威数据集、每个主题几十个离线评测，以及一个简单的知识 Skill，已经能够覆盖大部分收益。随后再根据业务复杂度、用户技术水平、准确性要求、成本预算和数据权限逐步增加对抗审查与自动维护。
可靠的数据分析助手不是一次部署完成的功能，而是一个会记录错误、更新知识并重新接受验证的系统。
离线评测、线上监控、文档更新与回归测试共同构成持续纠错闭环。
09DATA PRACTICE
真正被自动化的，是重复分析，不是数据责任
Anthropic 表示，公司约 95% 的业务分析查询已经由 Claude 自动完成，整体准确率约为 95%。这使数据科学团队能够把时间投入因果建模、预测和机器学习等更具战略性的工作。但这一结果不是把模型接入数据仓库后的自然产物，而是权威数据集、语义层、业务背景、Skills、CI 和评测共同作用的结果。
更重要的变化是责任位置。模型可以生成查询、解释结果、发现文档缺口并起草修复，但指标定义、数据访问权限和最终业务判断仍需要明确的人类负责人。上下文越丰富，智能体往往表现越好；访问范围越广，又越容易与企业的数据治理和隐私原则冲突。不同组织需要在准确率、延迟、成本和权限之间做自己的选择。
自助式分析的目标也不应被理解为让所有人都拥有一个随时回答问题的聊天机器人。更可靠的目标是建立一条受治理的路径：自然语言问题被映射到唯一的数据定义，查询过程能够追溯，结果带有新鲜度和来源说明，错误会进入下一轮评测与维护。只有这些条件同时成立，直接问数据才会从便捷入口变成可信的工作方式。
模型让更多人接近数据；治理、验证和责任归属，决定他们接近的是事实还是幻觉。