自從 Andrej Karpathy 發表了他的 LLM-wiki 之後，網路社群上以文字處理為目的的方法論越來越多，今天看到了連蜜拉·喬娃維琪都公佈了自己的 Github repo Mempalace，它的概念相當有趣，覺得未來應該要試用一下，看可不可以整毫到我自己的方法論中。
什麼是 Mempalace？
它是一套專門設計給 LLM 的儲存與索引技術，核心概念有兩個，要分成壓縮與索引兩部分來解釋。
AAAK壓縮
AAAK 的全名是「AI-to-AI Shorthand」，白話來說就是利用 LLM 很會腦補的特性，把一段文字去除冗文贅字後，濃縮成最精鍊的概念。這樣濃縮出來的文字對人類來說幾乎無法閱讀，但 LLM 可以很好得讀懂，這樣就可以在極度節省 token 的狀況下壓縮資訊。
舉例來說：「我們在 2026 年 3 月 15 日的會議中決定，為了提升系統穩定性，我們將放棄原本的 Redis 快取，改用內存快取（In-Memory Cache）。」 就可以被AAAK壓縮成：[DEC:260315|STB_UP|MEM>RDS]
設計上在壓縮時，也會參考實際上的知識「位置」，這就是下一點要說的索引方法，也是此工具會被稱為宮殿的原因。
記憶宮殿座標
在這個方法論中，蜜拉·喬娃維琪把儲存位置分成了一串結構性的路徑，從最上是「wing」，也就是西式皇宮會有的「翼」，翼之下有「hall」(廳)，廳之下有「room」(房間)。翼是最上級的儲存架構，可能有「工作翼」、「個人健康保持翼」等等，可以理解成用於存放不同專案，而工作翼下可能會有不同的廳，例如「客戸廳」、「產品管理廳」等，而房間則是最細的儲存結構，例如產品管理廳之下可以有「資料庫設計房間」。系統會依據這三層的關係去計算不同筆記的實際座標，並定義出筆記之間「是否接近」。這就跟生物的分類學概念相似，獅子與家貓都是貓科動物，關係就比非貓科動物的猴子遠。
於是筆記的內容與位置座標就都會利用 AAAK 壓縮，確保 LLM 可以無損閱讀壓縮後的資訊。這讓 LLM 可以更簡單讀懂筆記，更簡單找到目標的筆記。
為什麼要與 Obsidian 整合？
可能先需要回的的問題是「為什麼要與 Obsidian 整合？」，我認為 Obsidian 用文字作為儲存基礎的特性，非常適合與 LLM 協作，所以如果一開始，你的 Vault 就是設計來讓人與 AI 協作，進而產出知識的，Obsidian 比其他的筆記軟體都更適合這套方法論。
如何與 Obsidian 整合？
那究竟如何整合呢？很直覺的想法會在筆記中加上兩個 Metadata ，分別是 AAAK 壓縮結果與記憶宮殿座標，但這其實有點浪費了。記憶宮殿座標的用途是透過計算與加權，得到一個類似向量資料庫、資訊之間的相對關系，如果在原始的設計中可以用 Wing/hall/room 的結構來計算相對座標，那在 Obsidian 中應該也要可以透過「儲存路徑」與「標籤」來進行計算，這樣也會產生一個相對座標。最後同樣再利用 AAAk 壓縮即可。甚至我可以說，用「儲存路徑」與「標籤」來進行計算會比原版的皇宮座標結更好，因為同一物品難以有多個座標，且皇宮只有三層，但利用儲存路徑配合標籤，我可以在一則筆記中下多個標籤，甚至是巢狀標籤，儲存路徑也可以有多層。這樣算下來可以分成更多層，設定上也更自由，對於已經使用 Obsidian 一段時間的人來說，也不用回頭在過去筆記中新增 metadata。
還是有限制
真正無法簡單在obsidian上完成的反而是讀取與壓縮的部分，但這點只要用 Claude code、Gemini Cli等工具，應該也可以在 Obsidian 內簡單完成，甚至可以說，快速做一個自用的 Plugin 也不會是問題。
應用
先撇除 Obsidian ，這個專案看起來可以有效的替換傳統 RAG 方法，因為它可以把每個推理的過程視作一個房間，這樣就可以記錄下整個推理過程，不會像傳統的RAG一樣忘掉一開始的討論。回到 Obsidian 之中，你的 Obsidian 如果只是單純把東西記錄下來，那用起來可能與其他筆記軟體差不多，但如果你是用於思考，產出想法，那我相信這套方法與 Claude code 之類的工具會讓你的效率增加不少。