{"notes":[{"id":"retrieval-augmented-generation/is-grep-all-you-need","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Is Grep All You Need","subtitle":"Grep 就夠了？","author":"Z. Yuan","paperDate":"2026-05-14","publishedOn":"2026-08-29","paperTitle":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","paperUrl":"https://arxiv.org/abs/2605.15184","bibliography":{"title":"Is Grep All You Need? How Agent Harnesses Reshape Agentic Search","authors":["Sahil Sen","Akhil Kasturi","Elias Lumer","Anmol Gulati","Vamse Kumar Subbiah"],"url":"https://arxiv.org/abs/2605.15184","pdfUrl":"https://arxiv.org/pdf/2605.15184v1","codeUrl":null,"preprint":{"id":"2605.15184","submittedOn":"2026-05-14","url":"https://arxiv.org/abs/2605.15184"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationisgrepallyouneed2026,\n  title = {{Is Grep All You Need? How Agent Harnesses Reshape Agentic Search}},\n  author = {Sahil Sen and Akhil Kasturi and Elias Lumer and Anmol Gulati and Vamse Kumar Subbiah},\n  year = {2026},\n  eprint = {2605.15184},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2605.15184}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/is-grep-all-you-need.4ebb3c804df8.bib"},"thumbnail":{"src":"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png","width":944,"height":422},"locale":"zh-hant","path":"/content/papers/zh-hant/retrieval-augmented-generation/is-grep-all-you-need.68ade8a4c325.md","headings":[{"id":"定義問題","text":"定義問題","depth":2},{"id":"解決問題","text":"解決問題","depth":2},{"id":"任務在長對話裡找回記憶","text":"任務：在長對話裡找回記憶","depth":3},{"id":"兩種檢索工具","text":"兩種檢索工具","depth":3},{"id":"四種-harness","text":"四種 harness","depth":3},{"id":"兩種結果傳遞方式","text":"兩種結果傳遞方式","depth":3},{"id":"模型與評分","text":"模型與評分","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"實驗一grepharness-與傳遞方式","text":"實驗一：grep、harness 與傳遞方式","depth":3},{"id":"實驗二干擾越多會怎樣","text":"實驗二：干擾越多，會怎樣？","depth":3},{"id":"兩個實驗的數字對不起來","text":"兩個實驗的數字對不起來","depth":3},{"id":"作者自己劃的界線","text":"作者自己劃的界線","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"這兩年用過 Claude Code、Codex 或 Gemini CLI 的人，大概都看過這個畫面：你問它一個關於程式碼的問題，它先跑一串 `grep`，讀幾個檔案，再回頭回答你。\n\n這和過去幾年的 RAG 標準做法不太一樣。那時候的預設，是先把文件切塊、轉成向量，存進向量資料庫，再用語意相似度去找。\n\n於是很多人開始問：既然 agent 自己會 grep，向量檢索還需要嗎？\n\n這篇來自 PwC（美國）的預印本，2026 年 5 月發表於 arXiv。標題問的是「grep 夠不夠」，但讀完會發現，作者真正量到的是另一件事：**同一個檢索工具，放在不同的 agent 外殼裡，表現可以差很多。**\n\n\n> [!TIP]\n> \n> **Harness 是什麼？**\n> \n> 這篇論文反覆出現的 **agent harness**，可以想成「包在模型外面的那層程式」：它決定給模型哪些工具、系統提示怎麼寫、工具的結果用什麼格式送回去、什麼時候停下來。\n> \n> 同一個 Claude Opus 4.6，放在 Claude Code 裡，和放在自己用 LangChain 寫的 agent 裡，就是兩種 harness。模型一樣，看到的提示、工具說明和回傳格式都不一樣。\n\n\n## 定義問題\n\n作者認為，過去比較檢索方法的研究，大多假設一條固定的管線：檢索器找出文件，拼進提示詞，交給模型回答。\n\n但 agent 不是這樣用檢索結果的。它會自己決定要搜什麼、搜幾次、結果夠不夠，不夠就換個關鍵字再搜。這些行為都受 harness 影響。\n\n所以作者想回答三個問題：\n\n1. **grep 和向量檢索，在不同 harness 裡誰比較好？**\n2. **工具結果直接塞進對話，還是寫成檔案讓 agent 自己去讀，會改變結論嗎？**\n3. **無關的資料越來越多時，兩種檢索的表現怎麼變？**\n\n## 解決問題\n\n### 任務：在長對話裡找回記憶\n\n評測資料是 LongMemEval 的 116 題子集。\n\nLongMemEval 測的是長期對話記憶：每題附帶一大堆聊天紀錄（session），其中一個或幾個 session 藏著答案，其他都是無關的干擾。題目分成六類：\n\n| 類別 | 測什麼 |\n| --- | --- |\n| knowledge-update | 追蹤狀態隨時間的變化 |\n| multi-session | 跨多段對話彙整資訊 |\n| single-session-assistant | 回想助理自己說過的內容 |\n| single-session-preference | 使用者的個人偏好 |\n| single-session-user | 使用者說過的事實 |\n| temporal-reasoning | 計算時間長度、排列事件順序、推算日期 |\n\n舉個本文自擬的例子：題目可能是「我上次換工作是幾個月前？」，答案就藏在幾十段聊天紀錄的某一句話裡。\n\n作者另外用他們先前提出的 Chronos 前處理，把對話裡的日期、時間區間抽成結構化的事件紀錄，和原始對話一起存成每題各自的檔案。作者的理由是，這篇要測的是「找不找得到證據」，不是「會不會從零碎的對話推算日期」。\n\n### 兩種檢索工具\n\n**grep**：把每題的對話與事件紀錄載入記憶體，直接用正規表示式比對原始文字，按命中次數排序。不需要 embedding 模型、向量索引或任何外部服務。\n\n**向量檢索**：每一輪對話、每一筆事件都事先轉成 embedding，存進每題各自的索引。查詢時把問題轉成向量，用近似最近鄰搜尋找出候選，再經過一次重新排序（rerank），回傳前 $k$ 筆；$k$ 由 agent 自己決定。\n\n論文沒有寫明使用的 embedding 模型與 reranker 名稱。\n\n### 四種 harness\n\n- **Chronos**：作者自己用 LangChain 寫的 agent，有四個搜尋工具（對話與事件各有 grep 和向量版本），依實驗設定開關。系統提示會依題目類別動態調整，例如時間推理題和偏好題的提示不同。\n- **Claude Code**、**Codex CLI**、**Gemini CLI**：三家模型供應商自己的命令列 agent。作者給它們題目和一段動態產生的搜尋策略，讓它們透過 bash 呼叫包裝好的 grep 或向量搜尋腳本。\n\n\n> [!NOTE]\n> \n> **一個值得留意的設定細節**\n> \n> 依論文 §3.3.1 的描述，Chronos 在每題開始時會先放入一段「向量檢索前 15 筆」的初始脈絡，才進入工具呼叫的迴圈。論文沒有說明在 grep-only 的設定下，這一步是否也一併移除。讀 Chronos 的 grep 成績時，可以把這點放在心上。\n\n\n### 兩種結果傳遞方式\n\n- **Inline（標準）**：搜尋結果直接印到標準輸出，或作為工具回應插進對話。模型馬上看得到，但結果很多時會擠佔上下文。\n- **Programmatic（檔案式）**：搜尋結果寫進檔案，模型只拿到檔案位置，必須再呼叫一次工具去讀或去 grep 那個檔案。這能避免大量結果塞爆上下文，代價是多一個步驟。\n\n### 模型與評分\n\n受測模型有五個：Claude Opus 4.6、Claude Haiku 4.5、GPT-5.4、Gemini 3.1 Pro、Gemini 3.1 Flash-Lite。\n\n依照 LongMemEval 的評測方式，用 GPT-4o 當評審：看題目、標準答案和 agent 的回答，判斷對或錯。\n\n## 討論\n\n### 實驗一：grep、harness 與傳遞方式\n\n[![原論文 Table 1：五個模型在 Chronos 與各家 CLI 中，grep 與向量檢索在 inline 與 programmatic 兩種傳遞方式下的準確率](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)](/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png)\n\n*原論文 Table 1，取自 [**v1 PDF 第 5 頁**](https://arxiv.org/pdf/2605.15184v1#page=5)，CC BY 4.0。116 題、完整干擾資料；前兩欄為 inline，後兩欄為 programmatic。*\n\n每一列固定一組模型與 harness，四個欄位分別是兩種檢索乘上兩種傳遞方式。\n\n**先看前兩欄（inline）**。十組裡，grep 全部高於向量檢索。差距最大的是 Chronos 搭配 Gemini 3.1 Flash-Lite：86.2% 對 62.9%；最小的是 Claude Code 搭配 Claude Opus 4.6：76.7% 對 75.0%。\n\n**再看同一個模型、不同 harness**。Claude Opus 4.6 的 inline grep，在 Chronos 是 93.1%，在 Claude Code 只有 76.7%，差了 16.4 個百分點。同樣在 Chronos 裡，grep 和向量的差距是 9.5 個百分點。換 harness 造成的落差，和換檢索方法相當，甚至更大。\n\n**最後看後兩欄（programmatic）**。改成檔案式傳遞後，向量檢索在十組裡有五組反超 grep。最戲劇性的是 Codex CLI 搭配 GPT-5.4：inline grep 有 93.1%，和最好的成績並列；改成 programmatic，grep 掉到 55.2%，向量也只有 67.2%。\n\n作者的解讀有兩點：\n\n1. **LongMemEval 獎勵字面證據**。確切的日期、次數、偏好、原句，這些字串在斷詞前後都很穩定，grep 可以直接找到，不需要經過 embedding 這一關。\n2. **檔案式傳遞把任務變難了**。原本是「讀工具回傳的訊息」，現在變成「找到檔案、打開它、整合內容」。只要這多出來的一步不穩，準確率就可能和檢索品質無關地崩掉。\n\n\n> [!TIP]\n> \n> **116 題，差一題是多少？**\n> \n> 一題佔 $1/116\\approx0.86$ 個百分點。\n> \n> Claude Code 搭配 Opus 的 76.7% 對 75.0%，換算回題數是 89 題對 87 題，只差 2 題。論文每個設定看起來只跑了一次，也沒有報告變異範圍。差距只有幾題的比較，最好別看得太重。\n\n\n### 實驗二：干擾越多，會怎樣？\n\n第二個實驗調整每題能看到的 session 數量：5、10、20、30，以及完整的 39 到 66 個 session。含答案的 session 一定保留，其餘名額用同一題的干擾 session 補滿。\n\n常見的直覺是：資料少的時候 grep 就夠了，資料一多，就需要語意搜尋。\n\n結果沒有這麼單純：\n\n- **曲線不是單調的**。例如 Chronos 搭配 Opus 的 grep，從 s20 的 90.5% 降到 s30 的 85.3%，到完整資料又回到 89.7%。\n- **資料少時，向量反而常常較好**。在 s5，Chronos 的 grep 落在 83.2% 到 89.7%，向量則是 87.9% 到 94.0%。\n- **誰比較好，取決於 harness**。Claude Code 搭配 Opus 和 Haiku，在每個設定都是 grep 較好；Gemini CLI 搭配 Gemini 3.1 Pro，則每個設定都是向量較好，完整資料時差距拉到 89.7% 對 78.5%；Chronos 則在不同設定間互有領先。\n\n作者也提醒，每換一個 session 上限，干擾 session 就會重新抽樣。所以「30 個比 20 個簡單」這種中段起伏，可能只是那次抽到的干擾剛好比較容易處理。解讀這些曲線時，要把各次隨機抽樣的影響一起考慮進去。\n\n### 兩個實驗的數字對不起來\n\n讀這篇論文時，有一件事需要特別留意。\n\n實驗一和實驗二的「完整資料」設定，看起來是同樣的 116 題、同樣的干擾資料、同樣的 inline 傳遞，但數字差很多：\n\n| 模型與 harness | 檢索 | 實驗一（Table 1） | 實驗二 full（Table 2、3） |\n| --- | --- | ---: | ---: |\n| Opus＋Claude Code | grep | 76.7 | 94.0 |\n| Haiku＋Claude Code | grep | 55.2 | 81.9 |\n| Opus＋Chronos | 向量 | 83.6 | 92.2 |\n| Gemini 3.1 Pro＋Gemini CLI | grep／向量 | 81.9／75.0 | 78.5／89.7 |\n\n最後一列連勝負都反過來了：實驗一是 grep 領先，實驗二變成向量領先。論文沒有解釋兩個實驗的設定差在哪裡。實驗二也還缺 Codex 的資料列，作者自己標示為尚待補齊。\n\n所以結論說「grep 一致地比向量準確」，嚴格來說只對實驗一的 inline 設定成立。\n\n### 作者自己劃的界線\n\n作者在限制一節寫得很清楚：這些結論綁定在長期對話記憶的問答上。這類題目的證據常常就是原文裡的某一句話，對字面比對特別有利。換成科學文獻的改寫摘要、圖片很多的文件，或程式碼語意這類證據很少原樣出現的領域，結果可能不同。\n\n作者明說，他們**不主張 grep 普遍勝過向量檢索**，只說在他們研究的任務與語料上，grep 可以在端到端的比較中勝出。\n\n## 結論\n\n這篇論文的標題問「grep 夠不夠」，答案是：**在這個任務、這幾種設定下，常常夠，但要看是誰在用、怎麼用。**\n\n1. **Inline 時，grep 在十組裡全勝**。長對話記憶的證據多半是可以原樣找到的字串，正好是 grep 擅長的。\n2. **Harness 的影響和檢索方法一樣大**。同一個 Claude Opus 4.6，在自製 harness 和 Claude Code 之間差了 16.4 個百分點。\n3. **改成檔案式傳遞，勝負會重洗**。Codex 搭配 GPT-5.4 的 grep 從 93.1% 掉到 55.2%；十組裡有五組變成向量領先。\n4. **干擾增加時，沒有固定的贏家**。兩種檢索的優劣隨 harness、模型與抽樣起伏。\n\n這些結果來自 116 題、單次執行、未具名的向量模型，兩個實驗之間還有對不上的數字，適合當成「值得自己驗證的方向」，不適合當成定論。\n\n作者在結論寫了一句很實用的話：檢索機制、harness 的編排、結果的傳遞路徑，應該當成一個系統一起評估。\n\n換句話說，要比較 grep 和向量，最好在你自己的 agent 裡比。\n","imageSizes":{"/content/papers/assets/7388f9c6a8dfcf342dfed65f8f8c3d27d2ffbbf3d5dfb51aeb45005be29a2c00.png":{"width":944,"height":422}}}