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是個好工具。但它不是智能體需要的唯一工具。