Grep 就够了？企业 RAG 正在从“检索文档”转向“编译知识”

过去两年，企业做知识库的默认路径几乎是同一条：把文档切块、向量化、存进向量数据库，用户提问时召回最相似的几个片段，塞进上下文让模型回答。架构图很漂亮，Demo 也能跑，但真正上生产之后，问题一个接一个冒出来。

分块策略怎么定？Embedding 模型选哪个？相似度阈值设多少？每个环节都要调参，调完还是不能保证召回的相关性。更糟的是，召回的错误片段会干扰模型推理，本来只差一点，最后答得更偏。

一分钟速览

• 朴素 RAG 的“查询—嵌入—相似度排序”是单一通路，无法覆盖精确查询、概念查询、多跳查询等不同类型。
• GraphRAG、RAPTOR、Contextual Retrieval 等高级方案增加了复杂度，但在部分场景的提升并不匹配维护成本。
• PwC 的研究让 Agent 同时使用向量搜索和 Grep，结果 Grep 常常提供更高准确率。
• 微软的 Agentic RAG 架构用 SEARCH、FIND、OPEN 三类工具迭代检索，在 BRIGHT、WixQA、FinanceBench 上均有提升。
• Harness + Grep 的瓶颈是探索成本：数据规模一大，迭代次数线性增长，Token 消耗快速上升。

为什么“精确匹配”突然好用了

Grep 这类工具过去被认为太原始，只适合查代码。但当使用者从人变成 Agent，情况变了。人用 Grep 要自己想关键词，一次只能试一个；Agent 可以一次构造出带多个约束的复杂查询，快速试错，再根据结果调整。OpenAI 对 GPT-5 在 BrowseComp-Plus 数据集上的搜索行为分析也显示，AI 使用精确匹配时比人类更“精确”、更“结构化”。

更重要的是，企业知识里有大量查询属于“证据定位”：某个合同编号、某个函数名、某个错误字符串、某个日期对应的营收数字。这类问题用向量搜索只会引入语义相近但无关的噪音，用精确匹配反而一步到位。

但这不是说向量检索没用了。更准确的结论是：一个设计良好的 Agent Harness，即使只配备 Grep 这类简单工具，也能在很多场景达到接近甚至超越复杂 RAG 的效果。关键不在工具本身，而在 Agent 如何编排它——先召回、再定位、再精读。

Harness 的天花板：每次都要重新发现

问题出在规模。当数据量扩大，完全依赖 Harness 的迭代探索和 Grep 的精确匹配，会让 Agent 反复搜索才能找到答案区域。每一次 Grep 都是一次 IO，迭代次数线性增长，响应时间跟着涨；每一次迭代又把搜索结果载入上下文，多轮累积的 Token 成本相当可观。

更隐蔽的浪费是“冷启动”。用户提问，系统向量化问题，检索相似片段，拼进 Prompt，模型回答，然后一切归零。下一次查询，同样的流程再来一遍。系统每次都要重新理解知识库里有什么、文档之间是什么关系、哪些来源更权威。有分析指出，Agent 可能有高达 85% 的计算精力消耗在“重新发现”的循环上，而不是真正的任务完成。

这不是某个产品的 bug，而是范式缺陷：所有“理解”都发生在查询时，索引里只存了向量，没有存理解。

知识编译：把理解挪到索引时

Andrej Karpathy 提出的“LLM Wiki”给出了另一种思路：把原始笔记当作源材料，用 LLM 编译成一份持续更新、带明确引用、可逐字阅读的 Wiki。不是每次提问时临时拼几个相似片段，而是“知识被编译一次，然后保持更新，而不是在每个查询上重新推导”。

这个思路正在从个人知识管理溢出到企业 RAG。核心变化是：检索系统不再只提供“相似的文本块”，而是提供“已经组织好的知识工件”——带结构、带出处、带更新时间的条目。Agent 拿到这些工件，迭代次数更少，Token 消耗更低，也更容易解释答案从哪来。

微软的 Agentic RAG 实践提供了一个中间形态：为 Agent 配备 SEARCH（广域召回）、FIND（精确定位）、OPEN（深度阅读）三类工具。先用 SEARCH 缩小范围，再用 FIND 精准定位，最后用 OPEN 获取完整上下文。报告显示，在 BRIGHT、WixQA、FinanceBench 上都有显著提升，消融研究表明最大提升来自“从单次检索转向 Agentic 工具使用”。

有意思的是，BM25 加 Grep 的组合就能让 Harness 表现更好。BM25 在单次检索中表现一般，但在 Agent Loop 内部却强得多。这意味着企业不一定需要复杂的 Embedding 模型和向量数据库，仅靠词汇层面的检索工具组合，就能为 Agent 提供足够强的检索能力。

企业该怎么选

短期最划算的做法，不是再换一个向量数据库，而是先把 Agent 的检索编排做对：给它多种工具，让它自己决定什么时候召回、什么时候精读；把权限、引用和日志做扎实，保证答案可追溯。

中期要开始积累“编译层”。把高频使用的制度、流程、产品文档，整理成结构化条目，标明来源、版本和适用范围；让更新走增量编译，而不是每次重建索引。这部分工作枯燥，但它决定的不是“能不能答”，而是“答得稳不稳、贵不贵”。

长期看，RAG 的竞争点会从“召回算法”转向“知识工程”：谁能把企业里散落的文档、对话、表格，持续编译成 Agent 能直接使用的知识，谁就能把 Token 成本和响应时间压下来。Grep 很重要，但它只是起点。