LLM 知識管理：從 RAG 到知識編譯器

本文靈感來自 Andrej Karpathy 於 2026 年 4 月分享的 LLM Knowledge Base 架構

我跟筆記軟體的恩怨史

先坦白說：我是一個不善於整理筆記的人。

這些年來我用過的知識管理工具可以列一長串。早期用 Evernote，什麼都往裡面丟，剪貼網頁、拍照、寫筆記。一年後打開來看，幾百則筆記堆在那裡，沒有分類、沒有標籤、搜尋也找不太到想要的東西。後來換到 Notion，覺得它的 database 和 template 功能很強大，花了不少時間設計分類架構。結果呢？架構是設好了，但我懶得每次都照格式填，最後又變成一堆雜亂的頁面。Logseq 用過一陣子，大綱式筆記的概念很新鮮，但我的腦袋不是那樣運作的。Obsidian 的雙向連結很吸引人，本機 Markdown 檔案也對我的胃口，但同樣的問題：我就是不會主動去整理那些筆記、加標籤、建連結。連 Notability 這種手寫筆記 app 都試過，想說也許手寫會讓我比較願意整理，結果寫完就再也沒打開過。

除了整理的問題，還有一個更實際的痛點：查詢。我經常需要從筆記中找某個設定指令、某段架構設計、或某次會議的結論。但不管用哪個工具，跨裝置查詢總是卡卡的。有的要開專屬 app，有的離線就搜不到，有的同步慢到我都忘記自己要查什麼了。我需要的是不管在辦公室的電腦、家裡的筆電、還是手機上，都能在幾秒內找到我要的東西，而且離線也能用。這也是我後來決定把知識庫做成自己網站 Wiki 模組的原因之一：一個 URL、一個搜尋框，任何裝置打開瀏覽器就能查，不需要安裝任何 app。

我一直在找一個「只要丟內容進去就會自動整理好」的工具。之前也出現過幾個號稱能做到這件事的軟體，用 AI 自動分類、自動摘要、自動建連結。但多半做得不夠好，不是分類邏輯奇怪，就是摘要品質低落，最後還是得自己手動修正。

所以當我看到 Karpathy 用 LLM 來做知識管理的思路時，第一個反應不是興奮，而是：「這次真的能解決我的問題嗎？」

老實說，我不確定。也許過一陣子又會有新的思維或方法出現，讓現在的做法變得過時。但至少目前，LLM 的語言理解能力確實比之前那些工具的自動分類強太多了。值得試試看。

RAG 的天花板

在談 Karpathy 的方法之前，先聊聊 RAG，因為這是目前大多數人聽到「AI + 知識管理」的第一反應。

RAG 的流程是：把文件切成 chunk、丟進向量資料庫、查詢時用 embedding similarity 撈出相關段落、餵給 LLM 產生回答。這套流程我做過，也確實能解決一部分問題。

但用了一陣子就會發現幾個根本性的限制。

檢索品質靠運氣。 向量相似度搜尋本質上是淺層匹配。一個複雜的技術問題，答案散落在三份文件的不同段落裡，RAG 不一定能把三段都撈到。更常見的情況是撈到一段看起來相關但其實答錯方向的內容，LLM 就被帶偏了。

沒有知識累積。 每次查詢都是從零開始。今天問了一個好問題，LLM 給了一個精彩的綜合分析，但這段分析不會被留下來。明天換個角度問類似的問題，整個過程重來一次。知識沒有沉澱，沒有複利效應。

向量是黑盒子。 文件進了向量資料庫之後，你無法直接閱讀或編輯 embedding。某段內容有錯，你得回去改原始文件、重新 embedding、祈禱新版本會被正確檢索。這不是知識管理，這是在跟機器猜拳。

Karpathy 的思路轉換

2026 年 4 月初，Karpathy 在 X 上分享了他最近的工作方式。他說自己大量的 LLM token 用量已經不是在操作程式碼，而是在操作知識。他用 LLM 來建立和維護個人知識庫，處理各種研究主題。

他提出的架構非常清晰，三層結構：

Raw Sources（原始素材）。 不可變的來源文件。研究論文、GitHub repo、網頁文章、資料集，全部用 Obsidian Web Clipper 之類的工具轉成 Markdown 檔案丟進 raw/ 資料夾。LLM 只讀不改。

Wiki（知識庫）。 LLM 產出的結構化 Markdown 檔案。包含摘要、概念頁面、實體頁面、交叉參考和反向連結。這一層完全由 LLM 擁有和維護。

Schema（架構定義）。 一份配置文件（像是 CLAUDE.md），定義 wiki 的結構慣例、ingest 流程、品質標準。

核心操作也只有三個：Ingest（消化新素材，更新相關 wiki 頁面）、Query（查詢知識庫，有價值的回答直接歸檔成新頁面）、Lint（定期掃描 wiki，找出矛盾、過時資訊、缺失的交叉參考）。

這個設計最精妙的地方在於：Markdown 就是 source of truth。 不需要向量資料庫，不需要 embedding pipeline，不需要複雜的檢索基礎建設。每一筆知識都是人類可閱讀、可編輯、可追溯的 .md 檔案。在大約 100 篇文章、40 萬字的規模下，LLM 透過 index 和 summary 導航的效率，比 RAG 的 chunk retrieval 還好。

Karpathy 用一句話總結了核心洞見：「維護知識庫最煩的不是閱讀和思考，是 bookkeeping。」而 LLM 做 bookkeeping 幾乎零成本。

我的實作：用 Claude Code 編譯 Wiki

看到 Karpathy 的分享，我馬上決定動手做看看。

我的個人部落格是一個 Rails 8.1 應用，裡面原本有一個閒置沒在用的 Projects 模組。受 Karpathy 啟發，我用 vibe coding 的方式，花了不到一天把它改造成 Wiki 知識庫模組，重新設計了整個 ingest 流程。核心想法是：Claude Code 自己就是那個 LLM，不需要再繞一圈。

我寫了一個 /wiki-add 的 Claude Code skill。流程極其簡單：

丟 raw data 進去（URL、檔案路徑、或直接貼文字）
Claude Code 查詢現有的 wiki entry slug 列表（用來建立 backlinks）
Claude Code 自己消化素材，產出結構化的 wiki entry：標題、摘要、分類、標籤、Markdown 內容、反向連結
寫一段 Ruby script，SCP 到 production server，docker exec 進 container 執行 rails runner

就這樣。從丟素材到寫入 production 資料庫，整個過程不到一分鐘。沒有向量資料庫、沒有 embedding、沒有 RAG pipeline。Claude Code 就是知識編譯器。

這正好解決了我一直以來的痛點：我不需要整理。丟進去就好，AI 幫我做 bookkeeping。分類、標籤、摘要、反向連結，全部自動處理。對我這種不擅長整理筆記的人來說，這才是真正有用的工具。

跳脫 RAG 的思維模型

我認為 Karpathy 這套方法論真正改變的不是技術實作，而是思維模型。

RAG 的思維是「搜尋」。 我有一堆文件，當使用者提問時，我去搜尋最相關的段落。這本質上是 Google 的延伸，只是用向量搜尋取代關鍵字搜尋，然後讓 LLM 幫忙組織答案。

LLM KM 的思維是「編譯」。 我有一堆原始素材，LLM 持續地把它們消化、整理、結構化、互相連結，產出一個活的知識庫。這不是搜尋引擎，這是一個有記憶、會成長的系統。

用一個比喻就能說清楚：

RAG 像是一個圖書館員。你問問題，他去書架上找幾本相關的書，翻到對的頁面念給你聽。每次都重新找。

LLM KM 像是一個研究助理。他讀完所有資料，整理成一本百科全書。這本百科全書每天都在更新，新資料進來就自動融入既有的知識網路。你問問題時，他不是去翻原始文件，而是查他自己寫的百科全書。

實務上的幾個關鍵設計

幾天下來，我在實作中歸納出幾個重要的設計決策。

Markdown 優先，不要急著建複雜的基礎建設。 Karpathy 的核心洞見就是這個。.md 檔案已經夠好了。人能讀、AI 能讀、Git 能追蹤、任何編輯器都能開。不需要自建一套 CMS、不需要搞 Graph Database、不需要 vector store。在知識量到達幾百篇、幾十萬字之前，Markdown + index 就已經非常好用。

讓 AI 擁有 wiki 層。 原始素材是人決定要收集的，wiki 是 AI 產出的。這個分工非常重要。人負責「要讀什麼」，AI 負責「怎麼整理」。不要讓人去手動維護知識庫的格式、交叉參考和分類標籤，那些正是 LLM 最擅長的 bookkeeping。

Backlinks 是知識網路的血管。 我在 WikiEntry model 裡設計了 backlinks 欄位，是一個 string array，存放相關 entry 的 slug。每次 ingest 新素材時，Claude Code 會查詢既有的 slug 列表，判斷哪些 entry 跟新內容相關，自動建立連結。這讓知識庫從一堆平面文件變成一個有機的網路。

Status 分層控制可見性。 不是所有知識都適合公開。我的 wiki 有四種狀態：draft、restricted、published、adminonly。預設寫入的是 adminonly，只有我看得到。確認內容沒問題再調整可見性。這讓我可以放心地把各種筆記和草稿丟進去，不用擔心半成品曝光。

寫入流程要極致簡單。 如果每次新增一筆知識都要開後台、填表單、選分類，這個系統很快就會被棄用。我的 /wiki-add 就是一行指令。丟 URL 就抓網頁、丟檔案路徑就讀檔案、丟文字就直接處理。分類、標籤、摘要全部自動產出。摩擦力越低，使用頻率越高。

這不只是個人工具

Karpathy 自己也說，這個方法論代表一個「incredible new product」類別。大多數企業都淹沒在非結構化資料裡：Slack 對話、內部 wiki、PDF 報告，沒有人有時間去綜合整理。一個 Karpathy 風格的企業級知識編譯器，不只是搜尋這些文件，而是主動撰寫和維護一本「公司百科全書」，而且即時更新。

我在醫院看到的狀況完全一樣。標準作業程序散落在不同科室的共用硬碟裡，格式不統一，版本管理靠檔名加日期。新的護理師來了，光找到對的 SOP 就要花半天。如果有一個 LLM 持續消化所有 SOP，維護一個結構化的知識庫，搜尋任何流程都能在幾秒內得到結構清晰的答案，而且附上原始文件的連結。

這才是 AI 在組織中該扮演的角色。不是取代人類做決策，而是替人類做整理、做連結、做 bookkeeping。讓專業人員把時間花在真正需要人類判斷的事情上。

這套方法能撐多久？

老實說，我不知道。從 Evernote 到 Notion 到 Obsidian，我換過太多工具了。每一次都覺得「這次應該是最好的方案」，結果過一兩年又有更好的東西出現。LLM KM 會不會也是這樣？很有可能。也許半年後 context window 大到可以直接塞進整個知識庫，根本不需要 wiki 這個中間層。也許會出現更好的知識表示方式，不是 Markdown 而是某種我們現在還想不到的格式。

但 Karpathy 點出了一件事我很認同：把 bookkeeping 交給 AI，把思考留給人類。 不管未來工具怎麼變，這個分工邏輯不會變。而且就算這套方法明年就過時了，至少我現在多了十幾篇整理好的 wiki entry。知識本身不會消失。