从传统RAG到Agentic RAG:原理对比与企业级落地实战

从传统RAG到Agentic RAG的演进原理与企业级实现解析
文章系统阐述了传统RAG(检索增强生成)的局限性——单向固定流程无法应对检索失败和信息不完整的场景,并详细介绍了Agentic RAG如何通过将检索能力工具化、赋予大模型自主决策和多轮迭代能力来解决这些问题。结合开源项目ChatBox的源码,展示了基于LangGraph框架的企业级Agentic RAG实现路径,指出真正的技术难点在于工具设计、提示词工程和离线链路优化。
引言:传统RAG的困境
你是否遇到过这样的场景:花了大量时间搭建RAG系统,结果模型回答答非所问,检索到一堆看似相关却毫无用处的内容?用户问"知识库里有哪些文档",系统直接宕机——因为它只会查,不会想。检索不到答案时就直接摆烂,而不是尝试换一种问法、翻一翻上下文再重试一遍。
RAG(Retrieval-Augmented Generation,检索增强生成)由Meta AI在2020年提出,其核心思想是将大语言模型的生成能力与外部知识库的检索能力相结合,解决LLM知识截止日期、幻觉(Hallucination)和私有数据访问等固有缺陷。传统RAG本质上是一种「外挂记忆」机制——LLM的参数权重存储的是通用世界知识,而RAG通过检索将特定领域或实时知识动态注入上下文窗口,使模型无需微调即可回答专业问题。然而随着应用场景日趋复杂,传统RAG的局限性已经越来越明显。
本文将从传统RAG的基本原理出发,逐步揭示它如何进化为Agentic RAG,并结合开源项目ChatBox的源码,带你理解企业级Agentic RAG的完整实现路径。
传统RAG的实现原理
离线链路:文档切片→向量化→存储
传统RAG的第一条链路是离线处理,与用户无关。核心流程如下:
- 文档加载:将PDF、Word、TXT等文档读入内存
- 文档切片:由于文档内容可能有上万字,无法一次性全部交给大模型,因此需要将文档切分为固定长度的段落(如256字符),段落之间保留一定重叠以保证语义连贯
- 向量化:使用Embedding模型(如千问Embedding 0.6B)将每个段落转换为固定维度的向量。Embedding模型将文本映射为高维向量空间中的点,语义相近的文本在向量空间中距离更近,这是后续相似度检索的数学基础
- 存储:将向量存入向量数据库(如ChromaDB)。ChromaDB是一款开源的向量数据库,支持余弦相似度、欧氏距离等多种相似度计算方式,并提供持久化存储和元数据过滤功能,是RAG场景下轻量级部署的主流选择
代码实现上,通过LangChain的递归分割器设置chunk_size和chunk_overlap两个参数即可完成切片,再调用Embedding模型向量化后存入ChromaDB。整个过程只需提供三个参数:切分后的文本片段、Embedding模型、存储路径。

在线链路:检索→拼接→生成
在线链路是用户交互的核心环节:
- Query改写:用户的原始问题可能不适合直接检索,需要先进行改写优化
- 双路检索:同时使用BM25关键词检索和向量相似度检索,分别获取相关片段。BM25是基于词频统计的经典关键词检索算法,与向量检索形成互补——向量检索擅长捕捉语义相似性(如"汽车"与"轿车"),BM25擅长精确关键词匹配(如产品型号、专有名词),两者结合的混合检索(Hybrid Search)能显著提升召回率,弥补单一检索方式的盲区
- 合并重排序:将两路检索结果合并后进行重排序(Reranking),筛选出最相关的Top-K片段
- Prompt拼接与生成:将筛选后的片段注入Prompt模板的Context部分,交给大模型生成最终答案
传统RAG的Prompt模板通常很简单:"你是一个专业助手,请根据以下问题和检索文档进行回答",加上Context和Question即可。
核心问题在于:整个过程是单向、固定且一次性的。如果第一轮检索未能命中有效信息,模型无法重新检索、换一种方式搜索,或者主动补充上下文。这正是Agentic RAG要解决的根本痛点。
Agentic RAG:从流水线到智能闭环
核心思想:把检索能力工具化
Agentic RAG是对传统RAG的根本性升级。它将RAG中的各个环节——Query改写、向量检索、关键词搜索、文件读取等——全部封装为可调用的工具(Tools),允许大模型在生成答案之前进行自主决策、多轮调用和动态调整。
换句话说,Agentic RAG不再是一条直线走到底,而是一个智能体驱动的闭环:思考→调用工具→观察结果→再思考→再行动,直到生成最终答案。这一决策范式源自Google Research在2022年提出的ReAct(Reasoning + Acting)框架——它将LLM的推理过程(Thought)与外部工具调用(Action)交织在一起,形成迭代循环。与传统RAG的关键区别在于,模型不再是被动的「内容生成器」,而是主动的「问题求解者」,能够根据中间结果动态调整后续行动策略。

模型需要具备三类核心能力:
- 规划能力(Planning):体现在思维链(Chain of Thought)推理过程中,规划如何分步解决问题
- 工具调用能力:能够根据需要调用不同的检索和读取工具。这依赖于模型厂商在API层面提供的Function Calling标准化接口,OpenAI、Anthropic、阿里云等主流厂商均已支持该能力
- 多步迭代能力:在最终回答之前可以进行多轮工具调用,逐步完善信息
与传统RAG的关键区别
| 维度 | 传统RAG | Agentic RAG |
|---|---|---|
| 流程 | 固定单向 | 动态循环 |
| 检索次数 | 一次 | 多次迭代 |
| 决策主体 | 预设规则 | 模型自主判断 |
| 失败处理 | 直接返回"未找到" | 改写Query重试 |
| 模型介入时机 | 仅生成阶段 | 从输入开始全程参与 |
传统RAG中,大模型只在最后的生成阶段才被使用。而Agentic RAG从用户输入问题的那一刻起,就让大模型参与决策——判断是否需要检索、选择调用哪个工具、评估结果是否充分。
企业级实现:ChatBox源码拆解
四大核心工具设计
开源项目ChatBox的Agentic RAG实现提供了很好的参考。它设计了四个核心工具:

-
Search Query(语义检索):最基础的向量相似度检索工具,从知识库中搜索与Query最相关的文档片段
-
List Files(文件列表):列出知识库中的文件清单。这是一个重要的兜底工具——传统RAG无法回答"知识库里有哪些文档"这类问题,因为它只能检索部分内容。有了这个工具,模型可以获取文件数量和列表信息
-
Read File Chunk(精确读取):根据文档ID精确读取特定文本片段。它有两大优势:一是可以精确定位特定片段,二是当信息不完整时,模型可以主动读取前后相邻的Chunk来补充上下文,不再依赖语义相似度检索。这一设计弥补了向量检索的一个固有缺陷——向量相似度高不等于信息完整,相邻Chunk往往包含关键的承接内容
-
Get File Metadata(元数据读取):读取文件的元数据信息,使用频率较低但在特定场景下有价值
智能决策流程
ChatBox的实现采用了"用时间换智能"的策略:
- 判断模型能力:首先检测模型是否支持工具调用(Function Calling)
- 不支持工具调用时:通过Prompt判断问题是否需要检索。不需要则直接回复;需要则进行语义搜索后生成答案。这比在Prompt中让模型忽略无关Context更优,因为用了两次模型决策
- 支持工具调用时:将所有工具注册到模型中,由模型自主决策调用哪些工具,形成完整的Agent循环
代码实现要点
ChatBox基于LangGraph的create_react_agent实现Agentic RAG。LangGraph是LangChain生态中专为构建有状态、多步骤Agent工作流设计的框架,其create_react_agent函数封装了完整的ReAct循环逻辑——包括工具调用的路由判断、结果回传和终止条件检测——开发者只需定义工具和提示词即可获得具备多轮推理能力的Agent。核心代码出奇简洁:
# 1. 定义工具列表
tools = [search_query, list_files, read_file_chunk, get_file_metadata]
# 2. 编写系统提示词,引导模型使用工具
system_prompt = "你是一个Agentic RAG助手,第一步...第二步...第三步..."
# 3. 创建React Agent
agent = create_react_agent(
model=llm, # 大语言模型
tools=tools, # 工具列表
system_prompt=prompt # 系统提示词
)
# 4. 运行Agent
result = agent.invoke({"messages": [user_query]})
需要特别注意的是,系统提示词中必须对模型的回复格式进行严格限制,否则模型可能会去掉引号或括号等符号,导致工具调用失败。
实际效果对比
以一个具体案例说明传统RAG与Agentic RAG的差异:
传统RAG:用户查询→向量检索→检索到结果→直接生成答案。如果检索结果不相关,模型只能回答"不知道"。
Agentic RAG:
- 第一轮搜索:使用Search Query检索,发现命中率很低
- 观察与反思:模型判断需要改写查询词
- 第二轮搜索:使用改写后的Query重新检索,命中相关Chunk
- 第三轮补充:通过Read File Chunk读取相邻片段,补充上下文
- 最终生成:基于充分的信息生成完整、准确的回答
总结与思考
Agentic RAG的核心价值可以用一句话概括:工具赋予能力,智能在于选择。真正的Agentic RAG始于检索,成于决策。
从技术实现角度看,Agentic RAG的核心逻辑并不复杂——借助LangGraph等框架,几十行代码就能搭建基本框架。真正的难点在于:
- 工具设计:如何设计合理的工具集,覆盖检索失败、信息不完整等边界场景
- 提示词工程:如何引导模型正确使用工具,避免格式错误导致调用失败
- 离线链路优化:文档切分策略、Embedding模型选择、Query改写策略等,这些决定了Context的质量上限
对于大模型应用开发者而言,理解从传统RAG到Agentic RAG的演进,不仅是技术栈的升级,更是思维模式的转变——从"预设流程"到"赋予模型自主决策权"。
核心要点
- 传统RAG是单向固定流程(检索→拼接→生成),无法应对检索失败或信息不完整的场景
- Agentic RAG将检索、文件读取等能力封装为工具,赋予大模型自主决策、多轮迭代的能力,形成思考-行动-观察的智能闭环
- ChatBox通过设计Search Query、List Files、Read File Chunk、Get File Metadata四大核心工具实现企业级Agentic RAG
- Agentic RAG的核心实现基于LangGraph的create_react_agent,代码逻辑简洁但能释放模型的自主决策能力
- 真正的技术难点不在框架搭建,而在工具设计、提示词工程和离线链路的Context质量优化
相关推荐
教程攻略Cursor+Codex双IDE协同:开源项目二开实战方法论
基于实战经验总结的开源项目二次开发完整方法论,详解Cursor+Codex双IDE协同工作流,涵盖二开七环节、MVP验证、AI读源码技巧,帮助开发者三天跑通项目、两周完成业务集成。
教程攻略Cursor多Agent实战:50分钟搭建Next.js全栈博客
使用Cursor IDE多Agent协作模式,50分钟内从零搭建全栈博客。涵盖Next.js、Clerk认证、Supabase数据库集成,详解4个AI Agent分阶段开发流程与关键避坑经验。
教程攻略从零搭建AI软件工厂:Cursor工程师的多Agent协作实战经验
Cursor工程师Eric分享AI软件工厂构建实战:从自动化六层级、护栏设计、并行Agent管理到规模化扩展,详解如何用多Agent协作实现7×24小时高效软件开发。