一、核心逻辑：为什么需要从 LLM 过渡到 RAG？

LLM 的本质是基于海量预训练数据学习语言规律，其生成能力依赖于训练数据的覆盖范围，但这种 “闭卷考试” 式的模式存在两大核心痛点，也是 RAG 技术诞生的根本动因。

1. LLM 的核心痛点

• 知识时效性缺失：预训练数据有固定截止时间，无法获取实时信息（如最新政策、行业动态、实时业务数据）。例如，企业想通过 LLM 查询 2024 年最新的产品迭代文档，单纯依赖 LLM 无法获取超出训练范围的内容。
• 幻觉问题难以根除：LLM 会基于统计规律生成看似合理但与事实不符的内容，且无法自主识别错误。比如在技术问答场景中，可能会编造不存在的 API 参数或代码逻辑，导致业务出错。
• 私有知识无法融入：企业内部的业务手册、技术文档、客户案例等私有数据，无法通过微调 LLM 高效融入（微调成本高、周期长），导致 LLM 无法贴合具体业务场景。

2. RAG 的核心价值

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路是开卷考试：在生成回答前，先从外部知识库中检索与用户问题相关的真实信息，再将检索结果与问题拼接后输入 LLM，让 LLM 基于真实内容生成回答。其核心价值在于：

• 无需大规模微调，即可快速接入私有知识，降低落地成本；
• 依托实时检索，解决知识时效性问题；
• 基于真实检索内容生成，从根源上减少幻觉，提升回答可信度。

简单来说，RAG 是 LLM 的 “外挂知识库”，让 LLM 从 “凭空想象” 转变为 “有据可依”。

二、LLM 过渡到 RAG

LLM 到 RAG 的过渡，本质是在原有 LLM 生成流程中嵌入 “检索环节”，构建 “检索 - 生成” 的闭环流程。整个过渡过程分为基础架构搭建、核心流程优化、效果迭代升级三个阶段，无需推翻原有 LLM 部署，仅需新增检索模块即可实现。

1. 基础架构搭建：从 0 到 1 构建 RAG 系统

RAG 系统的核心架构分为离线索引构建和在线推理生成两大部分，整体流程如下：

用户问题 → 问题预处理 → 向量检索 → 结果重排 → 拼接输入LLM → 生成回答

（1）离线索引构建：让知识库可检索

离线索引是 RAG 的 “地基”，核心是将非结构化文档（PDF、Markdown、TXT 等）转化为机器可理解的向量数据，存储在向量数据库中。具体步骤如下：

1. 数据加载与清洗
   • 加载各类文档数据：包括企业内部手册、技术博客、API 文档、PDF 报告等，支持批量加载；
   • 数据清洗：去除文档中的无效内容（如广告、重复段落、乱码），提取核心文本，同时保留文档的结构信息（如标题、段落、章节），为后续分块做准备。
2. 文本分块：平衡完整性与粒度分块是 RAG 的关键环节，分块过大易导致检索到无关内容，分块过小则会破坏语义完整性。推荐分块策略：
   • 基础分块：按语义完整性划分，单块长度控制在200-500 字，块与块之间设置50-100 字的重叠，避免关键信息被截断；
   • 进阶分块：结合文档结构分块，例如按章节标题划分段落，或按代码块、表格等特殊内容单独分块，适配技术文档、博客等场景的语义逻辑。
3. 向量嵌入：将文本转化为向量
   • 选择 Embedding 模型：根据场景需求选型，开源模型可选择text-embedding-3-small（轻量高效）、bge-large-zh（中文效果优异）；商业化模型可选择 OpenAI 的text-embedding-ada-002，适配多语言场景；
   • 向量生成：将分块后的文本输入 Embedding 模型，生成固定维度的向量（如 1536 维、768 维），向量之间的距离代表文本的语义相似度。
4. 向量存储：选择合适的向量数据库向量数据库负责存储向量数据与原始文本的映射，支持高效的相似度检索。根据场景规模选型：
   • 个人 / 小团队场景：选择轻量开源数据库，如FAISS（Facebook 开源，支持快速检索）、Chroma（易用性强，支持本地部署）；
   • 企业级场景：选择成熟稳定的商业化数据库，如Milvus（支持海量数据存储与分布式部署）、Pinecone（云原生架构，运维成本低）。

（2）在线推理生成：从检索到回答

在线推理是用户触发请求后的核心流程，决定了回答的效率与质量，具体步骤如下：

1. 问题预处理：优化检索意图
   • 问题清洗：去除用户问题中的冗余内容（如语气词、无关标点），提取核心意图；
   • 问题改写（可选）：针对复杂问题进行语义改写，提升检索准确率。例如，用户问 “怎么解决 Docker 部署 Elasticsearch 的网络问题？”，可改写为 “Docker Elasticsearch 网络配置 端口冲突 解决方法”，让检索更精准。
2. 向量检索：匹配相关文档
   • 将预处理后的用户问题转化为向量（与离线分块使用同一 Embedding 模型，保证向量空间一致性）；
   • 执行相似度检索：在向量数据库中检索与问题向量最相似的 Top-K 个向量（通常 K=3-10），获取对应的原始文本块。
3. 结果重排：提升内容相关性基础检索可能存在语义匹配偏差，需通过重排模型进一步优化结果相关性：
   • 基础重排：使用简单的关键词匹配（如 BM25 算法），补充向量检索的不足；
   • 进阶重排：使用重排模型（如bge-reranker-large），对检索到的 Top-K 个文本块进行二次评分，按相关性从高到低排序，保留 Top-3-5 个最优结果。
4. 拼接输入 LLM：生成回答
   • 构建 Prompt 模板：将 “用户问题 + 重排后的相关文本” 拼接成结构化 Prompt，明确告知 LLM“基于以下参考内容回答问题，不得编造信息”；
   • LLM 生成：将拼接后的 Prompt 输入 LLM，生成最终回答，同时可要求 LLM 标注回答的参考来源（如 “参考文档第 3 章第 2 段”），提升可信度。

2. 核心流程优化：从基础 RAG 到高性能 RAG

基础 RAG 架构可满足 80% 的场景需求，但在复杂业务场景中，还需通过优化策略进一步提升检索准确率与回答质量，主要包括以下维度：

优化维度	具体策略	适用场景
混合检索	结合向量检索（语义匹配）与关键词检索（BM25 算法），通过加权融合的方式获取结果，兼顾语义相关性与关键词精准性	技术文档、专业术语密集的场景
Query 改写	针对模糊问题、长句问题，通过 LLM 生成多个等价检索查询（Query），再基于多个 Query 进行检索，提升召回率	用户问题表述不清晰、意图模糊的场景
HyDE（虚拟文档检索）	先让 LLM 基于用户问题生成一篇 “虚拟文档”，再将虚拟文档转化为向量进行检索，拉近问题与文档的语义距离	专业领域问答、小众知识检索场景
多模态检索	支持图文、音视频等多模态数据的检索与生成，例如检索技术文档中的代码块、图表，辅助 LLM 生成更精准的回答	包含代码、图表的技术博客、产品手册场景
上下文压缩	对检索到的长文本块进行压缩，保留核心语义，避免输入 LLM 的内容过长导致上下文溢出	长文档检索、LLM 上下文窗口有限的场景

3. 效果评估与迭代：让 RAG 持续优化

RAG 的效果不是一次性的，需通过量化指标持续评估，不断调整分块策略、模型选型、重排逻辑等。核心评估指标如下：

• 检索指标：召回率（Recall@K）、精确率（Precision@K）、MRR（平均倒数排名），衡量检索到的内容是否包含答案；
• 生成指标：BLEU 值、ROUGE 值（衡量生成内容与参考内容的相似度）、人类评估（从准确性、相关性、流畅性三个维度评分）。

根据评估结果进行迭代：若召回率低，可调整分块策略（减小分块长度、增加重叠）；若精确率低，可优化 Query 改写规则、升级重排模型；若生成内容存在错误，可补充私有知识库数据、优化 Prompt 模板。

三、RAG 过渡到 Agent

RAG 解决了 LLM 的 “知识可靠” 问题，但仅能完成单轮问答场景（如 “查询某技术文档内容”）。而在复杂业务场景中，用户需要的是多轮、自主、闭环的任务执行（如 “整理近一周的技术博客数据→生成分析报告→发送邮件给团队”），此时需要将 RAG 升级为 Agent，赋予 LLM规划、工具调用、反思迭代的能力。

Agent 的核心逻辑是：以 LLM 为核心大脑，结合 RAG 的长期记忆（私有知识库）、各类工具（API、数据库、代码解释器等），自主拆解任务、选择工具、执行步骤、迭代优化，最终完成复杂任务。从 RAG 到 Agent 的过渡，本质是在 RAG 的基础上，新增 “任务规划” 与 “工具调用” 模块，构建 “感知 - 规划 - 执行 - 反思” 的闭环。

1. Agent 的核心能力：比 RAG 多了什么？

相较于 RAG，Agent 新增了三大核心能力，这是过渡的关键：

• 任务规划能力：自主将复杂任务拆解为多个子任务，明确执行顺序。例如，用户要求 “写一份产品经理求职简历”，Agent 会拆解为：检索简历模板→收集产品经理岗位核心技能→分析目标公司招聘需求→撰写简历初稿→优化排版与措辞→生成最终版本。
• 工具调用能力：自主选择并调用外部工具，弥补 LLM 的局限性。工具类型包括：
  • 知识工具：RAG 检索器（获取私有知识）；
  • 数据工具：SQL 连接器（查询数据库）、Excel/CSV 解析器（处理表格数据）；
  • 代码工具：代码解释器（Python、Docker）、GitHub 操作工具（提交代码、拉取分支）；
  • 业务工具：邮件 API、日历 API、天气 API 等。
• 反思迭代能力：执行工具后，评估结果是否满足任务需求，若不满足则重新规划、调用工具进行迭代。例如，执行 SQL 查询后发现数据缺失，会重新调整查询条件重新获取数据。

2. 过渡路径：从 RAG 到 Agent 的技术升级

这个过渡过程，我们可以分为“升级Agentic RAG→搭建Agent架构→进阶优化”三个步骤，同样从基础入手，逐步落地。

第一步：升级为Agentic RAG

Agentic RAG（智能体化RAG），是RAG过渡到Agent的核心中间步骤——它保留了RAG的检索能力，同时增加了“自主决策”能力，让RAG不再是“被动检索”，而是能根据用户意图，自主判断“是否需要检索”“检索什么内容”“检索后该做什么”。

我们可以通过三个核心能力的升级，实现RAG到Agentic RAG的过渡：

1. 工具封装：将RAG及其他能力封装为“可调用的工具”

Agent的核心是“调用工具完成任务”，所以首先要将RAG检索、SQL查询、API调用、代码执行等能力，封装成标准化的工具，让Agent能直接调用。

比如，我们可以用LangChain（目前最流行的Agent开发框架），将RAG检索封装为一个工具：

retriever_tool = Tool(

name="RAG检索器",

func=retrieve_function, # 自定义的检索函数，实现RAG的检索逻辑

description="用于检索外部知识库中的信息，当用户的问题需要具体的知识、数据或文档内容时，调用此工具；如果不需要外部知识，可直接回答。"

)

除了RAG检索工具，我们还可以封装其他常用工具，比如：

- query_db：SQL查询工具，用于查询数据库中的结构化数据（如用户数据、销售数据）；

- send_email：邮件发送工具，用于发送邮件（调用邮箱API）；

- code_interpreter：代码解释器工具，用于执行Python代码（如数据计算、图表生成）。

工具封装的关键是“明确工具的功能和使用场景”，让Agent能清晰判断“什么时候该调用哪个工具”。

2. 自主决策：让LLM判断“该做什么”

Agentic RAG与传统RAG的核心区别，在于“自主决策能力”。传统RAG是“用户提问→检索→生成”的固定流程，而Agentic RAG能让LLM自主判断：用户的问题是否需要检索？是否需要调用其他工具？是否可以直接回答？

举个例子：用户问“最新的行业营收数据是多少？”，Agentic RAG会进行如下决策：

1. 判断用户需求：需要最新的行业营收数据，属于“需要外部数据”的场景；

2. 判断工具：首先调用“RAG检索器”，检索是否有最新的营收数据文档；

3. 评估结果：如果检索到相关数据，直接基于数据生成回答；如果未检索到，判断是否需要调用“SQL查询工具”（查询数据库中的实时数据），或者告知用户“未找到相关数据”。

这种自主决策能力，需要通过“Prompt工程”和“框架支持”来实现。比如，用LangChain的create_react_agent，通过给LLM输入特定的Prompt，让它按照“思考→判断→调用工具→评估”的逻辑进行决策。

3. 规划与反思：拆解任务，迭代优化

对于复杂任务，Agentic RAG需要具备“任务拆解”和“反思迭代”的能力——将一个复杂任务，拆解成多个简单的子任务，逐一执行，然后评估执行结果，若未达到目标，再进行迭代优化。

比如，用户需求是“整理近3个月的行业资讯，生成一份PDF报告，并发送到我的邮箱”，Agentic RAG会将其拆解为以下子任务：

1. 调用RAG检索器，检索近3个月的行业资讯；

2. 整理检索到的资讯，提取核心要点；

3. 调用代码解释器工具，将整理后的内容生成PDF报告；

4. 调用邮件发送工具，将PDF报告发送到用户指定的邮箱；

5. 反思评估：检查报告是否完整、邮箱是否发送成功，若有问题，重新执行对应步骤。

这种规划与反思能力，是Agent区别于RAG的核心特征，也是实现“自主完成任务”的关键。

第二步：搭建Agent完整架构

当完成Agentic RAG的升级后，我们就可以搭建完整的Agent架构了。目前，最主流、最易用的Agent开发框架是LangChain（及LangGraph，用于构建复杂的状态机Agent），我们以LangChain为例，拆解Agent的核心组件和运行闭环。

1. 核心组件定义（4大组件）

（1）Agent核心：Agent的“大脑”，负责理解用户意图、规划任务、调用工具、反思迭代。推荐使用LangChain的create_react_agent（基础版）或LangGraph（进阶版，适合复杂流程）。LangGraph的优势是能构建“状态机”，清晰定义每个步骤的逻辑和跳转条件，比如“检索失败→重新检索”“生成报告成功→发送邮箱”。

（2）工具集：Agent的“手脚”，包括我们之前封装的RAG检索器、SQL查询工具、API工具、代码解释器等。LangChain提供了大量现成的工具集成，比如与OpenAI、Milvus、MySQL、邮箱API的集成，无需重复开发。

（3）记忆系统：Agent的“记忆”，分为短期记忆和长期记忆。短期记忆用于存储对话上下文（比如用户之前的提问、Agent的执行步骤），确保Agent能理解上下文；长期记忆就是我们搭建的RAG向量库，用于存储海量的知识和数据，供Agent随时检索。

（4）Prompt模板：Agent的“指令集”，用于引导Agent进行决策和执行。比如，Prompt模板中可以包含“你是一个智能助手，需要根据用户需求，自主规划任务，调用合适的工具，完成任务后，向用户反馈结果；若遇到问题，及时告知用户并尝试解决”。

2. Agent运行闭环（从用户输入到任务完成）

一个完整的Agent运行闭环，分为6个步骤，形成“输入→处理→执行→反馈→迭代”的闭环：

1. 用户输入：用户提出复杂任务（如“整理近3个月的行业资讯，生成PDF报告并发送邮箱”）；

2. 意图解析：Agent核心解析用户意图，明确任务目标（生成报告、发送邮箱）和所需资源（行业资讯、PDF生成工具、邮箱工具）；

3. 任务规划：将复杂任务拆解为多个子任务（检索资讯→整理内容→生成PDF→发送邮箱），并确定子任务的执行顺序；

4. 工具调用：按照任务规划，依次调用对应的工具（先调用RAG检索器，再调用代码解释器，最后调用邮件工具），执行每个子任务，并获取执行结果；

5. 结果整合与反思：整合所有子任务的执行结果，检查是否达到用户目标（报告是否完整、邮箱是否发送成功）；若未达到，反思问题所在（如检索不到资讯→重新检索，PDF生成失败→检查代码），并迭代执行；

6. 反馈结果：将最终的任务完成情况，清晰地反馈给用户（如“报告已生成，已发送至你的邮箱xxx，附件为PDF文件”）。

第三步：Agent进阶优化

基础版的Agent搭建完成后，还需要进行进阶优化，解决“任务规划不合理、工具调用错误、反思不及时”等问题，让Agent变得更智能、更稳定。

1. 多工具协同优化：让Agent能同时调用多个工具，协同完成任务。比如，调用RAG检索器获取行业知识，调用SQL查询工具获取结构化数据，调用代码解释器工具进行数据计算和可视化，三者结合，生成更全面的报告。

2. 流程自动化：支持多轮任务和定时任务。比如，“每周一早上，检索上周的行业资讯，生成周报并发送给团队成员”，Agent能自主定时执行，无需人工干预。

3. 错误处理机制：增加异常处理逻辑，比如工具调用失败（如API报错、数据库连接失败）时，Agent能自主重试，或者告知用户并给出替代方案；检索不到相关信息时，能自主判断是否需要调整检索关键词，或者放弃检索。

总结

最后，我们再梳理一下这条演进路径的核心逻辑：

LLM（基础）→ 解决“能理解、能生成”的问题；

RAG（升级）→ 解决“知识可靠、无幻觉、可处理私有/实时数据”的问题；

Agent（终极）→ 解决“自主规划、工具调用、完成复杂任务”的问题。

随着大模型技术的不断发展，Agent的能力会越来越强，未来会逐步渗透到各个行业，替代大量重复性的人工工作。而我们现在要做的，就是从基础做起，一步步完成从LLM到RAG再到Agent的过渡，掌握这项核心技能，为后续的技术落地和创新打下基础。