Data Agent：大数据项目的轮回

字数 3973，阅读大约需 20 分钟

Data Agent：大数据项目的轮回

技术换了一代又一代，瓶颈纹丝不动。

一、两个数字，一个轮回

先看一组让人脊背发凉的对比：

87% vs 88%。十年过去了，技术栈全换了，失败率纹丝不动。

这不是巧合。这是同一个病，换了一身衣服。

二、所有人都在追的皇冠

Data Agent——让业务人员用自然语言问数据问题，Agent 自动生成 SQL、查库、返回结果——是企业 AI 领域最诱人的愿景。

每家大厂都在押注：

• • Snowflake 推出了 Cortex Analyst
• • Databricks 推出了 AI/BI Genie
• • Microsoft 推出了 Fabric Data Agents（已 GA）
• • Google 推出了 BigQuery Conversational Analytics
• • dbt 推出了 Semantic Layer + MetricFlow

Databricks 2026 年的报告（基于 20,000+ 组织的真实数据）显示，60% 的组织将数据分析与报告生成列为最具影响力的 AI Agent 用例，仅次于代码生成。LangChain 的调研也印证了这一点：研究与数据分析（24.4%）是第二大 Agent 用例。

看起来，Data Agent 已经是一个被验证的赛道了。

但真相比这残酷得多。

三、91% → 10%：悬崖

这是整篇文章最重要的一组数据。

Text-to-SQL 准确率悬崖：基准测试 vs 真实企业数据

Text-to-SQL 准确率悬崖：基准测试 vs 真实企业数据

所有 Data Agent 的核心技术是 Text-to-SQL——把自然语言翻译成 SQL 查询。在学术基准测试（Spider 1.0）上，前沿模型的表现非常亮眼：

• • GPT-4o：86.6%
• • o1-preview：91.2%

这些数字让"用自然语言问数据"的 demo 看起来无比可信。

然后，研究者们做了一件残忍的事：他们用真实的企业数据库重新测了一遍。

Spider 2.0（ICLR 2025）用 632 个真实企业工作流任务重建了基准测试——BigQuery 和 Snowflake 上超过 1,000 列的数据仓库，需要 100 行以上多步骤 SQL 的复杂查询。结果：

同一个模型，同一个任务，70 个百分点的断崖。

更极端的是 MIT 的 BEAVER 基准测试——用真实的企业私有数据仓库查询日志构建，模型从未在训练中见过这些数据。GPT-4o 的得分：0.0%（检索模式）和 2.0%（无检索模式）。论文原话是：

"没有任何现成的 LLM（包括 GPT-4o）能正确回答任何一个问题。"

这就是 Data Agent 面对的现实。不是"还需要优化"，而是从学术到生产，存在一道几乎不可逾越的悬崖。

四、悬崖是怎么形成的？

为什么同一个模型在学术测试上 91%，到了真实企业数据上就变成 10%？

不是模型变笨了。是问题本身变了。

1. 学术测试是"翻译题"，企业数据是"理解题"

Spider 1.0 的数据库长这样：3–10 张表，列名清晰（student_name、course_id），关系明确。问题里几乎包含了写 SQL 所需的全部信息。模型只需要"翻译"。

企业数据仓库长这样：500+ 张表，10,000+ 列，列名是 usr_trx_fl、txn_dt_01、tmp_stage_agg。二十年的命名决策堆积在一起，没有人记得每个字段到底是什么意思。模型不是在翻译，而是在猜。

2. 最关键的语义不在数据库里

这是最致命的一点。用一个具体的例子来说明：

销售总监问："Q3 我们在欧洲区的收入是多少？"

模型找到了 orders 表、customers 表、regions 表，写出了一条看起来完全合理的 SQL：

SELECT SUM(o.amount) AS revenue
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN regions   r ON r.id = c.region_id
WHERE r.name = 'EU'
  AND o.order_date BETWEEN '2026-07-01' AND '2026-09-30';

SQL 能跑。数字出来了。但这个数字至少有七个地方是错的：

这七个事实，没有一个写在数据库的 schema 里。 它们活在财务部门的政策文档里，活在 BI 团队的指标定义里，活在老员工的脑子里。

模型看不到这些。所以它猜。猜得很自信。猜得很错。

3. "活跃客户"问题：五个部门，五个答案

再来一个更日常的例子：

产品经理问："上个月我们有多少活跃客户？"

模型找到 customers 表，看到 status 列有个值叫 'ACTIVE'，秒出答案：

SELECT COUNT(*) AS active_customers
FROM customers
WHERE status = 'ACTIVE';

数字很大。销售很开心。然后财务说不对，产品说也不对，客户成功说更不对。

因为"活跃客户"在每个部门的定义完全不同：

而数据库里的 status = 'ACTIVE'？在大多数系统里，它只表示"这条记录没有被归档"。跟上面五个定义一个都对不上。

模型选了看起来最明显的那个列。五个部门里没有一个认可这个数字。

这就是大数据项目十年来的经典场景——报表数字对不上，A 部门说收入是 X，B 部门说是 Y，吵了半天发现是口径不一样。 现在换成 Agent 来查，Agent 不会跟你吵，它会非常自信地给你一个错误的数字，而你根本不知道它错了。

五、Semantic Layer：救命稻草还是空中楼阁？

它确实有用

dbt 在 2026 年做了一个基准测试，结果很能说明问题：

Snowflake 的内部测试也显示：GPT-4o 在 150 个真实 BI 问题上裸跑只有 51%，加了 Semantic Views 后提升到 90%+。

dbt 的人说了一句被广泛引用的话：

"Text-to-SQL 失败的时候，它给你一个看起来对但实际上错的答案。Semantic Layer 失败的时候，它给你一个错误提示。对于要上董事会的数据，这个区别就是一切。"

但它不是默认有的

这是很多人的误解。 Semantic Layer 不是你买了 Snowflake 或 Databricks 就自动拥有的东西。它是一个需要大量人工填充的空架子。

每家都给你一个空架子。 里面"收入是什么意思""转化率怎么算""这个字段在不同部门的口径差异"——全得你自己填。

所以 dbt 那句话真正狠的地方不是"有了 Semantic Layer 就好了"。恰恰相反——它在说，你大概率没有一个填充好的 Semantic Layer，所以你的 Data Agent 现在就处于"静默失败"状态：给你看起来对但实际错的答案，而你还不知道。

填充 Semantic Layer 有多难？

Cloudera 和哈佛商业评论 2026 年联合发布了一个数据：只有 7% 的企业认为自己的数据完全准备好了给 AI 用。

不是 70%。是 7%。

这意味着 93% 的企业，连 Semantic Layer 的"填充"工作都还没开始——或者开始了，但远远没有完成。

六、那个六周的故事

这是我在整个调研过程中看到的最有洞察力的一手案例。

一个大厂数据团队的成员在 Reddit 上分享了他的亲身经历：团队接触了 4 个 Data Agent 的 POC，3 个停滞，1 个上线。

停滞的 3 个，死因都一样：不同团队对同一个指标的定义不同，语义层不存在，没人在让 Agent 查数据之前先统一"收入"到底是什么意思。

成功的那 1 个，关键不在技术。他们花了六周时间，让两个分析师（注意，不是工程师）和产品、财务、营销负责人坐在一起，写清楚"试用转化率"在每个部门的报告中到底意味着什么。产出了大约 30 页的纯英文指标定义和边界情况说明。

然后 Agent 层只花了 2 周就接上了。

那个帖子的作者总结说：

"那个准备工作才是项目本身。"

六周定义指标，两周接 Agent。 这个比例说明了一切——Data Agent 的难点从来不是 Agent，而是 Data。

这不就是大数据项目的翻版吗？当年做数据仓库，最难的也不是选 Hadoop 还是 Spark，而是让业务部门坐下来统一维度定义和指标口径。技术从来不是瓶颈，共识才是。

七、Novo Nordisk：一个成功案例，但别急着复制

在一片惨淡中，确实有成功的案例。全球制药巨头 Novo Nordisk（诺和诺德）用 AI 分析平台 Tellius 实现了 88% 的分析时间节省——区域销售分析从一周缩短到 10 分钟。这个案例在 2025 年 Gartner Data & Analytics Summit 上做了公开演讲，有详细的拆解。

但你仔细看它为什么能成功，就会发现一个关键细节：

Tellius 花了 7 年以上的时间，专门为制药行业预建了语义层。

它内置了 IQVIA 数据结构、HCP（医疗保健专业人员）互动模式、处方行为分析等制药行业特有的业务逻辑。Novo Nordisk 不需要自己花六周让各部门坐下来统一口径——因为 Tellius 已经把制药行业的通用口径编码好了。

换句话说，Novo Nordisk 的成功不是反例，恰恰是最好的正面证据——它成功，正是因为有人（Tellius）花了 7 年帮它解决了那个"非技术瓶颈"。

而且它的部署策略极其克制：

• • 先给 30 个人用，不是全公司铺开
• • 专门挑"对数据有好奇心的 power user"，不是随便谁都给
• • 从 30 人到 100+ 用户，花了将近一年

大多数企业面对的现实是：没有一个 Tellius 替你预建好语义层。你得自己干那个最苦最慢的活——统一业务语义。而这件事，跟十年前大数据项目的瓶颈一模一样。

八、最危险的失败模式：看起来对

大数据项目失败的时候，通常是明显的失败——报表跑不出来、数据对不上、系统崩了。你知道它坏了。

Data Agent 的失败模式更阴险：它看起来工作得很好。

SQL 能跑。数字出来了。图表画得漂漂亮亮。你拿去汇报了，拿去做决策了，拿去定 KPI 了。直到三个月后有人发现"这个数对不上"——但基于这个数字做的决策已经执行了。

Gartner 的数据显示，低质量数据每年给每家企业造成平均 12.9M 的损失。IBM 2025 年的 CDO 研究发现，超过四分之一的组织每年因数据质量问题损失超过 5M，7% 的组织损失超过

Data Agent 不会减少这种风险。如果没有 Semantic Layer 兜底，它会加速这种风险——因为它让错误数据的生产速度从"人工查询"提升到了"秒级自动化"。

💡 Colrows 的总结最精准："悬崖不是一个模型问题穿着数据的外衣。它是一个上下文问题穿着模型的外衣。修上下文，不是修模型。"

九、所以，Data Agent 到底能不能做？

能。但你得先问自己三个问题：

问题一：你的"收入"有几个定义？

如果答案是"一个"，恭喜你，你可能属于那 7% 数据就绪的企业。如果答案是"看哪个部门问的"——你需要先做的不是选 Agent 平台，而是让各部门坐下来统一口径。这件事没有任何技术可以替你做。

问题二：你愿意从 30 个人开始吗？

Novo Nordisk 的做法是：先找 30 个 power user，让他们用出价值，用成功案例说服其他人。不是全公司铺开，不是"数字化转型"的大项目。如果你的领导期望"三个月全公司上线 Data Agent"，那你大概率会成为 88% 的一员。

问题三：你能接受 Agent 说"我不知道"吗？

dbt 那句话的核心启示是：一个会说"我不确定"的 Agent，比一个永远给你答案的 Agent 安全一万倍。 在架构设计上，这意味着你需要 Semantic Layer 来约束 Agent 的回答范围——让它只回答有明确指标定义的问题，对于模糊的问题，老老实实说"这个问题需要人工确认"。

十、写在最后

2017 年，Gartner 说 85% 的大数据项目会失败。大家不信，继续建数据湖。

2019 年，VentureBeat 说 87% 的数据科学项目进不了生产。大家还是不信，继续招数据科学家。

2025 年，IDC 说 88% 的 AI POC 进不了生产。大家依然不信，继续买 Agent 平台。

失败率从 85% 到 87% 到 88%，稳步上升。技术从 Hadoop 到 TensorFlow 到 GPT-5，换了三代。

瓶颈从来不是技术。瓶颈是：你的组织能不能就"收入是什么意思"达成共识。

Data Agent 是一面比大数据更残酷的镜子。大数据时代，数据质量差，最多是报表不准、决策拍脑袋。Data Agent 时代，数据质量差，Agent 会自信满满地基于错误数据给你一个精确到小数点后两位的错误答案，配上一张漂亮的图表，而你还会夸它效率高。

这不是在说 Data Agent 没有未来。恰恰相反——它的未来非常确定。但通往那个未来的路，不是更强的模型、更大的上下文窗口、更花哨的 Agent 框架。

是那个最笨、最慢、最不性感的工作：让产品、财务、营销坐下来，花六周时间，写 30 页指标定义文档。

十年前欠下的数据治理债，现在该还了。