向量已死? Grep 萬能? 不，你需要的是「策展」一組檢索工具

最近一篇 PwC 的論文 Is Grep All You Need? How Agent Harnesses Reshape Agentic Search 在 X 上吵得蠻兇的，戰火還燒到一個更聳動的問題: 向量檢索已死? 這標題擺明在挑釁: 都 2026 年了，Claude Code、Codex 這些命令列 agent 光靠 grep 加 bash 就能找到東西，那花大錢養 embedding 模型、維護向量資料庫的 RAG 一整套基礎設施，是不是可以直接拆掉了?

LlamaIndex 的 Jerry Liu 第一時間就 出來潑了一盆冷水。小編覺得這個爭論很值得整理，因為它背後藏著一個更精準的判斷: grep 不是萬靈丹，它只在「高訊號關鍵字」的場景才真的好用，而那個場景剛好就是寫程式。

論文到底發現了什麼

先給論文該有的肯定。它做的事情很實在: 把 grep 和向量檢索兩種工具，接到四種不同的 agent harness 上(自製的 Chronos，以及 Claude Code、Codex、Gemini CLI)，拿 LongMemEval 這個長期記憶基準測試的 116 題來跑，看誰準。

結論有兩層:

🔹 第一層 (標題黨那層): 在「行內回傳」(inline)模式下，grep 的準確率在每一組 harness 與模型的配對上，都贏過向量檢索。最大的差距是 Gemini Flash-Lite 在 Chronos 上的 86.2% 對 62.9%。而且在第二個實驗裡，當你不斷往上下文裡塞無關的干擾對話，向量檢索的準確率會往下掉，grep 卻幾乎不動，因為純字串比對天生免疫於向量空間裡的「距離漂移」。

🔹 第二層 (作者真正想講的): harness 比演算法更重要。同一個 Claude Opus 4.6，在 Chronos 上 grep 能到 93.1%，換到 Claude Code 上只剩 76.7%。換 harness 造成的落差，跟換檢索演算法的落差差不多大。更誇張的是，改用「檔案式」(programmatic，把結果寫進檔案、讓 agent 自己去讀)的回傳方式，原本 grep 的優勢直接被抹平、甚至反轉: Codex 配 GPT-5.4 從行內 grep 的 93.1%，崩到檔案式 grep 的 55.2%。

編按: 所以這篇論文真正的重點不是「embedding 已死」，而是「你花在 harness 設計上的心力，應該遠多於花在挑哪個向量資料庫」。grep 只是眾多旋鈕裡的一個，而且通常不是最關鍵的那顆。

第一個關鍵: 它測的是「對話記憶」，不是企業文件

Jerry Liu 的批評一針見血。LongMemEval 測的是「翻找使用者過往的聊天紀錄」: 明確的日期、數字、偏好、使用者講過的話。這種題目的答案，往往就藏在某幾段「逐字、原封不動」的文字裡(論文稱為 literal spans，字面證據)。

這正是 grep 的主場。你要找的東西本來就是一個精確的字串，當然是字串比對贏。

但企業 RAG 的典型場景完全不是這樣: 對著一堆財報、法律合約、SOP 文件問複雜問題。這些文件的語言是改寫過的、術語不一致的、偏概念的。LlamaIndex 後來也寫了 一篇完整回應，把 grep 在這種語料上的硬傷講得更白: 你 grep 不了 PDF、掃描影像、Office 檔;語料一上百萬份檔案，純線性掃描就開始吃力;更要命的是「詞彙對不上」: 使用者問的是「營收認列」，文件裡寫的卻是會計準則代號「ASC 606」，字面比對直接一無所獲。他們開的藥方是「分層處理」: 先用讀得懂版面的工具把文件解析出來、建索引做語意檢索，grep 只留著當精確比對的後援。

連論文作者自己都很誠實，在「限制」(Limitations)那一節白紙黑字寫著:

在證據很少以字面形式出現的領域(例如對改寫過的論文摘要做綜整、大量圖表的文件、或程式碼語意)，向量檢索和混合路由的表現可能會很不一樣。我們並不主張 grep 在通用情況下「贏過」向量檢索。

換句話說，論文自己都沒宣稱 grep 是通用解，是讀者(和那個標題)把它過度延伸了。

第二個關鍵: grep 吃的是「高訊號關鍵字」

為什麼寫程式是 grep 的完美場景? 因為程式碼裡的識別字(函式名、變數名、錯誤碼)本來就是必須精確比對的關鍵字。你要找 handleUserLogin 這個函式，grep 一秒就給你所有出現的位置，零歧義。反過來，向量檢索在程式碼上一直做不好，因為它會把語意相近、但根本不是你要的東西也一起撈進來。

Sara Zan 在 一篇實測文章 裡補了一個「到了 agent 時代才成立」的觀察: 傳統 RAG 假設「查詢必須一次就對」，所以拼命優化單次召回的品質。但 agent 打破了這個限制，它可以先用一個很爛的查詢搜一次，看看結果，再改寫查詢搜第二次。這種「反覆迭代」剛好補掉了關鍵字搜尋最大的弱點(怕你措辭不對)，又保留了它精確的優點。

把這兩件事疊起來，grep 的甜蜜點就很清楚了: 語料是純文字、查詢以高訊號的字面關鍵字為主(程式碼、log、識別字、日期、人名)、而且 agent 可以反覆迭代搜尋。中小型的程式碼庫幾乎完美命中這三個條件，難怪 Claude Code 這類工具用得這麼順。

第三個關鍵: 雙峰的查詢分布，逼你走向混合檢索

前面說 grep 怕措辭、吃不了概念查詢。有趣的是，向量檢索有個剛好對稱的盲區: 它接不住精確的識別字。Your Vector Database Is Not a Search Engine 這篇文章整篇就在打這個弱點，而它開出的藥方不是「改用 grep」，而是「混合檢索」。

它先點出一個容易被忽略的陷阱: 大家評估檢索效果都拿 BEIR、MTEB 這類基準測試，而它們清一色是「漂亮的自然語言問句」，在這種題目上向量檢索當然贏 BM25。但你把真實的查詢紀錄拉出來看，分布其實是雙峰的: 一半是對話式的問句，另一半是精確查詢(產品代碼、錯誤碼、內部工具名、版本號、專有名詞)，後者常常佔了超過三成的流量。而 SKU-47291 這種字串被 tokenizer 切成 subword 之後，根本不會落在它原本該在的位置，向量檢索只會回給你一堆「看起來很像、其實不是」的鄰居。

所以這篇的結論是: 把 BM25(抓精確關鍵字)和向量檢索(抓語意)平行跑，用 RRF(Reciprocal Rank Fusion，互補排名融合)把兩份結果合併，再加一個 cross-encoder reranker 重排。grep 怕措辭、向量怕識別字，兩邊剛好各補對方的盲區，這才是雙峰查詢唯一說得通的解。

這也解釋了為什麼產業正在快速倒向混合檢索。有資料顯示，企業導入混合檢索的意願，在 2025 年底短短一個季度內就從 10.3% 跳到 33.3%;而「超長上下文會讓檢索變得多餘」這個說法，則從 15.5% 崩到 3.5%。大家都是踩了坑才學乖的。

更好的框架: 別找銀彈，要「策展」一組工具

Elastic 的 Leonie Monigatti 最近在 一場 Maven 演講(內容也整理成 一篇文章)裡，把這件事講得更透徹。她有個大膽的觀點: 「上下文工程大概有八成，其實就是 agentic search(代理式搜尋)。」你以為自己在做的是上下文策展，但底層真正在運作的，是一堆搜尋工具。她還畫了一條清楚的演進線: 早期的 RAG 是固定流程，每次都只檢索一次、又無法自我修正;agentic RAG 把它換成一個搜尋工具，讓 agent 自己決定要不要搜、要搜幾輪;到了上下文工程的時代，來源變多了(本地檔案、資料庫、網路、記憶)，自然就需要好幾種不同的搜尋工具並用。

她現場示範了一個很傳神的畫面: 只給 agent 一個 shell 工具加上一堆本地檔案，然後丟一個需要語意理解的問題給它。結果 agent 用 grep「作弊」、硬是假裝在做語意搜尋: 自己腦補出一串同義詞(regulate、compliance、constraints、gdpr、governance)，連續 grep 好幾輪，最後居然也湊出了答案。能動是能動，但這真的是對的做法嗎?

她的結論，跟論文、跟前面那些反方文章，完全收斂到同一句話:

如果你在找一把萬能的銀彈搜尋工具，很抱歉要讓你失望了。目標不是找到那一把銀彈，而是「策展」(curate)出一組合適的搜尋工具，讓你的 agent 能應付各種不同的查詢。

Elastic 在 一篇延伸文章 裡，把這個策展原則整理成「低地板、高天花板」(low floor, high ceiling):

大多數 agent 兩種都需要，重點是兩者混搭，而不是幻想單一工具能通吃。

那一組工具到底該放哪些? Elastic 給的是「用數據決定」的做法，而不是憑空設計: 先給一個通用工具上線，然後記錄 agent 的真實行為(它呼叫了什麼、重試幾次、在哪裡卡住失敗)。當某種查詢模式反覆出現、或反覆出包，再針對它打造一個專用工具。每個工具都得「賺到」自己被放進工具箱的資格。Claude Code 只配大約 20 個工具，而不是塞進幾百個 MCP 工具，就是這個哲學的體現。

連 grep 陣營都在偷偷補語意能力

這裡有一個很有意思的訊號: 連 grep 陣營自己都在偷偷補語意能力。最近冒出一票「語意版 grep」的命令列工具，目標都一樣: 在不架整套向量資料庫的前提下，讓 agent 直接對本地檔案跑自然語言搜尋。

LlamaIndex 的 semtools 是用 Rust 寫的命令列工具，主打兩個指令: parse 先用 LlamaParse 把 PDF、Word 這些原本 grep 不了的格式轉成 markdown，search 再用 static embedding(model2vec)做「模糊的語意關鍵字搜尋」，而且 search 全程在本地跑。LlamaIndex 那篇介紹文的標題還故意取作 “SemTools: Are Coding Agents all you Need?”，擺明在跟這波 grep 風潮對話。

Jina 的 jina-grep 則更貼近 grep 原本的使用習慣: 用 Jina embeddings v5、在 Apple Silicon 上透過 MLX 純本地跑。你可以直接用 jina grep "error handling" src/ 以自然語言搜尋，也可以把傳統 grep 的輸出用管線丟給它做語意重排(grep -rn "error" src/ | jina grep "retry logic")，等於幫 grep 接上一顆語意大腦。

LightOn 的 ColGrep 則是這幾個裡面最能呼應本文主旨的一個。它基於 late interaction(ColBERT，延遲交互)的 LateOn-Code 模型，包成單一個 Rust 執行檔、100% 本地、程式碼完全不外流。關鍵是它預設就是混合的: 先用 regex 像 grep 一樣縮小候選範圍，再用 ColBERT 做語意排序，兩份排名用 RRF 合併。LightOn 講得很直白: ColGrep 不是要取代 grep，而是「把 grep 的優點吸收進來、再往上擴充」，官方數據說它正面對決贏純 grep 約七成，還省下 15.7% 的 token。

三個工具擺在一起看，結論幾乎自己跳出來: 純字面比對確實有天花板，連最擁抱 grep 的寫程式場景，大家都在想辦法把語意能力搬回 shell 裡。而 ColGrep 那套「regex + 語意 + RRF」的預設行為，根本就是把「策展一組工具」直接內建成單一工具，等於幫你預先把混合檢索組好了。

收斂成幾個實務判斷

把論文、Jerry Liu、Sara Zan、Elastic 全部疊起來，小編幫大家收斂成幾條:

1️⃣ 別一聽到「搜尋」就反射性地架向量資料庫: 如果語料是中小型純文字、查詢又以字面關鍵字為主、agent 還能反覆迭代，grep 往往是更省事的起點，省下一整層基礎設施。

2️⃣ 但也別反過來以為 grep 萬能: 它搜不了 PDF、圖片、Office 檔，搞不定同義詞和概念查詢，語料一大、延遲就線性上升。它的本質，是拿「延遲和 token」去換「彈性」。

3️⃣ 檢索層的標準答案是混合檢索: 就是上面那套 BM25 加向量檢索、合併後再重排;遇到需要多 hop 的關係推理，再疊上 GraphRAG。在真實的企業語料上，混合幾乎都打贏任何單一方法。

4️⃣ agent 層的標準答案是策展一組工具: 低地板的專用工具，搭配高天花板的通用工具，而不是硬塞一個萬能介面。組合勝過任何單一工具，但工具數量要克制，免得撐爆上下文、又害 agent 選錯工具。

5️⃣ 真正該花心力的地方是 harness: 這是論文最反直覺的發現。一個好的 harness，能讓模型反覆改寫查詢、查看片段、自己決定何時收手，就算配的是向量檢索，也可能贏過爛 harness 配 grep。檢索演算法只是其中一顆旋鈕而已。搜尋老兵 Doug Turnbull 在 Agentic Search Is Having a Grep Moment 裡進一步點出，harness 其實有兩層迴圈: 內層是 agent 自己改寫查詢、反覆迭代;外層則是一道由你定義的「程式化品質閘門」(他稱為 hook)，agent 搜完後拿結果去對領域標準把關(夠不夠新、夠不夠權威)，不合格就把具體理由回灌、叫它再搜一次。他的結論很犀利: grep 能在生產環境動起來，往往不是因為 grep 本身有多強，而是外面這層約束和驗證在替它扛品質。

回到那個挑釁的標題。Grep is all you need 嗎? 對中小型的程式碼庫，可能真的是;但只要場景一離開「高訊號關鍵字 + 純文字 + 可迭代」這個甜蜜點，答案就從「二選一」變成「怎麼搭配」。與其糾結該選 grep 還是向量檢索，不如先想清楚自己的資料長什麼樣、查詢分布如何、agent 能不能反覆迭代，再決定怎麼組工具，而且一定要建一套評估(eval)流程去量，別憑感覺。檢索沒有銀彈，只有策展得好不好的工具箱。