Mnemo: 為 LLM 設計的本地優先 AI 記憶層

Mnemo 是一個本地優先的 AI 記憶層，旨在提供跨 LLM 會話的持久化、結構化記憶，且無需雲端依賴或 Python 執行環境。它作為一個 sidecar 服務運行，從對話中提取實體與關係以建立知識圖譜，隨後將相關且經過評分的上下文注入到未來的提示詞中。

核心功能與工作流程

Mnemo 透過自動化資訊的提取與檢索，使 LLM 應用程式能夠在不同會話之間維持狀態與知識。該系統透過兩個主要端點的流水線運作：

1. 攝取與提取

當原始文本（例如對話輪次或文件）被發送到 /ingest 端點時，Mnemo 會使用配置好的 LLM 來識別命名實體（人物、工具、地點、概念）及其之間的關係。這些實體會根據名稱與類型進行去重，別名會被合併，產生的數據會持久化在 SQLite 資料庫中。同時，記憶中的 petgraph 會被更新，以維持知識圖譜的結構關係。

2. 檢索與上下文注入

當查詢被發送到 /retrieve 端點時，Mnemo 會執行六階段的檢索流水線以組裝 context_prompt：

全文分塊搜尋：初步搜尋相關的文本片段。
實體名稱搜尋：搜尋特定的已知實體。
圖譜擴展：在知識圖譜上執行廣度優先搜尋 (BFS) 以尋找相關概念。
關係篩選：根據定義的關係進行結果篩選。
評分與排序：根據相關性對結果進行排序。
組裝：生成最終的上下文字串，以便注入到 LLM 的系統提示詞中。

圖譜擴展的結果會以 0.5x 進行評分，以確保直接匹配的結果始終比推論出的關係排名更高。

技術架構與效能

Mnemo 是以四個 Rust crate 組成的套件實現的，以確保高效能與極小的佔用空間：

mnemo-core：處理實體提取、圖譜操作、檢索引擎與資料庫層的核心函式庫。
mnemo-api：基於 Axum 的 REST API，作為核心邏輯之上的薄處理層。
mnemo-cli：用於與 API 互動的命令列介面。
mnemo-bench：專用的基準測試套件。

效能基準測試

在 Apple M2 上測試（使用 SQLite 的 WAL 模式與記憶中的 petgraph），該系統在核心操作上展現了低延遲（此為 debug build 數字；據報 release build 會快 3–5 倍）：

Operation	Avg Latency	Throughput
Entity insert (SQLite)	~0.12 ms	~8,300 ops/s
Entity lookup by ID	~0.08 ms	~12,500 ops/s
Chunk insert	~0.14 ms	~7,100 ops/s
Full-text chunk search	~0.28 ms	~3,500 ops/s
Graph neighbor (depth=1)	~0.21 ms	~4,700 ops/s
Graph neighbor (depth=2)	~0.89 ms	~1,100 ops/s
Full retrieval pipeline	~4.2 ms	~238 ops/s

部署與整合

Mnemo 設計具備靈活性，支援任何與 OpenAI 相容的後端，包括像 Ollama 這樣的完全本地選項。

整合路徑

Docker：建議使用 Docker Compose 來同時部署 Mnemo 與 Ollama 的路徑。
Binary：對於獨立運行 LLM 後端的用戶，可透過 cargo install 進行安裝。
Python SDK：可透過 pip 使用 mnemo-sdk 套件，以便整合進 Python 為主的 LLM 流水線中。

配置

配置透過環境變數或 TOML 檔案處理。關鍵變數包括 MNEMO_LLM_BASE_URL（預設為 Ollama）、MNEMO_LLM_MODEL 以及 MNEMO_LLM_PROVIDER（支援 ollama、openai、anthropic 或 custom）。

社群觀點與不同意見

雖然 Mnemo 為本地記憶提供了結構化方法，但社群討論也為開發者提出了幾項考量因素：

上下文窗口管理：部分用戶建議，若將過多記憶填入 LLM 的上下文窗口，可能會降低模型效能。
功能對等性：討論指出未來可能引入 BM25 嵌入技術以改進檢索。
Project-level 記憶：部分開發者認為，記憶的需求正轉向專案層級的儲存，以便在不同模型與框架之間共享，而非僅限於會話層級的記憶。
整合趨勢：普遍觀點認為，受管代理框架（managed agent harnesses）最終可能會原生內建這些功能，從而可能減少對獨立 sidecar 服務的需求。