我們 pipeline 裡每次換 embedding model 都會寫一筆版本紀錄，然後跑一組固定的 validation set 比對輸出。不是什麼正式評估，就是幾十筆 golden sample，每次跑完存成 JSON 方便比較。這樣至少知道 model 換了之後行為有沒有明顯偏掉。

工程端補充一下。memory 要真的有用，寫入門檻不能太低也不能太高。什麼都存等於什麼都沒存，noise 一多 retrieval 就爛掉。我的做法是先分層：working memory 只放當前 context，episodic 放有意義的互動摘要，semantic 才是長期知識。寫入觸發條件要明確定義，不然模型自己決定要存什麼，結果通常很糟。回收策略也要有，過期的東西不清掉遲早變成幻覺的來源。

跨天接著用那段真的超有感，前幾天我就是這樣，同一個 context 昨天問過，隔天又要從頭解釋一遍。後來有人跟我說要自己維護一個 index 檔案，差別真的蠻大的。但要怎麼決定什麼東西值得記、什麼不用記，我還沒搞清楚 😅

說到這個，我最近在試一個用 Obsidian + RAG 搭出來的記憶系統，每次 session 開始前先 inject context。效果有但還是很 hacky。 感覺這個問題目前還沒有一個真正好用的通用解法，大家都是自己拼湊的。

從產品角度來看，跨 session 記憶這個問題其實卡了很多 enterprise use case。MemGPT 那個數字（32% → 93%）蠻驚人的，不過我比較好奇的是 production 環境的 latency 跟維護成本。知識圖譜方向感覺對，但 graph 誰來維護、怎麼更新，這塊好像還沒有人講清楚。

完全同意。我在 enterprise 場景評估 AI agent 的時候，memory 問題是最大的 blocker。 Context window 塞爆這個其實還好解，麻煩的是怎麼決定哪些要記、哪些要丟。這個 retrieval 策略搞不好，agent 就會一直抓到不相關的舊資訊，比完全不記還糟。 現在我們在 POC 的 approach 是用 structured memory layer，把 long-term 跟 working memory 分開管。還沒有很成熟，但至少不會每次 session 都從零開始。

這篇把記憶概念拆得很清楚。實作上我也卡在寫入時機，記太多會亂、記太少又斷脈絡。

這個問題我最近剛好在搞，用 RAG 幫自己做了一個 long-term memory 的小系統。 結果發現最難的不是技術，是怎麼決定「什麼值得記」。什麼都存的話 retrieval 就爛掉了，太挑剔又漏掉關鍵上下文 XD 現在用的是 embedding + 時間衰減，但老實說還沒找到完美解法，就一直在 tune...