AI 能否解决数据孤岛挑战？多 AI 代理时代的新挑战。

AI智能体时代的新挑战

AI能否破解数据孤岛难题？多AI智能体时代的新挑战。

从数据孤岛到AI代理孤岛

过去十年，企业一直在与数据孤岛问题作斗争。随着我们进入新的LLM时代，每个人都渴望利用LLM来解决跨数据孤岛的数据检索问题。然而，我们必须考虑这是否会改善现状，还是使其恶化。

在这篇文章中，我们将讨论LLM时代之前企业面临的数据孤岛挑战，以及LLM给数据生态系统带来的新希望，最后，我们将探讨在使用更多垂直LLM代理解决不同场景目的时出现的一些新挑战。

数据孤岛

企业常常面临多个系统和数据库存储不同数据类型的挑战。这些数据孤岛源于遗留系统以及它们之间缺乏集成，导致用户对数据碎片化的视图。这使得数据检索和全面分析变得困难。

如今，公司仍然依赖手动努力或第三方工具来整合和集中来自各个孤岛的数据。这一过程耗时且成本高昂，往往导致数据不完整或不准确。因此，决策基于有限或过时的信息，可能给公司带来损失或错失机会。

数据访问工作流程冗长是由于多样化的数据源和组织复杂性。拥有多个数据源的企业需要不同的技术专家来执行系统集成和开发。随着架构变得更为复杂，维护成本也随之增加。

此外，随着AI、ML、BI和报告等各种数据应用的兴起，技术专家必须处理不同的应用场景和输出格式要求。这意味着数据团队仍然难以跟上数据需求。

LLM能否力挽狂澜？

大型语言模型（LLMs）的兴起展示了机器理解自然语言的能力。这些能力使工程师能够完成卓越的任务，许多人开始考虑利用LLMs来解决长期以来使用自然语言从数据库中检索数据的难题，即“文本到SQL”（Text-to-SQL）。虽然“文本到SQL”的概念并不新鲜，但随着“检索增强生成（RAG）”的引入和LLM模型的进步，现在有机会将LLM的理解能力与RAG技术相结合，以增强对内部数据和知识的理解。

数据孤岛的终结？

现代数据平台如AWS 、Snowflake 、Databricks 、Starburst 和Canner 采用如数据编织 等提议的数据架构解决方案，连接来自各种来源的数据，并采用数据网格架构 ，使业务团队和用户能够独立访问数据。这些创新标准化了跨来源的元数据，并确保领域用户的安全去中心化数据所有权。

克服使大型语言模型理解我们的业务上下文并提供基于上下文的答案的技术挑战，有助于打破数据与知识之间的壁垒。这有可能彻底改变企业运营和决策的方式。

随着更多公司采用这种架构来缓解数据孤岛问题，这是否意味着数据孤岛的终结？我们能否解决前面提到的所有数据孤岛挑战？当然不是。让我们看看为什么。

不同行业与职能中的新兴AI代理

Insight Partners最近的一篇博文，“AI代理正在颠覆自动化：当前方法、市场解决方案及建议” 指出，AI自动化工具、AI代理/副驾驶在过去几个月中蓬勃发展，并认为这将成为未来几年内各行业各部门的新常态。

源、上下文、管理的碎片化设计

该文章还展示了一张架构图，展示了AI代理的设计。通常，一个AI代理包含几个常见组件：用户界面、AI流水线、管理员、数据连接器和语义搜索。

用户界面和AI流水线是大多数AI代理区分的关键；与传统软件开发类似，关于管理、源连接器和存储的大部分逻辑是相似的。

在当今的AI系统中，每个代理都开发其内部的语义上下文、连接和控制，以提供必要的上下文。因此，目前代理无法学习和共享从公司学到的业务逻辑。

这带来了一个新的挑战。

新孤岛 —— AI 代理孤岛

本月，Notion 创始人 Ivan Zhao 在 X 平台分享了他对未来 AI/LLM 革命挑战的看法 。在 AI 时代，不仅数据碎片化，上下文也碎片化。如果使用多个 AI 代理是必然趋势，这可能会为内部运营多个 AI 代理的企业带来新的复杂性。

在即将到来的新 AI 时代，将有一系列新的挑战。一些关键问题包括跨代理的重复访问控制和策略设置。当业务上下文发生变化，例如 KPI 公式的调整，将难以确定哪个代理使用正确的指标或术语来回答用户的问题。最终，AI 代理无法被信任，因为我们无法确定某个代理是否准确理解了我们的问题。

让我们将这一挑战分解为两大类别。

上下文孤岛

代理内部的上下文通常包括用户的角色、权限和偏好等个人特征，以及数据的关系和层次结构等语义上下文。通过识别这些信息，系统可以确保查询返回上下文准确的结果。

然而，在当今的多AI代理架构中，这些信息是分散的，并且在每个AI代理中重复实现，没有任何方法促进彼此之间的通信和信息提取。

接口孤岛

第二个主要挑战是，尽管LLM或AI代理帮助我们应对数据孤岛SQL复杂性（接口）挑战，但每个代理实现与数据源通信的接口方式各不相同；这些细微差别并未向终端用户暴露。然而，每种实现之间的差异可能会使用户对每个代理的行为感到困惑。

我们如何解决这一问题？Wren AI 项目

鉴于当前多AI代理架构面临的两大挑战，我们需要引入一个新层来应对；提供一个表示层，使AI代理能够理解和重用已明确定义的定义，并且当任何语义更新时，所有代理应自动获取最新信息。

AI/LLM 代理的语义引擎 — Wren 引擎

这就是我们启动 Wren 引擎 的原因，它是一款为 AI 代理带来商业语境的语义引擎。AI 代理可以通过 Wren 引擎设置诸如语义关系、策略、访问控制信息、计算与聚合以及商业术语定义等信息，因此当查询请求传递到 Wren 引擎 时，它们将根据不同的用户角色和语义上下文动态生成逻辑计划。

LLM接口表示（LIR）

我们创造了一个新术语，称为“LLM接口表示”（LIR），它位于LLM代理和您的执行引擎之间。LLM代理与用户界面（SQL、API）之间的LIR提供了业务上下文，包括业务术语、概念、数据关系、计算、聚合以及用户访问属性，以供LLM代理和执行引擎使用。

通过这一新设计，我们可以实现以下结果：

1. 向LLMs提供上下文：我们可以向LLMs提供必要的上下文，使它们能够理解业务中数据结构的含义，并根据策略或治理角色设置正确设置访问控制。
2. 逻辑计划生成：当来自不同用户角色和上下文的查询发送时，它将根据LIR中预定义的语义关系、计算、聚合、访问控制和策略动态生成适合执行引擎的正确逻辑计划。

Wren AI 项目

以下是前述概念的一个经过验证的实现。

Wren AI 是一个基于 语义引擎 —— Wren Engine 构建的 LLM 代理；在 Wren Engine 中，我们设计了一种称为 “模型定义语言（MDL）” 的 LIR。

该实现表明，MDL 能够通过 RAG 架构和查询规划阶段预定义的上下文感知层，将上下文传递给 LLM；传递到 Wren Engine 的 SQL 查询将根据不同的用户角色和 MDL 提供的语义上下文动态生成逻辑计划。

访问我们的 GitHub 以了解我们的实现！

开源与标准接口的AI代理

Wren AI项目 已在GitHub上完全开源，任何LLM开发者或用户均可自由托管，作为针对临时和分析用例的AI代理，支持Ollama、OpenAI、Fireworks AI等任意LLM推理端点；Wren引擎可作为开发内外部AI代理的语义引擎。

Wren引擎 旨在构建一个适用于任何AI代理的无感知语义引擎。它遵循两个重要特性：可嵌入性和互操作性。基于这两大设计理念，您可以通过我们的API在AI代理间复用语义上下文，并自由连接您的本地和云数据源，完美融入您现有的数据架构。

感谢Jimmy Yeh 和Yaida Colindres 对本文进行审阅并提供反馈！

👉 GitHub: https://github.com/Canner/WrenAI

👉 X: https://twitter.com/getwrenai

👉 Medium: https://blog.getwren.ai/

如果您喜欢这篇文章，请不要忘记在GitHub上给⭐ Wren AI点个星⭐ ，一如既往，感谢您的阅读。