数据曾被誉为新的石油，但这种说法正在演变。随着人工智能的兴起，算力已经成为企业推动创新和成功的关键资源。生成式人工智能所涉及到知识工作和创造性工作的领域，如果生成式人工智能可以让这些人至少提高 10% 的效率和 / 或创造力，他们不仅变得更快、更有效率，而且比以前更有能力。因此，生成式人工智能具有创造数万亿美元经济价值的潜力。

显然，与先前发明的相似之处和潜在影响是确定的。与互联网和移动电话的进行比较，人们希望通过这种比较来捕捉这种新技术的诱惑力和时刻。

那么人工智能将如何影响 “知识工作” 呢？尤其是数据分析在短时间内经历了快速增长，引发了人们对数据分析所提供价值的质疑。这导致人们越来越希望有更好的标准和工具来满足交付价值的需要，采用软件工程实践为数据分析带来了长足的进步。引入人工智能这样的新变量似乎令人望而生畏，并伴随着过多的考量。然而，将人工智能整合到一家公司的数据战略中是至关重要的，忽视它将错失良机。

1. 关于数据分析

数据分析市场增长迅速，并继续增长，预计到 20302 年，北美市场的复合年增长率将达到 27.3%

在数据科学和数据分析学位出现之前，从其他分析领域过渡到数据分析要容易得多，例如物理，数学，会计，经济等等。但在过去的几年里，情况已经发生了根本性的变化。高等教育学位的增长反映了人们对这个领域的兴趣，数据科学学士学位增长了数倍。

从广义上看，数据分析由来已久，例如，会计和财务就是分析性很强的领域，在向公众报告有关公司财务状况的指标时有严格的定义和规定。现代意义上的数据分析满足了从有限信息中获取尽可能多信息的愿望，并提出了一系列挑战，需要与传统软件工程不同的思维方式。虽然软件工程创建的代码片段是确定的，并且可能是幂等的，但是数据流水线可以并且确实会随着数据采集过程的变化而变化。

数据分析需要与软件工程类似的标准，但需要新的工具。这就是为什么当数据网格出现时，它引起了数据社区的共鸣，让人想起了软件工程的敏捷宣言。数据网格解决了分散在整个组织中的不可信和分散的数据这一痛点。联邦产品所有权的想法也很诱人，由于集中的提取 - 转换 - 加载 (ETL) 过程已经变得过于繁琐和迟缓，以至于无法快速满足组织的分析需求。

这引发了对从 ETL 到 ELT 的转换，其中数据转换是最后一步，由数据分析师或分析工程师负责。以获得授权的数据团队创建自己的数据模型，而不是依赖数据架构师来构建，这减少了数据消费端等待获取数据的时间。

然而，随着速度的提高，来自多个来源的数据表也随之增多，需要考虑将数据呈现给最终用户的 “最终负载”。ETL 流水线通常直接采用可视化工具 (如 Tableau或PowerBI等) 或电子表格，而不是作为建模数据返回到数据库。

考虑到向用户交付最终价值通常需要最后的负载，一个更准确的缩写词可能是 ELTL，还需注意的是最后一次加载之前的数据治理步骤。

2. 数据治理、数据建模和语义层

忽略数据治理而直接交付给业务用户的数据会引起许多问题。在用户比较仪表盘时，并意识到相似的指标可能产生了不同的结果。错误会呈现在最终的产品中，因为测试并没有得到足够的重视。这与软件工程不同，在软件工程中，测试是质量的保证。随着数据分析领域的成熟，软件工程已经经历的这种坑正在重复。

为了提高准确性，人们尝试使用数据的语义层。语义层定义了公共度量，以确保整个组织的数据一致性。这是数据分析领域添加更多数据治理的重要改进。此外，还出现了许多强调数据目录的数据治理解决方案。而今，我们有了更多的工具，强调了与传统数据分析不同的软件工程原则。

那么，AI会应用到数据分析领域的哪些方面呢？典型地，AI正被应用于数据分析的最后一个 “加载” 环节，即电子表格、可视化和数据库中的人工智能。这些数据加载很重要，但是更重要的是在数据仓库建模上添加 AI。

如果没有AI辅助的数据建模和数据治理，整个方案很可能会失败。

2.1 精确分析

对数据建模的重新强调似乎令数据分析领域形成了闭环。到目前为止，流程中的差异已经允许数据团队在创建表格方面拥有比以前更多的自主权，将数据传递给业务用户的速度有了明显的提高，但还是太慢了。数据团队是一个瓶颈，向仪表盘添加新的过滤器并不总是向最终用户提供信息的最佳方法。

这实际上在重复过去的错误，也就是说，这个错误就是大规模的数据生成无需考虑数据治理。这就是为什么最成功的AI数据应用程序将包括数据治理。数据治理不是可选项，而是提供一个可靠的人工智能Data Agent的本质特征。

因此，我们需要添加 AI能力来提高速度，改善对数据建模和数据治理的依赖，提升元数据和文档实践。本质上，人们需要需要精确的信息。有些仪表盘存在一个组合问题，太多过滤器和许多不同的选项导致有太多的视图，以至于很难对其进行排序。AI的能力几乎可以即时访问数据并获得新的见解。这种能够精确得到人们所需要的东西的能力称之为 “精确分析”。“有了这么多可能的数据和度量的组合，精确分析允许AI根据用例对数据进行正确的转换。

2.2 数据对象

单个查询结果的数据单元可以视为 “数据对象”。使用 AI，用户可以生成许多不同的、唯一的数据对象，这些数据对象与仪表盘在不同：

它们更容易访问和比较。
比较数据对象的能力是内置的。

数据对象也被称为数据产品和数据模型，我们可以使用数据对象作为任务名称来描述响应用户的提示词查询。

数据对象目前被定义为以下三种：度量 (1 行和 1 列)、记录 (1 行和多列) 和数据集 (多行和多列)。建立数据类型有助于更容易地组织和共享数据，并定义如何组织数据对象。

当前的AI能力和可靠性的改进之间需要达到一个权衡。目前的AI能力很大程度上依赖于一个文档化的语义层。这个语义层建立在数据库中关于表的元数据之上。需要对这些表进行建模，并描述它们彼此之间的关系。AI可以帮助发现这些关系，但需要人工确认这些关系。

所有元数据之所以重要是因为AI需要上下文，一般的AI系统通过 RAG 来构建。再将数据发送到正在使用的 AI 模型之前，RAG 允许检索上下文并将其放入提示词中。

为了提高这些系统的准确性，需要通过一些检查机制来构建工作流，例如：主键和连接的检查。这不仅使 AI 的输出得到改进，而且令 SQLMesh 这样的工具更容易地与审计的输出集成。在 SQLMesh 中，定义行列组合被称为 “grain”，连接关系被称为 references。这些原型允许AI系统建立护栏，并提高 RAG 的精度。

3. AI 驱动的数据分析

我们能够利用AI来解决数据领域的一些基本问题。现在有很多工具可用，要么提供可以与数据集成的解决方案，要么提供可以从头开始构建的方案。AI驱动的数据分析方案大致分为两个方向：查询来自数据库或文档等来源的数据和从已经存在的报表中检索数据。

3.1 从现有数据源检索数据的 AI

这些工具在分析报告的数据目录之上构建一个Data Agent。与原始数据源相比，从已经存在的报表中检索数据的缺陷是报表之间的不一致。我们可以专注于查询数据并作为一个坚实的起点，然后在此基础上构建现有报告的检索。我们也可以只专注于从现有来源检索，并不试图以任何方式转换数据，而是提供已经转换的信息。因此，提供强大的 AI 数据治理和可解释性的工具将蓬勃发展。

3.2 从原始数据查询的AI(如，Text2sql)

Text2SQL 真的可以工作吗？该技术现在对于企业解决方案来说是可行的，可以交付准确和相关的结果。这方面的一个指标是著名的 Text-to-SQL 基准测试Spider 的进展。Spider 基准测试是 WikiSQL 基准测试的继承者，解决了它的一些缺点。当前最佳执行模型的准确率是 91.2% 。另外，人工智能基准常常有错误，某些性能改进可能意味着对基准的过度拟合。作为参考，MMLU 的错误率大约为 9% 。

LLM 的出现使得 Spider 基准测试背后的团队引入了一个名为 Spider 2.0的新挑战。这是一个多步骤的工作流，可以用来测试RAG)工作流的性能。这是一个令人兴奋的新基准测试，有助于展示这些系统在生产环境中的性能。

另外，Text2SQL 需要有适当的护栏来确保结果足够准确，以产生切实的影响。

3.3 信任、幻觉和人机交互

在构建一个成功的Text2SQL 系统时，上下文就是一切。一个常见的问题是，这种准确性是否足以让数据团队放心，可信度会不会被一个不准确的人工智能系统破坏。重要的是要围绕 AI 构建的应用程序，我们需要从一开始就考虑对结果的信任。

除了可信度和元数据之外，还需要向数据团队和业务用户提供控制能力。无论采用何种的形式，所提供的控制必须使双方确信他们了解了信息的来源，并且可以自行审计。一些有利于数据团队的控制方法如下：

当AI没有足够的信心能够回答一个问题时，需要通知数据团队，以便将该问题转发给他们。
能够审计的 SQL 查询和AI的思考方式，以获得其最终答案

业务用户也需要通过以下方式实施控制：

实时透明地进入AI思维链路
能够将源数据表与最终输出进行比较
通过人机交互，给人工智能提供反馈

所有这些组件都只能在Data Agent结构中使用。在 LangChain 的一篇描述认知架构的文章中，描述了根据能力水平对 LLM 系统进行排名。

未来的Data Agent可能会更善于提出后续问题，在元数据不足的情况下，Data Agent将能够收集这些信息。感知架构不仅使用Data Agent进行查询和检索，还将能够更新由用户反馈的元数据。这个新一代的数据分析方案将创建一个飞轮效应，导致文档的改进和对重要数据指标的更大共识。

最成功的平台仍将依靠人机交互，以提高AI的输出效果。声称Data agent是自主的，导致了一些产品的平庸结果，但是依赖于人机交互的方式则产生了巨大收益。重要的是，我们应该现实地看待当前的AI能力，并建立适当的防护措施。

3.4 数据智能 vs 商业智能

AI 驱动的数据应用所需要的范围比传统的 BI 工具更大。为了AI 方案的成功，治理和控制需要作为解决方案的一部分，而不是事后诸葛亮。数据智能平台超越了传统 BI 平台对可视化的强调，包括：

自然语言通达 (即 “认知层”)
语义编目与发现
自动化管理与优化
加强管治并保护私隐

有越来越多的工具实现 SQL 接口来查询数据，任何可以使用 SQL 查询的数据源都可以被Data Agent使用。通过Data Agent 的 API ，我们可以构建自己的 UI，并向用户提供有价值的见解。

4. AI驱动数据分析的收益

那么，谁能从这样的AI解决方案中受益呢？主要受益者是数据团队和业务用户 (即数据使用者)。

4.1 Data Agent 如何帮助数据团队

Data Agent 通过自动化数据处理、实时监控数据质量、智能数据发现和任务调度优化，帮助数据团队提升效率。它能够自动执行ETL任务，减少人工干预，确保数据准确性；通过机器学习发现数据中的模式和趋势，生成洞察报告；同时优化任务执行顺序，提升资源利用率。此外，Data Agent 还支持团队协作与知识共享，确保数据安全与合规性，为数据团队提供可靠的技术支持，助力数据驱动决策。

问题	对于数据团队
工具构建需要大量的时间，如UI、安全性、可扩展瓶颈、准确性问题等	容易通过接口构建并浏览指标何其他信息，使用API 完成定制
数据消费端的请求多样，容易过载	通过数据飞轮解决复杂问题
仪表盘存在太多过滤器，太多的视图	Data Agent 实现精确分析，按需提供指标信息

4.2 Data Agent 如何帮助业务用户

Data Agent 通过简化数据访问和分析流程，帮助业务用户更高效地利用数据。它提供直观的可视化工具和自然语言查询功能，使非技术用户也能轻松获取所需数据并生成报告。Data Agent 还能自动分析业务数据，识别关键趋势和异常，提供 actionable insights，帮助用户快速做出数据驱动的决策。此外，它支持个性化数据推送，确保用户及时获取与其工作相关的信息，提升业务效率和决策质量。

问题	对于业务用户
用户又太多选项来访问数据，学习成本较高	通过自然语言使用 Data Agent 访问原始信息和数据库，
用户不能直接判断数据源是否可信	Data Agent 通过指标比对的方式完成数据治理，并指出指标之间的差异
部门间存在数据藩篱	Data Agent 能够共享不同团队间的信息
用户希望访问底层数据	Data Agent基于语义层来实现数据的准确性和可靠性
在dashboard上增加新的过滤器或视图需要数周的时间	对于ad hoc 请求可以秒级响应

5. Data Agent 的发展趋势

许多产品都在宣传 “专有的AI数据分析师” 或 “专有的AI数据科学家”。然而，未来将是把所有这些数据角色集成到一个或多个Data Agent中。这个Data Agent最终将能够覆盖数据成熟度生命周期的所有方面，包括但不限于：

Ad Hoc 和 Reactive 查询
描述性报道 (“发生了什么”)
诊断报告 (“为什么会发生？”)
预测分析 (“会发生什么？”)
规范性分析 (“如何让它发生？”)

大多数数据分析领域的解决方案都涵盖了数据成熟度生命周期的特定方面。然而，Data Agent 的目标是最终封装数据分析的所有领域，真正为业务交付价值。

【参考资料与关联阅读】

https://www.sequoiacap.com/article/generative-ai-a-creative-new-world/
https://www.insidehighered.com/news/tech-innovation/teaching-learning/2024/01/25/data-science-major-takes-across-college-campuses
https://yale-lily.github.io/spider
Are we Done with MMLU? https://arxiv.org/html/2406.04127v1
https://blog.langchain.dev/what-is-a-cognitive-architecture/
https://www.databricks.com/blog/what-is-a-data-intelligence-platform
知识图谱与向量数据库的相遇
数据分析中10种常见的可视化图例
面向数据产品的10个技能
浅析dashboard的10个实现原则
数据集中的10种变量类型
数据工程师常见的10个数据统计问题
浅析数据工程
数据架构中的数据问题
温故知新：数据科学札记
清单管理？面向机器学习中的数据集
web系统中的结构化数据标记
老曹眼中的面向数据架构
NoSQL 之于大数据
解读向量数据库
在大模型RAG系统中应用知识图谱
让知识图谱成为大模型的伴侣
大模型系列——解读RAG
7B？13B？175B？解读大模型的参数
大模型应用的10种架构模式

本文来自公众号：喔家ArchiSelf