自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

向量數(shù)據(jù)庫真的能滿足所有 AI Agent 的記憶需求嗎?

數(shù)據(jù)庫 其他數(shù)據(jù)庫
記憶管理對于長期運行的 AI Agents 的廣泛應(yīng)用至關(guān)重要。雖然向量數(shù)據(jù)庫在處理對話式智能體時表現(xiàn)出色,但我們發(fā)現(xiàn)它們無法滿足復(fù)雜 Agentic AI 任務(wù)多樣化的記憶需求,尤其是情景記憶(episodic memory)和程序記憶(procedural memory)。

作者 | Debmalya Biswas 

編譯 | 岳揚

圖:Agentic AI 記憶管理(圖片由作者提供)圖:Agentic AI 記憶管理(圖片由作者提供)

1.Agentic AI 系統(tǒng)簡介

AI Agent 是當(dāng)前的熱門話題。我之前對此有過撰述,其他人也正在熱議這個話題。然而,圍繞 Agentic AI 系統(tǒng)的具體定義,卻有不少爭議。它們與生成式 AI(Gen AI)或大語言模型(LLM)智能體究竟有何區(qū)別?

本節(jié)旨在通過分析 Agentic AI 系統(tǒng)在實施具體營銷案例時的功能性與非功能性需求,為這場討論撥云見日 —— 具體見圖 1。

圖 1:Agentic AI 在營銷案例中的應(yīng)用(圖片由作者提供)圖 1:Agentic AI 在營銷案例中的應(yīng)用(圖片由作者提供)

面對用戶任務(wù),Agent 平臺的目標(biāo)是找出能夠勝任該任務(wù)的 Agent(或 Agents 集群)。首先,我們需要的是一個能夠?qū)⑷蝿?wù)拆分為子任務(wù)的編排層(orchestration layer),并由編排引擎來協(xié)調(diào)各 Agent 的執(zhí)行。

目前,我們依靠 LLM 來處理任務(wù)分解,這就是與 Gen AI 的重疊之處。但遺憾的是,這也意味著當(dāng)前 Agentic AI 的推理能力受限于大語言模型(LLM)。

以 GPT4 為例,其對以下提示詞的任務(wù)分解在圖 1 中有詳細展示:“生成一項量身定制的電子郵件營銷計劃,目標(biāo)是一個月內(nèi)實現(xiàn) 100 萬美元的銷售目標(biāo)。相關(guān)產(chǎn)品及其性能數(shù)據(jù)可在 [url] 查詢。請接入 CRM 系統(tǒng) [integration],獲取客戶姓名、電子郵件地址和人口統(tǒng)計詳細信息?!?/p>

分解步驟為:(分析產(chǎn)品)—(確定目標(biāo)群體)—(創(chuàng)建定制電子郵件營銷活動)。

接下來,系統(tǒng)將監(jiān)控執(zhí)行過程和執(zhí)行環(huán)境,并自主進行調(diào)整。在本案例中,Agent 意識到無法達成銷售目標(biāo),便自主增加了以下任務(wù):(尋找替代產(chǎn)品)—(利用客戶數(shù)據(jù))—(進行A/B測試)。

值得一提的是,對于多數(shù)應(yīng)用場景,與企業(yè)系統(tǒng)的集成(如本例的 CRM 系統(tǒng))是不可或缺的。例如,可以參考 Anthropic 最近提出的模型上下文協(xié)議(MCP)[1],該協(xié)議旨在將 AI Agents 與存儲企業(yè)數(shù)據(jù)的外部系統(tǒng)相連接。

鑒于這類任務(wù)的長期運行性質(zhì),Agentic AI 系統(tǒng)的內(nèi)存管理顯得尤為關(guān)鍵。一旦啟動了初步的電子郵件營銷活動后,Agents 就需要對其進行為期一個月的監(jiān)控。

這就涉及到在任務(wù)間共享上下文以及在長時間內(nèi)維持執(zhí)行上下文的連續(xù)性。

目前的做法是利用向量數(shù)據(jù)庫(Vector DBs)來外部存儲 Agents 的記憶,確保數(shù)據(jù)項在需要時能夠被訪問。接下來,我們將深入探討以下細節(jié):

  • 如何通過向量數(shù)據(jù)庫管理 AI Agents 的記憶
  • 以及相應(yīng)的數(shù)據(jù)質(zhì)量問題。

我們會發(fā)現(xiàn),盡管向量數(shù)據(jù)庫在處理會話記憶(如問答對(Q&A pairs))時足夠用,但對于 agentic 任務(wù)來說,它們在管理以下額外記憶類型時顯得力不從心:

  • 語義記憶(通用知識)
  • 情景記憶(個人體驗)
  • 程序記憶(技能與任務(wù)流程)

因此,我們強調(diào)需要采用其他形式(例如,知識圖譜、有限狀態(tài)機)來有效地對記憶存儲進行管理。

2.利用向量數(shù)據(jù)庫進行會話記憶管理

向量數(shù)據(jù)庫(Vector DBs)是專為存儲向量數(shù)據(jù)而設(shè)計,并能基于向量間的相似度來處理查詢。這類數(shù)據(jù)庫當(dāng)前是存儲和提取對話智能體所需數(shù)據(jù)(記憶)的核心工具。圖 2 展示了如何利用向量數(shù)據(jù)庫對對話智能體進行編碼和記憶管理。

圖 2:基于向量數(shù)據(jù)庫的編碼技術(shù),用于 LLMs(圖片由作者提供)圖 2:基于向量數(shù)據(jù)庫的編碼技術(shù),用于 LLMs(圖片由作者提供)

這一過程涉及到選擇一個編碼器模型,該模型獨立于主流程,負責(zé)將不同類型的原始數(shù)據(jù)(如文本、音頻和視頻)離線轉(zhuǎn)換為向量。在編碼空間中,相似的對話數(shù)據(jù)會被映射到彼此靠近的向量上。

例如,文本必須轉(zhuǎn)換為數(shù)值向量才能被計算機處理,這一轉(zhuǎn)換是通過分詞器(Tokenizers)完成的。token 可以是字節(jié)、字符、字符組合、單詞甚至是完整的句子。目前,字節(jié)對編碼(BPE)是最常用的分詞方法,它將一對相鄰的字節(jié)作為一個 token。

選擇合適的“token”至關(guān)重要,因為它不僅決定了神經(jīng)網(wǎng)絡(luò)能夠捕捉的 token 間關(guān)系,還影響著訓(xùn)練該網(wǎng)絡(luò)的計算復(fù)雜度。

這些編碼后的數(shù)據(jù)存儲在向量數(shù)據(jù)庫中,在推理階段,可以基于向量相似度,使用相同的編碼器模型來檢索這些數(shù)據(jù)。在對話過程中,對話智能體可以通過編碼查詢(query)內(nèi)容并在向量數(shù)據(jù)庫中搜索相關(guān)信息來訪問長期記憶系統(tǒng)。隨后,智能體會利用檢索到的信息來回答用戶的查詢(query),這些信息是基于之前存儲的數(shù)據(jù)。

2.1 向量數(shù)據(jù)庫中的數(shù)據(jù)質(zhì)量問題

盡管數(shù)據(jù)質(zhì)量對 AI 的重要性得到了普遍認同,但目前企業(yè)對數(shù)據(jù)質(zhì)量的關(guān)注主要集中在對結(jié)構(gòu)化數(shù)據(jù) / SQL 數(shù)據(jù)的處理上。非結(jié)構(gòu)化數(shù)據(jù),如文本、圖像、音頻和視頻,幾乎占據(jù)了與企業(yè)生成式 AI(Gen AI)使用場景相關(guān)的 80% 的數(shù)據(jù),卻往往被忽視。本節(jié)我們將探討:

對于存儲在向量數(shù)據(jù)庫中的非結(jié)構(gòu)化數(shù)據(jù),數(shù)據(jù)質(zhì)量的標(biāo)準(zhǔn)是什么?特別是在檢索增強生成(RAG)的應(yīng)用場景中。

結(jié)合微調(diào)技術(shù),RAG 成為了將預(yù)訓(xùn)練的大語言模型(LLM)與企業(yè)數(shù)據(jù)相結(jié)合,增強其上下文相關(guān)性和同時在此過程減少幻覺產(chǎn)生的關(guān)鍵手段之一(見圖 3 的 Gen AI 生命周期階段)。

圖 3:Gen AI 生命周期階段(圖片由作者提供)圖 3:Gen AI 生命周期階段(圖片由作者提供)

面對用戶查詢,RAG 流程包括以下三個步驟(見圖 4):

  • 檢索:將用戶查詢轉(zhuǎn)換為向量形式的嵌入,以計算其與其他內(nèi)容的相似度得分。
  • 增強:利用從向量存儲中檢索到的最新搜索結(jié)果/上下文進行信息補充。
  • 生成:通過將檢索到的信息片段整合到提示詞模板中,為 LLM 提供額外的上下文,從而生成針對查詢的上下文響應(yīng)。

我們首先來看看當(dāng)前結(jié)構(gòu)化數(shù)據(jù) / SQL 數(shù)據(jù)世界中常見的數(shù)據(jù)質(zhì)量維度:

  • 準(zhǔn)確性:數(shù)據(jù)反映現(xiàn)實情況的精確度如何?
  • 完整性:數(shù)據(jù)是否存在缺失值或空值?
  • 一致性:信息在不同位置存儲時是否保持一致?
  • 及時性:數(shù)據(jù)的時間戳反映了其新鮮程度。

接下來,我們將它們應(yīng)用于非結(jié)構(gòu)化數(shù)據(jù)領(lǐng)域/向量數(shù)據(jù)庫 —— 具體見下圖 4。

圖 4:RAG — 向量數(shù)據(jù)庫中的數(shù)據(jù)質(zhì)量問題(圖片由作者提供)圖 4:RAG — 向量數(shù)據(jù)庫中的數(shù)據(jù)質(zhì)量問題(圖片由作者提供)

在向量數(shù)據(jù)庫領(lǐng)域,集合(collection)相當(dāng)于 SQL 數(shù)據(jù)庫中的表(table),每個集合項通常包含:唯一標(biāo)識符(ID)、向量(實際數(shù)據(jù),以浮點數(shù)數(shù)組形式存儲)和元數(shù)據(jù)(例如,時間戳)。

準(zhǔn)確性:指的是向量存儲中數(shù)據(jù)的精確度。試想,如果 AI 基于錯誤信息撰寫新聞,可能會產(chǎn)生虛假新聞而非有價值的內(nèi)容。我們通過以下兩個指標(biāo)來衡量這一點:

  • 正確性:涉及 LLM 響應(yīng)的事實準(zhǔn)確性,
  • 基礎(chǔ)性:涉及 LLM 響應(yīng)與底層知識庫(KB)的關(guān)系。

研究發(fā)現(xiàn)[2],即使模型響應(yīng)是正確的,也可能缺乏適當(dāng)?shù)囊罁?jù)。

錯誤和不一致的向量:由于嵌入過程中的問題,一些向量可能受損、不完整,或者以錯誤的維度生成,這可能導(dǎo)致 AI 輸出混亂或脫節(jié)。例如,如果 AI 基于音質(zhì)參差不齊的錄音生成音頻,結(jié)果可能會顯得不連貫。在文本生成中,數(shù)據(jù)中的語法或語氣不一致可能導(dǎo)致內(nèi)容生硬或脫節(jié)。

缺失數(shù)據(jù)的形式可以是缺失向量或元數(shù)據(jù)。例如,如果生成式 AI 從數(shù)據(jù)不完整的數(shù)據(jù)集中生成視覺設(shè)計,可能會產(chǎn)出帶有缺失元素的設(shè)計。

及時性:如果為 RAG pipeline 中的提示詞提供上下文向量的數(shù)據(jù)庫中的文檔已經(jīng)過時,那么生成式 AI 系統(tǒng)可能會產(chǎn)生不相關(guān)的輸出。例如,如果一個啟用了生成式 AI 的聊天機器人基于過時的政策文件回答問題,就可能會提供不準(zhǔn)確且具有誤導(dǎo)性的答案。

3.Agentic Memory

盡管上述方法能夠有效地將對話存儲為問答對并實現(xiàn)檢索,但它并不足以滿足 Agentic AI 系統(tǒng)所需的其他記憶類型,這些記憶類型對于復(fù)制或改進人類行為至關(guān)重要,尤其是以下四種:

  • 語義記憶(Semantic memory) —— 存儲事實、概念、意義等通用知識。
  • 情景記憶(Episodic memory) —— 記錄與過去特定事件和情境相關(guān)的個人經(jīng)歷。
  • 程序記憶(Procedural memory) —— 存儲如駕駛汽車等運動技能,以及完成任務(wù)的相應(yīng)程序步驟。
  • 情感記憶(Emotional memory) —— 保存與個體經(jīng)歷相關(guān)的情感體驗。

3.1 理解人類記憶

在本節(jié)中,我們首先探討人類大腦如何處理短期記憶和長期記憶 —— 如圖 5 所示。

圖 5:人類大腦的記憶管理(圖片由作者提供)圖 5:人類大腦的記憶管理(圖片由作者提供)

記憶的形成始于感覺系統(tǒng),來自外界的信息首先進入感覺記憶(sensory memory)。這一初始階段以原始形式保存感覺信息,但持續(xù)時間極短,通常僅有幾百毫秒。

隨后,被我們注意到的信息會轉(zhuǎn)移到短期記憶(STM)。短期記憶的容量有限,僅能保存大約 7 個信息塊,且持續(xù)時間約為 20 到 30 秒。它是我們進行思考、解決問題和做出決策等有意識心理活動的場所。

信息要從短期記憶轉(zhuǎn)移到長期記憶(LTM),需要經(jīng)過編碼過程,將其轉(zhuǎn)化為更持久且具有意義的表征。

編碼通過多種機制實現(xiàn)(例如重復(fù)、精細加工,或與已有知識建立關(guān)聯(lián))。

成功編碼后,信息會進入長期記憶。長期記憶的容量極大,能夠存儲信息長達數(shù)小時,甚至一生。

記憶的檢索系統(tǒng)依賴于與上下文信息的關(guān)聯(lián)。外部和內(nèi)部的檢索線索通過重現(xiàn)編碼時的情境,幫助我們提取特定記憶。

  • 回憶是指在沒有外部線索的情況下,主動重建信息的過程。
  • 再認則是指在多個選項中識別出之前遇到的信息。
  • 此外,檢索策略如促發(fā)(priming)、記憶技巧(mnemonic techniques)、分塊(chunking)和復(fù)述(rehearsal),能夠顯著提升記憶的提取效率。

3.2 映射到 Agentic 記憶

基于我們對人類大腦的理解和 AI Agents / 應(yīng)用的要求,我們需要考慮以下記憶類型 —— 如圖 6 所示:

  • 語義知識:來自外部(如 Wikipedia)和內(nèi)部系統(tǒng)(如 Sharepoint、Confluence、文檔、消息平臺等)的信息。
  • 情景記憶:特定過去事件和情境的記憶。這些內(nèi)容是在 AI Agents 運行過程中獲得的。
  • 程序記憶:類似于人類記住游泳或開車等運動技能的方式。它涵蓋了描述 AI Agents 如何實現(xiàn)特定任務(wù)的工作流和程序。
  • 情感記憶:記錄與個體經(jīng)驗相關(guān)的情感。涉及用戶關(guān)系、偏好、反應(yīng)和相關(guān)數(shù)據(jù),使 AI 在用戶交互中更具人性,并在用戶互動中保持一致。

語義記憶可能是目前唯一在 LLM 中通過預(yù)訓(xùn)練和嵌入可實現(xiàn)的記憶類型 —— 其他記憶類型仍在開發(fā)中。

在后續(xù)部分,我們將展示如何為 Agentic AI 系統(tǒng)實現(xiàn)一個全面的記憶管理模塊 —— 如圖 6 所示。

圖片圖片

圖 6:Agentic AI 記憶管理(圖片由作者提供)

記憶路由器默認總是將請求路由到長期記憶 (LTM) 模塊,以查看是否存在現(xiàn)有模式來響應(yīng)給定的用戶提示詞。如果有,它就會檢索并立即做出響應(yīng),根據(jù)需要進行個性化處理。

如果 LTM 失效,記憶路由器將其路由到短期記憶 (STM) 模塊,該模塊然后使用其檢索過程(函數(shù)調(diào)用、API 等)將相關(guān)上下文檢索到 STM(工作記憶)中,并充分利用適用的數(shù)據(jù)服務(wù)。

STM-LTM 變換模塊始終處于活動狀態(tài),并不斷獲取檢索到的上下文,從中提取“recipes”(例如,參考可教學(xué)智能體和 AutoGen 中的“recipes”概念),并存儲在語義層(通過向量數(shù)據(jù)庫實現(xiàn))。與此同時,它還在收集其他相關(guān)屬性(例如,token 數(shù)量、產(chǎn)生模型響應(yīng)的成本、系統(tǒng)狀態(tài)、執(zhí)行的任務(wù)/生成的響應(yīng)),并創(chuàng)建一個 episode,然后將其存儲在知識圖譜中,其中底層過程存儲在有限狀態(tài)機(FSM)中。

4.Conclusion

總而言之,記憶管理對于長期運行的 AI Agents 的廣泛應(yīng)用至關(guān)重要。雖然向量數(shù)據(jù)庫在處理對話式智能體時表現(xiàn)出色,但我們發(fā)現(xiàn)它們無法滿足復(fù)雜 Agentic AI 任務(wù)多樣化的記憶需求,尤其是情景記憶(episodic memory)和程序記憶(procedural memory)。

在這篇文章中,我們提出了一種 Agentic 記憶架構(gòu)的初步設(shè)計方案,其中記憶路由器(memory router)負責(zé)在短期記憶模塊(STM)和長期記憶模塊(LTM)之間進行請求調(diào)度。我們的主要貢獻是一個從 STM 到 LTM 的轉(zhuǎn)換器模塊,該模塊能夠?qū)⑶榫坝洃洺橄蟛⒋鎯υ谥R圖譜(knowledge graphs)中,將程序記憶存儲在有限狀態(tài)機(FSMs)中。目前,我們正在積極優(yōu)化 Agentic AI 系統(tǒng)中長期記憶(LTM)的存儲和檢索機制(包括探索其他形式的方法)。

責(zé)任編輯:武曉燕 來源: Baihai IDP
相關(guān)推薦

2024-05-22 12:07:12

向量數(shù)據(jù)庫AI

2023-07-28 08:00:00

人工智能向量數(shù)據(jù)庫

2023-10-10 13:57:35

2024-01-08 15:35:34

2009-10-29 11:01:52

Amazon RDSMySQL關(guān)系數(shù)據(jù)庫

2009-07-10 09:28:41

NoSQL關(guān)系數(shù)據(jù)庫

2025-04-03 11:04:40

2022-10-11 08:00:00

人工智能機器學(xué)習(xí)數(shù)據(jù)

2018-04-12 17:17:12

2023-11-27 00:58:00

數(shù)據(jù)庫AI

2017-08-08 09:18:03

數(shù)據(jù)大數(shù)據(jù)云計算

2015-01-22 10:05:24

2023-09-11 09:58:46

2020-05-29 15:31:11

數(shù)據(jù)庫管理系統(tǒng)DBMS

2020-05-31 13:37:53

DBMS云端數(shù)據(jù)庫

2022-07-20 11:08:12

微服務(wù)數(shù)據(jù)庫架構(gòu)

2020-09-10 18:14:51

人工智能 IBM

2020-09-11 10:59:05

數(shù)據(jù)庫

2010-08-19 09:48:41

Unix

2022-10-18 11:47:08

數(shù)據(jù)分析運營直播
點贊
收藏

51CTO技術(shù)棧公眾號