RAG 沒死，它只是跟 LLM Wiki 不在同一個戰場

每隔幾週就會有人跳出來喊某個技術死了，這次輪到 RAG。

2023 年大家喊 "fine-tuning 死了，因為有了 RAG"。2024 年 Gemini 1.5 把 context window 撐到百萬 token，又有人喊 "RAG 死了，全塞進 prompt 就好"。現在輪到 Karpathy 的 LLM Wiki——然後同一批人再一次喊 RAG 死了。

有趣的是，RAG 原本就是被拿來 "殺" fine-tuning 的那把刀，轉個身自己被放到斷頭台上示眾兩次。

我把 Karpathy 那篇 gist（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）從頭到尾看過一次，結論很清楚：他根本沒說要取代 RAG，甚至在文章最後還寫了 "Everything mentioned above is optional and modular"。他在講的是一個很具體的場景，跟大家在 Pinecone、Weaviate 上做的事根本不是同一件事。

Karpathy 的 LLM Wiki 在幹嘛

簡單說，就是把你平常丟給 LLM 的零碎資料——讀過的論文、看過的書、專案筆記、客戶訪談逐字稿——交給 LLM 自己讀、自己寫成 wiki、自己維護交叉引用跟摘要。每一次查詢不是跑向量搜尋，而是直接把這份 wiki（或其中幾個章節）塞進 context。

他自己給的適用範圍很明確：大約 100 份來源、幾百頁內容。對應到的用途也很生活化：個人知識管理（健康、心理、目標）、深入研究某個主題、讀書筆記、小團隊的內部 wiki、競品分析、出差行程規劃。

在這個規模下，wiki 路線確實打敗 RAG。原因也不難懂：

• 結構化：你親手整理過，知識之間的關聯是人腦理順的，不是向量空間硬湊的。
• 可累積：每次讀到新東西可以編回 wiki，知識會滾動成長。
• 有脈絡：整個章節一起丟進 context，LLM 不會看到被切碎的 chunk。
• 成本夠低：幾百頁文字現在的 context window 一次塞得下，根本不用做檢索。

更關鍵的是，Karpathy 真正在講的不是 "小規模贏"，而是 "活水贏死水"

大部分轉發那篇文章的人只抓了 "RAG 像金魚、每次 query 都是全新的開始" 這個比喻，但原文裡他花更多篇幅在講另一件事：知識庫真正的痛點不是讀、也不是思考，而是 bookkeeping——更新交叉引用、讓摘要保持最新、記下新資料跟舊說法矛盾的地方、維持整本 wiki 幾十頁之間的一致性。

他甚至設計了一個叫 Lint 的動作，讓 LLM 定期去掃整份 wiki，找出 "頁面之間的矛盾" 和 "被更新資料推翻掉的陳述"。換句話說，LLM Wiki 真正的主張是：每一份新資料進來，都要主動跟舊的內容比對，發現矛盾就記下來、舊說法被新資料推翻就更新交叉引用和摘要。這是一池需要被持續攪動的活水。

反過來看，如果你只是把 PDF 一份份切 chunk 丟進向量資料庫，不做摘要、不做整合、不檢查矛盾，長期下來收集到的就不是知識，是一灘死水裡的雜訊。同一個問題可能有三個互相打架的答案並存、舊資料跟新資料平起平坐、該被推翻的陳述還會被檢索回來當事實。這種狀態下 LLM 即使找到 chunk 也拼不出可靠答案，人只是額外被噪音困擾而已。

這裡順便補一個很多人沒注意到的細節：Karpathy 在整份文件裡明確把寫跟維護都交給 LLM——他寫得很直白，"You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it"，人只負責挑來源、問好問題、想它代表什麼。但他同時在矛盾處理這塊留了一大塊空白：發現矛盾之後誰來 resolve，他全程沒寫。新資料跟舊說法打架，是 LLM 自己挑一個版本蓋掉、還是把兩個都留著讓人判斷？他一律只用 "note"、"look for" 這種觀察性的動詞帶過，沒有 resolution policy、沒有 approval gate、沒有 escalation 流程。

這個留白在他那個規模下完全不是問題。幾百頁內容，LLM 標了三個矛盾就三個，人自己點進去花幾分鐘判斷、改掉就好；就算 LLM 亂 reconcile 出錯，整份 wiki 小到人讀得完，發現歪了隨時能回頭校正。規模夠小的時候，模糊就是優雅。

但把同樣的流程放大，這個留白會直接爆炸。十萬份文件、每天標出三千個矛盾，沒人有空逐條看；讓 LLM 自己亂 reconcile，錯誤會靜靜滲進下游十萬次檢索，等你察覺時通常已經太晚。而這還只是矛盾處理這一塊；Karpathy 整套維護流程裡，光是 ingestion 本身在規模上就已經不成立。

要講清楚這件事，要先搞懂為什麼 Karpathy 的流程在小規模會 work。不是因為人親手維護，而是因為 LLM 在那個規模下真的做得到全局 bookkeeping。幾百頁整份塞得進 context window，每一次 ingestion LLM 都能看到全局；新進一份文件，它可以順便更新十幾個相關頁面的交叉引用，再跑一遍 Lint，成本低到可以忽略。Karpathy 自己那句 "can touch 15 files in one pass"，前提正是整份 wiki 總共也就那幾十頁。

但把規模放到 10,000 份、10 萬份呢？全公司累積五年的 Slack 訊息、Notion 頁面、Linear 工單、Zoom 逐字稿、客服對話、Git commit、legal 文件呢？

這個規模下扛不住的不是人，是 LLM 自己。整份知識庫早就不可能塞進 context，每次 ingestion 只能看到局部，根本做不到跨十萬頁維持一致性。Lint 要找頁面之間的矛盾本質上是個 O(N²) 的活——100 份是小事，10 萬份跑一輪要多久、要花多少錢？而且新資料還在一直湧進，上一輪 Lint 還沒跑完，下一批一千筆又已經排隊進來。

Karpathy 那套流程在小規模是優雅的，在這個規模下是系統本身做不到——而他留白的那塊 resolution flow 就再也沒有任何後援可以收尾。

這才是 RAG 真正被發明出來要解決的問題：當資料量大到連 LLM 自己都無法對整份知識庫做全局 bookkeeping，你需要一套在那個規模下還跑得動的自動切分、自動索引、自動檢索系統。向量搜尋的強項從來就不是 "比 wiki 聰明"，而是 "在 wiki 根本跑不動的規模下，還能幫你找到相關片段"。

所以這根本不是 A 取代 B，是兩個完全不同的規模區間：

• 幾百份來源以下、整份 wiki 還塞得進 context window：讓 LLM 自己維護一份 wiki 贏。
• 幾萬份來源以上、每天還在增加、連 LLM 都無法一次看到全局：只有 RAG 那條路。

RAG 的確有盲點

把 RAG 捧上天也不公平，它真的有幾個讓人頭痛的問題：

• chunk 切得爛：把一份合約切成 500 字的小塊，重要的條款可能剛好跨在切點上。
• 語意被打散：一篇文章的論點散在好幾段，向量搜尋只回傳其中一段，LLM 就拼不回原意。
• 多跳推理弱：問 "A 跟 C 有什麼關係"，但資料裡只寫了 "A 跟 B 有關"、"B 跟 C 有關"，純向量搜尋很難把這兩段自己串起來。
• 沒有知識累積：這點 Karpathy 講得沒錯，每次查詢都是從零開始，系統學不會。

這幾年冒出來的 RAG 變形，基本上都是在補這些洞：

• GraphRAG（Microsoft 提出）：先把整個語料庫抽成一張知識圖譜——誰和誰有關係、事件和事件怎麼連——查詢時不只靠向量相似度，還會沿著圖的關係走，多跳推理因此做得起來。
• RAPTOR：把文件做階層式的分群和摘要，形成一棵樹。問細節的時候查葉節點，問宏觀問題的時候查上層的摘要節點。等於是把 Karpathy 說的 "人工 wiki 結構" 自動生出來。
• HippoRAG：借用海馬迴的概念，在知識之間建立關聯索引，讓系統有類似 "聯想" 的能力。
• Self-RAG / CRAG：讓 LLM 自己評估檢索回來的東西夠不夠好，不夠就重新查、換查詢、或直接承認 "我不知道"。
• Agentic RAG：把檢索包成工具，讓 agent 視情況決定要查幾次、怎麼查、查完要不要再查一輪。

這些都不是在 "取代 RAG"，而是在做一件 Karpathy 在小規模下可以留白的事：把 resolution flow 強制形式化，把 RAG 從 "一次性的向量查詢" 推向 "會累積、會自我修正" 的知識系統。

回到那個 "RAG 已死" 的論調

真正的狀況幾乎都一樣：新方法補上舊方法的某個弱點，然後被拿來宣稱舊方法整個沒用了。

Karpathy 的 LLM Wiki 是一個很漂亮的個人知識管理方案，我自己也想照著做一份。但它解決的是 "我讀了 80 篇論文想要整理一份隨時可查的筆記" 這種規模的問題，不是 "我公司五年份的內部文件要怎麼讓全員查得到" 這種規模的問題。

這兩個戰場的打法完全不一樣。把它們混在一起然後喊誰取代誰，只是在製造流量，對真正要解決問題的人沒什麼幫助。