自助分析梦想长期受阻于数据访问、可用性和语义理解。AI（LLM）通过SQL生成、上下文理解和对话界面正实现此梦想。开放数据栈是关键，但仍需解决AI幻觉和可观测性问题。
译自：Self-Service Analytics Failed. Can Agentic AI Finally Succeed?
作者：Alasdair Brown
十多年来，数据行业一直追逐着自助分析的梦想。承诺很简单：让每个人都能访问数据，洞察力就会随之而来。然而在实践中，很少有组织成功。障碍比预期的要高，即使你克服了它们，终点线也一直在移动。
三方面问题
挑战可以分解为三个相互关联的问题。
首先是访问控制。在整个组织中提供受治理、安全的数据访问非常困难。不同的团队需要不同的权限。合规性要求因地区而异。个人数据需要保护。正确实现这一点需要大量的基础设施和持续的维护。
其次是可用性。即使有了访问权限，工具仍然令人望而生畏。直接数据库访问需要精通 SQL。尽管商业智能 (BI) 工具具有可视化界面，但它们并不总是直观的。每个平台都有自己的术语：维度与指标、轴与标签、度量与字段。用户面临数百种具有细微差别的图表类型。学习曲线陡峭，并且这种学习从未真正结束。
第三是业务定义，也称为语义理解。数据存储在哪里？这些列名是什么意思？财务团队如何定义“月活跃用户”与产品团队的定义有何不同？这些机构知识散落在文档、Slack 讨论串和人们的头脑中。让新团队成员熟悉你的数据需要数周或数月的时间。
每一部分都很难。综合起来，它们对许多组织来说都难以解决。
AI 真正有帮助的地方
有些 AI 用例感觉像是为了解决问题而寻找解决方案，但大型语言模型 (LLMs) 解决了分析工作流程中的实际痛点。
- SQL 生成在实践中越来越可靠。LLM 已经广泛用于代码生成，其中也包括 SQL。学习 SQL 的障碍，曾让许多业务用户无法直接访问数据，现在可以大大降低。当然，还有改进的空间。更复杂的查询仍然具有挑战性，不常见的 SQL 方言容易出错。但每一代模型通常都提高了 SQL 生成质量，并在给定强模式和业务上下文线索时增强了推理能力。
- 理解上下文。 就像人类一样，LLM 需要了解它们所交互的系统和数据的上下文。内部系统通常散布着零散的文档，人类很难找到和理解。LLM 已经开发出宽大的上下文窗口，能够搜索和阅读来自各种来源的外部上下文。它们可以为用户带来语义理解，即使是用户自己没有提供这些理解。这并非没有挑战；需要前期和持续的工作来确保元数据存在、保持最新并可供 LLM 访问。
- 聊天界面使交互民主化。 你不再需要掌握 BI 工具的特性。无需滚动浏览图表库。无需与配置面板搏斗。界面是对话式的。输入你想要的内容。说出来。放入一个模型的屏幕截图。表达你的需求，就像请同事构建它一样，而实际上不会占用任何人的时间。
这些进步解决了阻碍数据分析访问的用户面临的实际障碍。
供应商锁定挑战
虽然取得了进展，但挑战依然存在。访问仍然需要治理。工具必须与数据库高效集成。这就是当前格局变得复杂的地方。
许多主要的专有软件供应商提供出色的第一方解决方案。这些解决方案提供了良好的体验，扩展了本机访问控制并使平台更易于访问。它们是在其生态系统内运行的合法解决方案。
但它们并未涵盖所有用例。它们无法与供应商解耦。你无法部署自己的内部 ChatGPT 风格界面，供任何人使用，无论他们是否了解供应商。而且关键是，它们无法跨多个数据源提供统一访问。
多源现实
大多数企业都没有单一的数据提供商。有分析数据仓库、支持主应用程序的运营 PostgreSQL 数据库、支持另一项服务的 MySQL，以及可能潜藏在某处的 Oracle ERP。在数据库之外，Slack 中有对话、Stripe 中有账单信息、Salesforce 中有账户数据。用户经常需要将来自这些来源的运营数据与仓库中的分析数据进行关联。
传统的解决方案？通过将所有内容复制到仓库中来创建“单一事实来源”。实际上，这种方法的成功率与完全自助分析本身大致相同。大多数组织仍然存在数据孤岛。
五年前，数据网格（data mesh）概念承诺通过 Trino 和 Presto 等引擎来解决这个问题：从单一界面查询任何地方的任何数据。它们确实有效，但它们复杂、笨重，并且在访问和可用性方面让我们回到了原点。
MCP 的出现
LLM 和模型上下文协议 (MCP) 提供了一种有趣的替代方案。MCP 服务器不使用凌驾于所有数据层之上的“元引擎”，而是通过一个通用、可互操作的协议暴露几乎任何数据库的原始功能。LLM 不再通过插件将“元 SQL”方言转换为下游语法，而是直接为每个数据库编写本机 SQL。
这是一个优雅的技术解决方案来解决集成问题，但我们不能使用第一方供应商体验来实现它。
开源智能体数据栈
我们需要的是一个开放的数据栈，它能够支持内部构建这些体验，与使用开放协议的任何数据供应商协作，并允许用户通过对话式语言进行交互。
该数据栈包含三个核心组件：
- 数据库层提供大规模实时分析能力。它需要处理高吞吐量、并发查询并具有低延迟。当 AI 代理可以生成比人类分析师多得多的查询时，这一点至关重要。
- 协议层 (MCP) 在 AI 应用程序和数据源之间创建了一个标准接口。开发人员通过 MCP 服务器暴露数据，AI 应用程序作为 MCP 客户端连接。这适用于数据库、文件系统、开发工具、Web API 和生产力工具。
- 聊天界面（如 LibreChat）使用户和组织能够完全控制其数据、代理和对话，同时支持企业级部署。
贯穿始终的关键词是“开放”。开源组件。开放协议。开放标准。这既能防止供应商锁定，又能让组织根据其特定需求进行定制。
实际应用
对于许多已在生产环境中部署这些数据栈的组织来说，这已成为现实。
Shopify 使用 LibreChat 为整个公司的反射式 AI 提供支持。通过近乎普遍的采用和数千个自定义代理，团队连接到 30 多个内部 MCP 服务器，使关键信息的访问民主化。
在医疗保健领域，cBioPortal 使用这个数据栈使癌症研究人员能够对基因组学和治疗轨迹提出全新的问题。正如他们的团队所说，“它让发现触手可及。”
ClickHouse 在内部使用这些系统来构建其 AI 优先的数据仓库，为数百名用户处理大约 70% 的数据仓库查询，并且使用量正在迅速增长。
我们到了吗？
幻觉仍然存在，而且并非总是微不足道的，尤其是当我们向非领域专家用户提供访问权限时。“草莓中有多少个 R？”这个问题已经成为一个反复出现的笑话，并继续在社交媒体上广为流传，成为衡量新发布模型最基本的晴雨表。
表面上看，这听起来像是一个微不足道的问题，但它生动地展示了 LLM 可能引入的问题。我们可能期望的模式是模型生成一个 SQL 查询，将其发送到数据库处理我们的数据，然后模型将输出返回给我们。我们可以验证 SQL 是否正确，并且我们知道数据库会正确执行它。
然而，这给我们留下了一些悬而未决的问题：
- 如果 LLM 让不了解 SQL 的用户能够查询数据库，那么谁来负责验证 SQL 的语义是否正确？
- 用户经常要求模型解释结果。如果一个模型不能可靠地数出“strawberry”中三个 R 的数量，它能可靠地解释你收入数字中的趋势吗？
这可能是将 AI 引入我们的分析中最大的不确定性领域。尽管这些问题似乎随着每一代模型的更新而自然改善，但目前在实践中它们仍需要细心和关注。
在上述实际案例中，实施 AI 平台的团队正使用量身定制的 LLM 可观测性解决方案来监控查询和输出的质量。离线和在线评估允许对这些变量进行评分，使团队能够衡量有效性、检测回归并持续改进系统性能。有效而简单地做到这一点仍然是一个开放的挑战，也是未来最大的改进机会。
这对你意味着什么
开放数据栈具有清晰、实际的优势。
有了像 LibreChat 这样的开放用户体验层，你将获得熟悉的聊天界面，而无需与任何供应商紧密耦合。无论是你的数据库供应商还是 AI 提供商。部署一次，无论你使用 OpenAI、Anthropic 还是 Google 的模型，或者与 ClickHouse、Postgres、Snowflake 或 Oracle 集成，它都能以相同的方式工作。
当界面是对话式的时，学习曲线就会变平。用户无需成为 SQL 专家或 BI 工具的高级用户。他们只需要知道要问什么问题。这大大减轻了支持和技能提升的负担，让构建者能够专注于他们最擅长的事情：构建。
集成依赖于像 MCP 这样的开放标准，而不是特定于供应商的 API。随着 LLM 在生成 SQL 和理解数据上下文方面不断改进，你的数据栈也会自动变得更好。你无需等待供应商更新其专有集成层。
通过开放数据栈，你的数据不会消失在别人的黑箱中。你可以控制分析使用情况、评估答案质量并衡量系统提供的真实价值。这在今天并非一项简单的任务，但你的数据栈仍然开放，可以随着领域的发展而采用新的方法。
最终，你拥有自己的数据栈。你可以随着时间的推移对其进行演进。随着更好选项的出现而更换组件。无需重建界面即可添加新的数据源。无需对新用户体验进行再培训即可更换 AI 提供商。测量和可观测使用情况、性能和消耗。当你构建旨在持续数年而非数月的基础设施时，这种灵活性至关重要。
相同的界面。相同的用户体验。可互换的模型和可插拔的集成。
自助服务没错，只是生不逢时
自助分析的承诺没错。它只是超前于可用于实现它的技术。LLM 并不能解决所有问题，但它们正开始解决此用例的正确问题：代码生成和自然语言接口。
