Claude Code 拔掉向量搜尋：RAG 之外的三種接地方式

Claude Code 早期版本是有向量資料庫的。

作者 Boris Cherny 在 X 上講得很白：他們很快就發現讓模型自己拿工具去搜比較好用，順便省掉安全、隱私、索引過期、可靠度這一整串麻煩。那則貼文有 120 萬次瀏覽，之後 Cursor、Cline、Codex CLI 都往同個方向走。

但如果你就這樣得出「RAG 死了」，你會在下一個專案踩得很慘。因為那次實驗同時換掉了兩件事，而只有一件會外推。

吳恩達那份 AI 工程技能圖裡，「建構與部署 AI 應用」底下六個子技能，有一項叫「用資料為模型接地」。他的原話大意是：RAG 加向量檢索只是早期做法，現在真正要判斷的是該用向量索引、知識圖譜，還是在結構化資料上蓋一層語意層。

這篇把那句話展開成一張你可以照著選的表。

那次實驗到底證明了什麼

你打開一個陌生的 repo，想找付款流程寫在哪。你會做什麼？

大概是 grep 一下 processPayment。你不會先把整包程式碼切成 512 token 的 chunk、算 embedding、丟進向量庫，然後問它「跟付款有關的段落」。

程式碼有兩個特性讓 grep 贏得毫無懸念。函式名是唯一而且拼字精確的，找 getUserById 不需要語意相似度。而 repo 本身就有結構，資料夾和 import 關係就是一份現成的索引。

程式碼的索引早就寫好了，它叫做資料夾。

不過那次實驗其實同時換掉了兩件事：精確比對取代語意比對，以及多輪檢索取代單次檢索。前者只在拼字精確的語料上成立，後者幾乎在所有語料上都成立。把兩件事綁在一起講，就會推出「RAG 死了」這種太大的結論。

選項一：讓模型自己去撈

Agentic search 是一種檢索方式：不預先建索引，而是把 grep、glob、讀檔這類工具交給模型，讓它自己決定搜什麼、搜幾次、什麼時候算夠了。

Amazon Science 有一篇論文正面測了這件事。拿掉向量庫、只給 agent 基本的關鍵字搜尋工具，在六個資料集上拿到傳統 RAG 九成以上的表現，其中 faithfulness 一項達到 94.5%。論文自己也列了限制：文件一大就掉、多媒體處理受限、context window 會卡，而且抓不到「沒有明說但語意相關」的東西。

LlamaIndex 另外做過一組對照，結論剛好補上另一半。agent 版的正確性和相關性都比較高（8.4 對 6.4、9.6 對 8），但平均慢了 3.81 秒（11.17 秒對 7.36 秒），因為每一輪都要跟模型來回一次。

所以它適合誰。語料頻繁變動、關鍵字精確、可以接受延遲的場景。即時對話的客服前台不適合，背景跑的分析任務很適合。

選項二：知識圖譜，漂亮數字都是賣圖的人測的

主管問你「哪些政策會影響供應鏈部門」。

這題向量搜尋幾乎注定答不好。因為「供應鏈部門的上層單位是誰」這個關係不在任何一段文字裡，它在組織圖裡。你把階層拍平成 chunk 的那一刻，結構就沒了。

網路上你會看到一堆 GraphRAG 完勝的數字。AWS 和 Lettria 合作的評測是 80% 對 50.83%；V7 在一千份文件上測出 93.8% 對 72.1%，最難的那批題目是 91.7% 對 36.3%；Diffbot 更早的 benchmark 則是從 16.7% 拉到 56.2%。

這三個數字的出處，分別是一家知識圖譜 NLP 公司、一家文件 AI 公司、和一家知識圖譜公司。沒有一個是中立第三方。

非廠商的評測長什麼樣？一篇針對 ORAN 電信規格的學術論文，在同一套題目下，混合式 GraphRAG 的事實正確率是 0.58，純 GraphRAG 是 0.50，而向量 RAG 在簡單題上反而最高（0.61），要到難題才掉下去。混合式雖然正確率最高，context 相關性卻只有 0.04，因為它把兩邊結果都塞進去，廢話變多了。

廠商測的是自己最強的那批題目，你要問的是你的題目長不長那樣。

真正可靠的規律不是「圖比較準」，而是查詢要跨幾個實體、要跳幾層關係。只有一兩個實體的「找跟 X 有關的文件」，向量搜尋就夠了，加圖只是多花錢。要串起三個以上實體、而且關係本身就是答案的時候，圖才開始值得。這條線也是OpenSpace 用 Graph 重做知識庫在賭的東西。

選項三：語意層，它最大的價值是會說「我答不出來」

主管問「上季北區的毛利率」。你的 agent 生了一段 SQL，跑出來一個數字，看起來很合理。

但它 join 到的是一張 staging 表，裡面有還沒沖銷的退貨。沒有人會發現。

語意層是蓋在資料表之上的一層業務語彙：指標怎麼算、維度有哪些、哪些能交叉。模型不再自己拼 SQL，而是去呼叫這些已經定義好的指標。

模型的 text-to-SQL 到底行不行，完全看你拿什麼題庫問。

Spider 2.0 是 632 題，取自 BigQuery、Snowflake 這類真實企業環境，資料庫動輒超過一千個欄位，正解 SQL 常常破百行。同一批模型，題庫從乾淨換成真實，正確率掉了七十個百分點以上。

dbt 在 2026 年重跑了自家評測。全題庫的 text-to-SQL 從 33% 提升到 64.5%，模型確實進步很多；但在語意層涵蓋範圍內的題目，語意層做到 98.2%（Claude Sonnet 4.6）和 100%（GPT-5.3 Codex）。這是 dbt 自己測的，數字要打折看。不過裡面有一個觀察不需要打折：text-to-SQL 錯的時候是安靜地錯，語意層答不出來的時候會直接說它答不出來。

給老闆的數字，錯得大聲比錯得安靜好。

所以你該選哪一個

先問你的查詢長什麼樣，不要先問哪個資料庫比較潮。

多數正式環境最後都是混的，但混合不是免費的。上面那篇 ORAN 論文就顯示，把兩種檢索結果全塞進 context，事實正確率會升，context 相關性反而崩到 0.04。加一種檢索來源之前，先想清楚你要拿什麼去砍掉多出來的雜訊。

還有一件事跟資料庫無關：文件本身要能被讀。PDF、HTML、掃描件轉成模型吃得下的格式，加上一條讓資料保持乾淨和新鮮的管線，這部分的工作量通常比選檢索方式大得多，也最常被低估。

利益揭露：以下是聯盟連結。如果法遵或隱私因素讓你必須把 embedding 模型留在自己機器上跑，24GB 這一級的工作站顯卡是常見的起點，麗臺 RTX PRO 4000 Blackwell 規格上剛好落在這個區間。

回到吳恩達那句話

六個子技能裡，「用資料為模型接地」最容易被誤讀成「選一個資料庫」。它其實是「你的查詢分佈長什麼樣」的問題。

而多數團隊從來沒看過自己的查詢分佈。要看，就得回到讀真實 trace 做錯誤分析那一套。你上一次真的去翻使用者實際問了什麼，是什麼時候？

常見問題

RAG 是不是已經被淘汰了？

沒有，被淘汰的是「一律先建向量索引」這個預設值。向量檢索在大量非結構化文件、跨措辭查詢、多模態檢索上仍然沒有替代品。程式碼這種拼字精確又頻繁變動的語料，才是它輸得最徹底的地方。

為什麼 Claude Code 不用向量資料庫？

Boris Cherny 說早期版本確實用過 RAG 加本地向量庫，但很快發現 agentic search 比較好用，而且省掉安全、隱私、索引過期、可靠度這幾類問題。程式碼的函式名唯一、資料夾結構本身就是索引，grep 找得比語意相似度準。

知識圖譜真的比向量搜尋準三倍嗎？

要看是誰測的。那些兩倍到三倍的數字幾乎都來自賣圖資料庫或知識圖譜的廠商。非廠商的學術評測差距小得多，向量檢索在簡單題上還可能贏。真正的判準是你的查詢要串幾個實體，不是廠商的百分比。

什麼時候該做語意層而不是讓模型直接寫 SQL？

答案是一個會被拿去做決策的數字時。text-to-SQL 在乾淨題庫上有八九成正確率，換到真實企業資料庫掉到一兩成，而且它錯的時候不會告訴你。語意層答不出來會直說。

這四種可以混用嗎？

可以，多數正式環境都是混的。但混合會稀釋精準度，有評測顯示混合式的事實正確率最高、context 相關性反而最低。加一種來源就要多一道過濾。