我想我問錯問題了。

有一陣子，問題很簡單：記憶會讓代理人更聰明嗎？

這聽起來像是正確的問題。它其實也是個陷阱，因為它假設記憶應該被當成一種通用的智慧增幅器來評估。你加上一層記憶，代理人記住更多東西，然後輸出應該就會變得更好。更完整。更準確。更像人。或者隨便哪個我們現在正在用來避免說「我希望這個昂貴的東西有用」的詞。

在做了更多實驗之後，我覺得這種框架是錯的。

記憶並不會在任何一般意義上讓模型更聰明。大多數時候，它也做不到。模型本身的權重裡，已經壓縮了大量通用的程序性知識與領域知識。如果你的記憶層召回的是模型本來就知道的資訊，那你並沒有增加智慧。你只是用更高延遲，多開了一條路去說同一件事。

這就是讓人不舒服的地方。很多代理人記憶系統失敗，不是因為召回壞掉了，而是因為被召回的資訊沒有邊際價值。

它們只是給了模型一個它本來就會做的東西。

這個實驗不是慶功遊行

我在 OrKa Brain 上做了一個後續基準測試：250 個任務、五條軌道、brain 對上 brainless。目的在於看看程序性記憶是否會在規模擴大、任務類型更多的情況下展現更強的結果。

結果沒有。

絕對評分幾乎完全持平。Brain 得分 8.39，Brainless 得分 8.27。也就是在 10 分量表上只差 +0.12。技術上是正向的，但不是那種可以拿來宣布持久記憶已經開啟代理人智慧新時代的結果，除非你跟證據的關係主要只是裝飾性的。

成對比較的結果一開始看起來稍微好一點。Brain 在 53.8% 的比較中勝出。但之後評審顯示有 74.4% 的首位偏誤，這表示原始的成對分數不能直接拿來解讀。如果評審有將近四分之三的機率會選第一個答案，那這個測量工具其實算不上穿著實驗室白袍。它比較像是在擲一枚有偏的硬幣，然後事後寫一段很有把握的解釋。

在控制位置因素之後，大部分所謂的 Brain 優勢都消失了。跨領域遷移沒有保住。反模式避免沒有保住。多技能組合最後崩成擲硬幣。路由結果被混淆了，需要重新跑。

只有一條軌道存活下來：長時間的同領域序列。在那條軌道裡，即使被放在不利位置，Brain 仍有 74% 的勝率。

這才是值得保留的部分。

不是因為它證明記憶在一般情況下有效。它沒有。它證明的是更窄、也更實用的一件事：當輸出依賴同一個持續演變情境中的先前狀態時，記憶似乎有幫助。

這是一個非常不同的主張。

天花板效應就是訊息本身

乍看之下，你可以說 Brain 失敗了。我覺得這樣說太輕率。

更好的解讀是，這個基準測試暴露出錯的記憶類型。OrKa Brain 所召回的大多是程序性知識：如何拆解任務、如何推理權衡、如何避免通用錯誤、如何組織解法、如何把某個領域的模式遷移到另一個領域。

問題是，有能力的大型語言模型早就知道很多這些東西了。它們看過無數架構審查、除錯會議、遷移計畫、支援流程、專案回顧、Stack Overflow 爭論、事故報告、程式碼審查、框架文件，以及各種企業文件——那些會用五頁篇幅說「我們忘了快取」的東西。

所以當記憶層召回一個通用程序時，模型並不會突然拿到缺失資訊。它只是收到一個提醒，提醒它權重裡本來就有的內容。

這就是天花板效應重要的原因。這不只是實作失敗而已。這是一個分類警告。如果記憶存的是通用能力，模型常常可以繞過它，因為模型本來就已經有通用能力。

這也是為什麼「代理人記憶」在 demo 裡會看起來很驚人，到了基準測試卻又莫名其妙地變弱。在 demo 裡，被記住的上下文感覺很有用，因為我們看得見系統在引用過去。在基準測試裡，如果被記住的東西沒有改變答案，效果就會消失在風格、冗長程度或評審偏好之中。

真正有用的問題不是「系統有沒有記住某件事？」

而是「被記住的那件事，是否包含模型不可能知道、或不可能安全推斷出的資訊？」

那才是界線。

記憶是為了偶然性資訊

這個理論更精確的版本是：

當答案依賴於模型權重中不存在的偶然性資訊時，記憶才有幫助。

不是垂直知識。不是領域知識。也不是把「更多上下文」當成萬靈咒。是偶然性資訊。

所謂偶然性，我指的是其真實性取決於某個特定使用者、系統、公司、客戶、程式碼庫、先前決策、在地流程或時間點的資訊。它不是一般情況下為真的資訊。它只在這裡是真的。

模型可以知道軟體遷移通常怎麼失敗，但它不可能知道在這個程式碼庫裡，上一次遷移失敗是因為計費 worker 悄悄依賴了一個已淘汰的 Redis key。

模型可以知道什麼是精簡寫作，但它不可能知道某個特定使用者偏好直接的技術回答，不要贅字、不要假熱情，也不要在段落上噴企業香水。

模型可以知道客服分流通常怎麼做，但它不可能知道這個特定客戶總是用錯產品名稱來回報計費問題。

模型可以知道部署管線通常怎麼運作，但它不可能知道這個團隊避開週五發版，因為某條回滾路徑仍依賴一支沒人想承認存在的手動腳本。

那才是記憶。

其他東西都有可能變成：附著在一個本來就已經有第一份副本的模型上的第二份通用知識副本。

程式碼庫 AI 讓這個區別變得很明顯

拿軟體工程來說，因為這個錯誤在那裡特別清楚。

一個天真的做法會說：「我們需要記憶，這樣模型才知道怎麼寫程式。」這聽起來合理，直到你看見模型本來就知道些什麼。一個能力足夠的模型，對程式語言、設計模式、API 慣例、測試策略、重構技巧、基礎架構模式，以及那些大家都在引用、但整個產業有一半根本不照做的最佳實務墓園，都有廣泛接觸。

如果你用記憶去教它通用軟體知識，你可能會撞上跟程序性記憶一樣的天花板。模型本來就知道函式應該要小、測試應該覆蓋邊界情況、遷移應該可回滾，而且分散式系統很擅長毀掉你的下午。把這些想法存成記憶並沒有太大幫助。它大多只是讓模型用更慢的方式說出它本來就會說的話。

問題不在於模型不懂軟體工程。問題在於它不懂這個軟體系統。

這表示通用工程知識不應該被當成有價值的記憶層。那些東西本來就已經在模型裡了。真正有價值的是程式碼庫的在地形狀：命名慣例、架構疤痕、禁止依賴、部署限制、隱性耦合、不穩定的測試、內部抽象、遺留決策，以及為什麼某個醜陋的函式絕對不能「整理一下」，除非你喜歡看事故報告。

儲存庫檢索的任務，不是提醒模型什麼叫 clean code。它的任務是讓模型看見這個程式碼庫實際上是什麼樣子。

模型可以知道驗證通常怎麼做，但它不可能知道在這個系統裡，管理員角色之所以在兩個服務裡重複，是因為 2022 年有一次遷移只做了一半。

模型可以知道 Redis key 應該有清楚的所有權，但它不可能知道計費系統仍依賴一個已淘汰的快取 key，是因為有個 worker 從來沒搬到新的事件管線。

模型可以知道如何寫資料庫遷移，但它不可能知道這個團隊會避免破壞性遷移，除非回滾計畫已經由那位還記得舊 schema 為何存在的人審過。

這就是記憶真正能派上用場的地方。

風格指南告訴模型程式碼應該長什麼樣。儲存庫歷史告訴它程式碼為什麼長得不對，但還是能用。事故記憶告訴它屍體埋在哪裡。團隊慣例告訴它哪些變更會被接受、哪些會被拒絕，甚至在 CI 還沒來得及抱怨之前就已經決定了。

這些不是同一層。如果把它們當成一坨通用 RAG，大量檢索、理解甚少的系統就會誕生。

在軟體產品裡，這個區別很重要。文件提供基準。儲存庫狀態塑形。事故與決策歷史則施加約束。

如果這三件事混在一起，助手仍然可能聽起來像資深工程師。它甚至可能比以前更像資深工程師，而那通常只是代表它學會了有自信地說出「trade-off」。真正的問題是，它是否理解眼前這個特定系統。

這才是記憶從裝飾品變成有用工具的地方。

聊天記憶也是同樣的模式

這不只是程式碼庫的問題。聊天記憶在更小、更熟悉的形式下，也呈現相同結構。

當系統記住某個使用者喜歡簡潔回答時，它之所以有用，並不是因為模型缺少「簡潔」這個概念。模型本來就知道如何簡潔。真正有用的資訊不是「簡潔是什麼意思？」而是「對這位使用者來說，簡潔是什麼意思？」

那是一個綁定於實體的事實。它把一項通用能力，連到一個特定的人身上。

這也是為什麼個人化可以有用，但不一定顯得多麼高深。價值不在於從零教模型一種新的寫作風格，而在於依照已知身分選擇正確行為。

同樣的事情也發生在公司內部。模型知道怎麼做程式碼審查，但它不知道這個儲存庫因為三年前造成過一次正式環境事故，所以禁止使用某個特定函式庫。模型知道怎麼處理退款，但它不知道年度合作夥伴合約有不同的退款流程。模型知道怎麼摘要顧客抱怨，但它不知道這位顧客總是把正式環境事故說成「小問題」，因為他們客氣到有點自我破壞。

這種在地怪異不是雜訊。它才是工作本身。

真實系統不是只有一般規則。它們是由例外、疤痕、習慣、慣例、先前錯誤、政策捷徑、未文件化的依賴，以及那些人人都知道、直到那個知道的人離職才消失的東西所組成。

那才是記憶應該儲存的材料。

不是通用能力，而是營運沉積物。

這會改變架構

我之前的框架比較像技能重用。代理人學到一項技能，把它存起來，之後再把它召回，用在新任務上。這是一個乾淨的模型。它也可疑地適合畫成圖，這通常就代表我們應該提高警覺。

資料把我推向另一種架構。

記憶系統不應該先問：「有哪個技能跟這個任務相似？」那有時候是有效的，但作為核心檢索原則太弱了。相似不等於必要。一段記憶在語意上可能很接近，但如果它不會改變答案，那就沒有用。

更好的檢索問題是：「關於這個情境，有哪些資訊是模型不可能、安全上也不應該、或成本過高而無法推斷出來的？」

這個問題會改變一切。

你會因為任務依賴某個已知實體而檢索。你會因為答案取決於產品、客戶、程式碼庫、環境、部署目標或團隊慣例而檢索。你會因為使用者有穩定偏好而檢索。你會因為程式碼庫有在地規則而檢索。你會因為客戶有歷史而檢索。你會因為系統以前失敗過、而且那次失敗看起來跟現在相關而檢索。你會因為模型正準備用通用能力回答一個需要特定狀態的問題而檢索。

這跟語意相似度是不同的觸發條件。

真正的觸發條件是不定性。模型可以產生一個答案，但這個答案不足以只靠提示詞與一般知識來決定。它需要在地狀態。

這也表示記憶不該只有一個桶子。一個嚴肅的系統，大概需要分開的儲存區，各自有不同任務。

Grounding 是為了權威性。它提供模型精確來源、最新文件、儲存庫檔案、API 合約、schema、設定，以及可驗證的參考資料。

營運知識是為了在地形狀。它告訴模型這個產品、儲存庫、客戶、工作流程、團隊或部署環境是怎麼運作的。

事件記憶是為了歷史。它告訴模型這個使用者、客戶、任務、工作階段、服務或系統之前發生了什麼事。

推理則把這三者組合起來。

當人們把這些全都塞進「記憶」這個詞裡時，系統會變得更難評估。他們也更容易騙過自己，而這似乎正是代理人出現時，MLOps 的預設流程。

下一個基準應該更殘酷

舊問題是：記憶是否提升輸出品質？這太寬泛了。

如果模型靠通用能力就能答得很好，記憶很難顯示出大幅效果。評審也許會偏好某個答案，但最後你測到的會是風格、冗長程度、格式、位置偏誤，或者評審當天早餐吃了什麼。

下一個基準應該要讓記憶變得必要。

一個任務應該要求某個只存在於記憶或 grounding 的事實。沒有那個事實，模型應該要嘛失敗、要嘛保守回答、要嘛產出通用答案。有了那個事實，模型才應該能正確回答。

不是更漂亮，而是正確。

對聊天助手來說，答案可能取決於儲存的使用者偏好。對程式碼助手來說，答案可能取決於儲存庫特定規則、過去事故、禁用依賴、遷移限制，或存在於模型權重以外的團隊慣例。對客服自動化來說，答案可能取決於客戶特定例外、產品規劃怪例，或先前的升級模式。對路由來說，答案可能取決於同一系統中先前失敗的路徑。

評分不應該是「哪個答案感覺更完整？」那會讓評審偏誤走進房間、坐上桌子，然後開始依據感覺打分。

分數應該要具體。系統有沒有使用正確的儲存庫規則？有沒有遵守部署限制？有沒有記住使用者偏好？有沒有避開已知失敗路徑？有沒有引用最新的內部文件？有沒有保留先前的產品決策？有沒有把通用知識和偶然狀態區分開來？

那才是記憶應該展現真實差距的地方。不是 +0.12 的潤飾差距，而是正確性差距。

如果記憶在那裡都贏不了，那記憶系統大概沒做什麼事。如果它能贏，那它的價值就不再神秘，而是可測量的。

去炒作版的說法

我不認為「記憶讓代理人更聰明」是正確說法。它太模糊了，而模糊的說法正是 AI 炒作會繁殖的地方。

更精準的說法雖然沒那麼聳動，但更有用：當任務依賴於不在模型權重中、而且不能從一般知識安全推斷出的資訊時，記憶才有幫助。

這也解釋了為什麼通用程序性召回幾乎沒帶來什麼變化。它解釋了為什麼長時間同領域召回是唯一存活下來的訊號。它解釋了為什麼聊天偏好很重要。它解釋了為什麼程式碼助手需要儲存庫狀態加上決策歷史，而不只是更多文件。它也解釋了為什麼企業助手只有在知道公司在地怪異時才會真的變得有用。

模型本來就有平均值。

記憶是為了修正偏差。

而大多數真實工作，本來就是偏差。

我想這就是我們一直漏掉的部分。我們一直在打造記憶系統，好像模型是空的、需要被填滿一樣。但模型並不空。它充滿平均值。充滿一般模式。充滿看似合理的程序。充滿那種通常正確、直到碰上真實組織、真實客戶、真實程式碼庫，或真實的人類，還有那些不符合中位數偏好的偏好時，就會失準的答案。

記憶不是拿來跟預訓練競爭的。

記憶是用來在在地情境要求時，修正平均值的。

我現在會怎麼劃界線

我會這樣劃界線。

不要存模型已經知道的東西。不要檢索模型可以安全推斷的東西。不要把通用建議稱作記憶。不要把領域知識和偶然狀態混為一談。

要存的是那些會改變答案的東西，因為它們是特定的、當下的、在地的、個人的、歷史的、程序性的、儲存庫綁定的、客戶綁定的、產品綁定的或系統綁定的。

Grounding 用於權威性。記憶用於偶然性。推理用於組合。

把這三者混在一起，就是在打造一個價格很高的自動補全工具，外加一本剪貼簿。

這個基準並沒有證明記憶毫無用處。它證明的是，記憶必須靠自己爭取位置。如果被記住的東西沒有改變答案，那它在任何有意義的操作層面上都不算記憶。它只是帶時間戳的雜訊。

模型不需要記憶。

情境需要。

原文出處：https://dev.to/marcosomma/the-model-does-not-need-memory-the-situation-does-196g