grep vs. RAG：為AI智慧體選擇正確的搜尋策略
本文對比了grep（詞法搜尋）與RAG（語義搜尋）在AI智慧體中的應用場景。grep在小規模純文本語料庫中快速精準，但無法處理PDF等非結構化文件，且擴充套件性差。RAG透過解析、分塊、嵌入和向量索引實現規模化語義搜尋，支援自然語言查詢，但需要額外基礎設施。作者建議採用分層方法：先用工具解析非結構化文件，再用語義搜尋處理大規模語料，同時在適用場景保留grep。
文章情報
要點
- grep適用於小型純文本語料庫的精確匹配，但無法處理非結構化文件。
- 語義搜尋（RAG）透過嵌入和近似最近鄰索引實現規模化、詞彙無關的檢索。
- 生產環境中常採用混合搜尋（語義+詞法+後設資料過濾）以兼顧精度與召回。
- 實用方案是分層使用：解析非結構化文件為文本，再根據場景選擇搜尋策略。
為什麼重要
這條新聞值得關注，因為grep適用於小型純文本語料庫的精確匹配，但無法處理非結構化文件。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
在最近的一篇論文中，Sen等人提出，在搜尋被智慧體工具鏈深刻重塑的世界裡，grep可能是最佳介面。檔案系統工具將很快取代語義搜尋乃至整個RAG的想法已流傳一段時間，但爭論主要圍繞基於文本的文件（如Markdown檔案、原始碼），很少考慮智慧體在企業環境中日常遇到的情況：非結構化文件（PDF、Office檔案、圖片）。
本文探討grep（更廣義地說是詞法搜尋）何時比RAG更快更準確，以及何時並非如此。
grep 及其附屬工具
詞法搜尋基於兩個假設：首先，存在一個文本語料庫，通常以純文本檔案形式儲存在檔案系統中；其次，語料庫規模較小（數百到數千個文件），這樣智慧體能夠挑選要搜尋的檔案而不被低訊雜比淹沒。在大多數設定中，grep作為bash工具暴露給智慧體，前提是智慧體能訪問shell。
grep擅長精確子串和正規表示式匹配。它沒有查詢的語義表示，這沒問題，因為智慧體會透過在不同呼叫中發出不同搜尋模式來操作語義。這使得它非常適合檢索高度具體的資訊：已知的令牌、函式名、錯誤字串。上下文至關重要，智慧體很少單獨使用grep：它搜尋一段內容，然後透過讀取周圍檔案來擴充套件上下文。
grep已有50多年曆史，其使用示例隨處可見，這使LLM能夠有效應用它並在模式和最佳化上泛化。
然而，詞法搜尋有兩大限制：第一，無法grep PDF、帶文字的圖片或Office文件。詞法搜尋能解鎖的語料庫僅限於純文本。儘管Markdown和其他文本格式日益普及，但大多數企業知識仍鎖在非結構化檔案中。第二，擴充套件性在語料庫達到一定規模時崩潰。原始的grep掃描100萬個檔案中的一個小模式需要4秒以上。即使使用亞秒級的ripgrep，隨機且無關聯的匹配產生的噪聲會迅速填滿智慧體的上下文視窗，將相關資訊擠走。
針對這兩個限制，已有企業級方法能提升智慧體搜尋的可擴充套件性，同時保持準確性和延遲。
解鎖非結構化文件
目前大多數CLI智慧體工具鏈配備了基本的PDF讀取工具以及多模態“看”圖能力。然而，編碼智慧體中的PDF讀取通常不準確且有損耗：不感知佈局的提取器會將表格混在一起，忽略圖片，並割裂列。視覺推理在推理時更昂貴，且由於模型主要基於文本訓練，基於視覺的讀取更慢且更容易出錯和產生幻覺。
需要一個平衡準確性和延遲的工具層來解鎖非結構化文件，並將其文本內容暴露給下游工具（如grep）。LlamaIndex為此提供了一組智慧體原生工具：
- LlamaParse MCP：一個即插即用的MCP伺服器，允許智慧體呼叫LlamaParse平臺進行檔案解析、分割和分類，支援130多種格式，在表格、圖表、圖片、複雜佈局和手寫文字上具有高準確性，由智慧體OCR驅動。
- LiteParse：一個快速、完全本地的工具，用於解析非結構化檔案。它按空間位置提取文本，保留佈局，並使用OCR（Tesseract或自定義即插即用HTTP伺服器）忠實呈現內容。響應時間通常為幾秒。LiteParse適合快速本地工作負載，智慧體需要快速瞭解文件概況，它是grep的最佳伴侶——可以輸出到stdout或可被搜尋的檔案。
LiteParse和LlamaParse都有智慧體技能，可透過Vercel skills CLI安裝或直接從GitHub拉取。這些技能為智慧體提供了使用LiteParse、LlamaParse SDK和MCP所需的上下文。
一旦解鎖了非結構化文件，就可以將這些知識與合適的智慧體搜尋（詞法或語義）相結合，這是下一節的主題。
構建規模化：語義搜尋與RAG
詞法搜尋在企業規模面前早已失效。當語料庫從數千文件增長到數百萬文件（內部維基、合同、工單、研究報告、設計規範）時，grep式搜尋在三個維度同時退化：延遲（線性掃描百萬檔案對互動式智慧體迴圈太慢）、召回（詞法搜尋只找到字面匹配項，“收入確認”會錯過“ASC 606”）、訊雜比（百萬文件中即使特定令牌也會返回數千次匹配，相關結果被埋沒）。
語義搜尋（以及其上的RAG模式）避開了這三個問題。文件透過佈局感知工具（如非結構化格式的LlamaParse）一次性解析，分塊，嵌入向量空間，並建立索引。查詢時，智慧體的自然語言問題也被嵌入，近似最近鄰索引在數十毫秒內返回top-k語義相關塊，無論語料庫有十萬還是千萬文件。
這才是可擴充套件性的真正所在：子線性檢索（ANN索引使查詢時間大致恆定）、詞彙無關的召回（嵌入捕捉含義，減少重試次數）、有限的上下文成本（top-k返回小規模排序塊，而非無限制的grep命中列表）。生產級RAG系統通常將語義搜尋與詞法（BM25）和後設資料過濾結合，兼顧精確匹配的精度和嵌入的召回。
語義搜尋需要索引管道、嵌入模型和向量儲存，並且在你知道確切字串時不如grep精確。但當語料庫規模大、異構或充滿非結構化文件時，這些成本在第一次查詢時就已值得。
結論：grep就是一切嗎？
grep不會消失，也不應消失。對於小型純文本語料庫（程式碼庫、文件資料夾、少量Markdown筆記），詞法搜尋快速、可預測，為智慧體提供所需的精確性。
但“grep就是一切嗎？”對於大多數企業智慧體實際生存的世界是個錯誤的問題：語料庫有數百萬文件，其中大部分是非結構化的（PDF、幻燈片、電子表格、掃描件），查詢是自然語言而非已知令牌。在那裡，僅靠詞法搜尋在每個關鍵維度都碰壁：它無法讀取格式，無法擴充套件，也無法彌合詞彙鴻溝。
務實的答案是分層方法。用佈局感知工具（如LlamaParse或LiteParse）將非結構化文件解析成忠實文本。將該文本索引用於語義搜尋，使智慧體能夠按含義規模化檢索。同時保留grep工具箱，用於已知語料庫上的精確匹配搜尋，讓智慧體在兩者之間選擇。
grep是個好工具。但它不是智慧體需要的唯一工具。