譯者 | 布加迪

審校 | 重樓

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

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

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

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

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

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

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

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

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

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

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

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

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

機器學習中的批處理思維

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

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

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

圖2. 傳統(tǒng)機器學習的批流程

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

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

若沒有情景化的數(shù)據(jù)，LLM無法提供價值

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

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

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

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

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

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

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

LLM是外向型

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

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

要真正發(fā)掘AI的潛力，我們需要轉(zhuǎn)變思維。

AI系統(tǒng)應該是工作流程的積極參與者——獻計獻策，參與動態(tài)對話，在一些情況下還能自主操作。這需要大幅改動架構(gòu)。我們需要的不是靜態(tài)的查詢-響應系統(tǒng)，而是能夠?qū)崿F(xiàn)流暢實時的交互和靈活適應的事件驅(qū)動架構(gòu)。

流處理如何發(fā)掘AI的潛力？

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

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

面向生成式AI的流處理

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

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

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

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

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

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

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

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

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

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

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

流處理是生成式AI的未來

生成式AI是我們在構(gòu)建和使用技術(shù)的方式上的一場根本性轉(zhuǎn)變。要充分發(fā)掘其潛力，我們需要與AI處理和獲得見解的方式保持一致的系統(tǒng)：持續(xù)、動態(tài)、實時。流處理平臺為這種演變提供了基礎。

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

• 從被動AI系統(tǒng)轉(zhuǎn)向主動AI系統(tǒng)。
• 支持實時個性化和決策。
• 確保LLM依據(jù)最新、最相關的數(shù)據(jù)運行。
• 創(chuàng)建可擴展的、靈活的架構(gòu)，可以隨AI的進步而發(fā)展。

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

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