最近筆電剛好升級到 MacBook Pro M5（24GB RAM），想說來試試看大家一直在聊的「本地端 AI + 個人知識庫」到底能做到什麼程度。畢竟「第二大腦」這個概念喊了好幾年，工具也越來越成熟了，是時候親自踩進去看看。
萬萬沒想到，踩進去之後，反而讓我想通了一件跟工具完全無關的事。
先說說我怎麼測的
測試組合長這樣：
| 項目 | 配置 |
|---|---|
| 主機 | MacBook Pro M5 (2025), 24GB RAM |
| 模型 | Google Gemma 4 E4B（透過 LM Studio 載入） |
| 前端 | AnythingLLM（對話介面 + 記憶管理） |
| 知識庫 | 5 份自己寫的方法論文件，透過向量資料庫（RAG）接入 |
這五份文件涵蓋了市場定位、實戰專案設計、書籍大綱、品牌架構和學習策略，彼此之間有明確的邏輯關係和層次結構。我丟給它的問題也不算太刁鑽：「如果要為這套方法論來寫一本附帶豐富插圖的日式小說書籍，你會怎麼規劃？」
拿回來的結果，第一眼看起來還蠻厲害的——賽博龐克 × 江戶工匠的視覺對比、師徒傳承的三幕劇敘事、每個章節都有場景設定和插圖方向。包裝能力確實不錯。
但仔細一看，核心理解全偏了。
我的方法論有四個維度，它把每個維度的內涵重新發明了一遍。有的被簡化成表面的關鍵字，有的被直接對應到錯誤的概念。更關鍵的是，我在文件裡花了不少力氣說明「這不是一個統一的方法論，而是一個品牌傘」，但模型完全忽略了這個設計意圖，自動把四個維度組裝成一套修煉體系。
簡單來說——關鍵字都抓到了，但關鍵字之間的邏輯關係，一個都沒有。
是模型太弱嗎？我換了個做法試試
第一反應當然是覺得模型不夠聰明。Gemma 4 E4B 畢竟是輕量模型，跑在 24GB RAM 上也是吃緊邊緣。但在下結論之前，我決定先試另一件事——同一個模型、同一個問題，但這次不走 RAG，改由我自己選擇相關文件，完整地上傳給 LM Studio，然後使用與前面那個（AnythingLLM + RAG）測試相同的對話過程，逐步引導它去理解脈絡。
結果差異大到我自己都有點驚訝。
這一版正確抓到了四個維度的名稱，用上了具體的專業概念（而不是自己編的），也正確對應了我三本書的層級結構。甚至在場景設計上，能把特定的技術概念嵌入對應的故事轉折點。
當然也不是完美——它還是把我的品牌傘讀成了統一方法論（還設計了一個「四道光芒匯聚」的高潮場景……），一些更深層的洞察也沒抓到。但整體理解深度，我估計從三成跳到了七成左右，差距是肉眼可見的。
同一顆腦袋，結果卻天差地遠。那差在哪？
差在 RAG 怎麼處理你的知識
這就得說到 RAG 的運作方式了。
LLM 有一個根本限制：上下文視窗（context window）是有限的。不管模型多聰明，它一次能看的資訊量就這麼大，你的知識庫不可能全部塞進去。RAG 的解法很直覺——既然塞不下，就幫你自動篩選：把文件切成小塊（chunk）、轉成向量存進資料庫，提問時撈出「最相關」的片段，再塞進模型的上下文裡。
聽起來很合理。但問題就出在「切成小塊」這一步——我的五份文件之間有交叉引用、有層次依賴、有「A 的定義要搭配 B 的限定條件才完整」的關係。RAG 把它們切碎之後，這些關係全斷了。模型拿到一堆看起來相關的碎片，但碎片之間的脈絡不見了，只能拿這些碎片做表面拼貼。
而我第二次測試時做的事情完全不同——不是讓系統自動切碎再撈，而是我自己判斷哪些文件跟這次的議題有關，然後把它們完整地交給模型。知識的結構沒有被打散，文件之間的關聯性也保留了。
所以改善的原因不只是「文件沒被切碎」，更關鍵的是「由誰來決定模型該看什麼」。
想到這裡，我覺得有兩件事蠻反直覺的
做完這兩個實驗，我開始回頭想一些更根本的問題。然後發現，大家對「AI + 知識庫」這件事，有兩個很普遍的直覺，但可能都指錯了方向。
直覺一：「資料越完整越好，最好全部塞進去」
大部分人對「第二大腦」的想像大概是這樣的——如果 AI 能讀取我所有的筆記、所有的文件、所有的記憶，它就能幫我做出最好的判斷。現在做不到只是因為上下文視窗太小，等技術突破了，全部塞進去就對了。
但你回頭想想，人的大腦面對的其實是同樣的限制——你不可能在想一個問題的時候，同時調用你人生中所有的記憶。大腦每一刻能放進「工作區」的資訊就是那麼多。
而大腦的厲害之處，恰恰就在這個有限的工作區裡。它不是靠「記得多」來思考的，而是靠在某個時刻只聚焦於跟當下問題相關的知識，其他的先放到背景去。這個「有限範圍的聚焦」不是缺陷，而是深度思考的前提。塞太多不相關的東西進來，反而會分散注意力。
所以 LLM 的上下文視窗有限，也許不是一個等待被突破的技術瓶頸，而是跟大腦一樣——在有限範圍內聚焦，本身就是有效思考的必要條件。
直覺二：「既然塞不下，那就用自動化來篩選」
接受了「塞不下」這個現實之後，開發者很自然地想到工程解法——用向量資料庫做語意檢索，搭配 RAG 的切塊機制，讓系統自動幫你挑出最相關的內容。
但我的實驗結果顯示，這個自動化篩選帶來了兩個代價：破壞了知識的完整性，也失去了知識之間的關聯性。
更根本的問題是——「哪些知識跟我當下的思考有關」這件事，本質上是一個人在當下根據議題做出的判斷。它取決於你這次想解決什麼問題、你的思考走到了哪裡、你覺得哪些背景跟這次有關。大腦做這件事的時候，是以完整的記憶為單位去選擇的——調出某個專案經驗、某篇讀過的文章、某次對話的觀點——而不是把記憶切成碎片再拼。
RAG 的做法剛好相反：先切碎，再從碎片裡撈。這不是「篩選」，比較像是把一本書撕成一頁一頁，再靠關鍵字撈幾頁出來拼在一起。每一頁都沾到邊，但整體脈絡不見了。
所以，你需要的不是「第二大腦」，而是「第二注意力」
如果把上面兩個反直覺合在一起看，結論其實很清楚：
我們一直在追求的「第二大腦」——一個能幫你記住所有東西、自動幫你找出相關內容的系統——方向可能搞反了。大腦真正厲害的不是記憶容量，而是聚焦和篩選的判斷力。而這個篩選，應該是以完整知識為單位的選擇，不是碎片化的自動拼貼。
換個說法：你需要的不是一個幫你「記更多」的第二大腦，而是一個在你指定的方向上、用完整的知識幫你「看更深」的第二注意力（second attention ）。
而「指定方向」這件事，始終是人的工作。
那實際上該怎麼做？
說到這裡，答案其實出乎意料地簡單…
你不需要什麼新工具、新架構、新技術。你需要的是一個工作習慣——我暫且叫它「策展再對話」：
- 建立你的知識庫：用 Obsidian、Notion、或任何你習慣的筆記工具，把資料好好整理。標籤、分類、連結，讓你能快速找到相關內容。
- 提出議題，做收集：跟 AI 對話之前，先花兩分鐘想「這次需要什麼背景資料？」然後去知識庫裡搜尋，找出相關的完整文件。
- 審視收集結果：看一下找到的東西，不相關的拿掉、漏掉的補上。
- 帶著精選資料進入對話：把篩選過的完整文件上傳給 AI，開始討論。
- 動態補充：討論中發現缺資料，回到步驟 2。
看起來很土法煉鋼？沒錯。但這個流程做到了兩件關鍵的事：知識的完整性被保留了，而且你清楚知道 AI 看了什麼。當回答偏了，你可以判斷是「我挑的文件不對」還是「文件內容本身寫得不夠清楚」。變數可控，改善才有方向。
有趣的是，寫完這篇文章之後我才注意到，OpenAI 的共同創辦人之一的 Andrej Karpathy，最近剛好也分享了他用 LLM 建立個人知識庫的做法，而且在社群上爆紅。他的核心觀點跟我的實驗結論有一個交集——他本來以為需要 RAG，結果發現在個人知識庫的規模下，結構化的 Markdown wiki 就夠用了，不需要向量資料庫做碎片化檢索。
不過他的解法跟我的方向不同。Karpathy 選擇讓 LLM 全面接管知識的編譯、連結和維護，人幾乎不介入 wiki 的編輯。而我更傾向讓人保留策展的判斷權——由人來決定每次對話要帶哪些完整文件進去。兩條路都繞過了 RAG 的碎片化問題，但對「人在其中扮演什麼角色」的想法不一樣。哪個更適合你，大概取決於你的使用場景和個人偏好。
比起選模型，先問自己「該給它看什麼」
最後回到一開始的實驗。
本地端小模型和雲端大模型之間，確實有理解力和表達力的差異，這不用迴避。同樣的文件丟給不同等級的模型，得到的深度和細緻程度一定不一樣。
但不管你用哪個模型，有一件事比模型的選擇更優先——你決定讓它看什麼。如果餵進去的是被切碎的片段，再強的模型也只能拼貼。如果你自己判斷了哪些完整的知識跟這次問題有關，即使是輕量的本地模型，也能給出有結構的回應。
所以下次當你覺得「AI 好像不太懂我在說什麼」的時候，也許可以先試試：不是換一個更強的模型，而是重新想一下——我這次給它看的東西，對嗎？夠嗎？完整嗎？
我想，你可能也會驚訝於結果的差異。
（說真的，我搞了一整套本地端環境、架了向量資料庫、折騰了半天 RAG 設定，最後發現最有效的方式是「自己選檔案再上傳」……這大概就是工程師的日常吧。Orz）
參考資訊：
- Andrej Karpathy, “LLM Knowledge Bases”（LLM 知識庫）（X / GitHub Gist）：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Chris Lettieri, “I trained a local LLM on my Obsidian, here’s what I learned”（我用自己的Obsidian來訓練本地端LLM模型的心得）（Medium）：https://medium.com/@BitsOfChris/i-trained-a-local-llm-on-my-obsidian-heres-what-i-learned-a3e738f9bed0
- LLM Workspace – Obsidian Plugin：https://www.obsidianstats.com/plugins/llm-workspace
