Berkeley研究指出AI推理成本已跌至$0.1/百万token,讨论低成本智能对系统架构和数据设计的影响。
……民有、民治、民享的政府……——亚伯拉罕·林肯,《葛底斯堡演说》(1863 年)
AI 的成本正在迅速下降。2023 年初,GPT-4 级能力的成本约为每百万 token 30 美元;如今,同等能力的成本已低于 1 美元,一些提供商甚至将其压低至 0.10 美元以下。从各项基准测试来看,推理价格每年下降 9 倍至 900 倍,中位降幅接近 50 倍。即使是前沿模型,每一代的成本也在大幅降低,而开源模型则紧随其后。更关键的是,即便“诺贝尔奖得主级天才”智能尚未到来,足以胜任绝大多数知识工作的智能如今已经存在,并且成本还在逐月下降。照此趋势,我们很快就将进入智能几乎免费的时代——这种智能对于日常知识工作而言绰绰有余。
披露:本文是一篇由 Aditya G. Parameswaran——加州大学伯克利分校 EECS 副教授兼 EPIC Data Lab 联合主任——及其合作者共同撰写的观点文章。本文兼具领域综述与观点阐述的性质,下文讨论的若干研究方向(包括智能体式推测、结构化记忆,以及从零开始合成定制数据系统)均源自作者们正在开展的研究工作。
那么,这个智能近乎免费的新时代对数据系统意味着什么?我们认为,接近于零的推理成本带来了三项新的挑战与机遇:
面向 AI 智能体的数据系统。AI 智能体很快将成为数据系统的主要工作负载——系统会针对每个终端用户请求启动一群 AI 智能体。考虑到 AI 智能体与人类——或代表人类行动的应用程序——在特征上的差异,我们应如何重新设计数据系统,以服务这类智能体用户?
由 AI 智能体构成的数据系统。随着 AI 智能体开始承担大部分知识工作,我们需要一种新的基础底座,让成千上万个 AI 智能体能够管理长期运行任务中的状态、相互协调并达成共识,以及处理彼此的故障。能够可靠、高效地运行和管理 AI 智能体集群的数据系统应该是什么样的?
由 AI 智能体构建的数据系统。AI 智能体正迅速获得一次性合成整个数据系统的能力——这意味着,我们可以针对每一种新工作负载重新构建定制系统。验证这类系统是否符合预期行为是一项挑战。要让 AI 智能体合成出真正值得信赖的数据系统,需要具备哪些条件?
面向 AI 智能体、由 AI 智能体构成并由 AI 智能体构建的数据系统
接下来,我们将更详细地讨论这三个方面,随后探讨数据系统与 AI 智能体相互交织的未来,尤其是这三项挑战彼此交汇时的情形。
查询数据库的 AI 智能体,其行为并不像人或 BI 工具。它会执行我们所说的智能体式推测:产生一股高吞吐量、异构的工作流,涵盖模式自省、列式探索,以及从部分查询到完整查询的逐步构造。当多个 AI 智能体分别探索假设空间的不同部分时,每个用户请求都可能产生数千条独立的 SQL 查询。如今,用户可以发出“高层级”的数据任务,例如根因分析——比如“为什么伯克利今年的咖啡销量下降了”——或探索性队列分析——比如“哪些用户群体最有可能在下个季度流失”——每项任务都涉及由潜在连接、聚合与过滤条件组合构成的组合爆炸式空间。
这些 AI 智能体发出的请求蕴含着各种优化机会。例如,在一个由多个 AI 智能体尝试完成每项任务的文本转 SQL 基准测试中,只有 10%~20% 的子计划彼此不同。因此,80%~90% 的子查询都在执行重复工作。同一组实验表明,随着智能体式尝试次数增加,任务成功率也会显著提高——因此,这些冗余实际上是有益的。但从数据系统的角度来看,它们却是在浪费计算。
以 AI 智能体为中心的数据系统可以利用这些特性,帮助 AI 智能体更快取得进展。它可以复用重叠子计划之间的结果,借鉴已有数十年历史的多查询优化与共享扫描研究成果。数据系统也可以尝试以“足够满意”为目标,利用近似查询处理(AQP)领域的成果,返回足以让 AI 智能体继续推进的近似答案;或者以流式方式返回最终算子或中间算子的结果,帮助 AI 智能体判断是否有必要或有帮助继续查看剩余结果。
另一个机会是彻底重新思考查询接口:AI 智能体不再一次发出一条 SQL 查询,而是可以发出一批查询,每条查询都有自己的近似要求。由于枚举指数级搜索空间(如前述根因分析或队列分析示例)并不能很好地发挥 AI 智能体的推理能力,或许数据系统应当支持更高层级的原语,而不是要求 AI 智能体显式列出每一条 SQL 查询。这里的一种思路是借鉴 DBT 风格的 Jinja 宏,为 AI 智能体提供基于循环的原语,用于与数据系统交互。
最后一个机会,是不再将数据系统视为查询的被动执行器;数据系统可以变得主动,因为它们更了解数据和系统特征,而 AI 智能体事先可能并不具备这些基础信息。数据系统可以引导 AI 智能体探索不同方向,提供相关查询的结果,也可以提供性能层面的反馈(例如,系统可以先向 AI 智能体提供延迟估算,而不是直接执行一条代价高昂的查询)。与过去相比,我们如今之所以能够这样做,是因为 AI 智能体可以接受任何形式的文本反馈,而不再期待严格规范的 SQL 查询结果。事实上,数据系统还可以提前为 AI 智能体准备实体化视图和虚拟视图,并将其作为上下文的一部分提供给 AI 智能体,因为这可能比让 AI 智能体自行创建或使用这些视图成本更低或效果更好。
前文关注的是 AI 智能体如何与数据系统交互。现在,我们来考虑 AI 智能体持续工作所需的其他一切:它们在哪里运行、如何记忆、如何相互协调,以及如何应对其他 AI 智能体的故障。这种智能体基础底座独立于提供原始智能能力的推理技术栈。不过,推理技术栈本身正通过 API(例如 OpenAI 或 Anthropic 提供的 API)被抽象化;对于开放权重模型,则由隐藏底层细节的服务框架完成抽象。到目前为止,智能体基础底座一直由 Claude Code 和 Codex 等运行框架负责管理,并结合各种机制来存储和检索记忆。
首先,在记忆方面,目前的共识是文件已经足够;AI 智能体将内容写入非结构化的 markdown(MD)文件,随后可以使用 grep 或基于嵌入的检索方式进行搜索。事实上,许多人认为,持续学习的解决方案是让 AI 智能体摄取大量内容(例如整个代码库、Slack、公司 Wiki 等),然后将学习成果写入 MD 文件,并在需要时按需选择性检索。文件系统、bash 脚本和 MD 文件对 AI 智能体而言确实很重要,而且未来仍将如此。然而,当规模扩大、AI 智能体承担绝大多数知识工作时,这种方法将不再有效。
由于上下文窗口有限,将所有可能相关的 MD 文件片段全部检索出来并塞入上下文,终究会在某个时刻失效。即使上下文窗口继续增长,不把所有信息都放入上下文仍能带来延迟方面的收益——而且在许多情况下,例如知识工作涉及与大型数据库或代码库交互时,将所有相关数据序列化进上下文根本不可行。
一种选择是使用知识图谱表示,但由于缺乏结构化搜索,知识图谱与基于非结构化 MD 的记忆存在相同的局限。真正需要的是,能够跨多个关注属性(或维度),只检索与任务密切相关的记忆。例如,当 AI 智能体调试一个不稳定测试时,它应当能够只提取标记了相关模块、语言、框架和故障模式的记忆,而不是根据关键词或嵌入相似度进行检索。另一个独立的问题是,究竟应该检索什么;包含错误的原始 AI 智能体轨迹并没有太大用处,因为它会诱使 AI 智能体重复相同的错误——相反,我们希望检索到的记忆能够起到纠正作用。
我们最近探索了结构化记忆的相关概念,其中我们跨越各种属性来组织记忆,每个属性都可以设为 * 来表示通用适用性,或者设为值列表进行匹配。对于数据智能体,维度可以包括列和表、操作类型,最后是开放式自然语言纠正指令。因此,我们可以包含仅适用于给定操作类型的记忆(例如"执行日期时间操作时,使用财年而非日历年约定"),或特定表的记忆(例如"在按产品名称查询时,优先使用列 product_cleaned 而非列 product")。一个开放的问题是定义特定于应用的结构化记忆,或其他人称之为内存的世界模型。我们认为这类似于为每个应用定义模式——智能体本身也许可以帮助我们随着时间推移定义和完善它。
结构化记忆对进化框架有效管理搜索空间也很有用。实际上,存储、组织和挖掘大量单智能体和多智能体追踪可以帮助未来的智能体变得更加高效——可能通过基于结构化记忆的机制实现有效的递归自我改进。
另一个挑战是在许多智能体执行转换时,支持对共享内存的并发编辑,以及一般的并发编辑。虽然有一些有用的尝试来支持多版本控制和写时复制语义,但当数千个智能体同时尝试编辑共享状态时,这样的技术是否足够还不清楚。例如,当智能体尝试各种潜在交易以响应用户请求时,这些交易中绝大多数的影响需要被回滚——只有一个"正确的"交易的结果会持久化。支持恰好一次语义的工作与此相关,基于 CRDT 和操作转换的底层技术也是如此。对于记忆等模糊机制的更新,我们可能能够牺牲一致性以换取低延迟,从而实现完美正确性。虽然智能体可以推理语义来补偿或回滚它们的操作,以最终完成大多数任务,但主要的挑战在于它们在这个过程中互相干扰的程度。一个要避免的重要故障模式是一种"活锁"形式,其中不断的补偿操作阻止任何有意义的进展。
除了共享状态之外,当试图支持一大批智能体时,还会出现其他问题,包括智能体失败时怎么办、智能体应如何相互通信(直接或通过中间共享状态),以及我们应如何处理落后的智能体。在支持持久多智能体执行方面已有一些进展,例如 Temporal,但这样的解决方案是否能在数千个智能体的规模上应用仍有待观察。在通信话题上,我们需要机制来使智能体能够相互协商。想象四个开发者智能体试图就共享模式达成共识,具有不同但重叠的目标。在人类的场景中,这将涉及迭代讨论和妥协;对于智能体集群,我们必须定义允许它们汇聚到反映各自委托人基本目标的设计的机制。或者,如果所有智能体都需要访问有限的资源,再次通信将是必要的。是通过集中式协调最好地完成,还是需要分散式方法,仍有待观察。
最后,如果智能是实际上免费的,那么我们可以利用这种智能从零开始合成新的数据系统。实际上,在许多场景中,通用数据系统可能过度设计,因为它们必须支持每种模式、查询和硬件目标。给定一个工作负载,包括 Bespoke OLAP 和 GenDB 在内的最近工作已表明,可以使用智能体流水线在几分钟到几小时内、仅需几美元的成本合成一个完整的、特定于工作负载的分析引擎。这些引擎是一次性的:当工作负载改变时,可以简单地重新生成它们。类似地,我们的工作已表明,可以从零开始合成自定义键值存储,针对工作负载进行优化。事实上,现代 IDE(如 Kiro)将系统开发的规范提升为一等公民。
然而,主要问题是规范通常是不完美的,并且不涵盖所有边界情况。现在的智能体会利用缺失的规范来奖励黑掉高性能指标。在我们的自定义键值存储工作中,我们发现缓解这个问题的一种方法是拥有辅助验证智能体,试图生成捕捉边界情况利用的测试用例,本质上是扩展规范。另一种方法是同时生成系统和它的正确性证明,我们在这方面找到了一些早期成功,但需要做更多工作来巩固这个方法。此外,最好的方式来询求系统的人工编写规范仍有待观察——这能否以迭代的、人在环的方式完成,而不是一次性的、不完整的方式。实际上,即使对于手工编写的软件,人工编写的规范也是不完整的,因此可以预期,未来更加对齐的智能体在做设计决定时将越来越多地行使更好的判断。
这里的其他问题涉及测试是否从一个成熟的系统(例如 Postgres)开始并移除组件/功能能够导致更高的性能或更多的用户信任。另外,是否有机会使设计可组合,包含各种经过验证的组件,可以根据工作负载进行混合和匹配?例如,也许工作负载还没有改变足够多导致存储层需要更新,但也许查询优化器需要改变。一个也许更可行的主张涉及采用与证明系统耦合的智能体来针对与形式化证明相关的代码的关键部分,而不是为整个系统这样做。
最后一个机会是远离具有明确定义接口的传统数据系统栈(例如,解析器、查询优化器、存储管理器等),这些过去大多是单一人类团队管理的特权。相反,智能体可以找到新的方式来"混合"这些组件,也许由此确定新的优化机会。智能体还可以填补功能上的缺口,使现有系统更加功能完整,或与其他竞争系统达到功能对等——或者,类似地,不断完善开源系统以响应特性请求或问题(也许由其他智能体提出!)。以优先考虑正确性、长期维护和人类可解释性的方式做这个将是一个挑战。
在近乎免费的智能时代,数据系统比以往任何时候都更重要。随着智能体承担大部分知识工作,数据系统的工作负载将会改变,它们需要运行的基质必须被构建,而且越来越多的是,它们将参与设计数据系统本身。这些转变中的每一个都开启了新的、令人兴奋的研究议程。
展望更远,智能体和数据系统之间的边界可能会开始模糊。例如,智能体可以设计它们自己运行的数据系统,定义接口以及下面的系统组件。接口和内部结构可以通过智能体的递归自我改进形式随着时间推移而演进。还有一个机会来重新思考数据系统作为整个相关状态的整体真实来源:包括原始数据、内存和协调状态,进一步消除被智能体查询的数据和作为智能体活动结果生成的数据之间的区别。最后,数据系统本身可能会纳入智能体组件,从被动计算引擎根本性地演进为智能、主动、自我优化的架构。很难预测未来会发生什么。我们将经历一场狂野的旅程!
本文中描述的视角和正在进行的工作是 EPIC 数据实验室、数据系统与基础集团和更广泛的伯克利 AI-Systems 社区的许多了不起的合作者之间的联合研究和讨论的产物。感谢你们!
本文 BibTeX:
@misc{intelligence-is-free-blog,
title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
year={2026}
}