Agent 正在殺死 無腦 RAG, 談一下我棄用 RAG 大半年的感受
整理版優先睇
Agent + grep 已經可以取代唔少場景嘅RAG，作者分享自己棄用RAG半年嘅經驗同選擇標準。
作者係一個長期用 Obsidian 記筆記嘅人，庫入面有幾百篇 markdown，內容涵蓋讀書、項目、產品同對話。大半年前佢開始用 Claude Code（Agent 模式）嚟翻筆記，原本諗住要搞 RAG（切塊、向量化、reranker、graph RAG），但試完 Agent 之後就放棄咗。
作者發現 Agent + grep 已經能搞定九成場景：grep 冇變聰明，但 Agent 可以根據語境換詞、推理、跨文件 read、迭代重試，成個過程零基礎設施。佢實測一個問題：幫手揾「上下文工程」嘅筆記，Agent 用 20 秒、4 輪搜索就揾到，仲自己換咗「上下文管理」「context window」「prompt 複用」幾個關鍵詞。
但作者唔係話 RAG 已死，而係話 RAG 嘅不可替代地盤比想像中窄。仲需要用 RAG 嘅情況包括：數據規模太大（幾十萬級以上）、內容夾雜大量圖表（grep 睇唔到）、跨語言或術語跨度太大（向量空間嘅語義鄰近更穩）。其餘嘅中小型筆記庫，Agent + grep 已經夠用，仲慳返一筆 infrastructure 錢。
- Agent + grep 可以覆蓋九成個人筆記檢索場景，零基礎設施係最大優勢。
- 方法：用 Agent 根據語境自動換詞、跨文件 read 同迭代搜索，取代傳統 RAG 嘅向量索引。
- 差異：RAG 喺大規模、多模態、跨語言場景仍然唔可取代，但中小型庫已冇必要。
- 啟發：唔好再有工程慣性——見到文檔檢索就上 RAG，要先問三個問題：規模、模態、詞彙跨度。
- 可行動點：如果你嘅資料庫係 markdown 為主且少過幾萬篇，先試 Agent + grep，用唔掂先考慮 RAG。
由 RAG 轉向 Agent + grep 嘅契機
作者有個 Obsidian 筆記倉庫，幾百篇 markdown，主題橫跨讀書、項目、產品同對話。大半年前佢諗緊要唔要畀筆記上 RAG——切塊、向量化、reranker、graph RAG 都研究過。最後佢冇接，因為試用 Claude Code 幾日之後，發現 grep 加上 Agent 嘅迭代已經能搞定九成場景。
Agent 將 grep 由一個靜態工具變成一個能推理、能迭代嘅檢索流程
之前佢嘅認知係教科書答案：代碼用 grep，文檔用 RAG。原因係代碼嘅字串確定，但文檔寫法多變。不過 Agent 模式之下，grep 只係工具唔係答案，Agent 會根據語境換詞、推理、跨文件 read、迭代重試。
Agent + grep 實測：20秒揾到想要嘅筆記
作者做咗一次實測：叫 Claude Code 幫佢揾「去年嗰段關於上下文工程嘅筆記」。佢冇落手，睇住 Agent 點搜。
- 1 先搜「上下文工程」，冇乜命中。
- 2 換「上下文管理」，出一篇但內容唔啱。
- 3 再試「context window」，命中幾條。
- 4 最後試「prompt 複用」，揾到想要嘅筆記。
- 5 成個過程約 20 秒，4 輪搜索，最後 read 兩個文件確認。
呢個過程令作者意識到：grep 冇變聰明，變聰明係上面嗰層 Agent。Agent 能夠根據語境 自動換關鍵詞，跨文件 read，迭代重試。最重要係 零基礎設施——冇切塊、冇建向量庫、冇維護 embedding 模型。
RAG 真正唔可取代嘅地盤
作者唔係話 RAG 已死，佢用過幾年 RAG，知道強項。但 Agent + grep 呢波之後，RAG 嘅不可替代地盤比過去窄咗。佢歸納咗三種仲要 RAG 嘅情況：
- 數據規模太大：幾十萬、幾百萬級文檔庫，Agent 每次跑 4-5 輪 grep + read 延遲同成本都扛唔住，必須預索引。
- 內容夾雜大量圖：產品手冊嘅架構圖、掃描合同、PPT 截圖、視頻幀——grep 一律睇唔到，embedding 模型可以將圖像同文本編碼到同一向量空間。
- 跨語言或跨術語跨度太大：中文筆記英文問、專業術語對大白話，Agent 能換詞試一部分，但向量空間嘅語義鄰近性更穩，尤其係多語言文檔庫。
其餘嘅中小規模 markdown 庫、個人筆記庫、內部文檔庫？Agent + grep 跑一遍，往往比折騰一套 RAG pipeline 划算得多。
選擇檢索方案嘅新框架
作者提出三個問題判斷係咪需要 RAG：
- 1 你嘅數據規模真係大到 grep 扛唔住嗎？
- 2 你嘅資料裏面真係有 grep 睇唔到嘅模態嗎？
- 3 你嘅用戶問問題嘅方式，真係令 Agent 換 5 輪詞都換唔出嚟嗎？
三個問題有任何一個答「係」——上 RAG。都唔係？Agent + grep 大概率夠用，慳返一筆錢。佢強調「RAG 已死」唔係真死，係嗰種工程慣性——「只要是文檔檢索，就上 RAG」——死咗。
我有個 Obsidian 筆記庫，有幾百篇 markdown，主題橫跨讀過嘅書、做過嘅項目、睇過嘅產品、同人傾過嘅對話。
大半年前，我開始用 Claude Code 幫我翻呢啲筆記。
接 Claude Code 之前，我專門研究過要唔要俾筆記上 RAG——切塊、向量化、reranker、graph RAG，方案我都睇過。
最後我冇接。
唔係嫌麻煩，係因為接咗 Claude Code 跑咗幾日之後，我發現 grep 加上 Agent 嘅迭代，已經搞得掂 90% 嘅場景。
呢件事令我重新睇嚇最近半年網上嗰場「RAG 已死」嘅討論。
之前我嘅認知係教科書答案——
代碼用 grep，文檔用 RAG。
點解？因為代碼嘅字符串係確定嘅：函數名就係嗰一個寫法，錯誤碼就係嗰一個數字。
但文檔唔係咁樣。同一件事，我舊年可能寫嘅係上下文緩存，今年改寫過嘅筆記裏面叫 Prompt Caching，仲有一篇半中半英寫 prompt 複用。我自己寫嘅筆記，自己都唔一定 grep 得到。
所以教科書話必須切塊、向量化、揾 Top-K——令措辭唔一樣但意思接近嘅內容都命中到。
呢套邏輯聽落幾合理。
直到我俾 Claude Code 試咗一次。
Claude Code 翻筆記嘅一次實測
我抱住試嚇嘅心態，俾 Claude Code 翻一次筆記。
我問嘅問題係——幫我揾舊年嗰段傾上下文工程嘅筆記。
然後我冇動手，睇佢點樣搜。
它先搜 上下文工程，冇乜命中。
然後換 上下文管理，出咗一篇，但內容唔啱。
接着試 context window，命中幾條。
再試 prompt 複用，揾到嗰段我想要嘅。
成個過程大約 20 秒，4 輪搜索，最後 read 兩個文件確認。
我呆咗一下。
grep 冇變聰明。變聰明嘅係佢上面嗰一層。
grep 嘅邊界，俾 Agent 重新畫咗
普通 grep 只能搜你輸入嗰一個字符串。
但 Claude Code 呢種 Agent 模式下，grep 係工具，唔係答案。
Agent 會根據語境換詞、推理、跨文件 read、迭代重試。
我話上下文工程，佢會聯想到上下文管理、context window、prompt 複用，逐個試。
呢套流程喺幾百篇筆記嘅規模上，命中率幾高，速度都唔慢。
最關鍵嘅——零基礎設施。
我冇切塊，冇建向量庫，冇維護 embedding 模型，更加冇俾向量數據庫嘅錢。
後來我又用同樣嘅方式翻過幾次：
• 跨措辭：我用中文問，佢自動加幾個英文 keyword 一齊搜 • 跨主題歸納：我問佢我之前對某條推文嘅看法，佢先 grep 名，再 read 命中文件，再 grep 推文相關嘅關鍵詞 • 跨年份對比：我問佢今年同舊年喺 prompt 呢件事上嘅想法變化，佢分兩次搜索後做對比總結
呢啲場景喺冇 Agent 嘅時代，係 RAG 嘅舒適區。
而家俾 Agent + grep 食咗。
咁 RAG 真正不可替代嘅，係咩？
我唔係話 RAG 已死。我用過幾年 RAG，知道佢嘅強項。
但要老實講——Agent + grep 呢一波出咗之後，RAG 真正不可替代嘅地盤，比過去想像嘅窄。
我自己用落嚟，剩返呢幾種情況 RAG 都係慳唔到。
一種係數據規模太大。幾十萬、幾百萬級嘅文檔庫，每次查詢俾 Agent 跑 4-5 輪 grep + read，延遲同成本都頂唔住。呢種規模必須預索引，向量數據庫就係為呢個而生嘅。
一種係內容裏面夾咗大量圖。筆記裏面夾嘅係文字，grep 睇到；但產品手冊裏面嘅架構圖、掃描嘅合同、PPT 截圖、視頻幀——grep 一律睇唔到。embedding 模型可以將圖像同文本編碼到同一個向量空間裏面，呢個係 RAG 不可替代嘅地方。
仲有就係跨語言或者跨術語跨度太大。中文筆記英文問、專業術語對大白話——Agent 可以換詞試一部分，但跨度太大時，向量空間嘅語義鄰近性都係更穩。呢種情況喺多語言文檔庫裏面特別明顯。
剩返嘅中小規模 markdown 庫、個人筆記庫、內部文檔庫？
Agent + grep 跑一次，往往比搞一套 RAG pipeline 划算得多。
所以「RAG 已死」？
唔係死，係地盤俾壓縮咗。
死嘅唔係 RAG 呢個技術。死嘅係嗰種工程慣性——只要係文檔檢索，就上 RAG。
今日揀檢索方案，問嘅問題應該唔同咗：
• 你嘅數據規模真係大到 grep 頂唔住咩？ • 你嘅資料裏面真係有 grep 睇唔到嘅模態咩？ • 你嘅用戶問問題嘅方式，真係俾 Agent 換 5 輪詞都換唔出來咩？
三個問題有任何一個答係——上 RAG。
都唔係？Agent + grep 大概率夠用，慳一筆錢。
寫喺最後
grep 都係嗰個 grep，冇變。
變嘅係佢上面嗰一層。
Agent 將 grep 從一個靜態工具，變成咗一個可以推理、可以迭代嘅檢索流程。呢一層正在重新畫 grep 同 RAG 之間嗰條線。
具體可以劃到邊度，唔同場景有唔同答案。
我有個 Obsidian 筆記倉庫，幾百篇 markdown，主題橫跨讀過的書、做過的項目、看過的產品、跟人聊過的對話。
大半年前，我開始用 Claude Code 幫我翻這些筆記。
接 Claude Code 之前，我專門研究過要不要給筆記上 RAG——切塊、向量化、reranker、graph RAG，方案我都看過。
最後我沒接。
不是嫌麻煩，是因為接 Claude Code 跑了幾天之後，我發現 grep 加上 Agent 的迭代，已經能搞定 90% 的場景了。
這件事讓我重新看待最近半年網上那場「RAG 已死」的討論。
之前我的認知是教科書答案——
代碼用 grep，文檔用 RAG。
為什麼？因為代碼的字符串是確定的：函數名就那一個寫法，錯誤碼就那一個數字。
但文檔不是這樣。同一件事，我去年可能寫的是上下文緩存，今年改寫過的筆記裏叫 Prompt Caching，還有一篇半中半英寫 prompt 複用。我自己寫的筆記，自己都不一定能 grep 到。
所以教科書說必須切塊、向量化、找 Top-K——讓措辭不一樣但意思接近的內容也能命中。
這套邏輯聽起來挺合理。
直到我讓 Claude Code 試了一次。
Claude Code 翻筆記的一次實測
我抱着試試的心態，讓 Claude Code 翻一次筆記。
我問的問題是——幫我找去年那段聊上下文工程的筆記。
然後我沒動手，看它怎麼搜。
它先搜 上下文工程，沒什麼命中。
然後換 上下文管理，出來一篇，但內容不對。
接着試 context window，命中幾條。
再試 prompt 複用，找到了那段我想要的。
整個過程大約 20 秒，4 輪搜索，最後 read 兩個文件確認。
我愣了一下。
grep 沒變聰明。變聰明的是它上面那一層。
grep 的邊界，被 Agent 重新畫了
普通 grep 只能搜你輸入的那一個字符串。
但 Claude Code 這種 Agent 模式下，grep 是工具，不是答案。
Agent 會根據語境換詞、推理、跨文件 read、迭代重試。
我說上下文工程，它能聯想到上下文管理、context window、prompt 複用，挨個試。
這套流程在幾百篇筆記的規模上，命中率挺高，速度也不慢。
最關鍵的——零基礎設施。
我沒切塊，沒建向量庫，沒維護 embedding 模型，更沒付向量數據庫的錢。
後來我又用同樣的方式翻過幾次：
• 跨措辭：我用中文問，它自動加幾個英文 keyword 一起搜 • 跨主題歸納：我問它我之前對某條推文的看法，它先 grep 名字，再 read 命中文件，再 grep 推文相關的關鍵詞 • 跨年份對比：我問它今年和去年在 prompt 這件事上的想法變化，它分兩次搜索後做對比總結
這些場景在沒有 Agent 的時代，是 RAG 的舒適區。
現在被 Agent + grep 吃掉了。
那 RAG 真正不可替代的，是什麼？
我不是說 RAG 已死。我用過幾年 RAG，知道它的強項。
但要誠實講——Agent + grep 這一波出來之後，RAG 真正不可替代的地盤，比過去想象的窄。
我自己用下來，剩下這幾種情況 RAG 還是省不了。
一種是數據規模太大。幾十萬、幾百萬級的文檔庫，每次查詢讓 Agent 跑 4-5 輪 grep + read，延遲和成本都扛不住。這種規模必須預索引，向量數據庫就是為這個生的。
一種是內容裏夾了大量圖。筆記裏夾的是文字，grep 能看見；但產品手冊裏的架構圖、掃描的合同、PPT 截圖、視頻幀——grep 一律看不見。embedding 模型可以把圖像和文本編碼到同一個向量空間裏，這是 RAG 不可替代的地方。
還有就是跨語言或跨術語跨度太大。中文筆記英文問、專業術語對大白話——Agent 能換詞試一部分，但跨度太大時，向量空間的語義鄰近性還是更穩。這種情況在多語言文檔庫裏特別明顯。
剩下的中小規模 markdown 庫、個人筆記庫、內部文檔庫？
Agent + grep 跑一遍，往往比折騰一套 RAG pipeline 划算得多。
所以「RAG 已死」？
不是死，是地盤被壓縮了。
死的不是 RAG 這個技術。死的是那種工程慣性——只要是文檔檢索，那就上 RAG。
今天選檢索方案，問的問題應該不一樣：
• 你的數據規模真的大到 grep 扛不住嗎？ • 你的資料裏真的有 grep 看不見的模態嗎？ • 你的用戶問問題的方式，真的讓 Agent 換 5 輪詞都換不出來嗎？
三個問題有任何一個答是——上 RAG。
都不是？Agent + grep 大概率夠用，省一筆錢。
寫在最後
grep 還是那個 grep，沒變。
變的是它上面那一層。
Agent 把 grep 從一個靜態工具，變成了一個能推理、能迭代的檢索流程。這一層正在重新畫 grep 和 RAG 之間的那條線。
具體能劃到哪兒，不同場景有不同答案。