文章重點
- 開源項目Mastra推出「觀察記憶」(Observational Memory)技術,採用Observer和Reflector雙代理架構,持續壓縮對話歷史為帶日期標記的觀察日誌
- 該技術在長上下文基準測試中的表現超越傳統RAG(檢索增強生成)系統,同時將AI代理運營成本降低約10倍
- 與RAG的「按需檢索」模式不同,觀察記憶維護一個持續演進的觀察日誌,更接近人類記憶的「沉澱式」運作方式
- 作為完全開源的項目,觀察記憶可能大幅降低企業AI代理部署的成本門檻,對現有RAG服務商構成競爭壓力
- 技術社群反應熱烈,多位業界專家認為這代表了AI記憶管理的「範式轉換」
RAG的困境:當「檢索」遇上「遺忘」
過去兩年,檢索增強生成(Retrieval-Augmented Generation,RAG)幾乎成了企業AI部署的標準架構。其核心邏輯看似優雅——當AI模型需要回答問題或執行任務時,先從外部知識庫中檢索相關信息,再將這些信息作為上下文提供給模型。這解決了大型語言模型(LLM)的兩個核心痛點:知識過時和幻覺生成。
然而,隨着AI代理(AI Agent)的應用場景從簡單的問答擴展到複雜的多步驟任務執行,RAG的局限性開始暴露無遺。
最根本的問題是:RAG是無狀態的。每次檢索都是獨立的——系統不會「記住」上一次對話中用戶提到了什麼偏好,不會「理解」過去三個月的互動模式,更不會從歷史對話中「學到」關於用戶或任務的深層洞察。RAG從向量數據庫中撈出的是碎片化的文檔片段,而非連貫的、有時間脈絡的理解。
對於一個處理客戶服務的AI代理來說,這意味着每次對話都像是第一次見面。用戶上周詳細說明過的問題背景、上個月表達的偏好、去年投訴過的產品缺陷——所有這些信息要麼在RAG的向量空間中被淹沒,要麼需要大量的上下文窗口來承載,而後者直接推高了API調用成本。
這正是Mastra的「觀察記憶」技術試圖解決的核心問題。
觀察記憶的架構解剖:Observer與Reflector的精妙分工
觀察記憶的核心設計借鑒了一個來自認知心理學的洞察:人類的記憶不是「檢索系統」,而是「沉澱系統」。我們不會逐字記住每一段對話,而是從經歷中提取有意義的觀察,隨着時間推移將這些觀察沉澱為更深層的理解和模式識別。
Mastra的技術通過兩個專門的背景代理來模擬這一過程。
Observer(觀察者)代理在每次對話過程中靜默運行。它的工作不是參與對話,而是「旁聽」——持續監測對話流,識別並提取具有長期價值的信息碎片。這些信息包括但不限於:用戶明確表達的偏好(「我喜歡簡潔的報告格式」)、隱含的行為模式(用戶總是在週一早上處理財務數據)、重要的事實陳述(「我們公司剛完成了對X公司的收購」)、以及任務執行中的關鍵決策點。
Observer提取的每一條信息都會被標記上精確的時間戳,形成一條帶日期的「觀察記錄」。這種時間標記至關重要——它讓系統能夠區分「用戶三個月前說喜歡A方案」和「用戶昨天改口說更喜歡B方案」,從而始終使用最新、最相關的信息。
Reflector(反思者)代理則在對話間隙(或以設定的頻率)啟動,對Observer累積的觀察記錄進行高層次的綜合分析。它的工作類似於人類在一天結束時的「反思」過程——將零散的觀察提煉為結構化的洞察。例如,Reflector可能從「用戶連續五次要求簡化報告」和「用戶多次跳過詳細數據表格」這兩條觀察中,綜合出「該用戶偏好高層摘要而非詳細數據,報告應以視覺化圖表為主」這一高層次洞察。
Observer和Reflector的分工創造了一個雙層記憶結構:底層是細粒度的、帶時間戳的觀察事實;上層是從這些事實中提煉出的、持續更新的高階理解。當主AI代理需要歷史上下文時,它不需要翻閱完整的對話記錄,也不需要從向量數據庫中搜索碎片化的信息——它只需要參考這個精煉的、結構化的觀察日誌。
觀察記憶 vs RAG:架構對比
RAG的工作流程:用戶提問 → 將問題轉化為向量 → 在向量數據庫中搜索相似內容 → 將檢索到的文檔片段注入提示詞 → 模型生成回答。每次檢索都是獨立的,系統不維護持續狀態。
觀察記憶的工作流程:對話進行中 → Observer背景提取關鍵觀察 → 觀察被時間標記並存入觀察日誌 → Reflector定期綜合觀察為高層洞察 → 主代理在需要時參考精煉後的觀察日誌。記憶是持續演進的,不依賴即時檢索。
成本革命的數學:為什麼能便宜10倍?
「成本降低10倍」的宣稱引人注目,但背後的經濟邏輯需要仔細拆解。
在傳統的RAG架構中,AI代理的成本主要由三部分構成:LLM API調用費用(按token計費)、向量數據庫的存儲和查詢費用、以及嵌入模型的運算費用。其中,LLM API費用通常佔據總成本的60%至80%,而這一費用與每次調用中注入的上下文長度(token數量)直接相關。
RAG的成本問題在於它的「冗餘性」。每次檢索返回的文檔片段中,大量內容是重複的或與當前查詢低相關的。但由於檢索精度的限制,系統不得不將比實際需要更多的上下文注入提示詞,以確保關鍵信息不被遺漏。在一個典型的企業客服場景中,RAG可能為每次對話注入3,000至8,000個token的檢索上下文,其中真正有用的信息可能只佔20%至30%。
觀察記憶通過「前置壓縮」從根本上改變了這個經濟等式。Observer和Reflector的工作本質上是一個持續的信息壓縮過程——將冗長的對話歷史壓縮為精煉的觀察要點。當主代理需要歷史上下文時,它參考的是已經被壓縮過的觀察日誌,而非原始對話記錄或碎片化的文檔。
以一個運行了六個月、積累了數百輪對話的企業AI代理為例:在RAG架構下,每次對話可能需要檢索和注入數千個token的歷史上下文;而在觀察記憶架構下,六個月的互動歷史可能被壓縮為幾百個token的精煉觀察。這就是10倍成本差異的來源。
當然,觀察記憶並非零成本。Observer和Reflector作為背景代理,本身也需要消耗LLM API的算力。但關鍵在於,它們的工作是「一次壓縮,多次復用」——Observer和Reflector處理一次對話的成本是固定的,而壓縮後的觀察日誌可以被後續無數次對話復用,其邊際成本趨近於零。相比之下,RAG的每次檢索都是獨立的,成本隨對話次數線性增長。
長上下文戰場:觀察記憶為何勝過RAG?
成本優勢只是故事的一半。更令技術社群興奮的是觀察記憶在長上下文基準測試中超越RAG的表現。要理解這一點,需要先理解RAG在長上下文場景中的結構性弱點。
RAG的檢索精度高度依賴查詢與文檔之間的向量相似度。在短上下文場景中(如單輪問答),這種方法表現出色。但當對話跨越數十輪甚至數百輪時,RAG面臨兩個日益嚴峻的挑戰。
第一,上下文碎片化。向量檢索返回的是獨立的文檔片段,它們之間的邏輯關聯和時間順序在檢索過程中會丟失。當一個複雜問題的答案需要綜合多個不同時間點的信息時,RAG檢索到的碎片往往缺乏連貫性,導致模型的回答出現邏輯斷層或信息矛盾。
第二,「大海撈針」問題的惡化。隨着知識庫的增長,與當前查詢相關的信息在整個向量空間中的「密度」持續下降。這意味着檢索的準確率會隨着數據量的增加而下降——一個在1萬條記錄中表現優秀的RAG系統,在100萬條記錄中可能開始遺漏關鍵信息。
觀察記憶通過其「持續壓縮」的架構,從根本上避開了這兩個問題。由於Observer在對話發生時就提取了關鍵觀察,而Reflector持續將這些觀察綜合為高層洞察,觀察日誌本身就是一個連貫的、有時間脈絡的、持續更新的知識結構。它不需要在查詢時進行向量搜索,因此不受知識庫規模增長的影響;它保留了信息之間的邏輯和時間關聯,因此不會出現上下文碎片化的問題。
從某種意義上說,觀察記憶將RAG的「讀時計算」模式轉變為「寫時計算」模式——信息處理的成本從每次查詢時承擔,轉移到了信息錄入時一次性承擔。這種架構轉換在數據庫領域有一個經典的類比:從「按需查詢」的OLTP模式,轉向「預先聚合」的OLAP模式。
關鍵技術細節:觀察日誌的結構
觀察記憶的日誌並非簡單的文本堆疊。每條觀察記錄包含以下結構化字段:時間戳(精確到秒)、觀察類型(事實陳述/偏好表達/行為模式/情緒信號)、信心分數(Observer對該觀察重要性的評估)、關聯索引(與其他觀察的邏輯關聯)。Reflector在綜合觀察時,會根據信心分數和時間衰減函數對觀察進行加權,確保最新和最高置信度的觀察獲得優先考慮。當觀察之間出現矛盾(如用戶改變偏好)時,Reflector會保留最新的觀察並標記歷史變更軌跡。
開源的戰略意義:重塑企業AI的成本結構
觀察記憶技術的另一個重要維度是其完全開源的屬性。在當前企業AI部署的成本結構中,RAG相關的基礎設施——向量數據庫(如Pinecone、Weaviate)、嵌入模型API、以及RAG優化工具——已經形成了一個利潤豐厚的商業生態系統。觀察記憶作為開源替代方案的出現,可能對這個生態系統產生深遠的衝擊。
對於正在考慮或已經部署AI代理的企業來說,觀察記憶的開源可用性意味着一個潛在的成本優化路徑:用開源的觀察記憶替代部分或全部RAG基礎設施,在保持甚至提升性能的同時,大幅降低運營成本。這對於中小型企業尤為重要——在當前的成本結構下,許多中小企業被排除在AI代理部署的門外,而10倍的成本降低可能使這些企業首次具備經濟可行的AI代理部署能力。
然而,「開源」並不意味着「免費午餐」。企業仍然需要投入工程資源來部署、定制和維護觀察記憶系統。Observer和Reflector的行為需要根據具體業務場景進行精細調整——什麼信息值得「觀察」、什麼觀察值得「反思」、觀察日誌的保留策略如何設定——這些都需要對技術和業務的雙重理解。
此外,觀察記憶目前的開源狀態也引發了一些關於可持續性的問題。Mastra作為一個開源項目,其長期維護和發展需要穩定的資源支持。開源AI基礎設施的商業模式(如Red Hat模式的企業支持服務、或Databricks模式的托管服務)是否適用於觀察記憶,還有待觀察。
並非取代,而是互補:觀察記憶與RAG的共存未來
儘管觀察記憶在多個維度展現了對RAG的優勢,但將兩者簡單地定位為「替代關係」可能過於簡化。更準確的理解是,它們解決的是記憶管理中的不同層面的問題,在許多實際場景中,兩者的結合可能比任何一方的單獨使用更為有效。
RAG的不可替代性。RAG在處理靜態知識庫(如公司政策文檔、產品手冊、法律條文)的查詢方面仍然具有明確的優勢。這些信息是事先存在的、結構化的、不會隨對話而變化的。對於這類信息的檢索,RAG的向量搜索仍然是最直接和高效的方法。觀察記憶的「觀察-反思」機制更適合處理從對話中動態生成的信息,而非既有的靜態知識庫。
混合架構的可能性。一個理想的企業AI代理可能同時使用兩種記憶系統:用RAG檢索公司知識庫中的靜態信息,用觀察記憶維護與每個客戶互動中積累的動態理解。這種「雙記憶」架構能兩者兼顧——既有對企業知識的準確檢索,又有對客戶個體的持續記憶。
生態整合的挑戰。要實現這種混合架構,觀察記憶需要與現有的RAG工具鏈無縫整合。目前,RAG生態系統已經相當成熟,擁有LangChain、LlamaIndex等框架的廣泛支持。觀察記憶作為新生技術,其與這些框架的整合程度將直接影響其在企業環境中的採納速度。
從更長遠的視角看,觀察記憶的出現代表了AI記憶管理從「檢索範式」向「認知範式」的轉變。RAG模仿的是圖書館的運作方式——有問題就去書架上找答案。觀察記憶模仿的是人腦的運作方式——從經驗中持續沉澱理解,在需要時調用已經內化的知識。兩種範式各有所長,而最強大的AI系統很可能是兩者的有機結合。
對香港企業AI部署的實際影響
對於正在積極擁抱AI轉型的香港企業來說,觀察記憶技術的出現具有直接的實際意義。
香港的金融服務業是AI代理最早的應用領域之一。多家大型銀行和保險公司已經部署了基於RAG的客戶服務AI代理,但運營成本一直是規模擴展的主要障礙。以一家中型銀行為例,其AI客服代理每月的LLM API費用可能高達數十萬港元,其中大部分花費在RAG的上下文注入上。如果觀察記憶能將這一成本降低10倍,那麼AI代理的部署就從「高管層面的戰略決策」降級為「部門層面的營運工具」——這是大規模採納的臨界點。
此外,觀察記憶的「客戶記憶」能力對香港的高端服務業(如私人銀行、保險經紀、法律諮詢)特別有價值。這些行業的核心競爭力在於對客戶需求的深度理解和個性化服務。傳統上,這種理解存在於資深顧問的個人經驗中,一旦顧問離職,大量的客戶洞察就會隨之流失。觀察記憶提供了一種將這些洞察系統性地捕獲和保留的技術途徑——每一次客戶互動中的關鍵信息都會被Observer提取並存入觀察日誌,形成一份持續演進的「客戶理解檔案」。
當然,在香港部署這類技術也面臨獨特的合規挑戰。香港個人資料私隱專員公署對個人數據的收集和處理有嚴格的規範要求。觀察記憶系統在「觀察」客戶對話內容時,必須確保其行為符合《個人資料(私隱)條例》的規定。這意味着企業在部署觀察記憶時,需要在技術設計層面就內置隱私保護機制——例如自動過濾敏感個人信息、設定觀察日誌的保留期限、以及為客戶提供查閱和刪除其觀察記錄的權利。
觀察記憶的出現標誌着AI記憶管理領域的一個重要轉折點。它或許不會完全取代RAG,但它為AI代理的記憶問題提供了一個根本不同的解題思路。對於關注AI技術演進的企業決策者來說,現在是時候將觀察記憶納入技術評估的範圍,認真思考它是否能為自身的AI部署策略帶來結構性的成本和性能優化。這不是一個遙遠的未來趨勢——這是一個今天就可以開始試驗的開源工具。