为何AI Agent需要可组合的数据系统

AI Agent 无法在僵化的模式（schema）和预构建的仪表盘上实现扩展。它们需要可组合的数据系统，这些系统暴露小型、范围明确的数据集、丰富的元数据以及代理可按需组合的接口。

Unix 的发明者足够谦逊，认识到他们无法预测人们想要做的一切。他们也足够聪明，认识到某些模式在多个工作流中是通用的。这些洞察促使他们设计了一个极简的操作系统，提供了必要的原语（primitives），让小巧、锐利的程序能够协同工作。程序员随后可以通过任意组合这些工具来解决最复杂的问题。

人类擅长利用工具。LLM 则更上一层楼。它们能够完美地管理数量级更多的工具。Unix 哲学支撑着新兴的 AI 驱动格局。

另一方面，我们的数据生态系统甚至还没有达到 1969 年 Unix 的成熟度。

关系数据模型的发明者 Codd 发现，将数据分解成连贯的束，并允许用户即时将这些束拼接在一起，是一种提供下游灵活性的非常聪明的方式。关系数据模型似乎是 Unix 工具在数据领域的几乎完美的对应物。可惜的是，并非如此。为了让关系模型大规模工作，需要在这些原本独立的数据束之上强加一个单体结构。在这种情况下，可组合性只是表面上的。

在过去的 50 年里，我们让这种架构为人类工作。它无法扩展以满足 AI Agent 的需求。

从关系孤岛到单体模式

关系数据库是我们第一次认真尝试数据可组合性。带有主键和外键的表为我们提供了一种有条理的方式来关联信息。范式、约束和连接（joins）承诺了这样一种可能性：任何报表都可以通过以正确的方式组合正确的表来构建。

但有一个问题：你必须提前知道关系。模式设计是一种预测行为：

• 哪些实体重要，
• 它们如何关联，
• 我们期望的基数，以及
• 哪些查询必须快速。

外键隐含了对哪些表会被连接的猜测；索引和物化视图编码了对哪些使用模式重要的猜测。

结果是一个悖论。每个表都是自己的孤岛，但群岛被冻结在设计时定义的单一环境中。业务发生变化，你就得回到模式迁移、索引重建和视图重新设计。数据在理论上是“可组合的”，但在实践中，改变组合的成本很高。

OLAP：为人类预组合的数据

OLAP 技术应运而生，以缓解分析工作负载中的一些问题。OLAP 立方体（cubes）和现代变体将数据组织成多维结构：时间、地区、产品、客户等。它们明确针对沿着这些维度进行切片、切块、下钻和上卷进行了优化。

对于其设计目的而言，这很有效：沿着已知维度对已知指标进行快速、交互式的探索。但它带来了相同的预测负担：

• 你必须提前决定哪些维度足够重要，需要在立方体中显式建模。
• 你沿着这些维度预聚合数据，以便人类可以拖拽、拖放、切片和旋转，而不必为每个查询等待几分钟。
• 你在设计度量和层级时，会考虑特定的业务问题。

OLAP 赋予了分析师比在交易数据库上使用原始 SQL 强得多的能力，但最终消费者仍然是坐在仪表盘前的人类。人类一次只能处理这么多维度、过滤条件和边缘情况。整个技术栈——从模式到立方体再到仪表盘——都是围绕“人是思考者”这一假设设计的。

这是预组合的数据：在其边界内强大，在边界外僵化。

LLM 作为数据的语义引擎

当消费者不是人类，而是 LLM 驱动的代理时，可组合性变得更有趣。

我们已经看到 LLM 比专家工程师更好地利用 Unix 风格的工具，仅仅是因为它们能记住和编排的工具比人类多得多。同样的事情也开始发生在数据上。我们可以不问“人类分析师如何理解这个立方体？”，而是问“AI Agent 如何发现并利用跨多个小而不完美的数据集的结构？”

最近在数据发现和语义匹配方面的工作表明，LLM 能够发现传统方法遗漏的关系。它们可以通过查看列名、值和文档来推断语义类型和联系，即使没有显式的外键或共享 ID。将表序列化为文本并利用 LLM 将查询与数据集匹配的技术，有效地将模型视为位于许多松散相关表之上的语义引擎。

换句话说：

• 一个数据集具有丰富的语义标签和本体。
• 另一个只是原始日志或稀疏的交易数据。
• 能够访问两者的 LLM 可以推断它们如何关联，映射列含义，解决命名不一致问题，并识别共享实体。

在 OLAP 预定义连接和聚合的地方，LLM 可以即时发现它们。

这就是数据可组合性：小型、专注的数据池，每个池都有自己的局部逻辑，由 AI 按需拼接在一起，而 AI 的工作记忆能容纳的上下文比任何人类分析师都要多得多。

停止预测，开始组合

这种转变正在影响我们设计数据系统的方式。

数据设计师需要停止试图提前预测每个消费者会用他们的数据做什么。历史上，我们别无选择：预测是获得性能的唯一途径。你过度设计了模式、索引、立方体和视图，因为计算资源和人类注意力都很稀缺。

但我们的消费者正在改变。丰富数据基础设施的主要用户很快将是 AI Agent，而不是人类。这些代理：

• 不介意处理许多小型、专业化的数据集。
• 能够容忍异构模式、命名约定和不完整的文档，只要有足够的信号来推断结构。
• 可以并行发出许多探索性查询，以发现有用的连接和聚合，然后将提炼后的结果呈现给人类。

在那个世界中，数据平台的工作不是“预测每个查询”，而是“使任意组合变得廉价”。这推动我们走向一个新的范式：即时优化。

不是：

• 预构建我们能想到的每个视图和立方体。
• 将我们的数据锁定在僵化的仓库层级中。

我们应该致力于：

• 暴露小型、范围明确的数据集，具有清晰的语义和血缘。
• 提供丰富的元数据、文档和示例查询，LLM 可以消费。
• 构建能够根据代理的声明式意图按需实例化优化视图的基础设施。

代理应该能够说：“我需要这些地址的钱包活动的时间序列视图，并附带协议元数据和风险评分”，然后平台能够组装、优化并提供精确的结果，而不是强迫代理手动拼接十个原始表。

这与我们在 Unix 中看到的模式相同：不要过度指定工作流；只需确保原语能够干净地组合。

再次向 Unix 学习

最初的 Unix 设计者拥有一个我们如今才重新发现的优势：他们假设自己不知道用户想做什么。因此，他们没有预先构建庞大的、特定用途的应用程序，而是专注于少量的设计原语——文件、文本流、进程和管道——并让将它们连接在一起变得微不足道。

相比之下，大型机和 VAX 操作系统通常将权力集中在大型子系统和紧密耦合的工作流内部。环境对使用模式做了很强的假设，因此改变这些模式的代价很高。

如今，数据基础设施看起来更像大型机，而不是 Unix。仓库、立方体和仪表盘编码了许多关于数据将如何使用的假设。当这些假设发生变化时（它们总是会变），就要在迁移、重新建模和脆弱的集成中付出代价。

可组合性的教训与以前相同：

• 保持单元小巧且专注：代表清晰概念的数据集，而不是巨大的反规范化数据块。
• 投资于简单、一致的接口：人类和 LLM 都能理解的模式、合约和元数据。
• 为组合而设计，而非预测：假设你不知道未来的代理会做什么，但给他们执行几乎任何事情的元语。

可组合性赢过一次，当我们将其应用于工具时。它即将再次获胜，当我们将其应用于数据时。

这对区块链数据意味着什么

区块链数据已经分散在合约、链、事件、追踪、代币标准和特定于应用的状态中。

对于人类用户来说，这种碎片化通常隐藏在仪表盘、API 或预构建视图之后。对于 AI Agent 来说，这种模式是不够的。代理需要实时发现、组合和推理多个小数据集。

这使得可组合性成为一个数据基础设施问题。

区块链数据的未来不是一个单一的、包罗万象的、能够预测所有问题的模式。而是一个由范围明确的数据集、清晰的语义、可靠的元数据和查询接口组成的系统，随着新工作流的出现，这些可以组合成新的工作流。

这就是我们如何看待 Ormi 在数据栈中的角色：使区块链数据足够快速、可靠和结构化，以便应用程序和代理在其上构建，而无需将每个用例强制塑造成相同的形状。

• 原文链接： blog.ormilabs.com/why-ai...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～