RAG+rigrep，企业知识层检索的最佳范式
最近我在重构去年初做的一套智能问答系统。
去年那版系统很典型：文档入库、向量化、召回、拼上下文、让大模型回答。能跑，也能演示，但真放到企业知识层里，还是会有不少问题：用户问法和文档写法对不上，制度版本混在一起，召回结果不稳定。
重构过程中，我读到一篇很贴近这个问题的论文：Is Grep All You Need? How Agent Harnesses Reshape Agentic Search。
它讨论的不是传统搜索引擎，而是 Claude Code、Codex CLI、Gemini CLI 这类 Agent，在多轮对话记忆问答里，怎么调用工具去找证据。
这篇文章想要分享的主题是：为什么 Agent 喜欢用rg；为什么rg不能替代 RAG；以及企业知识层该怎样组合词面检索、语义检索和工具调用。
01 这篇论文到底在研究什么
这篇论文的场景很具体：长对话记忆问答。
它不是在问“巴黎是哪个国家的首都”这种常识题，而是让模型从一大段历史对话里找答案。真正的证据可能只是一句话，周围却夹着大量无关内容。
这和传统 RAG 的差异很大。传统 RAG 更像固定流水线：问题来了，拿回前几条结果，拼进上下文，然后回答。Agentic Search 更像一个会自己查资料的研究助理：先搜一轮，读结果，不够再换关键词继续搜。
所以这篇论文的重点不是一句“grep 比向量检索强”，而是：
检索效果不只取决于检索算法，还取决于 Agent 所在的运行框架、工具调用方式，以及检索结果呈现给模型的方式。
02 grep / rg 为什么在 Agent 里很强
先澄清一个概念。Codex、Claude Code 里常用的是ripgrep，命令叫rg。它可以理解成更适合现代代码库的 grep：递归搜索快，默认尊重.gitignore，输出也更适合开发者阅读。
在代码库和日志场景里，rg的优势非常明显。很多工程问题都有明确线索：错误码、字段名、函数名、配置名、接口路径。这些东西不需要语义理解，直接搜就行。
比如 demo 里可以跑：
python -B scripts\rg_examples.py它会同时找到业务代码和测试文件。这个过程和 Codex、Claude 读代码库很像：先定位，再阅读，再修改。
论文里把这类方法叫 lexical search，也就是词面检索。它简单、稳定、成本低、命中明确，但硬伤也很明显：你必须猜中词。
用户问：
员工离职后系统权限什么时候回收？
文档里可能写的是：
离职员工账号应在最后工作日 18:00 前关闭。涉及生产系统权限的，IT 应先冻结高风险权限。
直接用rg搜完整问题，很可能没有结果。因为“权限回收”和“账号关闭”“冻结高风险权限”不是同一串字。
这就是向量检索和 RAG 的价值：不是只找同一个词，而是找到含义相关的证据。
03 RAG 解决的是另一个问题
企业知识问答不是代码定位。
代码定位问的是：
这个字段在哪里出现过？
企业知识问答问的是：
这个业务场景应该怎么处理？
前者靠rg很便捷，后者只靠rg很危险。企业知识表达不统一，来源复杂，还涉及权限、版本和引用追溯。同一件事可能叫续费、续约、续签、合同延展，用户不会按文档原词提问。
所以 RAG 的关键不是“向量库很高级”，而是建立一条可信问答链：
语义召回 → 关键词补召回 → 权限过滤 → 重排 → 证据拼装 → 生成答案 → 返回引用为了让读者能跑起来，我在 demo 里做了一个最小版mini_rag.py：
python -B scripts\mini_rag.py --query "员工离职后系统权限什么时候回收？"它不是生产级 RAG，只是用规则模拟“切分、召回、证据、来源”这条链路。
rg回答“有没有这串字”，RAG 回答“这个问题应该引用哪些证据”。
04 工具结果怎么给模型，也会影响答案
这篇论文还有一个很实用的点：它不只比较 grep 和向量检索，还比较检索结果怎么呈现给模型。
一种是Inline：搜索结果直接塞进上下文。好处是简单直接，模型马上能读。坏处是结果一多，就会和系统提示、历史对话、之前的工具结果抢空间。
另一种是File-based / Programmatic：搜索结果先写入文件，Agent 再决定读哪一部分。好处是可以减少上下文压力，坏处是多了一步工具使用，模型必须知道怎么读文件、读多少。
这点放到企业知识层里非常关键。
很多系统效果不好，不一定是模型不行，也不一定是向量库不行，而是中间链路设计得太粗：召回结果太长，证据没有分组，制度版本缺少元信息，权限过滤放得太晚。
Agent 系统不是“换一个检索器”就能变好。检索器、工具说明、结果格式、上下文预算、权限过滤，都会影响最终答案。
05 rg 在企业知识层里应该放哪里
所以是不是有了 RAG，就不用rg了？恰恰相反。企业知识层里，rg应该成为工程侧的基础工具。
第一，数据盘点。
rg "合同|续签|客户状态|CRM" docs/第二，知识治理。
rg "TODO|草稿|已过期|password|token" docs/第三，RAG 排障。
当用户说“系统答错了，制度里明明有”，第一步不应该怀疑模型，而是用rg查：
rg "离职|账号关闭|权限复核" docs/如果原文存在但 RAG 没召回，问题可能在解析、切分、embedding、元信息、权限过滤或重排。第四，代码和配置定位。字段怎么定义、接口在哪里用、日志从哪里打出来，仍然是rg的主场。
06 我的重构判断
这次重构去年那套智能问答，我最大的变化不是换一个更贵的模型，也不是把所有文档重新 embedding 一遍，而是拆成两条链路。
一条是工程链路：
文档盘点 → 敏感扫描 → 原文定位 → 召回排障 → 版本治理这里rg非常好用。
另一条是问答链路：
问题理解 → 混合召回 → 权限过滤 → 重排 → 证据生成 → 引用追溯这里 RAG 是底座。再往前走一步，Agentic Search 会把两条链路连起来。Agent 不只是被动接收前几条检索结果，而是能判断要不要继续搜、换什么关键词、读哪份文件、是否证据不足。
未来的企业知识层，不是单纯的向量数据库，也不是让大模型自己 grep 全目录，而是一套可控的 Agent 检索系统。
rg/grep不会过时。它们会继续作为可靠的工程放大镜存在。
但企业知识层不能停留在“搜到某个词”。它必须回答更难的问题：用户到底在问什么、哪些证据可信、哪些资料有权限、答案能否追溯。
所以最后还是那句话：
定位靠
rg，回答靠 RAG。
简单问题靠搜索，企业级知识层靠系统工程。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～