别把你的LLM当数据库用

别把你的LLM当数据库用

批处理范式为何已成为过去时，它如何阻碍 AI 应用发展，以及为何 AI 的未来需要一个实时事件流平台。

译自 Stop Treating Your LLM Like a Database，作者 Sean Falconer。

想象一下，你开着一辆车，戴着耳机，耳机每五分钟才更新一次你的视野，而不是提供连续的视频流。你多久会撞车？

虽然这种批处理方式在现实世界中显然行不通，但这正是许多系统今天的工作方式。批处理源于过时的技术限制，迫使应用程序依赖静态的、延迟的数据。这种方法在计算能力、内存和存储空间有限时可能是唯一可行的解决方案，但它与我们与现实世界互动的方式完全不符——更不用说AI应该如何运作了。

生成式AI拥有巨大的潜力，但将大型语言模型(LLM)视为静态数据库——等待输入并交付输出的反应式系统——完全忽略了重点。AI依赖于实时、上下文相关的数据。然而，坚持批处理思维方式，我们正在扼杀它的能力。

让我们探讨一下为什么批处理范式是过去的东西，它如何阻碍AI应用，以及为什么AI的未来需要一个实时的事件流平台。

面向批处理的分析和机器学习系统在几十年来一直主导着技术领域。这些系统出于必要而诞生，是在计算机内存有限、计算能力受限且存储空间极少的时候创建的。然而，同样的传统方法现在正被应用于生成式AI的新世界。

MLOps主要围绕着一组离散的、顺序的任务展开，例如特征工程、模型训练、模型测试、模型部署和偏差特征描述。这种概念模型非常适合面向批处理的开发和交付，但它限制了这些应用程序在不断变化的世界中能够达到的反应速度和准确性。那些需要更好响应能力的应用程序必须放弃常见的MLOps基础设施。

我们认为这是一种错误的方法。

从根本上说，这种范式将数据聚合到一个中心数据库中，在那里被动地等待系统或用户轮询和调用。这创建的系统只有在其接收到的查询的特定性方面才有用。虽然这种方法在其时间的限制内有效，但它从根本上与我们体验和与世界互动的方式脱节。

批处理流程的高级视图

即使技术已经发展，这种思维方式仍然根深蒂固。今天，我们拥有像数据流平台这样的替代技术，允许实时、事件驱动的架构。但是批处理系统仍然存在——不是因为它们是最好的解决方案，而是因为它们已经成为公认的做法。

就像一句老话，“没有人因为购买IBM而被解雇”，批处理系统也可以这么说：没有人因为设计一个在一个地方聚合数据、并以这种集中数据上的行为高效可靠为前提的系统而被解雇。我们已经习惯于将工作建模为一系列任务，完成一项任务后再进行下一项任务。来自运筹学和精益制造等学科的既定成果强化了这样一个观点：当我们进行面向批处理的工作时，人类做得很好，因为我们通过实践变得更好，而思维切换效率较低。现代分布式系统不需要受限于我们的局限性。

在我们的日常生活中，我们不会基于“批处理更新”来处理世界。我们持续地处理信息，对不断变化的环境做出反应和适应。然而，历史的局限性导致批处理成为默认范式。

传统的机器学习反映了这种面向批处理的思维方式。模型围绕着严格的线性工作流程进行操作：

1. 收集训练数据: 收集特定领域的静态数据集，通常代表某个时间点的快照。
2. 特征工程: 对数据进行预处理、细化和准备，以用于模型。
3. 训练模型: 基于整理后的数据构建模型。
4. 测试模型: 将现有数据的一部分与训练数据隔离，并用于根据某些预定义的性能阈值测试模型的有效性。
5. 部署模型: 部署后，模型成为一个固定的工件，用于查询预测。

传统机器学习的批量处理

虽然对特定用例有效，但此过程本质上是僵化的，缺乏适应性。

相比之下，生成式AI之所以具有变革性，原因之一是基础模型本身具有可重用性，并且能够解决许多领域的不同问题。但是，为了使这些模型能够跨各种领域重用，必须在提示组装过程中对数据进行情境化处理——这是批量处理根本无法满足的需求。

让我们考虑一个简单的例子。假设我们要创建一个AI驱动的航班助手，在航班延误时帮助客户。

用户与AI航班助手之间的交互示例

在上面的两次交互中，需要大量上下文才能满足客户的需求。

大型语言模型需要记住所涉及的城市是纽约。它需要知道客户身份和当前预订、当前航班信息、出发和到达时间、座位布局、座位偏好、价格信息和航空公司更改政策。

与传统机器学习（模型使用特定于应用程序的数据进行训练）相反，大型语言模型并非使用您的数据进行训练；它们使用一般信息进行训练。特定于应用程序的数据工程是在提示组装过程中进行的，而不是在模型创建过程中。

通过提示组装实现大型语言模型的可重用性和定制化

在一个每分钟发表两篇医学论文和每小时解决8400起法律案件的世界里，静态数据是不够的。人工智能系统需要实时、动态的数据才能兑现其承诺。尽管有更好的替代方案，但坚持使用面向批处理的系统会限制现代应用程序的潜力，尤其是在人工智能领域。现在是时候重新思考这种过时的做法，并采用反映我们在动态、实时世界中生活和工作方式的架构了。

在我们设计下一代人工智能应用程序时，我们有可能会陷入同样的面向批处理的陷阱。我们将大型语言模型视为数据库——等待输入并响应特定查询的被动工具。但这种思维方式与大型语言模型的能力根本不相符。人工智能不仅仅是保存信息；它还关乎推理、生成和演变。

数据库是内向型的，在被明确要求之前会保留信息，而大型语言模型是外向型的，旨在参与、综合和主动贡献。它们在上下文不断变化的环境中蓬勃发展，需要能够支持这种动态行为的架构。面向批处理的方法（模型和数据定期更新，但在其他方面是静态的）会扼杀生成式人工智能的真正潜力。

要真正释放人工智能的潜力，我们需要转变思维方式。

人工智能系统应该是工作流程中积极的参与者——贡献想法，参与动态对话，并在某些情况下自主运行。这需要对架构进行彻底改革。我们不需要静态的、基于查询响应的系统，而是需要能够实现流畅、实时交互和适应的事件驱动架构。

对数据流平台的需求源于批处理系统处理实时需求的不足。在金融、电信和电子商务等领域，毫秒可以决定成败，面向批处理的架构无法跟上。需要应用程序在交易发生时检测欺诈，在产品售出时更新库存水平，或在客户交互期间提供实时个性化服务。

流处理的高级视图

流处理平台通过启用与动态、快节奏系统需求一致的连续、事件驱动的流程来解决这些差距。

生成式人工智能的大多数实际用例都依赖于实时、情境化数据。流处理平台通过解决批处理系统无法解决的关键挑战来补充这些模型。

1. 实时上下文化: 大型语言模型需要最新的数据才能生成有意义的响应。例如，一个AI驱动的航班助手需要立即访问航班延误、取消和改签选项。流处理平台提供了这种实时上下文，确保AI在需要时拥有所需的信息。
2. 动态决策: 生成式AI系统不仅仅可以响应查询。流处理平台允许AI动态响应变化的输入，例如在库存水平变化时调整产品推荐，或在新的法律案例发布时做出响应。
3. 可扩展的解耦架构: 大型语言模型通常需要与多个系统集成，从CRM到分析平台。流处理平台支持解耦架构，其中每个组件可以独立运行，同时使用相同的數據流。这避免了批处理系统的瓶颈和僵化，使AI应用程序能够有效地扩展。
4. 减少AI工作流程中的延迟: 在批处理系统中，数据收集和处理之间的延迟会导致过时的见解。例如，存储客户数据的批量更新向量数据库可能会推荐已经缺货的产品。流处理消除了这种延迟，使AI工作流程与现实世界条件保持一致。

主动式AI的兴起激发了人们对超越简单查询响应交互的智能体的热情。这些系统可以自主启动行动、做出决策并适应不断变化的环境。

考虑一个典型的AI智能体。我们可以将智能体视为一个自动化流程，它会推断其环境并主动采取行动以实现某些指定的目标。它的决策可能很复杂，包含受中间数据查询影响的条件分支逻辑。

它可能需要从多个来源提取数据，处理提示工程和RAG工作流程，并直接与各种工具交互以执行确定性和随机工作流程。所需的编排非常复杂，依赖于多个系统。如果智能体需要与其他智能体通信，复杂性只会增加。如果没有灵活的架构，这些依赖关系会使扩展和修改几乎不可能。

智能体依赖关系概述

为了实现这一点，它们需要：

• 持续感知: 实时事件流，例如库存变化、用户行为或系统状态。
• 上下文推理: 能够综合动态数据以推断意图和计划行动。
• 自主决策: 无需等待明确的用户指令即可采取行动，例如重新预订航班或动态调整系统配置。

例如，使用流处理的AI驱动的旅行助手可以自主监控航班时刻表，识别延误，重新预订受影响的航班并通知用户——所有这些都无需人工干预。使用静态的、批量更新的数据，这种程度的自主性是不可能的。

流处理平台通过提供持续、低延迟数据流和实时计算所需的架构来满足这些需求。如果没有这个基础，自主协作AI系统的愿景将无法实现。

生成式AI代表了我们构建和使用技术方式的范式转变。但要充分发挥其潜力，我们需要与AI处理和生成见解的方式相一致的系统——持续地、动态地和实时地。流处理平台为此演变奠定了基础。

通过将AI应用程序与流处理平台集成，我们可以：

• 从反应式AI系统转向主动式AI系统。
• 实现实时个性化和决策。
• 确保大型语言模型使用最新、最相关的数据。
• 创建可扩展、灵活的架构，可以随着AI的进步而发展。

生成式AI不仅仅是关于构建更智能的系统；它也是关于构建反映我们体验世界方式的系统：作为一个持续的、不断变化的事件流。流处理平台使这一切成为可能，弥合了过去的静态系统与动态的、AI驱动的未来之间的差距。