真正該停止喊『RAG 已死』的原因，不是因為 RAG 完美，而是 LLM Wiki 與 RAG 根本不在同一個規模戰場

這串 Threads 是對 Karpathy LLM Wiki 討論的另一個版本整理，但它有一個很值得記錄的優點：它先把一句最容易被拿來帶風向的話拆掉。

Karpathy 根本沒有說 RAG 已死。

真正的問題從來不是誰取代誰，而是：

• LLM Wiki 解的是什麼規模的知識問題？
• RAG 解的是什麼規模的檢索問題？
• 哪些優勢只是因為資料量還小？
• 哪些痛點一旦放大就會爆炸？

這篇真正值得記錄的，不是它又重複講了一次活水 vs 死水，而是它把『戰場尺度』這件事直接講穿。

這篇真正值得記錄的重點

1. LLM Wiki 的成立前提，是整份知識庫還看得完、改得動、塞得進 context

這串 Threads 一開始就抓住 Karpathy 方法真正適用的區間：

• 大約百份來源
• 幾百頁內容
• 個人知識管理 / 小團隊 wiki / 讀書筆記 / 競品分析這類場景

在這個尺度下，wiki 式方法有幾個明顯優勢：

• 結構化
• 知識可累積
• 有章節脈絡
• 能整體丟進 context
• 成本還撐得住

也就是說，它不是比較聰明，而是在小規模下可以真的維持全局。

2. 一旦規模放大，最先爆掉的不是 retrieval，而是 bookkeeping 與矛盾處理

這篇後面幾段其實很關鍵，因為它把問題指回同一個核心：

• 幾百頁時，LLM 可以順手更新多個頁面、交叉引用與摘要
• 十萬份文件時，整份知識庫根本塞不進 context
• 每次 ingestion 都只能看到局部
• Lint / 矛盾掃描會變成巨大成本
• 新資料還會不停流入

也就是說，規模放大後最先崩潰的，不一定是回答品質，而是：

整個系統已經沒有能力維持知識的一致性。

3. RAG 真正解的，不是『理解更深』，而是『在大規模下還能跑』

這串文把 RAG 的價值說得很準：RAG 的強項從來不是比 wiki 更有智慧，而是當整份知識庫根本不可能被一次看完時，它仍能透過切分、索引、檢索，把相關片段拉回來。

所以真正成熟的說法不是：

• wiki 打敗 RAG
• 或 RAG 打敗 wiki

而是：

• 小規模下，wiki 路線更像活水知識系統
• 大規模下，RAG 是唯一還能撐住的可擴展路線

4. 近年各種 RAG 變形，本質上都在把『活水能力』補回來

這串 Threads 也提到一個非常值得記的點：GraphRAG、RAPTOR、HippoRAG、Self-RAG、Agentic RAG 等等，看似新招，其實本質上都在補傳統 RAG 的弱點：

• 多跳推理
• 層級摘要
• 關聯索引
• 檢索品質評估
• 自我修正
• 動態查詢流程

換句話說，整個方向不是『丟掉 RAG』，而是：

把 RAG 從一次性的片段查詢，推向會累積、會修正、會有流程的知識系統。

5. 「RAG 已死」這種句子最大問題，是把不同場景硬塞進同一個比較框架

這篇最後收得很好：Karpathy 的 LLM Wiki 是很漂亮的個人知識管理方案，但那是「我讀了 80 篇論文後整理成一份隨時可查的筆記」這類問題；它不是「我公司五年份 Slack、Notion、Linear、客服逐字稿、法律文件要怎麼給全員查」這種問題。

這種時候再喊誰取代誰，通常只是為了流量，不是為了工程判斷。

我的判讀

這篇真正值得記錄的，不是它再講一次 RAG vs wiki，而是它把一個很常被忽略的工程原則講清楚：

很多 AI 系統之爭，表面上看像方法論之爭，實際上常常是規模區間不同。

如果這件事沒先切清楚，最後就很容易把：

• 個人知識管理
• 小團隊 wiki
• 大規模企業知識檢索

這三種完全不同問題混在一起講，然後得出一個看起來很有流量、但工程上沒什麼用的結論。

Allen 的一句話版

這篇真正值得記的，不是『RAG 沒死』這種口號，而是它把尺度切清楚了：LLM Wiki 與 RAG 根本不在同一個規模戰場，小規模知識系統可以走活水 wiki，大規模知識系統仍然得靠 RAG 撐住。