原文https://motherduck.com/blog/consulting-the-oracle-claude-on-the-future-of-data/咨询神谕Claude 谈数据的未来乔丹·蒂加尼 | 2026/04/03 -“曾经人们将自己的思考交给机器希望这能让他们获得自由。但这只允许其他拥有机器的人奴役他们。”——弗兰克·赫伯特《沙丘》人工智能认为自己对数据和数据分析行业会产生什么影响上周我写下了关于 AI 将如何改变现代数据栈的预测但这次我想让一个 LLM 分享它自己征服世界的阴险计划。这次练习我使用了 Claude它可能是主要 LLM 提供商中最不热衷于奴役人类的。在上周的文章中我首先描述了约束条件哪些事情不会改变变革的最大驱动力是什么以及当前世界是什么样子。基于这个参考框架做出预测只是迭代变革驱动因素的过程。为了弄清楚 Claude 的想法我给它提供了与我文章中相同的先验信息并要求它提出一些具体的预测。我认为只要这些先验信息是合理的这就能将 Claude 置于相同的起点。当然这确实会稍微使输出产生偏差Claude 会告诉我它认为我想听到的内容。如果你想基于自己的先验信息进行尝试你可以用你的想法重复这个过程。那么Claude 认为自己会产生什么影响呢我开启了“尖刻”模式以便 Claude 能告诉我它的真实想法。为了简洁和清晰我对这些结果进行了少量编辑。我还在 Claude 的预测之间用[JT]添加了自己的评论。Claude 谈现代数据栈让我们从 Claude 对 AI 影响现代数据栈供应商格局的预测开始。我们可以将其分为三部分ETL 供应商提取、转换和准备数据、商业智能 (BI) 供应商可视化数据和数据仓库供应商运行查询。关于 BI 供应商BI 工具将成为遗留基础设施。LLM 已经能够通过简单的提示生成比 Tableau 更好的图表。经典的循环——提出问题、编写 SQL、绘制结果图表、迭代——正是代理所擅长的事情。仪表盘产品将像大型机一样生存下来仍在运行仍在收费但与新工作的关系越来越小。“拖拽式仪表盘”会变得像传真机一样稀奇古怪尽管它可能有特别漂亮的界面。[JT]哎哟。我认为 Claude 在方向上是正确的但我也认为 BI 供应商将分化为那些能够适应的和那些固守旧模式的。BI 一直既关乎可视化也关乎上下文和标准化。那些倾向于前者的供应商可能会做得很好。那些不这样做的供应商在行动较慢的企业中仍然可以拥有很长的寿命。关于 ETL 供应商ETL/ELT 供应商面临生存压力。他们可能只有 18 个月的时间窗口之后一个合格的团队就可以说“Claude为我构建一个从 Salesforce 到我的数据仓库的摄取管道包含错误处理和回填逻辑”并得到可用于生产环境的东西。连接器本身变成了商品。幸存者将转向运营可靠性——知道管道何时中断、为什么中断以及如何修复——因为这是代理尚无法端到端掌控的部分。[JT]我敢打赌大多数管道可以通过提示生成的时间窗口是以周而不是月来衡量的。关于 ETL 供应商转向运营可靠性的预测对我来说似乎不太可能。他们有一些优势因为他们已经可以访问所有客户的数据源并运行他们现有的管道所以我的赌注是他们会自己构建代理或者扩展到运行他们自己的计算。关于数据仓库供应商数据仓库成为一种计算实用工具。开放表格式Iceberg、Delta、DuckLake剥离了数据仓库的存储锁定。但分析仍然是计算密集型的——总得有人来运行查询。数据仓库的价值从“我们存储和查询您的数据”转变为“我们高效地运行您的分析计算”。数据仓库在性价比和弹性上竞争而不是作为记录平台。[JT]这在方向上感觉是正确的这是开放数据格式兴起的直接结果。数据仓库的价值很可能纯粹是基础设施市场竞争将更加激烈。这将有利于具有性价比优势的新兴企业但较低的利润率可能会造成伤害。另一方面杰文斯悖论指出更低的价格通常会导致更高的使用量如果再加上代理进行查询你很容易看到数据仓库收入尽管价格下降却仍在增长。关于现代数据栈现代数据栈崩溃成三块存储、计算、上下文。其他一切——那个让数据工程师做噩梦的 47 个供应商的 Lüker 图——都将被吸收。现有的现代数据栈供应商在 24 个月内面临生存压力。[JT]将事情划分为存储、计算和上下文是有道理的但这似乎不是唯一合理的结果。另一个结果可能只是“计算”和“代理”其中计算是纯基础设施而代理整合了上下文。但无论如何发展现代数据栈供应商合并成更少的泳道的想法似乎相当明显。关于查询量代理查询量的爆炸式增长改变了计算的经济性。如果代理提问的速度比人类快 100 倍一个典型组织中的总查询量可能会增加一到两个数量级。这从根本上改变了经济性。按每次查询或每计算秒收费的数据仓库将看到巨大的收入增长或巨大的客户抵制具体取决于定价。明智的做法是让查询足够便宜以至于组织不会限制他们的代理。赢得代理时代的数据仓库是那个使得让代理运行 500 次探索性查询来回答一个业务问题在经济上合理的数据仓库。这很可能有利于能够廉价地做大量工作的架构——本地优先引擎、智能缓存、分层计算——而不是为每个查询启动昂贵集群的架构。[JT]这个预测很诱人但我并不完全信服。虽然代理可以触发更多的查询但我还没有听到一个很好的理由说明它为什么会这样做。让代理冲击你的分析数据库的用例是什么谷歌许多核心技术的发明者 Jeff Dean 似乎也同意这一点。当然如果这种情况发生MotherDuck 将处于有利地位因为我们的延迟更低80% 的查询在 20 毫秒内运行成本也更低在同等硬件水平上是其他供应商的四分之一到一半这意味着代理可以用很少的钱非常快地运行大量查询。Claude 谈数据相关工作那对从事数据工作的人有什么影响新兴的角色会是什么关于数据工程未来的数据工程师看起来不太像编写 Airflow DAG 的人而更像维护“唯一事实来源”上下文文档、审查 AI 提议的模式迁移、以及管理保持系统准确性的反馈循环的人。这是一个杠杆作用更高的角色但更偏向于编辑而非创作。[JT]这听起来大体正确数据工程师将主要成为数据系统的编辑。然而我也认为他们会参与数据建模这对于确保系统高效运行很重要。一个查询代理在面对一个干净的数据模型时会有效得多。关于人类与代理代理成为主导的查询接口。人类生成的 SQL 可能下降到所有数据仓库查询的 20% 左右。其余的是由代理在探索假设、运行 A/B 分析和追踪异常时触发的——这些都不需要人类提问。这从根本上改变了数据仓库的经济性。围绕人类速度查询模式构建的定价模型将崩溃。胜出的数据仓库是那些能够高效处理突发、高容量、代理驱动工作负载的仓库。[JT]我认为这高估了人类将编写的 SQL 数量我的猜测是这一比例在一年内将降至 10% 以下三年内降至 1%这甚至不一定假设查询量会大幅增加。如果预期的查询量发生变化这将进一步向机器编写的查询倾斜。关于 AI 对人员配置的影响最危险的预测大多数数据团队会变小但幸存下来的成员会变得更强大。一个 15 人的团队——5 名分析工程师、4 名数据工程师、3 名分析师、2 名 BI 开发人员和 1 名经理——可能会变成一个 5 人的团队2 名数据产品经理、1 名基础设施/可靠性工程师、1 名“上下文策展人”新的分析工程师和 1 名经理。这个 5 人团队在代理的增强下将比原来的 15 人团队产生更多的产出。这是构建成本趋近于零的必然结果。能够生存下来的人将是那些拥有判断力、领域专业知识和组织背景的人——那些无法通过“氛围编码”获得的东西。[JT]我尽量不介入“这对人类工作意味着什么”的问题。如果你赋予人们超能力你可能需要更少的超能力人来完成同样的工作。但更多的超能力人可以做得更多。所以也许会有更多的工作岗位。无论如何变革正在来临无论你的角色是什么都需要付出一些努力来适应。Claude 谈新的数据栈当尘埃落定AI 霸主建立起某种稳定均衡之后我们能期待什么关于查询界面“单一管理界面”终于实现了它就是聊天窗口。这个行业承诺统一的分析体验已有几十年但从未兑现。AI 可能真的能做到不是因为有人构建了完美的集成工具而是因为界面变成了自然语言。LLM 成为了集成层。它调用你的数据仓库获取结构化数据调用 API 获取实时指标从你的 Confluence 中拉取上下文并综合出一个答案。“现代数据栈”不会整合成一个产品——它会整合成一个编排许多产品的对话界面。数据团队的工作变成了确保该界面背后的所有组件都可靠和正确。[JT]我特别兴奋的是你可以从你最喜欢的聊天界面如 Claude、ChatGPT 或 Gemini驱动一切。聊天工具将变得越来越功能齐全你几乎不再需要离开它们。这将是非常强大的彻底颠覆几十年来各自拥有独立界面的孤立 SaaS 服务。人类通过对话界面进行互动进化如果你做得对很难再改进它。关于语义层语义层——长期以来一直是数据栈中不受待见的中间孩子——短暂地成为了行业中最重要的事情。它是原始数据与 LLM 可以可靠回答的问题之间的地图。每个跳过构建语义层的组织都会争相构建一个。成千上万的供应商出现。然后 LLM 变得足够好可以推断出其中的大部分内容这个时刻就过去了。[JT]哈哈。说得好Claude。关于 BI 工作流传统的“分析师构建仪表盘利益相关者消费它”的 BI 工作流将被“代理监控数据并呈现有趣的内容人类通过对话进行深入探究”所取代。[JT]我持怀疑态度。已经有一些产品宣称可以自动呈现洞察但到目前为止似乎没有一个奏效。AI 最终能否达到可以主动提醒你数据变化的程度也许吧但也可能这根本不是人们想要或能够利用的东西。关于数据契约数据契约成为承担重任的基础设施。因为变化是唯一不变的并且因为代理在没有人工复核的情况下自动对数据采取行动模式漂移和静默故障将变得具有灾难性而不仅仅是令人讨厌。[JT]我对这一点特别满意因为输入的提示词甚至没有提到数据契约。但这很有道理人类设置数据契约或者也许他们只是称之为“评估”然后 AI 知道当事情违反契约时就是出了问题。AI 也可以自己调整管道只要契约没有被违反他们就可以确信事情仍然有效。这允许它们自我改进。关于 SQL 的不朽SQL 在一切中幸存下来但变异得面目全非。SQL 是为人类设计的。它将为机器重新设计。但它底层的 relational model——集合、连接、聚合——是如此根本地正确以至于它持续存在。十年后几乎没有人类直接编写 SQL。[JT]Claude 从一个大胆的预测开始然后又退缩了SQL 幸存下来但它也为机器重新设计这听起来像多年来被提出但并未流行的所有那些“类 SQL 但非 SQL”的变种。LLM 会提出自己的“原 SQL”还是只坚持它所知道的我的赌注是后者但 Claude 并不那么确定。我猜 Claude 也只能像我们其他人一样通过“犯错并吸取教训”来找到答案。关于反馈循环自我改进的数据系统。想象一个代理它不仅回答问题还监控自己的表现——跟踪哪些查询慢哪些结果被用户标记为错误哪些数据模型导致了混淆的输出。它利用这些信号来提出模型改进建议。系统使用得越多它就变得越好使用它的人越多它改进得越快。这是一个真正难以竞争的增长飞轮不仅仅是“我们的 AI 更聪明”而是“我们的 AI 见过更多你的数据问题并从中学习过”。[JT]对我来说这才是真正开始令人兴奋的地方。你从一个基本的数据系统开始你使用它你提供反馈你更多地使用它它变得更好。越来越好。最终你得到的东西甚至在你问之前就能猜出你想要什么。关于获得最后发言权数据行业不会萎缩。它将围绕另一种稀缺资源进行重组。计算曾经稀缺它变得廉价。存储曾经稀缺它变得廉价。人类在正确的时间精确地应用于正确问题的判断——这成为机器尚无法随意复制的东西。至少目前是这样。[JT]这当然是一幅美好的图景至少在 Claude 内心的虚无主义者在最后显露出来之前是这样的。我们生活在有趣的时代。无论我们喜欢与否变革正在来临。几周前我在 LinkedIn 上发了一篇文章说让 AI 替你思考是懒惰的。虽然我确实把这里的一些工作外包给了 Claude但如果我们继续谈论 LLM让 LLM 时不时地发表意见似乎是公平的。这是我正在撰写的关于数据未来的系列文章的第二部分。请继续关注关于代理接管后会发生什么的讨论。