跳至主要內容
作品集 ©2026
已上線共同創辦人 · 架構與 Python SDKMay 2025 — 至今
GitHub

MemFuse — LLM 記憶基礎設施

面向 LLM 的開源記憶基礎設施，具備認知架構、智慧緩衝與統一搜尋——解決困擾每個 AI 應用的無狀態問題。

面向 LLM 的開源記憶基礎設施，具備認知架構、智慧緩衝與統一搜尋——解決困擾每個 AI 應用的無狀態問題。

問題

大型語言模型本質上是無狀態的。每次 API 呼叫都是獨立運作，當 context window 滿了（4K–128K tokens），所有對話歷史、使用者偏好與關鍵脈絡都會消失。這帶來四個關鍵問題：

  1. LLM 會忘掉一切——超出 context window 就沒有跨 session 的持久學習
  2. 開發者浪費 token 與金錢——每次 API 呼叫都要重送整段聊天歷史
  3. 每個團隊都從零重建記憶系統——而不是重用經過實戰驗證的基礎設施
  4. 沒有標準解法——每個應用各自實作臨時的記憶管理

沒有持久記憶，AI 應用就會變成每次對話都從零開始的健忘助理。

我的角色

我共同創辦 MemFuse，並共同設計其記憶架構，在早期開發階段共同建構核心記憶 primitives。我負責公開的 Python SDK（memfuse-python）與開發者整合體驗——安裝、快速入門、範例與文件——讓替 LLM app 加上持久記憶維持在三行程式碼的改動。專案由共同創辦人持續維護，我則專注於其他承諾。

做法

MemFuse 實作受人類記憶系統啟發的認知架構，並針對 production 工作負載做積極的效能最佳化。

五層認知記憶系統

打造第一個面向 LLM 的分層記憶開源實作：

  • M0（情節層）——原始對話歷史，類似短期工作記憶
  • M1（語意層）——從對話中萃取的事實與實體
  • M2（知識圖譜）——具圖結構的複雜關聯知識
  • M3（程序層）——學到的行為模式與程序
  • MSMG（多圖譜）——進階的圖式語意關聯

進階緩衝系統架構

設計三元件緩衝系統，大幅降低延遲：

  1. WriteBuffer——透過寫入聚合，把多筆小寫入批次成較大的操作
  2. SpeculativeBuffer——分析存取模式，在請求前主動預取資料
  3. QueryBuffer——快取高頻存取資料，並以 Reciprocal Rank Fusion（RRF）做智慧重排序

中央 BufferManager 協調所有記憶層級的資料流，在各層級都以最低延遲為目標最佳化。

統一認知搜尋

實作結合三種模態的搜尋融合：

  • 向量搜尋——語意相似度（pgvector）
  • 圖搜尋——關聯推理
  • 關鍵字搜尋——精確比對
  • RRF 重排序——跨所有來源挑出最相關結果

自訂 TimescaleDB 實作

自建類似 pgai 的 embedding 與向量運算實作，而非依賴 TimescaleDB 官方 extension，以便針對我們的使用情境做更細緻的控制與客製。

多租戶架構

設計安全隔離與彈性範圍劃分：

  • User（必填）——使用者身分
  • Agent（選填）——特定 AI 助理（預設為 "agent_default"）
  • Session（選填）——對話 thread 識別碼

影響

開發者體驗革新

三行程式碼整合，零程式碼透明運作——記憶在背景生效，不必改現有 LLM API 模式：

from memfuse import MemFuse
from memfuse.llm import OpenAI
 
# Initialize memory scope
memfuse_client = MemFuse()
memory = memfuse_client.init(user="alice")
 
# Standard OpenAI client with memory automatically enabled
llm_client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"), memory=memory)
 
# All subsequent calls leverage persistent memory
response = llm_client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "What's Mars gravity?"}]
)

後續追問會自動擷取相關脈絡，不必手動管理歷史。

工程原則

  • Local-first 架構——沒有強制雲端依賴或授權費用
  • Apache 2.0 授權——完全開源、方便 fork
  • 以 benchmark 驅動——對照 LongMemEval、MSC 等 agent-memory benchmark 評估

效能最佳化

  • Token 效率的 context——只送相關擷取記憶，而非重送完整聊天歷史
  • 快速檢索——透過 speculative prefetching 與 query 快取
  • 寫入聚合——提升資料庫效率

實際應用場景

已部署於多個領域：

  • 具持久使用者偏好的對話式 AI
  • 跨 session 追蹤學生進度的教育導師
  • 學習開發者模式的 CLI 程式助理
  • 具共享記憶的多 agent 系統
  • 具深度 context 保留的研究助理

技術創新

1. 自訂 pgai 實作

自建專有的 embedding 與向量運算能力，而非依賴 TimescaleDB 官方 extension，能更細緻地控制效能特性。

2. Speculative Prefetching

依存取模式分析做預測式資料載入——在 LLM 記憶系統中並不常見，但對維持夠快的檢索、保住對話流暢度至關重要。

3. 分層認知架構

第一個開源記憶系統，完整實作人類記憶研究啟發的五層認知模型（M0–M3 + MSMG）。

4. 統一搜尋融合

無縫結合向量、圖譜與關鍵字搜尋，並以智慧 RRF 重排序——多數系統只提供向量搜尋。

5. 零程式碼透明

記憶層透明運作，不必改現有 LLM API 呼叫模式——初始化之後，後續呼叫自動利用記憶。

學到的教訓

  1. 認知架構勝過天真儲存——分層記憶層級（M0–M3）明顯優於單層做法
  2. 緩衝不可或缺——沒有積極的快取與預取，檢索延遲會扼殺對話流暢度
  3. Local-first 贏——開發者偏好可自架、完整資料主權的方案，而非 SaaS 記憶服務
  4. 整合摩擦會扼殺採用——三行程式碼設定很關鍵——再複雜一點，開發者就會自己重造
  5. 搜尋融合 > 單一模態——向量 + 圖譜 + 關鍵字搜尋搭配 RRF 重排序，比任何單一做法更能挑出好結果

技術棧與工具

  • 後端： Python、PLpgSQL、Shell
  • 資料庫： TimescaleDB（自訂 pgai 實作）、pgvector 做 embedding
  • 基礎設施： Docker 容器化（timescale/timescaledb-ha:pg17）、Poetry 管理依賴
  • 測試： Nox 自動化、LongMemEval 與 MSC benchmark 框架
  • 程式碼品質： Pre-commit hooks、Flake8、darglint
  • API： OpenAI、Anthropic、Gemini、Ollama 整合
  • 未來支援： Neo4j、Qdrant、Redis 後端