RAG is dead, right?? — Kuba Rogut, Turbopuffer
三句話摘要
RAG 並未真正死亡，而是演變為混合式、迭代型的 agentic retrieval，成為現代 AI 代理系統的標準實踐。 RAG 並未死亡，而是從單次向量查詢演變為多工具、多輪次、智慧型的 agentic retrieval，其中預先索引是一次性投資，執行期則通過精準檢索獲得指數級的效率與成本優勢。 RAG 的真實定義被扭曲了：業界通常將 RAG 等同於向量搜索，但檢索增強生成（Retrieval Augmented Generation）應包括向量搜索、全文搜索（BM25）、正則表達式、基本篩選等多種方法，最後才將結果傳入 LLM。
重點整理
重點- 1
RAG 的真實定義被扭曲了：業界通常將 RAG 等同於向量搜索，但檢索增強生成（Retrieval Augmented Generation）應包括向量搜索、全文搜索（BM25）、正則表達式、基本篩選等多種方法，最後才將結果傳入 LLM。
- 2
Agentic search 是迭代式推理工具：與簡單的文件系統 grep 不同，真正的 agentic search 賦予 AI 代理一套工具來逐步且反覆地發現並推理上下文，代理能判斷是否已達成任務目標，並決定是否繼續搜索。
- 3
預先索引帶來指數級效率提升：Cursor 用 Merkle 樹計算代碼庫相似性，同一團隊開發者在 99% 情況下打開相同代碼庫，只重新索引變更檔案而非全部，語義搜索準確度提升 12-24%，同時節省大量 token。
- 4
嵌入是「緩存計算」而非浪費：相比每個查詢都從零開始 grep 與推理（每次耗費數千 token），一次性的索引投資使運行期查詢輕量化，對於大規模代碼庫和多代理並行查詢場景特別經濟。
實用技巧與重點
乾貨- 具體數字與效果指標：
- Cursor 語義搜索：平均 12.5-13.5% 答案準確度提升
- Cursor Composer 2：24% 準確度提升
- 線上 A/B 測試：2.6% 代碼保留率提升，2.2% 不滿意用戶請求下降
- 單一 agent grep 子步驟成本：~6,000 tokens
- 工具與公司：
- Turbo Puffer：全文搜索與向量搜索資料庫
- Cursor：使用語義搜索的代碼編輯器
- Claude Code：早期使用本地向量 DB RAG 但棄用，改用 grep
- Merkle 樹：用於計算代碼庫版本間相似性
- 技術方案：
- 檢索方法組合：向量搜索、BM25、grep、regex、篩選器
- Cursor 的優化：解析 → 分塊 → 嵌入，再用 Merkle 樹去重與增量更新
- Agent 迭代流程：grep → 讀檔 → 評估 → 重複（直到達成目標）
結論
結論“RAG 並未死亡，而是從單次向量查詢演變為多工具、多輪次、智慧型的 agentic retrieval，其中預先索引是一次性投資，執行期則通過精準檢索獲得指數級的效率與成本優勢。”
完整解析
詳細RAG 能否已死？這個問題在 2025 年末至 2026 年初的社群媒體炸裂式傳播，但 Google 搜尋量數據卻顯示另一回事——搜尋熱度在 2023 年初興起，2024 年穩定，到 2025 年中期再創新高。這種矛盾源自對 RAG 和 agentic search 兩個概念的普遍誤解。
業界常把 RAG 簡化為「向量搜索」，認為就是嵌入文本、查向量、丟進 LLM。實際上，RAG（檢索增強生成）的「檢索」層應涵蓋向量搜索、全文搜索（BM25）、正則表達式、基本篩選等多種工具，視查詢需求靈活組合。而「agentic search」也常被誤解為文件系統 grep，其實是賦予 AI 代理一套工具，讓它能多步驟、反覆地推理和尋找所需上下文——如果代理發現當前結果不足以完成任務，它能自主決定繼續搜索，形成閉環。
Cursor 是業界實踐的典範。他們在 2026 年初發表的技術文章詳述了代碼庫索引策略：開發者打開新代碼庫時，Cursor 會解析、分塊、嵌入整個代碼庫，使其可被語義搜索。妙處在於團隊中 100 名工程師絕大多數時間在操作同一兩個代碼庫——重複索引很浪費。Cursor 採用密碼學中的 Merkle 樹技術來計算版本間相似性，若相似度達標就複用舊數據，只對變更檔案重新分塊嵌入，借助 Turbo Puffer 確保安全性。這套機制帶來實質收益：語義搜索讓平均答案準確度提升 12.5-13.5%，Composer 2 模型甚至達 24%；線上 A/B 測試顯示代碼保留率提升 2.6%，不滿意請求下降 2.2%。
與之對比，Claude Code 早期採納 RAG（本地向量 DB），但創辦人 Boris Cherney 指出它對他們不奏效。背後的概念是「嵌入與語義搜索是緩存計算」。試想 Claude Code 的典型跡象：每當代理需要理解某功能（如元數據過濾），它得逐一 grep、讀檔、評估、重複，每次需 6,000 多 token，跨 10 位開發者、10 天、相同問題，重複成本累積。Cursor 則不同：投入前期索引成本後，執行期的代理只需輕量化查詢（「如何過濾元數據？」），立即獲得結果，省 token、省時、省錢，代理速度質變。
Google CEO Jeff Dean 曾言：「即使達到一兆 token 的上下文窗口，關鍵不是一次性獲取全部，而是精細檢索機制將其縮減至百萬級。你不需要一次擁有一兆，你需要的是正確的那百萬。」這正是 Turbo Puffer 的哲學——客戶儲存數兆 token，系統的價值在於快速篩選出適用的十萬、百萬級數據。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
