智能分析远不止于文本转SQL：来自Anthropic的启示

分析垃圾正成为新的AI垃圾

Anthropic在2026年6月3日关于自助分析的文章中公开表达了诸多数据团队通过惨痛经验才领悟到的道理：智能代理分析并不等同于让Claude Code连接数据库并提问。

大多数人都知道“AI垃圾”这个术语，分析垃圾则是它的同类。借助编程智能体，现在任何人都能连接数据库并生成分析报告。这确实降低了入门门槛，但另一方面，几乎没人会去核实这些数据。仪表板以.html文件、Confluence页面或终端截图的形式出现，而其中很少有经过验证的。其原因是一种错误的安全感——由于大语言模型能将英语很好地转化为SQL，人们就认为得到的答案一定是正确的。

那种信心是错置的。当智能分析仅局限于查询生成时，问题的界定就会过于狭隘，而那些决定某个答案是否有用的周边基础设施却会被忽视。Anthropic自身的设计将数据基础、真实信息来源、技能以及验证机制置于Claude看到查询之前。这篇文章列出了经典的数据工程实践作为必要要求，并分享了经验，以便其他团队能够避免犯同样的错误。

这篇文章属于企业级人工智能领域的报道，并非研究论文，却是目前最清晰地阐述可靠智能分析所需要素的实用文章之一。文中按顺序阐述了核心观点：为何文本转SQL并非正确思路、歧义从何而来、Anthropic开发了什么、在编写查询之前需要具备哪些条件、语义层与技能的作用、为何评估与维护至关重要，以及团队应从何处着手。

为何文本转SQL备受关注

查询生成是那种能在30秒内展示成果的功能。用通俗的英语提出问题，观看模型生成查询语句，将其应用于数据仓库，随后便能得到数值或图表结果。这对那些过去依赖分析团队或预置仪表盘的非技术人士而言，显得尤为神奇。

Claude或Codex给出的流畅解释与整齐的数字并不能说明问题是否得到了正确解答。用Anthropic的话来说，让Claude处理仓库相关任务会给人一种精确的错觉，而这正是陷阱所在。

以某利益相关者询问“上个月的活跃客户收入是多少？”为例，分析上的细节问题立刻就会出现：

• 什么才算活跃客户？
• 官方采用的客户定义是什么？
• 该数字是总收入还是净收入？
• 应使用哪个日期字段？
• 需要应用哪些退款规则、欺诈过滤机制或产品排除条件？

只有在这些决策做出之后才能生成文本到SQL的查询。因此，一个可靠的分析工具需要配套完整的基础设施来引导其对业务逻辑的理解。

这呼应了谷歌一篇关于机器学习系统中隐性技术债务的著名论文，该论文指出模型只是庞大生产级机器学习系统中的一个小模块。

上图即来自该论文的截图。如果将那个小黑框替换为文本转SQL功能，同样的结构也适用于分析代理。

Anthropic的回答与这种观点一致，体现在“数据并非软件”这句话上。分析工作与软件功能的失败机制不同：通常存在一个来自正确来源的正确答案，但仅凭最终输出却无法确定性地验证它。而且一个系统可能写出毫无错误的SQL代码，却完全理解不了其业务含义。

Anthropic还提供了一组对比这两种范式的示例，见下表。

Anthropic将由此产生的故障分为三种类型：

1. 概念或实体模糊性。用户提到“活跃用户”、“收入”或“留存率”时，系统需要从多种可能的解释中选择。这些解释之间的差异往往很微妙，导致错误的答案仍看起来专业合理。
2. 数据过时。文档、表格和业务规则不断变化。三周前还准确的指标，在架构调整、新的排除规则生效或控制面板重新构建后，可能会悄然出错。
3. 检索失败。正确答案其实存在于系统的某个部分，但可搜索的内容过于庞大。模型会忽略正确的表格、指标或文档，而基于类似但不准确的信息得出结论。

仓库本身无法解决这些问题。它只存储数据，而非业务的完整含义——后者的内涵分散在各种度量定义、语义模型、注意事项、团队规范、责任归属以及历史记录之中。以收入为例，编写GROUP BY语句很简单，但确定“活跃”意味着什么却很困难：是30天内的某次购买，还是某个计费周期内的合法非欺诈性使用，又或是仅存在于语义层中的特定领域阈值？

因此，Claude能否编写SQL其实并非关键问题，因为它很可能比大多数人写得更好。真正有意义的问题是，Anthropic为了克服这些问题，围绕Claude构建了什么机制。

Anthropic的构建成果

答案是经过验证的工程实践与智能体所实现的额外功能层的结合。实际上，这是一个完整的系统，Claude作为顶层接口，其余所有组件则位于其下方。这篇文章将其分为四个部分：

1. 数据基础，包括标准数据集、数据模型、转换规则、测试机制、新鲜度检查以及元数据。
2. 事实来源，涵盖语义层、数据溯源、业务背景以及有助于将问题映射到规范含义的精选参考资料。
3. 技能，即领域内的操作流程，用于指导模型如何工作，而不仅仅是告知其存在哪些数据。
4. 验证机制，包括离线评估、在线检查、数据来源追溯以及维护循环。

上面的截图来自Anthropic的帖子。请注意SQL出现在流程中的位置：在所有艰难决策之后。当模型最终生成查询语句时，系统已经缩小了问题的含义范围，并确定了哪条处理路径值得信赖。

与选择模型相比，这种结构能更好地解释标题中的数字。粗略阅读会让人觉得95%这个数值是模型的性能指标，而仔细阅读后会发现这是系统层面的基准，因为帖子中大量内容都在描述围绕Claude设计的框架，而关于Claude本身的描述却很少。

在生成任何SQL之前需要具备什么条件

Anthropic明确指出，传统的数据工程方法依然适用：维度建模、数据新鲜度与完整性检查、可直接使用的标准数据集以及清晰的数据字典。仅仅因为交互方式变成了对话形式，并不意味着这些方法就不再需要了。事实上，由于使用者现在是根据人类问题来行事的智能体，其重要性反而更高了。分析师有时能察觉到某个表格存在问题，而智能体则可能更快地将错误的假设扩大化。

一家处于行业前沿的公司却告诉全世界，传统的数据工程对智能体而言至关重要，这其实有些讽刺。这些做法并非新鲜事物，任何二十年前出版的数据仓库相关书籍都会给出同样的建议。不过它们依然值得再次强调。

标准数据集

一组受严格约束的逻辑模型，每个模型都是唯一的真实数据源，这能在检索开始之前就减少可能的答案数量。虽然可能需要不同的聚合层级，但所有汇总结果都应基于这一小部分基础数据。分析型智能体也是如此：当它们只能访问少数几个可信的数据集，并且知道这些数据集如何与更丰富的维度相对应时，选择错误数据源的概率就会大幅下降。

元数据作为一级产品

元数据为智能体提供了关于表格、列、数据粒度、负责人以及注意事项的详细说明。如果没有人对模型、每列的含义以及关联键进行记录，大型语言模型就会用猜测来填补这些空白。

将模型、文档、仪表板及技能文件集中管理

所谓“共置”，可能仅仅意味着一个庞大的单仓库结构，但Anthropic给出的定义更为精确。几乎所有数据代码——从建模与语义层相关的内容，到参考文档以及标准控制面板定义——都存储在同一个仓库中，并通过跨层完整性检查来确保其质量。任何可能破坏下游控制面板功能或使文档中规定的指标失效的建模变更都会被CI系统识别出来，相关修复内容也会在同一次拉取请求中一并提交。

这打破了“人工智能分析使得数据工程变得不那么重要”这种片面的观点。通过模型处理的查询越多，建模层的质量就越容易被察觉。

其他供应商也提供了类似功能。dbt语义层的存在就是为了让指标定义只需编写一次，即可被所有工具重复使用。微软建议为Copilot准备Power BI数据时采用适合AI处理的架构、经过验证的答案以及明确的指令，这样模型才能基于可靠的上下文给出回复。Snowflake则围绕语义模型和经过验证的查询构建Cortex Analyst，并对SQL生成过程进行监控。所有产品都在传达同一个道理：提前准备好的上下文是得到正确答案的关键。

语义层就是智能体的地图

语义层是一种架构桥梁，它将原始的、复杂的数据转化为人们熟悉的业务术语、指标和关联关系。它位于诸如 Snowflake、Databricks 或 BigQuery 等数据存储系统与 Power BI、Tableau 或 AI 智能体等数据使用工具之间。有了语义层，就可以了解某一列的含义、另一列的数据类型、指标的计算方式，以及层级结构和表格关联的运作原理。

上图展示了该层的位置。Anthropic认为它极为重要，其智能体在结构上必须首先查询语义层。其运作原则是模型从受约束的意义出发，而非对原始数据表进行无限制的探索。Anthropic甚至认为让智能体自行构建语义层是一种不良做法。保持该系统的良好状态仍需人类参与，而这正是来自世界顶尖实验室的成果。

整个行业正逐渐形成相同的观点。Snowflake的Cortex Analyst利用语义模型将业务问题与数据库结构相连接。Databricks的Genie则由领域专家提供数据集、操作指南、示例SQL代码以及业务背景信息。dbt将度量逻辑集中管理，避免下游工具重复构建；而Microsoft则将经过验证的答案和AI指令整合到BI模型中。在Google的数据科学代理取得突破之前，它也需要类似的功能——一个名为Analyzer的伪语义层。

没有这样的映射，代理只能靠猜测；有了它，模型便能在受限的框架内进行推理，而无需从头创建新的框架。

示例查询可丰富该层功能

Anthropic指出，查询语料库——即来自控制面板、笔记本以及早期分析的历史SQL语句——能够产生积极的整体效果。关键在于不要直接将原始数据喂给智能体，而应将这些语料库提炼为结构化的领域专用参考文档，以及以技能形式存储的可复用分析模式。查询历史只是用于筛选整理的原始材料，而非智能体直接读取的权威信息源。

谁拥有什么数据还会带来实际影响。由于分析代理依赖于受管控的定义，那些维护这些定义的人——通常是分析工程师和领域负责人——便成为了代理质量保障体系的一部分。有争议的指标不再仅仅是仪表板上的争论点，而是共享层中的缺陷，这类缺陷会在一个地方得到修复，并被所有使用者（无论是人类还是模型）所感知。那些已经采用这种工作方式的团队，相比那些指标逻辑分散在各种笔记本和商业智能工具中的团队，会更轻松地过渡到使用分析代理。

为何技能对准确性影响如此之大

语义层能够解释世界的含义，但无法指导人们如何行动。它无法说明当利益相关者提出一个含糊不清的问题、且该问题存在两个可能的来源以及某个特定区域内的已知异常情况时，优秀的分析人员应该采取哪些步骤。

在Anthropic的分析系统中，技能类似于经过编码的分析师操作手册，而非普通文档。它们包含流程性知识：

• 检查各数据源的顺序
• 何时应使用语义层以及何时可以采取备用方案
• 需要向相关方提出的澄清问题
• 该领域适用的注意事项
• 在信任结果之前对其进行验证的方法
• 最终答案中所包含的来源信息

Anthropic最出色的成绩便源自于此。根据文章中关于技能的部分介绍，没有技能辅助时，Claude在分析评估中的得分从未超过21％；而借助技能层后，整体准确率上升到了95％以上，某些领域的准确率甚至接近99％。

这一数值决定了该系统应被称为何。如果最大的提升来自流程化指导而非更优的SQL生成，那么它本质上并非文本转SQL的产品，而是一款包含查询执行功能的分析工作流产品。

同时，记住它的“非本质特征”也有帮助：它既不是更长的系统提示语，也不是粘贴进去的一堆示例查询。它是一个有版本控制、触发条件及明确流程的维护对象，会在需要时被加载。正因如此，它可以在拉取请求中进行审查，利用评估集进行测试，且在底层数据模型发生变化时也易于废弃。

下图展示了Anthropic使用的技能模板。

综合来看，这些组件共同构成了完整的定义，附录中则完整呈现了该模板。

评估与维护与提示语同样重要

即便是一个基础扎实的分析模型，也会随着时间逐渐失效。一旦出现了语义层、精心挑选的示例以及相关技能，数据漂移就会成为新的问题：表格结构发生变化，定义也随之改变，仪表板需要重新构建，而这些技能也会不再与原始模型匹配。昨天还有效的处理流程，到了明天就可能变成过时的内容。

Anthropic给出了一个鲜明的例子：在开始将技能维护视为工程问题之前，仅一个月内其离线准确率就从约95%下降到了约65%。这一数据使得技能维护从一项可选的优化措施变成了保障系统可靠性的必要要求。

分析工具在这里有一个便利的特性，那就是评估可以基于任何正确流程都应复现的真实数值。一旦确定了这些数值，系统的其他所有参数都可以据此进行调整。团队可以在多个思维层级上尝试使用Haiku、Sonnet或Opus等工具的第二个版本，比较准确率，从而选出在成本与质量之间取得最佳平衡的方案——无论是以较低成本获得足够高的准确率，还是不惜一切代价追求最高准确率。

成熟的分析系统会通过特定方式接受测试：存储案例、明确的断言，以及一个反馈机制，一旦系统出现错误就会重新编写操作指南。Databricks在其Genie文档中也采用了类似的理念，将该产品中融入了响应检查、基准测试、可信资产以及精心整理的指导说明。

在这里，提示词的重要性并不像人们通常认为的那么高。质量依然重要，但若语义层薄弱、示例陈旧、模型能力不断下滑且缺乏评估机制，再出色的提示词也无法长久挽救系统。只有当整个系统被当作需要维护的产品来运行时，代理分析才能发挥作用；如果让模型直接操作数据并自行发挥，则无法实现这一目标。

数据团队可从何处着手

最好的起点是采用最简单的可行结构，逐步增加复杂性，且仅在证明这样做能带来成效时才这么做。Anthropic关于构建高效代理的指导也提出了相同观点，其后续的分析文章也呼应了这一思路。以下是五个步骤：

1. 选择某个特定领域而非整个系统，比如收入质量、客服运营、增长流程或财务报告。应挑选有明确负责人且存在重复性问题的领域。

建立统一的受管控真实数据源。在相关领域拥有标准数据集、明确的度量定义、指定的负责人以及基本的新鲜度监控机制之前，可暂不处理查询请求。

优先考虑语义层，将原始SQL作为备用方案。当问题能够清晰对应到受管控的语义时，智能体不应直接在原始表格中随意查找答案。

制定一份简明的技能指南或操作手册，描述优秀分析师在该领域的工作流程：明确问题、选择数据源、验证信息、生成报告，并注明数据的来源。

在全面推广之前先构建一个小规模的测试集。二十到三十个真实问题，加上预期答案和已知的边界情况，其教学效果远胜于上百次内部演示。

需要避免的一点是将前沿模型直接接入数据仓库并称之为策略。这种做法除了能让人们了解错误答案可能有多具说服力之外，几乎无法带来其他收获。

文本转SQL作为一种实用的执行方式，在技术架构中占有一席之地。问题在于，这一概念过于狭隘，无法涵盖整个系统。这一主题很可能会将团队分为两类：一类将文本转SQL视为独立产品，另一类则将其视作更广泛的分析工作流中的单一薄层功能。值得探讨的问题包括：最大的故障源自何处（歧义、数据检索问题、数据过时或流程缺陷）、分析工具所需的基础条件是否已经具备，还是该项目会暴露出隐藏的数据模型问题，以及目前的技能层面包含哪些内容，比如提示词、操作手册、SQL示例或分析师检查清单。

附录：完整的技能模板

Anthropic提供的完整技能模板如下。

---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [the company]'s data warehouse for any
  [list of business domains] question — THEN invoke this skill. DO NOT invoke
  for [adjacent engineering tasks] or questions with no data-warehouse component."
---

# [Warehouse] Skill Instructions

## Description
The single source of truth for safe and effective [warehouse] querying.
Referenced by other skills [listed] for query execution guidance.

Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.

**Out-of-scope decisions**: [product areas, etc.] → surface data only,
state "decision is [owning team]'s call", do NOT take a position or author
code fixes.

## Executing queries
Priority:
1. **[Managed connection]** (if available): [query tool] / [schema tool]
2. **[CLI fallback]** (if installed): [default project, fallback project]
3. **Neither** — ask the user to authenticate, then stop

---

# Semantic Layer (REQUIRED first step)

The governed semantic layer is the **mandatory default path** for every data
question — same numbers as [the BI tool], joins/grain/filters baked in. Raw SQL
via the reference docs below is the **fallback**, used only after the
semantic-layer path is shown not to cover the ask.

## Required workflow
1. **Load** — [how to load the semantic layer in each runtime, with fallbacks]
2. **Discover** — search measures/dimensions by keyword; **always check
   segments** (the named canonical population filters — hand-rolled WHERE
   clauses for these are the dominant wrong-answer mode)
3. **Compile + run** — build the spec → compile to SQL → execute
4. **Fallback** — only if discovery finds no relevant metric or compile fails
   → raw SQL via `references/*.md` (PART 3 below)

> **Don't bail early.** Do NOT fall back to raw SQL on these grounds:
> - "[custom date filtering / cohorts]" → [covered by time-dimension specs]
> - "[needs a join]" → [the metric layer already encapsulates its joins]
> - [3–4 more pre-rebutted excuses agents use to skip the semantic layer]

### Date windows & timezone — decide before you query
- **As-of date vs trailing-N days**: [convention for each]
- **"Last week/month"** → the last *complete* calendar week/month, not trailing-7/30
- **Timezone default**: [TZ]; [exception for certain reporting rollups]
- **Freshness lag**: [some] tables settle late — anchor on MAX(date), not "yesterday"

---

# PART 1: MUST KNOW (Read First for Every Request)

## 🚀 Quick Start Workflow
1. **Check for red flags first**: [restricted/PII requests, gated domains,
   high-stakes asks that need extra validation]
2. **Out of scope — escalate, don't guess**: [access requests, pipeline
   troubleshooting, stale dashboards, root-cause assertions, product/pricing
   recommendations] → redirect to [the owning team], don't answer
3. **Clarify the request**: time period, segment, the business decision it informs
4. **Check for existing dashboards**: [per-domain dashboard catalogs]
5. **Identify the data source**: [navigation map below; prefer governed/aggregated tables]
6. **Execute the analysis**: [required filters + adversarial review]
7. **Deliver insights**: show methodology, differentiate observations from interpretations

## 🏢 Business Context

### Entity Disambiguation (MUST CLARIFY)
- **"[Term A]" can mean**: [entity 1] or [entity 2] — always clarify which
- **"[Term B]" can mean**: [entity 1] → [entity 2] → [entity 3] (one-to-many chain)
- **"Users"**: [which identifier gives accurate counts, and which ones inflate them]

### Business Terminology
- [Current product names vs deprecated aliases that still appear as frozen
  values in the data layer — write with the new names, filter with the old]
- [Key internal acronyms]
- **[Headline metric] calculations**: [monthly / default window / leading indicator]
- **Unfamiliar terms — search [internal docs], don't guess**

### Data Integrity Requirements ⚠️
- **NEVER**: make up data/columns; make speculative assertions beyond what data shows
- **ALWAYS**: use safe division; differentiate observations ("data shows X")
  from interpretations ("this suggests Y"); flag limitations

---

# PART 2: HOW TO DO (Follow During Execution)

## 🔧 Technical Execution Guide
- [Managed-connection tools and CLI invocation details]
- **PII protection**: for restricted data, return the SQL for the user to run
  themselves — do not return results

## 📊 Analysis Best Practices Guide
1. Clarify the ask before querying
2. Show your work (filters, inclusions/exclusions, freshness)
3. Clarify denominators
4. Consider sample bias
5. Connect to business impact
6. **Adversarial SQL review (MANDATORY)** — spawn the [sql-reviewer] sub-agent
   for every query before the final answer; blocking findings must be fixed
   and re-reviewed; do not self-certify
7. **Report with provenance** — every answer ends with a footer:
   > **Source:** [semantic layer | governed table | raw exploration] ·
   > **Confidence:** [tier] · **Reviewed:** [reviewer ✓, round N] ·
   > **Freshness:** [max date in the data] · **Owner:** [owning team]

---

# PART 3: DATA REFERENCES & RESOURCES

## 📚 Knowledge Base Navigation
### [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: `references/[domain_a]_dashboards.json`

### [Domain B] → `references/[domain_b].md`
- **Use for**: [...]

[... one entry per business domain — a few dozen in total ...]

## ⚠️ Troubleshooting Guide

### When Information Is Missing
- [missing tables / access denied / outdated docs / unknown enum values → what to do]

### Field Naming Gotchas
- Use `[field_x_v2]` NOT `[field_x]`
- [Two similarly-named tables report the same metric at different grains — which to use]
- [Which of two plausible sources is canonical for the headline metric]
- [… a dozen more hard-won one-liners …]