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