Karpathy 的 LLM Wiki：它想解決什麼問題，代價是什麼

一句話版本：它解決的是「跨文件的綜合無法累積」，代價是「拿來源的純淨度去換查詢的速度」。 一個人、百頁以內、你自己會看過，這筆交易划算；三個條件缺一個，就不划算。

一、它想解決的問題

多數人用 LLM 讀自己的資料，流程都長一樣：上傳一批檔案，問問題，系統去撈相關片段， 生成答案。NotebookLM、ChatGPT 的檔案上傳、大部分 RAG 系統，都是這個形狀。

問題不在單次答得準不準，而在知識不會累積。

模型在每個問題上都是從零開始。今天你花了半小時，讓它讀五份文件、比對出一個結論； 明天你問一個相鄰的問題，它又從零把那五份文件重新撈一遍、重新拼一次。 上次那半小時的綜合工作，沒有被存在任何地方。

Karpathy 的提案是在你跟原始檔案之間，插一層持久的 wiki：

• raw/ 放原始文件，不可變，人只往裡面丟東西
• wiki/ 放 LLM 編譯出來的 markdown 頁面，人不手動編輯
• 一份 schema 檔規定 LLM 該怎麼做

每收錄一份新文件，LLM 不是重跑一遍，而是把新東西整合進既有結構——補上交叉引用、 更新受影響的頁面、標記出現的矛盾。查詢時它先讀 index.md（全部頁面的目錄）， 找出相關頁面，再鑽進去。

差別在產物的性質：綜合的成本只付一次，而且會複利。交叉引用已經在那裡了， 矛盾已經被標記過了，你不必每次重建。

順帶一提，這也是它宣稱「不需要 RAG」的地方——不需要 embedding、不需要 vector database， 一份人看得懂的目錄檔加上 context window 就夠了。Karpathy 自己說他本來以為得動用 “fancy RAG”，結果沒有必要。但這句話有規模前提，見第四節。

二、優點

綜合會累積。 這是全部價值的來源，其他都是衍生的。

基礎設施成本趨近於零。 純 markdown 檔案。沒有向量資料庫、沒有 embedding pipeline、 沒有要維運的服務。git clone 就能帶走。

查詢又快又便宜。 因為綜合在寫入的時候就做完了，查的時候只是讀檔。

產物是人看得懂的。 你可以在 Obsidian 裡直接翻，可以用 git 看它每一次改了什麼。 出錯的時候，錯誤是「頁面裡有一段話不對」，看得到，也 revert 得掉。

雜務落在 LLM 身上。 索引、連結、摘要、格式，全部它做。人只負責兩件事： 決定收錄什麼、問好問題。Karpathy 自己說他「rarely touch it directly」。

三、缺點：最嚴重的一個，叫 knowledge base poisoning

Anand Lahoti 寫過一篇批評，替這個失效模式取了名字。這是我讀到對這個模式最有力的質疑。

它在講什麼

白話版：你讓 AI 寫的東西，跟原始文件擺在同一個書架上，久了就分不出來了。

他的比喻最好懂：

圖書館員如果是寫新書、然後把新書擺到原著旁邊，久了你就分不出哪本是原著。 圖書館員如果是寫索引卡、卡片上指著原著，你永遠分得出來。

Karpathy 的模式是第一種圖書館員。

危險的不是明顯的錯

明顯的錯很好抓。真正麻煩的是「看起來合理、結構工整、語氣篤定，但其實是模型『以為』 文件在說什麼的一點點腦補」。

Lahoti 舉的例子值得完整看一遍：

原始合約寫的是**「net 30，10 天內付款折 2%」。AI 編出一頁《Payment Terms》， 寫成「standard agreements use net-30 terms with early-payment discounts」—— 很合理的摘要，只是2% 沒了，10 天窗口也沒了**。

六個月後有人問「我們的早付折扣通常多少？」，搜尋第一個就撈到那頁， 因為它 backlink 最多、是概念樞紐——一個好的檢索器本來就該撈出它。 模型看的是那頁，不是合約。頁面上沒有 2%，所以它講得含糊， 或者從其他同樣方式寫出來的頁面裡腦補一個數字。

然後你跑 lint 健檢。模型把這頁連到上個月它自己寫的《Vendor Agreements》—— 那頁也漏了 2%。兩頁互相一致，卻都跟合約不一致。lint 什麼都不會標， 因為從內部看，一切都很連貫。

「You now have a knowledge base whose internal consistency is a lie that points away from ground truth.」 （你現在有一個知識庫，它的內部一致性是一個謊言，而且這個謊言指向離事實更遠的方向。）

為什麼你不會發現

因為它很慢。沒有哪一天它會「壞掉」。它只是一天比一天更自我指涉： 查詢撈出來的是 AI 寫的摘要、被當成來源，下一個回答又疊在上一個回答上。 保管鏈安靜地磨損、然後斷掉，而沒有人注意到，因為每一份單獨拿出來看都還好。

這跟一般 RAG 出錯，差在哪

這是我認為最該講清楚的一點，因為它正好推翻了「這個模式全面優於 RAG」的直覺：

• 一般 RAG 幻覺是「撈錯東西」。 模型撈到不對的片段，答案就爛。很煩， 但來源本身是乾淨的——你改善檢索、重跑一次，就會得到好答案。
• AI 寫的 wiki 是「來源本身被污染」。「文件說了什麼」跟「之前某個 AI 以為文件說了什麼」， 這兩件事在檢索層已經分不出來了。

所以 Lahoti 說：「修檢索沒有用，因為檢索根本沒壞。」 它確實撈出了最相關的文件， 只是那份文件剛好是「三跳之前就掉了資訊的摘要的摘要」。

「This is the difference between a system that can make mistakes and a system that launders mistakes into truth.」 （這是「會犯錯的系統」和「把錯誤洗成事實的系統」的差別。）

但作者自己把界線畫出來了

這是很多人轉述這篇文章時漏掉的部分。他沒說這模式不行：

「Karpathy’s pattern isn’t wrong. It’s optimized for a context — one user, modest scale, active review — where the compounding failure mode can’t build up enough momentum to matter.」

他真正要罵的，是把個人做法搬去團隊規模、卻沒發現這件事。

四、其他四個缺點

一、規模上限大約 100–200 頁。 超過之後，index.md 自己就先塞爆 context window。 這個數字有三個互不相關的人各自撞到、講出同一個區間，是目前最一致的一項回報。 有個很實用的細分：index.md 有兩個功能——給人看的目錄和給 LLM 用的檢索入口， 這兩個功能不是同時退場的，後者先死。注意卡住你的是頁數，不是來源數。

二、摘要就是有損壓縮，而且回不去。 細節、edge cases、論證裡的細微之處會流失， 事後無法單從 wiki 復原。這一點沒有解法，只有緩解——把數字、日期、閾值、 具名定義規定成必須逐字保留。論證可以改寫，數字不可以改寫。

三、drift 是實務上最常回報的失效。 收錄新東西時沒有充分更新交叉引用， 舊頁面就悄悄過時了。一位在生產環境跑這套的人強調，定期的 lint pass 不是選配。

四、大型文件這套處理不了。 它預設每份來源短到可以一次讀完。 面對一本四百頁的書或一個大型 codebase，你需要一個前置的檢索步驟—— 那正是 RAG 的用途，只是它擺在攝取端當鷹架，而不是擺在查詢端當介面。

還有一個不算缺點、但必須認清的前提：人工審查是最後一道防線。 這個模式之所以能運作，正是因為有一個人在看 AI 產出了什麼。 一旦攝取全自動化，這道防線就沒了——而 rohitg00 的《LLM Wiki v2》正好主張要自動化到 On new source: auto-ingest 的程度。這是我讀到的兩份來源之間唯一直接衝突的地方， 兩篇時間太近，也沒辦法用「較新的贏」來裁決。

我自己的判斷是兩邊講的是不同層次：索引更新、連結維護、格式檢查，該全自動； 但 auto-ingest 越線了，因為它讓「AI 寫的東西進入 source of truth」這一步， 不再經過任何人的眼睛。

五、所以，什麼時候能用

Lahoti 給的判定很乾脆：個人 wiki，「Write-time wins」； 需要三年後仍可信的團隊知識庫，「Query-time wins, and it isn’t close.」

以及那個在攝取第一份文件之前該先問自己的問題：

「當這個知識庫裡的某件事，兩年後被發現是錯的，我有辦法追出為什麼嗎？ 如果答案要經過某個 LLM 寫下、然後被當成來源索引起來的內容——你已經輸了。」

六、最後一件事：上面沒有一格是量出來的

前面五節都在講機制。這節講一件更基本的事：這整個題目的證據等級都偏低。

完全沒有 benchmark。 沒有任務定義、沒有 scale curve、沒有跟 hybrid RAG、GraphRAG、 long-context prompting、NotebookLM 這些 baseline 的任何比較。這是最大的洞， 而且我讀的四份來源沒有一份補上。

批評方是機制論證。 Lahoti 的邏輯站得住，但他沒有量化過 drift 速度、 也沒有量化過錯誤複合率，更沒有 write-time 對 query-time 的實測。 他也沒定義「團隊規模」的門檻在哪，只給了兩個端點，中間全是空白。

擴充提案方有利益關係。 rohitg00 的提案跟他自家產品高度重疊，文末又連了一次。 這不代表他講的是錯的，但讀的時候要把這個傾向算進去。

「100–200 頁」是三個人的自述，不是量測。 三個互不相關的人收斂到同一區間， 這已經是拿得到的最強證據了——但三個自述加起來，還是自述。

Karpathy 的兩份文件是同一個人寫的。 他先在 X 發短版，兩天後發 gist。 引用兩次，不等於兩個獨立證人。

老實的總結： 如果你是一個人、規模不大、每次收錄你自己都會看過，這個模式落在 兩份批評性來源都明確背書的格子裡，放心跑。 但不要拿「我跑得很順」去推論它在團隊也能跑， 也不要把「三個人講一樣的話」當成實證。

來源