AI数据代理：开启数据智能与分析的惊人新时代！你准备好了吗？

Rifx.Online
Data Science , Predictive Analytics , Technology
12 Feb, 2025

AI如何重塑分析策略

数据曾被誉为新石油，但这一叙述正在演变。随着AI的崛起，计算能力如今已成为企业必须确保的关键资源，以推动创新和成功。红杉资本在阐述潜在影响时毫不避讳地提出大胆的主张，

“生成性AI所涉及的领域——知识工作和创意工作——包含数十亿的工作者。[如果]生成性AI能够使这些工作者的效率和/或创造力提高至少10%：他们不仅变得更快、更高效，而且比以前更具能力。因此，生成性AI有潜力创造数万亿美元的经济价值。”

Sonya Huang, Pat Grady, 生成性AI：一个创意新世界¹

这一大胆的主张是否会实现，目前市场正在验证。不管怎样，与之前的发明和潜在影响之间的相似性是显而易见的。人们在寻找与互联网和手机的出现进行比较时，常常用这种方式来捕捉这一新技术的魅力和时刻。

那么，AI将如何影响“知识工作”呢？数据分析在短时间内经历了快速增长，这引发了关于数据分析所提供价值的问题。这导致了对更好标准和工具的需求增加，以满足交付价值的需要。最近在改善数据分析作为一个职业方面取得了一些进展，例如采用软件工程实践。引入像AI这样的新变量可能看起来令人生畏，并带来了大量的考虑因素。然而，将AI整合到公司的数据战略中至关重要，忽视这一点将是一个错失的机会。我们认为，这样做将加速通过数据分析实现商业价值的过程，释放其全部潜力。

我们是如何走到这一步的

数据分析市场迅速增长，并将继续增长——预计到2023年，该市场将以CAGR 27.3%的速度增长²。

十年前，数据分析，尤其是数据科学专业在大学课程中并不常见。在数据科学和数据分析学位数量增加之前，从其他分析领域转向数据分析要容易得多。专业人士通常会从物理、数学、会计、经济学等多种分析背景转型。

然而，在过去的五年里，形势发生了根本变化。高等教育学位的增长反映了人们对该领域的整体兴趣——国家教育统计中心“报告称最近数据科学学士学位授予量激增968%³，从2020年的84个增加到2022年的897个”。

从广义上讲，利用数据分析并不新鲜——例如，会计和金融是非常分析性的领域，并在向公众报告公司财务状况的指标时有严格的定义和规定。然而，现代意义上的数据分析则满足了尽可能从公司专有信息中获取更多信息的愿望。这种定制化带来了自身的一系列挑战，并需要与传统软件工程不同的思维方式。虽然软件工程创建的代码是确定性的且可能是幂等的，但数据管道可以并且确实会根据数据摄取过程每周发生变化。

行业工具

数据的“流动沙丘”需要与软件工程类似的标准，但需要新的工具。这就是为什么当数据网格出现时，它以一种让数据社区感同身受的方式引起了共鸣，这种感觉让人想起了软件工程师的敏捷宣言⁴。它解决了组织内部不可信和碎片化数据的痛点。联邦产品所有权的理念也很吸引人，因为集中式的提取-转换-加载（ETL）流程已经变得过于繁琐和缓慢，无法快速满足组织的分析需求。

这促使人们强调从 ETL 转向 ELT，由开发者工具如 dbt⁵ 引领，其中数据的转换是最后一步，并由数据分析师或分析工程师负责。这种赋权使数据团队能够创建自己的表，而不是依赖数据架构师构建数据模型，从而减少了数据消费者获取数据的等待时间。

然而，随着这一速度的提高，来自少数来源的表格数量激增。被忽视的方面是考虑“最终加载”，即数据是如何呈现给最终用户的。通常，ETL 管道会直接从转换阶段跳转到可视化工具（如 Tableau、PowerBI 或 Looker）或电子表格，而不是回到数据库作为建模数据。

考虑到通常会有最终加载将最终结果交付给用户，可能更准确的缩写是 ELTL。缺失的环节是这个最终加载之前的数据治理步骤。

数据治理、数据模型与语义层

直接交付给业务用户而不考虑数据治理的数据造成了许多问题。用户会将仪表板相互比较，意识到相似的指标却产生了不同的结果。由于测试并不一定被强调，错误会出现在最终产品中——这与软件工程的单元测试至关重要的情况不同。软件工程已经经历的学习循环在数据分析领域随着其成熟而重演。

为了提高准确性，dbt 提供了测试工作流的方法，并推出了他们的语义层。语义层定义了通用指标，以确保组织内的一致性。这些是开始在数据分析领域增加更多数据治理的重要改进。此外，许多强调数据目录的数据治理解决方案应运而生。最后，我们现在拥有更多工具，这些工具丰富了选项的多样性，并强烈强调与 dbt 竞争的软件工程原则，例如 SQLMesh。

考虑到这些，现在我们有了人工智能，它适合什么呢？人工智能正在被应用于最终“加载”步骤的各个方面——从电子表格、可视化到数据库。所有这些最终加载都很重要，但我们认为最重要的是在数据仓库中建模数据之上添加人工智能。

没有这一点和数据治理，人工智能倡议可能会失败。

语义层和数据模型

在当前的AI能力与可靠性之间，以及对AI不可避免改进的前瞻性规划之间，需要找到一个平衡。根据我们的经验，目前的AI能力在很大程度上依赖于良好记录的语义层。这个语义层是基于数据库中表的元数据构建的。这些表需要被建模，并描述它们之间的关系。AI可以帮助发现这些关系，但当这些关系得到确认时，AI将最为成功。

所有元数据的重要性在于AI需要上下文。典型的Agentic AI系统将使用RAG（检索增强生成）构建。RAG允许在发送给所使用的AI模型之前检索上下文并将其放入提示中。

为了提高这些系统的准确性，需要建立带有多个检查的Agentic工作流，例如：主键检查和连接定义。建立这些不仅可以提高AI输出的质量，还可以使SQLMesh等工具更容易与AI输出的审计集成。在SQLMesh中，定义行的列组合被称为“粒度”，而连接关系是引用⁶。这些基本元素允许构建具有保护机制的AI系统，并提高准确性，超出RAG单独能够实现的水平。

精确分析

这种对数据建模的重新强调将使一些人点头同意我们已经“回归原点”。但这将是过早的，因为到目前为止的过程差异使数据专业人员在创建表格时拥有了比以往更多的自主权。将数据提供给业务用户的速度显著提高。然而，尽管速度更快，这种速度仍然太慢。数据团队是一个瓶颈，在仪表板上添加新的过滤器并不总是获取信息给最终用户的最合适方法。引入AI将使数据查询和检索的时间从某些情况下的几周缩短到几秒钟。

这令人兴奋，但很容易变得自满，重蹈过去的错误。即，允许数据生成的进一步泛滥而不考虑数据治理。这就是为什么最成功的AI数据应用程序将包括数据治理。在我们看来，这不是可选的，而是提供可靠AI数据代理的一个基本特征。

因此，添加AI将提高速度，增强对数据建模和治理的依赖，改善元数据和文档实践。还有其他什么帮助呢？它将帮助充分实现您在需要时获得确切信息的目标。一些仪表板存在组合问题——有许多过滤器和许多不同的选项，导致您永远没有时间去整理所有这些视图。AI正在为公司内部带来谷歌为消费者带来的东西：几乎即时访问您的数据以及最新的见解。我们称这种获取您所需内容的能力为“精确分析”。这个术语的来源借鉴自医疗保健，其中“精准医学”一词指的是能够为某人提供特别定制的治疗。由于数据和指标的组合可能性如此之多，精确分析使AI能够为您提供恰到好处的数据转化，量身定制以满足您的用例。

数据对象

将单个 SQL 查询视为其自己的数据单元，我们称之为“数据对象”。通过 AI，用户可以生成许多不同且独特的数据对象——这些与仪表板有几个不同之处：它们更易于访问和比较。比较数据对象的能力是内置的。数据对象也被称为数据产品和数据模型，但我们暂时使用数据对象作为我们的工作名称，以描述回答用户提示的 SQL 查询。

数据对象目前定义为三种事物之一：一个指标（1 行和 1 列）、一条记录（1 行和多列）以及一个数据集（多行和多列）。建立数据类型有助于更轻松地组织和共享数据，并定义我们如何组织数据对象。

AI数据分析的到来

我们有机会利用AI解决数据领域的一些基本问题。目前已有许多工具可用，这些工具要么提供可以与您的数据集成的现成解决方案，要么是可以从头开始构建的解决方案。AI数据分析解决方案似乎大致分为两个功能组：一组解决方案查询来自您的数据库或文档的数据。另一组是从已经存在的报告中检索数据。我们希望分别探讨这些解决方案，然后解释它们在未来如何结合。

AI解决方案从现有来源检索数据

这些是建立在分析报告数据目录之上的AI代理工具。从已经存在的报告中检索数据的最大缺点是报告之间的不一致。这就是为什么Basejump AI专注于作为坚实起点的数据查询，然后在此基础上构建现有报告的检索。我们的预测是，提供强大AI数据治理和可解释性的工具将会蓬勃发展。

在这里，查询数据的区别非常重要。一些仅专注于从现有来源检索的公司并不试图以任何方式转换数据，而是呈现已经被转换的信息。

从原始数据源查询数据的AI解决方案（即文本到SQL）

文本到SQL真的能起作用吗？如果搜索是任何指标，进展将持续改善。我们认为，这项技术现在已适用于企业解决方案，以提供准确且相关的结果。其中一个指标是朝着著名的文本到SQL基准测试Spider⁷的进展。Spider基准测试是开创性WikiSQL基准测试⁸的继任者，解决了其一些不足之处。在撰写本文时，执行值的最佳模型达到了91.2%。这些高数字可能看起来仍有最后的9%待改善，然而，AI基准测试通常存在误差，超出当前表现的改善可能表明对基准的过拟合。作为参考，MMLU（一个流行的LLM基准）的错误率大约为9%⁹。

LLM的出现使得Spider基准测试团队推出了一个新的挑战，名为Spider 2.0¹⁰。这个更具挑战性的基准目前的高分仅略超过17%。这是一个多步骤工作流程，可用于测试增强检索生成（RAG）工作流程的性能。这是一个令人兴奋的新基准，帮助展示这些系统在生产中的表现。

那么文本到SQL真的能起作用吗？是的，它已经在工作，然而，需要有保障措施以确保结果足够准确，以产生实际影响。有几种方法可以确保这一点，并确保我们对当前进展的状态保持现实。

信任、幻觉与人机协作

在构建成功的文本到 SQL 系统时，背景至关重要。一个常见的担忧是，准确性是否足以让数据团队放心，他们辛苦赢得的信任不会被不准确的 AI 系统削弱。围绕 AI 构建的应用程序是最重要的；从一开始就需要考虑对结果的信任。

对这些模型的当前能力保持现实态度是很重要的。我们发现，当前系统需要良好的数据治理和元数据基础才能成功。AI 数据代理可以与雇佣新的数据分析师进行比较——如果你要求数据分析师计算过去一个月企业获得的潜在客户数量，数据分析师在没有一些背景信息的情况下不知道该去哪里。可能他们会问很多问题以便理清思路。数据代理也不例外——在缺乏良好文档和不存在的元数据的情况下，文本到 SQL 应用程序的批评者证明了他们的观点。它不起作用。然而，对于那些拥有良好定义的模式、最新的元数据以及企业内部术语的业务词汇表的用户而言，代理可以蓬勃发展。

除了信任和元数据的基础外，还需要为数据团队和业务用户提供控制。无论实施形式如何，提供的控制需要让双方都能放心，他们理解信息的来源并能够自行审计。以下是一些对数据团队有益的控制示例：

当 AI 对回答某个问题没有足够的信心时，数据团队需要被通知，以便将该问题转发给他们。
能够审计 AI 提供的 SQL 查询以及 AI 达到最终答案的思路

业务用户也需要对 AI 进行控制，具体包括：

实时透明化 AI 的思维过程
能够比较源表与最终输出
能够作为“人机协作”参与并向 AI 提供反馈

所有这些组件只有在代理架构中才能实现。在 LangChain 的一篇文章中描述认知架构¹¹，提供了一张图表，根据能力水平对 LLM 系统进行排名。

我们在 Basejump 的代理可以被视为状态机（级别 5）。未来的代理可能在提出后续问题方面表现得更好，并且在元数据不佳的情况下，他们将能够收集该信息。成功的架构不仅使用 AI 代理进行查询和检索，这些代理还能够更新由用户反馈丰富的元数据。这一新一代数据分析解决方案将产生飞轮效应，导致文档改进和对重要数据指标达成更大共识。

我们相信，最成功的平台将依赖于人机协作来改善 AI 输出。声称 AI 代理几乎是自主的结果使得产品如 Devin¹² 的结果令人失望，但依赖人机协作的工具如 Windsurf¹³ 和 Cursor¹⁴ 显示出显著的生产力提升。企业对当前 AI 能力保持现实态度并建立适当的保护措施是很重要的。这就是为什么在当前阶段，考虑到人类必须参与以帮助 AI 代理成功，最好将 AI 数据代理称为数据团队的助手，而不是完全的同事。

数据智能与BI平台

成功启动AI数据应用所需的范围比传统BI工具更广泛。为了使AI成功，治理和控制需要作为解决方案的一部分内置，而不是事后考虑。这就是为什么我们更喜欢使用“数据智能平台”或AI数据分析平台这个术语。数据智能平台的一些关键方面超越了传统BI平台对可视化的强调，包括：

自然语言访问（即“认知层”）
语义目录和发现
自动管理和优化
增强的治理和隐私

在Basejump AI，我们采取数据源无关的方法，我们认为这对于工程师发挥他们的最佳能力非常重要——选择合适的技术为用户构建强大的体验。任何可以使用SQL查询的数据源都可以使用，这为我们打开了一个充满可能性的世界，因为越来越多的工具实现了SQL接口来查询数据。我们不仅提供API以在我们的解决方案上构建自己的UI，还提供一个已经准备好的美丽界面，以开始为用户提供洞察。