https://yennj12.js.org/yennj12_blog_V4/tags/qdrant/Recent content in Qdrant on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 11 Sep 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mem0-intro-part4-storage-backends-zh/Fri, 11 Sep 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mem0-intro-part4-storage-backends-zh/大多數人選向量庫的方式，是看 benchmark 的 QPS 數字，或者「團隊已經在用 Postgres 了就用 pgvector」。 真正的答案是：在 Mem0 這套架構下，向量庫的選擇會直接決定你的三訊號檢索能不能運作——25 個支援的後端裡，有 10 個根本沒實作關鍵字檢索，選到它們，你的 BM25 訊號會靜默歸零。 這不是效能差異，是功能差異。 而它不會有任何錯誤訊息。 前言 Part 2 拆了寫入、Part 3 拆了讀取。兩條路徑上的每一次 insert、search、keyword_search 都委託給後端——Mem0 自己不存任何東西。 這一篇下到那一層：三個 store 各自存什麼、schema 長什麼樣、25 種向量庫的能力矩陣、以及那個影響最大卻最少被討論的差異——誰有 keyword_search，誰沒有。 本篇的目標：讀完之後，你能對著自己的規模、語言、與已有基礎設施，選出一組後端，並說得出每個選擇放棄了什麼。 一、核心問題：一份記憶被拆成三個地方存 1.1 為什麼不能只用一個資料庫 Part 1 給過結論，這裡補上原因。一條記憶要支援的查詢有五種，而它們對索引結構的要求互相衝突： 一條記憶：「Alice 推薦了中山區那家拉麵店」 查詢類型 需要的索引 衝突點 ────────────────────────────────────────────────────────────── 「他喜歡什麼食物」 HNSW / IVF 向量索引 近似最近鄰，不保證精確 「拉麵」 倒排索引 + 分詞 需要詞彙統計（IDF） 「關於 Alice」 實體 → 記憶 反向索引 Alice 不在這條記憶的文字裡 「按時間列出」 B-tree on created_at 向量庫的排序能力普遍很弱 「這條哪來的」 稽核日誌 需要 append-only 的事件表 第三行是關鍵：「Alice」這個詞完全沒有出現在記憶文字裡，所以無論向量索引還是倒排索引都撈不到它。只有一個從實體指回記憶的反向索引能解決。