RAG 与 Agent 原理详解

一篇把 RAG 和 Agent 讲透的原理笔记：它们各自解决什么问题、内部是怎么跑的、边界在哪、又怎么合体成 Agentic RAG。

0. 先给结论

• RAG（Retrieval-Augmented Generation，检索增强生成）= 给模型接一本可以随时翻的书。 不改模型权重，回答前先去外部知识库把相关资料捞出来，塞进上下文再让模型生成。
• Agent（智能体）= 给模型装上手和脚。 让模型自己决定下一步做什么——调用工具、观察结果、再决定下一步，循环往复直到目标达成。
• 一句话区分：RAG 解决「知道」，Agent 解决「做到」。 RAG 把外部知识喂进模型的嘴里，Agent 让模型自己去伸手拿。

两者的底层依赖是同一个东西：大语言模型（LLM）。所以要理解 RAG 和 Agent，得先理解 LLM 的先天性缺陷——它们不是补丁，而是针对缺陷长出来的两套解法。

1. 为什么需要它们：LLM 的四个先天缺陷

LLM 再强，本质也是一个「参数冻结的函数」：给它一段文字，它预测下一个 token。这决定了它有四个绕不开的毛病：

前三个是「知识」问题，答案是 RAG；第四个是「行动」问题，答案是 Agent。

顺带说清一个常见替代方案：微调（Fine-tuning）也能把新知识灌进模型，但代价是「知识更新一次就要重训一次」，慢、贵、且容易灾难性遗忘。RAG 把「知识」和「能力」解耦——模型只负责推理和表达，知识放在外部、随时可改、改了立刻生效。这是 RAG 最核心的设计哲学。

2. RAG 原理

2.1 三个环节：索引 → 检索 → 生成

RAG 的名字就是它的流程，拆开是三段：

一句话：RAG = 先搜（检索），再答（生成）。「搜」发生在向量空间，「答」发生在 LLM 里。

2.2 索引：把「文档」变成「能搜的向量」

这一步是离线做的，决定了 RAG 的上限——检索不到的东西，模型再强也答不出来。

① 切分（Chunking）：把长文档切成小块。这是最容易被低估、却最影响效果的一步。

• 切得太大：一块里塞了太多主题，检索精度下降，还挤占上下文窗口；
• 切得太小：语义被切碎，一块里没有完整信息，模型拿到的是「半句话」。

常见的切分策略从粗到细：固定长度（按 token 数）→ 递归字符切分（按段落/句子层级）→ 语义切分（按语义边界）。工程上还会做 overlap（重叠），让相邻块共享一部分内容，避免关键句子正好卡在切分点上。

② 向量化（Embedding）：用一个专门的嵌入模型，把每个文本块映射成一个高维向量（比如 768 / 1024 / 1536 维）。这个向量的妙处是——语义相近的文本，向量距离也近。「如何重置密码」和「忘记密码怎么办」字面完全不同，但在向量空间里离得很近。

嵌入模型通常是「双塔（bi-encoder）」结构：问题和文档各自独立编码成向量，这样才能离线把文档全部算好、在线只编码问题，速度快。代价是它只看「大致像不像」，精度不如后面要讲的 cross-encoder。

③ 存入向量数据库：把「向量 + 原文 + 元数据（来源、时间、权限）」一起存进向量库（Milvus / Qdrant / pgvector / Elasticsearch 等）。

2.3 检索：从「向量空间」里捞出最相关的几块

④ 相似度检索：把用户问题用同一个嵌入模型编码成向量，然后在库里找最相似的 Top-K 块。相似度常用余弦相似度或内积。

数据量大时不可能逐个算，所以用 ANN（近似最近邻）算法加速，主流有：

• HNSW：分层图结构，查询快、召回高，内存占用较大；
• IVF：先聚类分桶，只在最近的几个桶里找，省内存；
• PQ：把向量压成短码，进一步省空间（常和 IVF 组合成 IVF-PQ）。

记住关键词：ANN 是「用一点点精度换极大的速度」——它不保证找到全局最近邻，但绝大多数时候够用。

⑤ 重排序（Rerank，可选但强烈建议）：向量检索有个先天短板——双塔模型只看「整体像不像」。补一刀的做法是加一个 cross-encoder：把问题和每个候选块拼在一起送进模型算相关性打分。它更准，但慢，所以只对召回的前几十个做，重排出真正的 Top-5/10。

检索增强的几种常见手法：

2.4 生成：把资料喂进模型，让它「有据可依」

最后一步很朴素：把系统指令 + 检索到的文本块 + 用户问题拼成一个 Prompt，交给 LLM 生成。

这里有几个关键设计：

• 约束回答范围：「只根据以下资料作答，资料里没有的就说不知道」——这是抑制幻觉的主要手段；
• 要求引用：让模型标注每句话来自哪一块，既方便用户核实，也让编造无处遁形；
• 控制上下文预算：塞太多块既贵又会让模型「迷失在中间（lost in the middle）」，所以召回不是越多越好，重排后的精准 Top-K 往往优于粗糙的 Top-50。

2.5 RAG 的边界

RAG 不是银弹。它的效果强依赖检索质量：知识库里没有、切分切碎了、检索没召回，模型都答不对；它也不擅长需要多步推理的问题（比如「A 文档的数字 × B 文档的比例，再对照 C 表格判断是否超标」）——因为它是「一次检索、一次生成」的线性管道，不会自己去「查了再查」。这个短板，正是 Agent 要接管的。

3. Agent 原理

3.1 定义：Agent = LLM + 规划 + 记忆 + 工具

如果说 RAG 是「一问一答」，Agent 就是「给个目标，自己想办法达成」。业界通用的拆解是四件套：

核心区别：RAG 的流程是人写死的三步管道；Agent 的流程是模型自己动态决定的循环。

3.2 核心循环：ReAct（Reason + Act）

Agent 最经典的运行范式叫 ReAct，名字就是「推理 + 行动」的合成词。它把一次任务拆成不断重复的三拍：

用伪代码看更清楚：

1
2
3
4
5
6
7
while not done:
    thought = llm.reason(context)        # 想：下一步该干嘛
    if thought.is_final_answer:
        return thought.answer            # 收工
    action = thought.tool_call           # 做：决定调哪个工具、传什么参数
    observation = execute(action)        # 调工具，拿回结果
    context.append(observation)          # 记：把观察加回上下文，进入下一轮

关键洞察：Agent 的能力上限 = LLM 的推理能力 × 工具的质量与数量。给模型一把好用的工具集，它就能做很多事；工具缺失或难用，再聪明的模型也束手无策。

3.3 工具调用（Function Calling / Tool Use）是怎么落地的

「调用工具」听起来玄，机制其实很朴素：

1. 你把可用工具用结构化描述（通常 JSON Schema）告诉模型：工具名、作用、参数类型；
2. 模型不直接执行，而是输出一段结构化的调用意图（如 {"tool": "search", "args": {"q": "杭州天气"}}）；
3. 框架（Harness）解析这段意图，真正去执行；
4. 把执行结果回灌进上下文，模型据此继续推理。

划重点：模型只「提议」，框架才「执行」。 这条边界极其重要——它意味着权限、审计、拦截都发生在框架层，而不是指望模型自觉。（这正是 Harness 工程存在的理由。）

3.4 规划（Planning）：把大目标拆成小步

复杂任务不可能一步做完，Agent 需要「先想清楚再动手」的能力：

3.5 记忆（Memory）：短期的上下文 + 长期的外部存储

• 短期记忆：就是当前的对话上下文窗口。缺点很明显——窗口满了就得压缩/遗忘，长任务容易「忘了开头」。
• 长期记忆：把重要信息写进外部存储（数据库、向量库），需要时再检索回来。注意，长期记忆的实现往往就是 RAG——用检索来找回过去的经验。这也是 RAG 与 Agent 交集的第一个证据。

3.6 反思（Reflection）：让 Agent 自己纠错

单次 ReAct 循环容易一条道走到黑。Reflexion 类方法在循环里插入一个「自我检查」步骤：让 Agent 回看自己的行动与结果，判断「刚才那步对不对」，错了就调整策略重来。相当于给 Agent 加了一个「事后复盘」的环节。

3.7 多智能体（Multi-Agent）：分工协作

一个 Agent 既当规划者又当执行者容易顾此失彼，于是有了多智能体：把角色拆开——规划者 / 执行者 / 审查者 / 检索者各自独立，通过消息协作。好处是每个角色上下文更干净、职责更聚焦；代价是通信成本、协调复杂度和「互相甩锅/空转」的风险都会上升。

4. RAG vs Agent：一张表看清区别

一句话对照：RAG 是函数（给输入、按固定逻辑返回输出）；Agent 是程序（自己控制流程，可能跑循环、可能递归）。

5. 合体：Agentic RAG

现实里两者不是二选一，而是融合——把 RAG 降级成 Agent 手里的一件工具，让 Agent 自己决定「要不要检索、检索什么、够不够、要不要再搜」。

这就产生了 Agentic RAG，它在普通 RAG 上加了「自主性」：

• 要不要检索？ 简单问题直接答，不用浪费一次检索（Self-RAG 的入口判断）；
• 检索结果相关吗？ 不相关就改写 query 重新搜，而不是硬塞给模型；
• 一次够吗？ 复杂问题多轮检索、逐层深入，而非一次 Top-K 定生死；
• 答案有依据吗？ 生成后再自查，发现无据可依就回退重来。

对照一下：

这就是「RAG 解决知道、Agent 解决做到」的最终合流：Agent 负责「怎么查、查几次、查完怎么用」，RAG 负责「把外部知识真正取回来」。

6. 各自的坑（工程上真正会踩的）

RAG 侧

1. 垃圾进、垃圾出：知识库本身脏、旧、乱，检索再准也没用；
2. 切分是隐形杀手：块太大/太小/切断语义，效果断崖式下跌，且很难 debug；
3. 召回与精度的权衡：Top-K 太小漏信息，太大淹没模型（lost in the middle）；
4. 只看语义、忽略结构：表格、层级、条款编号这类结构信息，纯向量检索经常抓不住——这时混合检索（BM25）就很重要。

Agent 侧

1. 不收敛 / 死循环：模型在同样的状态里反复打转，烧钱烧时间——必须有步数上限、超时和熔断；
2. 误差累积：多步链路里每一步 90% 正确，十步之后正确率只剩约 35%（0.9¹⁰）——这也是「为什么要有确定性门禁」的原因；
3. 幻觉式工具调用：编造不存在的工具名或参数——需要框架层校验；
4. 成本与延迟不可预测：用户等不了几十秒，产品设计必须考虑「快慢分流」；
5. 安全边界：Agent 能真的动手（删库、发消息、下单），所以权限必须卡在框架层，不能靠模型自觉。

7. 总结

• RAG 用「先检索、再生成」的方式，把外部知识接进模型的口中，治的是 LLM 的知识冻结与幻觉；它的灵魂是「知识与能力解耦」——权重不动，知识随时换。
• Agent 用「想 → 做 → 看 → 再想」的 ReAct 循环，给模型装上手和脚，治的是 LLM 只会说不会做；它的灵魂是「让模型动态决定控制流」，能力上限 = 推理能力 × 工具质量。
• 二者不是竞争关系：RAG 是 Agent 的一件工具，Agent 是 RAG 的调度者。合体成 Agentic RAG 后，Agent 决定「怎么查」，RAG 负责「取回来」。

用一句最好记的话收尾：

RAG 让模型「说得有据」，Agent 让模型「做得成事」。

8. 术语速查卡

9. 延伸阅读

• ReAct: Synergizing Reasoning and Acting in Language Models（Yao et al.）——ReAct 循环的原始论文，Agent 范式的地基；
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（Lewis et al., 2020）——RAG 的命名与开山之作；
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection——「要不要检索、结果好不好」交给模型自己判断的代表工作；
• Reflexion: Language Agents with Verbal Reinforcement Learning——Agent 自我反思机制。

读论文时抓一条主线即可：RAG 一路在解决「检索得准不准」，Agent 一路在解决「下一步做得对不对」。

• Previous
  spark调优总结
• Next
  第 1 天：为什么 AI 编程需要工程化