真正該停止喊『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 撐住。