从一个简单的问答机器人说起
去年我用 LangChain 搭了一个内部的文档问答系统。做法很简单：把公司 Wiki 的所有页面切块，塞进 Chroma 向量库，用户提问时检索最相关的 3 个片段，拼接成 prompt 发给 GPT-4，然后返回答案。Demo 跑起来效果不错，老板很满意。
但上线第一天就翻车了。同事问：「我们上季度和 XX 客户签的合同金额是多少？」系统自信地回答了一个数字——可惜是错的。问题出在哪？检索到的片段里恰好出现了那个数字，但它属于另一份合同。
这就是朴素 RAG 的经典问题：检索到了相关片段 ≠ 检索到了正确片段。从那之后我开始系统地研究 RAG 的进化路径，发现这个领域的变化比我想象的要快得多。
朴素 RAG：能用，但不靠谱
朴素 RAG（Naive RAG）的核心流程可以归纳为三步：索引、检索、生成。
索引阶段，文档被切成固定大小的 chunk（比如 512 token），每个 chunk 转成向量存入数据库。检索阶段，用户的 query 也被转成向量，用余弦相似度找到 top-k 个最近的 chunk。生成阶段，把这些 chunk 和问题一起拼进 prompt，让 LLM 回答。
这个方案有三个明显的短板。第一，切分方式太粗暴——固定大小的 chunk 很可能把一段完整的意思拦腰截断，导致检索到的片段缺少上下文。第二，检索精度不高——纯向量相似度匹配在很多场景下效果一般，尤其是涉及数字、日期、专有名词的查询。第三，单轮检索没有纠错机制——检索错了就错了，LLM 拿到错误上下文后照样自信作答，看着像模像样但全是瞎编。
用一句话总结朴素 RAG：它在 Demo 里是王者，在生产环境里随时掉链子。
进阶 RAG：先把检索做好
社区很快意识到，RAG 的瓶颈首先在检索，其次才是生成。于是出现了大量优化检索的策略，我把它们归为三类。
1. 查询改写
用户问「上季度签了多少合同」时，向量检索可能找不到包含「上季度」这个短语的文档。但如果先用 LLM 把问题改写成「2026年Q1签订的合同总金额」，命中率立刻飙升。这就是查询改写（Query Rewriting）的核心思路——在检索前用 LLM 对用户问题进行扩写、细化、消歧。
更进阶的做法是多查询生成（Multi-Query）：把一个模糊问题拆成 3-5 个不同角度的问题，分别检索后再合并结果。比如用户问「我们的客户满意度怎么样」，可以拆成「客户满意度评分」「客户投诉数量」「客户留存率」三个维度去查。
2. 混合检索与重排序
向量检索擅长语义匹配，但遇到精确关键词（比如产品型号「XJ-9000」）就抓瞎了。解决方案是混合检索（Hybrid Search）：同时跑向量检索和 BM25 关键词检索，把两路结果合并。
合并之后还有关键一步：重排序（Reranking）。用专门的 cross-encoder 模型（如 bge-reranker、Cohere Rerank）对候选片段重新打分排序。这种做法比单纯依赖向量相似度靠谱得多——我去年的项目上线 reranker 后，准确率直接从 72% 跳到了 89%，效果立竿见影。
3. 更好的切分策略
固定大小切分是最偷懒的做法。更好的方式是「语义切分」：按段落、按 Markdown 标题层级、甚至用模型判断语义边界来切。还有一个技巧叫「小 chunk 检索 + 大 chunk 上下文」——检索时用小粒度 chunk 提高精度，但返回给 LLM 时带上前后相邻段落，保证上下文完整。
Agentic RAG：让 AI 自己决定怎么查
前面这些优化本质上还是在「单次检索 → 单次生成」的框架里打转。但真实场景中的问题往往不是一句话能说清的。
举个例子：用户问「我们上个季度销量最好的三个产品是什么？各自的库存还够不够？」这其实是一个多步推理问题。需要先查销量排行（可能得去 BI 数据库），拿到产品列表后再逐个查库存（可能要去 ERP 系统），最后汇总回答。传统 RAG 根本处理不了这种链路。
Agentic RAG 的突破在于：它不再把 RAG 当成一个固定的 pipeline，而是交给一个 AI Agent 去动态规划和执行。
Agentic RAG 是怎么工作的
Agentic RAG 的核心组件是一个能够使用工具的 LLM Agent。它拿到用户问题后，会自己判断：
第一步，这个问题我能不能直接回答？如果不行，我需要查什么？
第二步，调用检索工具（可以是向量库、SQL 数据库、API 接口、网页搜索），拿到结果。
第三步，检查检索结果够不够。不够的话，换个角度再查。够了就基于信息生成回答。
第四步，如果用户在追问，结合对话历史判断是否需要补充检索。
这个过程的关键区别在于：检索不再是一次性的，而是迭代式的。Agent 可以根据前一次检索的结果决定下一步做什么，就像一个人在做研究时不断翻书、查资料、调整思路。
几个典型的 Agentic RAG 模式
目前业界实践中最常见的 Agentic RAG 模式有这几种：
Router（路由）：根据问题类型自动选择检索源。问代码相关的去查 Git 仓库，问业务指标的去查数据库，问公司政策的去查 Wiki。这个模式最简单也最实用，LangChain 和 LlamaIndex 都有现成的实现。
Self-RAG（自反思检索）：Agent 在生成每段回答前先自我评估「我需要检索吗？」，生成后再评估「这个回答有没有事实支撑？」。如果发现某个陈述没有检索依据，就回溯重查。Self-RAG 的思路很漂亮，但实际落地时多轮反思会显著增加延迟和成本。
ReAct（推理-行动循环）：这个模式把推理（Thought）、行动（Action）、观察（Observation）串成一个循环。Agent 先用自然语言写一段推理，然后执行一个工具调用，观察结果，再推理下一步。ReAct 是目前 Agentic RAG 最主流的实现范式，也是 LangGraph 等框架的默认模式。
Adaptive RAG（自适应检索）：动态判断问题的复杂度，简单问题直接回答不检索，中等复杂度单轮检索，复杂问题启动多步检索链路。这个模式最贴近真实使用场景——没人喜欢问个天气也要等 5 秒检索。
我的实践经验
过去一年在生产环境打磨 RAG 系统，我学到了几条硬道理：
第一，检索质量决定 RAG 的上限。花再多的精力调 prompt、换模型，都不如把检索做好。上 reranker、做查询改写、用混合检索，这些投入的 ROI 远高于在生成侧做文章。
第二，Agentic 不是银弹。对于那些用户需求明确、问题类型固定的场景（比如客服 FAQ、合同条款查取），一个调教好的进阶 RAG 就完全够用。强行上 Agent 只会增加延迟和不确定性。Agentic RAG 最适合的场景是多步推理、跨数据源查询、需要动态决策的复杂问题。
第三，评估体系要跟上。RAG 系统上线后不能只看用户反馈。必须建立自动化的评估 pipeline：检索召回率、答案忠实度、答案相关性，三个维度缺一不可。我推荐用 RAGAS 框架，几分钟就能搭出一套评估脚本。
未来的方向
Agentic RAG 还远没有成熟。接下来值得关注的几个方向：
一个是Memory 机制的深化——让 Agent 记住用户的偏好、历史问题和知识背景，实现真正的个性化检索。另一个是多模态 RAG——不只能检索文本，还能查图片、表格、音视频，然后用多模态模型综合理解。还有就是成本优化——Agentic RAG 的 Token 消耗是传统 RAG 的 3-10 倍，如何用更小的模型、更聪明的缓存策略降低成本，是所有工程团队要面对的现实问题。
RAG 这条技术路线，从最初那个粗糙但惊艳的 Demo，到现在越来越成熟的 Agentic 范式，只走了不到三年。如果你正在考虑给自己的产品加上「AI 对话」功能，我的建议是：先从朴素 RAG 跑通最小闭环，然后逐步上 reranker、加查询改写、引入 Router 路由，到最后需要处理复杂查询时再引入 Agentic 模式。一步一步来，每一层优化都能看到实实在在的效果提升。
