---
layout: post.njk
source: https://yage.ai/share/conversational-analytics-second-wave-20261014.html
speaker: yage.ai
title: |-
  对话式分析的第二次浪潮：Claude 亮出看板
  SQL，谁为数字兜底
date: '2026-10-14'
summary: 文章探讨对话式数据分析的第二次浪潮，指出核心瓶颈在于数据口径而非模型能力。对比了OpenAI的语义层治理与Anthropic的过程透明化两种路径，强调在AI生成看板中，确保数据可信度与责任归属比单纯生成图表更为关键。
area: tech-engineering
category: ai-application
tags:
  - conversational-analytics
  - semantic-layer
  - data-governance
  - text-to-sql
  - ai-dashboard
people: []
companies_orgs:
  - anthropic
  - openai
  - google
products_models:
  - claude-dashboards
  - claude-motion
  - data-agent
media_books: []
draft: true
status: evergreen
---

2026年10月8日，Anthropic 在官方公告中发布了测试版本的Claude
Dashboards和Claude Motion，据路透社报道，文档、幻灯片和设计工具也在同一天正式推出。用户在对话框中输入一些日常用语后，界面可以生成一个交互图表看板。技术人员第一次看到这样的演示时，往往会觉得对话式数据分析终于变得实用了。

从更长的时间尺度看，这已经是对话式数据分析十年来的第二次浪潮。图表渲染作为通用能力早已成熟，真正让一个看板能跑的，是后面算出来的聚合数据是否准确可信。

一个 AI
看板可不可信，要看它把这份信任托付给了谁。一种做法是提前把业务口径定死，让模型照着算；另一种是把查询过程摊开，让人自己去核对。前一种把责任交给定义口径的人，后一种把核对的活儿推回给看表的人。

同一个模型在学术测试集上准确率约
85%，落到真实企业数据库只剩约 20%，差距几乎全在数据口径上

## 十年老路：卡住的一直是口径，不是模型

自然语言转 SQL 不是大模型的特产。WikiSQL 与 Seq2SQL 论文在
2017 年就提出来了，Spider
评测基准论文在 2018
年也显示，当时最强的模型在没见过的数据库上跨库精确匹配率只有
12.4%，可见机器理解陌生表有多难。

在大模型兴起以后，这个问题反而更突出了。2023 年的 BIRD
评测基准论文显示，ChatGPT 在这个基准上的执行准确率只有
40.08%，而人类可以完成 92.96%。到 2024 年 11 月，Spider 2.0
评测论文把题目换成了真实企业的复杂数据库（它是 2018 年那个 Spider
的升级版，难度高得多），结果即便是当时最前沿的 o1-preview
智能体，执行准确率也只有 21.3%；同一个模型回到早期的 Spider 上，能拿到
91.2%。题目一换成真实企业，能力就现了原形。

甚至我们用来考核它们的标尺都不靠谱。2026 年发表在 VLDB 的评测分析里指出，BIRD
和 Spider 2.0-Snow 的标注错误率分别达到 52.8% 和
66.1%。测试集本身错漏百出，光刷榜拿高分，和企业实际用起来能不能顶事，完全脱节。

商业软件也一样。Tableau 在 2019 年上线的 Ask Data
就支持用自然语言问数（Tableau
产品回顾），ThoughtSpot 在 2023 年的发布通告里宣布接入
GPT-3 推出 Sage。但很快大家就撞上同一个坎：工具只会把话翻成
SQL，算出来的数字却对不上业务口径，前后打架。

做指标层的 AtScale
后来复盘过这段（他们自己卖指标层方案，有广告嫌疑）：第一代自然语言查询只会把用户的话翻译成
SQL，却不懂业务规则，导致口径打架、没人敢信，整条赛道在 2021 到 2023
年明显退了潮（AtScale
复盘）。卡住的从来不是写代码，是指标口径与可信度。

## 为什么是现在：四个条件刚好凑齐

既然十年前的老办法老是卡壳，为什么对话式分析偏偏在 2026
下半年又一次集中爆发？归根结底，是四个支撑技术刚刚在最近完成工程闭环。

首先是模型具备了自主写代码、跑代码的闭环。2023 年 7 月 6 日，OpenAI
在 ChatGPT
更新日志中上线了 Code
Interpreter，给模型配备了一个能够执行代码和验证数值的沙盒环境，让模型终于拥有了自主取数和算账的能力。

第二件重要的事是，输出结果变成了可以独立交互的工件。Anthropic 在 2024
年 6 月 21 日的 Artifacts
发布公告里推出了独立窗口呈现机制，紧接着在 10 月 24 日的代码分析工具说明里加入了对表格数据的直接处理。

再次是企业数据连接协议走向标准化。为让模型能统一接入数仓、CRM 和 SaaS
工具，Anthropic 在 2024 年 11 月 25 日发布 MCP
开源公告，推出 Model Context
Protocol（MCP），构建一条标准化的安全通道。

最后是前端产品形态和协作机制的大融合。Anthropic 在 2026 年 1 月开放
Cowork 预览，3 月 12 日发布 自定义可视化介绍，4
月 17 日推出 Claude
Design 公告，9 月 16 日通过 协作形态整合博客全面整合，至今用户已经建了超过
4500 万份文档、幻灯片和设计。

而竞品的节奏同样紧凑：OpenAI 早在 2026 年 9 月 10 日就发布了 OpenAI
数据智能体公告中的 Data agent，比 Anthropic 快了四周；10 月 7
日又发布了流式组件编译器的 GPT-6
发布说明。Anthropic 的官方账号在 10 月 8 日推出 Dashboards 和
Motion，也反映了技术成熟与竞争压力的共同作用。（官方社交平台动态）

## 两种兜底：把口径先治理好，还是把过程露出来

对话实时生成看板在跨过门槛后，各家公司在确保数据真实性方面采取了不同的方法。

一条路是先把规矩定好，同一个词比如销售额，不同人的算法可以不一样（退不退款？未支付订单算不算？汇率按下单当天还是出库当天算？）。所以在数据库上面加一层，把业务规则和口径先统一定死，让模型只负责根据这些定义去做查询。这套集中管理口径的东西叫语义层。

这种设计思路强调可信度在定义和口径的选择上。因此，OpenAI的Data
agent也采用了类似的策略，它利用的是企业内部已有的定义和指标，因此只保证能理解每个数字的来源是哪些证据，而不保证会展示SQL语句。其他数据平台和BI厂商也普遍采取这样的策略，微软在Copilot中加入了受管理的语义模型，而Databricks则明确提到，如果不给模型提供业务上下文，它的”数据智能体”的表现极差，甚至到了不可接受的程度。

另一个方向靠的是把过程摊开，代表是 Anthropic 的 Claude
Dashboards。它给每幅图配一条自己的
SQL，点一下图上任意数字就能展开这条查询，角落还会显示数据最后更新的时间（入门指南）。按官方说法，看板默认只给自己看，分享出去后每个人用自己那份权限重跑一遍，看到的还是他本来就能看到的数据，不过这套权限模型还没有第三方穿透测试（The New
Stack 转引官方）。同批推出的动画工具 Motion
也是用代码驱动画面、不生成视频，改起来方便（Motion
入门指南）。

Google 站在中间。它的对话式分析在给出答案前，会把推理步骤和生成的精确
SQL
一起亮出来，还标出每个结论的引用来源，同时让回答走自己那套受治理的建模层，最后把每次查询记进审计日志（BigQuery
公告）。既立了规矩，也留了痕迹。

Anthropic 则相对低调。它坦诚地声明，Dashboards
用于快速探索和即时问答，不会替代专业 BI，并支持一键对接
Grafana、Hex、Sigma 等分析平台（未来会加入 Looker 和 Tableau）（官方公告）。Sigma
在同日发布了对应的接入集成（Sigma
合作声明），将这一分工落到实处。

治理前置先把口径定死、让模型照着算，过程留痕则把查询摊开、让人自己核对，两条路的差别在于谁来为数字负责

## 露出 SQL
不等于可信：这一轮真正的分野

将查询摊开、点一点就能看到它是如何计算出来的，相比几年前那些黑盒，确实是一个进步。但它解决的只是能不能查，而不是要不要信。把
SQL
直接怼到业务人员面前，等于把挑错的活儿又丢回给了他：他用这个工具，本来就是不想读代码，现在却要他去判断这条查询的逻辑对不对（Omni
的批评）。要是每个数字回头还得自己验一遍才知道准不准，那这套工具到底替他省了什么？

但更麻烦的是，因为用的是大模型来自由生成
SQL，同一个问题每次得到的答案可能都不一样。dbt
做过一组对照实验：同一个模型直接写 SQL，准确率在 84% 到 90%
之间；一旦把查询统一到一个口径上，准确率就到了 98% 到
100%，几乎不出错（dbt
的评测）。dbt
自己也卖口径产品，所以数字要打折扣，但至少说明一点：飘的不是模型，是口径。

离现实企业越近，反差越大。学术测试集上模型八九成准，一落到企业没清洗的脏库，直接写
SQL 只剩一到三成，复杂的多表关联甚至归零（colrows
的断崖分析、promethium
的基准指南）。这些数字也来自卖口径的公司，要打些折扣，但和一线工程师的体感吻合：模型越自信，错了越没人看出来。

但这个行业其实已经用脚投票了。Gartner 把语义层列成 2030
年跟数据平台、网络安全并列的关键基础设施，还直说缺少治理的模型直接参与决策，短期内就会给公司带来财务或声誉损失（Gartner
趋势预测）；Forrester
干脆把语义层定义成整个数据应用生态的控制平面（Forrester
观点）。分析机构看重的不是那个聊天框。

## 结语：出图已经不值钱，愿意为数字负责才值钱

回头看看，这场竞赛表面上在卷谁能让AI更快出图，实际上在比谁替数字的正确性兜底。立规矩的一派把责任交给定口径的人，摊过程的一派把责任推回给看表的人。两条路都不便宜：前者需要有人先把口径建起来，后者需要有人读得懂
SQL。选哪边，看你手里的数字有多重。只是找灵感、先摸个方向，怎么都行；要拿去汇报、决定花钱，那就得先问一句，这个数错了，谁来担。

Claude Dashboards
有没有补上语义层、行列级权限、审计和定时刷新，官方公开材料里一个字都没提，至今是未知数；至于准确率，两家其实半斤八两，Claude
Dashboards 和 OpenAI 的 Data agent
都没公布能比的数字。谁能一边留住随手一问的灵活，一边啃下口径这块硬骨头，答案还没到。但有一点已经清楚：出图早就不值钱了，真正稀缺的，是那个愿意为数字负责的环节。