本文介紹了為什么批處理范式已過時，它如何阻礙AI應用，以及為什么AI的未來需要一種實時事件流平臺。

想象一下，你戴著耳機駕駛一輛汽車，每五分鐘才更新一次路況信息，而不是持續不斷地提供當前位置情況的視頻流。過不了多久，你就會撞車。

雖然這種類型的批處理在現實世界中并不適用，卻是當今許多系統運行的方式。批處理誕生于過時的技術限制，迫使應用程序依賴靜態的延遲數據。當計算、內存和存儲均有限時，這種方法可能是唯一可行的解決方案，但它與我們跟現實世界互動的方式完全不符合，更不符合AI的運作方式。

生成式AI具有不可思議的潛力，不能將大語言模型（LLM）視為靜態數據庫，即等待輸入并提供輸出的反應式系統。AI依賴實時情境數據才能蓬勃發展。如果固守批處理觀念，我們無異在扼殺其能力。

不妨探討一下為什么批處理范式已過時，它如何阻礙了AI應用的發展，以及為什么AI的未來需要一種實時事件流平臺。

為什么我們受困于批處理模式？

用于分析和機器學習的面向批處理的系統幾十年來一直主導著技術界。這些系統應運而生，是在計算機內存有限、算力有限、存儲空間極小的時代創建的。然而，同樣的傳統方法現正被應用于新時代的生成式AI。

機器學習運維（MLOps）在很大程度上圍繞一組離散的、順序的任務發展而來，比如特征工程、模型訓練、模型測試、模型部署和偏差表征。這種概念模型非常適合面向批處理的開發和交付，但它限制了這些應用程序在不斷變化的世界中的反應性和準確性。那些需要更好響應的應用程序勢必需要避開通用的MLOps基礎設施。

我們認為，這是一種有缺陷的方法。

沒有人因設計批處理過程而被解雇

究其核心，這種范式將數據聚合到一個中央數據庫中，數據被動地等待系統或用戶輪詢和調用。由此形成的系統其用途完全取決于接收到的查詢的具體需求。雖然這種方法適用于當時的限制，但從根本上脫離了我們體驗世界并與之互動的方式。

圖1. 批流程的總體示意圖

盡管技術不斷發展，這種觀念依然根深蒂固。今天，我們有了數據流平臺之類的替代技術，可以實現實時的事件驅動架構。但是批處理系統仍然存在，倒不是由于它們是最好的解決方案，而是由于它們已成為認可的行事方式。

就像“沒有人因購買IBM系統而被解雇”這句老話，批處理系統同樣如此：沒有人因設計了一個將數據聚集在一個地方的系統而被解雇，前提是根據這個集中式數據采取行動高效而可靠。我們習慣于把工作看成是一系列任務，完成一項后再進行下一項。運籌學和精益制造等學科的成熟結果表明，我們在做批量工作時表現出色，因為我們通過實踐變得更好，而轉換思維比較低效。現代分布式系統不需要受制于我們的局限性。

機器學習中的批處理思維

在日常生活中，我們并不基于“批量更新”來應對世界。我們不斷地處理信息，對不斷變化的情境做出反應和適應。然而，歷史限制導致了批處理成為默認范式。

傳統的機器學習反映了這種面向批處理的思維。模型圍繞嚴格的線性工作流程進行操作：

• 收集訓練數據：收集特定領域的靜態數據集，常用于時間快照。
• 特征工程：對數據進行預處理、完善并為模型做好準備。
• 訓練模型：模型基于篩選后的數據而構建。
• 測試模型：將現有數據的一些部分與訓練數據隔離出來，用于對照某些預定義的性能閾值測試模型的有效性。
• 部署模型：一旦部署，模型就變成了固定的工件，用于預測查詢。

圖2. 傳統機器學習的批流程

雖然這個過程針對特定的用例很有效，但是本質上僵化，缺乏適應性。

相比之下，生成式AI如此具有變革性的原因之一是因為基礎模型天生可重用，并且能夠解決許多領域的各種問題。然而，為了使這些模型在不同領域之間可重用，必須在提示組裝期間確保數據在特定情景中，而批處理無法滿足這一要求。

若沒有情景化的數據，LLM無法提供價值

不妨考慮一個簡單的例子。想象一下，我們開發一款基于AI的航班助理，當航班延誤時可以幫助客戶。

圖3. 用戶與AI航班助理之間的示例交互

在上面的兩輪交互中，需要很多情景信息來滿足客戶的要求。

LLM需要記住，相關的城市是紐約。它需要知道客戶身份和當前預訂情況、當前航班信息、出發/到達時間、座位布局、座位偏好、定價信息和航空公司變更政策。

相比傳統的機器學習：模型使用針對特定應用程序的數據進行訓練，LLM并不使用你的數據進行訓練，它們使用一般信息進行訓練。針對特定應用程序的數據工程發生在提示組裝期間，而不是模型創建期間。

圖4. 通過提示組裝實現的LLM可重用性和定制性

在每分鐘發表兩篇醫學論文、每小時解決8400起法律案件的當下，靜態數據遠遠不夠。AI系統需要實時流動的數據來給出解決方案。盡管有更好的選擇，但堅持使用面向批處理的系統限制了現代應用的潛力，尤其是AI方面。是時候重新思考這種過時的方法，擁抱反映我們在動態實時的世界如何生活和工作的架構了。

LLM是外向型

當我們設計下一代AI應用程序時，可能會陷入同樣的面向批處理的陷阱。我們將LLM視為數據庫（等待輸入并響應特定查詢的響應式工具）。但這種觀念與LLM具有的能力根本不匹配。AI不僅僅用于保存信息，它還用于推理、生成和進化。

數據庫是內向型，保存信息，只在明確要求時才提供，而LLM是外向型，旨在參與、合成和主動貢獻。它們適合于這種環境：應用情景不斷變化，并且能夠支持這種動態行為的架構。面向批處理的方法（模型和數據定期更新，但其他方面是靜態的）扼殺了生成式AI的真正潛力。

要真正發掘AI的潛力，我們需要轉變思維。

AI系統應該是工作流程的積極參與者——獻計獻策，參與動態對話，在一些情況下還能自主操作。這需要大幅改動架構。我們需要的不是靜態的查詢-響應系統，而是能夠實現流暢實時的交互和靈活適應的事件驅動架構。

流處理如何發掘AI的潛力？

數據流平臺支持實時需求，即支持連續的、事件驅動的工作流程來滿足動態快節奏的系統需求。在金融、電信和電子商務等幾毫秒事關成敗的領域，面向批處理的架構力不從心。需要應用程序在交易進行時檢測欺詐，在產品銷售時更新庫存量，或者在客戶交互期間提供實時個性化。

圖5. 流處理的總體示意圖

面向生成式AI的流處理

生成式AI的大多數實際用例都有賴于實時的情境數據。流處理平臺通過克服批處理系統無法解決的重大挑戰來補充這些模型。

• 實時情境化：LLM需要最新的數據來生成有意義的響應。比如說，基于AI的航班助理需要即時訪問航班延誤、取消和重新預訂選項。流處理平臺則提供了這種實時上下文，確保AI在需要時獲得所需的信息。
• 動態決策：生成式AI系統能做的不僅僅是響應查詢。流處理平臺允許AI對不斷變化的輸入做出動態反應，比如在庫存量變化時調整產品推薦，或者對剛發布的新法律適用案件做出反應。
• 可擴展、解耦的架構：LLM常常需要與從CRM到分析平臺的多個系統集成。流處理平臺支持解耦的架構，其中每個組件可以在使用相同數據流的同時獨立操作。這避免了批處理系統的瓶頸和剛性，允許AI應用程序有效地擴展。
• 減少AI工作流程的延遲：在批處理系統中，數據收集與數據處理之間的延遲可能導致過時的信息。比如說，存儲客戶數據的批量更新矢量數據庫可能會推薦已經缺貨的產品。流處理消除了這種延遲，使AI工作流程與實際情形保持一致。

代理型AI：行動而不是等待的AI

代理型AI的興起激發了人們對并不僅限于簡單的查詢/響應交互的代理的興趣。這種系統可以自主發起行動、做出決策并適應不斷變化的環境。

以典型的AI代理為例。我們可以把代理看作自動化過程，對所處環境進行推理，并主動采取行動來實現某些指定的目標。它的決策可能很復雜，包含受中間數據查詢影響的條件分支邏輯。

它可能需要從多個來源提取數據，處理提示工程和RAG工作流程，并直接與各種工具交互以執行確定性和隨機性的工作流程。所需的編排很復雜，依賴多個系統。如果代理需要與其他代理進行聯系，復雜性只會有增無減。如果沒有靈活的架構，這些依賴關系使得擴展和修改幾乎不可能實現。

圖6. 代理依賴關系概況圖

要做到這一點，它們需要：

• 持續感知：實時事件流，比如庫存、用戶行為或系統狀態等方面的變化。
• 情境推理：綜合動態數據以推斷意圖和規劃行動的能力。
• 自主決策：無需等待明確的用戶指令即可執行操作，比如重新預訂航班或動態調整系統配置。

比如說，使用流處理的基于AI的旅行助理可以自動監控航班時刻表、識別延誤、重新預訂受影響的航班并通知用戶，這一切都無需人工干預。換成批量更新的靜態數據，這種程度的自主就不可能實現。

流處理平臺通過提供持續的低延遲數據流和實時計算必不可少的基礎設施來滿足這些需求。沒有這個基礎，自主、協作的AI系統仍是遙不可及的夢想。

流處理是生成式AI的未來

生成式AI是我們在構建和使用技術的方式上的一場根本性轉變。要充分發掘其潛力，我們需要與AI處理和獲得見解的方式保持一致的系統：持續、動態、實時。流處理平臺為這種演變提供了基礎。

如果將AI應用程序與流處理平臺集成，我們就可以：

• 從被動AI系統轉向主動AI系統。
• 支持實時個性化和決策。
• 確保LLM依據最新、最相關的數據運行。
• 創建可擴展的、靈活的架構，可以隨AI的進步而發展。

生成式AI不僅僅旨在構建更智能的系統，還旨在構建連續的、不斷變化的事件流。流處理平臺使這一切成為可能，彌合了昔日靜態系統與基于AI的動態未來之間的缺口。

原文標題：??Stop Treating Your LLM Like a Database??，作者：Sean Falconer