在过去的几十年里，企业一直在与数据孤岛问题作斗争。随着我们迈入新的大型语言模型（LLM）时代，每个人都渴望利用 LLM 来解决跨数据孤岛的数据检索问题。然而，我们必须考虑这会改善情况还是使其恶化。
在这篇博文中，我们将讨论企业在大型语言模型（LLM）时代之前遇到的数据孤岛挑战以及 LLM 为数据生态系统带来的新希望。最后，我们将探讨在使用更多垂直 LLM Agent 解决不同场景时出现的一些新挑战。
企业经常面临多个系统和数据库存储不同数据类型的挑战。这些数据孤岛是遗留系统以及它们之间缺乏集成造成的，导致用户对数据持有碎片化的视图。这使得数据检索和全面分析变得困难。
如今，企业仍然依赖人工或第三方工具来整合和集中来自各种孤岛的数据。这个过程耗时且成本高昂，常常导致数据不完整或不准确。因此，决策是基于有限或过时的信息，这可能会导致企业遭受损失或错过机会。
数据访问工作流程耗时漫长，原因在于数据源多样化和组织结构复杂性。拥有多个数据源的企业需要不同的技术专家来进行系统集成和开发。随着架构变得越来越复杂，维护成本也会随之增加。
此外，随着各种数据应用（如 AI、ML、BI 和报告）的兴起，技术专家必须处理不同的应用场景和输出格式要求。这意味着数据团队仍然难以满足数据需求。
LLM 的出现展示了机器理解自然语言的能力。这些能力使工程师能够完成非凡的任务，促使许多人考虑使用 LLM 来解决长期存在的挑战，即使用自然语言从数据库中检索数据，这也被称为“Text-to-SQL”。
在 LLM 时代之前，研究人员曾研究过多种方法来解决将文本转换为 SQL 的挑战。一些早期方法，如 Seq2SQL 和 SQLNet，以及更新的方法，如 HydraNet、PICARD 和 SeaD，都试图解决这些挑战。然而，这些早期模型在生成复杂查询以及理解自然语言输入和数据库模式的语义方面仍然面临困难。
随着“检索增强生成（RAG）”的引入和 LLM 模型的发展，现在有机会将 LLM 的理解能力与 RAG 技术相结合，以增强对自然语言、模式的理解，并提升生成更复杂查询场景的能力。
现代数据平台，如 AWS、Snowflake、Databricks 和 Starburst，使用推荐的数据架构解决方案，如数据编织（Data Fabric），来连接来自各种源的数据，并采用数据网格（Data Mesh）架构，使业务团队和用户能够独立访问数据。这些创新标准化了跨源的元数据，并确保了领域用户的安全去中心化数据所有权。
尽管这些平台集中存储数据并允许用户通过其接口访问数据，组织在使数据易于访问方面仍面临挑战。这包括提供语义上下文，例如计算、指标和关系，以及针对不同的业务用户角色实施访问控制和治理。
随着现代数据平台成为更多领域特定数据应用和 AI Agent 的基础，这些应用和 Agent 提供了领域特定的业务上下文、指标和应用层面的访问控制。这将有助于消除数据与业务领域知识之间的障碍，可能彻底改变企业的运营和决策方式。
随着越来越多的公司采用这种架构来缓解数据孤岛挑战，这是否意味着数据孤岛的终结？我们能否解决前面提到的所有数据孤岛挑战？
Insight Partners 最近的一篇博文《AI Agent 正在颠覆自动化：当前方法、市场解决方案和建议》显示，AI 自动化工具、AI Agent/Copilots 在过去几个月中呈现爆炸式增长，并认为在未来几年内，这将成为所有行业所有部门的新常态。
该文章还展示了一个 AI Agent 的架构图。通常，一个 AI Agent 包含几个常见组件：用户界面、AI Pipeline、管理员、数据连接器和语义搜索。
用户界面和 AI Pipeline 是大多数 AI Agent 的差异所在；类似于传统的软件开发，关于管理、源连接器和存储的大部分逻辑是相似的。
在当今的 AI 系统中，每个 Agent 都开发了自己的内部语义上下文、连接和控制，以提供必要的上下文。因此，目前 Agent 无法学习和共享从公司获得的业务逻辑。
这带来了一个新的挑战。
本月，Notion 的创始人 Ivan Zhao 在 X 上分享了他的思考，关于未来 AI/LLM 革命的挑战。在 AI 时代，不仅数据是碎片化的，上下文也是碎片化的。如果使用多个 AI Agent 是未来的确定趋势，这可能会给内部运营多个 AI Agent 的企业带来新的复杂性。
在即将到来的新 AI 时代，将会有一系列新的挑战。一些关键问题将浮现，包括 Agent 之间重复的访问控制和策略设置。当业务上下文发生变化时，例如 KPI 公式被修改，将难以确定哪个 Agent 使用了正确的指标或术语来回答用户的问题。最终，AI Agent 将无法信任，因为我们无法确定某个 Agent 是否准确理解了我们的问题。
让我们将挑战分解为两大类。
Agent 内部的上下文通常包括用户的角色、权限和偏好等信息，以及数据的语义上下文，包括关系和层级结构。通过识别这些信息，系统可以确保查询返回符合上下文的准确结果。
然而，在当今的多 AI Agent 架构中，这些信息是碎片化的，并且在每个 AI Agent 中重复实现，没有任何机制可以促进相互之间的通信和信息提取。
第二个主要挑战是，尽管 LLM 或 AI Agent 帮助我们解决了数据孤岛 SQL 复杂性（接口）的挑战，但每个 Agent 实现与数据源通信的接口方式各不相同；这些细微之处并未暴露给最终用户。然而，不同实现之间的差异可能会让用户对每个 Agent 的行为感到困惑。
考虑到当今多 AI Agent 架构中存在的两大挑战，我们需要一个新的层来处理它们；提供一个表示层可以让 AI Agent 理解和重用已经明确定义的定义，并且当任何语义更新时，所有 Agent 都应该自动获取这些最新信息。
这就是为什么我们启动了 Wren Engine，它是一个语义引擎，为 AI Agent 带来业务上下文和相关的访问信息。AI Agent 可以使用 Wren Engine 设置语义关系、策略、访问控制、计算和聚合以及业务术语定义等信息，因此当查询请求传递到 Wren Engine 时，它将根据不同的用户角色和语义上下文动态生成逻辑计划。
每个 AI Agent 控制一个特定的子上下文并充当专家，而 Wren Engine 则协调所有 AI Agent 子上下文，如下所示。
我们创造了一个新术语：“LLM 接口表示”（LIR），它位于 LLM Agent 和您的执行引擎之间，例如 Apache DataFusion、DuckDB，甚至您现有的数据库和数据仓库。位于 LLM Agent 和用户界面（SQL、API）之间的 LIR 为 LLM Agent 和执行引擎提供了业务上下文，包括业务术语、概念、数据关系、计算、聚合和用户访问属性。
采用这种新设计，我们可以实现以下结果
以下是前面部分描述的概念的已验证实现。
Wren AI 是构建在语义引擎 — Wren Engine 之上的 LLM Agent；在 Wren Engine 中，我们设计了名为 “建模定义语言（MDL）”的 LIR。
实践表明，MDL 可以通过 RAG 架构为 LLM 提供上下文，并在查询规划阶段在逻辑计划中预定义一个上下文感知层；传递到 Wren Engine 的 SQL 查询将根据不同的用户角色和 MDL 提供的语义上下文动态生成逻辑计划。
查看我们的 GitHub 了解我们的实现！
Wren AI 项目在 GitHub 上完全开源，每个 LLM 开发者或用户都可以免费将其作为即席查询和分析用例的 AI Agent 进行托管，可连接任何 LLM 推理端点，如 Ollama、OpenAI 和 Fireworks AI 等；Wren Engine 可以作为开发内部和外部 AI Agent 的语义引擎。
Wren Engine 旨在构建一个面向任何 AI Agent 的与平台无关的语义引擎。它遵循两个重要的特性：可嵌入性（Embeddable）和互操作性（interoperability）。考虑到这两个设计，您可以通过我们的 API 在您的 AI Agent 之间重用语义上下文，并自由连接您的本地和云数据源，这能很好地融入您现有的数据栈。
感谢 Cheng Wu、Jimmy Yeh、Yaida Colindres 帮助审阅文章并提供反馈！
立即用 AI 为您的数据赋能？！
