AI 怎麼「記得」你？

快速摘要：fibon 怎麼把對話變成可檢索的長期記憶——狀態／事件／知識三種卡片、cardinality、五路檢索與衝突仲裁。

可略過，如果：你只要結論「它記得住跨 session 的事實」就好；底層拆解在深入剖析 E。（全站最長的一章——這套記憶系統前後做了 2–3 個月、到現在還沒完全收工，篇幅很長，建議挑有興趣的小節跳著讀。）

問題的開始：一個 Chat 視窗的痛

回想第 1 章開頭的情境：你跟 AI 深入討論了一個複雜主題（例如規劃 5 天京都自由行），一週後想接續：「對了，那次聊到的飯店清單你還記得嗎？」這時通常有兩種狀況：

• 狀況 A：你點開上週同一個聊天視窗 → AI 翻得到歷史紀錄，無縫接續。
• 狀況 B：你隨手開了新視窗 → AI 當場失憶，用第一次見面的禮貌語氣說「請問有什麼我可以幫忙的？」

這兩者的本質差異，技術上稱為「跨 Session（跨對話階段）」難題。

什麼是 Session？

「Session」指一次聊天視窗、或單一條對話串（Thread）。每按一次「開啟新對話」就是啟動一個全新 Session。目前主流 AI 介面（ChatGPT、Claude、Gemini）的設計哲學都是：同一個 Session 內記得前面說過的話；一旦切換 Session，記憶瞬間歸零。

這有工程上的合理性——把記憶限制在單一視窗，可以防止 AI 把三個月前的無關舊話當成當下的背景雜訊。但如果你想把 AI 當作長期相伴的個人助理，這個設計就是災難：你不可能每次見私人秘書都要重新自我介紹「你好，我叫 Aaron，住台灣，正在開發一個叫 fibon 的專案」。真正的助理必須有跨越時間的長期記憶。

fibon 想解決的核心痛點就是這個：怎麼讓 AI 跨越不同對話視窗，也能牢牢記住你。 Smart Chat 模式與整套記憶系統，都圍繞這個目標而生。

記憶的容器 —— fibon 的「專案」

在談記憶卡片之前，得先介紹一個看似微小、實則決定性的容器概念：fibon 的「專案（Project）」。

為什麼需要專案？因為你的人生不是單一主題的線性延伸。此刻的你可能同時在做 5 件不相干的事：規劃京都旅行、學 AI Design Pattern、寫雲地備援技術報告、跟朋友約吃飯、研究房地產。這 5 件事的記憶與脈絡邏輯上互不相干。如果偷懶把所有記憶塞進同一個「大記憶池」，災難很快發生：你問「找一下上次提的飯店清單」，AI 可能從雲地備援報告裡撈出「異地機房的選址清單」；你問「Reflection pattern 怎麼實作」，它搞不好翻出京都旅行的交通規劃。整個記憶庫陷入混沌，每次檢索都帶著大量雜訊。

專案就是一個具「物理隔離」功能的主題資料夾。 你建一個「京都行 2026」專案，從這刻起所有關於這趟旅行的對話、事實、知識都會被自動貼上這個專案的標籤；切換到「AI Design Pattern 學習」時記憶池完全切離。每張卡片在資料表裡都帶一個硬性的 project_id，撈取記憶時預設只檢索當前專案的卡片，其餘專案的記憶在物理上被天然隔離。

fibon 記憶的三塊基磚

講完容器，核心問題是：專案資料夾裡要裝什麼形狀的資料？答案是三種小卡片。

這也是這一整章的核心主張，先把話講白：長期記憶不該儲存「對話紀錄」，而該儲存「狀態、事件與知識」。 更完整地說——長期記憶不是把對話存起來，而是把事實變成可老化、可取代、可追溯、可仲裁的結構；而且這套結構必須經過縱向測試，否則它會在短期 demo 裡看似正常、在長期使用中悄悄腐爛。這一章接下來，就是逐一兌現這四個形容詞。

這三類卡片不是憑空發明的。設計它們時，我問自己的第一個問題是：「一個會被長期記住的東西，到底由哪些成分組成？」我拿自己最熟悉的場景——軟體開發——來解構。一個專案從需求分析、系統分析、開發、除錯、部署到迭代，這條路上會留下什麼？團隊的每一次溝通、每一次需求變更，是發生過就不會再改變的「事件」；專案此刻支援哪些功能、跑在哪個版本，是隨時會更新的「狀態」；而這個專案為什麼存在、用了哪些原理、解掉了哪些問題，是沉澱下來的「知識」。還有一個成分藏在所有東西底下——「時間」：每一次溝通有時間點、每一個狀態有生效區間、每一條知識有學會的那一天。事件、狀態、知識，加上貫穿三者的時間——至少到目前為止，我還沒遇過什麼事情不能用這四個成分解構。這就是這套卡片系統的由來。

至於「卡片」這個形式，靈感則是從現代筆記方法論借來的：

人類記錄與反芻知識時，寫短小的「小卡片」遠比寫長文高效——卡片資訊密度高、好搜尋、易重組。fibon 把同樣的哲學套到 AI 記憶：把漫長對話拆成一張張原子化小卡，而不是塞整段歷史。

為什麼「小卡片」對 LLM 更好？ 這是我設計記憶系統時的核心假設：「輸入資料量越小、事實越精準，LLM 幻覺機率就該越低。」理由是 LLM 極易被無關廢話干擾——對話歷史一大坨塞進去，重點就被稀釋（業界有著名論文 Lost in the Middle：LLM 面對長上下文時最容易漏掉藏在中段的關鍵資訊）。短而精純的結構化卡片（例如 [現任公司: Anthropic]），比一大段長對話更能讓 LLM 一眼抓到核心。換句話說，與其把整段聊天丟進向量資料庫做粗暴全文檢索（撈出來仍是帶廢話的段落），fibon 的結構化提取（卡片化）就是專門對抗 Lost in the Middle 的工程補丁——在後台把事實的骨肉分離，只把濃縮精華餵給 LLM。

fibon 的三類卡片

為了模擬人腦記東西的真實模式，卡片分三大類：

表格裡少了一個成員——時間。它不是第四種卡片，而是藏在三類卡片底下的第四個維度：事件卡的發生時間、狀態卡的生效與過時區間、知識卡的學習與更新軌跡，全部釘在同一條時間軸上。它太重要，後面有兩處會專門處理它（狀態卡規則三的記憶半衰期、以及「時間錨定」一節）；在這裡先點名，是因為讀後面所有設計時，你都該帶著這個意識：每一張卡，都活在時間裡。

狀態卡 vs 事件卡 —— 解構「專案狀態」

這兩種卡乍看很像，但解的是完全不同的認知痛點。用一個真實情境對比：假設你開了「fibon 開源計畫」專案，過去兩個月發生了：

• 2026-03-01：專案啟動，目標 2026-07 開源。
• 2026-04-15：架構會議決定引入技能合規驗證（Skill Compliance）。
• 2026-04-30：自我進化是否啟用的決策：選 B 路徑，降級為安全參考設計。
• 2026-05-05：Aaron 開始動筆寫這份設計日誌。

問以下兩個問題，大腦檢索記憶的路徑截然不同：

問題 A：「fibon 現在的進度走到哪了？」 需要的是【狀態卡】。AI 不必翻兩個月的對話，只需要此刻唯一的真相：

[狀態卡：fibon 開源計畫]
當前階段     = 開源前驗收
最後更新時間 = 2026-05-05
下一個里程碑 = 2026-07 開源

這張卡會隨時間不斷更新——上個月的「前一輪收尾中」會被取代。你問的當下，系統回給你的永遠是此刻為真的最新版本。

問題 B：「當時為什麼決定不啟用自我進化？」 需要的是【事件卡】。「現在的狀態」回答不了，AI 必須把時鐘撥回過去，找那個座標軸上永遠不變的事件：

[事件卡：2026-04-30 決策會議]
發生事件     = 自我進化是否啟用的三選一方案評估
最終決策     = 選擇 B 路徑（降級為安全參考設計）
決策核心原因 = 安全敘事風險最低、工程實作成本最低

這張事件卡永遠不會被覆蓋——歷史已發生，不容篡改。三年後回頭查，2026-04-30 那天的事實依然躺在那裡。

為什麼架構上必須把兩者分開？ 只用一種卡會引發認知崩潰：只用狀態卡，歷史事件全消失，永遠無法回答「當時做某決策的動機與脈絡」；只用事件卡，歷史事實無限重疊，你想知道「現在最新地址」時，AI 得把過去 10 年搬家的所有事件讀完、自己推導。

所以兩者各司其職：狀態卡可被替換，回答「現在」；事件卡只允許累積，回答「過去」。 兩者還能跨卡連結——例如 2026-04-30 的【事件卡】會用一條指針指向並影響【狀態卡】的 [自我進化狀態 = 未啟用]。

狀態卡的四條核心維運規則

因為狀態卡「會更新、會替換、會衰減」，為防事實錯亂，底層為它刻了四條硬性規則。

規則一：分叉式取代機制（Supersede-Fork）

狀態卡會更新這件事帶著一個哲學漏洞：「fibon 當前階段是開源前驗收」這句話從哪天起為真？又從哪天起不再為真？不記時間，歷史審計就毀了。所以每張狀態卡都帶兩個時間戳：

[狀態卡：fibon 開源計畫]
當前階段             = 開源前驗收
生效時間 (effective_at)  = 2026-05-05  → 從這天起為真
過時時間 (superseded_at) = NULL        → 依然為真，尚未被取代

階段改變時，舊卡絕不 Delete，而是被「標記過時（Superseded）」：

[舊狀態卡 - 標記過時]
階段     = 前一輪收尾
生效時間 = 2026-04-15
過時時間 = 2026-05-05   → 從這天起，此事實不再為真

[新狀態卡 - INSERT 寫入]
階段     = 開源前驗收
生效時間 = 2026-05-05
過時時間 = NULL

兩筆事實同時並存在同一張表內，就像修訂法律——舊法條不會被扔進焚化爐，而是標註「本條已於某年某月由新法取代」。問「現在進度？」→ 篩選 WHERE superseded_at IS NULL 回傳最新卡；問「2026 年 4 月時的進度？」→ 走時序歷史檢索，找滿足時間區間的卡。這就是事實稽核（Fact Auditing）：歷史可追溯、現況可確認。

規則二：分身規則 —— 會替換（Single-Value）vs 會累積（Multi-Value）

處理新記憶時，必須區分事實的基數性（Cardinality）：

• 「會被替換」型（single_value）：居住地址、職稱、瀏覽器偏好、現任公司。有新資料進來就觸發上述 Supersede-Fork，把舊事實打入冷宮。
• 「會持續累積」型（multi_value）：技術選型、興趣、技能、討論過的話題。你寫了「用了 PostgreSQL」，隔天又寫「也用了 Redis」，兩者並存。

寫入時，衝突仲裁器（conflict_resolver）先看卡片的 Cardinality 屬性決定路線。這裡要劃清一條容易混淆的邊界：規則一的 Supersede-Fork 是 single_value 卡的專屬待遇（由 SUPERSEDE_FORK_ENABLED 旗標把關）；multi_value 卡若內容是全新事實就直接 INSERT 一筆並行資料，撞到同名舊卡要更新時則不分叉，走「就地後蓋前」、並在 card_update_log 留下一筆審計紀錄。

規則三：記憶的半衰期（Half-Life Decay）

光區分替換或累積還不夠，時間是記憶最大的敵人。30 天前寫的「專案預計 7 月開源」今天仍高度相關；6 個月前隨口說「最近改用 Firefox」今天大概率過時；6 個月前說「熱愛 Python」今天大概率仍成立。不同類型事實的衰減速度（半衰期）完全不同。撈取記憶的分數公式裡引入了數學指數衰減：

最終相關性分數 = 原始向量分數 × e^(−λ × Δt)
（Δt = 卡片存放天數，λ = 衰減係數）

透過這個補丁，90 天前的 [Firefox] 分數被嚴重打折，讓今天的 [Chrome] 輕鬆勝出；而 90 天前的 [熱愛 Python] 仍保留 0.64 的高權重，與今天的 [想學 Rust] 同時被撈出。

老化警告（Aging Facts）：為了更逼近真實助理，引入老化警告機制：若某張會替換型狀態卡躺在資料庫超過 180 天沒被重新驗證、也沒被新數值取代，被撈出來時系統會自動塞進 <aging_facts> 區塊，AI 回應時就會主動確認：「Aaron，我記得你之前住台北，這個資訊過了半年還準確嗎？」

規則四：主動衝突仲裁（Conflict Arbitration）

如果同一事實在兩次對話中嚴重矛盾（昨天說 fibon 預計 7 月開源，今天卻說改 8 月），系統該聽誰的？多數做法是「後浪推前浪」——用今天的粗暴覆蓋昨天。但這有巨大漏洞：萬一是你今天隨口說錯了？萬一是 LLM 把前後文搞混、產生提取幻覺？

fibon 認為系統不該自作主張替用戶決定，遇到真衝突就該舉手發問。三層衝突過濾網：

1. 同輪自我更正：同一次對話裡剛說「我住台北」又馬上打「打錯了是高雄」→ 直接覆蓋，不打擾用戶。
2. 跨對話低頻改動：30 天內改動 < 3 次 → 判定為正常事實演進，自動處理不打擾用戶——single_value 卡（開 SUPERSEDE_FORK_ENABLED 旗標時）走規則一的 Supersede-Fork 保留歷史；multi_value 卡則就地後蓋前，並在 card_update_log 留審計紀錄。
3. 高頻或跨度極大矛盾：改動時間 ≥ 30 天，或頻繁修改 ≥ 3 次 → 立即打入「仲裁等待佇列」。

觸發第三種時，前端會亮起「衝突仲裁面板」，秀出兩條打架的事實，彈三個按鈕讓你裁決：[保留舊事實] / [接受新事實] / [判定為兩者並存]。

最後一道防線——矛盾偵測（Contradiction Detector）。 撈取記憶完成的千分之一秒內，後端做最後掃描。若發現要放進 Prompt 的卡片中，有兩張標籤一樣但內容打架（例如同時撈出進度「收尾中」和「已驗收」），底層會在系統提示詞注入 <contradiction_alert> 區塊，AI 看到後會主動確認：「Aaron，我的記憶庫裡同時出現這兩個矛盾的進度，請問以哪個為準？」這是進入仲裁佇列前的最後一道防線。

時間錨定 —— 「今天」這個詞究竟該釘在哪？

前面都在講卡片內部規則，但有一個跨越所有卡片的時間硬傷：當你對 AI 說「今天我搬家了」，這個「今天」到底指哪一天？

絕不能直接存成字串「今天」。 初學者最直覺的錯誤是把用戶嘴裡的「今天」當字串存進資料庫。這會時空錯亂：昨天的今天叫昨天、明天的今天叫明天。一週後 AI 撈出這張卡讀到「今天搬家」，會誤以為是「正在讀卡片的這天」搬家，整條時間線錯亂 7 天。所以「昨天、明天、上週、下個月、這週末」等相對時間，必須在對話發生的那一秒就被解讀並釘死成絕對日期（如 2026-05-07），不允許延後處理。

LLM 自己沒有「時間感」。 更頭痛的是，LLM 是一個沒有手錶的盲人：它的訓練資料時間戳停在過去，呼叫 API 的當下它根本不知道「現在是幾年幾月幾號」。不給它配手錶，它抽卡時就無法把相對時間換算成絕對時間。

fibon 的解法：寫入端的時間釘死流程（Ingest Flow）

每次使用者按下送出、對話進入後台做記憶內化提取（Ingest 流程）時，底層連環發動：

1. 抓當下時鐘：依用戶端時區（如 Asia/Taipei）取得伺服器當前本地精準時間。
2. 強行配手錶：在組裝給 LLM 的 System Prompt 注入動態時間標籤 <current_time>2026-05-08T16:44:10+08:00 (Asia/Taipei)</current_time>（嚴守 ISO 8601 格式）。
3. 強迫 LLM 在提取時完成時間解算：命令 LLM 抽卡時輸出一個自訂的發生時間提示欄位（程式碼中叫 occurred_at_hint），看著手錶把相對詞換算成絕對日期（把「昨天」輸出成 2026-05-07）。
4. 資料庫硬性寫入：後端解析 Hint 後轉成 Time Stamp 寫入卡片的 occurred_at。萬一 LLM 解析失敗，後端立刻安全降級，強制改用訊息進後台那一刻的時間戳寫入——寧可一天的粗糙誤差，也不弄丟時間軸。

prompt_builder.py 的防護規則寫死了一條鐵律：「當使用者提及『今天 / 昨天 / 上週 / 下個月 / 週末』等相對時間詞時，必須無條件以動態注入的 <current_time> 標籤為唯一基準解讀換算。」

讀取端的時間範圍查詢（Retrieval）

一旦寫入端日期全變成絕對日期，讀取端查詢就很優雅。用戶開新視窗問「我昨天做了什麼？」——查詢當下 <current_time> 是 2026-05-08，大管家看著手錶把「昨天」翻成 2026-05-07，後端直接拿這個絕對日期對 occurred_at 發動 SQL Range Query（範圍查詢）。寫入端與讀取端各握一隻精準的動態時鐘，時空交錯問題被徹底消解。

第三類卡片 —— 知識卡

前面幾節講的都是「事實層面」的記憶（狀態卡與事件卡）。但人腦還裝著另一種更高階的財富：抽象概念與客觀知識。你搞懂了 [JWT 的無狀態認證原理]、梳理出 [伏見稻荷大社的完美交通路線]、辨析了 [Plan-Execute 與 ReAct 架構的本質差別]。這些不是「現在為真的個人事實」，也不是「過去的單一事件」，而是高密度抽象知識，可跨會話引用、雙向連結、隨時間深化。這就是 fibon 的第三類卡片：【知識卡】。

知識卡的終極目標：長出你專屬的「個人知識庫（Personal Obsidian）」

靈感來自筆記軟體 Obsidian 的雙向連結與圖譜視覺化。在 fibon 的願景裡，你每次對話、研究、爭論，fibon 的後台會自動把有價值的知識點淬煉成獨立的概念知識卡，卡片之間像神經網絡一樣自動拉起 related_to 雙向引用邊。隨時間推移，後台會長出一張完全屬於你的「數位大腦知識圖譜」。

先說清楚定位：這一節畫的是願景。知識卡的功能本身已經蓋好、也在開源首發版打開了（見章末實作細節 2），但「它真的有讓 AI 答得更準、更省嗎」這個效果問題，還沒經過扎實的實測驗證——以下講的是它該帶來什麼，而不是已經量到手的結論。

其中我最看重的一塊是知識的復用，背後有個常被忽略的成本結構：對 LLM 來說，讀進去的 input token 遠比生成出來的 output token 便宜（多數供應商 output 單價是 input 的好幾倍）。所以如果一個知識點第一次被想清楚、就淬煉成一張卡存起來，下次再用時只要把這張現成的卡當 input 讀回去，不必讓 LLM 從頭重新「想」一遍、「寫」一遍——省下的正是最貴的那段 output。知識卡復用賭的就是這個槓桿：把昂貴的「重新生成」換成便宜的「讀回現成答案」。這筆帳一樣要等真實流量才能蓋章，目前是一個有方向、待量測的設計。（這條「output 比 input 貴、復用省的是 output」的完整帳本，見深入剖析 C：Token 經濟學。）

知識卡最難的地方：怎麼不讓它長成垃圾場

狀態卡有「唯一現值」可以收斂、事件卡有「時間軸」可以定位，但知識卡兩者都沒有——知識沒有客觀唯一答案，而且會隨時間演化（JWT 的最佳實踐、Reflection pattern 的寫法、DDD 的詮釋，每一兩年都在變）。放著不管，知識卡很快會長成一堆重複、過時、互相矛盾的爛卡，那就不是資產而是負債了。這也是知識卡比狀態卡、事件卡更難、也更晚通電的根本原因。fibon 目前靠三道機制壓住這個熵增：

1. Tag 正規化：語意相近的標籤自動合併，不讓 JWT 和 json web token 裂成兩張卡、各自長出一棵互不相認的樹。
2. 新鮮度標記：超過 90 天沒被重新驗證的卡，被撈出來時自動標上「此摘要可能已過時」，AI 引用後會主動問你要不要重驗，而不是把舊知識當新的講。
3. 綁定事件卡：每張知識卡都連回「你在哪幾次對話真的討論過它」，讓它有出處、可追溯，而不是憑空長出來的孤兒卡。

但老實說，這三道只是「延緩腐爛」，不是「保證新鮮」。知識卡會不會在更大規模、更長時間下還是劣化成垃圾場，是我還沒驗證、卻也最想繼續解的開放難題。

知識卡與事件卡的結合

這種多維結構最迷人的地方，在於知識與經歷互相同步參照：

[知識卡：JWT (JSON Web Token)]
定義     = 一種基於 JSON 的輕量級、無狀態身份認證機制。
關聯概念 = [OAuth 2.0]、[Session-based Auth]、[Bearer Token]
↓ [ 該知識卡在你的生命中，曾被以下事件討論並見證過 ]
- 事件卡 #001 (2026-03-15)：與 Claude 激辯 fibon 認證系統該選 JWT 還是 Session。
- 事件卡 #002 (2026-04-02)：深夜修復一個隱蔽的 JWT Refresh Token 過期 Bug。
- 事件卡 #003 (2026-04-20)：在公司架構雙週會上拿這張卡向組員講解認證對比。

這意味著你的 AI 助理不只記住技術的客觀定義，還記住「你與這項技術在過去發生過哪些真實故事」。下次你在新視窗問「JWT 到底該怎麼用？」，它的回答會是：「Aaron，你在 3 月和 4 月一共與我討論過 3 次 JWT。簡短複習核心定義……你今天想深入哪一部分？是 3/15 為 fibon 做的那套認證架構，還是 4/2 那個讓你頭痛的 Refresh Token 過期 Bug？」這才是親手幫每位用戶長出個人知識庫的浪漫。

跨越三類卡片的 3 × 6 多維幾何結構

到這裡記憶版圖已經完整：3 種原子化卡片，搭配狀態卡內部的四條規則。但真正的架構優勢在這：每一張卡片不論屬於哪一類，底層都被硬性橫穿 6 個跨卡片的幾何座標軸（6 Dimensions）。

主流 AI 記憶系統（LangChain memory、Letta、mem0）的底層 Schema 幾乎都是平面、一維的「事實清單（Fact Rows）」——一筆資料就是一條事實，缺乏多維座標。fibon 從第一天就走多維結構：3 種原子卡片 × 6 個跨卡座標軸 的幾何立方體。先澄清一句：這 6 個軸是邏輯座標，不是同一張表上並排的 6 個欄位——時間、範圍、來源、信心軸的欄位長在卡片本身，關聯軸住在獨立的 card_relations 關係表，概念軸則由扁平 tags 與知識卡 link 表共同撐起。下表是各軸在 PostgreSQL 的物理落點：

這種「3 × 6 結構」怎麼玩？ 有了這個 OLAP 立方體（線上分析多維立方體）一樣的 Schema，可以對記憶做任意維度切片、切塊與聚合：

• 「找出這個月新建的所有知識卡。」→ 鎖【概念軸】為知識卡 + 用【時間軸】切當月區間。
• 「研究小助手抽的卡 vs 程式小助手抽的卡各佔多少？」→ 用【來源軸】agent_id 做 Group By。
• 「揪出哪些事實是 AI 自己推論出來、而不是我親口說的？」→ 用【信心軸】篩 provenance = 'agent_inferred'，再搭配 inference_confidence 看推論信心分級。
• 「與『JWT』關聯最強、又邏輯互相矛盾的卡有哪些？」→ 鎖【概念軸】為 JWT + 用【關聯軸】拉 contradicts 的邊。

這些多維查詢，在 LangChain 或 Letta 的平面 Schema 裡根本寫不出來，因為他們的資料結構沒預留這些軸線。

看不見的後台硬功 —— 撈記憶時的「五路融合檢索」

前面都在解決「怎麼把記憶存得精準」。當用戶發問時，「怎麼把記憶撈得無懈可擊」是另一套硬功夫。

最平庸的作法是：提問 → 轉 Embedding 向量 → 算向量相似度（Cosine） → 撈 Top 5 餵給 LLM。這種純向量檢索在複雜的個人助理場景會漏成篩子，因為它對「精確項目程式碼比對」遲鈍、對「中文錯字/罕見詞」易脫靶、對「我昨天做了什麼」這種時間查詢沒輒、也不具備「沿知識圖譜做關係展開」的能力。所以 fibon 的檢索後台走「五路平行召回與融合架構」：

                     [ 用戶輸入提問 (User Query) ]
                                 │
  ┌───────────┬───────────┬─────┴─────┬───────────┬───────────┐
  ▼           ▼           ▼           ▼           ▼
1.語意相似度  2.標籤精確   3.雙引擎模糊  4.時間區間   5.圖譜關係展開
 (pgvector)  (Tags Exact)(bigm+trgm) (Temporal)  (1-hop Graph)
 [ Top 20 ]  [ 全數揪出 ] [ Top 20 ]  [ 命中區間 ] [ 5 seed ≤30 ]
  └───────────┴───────────┴─────┬─────┴───────────┴───────────┘
                                 ▼
               [ 互惠排名融合算法 (RRF, k=60) ]
                 (多評審投票制；掛掉的路自動略過)
                                 ▼
               [ 後端核心重排與後處理過濾網 ]
                 - 依狀態卡 Cardinality 與時間進行數學衰減
                 - 當前對話情境層 (Scope) 加權提分
                 - 剛寫入但尚未落盤記憶的「同輪覆蓋 (RYOW)」
                 - 強制剔除 superseded_at 已過時的殭屍卡
                 - 最後防線的「矛盾偵測」與「老化警告」
                                 ▼
                   [ 篩出最精純的 Top 5 條記憶 ]
                                 ▼
                   [ 送入 System Prompt 餵給 LLM ]

五路各司其職、互補短長：

• 語意相似度：對「我之前提過跟程式語言相關的牢騷嗎？」這種沒關鍵字的感性查詢很有效。
• 標籤精確匹配（中文要先斷詞，要特別說明）：下精準指令或過濾時，能一條不漏把 #python 的卡全揪出。但中文有個前置難題——句子裡字與字之間沒有空格，得先把句子斷成「詞」才能跟標籤比對。這一步用 jieba（結巴） 斷詞，並掛上中研院釋出的繁體強化字典 dict.txt.big（jieba 預設字典偏簡中，會把「資料庫」「牛肉湯」這類繁中複合詞切壞）；英文本來就用空格分詞，jieba 直接 pass-through。斷出來的詞再去精確命中卡片標籤。
• 雙引擎模糊比對（字元層級，刻意不斷詞）：標籤那條走的是「詞」，但用戶常打錯字、用罕見詞或縮寫，這時斷詞反而會卡住。所以這一路乾脆不斷詞，改在字元層級做模糊比對；而中英文的字元粒度又不一樣，於是同時掛兩套 PostgreSQL 擴充並行：中文用 pg_bigm 以「相鄰兩字一組」（bigram，例如「記憶體」→「記憶」「憶體」）比對，最擅長抓中文錯字、人名、罕見專有名詞；英文／拉丁字母用 pg_trgm 以「相鄰三字母一組」（trigram，例如 cat → c,ca,cat…）比對。兩個述詞 OR 在同一條 SQL 裡，由 PostgreSQL 的 bitmap OR 同時掃兩座 GIN 索引、再取兩邊較高的相似度分數（GREATEST），讓中英文查詢都不漏接——也是向量模型「通靈失敗」時的保底。
• 時間區間查詢（PR-5）：把問句裡的時間表達式（「上週」「四月時」「上個月到現在」）解析成絕對日期區間，直接對卡片的 effective_at / occurred_at 撈落在區間內的卡。這條路正是前面〈時間錨定〉那套「寫入端把相對時間釘死成絕對日期」的回收——讓「我昨天做了什麼」這種查詢走專屬時間軸，而不是逼語意向量去硬猜。
• 圖譜關係展開：以其他幾路撈回的前 5 張卡為種子（seed），沿關聯軸向外踩一步（1-hop Graph Walk），單次展開最多拉回 30 個鄰居節點（硬性 200ms 逾時保護），把與當前話題高度相關、但字面不沾邊的隱性知識卡（聊到 JWT 時把 [OAuth 2.0]）扯出來。

這套架構還有高可用容錯：若五路中任一路掛掉（向量索引 HNSW 正在重建、或中文 bigm 模組當機），其餘四路立刻接手投票。內建一個自適應監控模組，為每一路維護最近 10 筆耗時樣本的滑動窗：窗內 P95 一旦超過 150 毫秒，就把該路降級隔離 10 分鐘；隔離期間只要新樣本讓 P95 回落到門檻之下，旗標立即解除、該路馬上歸隊，保證前端對話不卡死。

一個有趣的後處理細節：讀你剛寫的記憶（Read-Your-Own-Writes, RYOW）：高併發系統有個經典 Bug：你這一輪剛說「我搬家了，新地址是高雄」，下一秒馬上問「我現在住哪？」由於那條新記憶還在後端非同步寫入佇列（Ingest Queue）、還沒寫入 PostgreSQL，讀取端撈出來的仍是舊的「台北」，AI 就給出錯誤的舊答案。fibon 不採用沉重、容易在分散式節點炸裂的「跨流程資料庫事務鎖」，而是輕巧地在最上層加「同輪覆蓋快取機制」：五路融合檢索結束後，程式檢查當前 Session 裡有沒有剛從前端送進來、還卡在 Ingest 佇列尚未落盤的熱記憶；一旦發現，直接在記憶體裡覆蓋掉撈出來的舊地址。用最輕量的程式碼解掉這個「記憶時差」Bug。

為什麼這套龐大的記憶系統對 fibon 至關重要？

在逐一回扣目標之前，先把整章拆開講的東西收成一張圖——一輪對話從「發問」到「回答」、再到背景「內化成卡片」的完整鏈路，以及 5 個 LLM／Embedding 呼叫各自發生在哪、在做什麼：

sequenceDiagram
  participant User as 使用者
  participant GW as 網關 (Gateway)
  participant BR as 核心大腦 (Brain)
  participant PG as PostgreSQL (卡片庫)
  participant RD as Redis (Ingest 佇列)
  participant LLM as 雲端模型

  User->>GW: 發問「我昨天做了什麼？」
  GW->>BR: gRPC SubmitTask

  Note over BR,LLM: ① 讀取・把問句轉成向量
  BR->>LLM: Embedding(問句)
  LLM-->>BR: query 向量
  Note over BR,PG: 五路平行召回<br/>(jieba 斷詞→標籤 / bigm+trgm / 時間區間 / 圖譜 / 向量)
  BR->>PG: 五路查詢卡片
  PG-->>BR: 候選卡片
  Note over BR: RRF 融合 + 衰減/情境重排 + RYOW 同輪覆蓋<br/>→ 篩出 Top 5 卡片
  Note over BR,LLM: ② 生成・Top 5 卡片注入 System Prompt
  BR->>LLM: 生成回答 (Reasoning 模型)
  LLM-->>BR: 回答
  BR-->>GW: 串流回答
  GW-->>User: 顯示答案

  Note over BR,RD: 回答後・這輪對話丟進背景 Ingest (fire-and-forget)
  BR->>RD: 推入 ingest_stream
  RD->>BR: consumer 取出
  Note over BR,LLM: ③ 抽卡・對話→狀態/事件卡，把「昨天」釘成絕對日期
  BR->>LLM: Ingest 抽卡 (Haiku)
  LLM-->>BR: 結構化卡片 + occurred_at
  Note over BR,LLM: ④ 把卡片內容轉成向量
  BR->>LLM: Embedding(卡片)
  LLM-->>BR: 卡片向量
  Note over BR,PG: 衝突仲裁 (cardinality → supersede-fork / INSERT)
  BR->>PG: 寫入卡片 + tags + 向量
  Note over BR,LLM: ⑤ 淬煉知識卡 (Haiku)
  BR->>LLM: 知識卡抽取
  LLM-->>BR: 知識卡
  BR->>PG: 寫入知識卡 + related_to 邊

一句話看懂 LLM 花在哪：讀取端只花 ① Embedding ＋ ② 生成 兩次（②生成才是貴的 output token）；寫入端在背景花 ③ 抽卡 ＋ ④ Embedding ＋ ⑤ 知識卡，全部 fire-and-forget、錯誤不阻塞你的回答。五路檢索本身不呼叫 LLM——jieba 斷詞、bigm/trgm、時間區間、圖譜都是 PostgreSQL 本地算。

回到第 1 章立下的四個目標：

目標 2：精準篩選給 LLM 的資訊（看更少，看更準）。 時間分叉取代（Supersede-Fork）、事實基數性隔離（Cardinality）、生活情境層加權、專案範圍物理隔離，全都是為了在後台幫 LLM 築過濾網——把不相關的舊雜訊擋在外面，確保送進 Context Window 的永遠是經嚴密計算、最精準、當前為真的 5 條核心卡片。

目標 3：降低 Token 成本（設計目標，仍在驗證）。 機制上永遠只精選 Top 5 條高密度卡片、而不是塞 50 條長文，衰減到谷底或已過時的舊卡連踏進 Prompt 的資格都沒有——當輪送進去的記憶確實精簡。但如同前面誠實防線所說，把背景抽卡與各種注入區塊的成本算進總帳後，端到端到底淨省多少還沒有定論，這筆帳正在重新量；未來知識卡的「先查本地庫、沒過時直接用」打通後，預期能再省一截。

第 1 章開頭那個「對話 UX 不太對」的痛點，在這章得到了一個至少看起來可行的解答：跨 Session 失憶 → 卡片永久落盤，換一萬個視窗也能精準召回；捲軸找不到舊資料 → 結構化 3 × 6 多維存儲，可精確維度切片查詢；「重新問一次就好」的浪費 → 知識卡願景要靠本地高速快取，終結通用知識的重複運算。

我刻意說「至少看起來可行」——因為這一章拆的全是後端的基底，而這個基底，到這裡算是搭起來了：資料結構、五路檢索、衝突仲裁、時間錨定，都已經是跑得動的程式碼，不是投影片上的方塊。但下一個、而且可能更大的坑是 UI/UX：怎麼把這套多維記憶「長」成使用者能看見、能探索的介面。我腦中構想的那種呈現方式，市面上我還沒見過類似的設計（也可能只是我見識淺），所以沒有前人鋪好的路可以抄——基底完成只是拿到了入場券，把它變成普通人用得順、看得懂、甚至覺得有點酷的體驗，才是下一段真正的硬仗。

誠實列出目前還沒解完的難題

老實說，這套記憶系統開發中期曾遇到一個巨大盲點——多輪長對話中「撈記憶 → AI 回應 → 用戶基於回應追問 → 再次撈記憶」這條鏈路的多輪化學反應。最初在 Smart Chat 核心主測試輪跑了 71 個單輪測試（問一題、答一題、立刻結算），拿到振奮的 +23.9pp 能力提升（大幅領先沒有記憶系統的原生對照組）。但單輪測試再漂亮，也無法驗證真實的 10 輪來回對話中，記憶會不會隨上下文拉長而扭曲。

而真正反直覺到我重看三遍的，是另一個案例——

多輪測試成本很高（每跑一次要 5 到 10 倍 Token），且測試設計本身極難——「什麼才是最完美的多輪對話行為」世界上沒有標準答案，只能靠工程紀律做最理性的裁決。另外，〈第三類卡片——知識卡〉那節的兩端鏈路已完工（ADR-014 的 Schema、Gateway API、前端 UI、Brain 端「對話自動抽卡」與「注入 System Prompt」都已進主分支），KNOWLEDGE_EXTRACTION_ENABLED / KNOWLEDGE_INJECT_ENABLED 兩個旗標也已在開源首發版翻成預設開啟。個人知識庫正式上線，抽卡品質與 Token 成本則改為一邊跑一邊持續觀察、隨時準備微調或回退。

實作細節

[ AgingBench 縱向修復戰報 ]
• 標記過時的卡片數量：從原本的「0」張 ──> 上升到「15」張
• 改寫召回率 (Revision Recall)：
  - 修正前：d0: 0.65 ──> d2: 0.00 ──> d4: 0.00 (徹底癱瘓)
  - 修正後：d0: 0.65 ──> d2: 0.54 ──> d4: 0.41 (成功回推通車)
• 干擾老化 (Interference) 也得到連帶拯救：
  - d2 階段召回率從 0.14 一口氣拉抬到 0.64！

下一章，正面迎擊 AI Agent 圈最不願面對的房間裡的大象——為什麼 LLM 說的話、給的承諾，在底層連一個字都不能盲信？ 將完整揭曉 fibon 如何用冷酷的「合規審計架構」，強行稽核並確認：AI 真的有照你給的說明書（Skill）老實做完每一步。