在前文中,按照大厂的话术讲,我们 “搭建了一个本地轻量RAG的最小闭环” ,但从技术难度、体量和可用性上来看,充其量是一个测试的玩具而已。而在搭建真正的RAG系统之前,我们需要一篇详细的文章来梳理一下,RAG这几年的飞速发展,当前的热门方向以及合理的技术选型。
RAG 从哪里来
两条传统的漫长分离
RAG 并非凭空出现的发明,而是两个历史悠久的独立领域:信息检索(IR)与自然语言生成(NLG),在特定技术突破的催化下,历经漫长演化后融合的产物。
信息检索的历史可以追溯到 20 世纪 50–60 年代。Hans Peter Luhn 和 Gerard Salton 等先驱奠定了该领域的基础,在当时,他们研究的主要问题是如何从大规模文档集合中找出与用户查询相关的资料。
为了评估某个词对一篇文章的重要程度,学者们提出了 。它由两部分巧妙结合:词频():词在本文中出现的频率。逆文档频率():词在所有文章中的稀有度。
例如,“梯度下降”在某篇 AI 文章中 高、 也高,得分就高;而“的”字虽然到处都是,但 趋近于 0,最终得分也低。这初步解决了关键词权重的问题。
随后,为了更贴近用户真实搜索体验,BM25 作为 TF-IDF 的超级升级版诞生了。它从概率论角度出发,完整公式为:
其中 是查询中的第 个词, 是该词在文档 中的词频, 是文档长度, 是平均文档长度,(通常 1.2–2.0)和 (通常 0.75)是可调超参数。
公式中体现了两个关键优化:
- 词频饱和度:分子分母中 的设计使词频的作用会饱和,有上限。就像吃饭,吃第一碗幸福感很强,到了第十碗幸福感不会再增加。当 时,该项趋近于 ,不会无限增长。
- 文档长度惩罚: 参数控制文档长度归一化的强度。 时完全不惩罚长文档, 时按比例全额惩罚。
尽管 BM25 极为经典,但它本质上仍是字面匹配,不懂得土豆和马铃薯是同一个东西。于是,向量空间模型应运而生。它试图把词语的含义转换成电脑能处理的一组坐标空间。
假设我们用 [“生物性”, “人类关联性”] 两个维度来量化,"狗"可能是 [9, 4],"石头"是 [1, 0]。意思相近的词,在空间中的坐标点就靠得很近。为了计算这种空间中的语义相似度,余弦相似度成为了核心工具。它不关心两点间的绝对距离,而是关注方向的一致性:
结果为 1 表示语义相同,0 表示毫无关联,-1 表示语义相反。
自然语言生成 NLG 与此同时独立发展,目标是让计算机能够理解并生成流畅的人类语言。早期的 NLG 高度依赖专家编写的硬编码逻辑(基于规则),后来演进为通过统计字词相邻概率的 N-gram 模型。但长期以来,NLG 一直被困在“语言不够自然、无法长篇大论”的瓶颈中。直到深度学习与 Transformer 架构的爆发,大语言模型(LLM)赋予了 NLG 惊人的能力。
两个领域之间存在方法论上的差异,IR 更偏向统计和定量分析,早期 AI 则更侧重基于逻辑和符号的推理。这种差异导致两个领域在很长时间内并行发展,鲜有交集。然而,正是这种差异化的发展,为日后两者的优势互补与融合埋下了伏笔。在现在,IR 和 NLG 都存在一定的问题:
-
现代 NLG(大模型):虽然表达极其流畅,但它的知识被封印在训练完成的那一刻,容易产生幻觉。
-
现代 IR(搜索引擎/向量检索):能够精准定位最新、最权威的知识文档,但它整理、归纳并直接回答用户的问题。
正因如此,这条漫长的分离之路走到了交汇点。我们将 IR 强大的精准寻址能力,与 NLG 完美的自然语言表达能力拼接在一起,让 IR 找到资料,交给 NLG 进行总结陈述,这就是 RAG 诞生的原因。
前 RAG 时代:开放域问答
在 RAG 被正式提出之前,开放域问答ODQA 系统是融合 IR 与 NLG 最成功的尝试,可以被视为原型 RAG,这些早期系统采用经典的two step pipeline:
- 检索器(Retriever):接到问题后用 TF-IDF 或 BM25 从海量文档中快速找出几十篇可能相关的段落
- 阅读器(Reader):精读这些段落并从中抽取或生成答案
这个先查询信息,后精读作答的模式,就是 RAG 最核心思想的雏形。但它存在几个根本性缺陷,直接催生了后来更先进的 RAG 架构:
视野太窄:当时的阅读器能力有限,只能处理很短的文本片段。很多复杂问题的答案需要通读整篇文章甚至好几篇文章才能明白,这种管中窥豹的做法常常导致关键信息丢失。
检索与分析割裂:检索器和阅读器是分开训练、独立工作的。即便阅读器发现检索器给的材料全是垃圾,它也没法把这个反馈传递回去,检索器永远无法从最终答案的好坏中学习。
跨专业能力差:在维基百科上训练出来的检索器无法适应新领域。
Transformer
两项关键技术的突破为解决上述挑战并最终催生 RAG 铺平了道路。
Transformer 革命:2017 年 Transformer 架构的提出是一个分水岭事件。其核心的自注意力机制(Self-Attention)使得模型能够捕捉文本中长距离的依赖关系,生成上下文感知的词嵌入。在此之前,计算机理解一句话里的词语,很大程度上是孤立的,或者只能看到旁边的几个词。而 Transformer 让计算机能够像人一样通读整段话,理解每个词在当前语境下的确切含义,这一进步直接推动了检索技术的革新。
- 稀疏检索(Sparse Retrieval):以 TF-IDF 和 BM25 为代表,依赖关键词的精确匹配。
- 稠密检索(Dense Retrieval):利用 Transformer 的强大理解力,不再是匹配文字,而是匹配语义。它把查询和文档都转换成代表其核心思想的意义向量,然后在数学上寻找哪个文档的"意义"和查询最接近。
两者的结合,最终为 RAG 创造了完美的条件。BM25 对于需要精确匹配的专有名词、代码等非常有效;现代语义搜索理解模糊的、概念性的问题。它们的失败模式是互补的,混合检索始终优于任何一种单独使用。
RAG的产生
RAG的正式诞生
命名了 RAG 的论文,Facebook AI 的 Patrick Lewis 等人于 2020 年发表的《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》,其核心贡献是提出了一个通用的微调秘方,将参数化记忆与非参数化记忆相结合。
用开卷考试来理解:
- 参数化记忆:就像你的大脑,已经背下来的知识,内化成了你的一部分(存储在模型的参数里)。优点是反应快,随时能调用;缺点是知识有上限,而且可能会记错。
- 非参数化记忆:就像带进考场的参考资料,信息量巨大、准确且可以随时更新,但查找信息需要时间。
将检索到的文档视为潜变量 是论文最精妙的地方。而 RAG 的方法是不立刻决定哪一篇文章是唯一正确的,而是在脑海中进行一个快速的、模糊的概率评估,譬如论文 1 有 70% 的可能性有用,论文 2 只有 10%,论文 3 有 90% 非常关键。然后写的每一句话,都是融合了所有高可能性资料的结果。
形式化地,生成答案 的概率通过对所有可能文档 求边际化得到:
其中 是检索模型给出的文档相关性概率(即这篇资料有多大可能性有用), 是生成模型在给定文档 条件下的生成概率(即基于这篇资料能写出什么)。实际操作中, 被近似为检索器返回的 Top-K 文档,而非遍历整个语料库。
这就是边际化:加权求和,融合多种可能性,而不是死守着一篇。
端到端训练是另一个关键创新。老旧方法先单独训练检索器,再评单独训练生成器,而 RAG 的方法是训练目标是最大化边际化后的对数似然:
其中 是检索器参数, 是生成器参数。如果答案精彩,这个高分会同时奖励整个答题流程,即生成器 )与检索器 。梯度通过边际化自然地流向两个模块,实现自动地、同步地联合优化。
两种生成模式
RAG-Sequence(专注单一信源模式):适用于答案往往包含在单一、连贯文档里的任务。找到 5 篇最相关的文章,先拿出第 1 篇,只根据这篇完整地写一份草稿;然后收回,拿出第 2 篇,再写一份独立的完整草稿……重复 K 次,最终对 K 份草稿进行评估和融合,源自更相关文章的草稿占有更高权重。
每篇文档独立生成完整答案序列,最后按文档相关性加权求和。
RAG-Token(灵活多源融合模式):更强大,适用于需要综合多个信息源才能形成的复杂答案。把 5 篇文章一次性提取出来,但输出时只能一个词一个词地写,在写每一个词时,都会快速浏览所有 5 篇文章,综合所有信息后决定哪个词最好。
注意求和()与求积()的位置交换了,说明边际化在每个 token 级别进行,而非序列级别。这种方式能将来自不同来源的碎片化信息天衣无缝地融合在一个连贯的答案中。
两者的核心区别在于融合粒度。RAG-Sequence 在文档级别融合(每篇文档产出一个完整候选答案),RAG-Token 在 token 级别融合(每个词都综合所有文档的信息)。后者更灵活,但计算成本也更高。
为什么这很重要
RAG 通过一个核心机制应对 LLM 的根本性问题:事实接地(Factual Grounding)。它强制 LLM 的生成过程必须以外部检索到的、可验证的、最新的事实为基础,而不是仅仅依赖其内部固化的参数化记忆。
这带来了三重好处:
- 通过提供准确的上下文,显著降低幻觉的发生率
- 通过连接可实时更新的知识库,克服知识截止的问题
- 通过安全地访问私有数据库,使 LLM 能够利用专有知识,同时保护数据隐私
RAG 还从根本上改变了可解释性的故事。纯 LLM 是黑箱,其决策过程难以解释。RAG 通过将知识源外化,创造了一个本质上更加透明和可验证的系统,用户原则上可以检查模型引用的外部文档,以核实其生成内容的真实性。这对企业部署至关重要,因为可审计性通常是硬性要求。
现代 RAG 系统架构
两个阶段
RAG 系统有两个截然不同的操作阶段。
索引(离线阶段):这发生在任何用户查询到来之前,目标是创建一个高效、可搜索的知识索引。
- 加载(Load):从各种数据源(文件系统、数据库、API)加载原始数据
- 分割(Split):将长文档分割成更小的、语义完整的文本块(Chunks)
- 嵌入(Embed):使用嵌入模型将每个文本块转换成高维数字向量
- 存储(Store):将向量及其对应的原始文本存储到向量数据库,建立索引
检索与生成(在线阶段):当用户提交查询时,系统实时执行。
- 检索(Retrieve):将用户查询转换为查询向量,在向量数据库中找出 Top-K 个最相关的文本块
- 增强(Augment):将检索到的文本块与用户原始查询组合,形成"增强提示"
- 生成(Generate):将增强提示输入 LLM,生成最终的、有事实依据的回答
分块的问题
分块策略对 RAG 质量的影响远超实践者通常的预期,更小的块更精确,但会丢失上下文,而更大的块保留了上下文,但也引入了噪声。
| 策略 | 方法 | 优势 | 劣势 |
|---|---|---|---|
| 固定大小分块 | 按 token 数切割 | 简单快速 | 破坏语义完整性 |
| 语义分块 | 按句子/段落边界 | 语义完整 | 块大小不均 |
| 递归分块 | 层级分割(章节→段落→句子) | 灵活可控 | 需预定义层级 |
| 上下文增强分块 | 块 + 前后文摘要 | 检索精度高 | 存储开销大 |
一个将表格从中间切开、或将一个论断与其支撑证据分开的块,会以难以调试的方式降低检索质量。分块质量是整个 RAG 系统的上限,一个顶级的生成器也无法弥补由糟糕分块带来的劣质上下文。
嵌入模型
嵌入模型是 RAG 系统的翻译官,负责将文本信息转换为机器可以理解的向量。索引文档和编码查询必须使用同一个嵌入模型。
现代嵌入模型普遍采用双编码器架构:查询和文档分别独立编码为固定维度的向量,相似度通过向量运算(如余弦相似度或内积)计算。训练目标是对比学习,拉近相关文档对的向量距离,推远不相关的:
其中 是正样本(相关文档), 是负样本, 是温度参数。这本质上是一个 softmax 分类问题。
截至 2026 年 3 月,MTEB 排行榜 TOP5 如下表:
| 排名 | 模型 | 平均分 | 参数量 |
|---|---|---|---|
| 1 | GTE-Qwen2-7B-Instruct | 72.05 | 7B |
| 2 | NV-Embed-v2 | 71.23 | 7B |
| 3 | E5-Mistral-7B-Instruct | 70.36 | 7B |
| 4 | Voyage-3-large | 70.21 | 商业 |
| 5 | text-embedding-3-large | 64.59 | 商业 |
顶级模型与旧选项(如 text-embedding-ada-002)之间的差距是实质性的。如果你在使用旧的嵌入模型,升级可能是你对现有 RAG 系统能做的 ROI 最高的改进。
向量数据库
向量数据库针对一个操作进行了优化:给定一个查询向量,在大型集合中找到 k 个最相似的向量。这是近似最近邻问题。
精确最近邻搜索需要将查询与数据库中的每个向量进行比较,对于数百万个向量则无法使用。ANN 算法通过构建索引结构来交换少量精度换取数量级的速度提升。
主流 ANN 索引算法包括:
- HNSW(Hierarchical Navigable Small World):当前最流行的算法。构建多层图结构,顶层是稀疏的"高速公路",底层是密集的"小路"。查询时从顶层开始,快速定位到大致区域,然后逐层下降精确搜索。时间复杂度约 ,远优于暴力搜索的 。
- IVF(Inverted File Index):先用 K-means 聚类将向量空间划分为 个 Voronoi 单元,查询时只搜索最近的 个单元。 越大精度越高但越慢,典型设置 。
- PQ(Product Quantization):将高维向量压缩为短编码,大幅减少内存占用,代价是精度轻微下降。常与 IVF 组合使用(IVF-PQ)。
当前值得了解的数据库选项:
| 数据库 | 类型 | 特点 | 适用场景 |
|---|---|---|---|
| Milvus/Zilliz | 开源+云 | 大规模,高性能 | 亿级向量 |
| Qdrant | 开源+云 | 过滤功能强 | 结构化+向量混合 |
| Chroma | 开源 | 轻量,易集成 | 开发测试 |
| pgvector | 开源(PG 扩展) | 无需额外基础设施 | 已有 PG 环境 |
| Pinecone | 云服务 | 全托管,高可用 | 企业生产环境 |
RAG 的演进路径
RAG 技术演进可以清晰地划分为三个阶段,反映了该领域从简单概念验证到复杂生产级系统的快速成熟过程。
阶段一:Naive RAG(2020–2022)
Naive RAG 是最基础的实现形式,严格遵循线性的"索引 → 检索 → 生成"流水线,不包含任何高级优化策略。
其流程非常直接:接收用户查询 → 编码为向量 → 相似性搜索检索 Top-K 块 → 拼接成增强提示 → LLM 生成答案。
失败模式是可预测的:
- 检索质量低:检索到的文本块可能与查询只有表面的关键词重合,但语义上并不相关,引入大量噪声
- 幻觉依然存在:当检索到的信息充满噪声或不足时,LLM 仍然会产生幻觉
- 答案质量不稳定:生成的答案可能重复冗余、逻辑不连贯
阶段二:Advanced RAG(2022–2024)
Advanced RAG 通过在流水线每个阶段的针对性干预来解决这些失败模式。
检索前:查询转换
查询重写:用 AI 模型把用户的简单提问改写成更具体、更标准的问题。"RAG 有啥缺点?“→"检索增强生成系统在实际应用中,主要有哪些技术挑战和限制?”
HyDE(假设文档嵌入):不直接搜索问题,而是先让 AI 根据问题想象并生成一个最完美的答案,然后拿着这个假想的完美答案去知识库里找最相似的真实文档。
其数学原理是利用生成模型弥合查询空间和文档空间之间的分布差异:
由于假设文档 与真实文档在同一语义空间中(都是陈述性文本),嵌入相似度比直接用疑问句去匹配陈述句更准确。这在多个基准上将召回率提高了 10–20%。
后退提示(Step-back Prompting):对于具体问题,先检索更一般版本问题的上下文。
检索后:重排序和压缩
Cross-encoder 重排序:初始检索使用双编码器(快速,近似),检索 Top-50 候选集。然后用更强大的 Cross-encoder 对这个小规模候选集进行二次打分和排序,找出真正最相关的 Top-5。Cross-encoder 能够同时处理查询和文档,进行更深层次的相关性判断,精度远高于双编码器。
上下文压缩:在将检索到的内容送入 LLM 之前,主动对其进行压缩和筛选,移除与查询无关的句子或段落,对多个文档进行摘要。好处是双重的:帮助 LLM 聚焦于最关键的证据,同时有效管理 token 数量。LLMLingua 等方法可以在质量损失最小的情况下将上下文压缩 3–5 倍。
混合检索
对基线 RAG 最可靠的改进是结合稠密和稀疏检索。常见做法有两种:
加权分数融合:直接对两种检索分数进行线性组合。
常见权重 ,即 0.7 × 稠密分数 + 0.3 × BM25 分数。确切权重不如组合本身重要——你在覆盖每种方法的盲点。
Reciprocal Rank Fusion(RRF):不依赖原始分数(不同检索器的分数量纲可能不同),而是基于排名进行融合:
其中 是所有检索器集合, 是文档 在检索器 中的排名, 是平滑常数(通常 )。RRF 的优势在于不需要归一化分数,对异构检索器组合特别友好。
Advanced RAG 关键技术效果提升大致如下:
| 优化维度 | 技术手段 | 效果提升 |
|---|---|---|
| 索引优化 | 语义分块、层次化索引、元数据增强 | 检索精度 |
| 查询增强 | Query 重写、HyDE | 召回率 |
| 后置精炼 | Re-ranking(Cross-encoder)、上下文压缩 | 答案质量 |
| 混合检索 | 向量检索 + BM25 | 鲁棒性 |
Modular RAG(模块化 RAG)
模块化 RAG 不仅是一系列技术的集合,更代表了一种根本性的系统设计范式转变。它将原本线性的 RAG 流水线分解为多个独立的、可插拔的、可独立优化的功能模块。
核心组件:
- 搜索模块:集成多种检索策略(向量搜索、关键词搜索、知识图谱搜索),包含"查询路由器",根据查询类型智能分发
- 推理模块:将复杂问题分解为多个子问题(Query Decomposition),然后进行迭代式检索,模拟人类的研究过程
- 记忆模块:集成对话历史记录,处理多轮对话;高级实现可利用 LLM 自身生成的内容作为自记忆
- 融合/合并模块:当系统通过多查询或多源检索获得多个结果集时,智能合并这些结果(如 RAG-Fusion 技术)
- 反馈循环:利用用户的隐式反馈(点击)或显式反馈(评分),通过强化学习持续优化各模块性能
Agentic RAG
从工具到Agent的根本性转变
传统 RAG,即使是其进阶模块化形式,从根本上也是被动的。查询到来,流水线执行,答案返回。系统不决定是否检索、检索多少次,或检索到的信息是否足够。
Agentic RAG 通过让 LLM 成为检索过程的主动参与者而不是被动消费者来改变这一点。
1 | 传统RAG流程: |
1 | Agentic RAG流程: |
四种 Agentic 核心能力
1. 反思(Reflection)
Agent 能审视自己的输出,发现错误并迭代改进。
“Agents evaluate their own decisions and outputs, identifying errors and areas for improvement.”
关键创新是引入元认知机制:
- Faithfulness Score:评估答案是否基于检索内容
- Relevance Score:评估检索内容与问题的相关性
- Completeness Check:判断信息是否充分
2. 规划(Planning)
Agent 能制定结构化的任务执行计划,把复杂问题拆解成子任务。
案例:复杂问题"比较二战期间同盟国在欧洲和太平洋战场的战略差异"
- 传统 RAG:一次检索,信息片段化,答案肤浅
- Agentic RAG:① 分解为"欧洲战略"+"太平洋战略"两个子问题 → ② 分别检索并总结 → ③ 第二轮针对"战略差异"进行对比检索 → ④ 综合生成深度分析
3. 工具使用(Tool Use)
Agent 能根据问题的具体性质,实时判断应该调用哪个工具:
1 | Agent决策树: |
案例:
企业财报分析:从结构化数据库提取财务指标 → 从向量库检索行业分析报告 → 调用计算器进行同比增长分析 → 网络搜索最新行业新闻 → 综合生成多维度报告。
4. 多智能体协作(Multi-Agent Collaboration)
多个 Agent 分工合作,各自专注子任务,汇聚结果。
五种工作流模式
来自 Anthropic 和 LangGraph 的研究,定义了 Agent 系统中常见的协作模式:
1. 提示链(Prompt Chaining):将复杂任务拆解为顺序子步骤,每步结果作为下步输入。适用于任务可固定分步的场景;代价是顺序执行,延迟较高。
2. 路由(Routing):对输入进行分类,将不同类型的问题导向专门的处理流程。简单问题用小模型,复杂问题用大模型。
3. 并行化(Parallelization):将任务拆分为互不依赖的子任务并发执行,或多个模型投票(Voting)交叉验证,提升准确率。
4. 编排者-工人(Orchestrator-Workers):中心编排者动态分配任务给专业 Worker,能动态适应输入复杂度,如果第一个 Worker 的输出揭示需要不同的方法,编排者可以调整。
5. 评估者-优化者(Evaluator-Optimizer):初步输出 → 评估模型打分 → 迭代优化,直到达标。适用于有明确评估标准、迭代改进效果显著的任务(如文学翻译、代码审查)。
Agentic RAG 架构分类
1. Single-Agent RAG(单智能体):一个 Agent 独立管理检索和生成全流程。架构简单,易于实现;局限是扩展性差,难以处理多步推理。
2. Multi-Agent RAG(多智能体):多个 Agent 协作,各自专注特定子任务(检索、推理、综合)。模块化强,可扩展性好;局限是协调复杂度随 Agent 数量上升,存在冲突风险。
3. Hierarchical Agentic RAG(层级智能体):顶层 Agent 编排,底层 Agent 专注子任务,结果逐层汇总。适用于大规模复杂任务,需要明确的分层职责。
4. Corrective Agentic RAG(校正式):引入反馈回路,生成 → 批评模块评估 → 基于反馈修正 → 循环直至达标。优点是高准确率,适合高风险任务;局限是计算开销大,需防止无限循环。
5. Adaptive Agentic RAG(自适应式):实时评估查询上下文,动态调整检索策略。查询复杂性分类器是关键组件:
| 类型 | 特征 | 示例 | 策略 |
|---|---|---|---|
| 简单 | 事实性、封闭式 | “北京是哪个国家的首都?” | 直接回答 |
| 中等 | 需要单一知识源 | “解释什么是 RAG 技术” | Top-3 检索 |
| 复杂 | 需要综合多源 | “对比 RAG 和 Fine-tuning 的优劣” | 多轮检索 |
| 开放 | 需要推理和创造 | “设计一个 RAG 系统架构” | Agent 模式 |
6. Graph-Based Agentic RAG(图增强):见下一节详细介绍。
7. Agentic Document Workflows(ADW,智能体文档工作流):端到端文档自动化处理,包括解析、状态维护、知识检索、智能编排,最终生成可执行输出。
GraphRAG
GraphRAG 值得单独讨论,因为它解决了基于向量的检索的真正局限性:无法推理关系。
传统 RAG 的痛点:
- 只能检索到孤立的文档片段
- 无法理解实体间的复杂关系
- 多跳推理能力弱
知识图谱将信息表示为"实体-关系-实体"三元组构成的巨型关系网络。比如,“汤姆·汉克斯"是一个实体,”《阿甘正传》"是另一个实体,"主演"就是它们之间的关系。
传统 RAG vs GraphRAG 对比:
1 | 传统RAG: |
Microsoft GraphRAG 框架的核心创新是社区检测 + 层次化摘要:
- 从原始文档提取实体和关系,构建知识图谱
- 使用 Louvain 算法将图谱划分为主题社区
- 为每个社区生成摘要节点
- 查询路由:简单查询直接检索实体,复杂查询先检索社区摘要再深入细节
Agentic RAG 是否需要微调 LLM?
先理解三者解决的是不同维度的问题
| 维度 | RAG | Fine-tuning | Agentic 编排 |
|---|---|---|---|
| 解决什么 | 知识的时效性与准确性 | 模型的行为模式与推理深度 | 任务的自主决策与多步执行 |
| 修改模型权重? | 否 | 是 | 通常否(编排层) |
Agentic RAG 的核心创新在于编排层,让 LLM 自主决定何时检索、检索什么、用哪个工具。这一层本身不需要微调,它依赖 LLM 的通用推理和指令遵循能力,通过精心设计的系统提示(System Prompt)和工具定义来实现。
不需要微调的场景(纯 Prompt Engineering + Agentic 编排)
大多数 Agentic RAG 应用不需要微调 LLM。具体条件:
- 通用知识查询+自动化:Agent 只需要从文档库检索信息并回答问题,不涉及深度专业推理。例如企业 FAQ 机器人、保险索赔自动审核。
- 基座模型足够强大:使用 GPT-4、Claude 3.5、Qwen-Max 等前沿模型时,其通用推理、工具调用和指令遵循能力已经足以支撑 Agentic 行为。
- 数据频繁变化:如果知识库每天更新,微调的静态快照特性(需要重训才能更新知识)反而是劣势。
需要微调的场景(Fine-tuning + Agentic RAG 组合)
当以下条件出现一个或多个时,微调成为必要:
-
深度领域专业化:法律合同审查需要模型理解法律论证模式,医疗决策需要掌握临床推理逻辑。这些"思维方式"无法仅通过 RAG 注入上下文来实现,模型需要在训练阶段就内化这些推理模式。
-
严格的输出格式控制:Agent 的输出需要精确匹配下游系统的 API 格式(如 JSON Schema、特定的 Function Calling 协议)。微调可以将格式约束烧录进模型权重,比纯提示工程更稳定、更省 token。
-
成本与延迟约束:用微调后的小模型(7B–13B)替代大模型 API 调用,可以将推理成本降低。
-
反射能力内化:Self-RAG 就是典型案例,通过微调让模型学会生成"反射标记"(Reflection Tokens),在推理时自主判断是否需要检索、检索结果是否可靠、生成内容是否有事实依据。
需要微调的代表性方法
| 方法 | 微调内容 | 解决的问题 |
|---|---|---|
| Self-RAG | 在 LLM 词汇表中新增 4 类反射标记(Retrieve/IsRel/IsSup/IsUse),基于 Llama 2 进行监督微调 |
让模型学会自主决定何时检索、自我评估生成质量 |
| CRAG | 训练轻量级检索评估器(T5-large 级别),而非微调主 LLM | 评估检索结果质量,决定"采纳/改写/丢弃"策略 |
| AgentFlow(Flow-GRPO) | 使用在线强化学习(PPO)微调 Planner 模块(Qwen2.5-7B),其他模块(Executor/Verifier)保持冻结 | 优化规划器在长视距任务中的决策能力 |
| InstructRAG | 微调 LLM 学会对检索结果进行"自我合成"推理 | 提升模型处理噪声检索结果的鲁棒性 |
Self-RAG 的核心创新是引入四种反射标记作为特殊 token 扩展 LLM 的词汇表:
[Retrieve]:{yes, no, continue}— 决定当前是否需要检索[IsRel]:{relevant, irrelevant}— 评估检索文档的相关性[IsSup]:{fully supported, partially supported, no support}— 评估生成内容是否有文档支持[IsUse]:{5, 4, 3, 2, 1}— 评估输出的整体质量
训练分两步:先用 GPT-4 生成反射标记的合成训练数据,训练一个 Critic 模型 :
然后用 Critic 标注的数据训练 Generator 模型 ,使其同时学会生成内容和反射标记:
效果:Self-RAG (7B) 在多个基准上超越了 ChatGPT 和带检索的 Llama 2-Chat (13B),且推理时无需外部 Critic,模型自身已具备反思能力。
AgentFlow 的 Flow-GRPO 训练范式也值得关注,它展示了只微调编排者,冻结执行者的精巧设计:
- 可训练:仅 Planner 模块(Qwen2.5-7B-Instruct),使用 PPO 强化学习
- 冻结:Executor、Verifier、Generator 均使用 GPT-4o-mini 等固定模型
- 结果:7B 参数的 AgentFlow 在多跳搜索和数学推理任务上超越了 GPT-4o
这说明了一个关键洞察:不是所有组件都需要微调。找到系统的瓶颈组件,针对性微调,往往比全面微调更高效。
评测体系
为什么评测很难
RAG 质量是多维的:
| 检索质量好 | 检索质量差 | |
|---|---|---|
| 生成质量好 | 系统优秀 | 生成鲁棒性强 |
| 生成质量差 | 生成能力弱 | 失败的系统s |
必须分别评估检索和生成,才能针对性优化
检索质量评测
| 指标 | 定义 | 适用场景 |
|---|---|---|
| Recall@k | 前 k 个结果中包含相关文档的比例 | 覆盖率优先场景 |
| Precision@k | 前 k 个结果中相关文档的比例 | 精确率优先场景 |
| MRR | 第一个相关文档排名倒数的均值 | 单答案检索 |
| NDCG@k | 考虑排名位置的归一化折损累计增益 | 多相关文档、排名质量 |
| Context Precision | 检索到的上下文中相关内容的比例 | RAGAS 框架核心指标 |
| Context Recall | 真实答案所需信息被检索到的比例 | RAGAS 框架核心指标 |
几个关键指标的数学定义:
精确率与召回率:
MRR(Mean Reciprocal Rank),衡量"第一个正确答案出现得有多快":
其中 是第 个查询的第一个相关文档的排名位置。如果第一个相关结果排在第 1 位,贡献 1/1 = 1;排在第 3 位,贡献 1/3 ≈ 0.33。
NDCG@k(归一化折损累计增益),是最精细的排名质量指标,不仅考虑相关不相关,还考虑有多相关:
其中 是位置 的文档相关性等级,IDCG@k 是理想排序下的 DCG(归一化基准)。分母中的 实现了"位置折损"—,排名越靠后,对总分的贡献越小。
精确率/召回率的权衡是真实的:检索更多块提高召回率但降低精确率。Context Recall 优先于 Precision,宁可检索多,不可漏关键信息。
生成质量评测
RAG 评测三角,三者缺一不可:
1 | 忠实度 |
| 指标 | 定义 | 注意点 |
|---|---|---|
| 忠实度(Faithfulness) | 生成答案是否与检索到的上下文一致,无幻觉 | 不要求答案正确,只要与上下文一致 |
| 答案相关性(Answer Relevancy) | 答案是否回答了用户的问题 | 不考虑是否基于上下文 |
| 完备性(Completeness) | 答案是否覆盖了问题所需的所有关键信息 | 评估信息遗漏 |
RAGAS 框架
RAGAS(检索增强生成评估)是 RAG 最广泛采用的自动化评估框架,使用 LLM-as-judge 实现上述指标。
1 | from ragas import evaluate |
局限性:依赖 LLM 进行评估,存在自评偏差;对长文档和多跳推理评测能力有限;计算成本较高(每次评测需多次 LLM 调用)。
其他评测工具
| 工具 | 特点 | 适用场景 |
|---|---|---|
| TruLens | RAG 三元组评估 + 可观测性追踪,可视化界面实时追踪每次 RAG 调用的三元分数 | 开发调试 |
| Arize Phoenix | 生产环境 LLM/RAG 可观测性平台,嵌入可视化、漂移检测、与 OpenTelemetry 集成 | 生产监控 |
| DeepEval | 支持 RAG 三元评估 + Agent 轨迹评估 | 生产环境综合评测 |
| ARES | 自动 RAG 评估框架,自动生成测试集 | 快速建立评测体系 |
全链路技术选型与工程实践
文档分块(Chunking)
分块质量是整个 RAG 系统的上限。一个顶级的生成器也无法弥补由糟糕分块带来的劣质上下文。Vectara 的研究表明,分块配置对检索质量的影响与嵌入模型的选择相当或更大。
推荐默认参数(已经基准验证)
| 参数 | 推荐值 | 来源 |
|---|---|---|
| 分块大小 | 512 tokens | FloTorch 2026 |
| 重叠 | 50–100 tokens(10–20%) | 行业共识,Microsoft Azure 建议 25% |
| 分块策略 | 递归字符分块(Recursive Character Splitting) | 零模型调用,成本低,准确率最高 |
不同场景的参数调整
| 场景 | 分块大小 | 策略 | 备注 |
|---|---|---|---|
| 事实性问答 | 256–512 tokens | 递归字符分块 | 短而精,命中率高 |
| 分析性/多跳问答 | 512–1024 tokens | 递归字符分块 | 需要更多上下文支撑推理 |
| 财务报告 | 1024 tokens | 页级分块 | 表格和数值上下文必须保持在一起 |
| 技术文档(Markdown/HTML) | 512 tokens/节 | 按标题切分 + 节内递归 | 尊重文档的层级结构 |
| 代码库 | 函数/类级别 | 语言感知切分(AST) | 不用固定 token 数 |
| FAQ/短文档 | 全文档不切 | 不分块 | 切分会破坏完整语义 |
分块策略对比基准数据
| 策略 | 端到端准确率 | Token 级召回率 | 模型调用 | 评价 |
|---|---|---|---|---|
| 递归字符分块 | 69% | 85% | 零 | 推荐默认 |
| 固定大小分块 | 67% | 82% | 零 | 简单但不如递归 |
| 页级分块 | 57.9% | — | 零 | 仅限分页明确的文档 |
| 语义分块 | 54% | 91.9% | 需要 | 召回高但准确率低 |
数据源自 We Benchmarked 7 Chunking Strategies on Real-World Data. Most ‘Best Practice’ Advice Was Wrong
语义分块的陷阱:它的 Token 级检索召回率高达 91.9%,看起来很强,但端到端回答准确率只有 54%,因为生成的碎片平均只有 43 tokens,丢失了太多上下文。如果使用语义分块,必须设置最小分块限制(200–400 tokens)。
"上下文悬崖"效应:分块超过约 2500 tokens 后,响应质量会显著下降,块太大,噪声会淹没信号。
处理文本分块已经很让人头疼了,一旦加入图片等多模态数据,系统的复杂度确实会大幅上升。与纯文本的切割逻辑不同,图片通常是一个不可分割的语义整体。目前业界在 RAG 管道中处理图片数据,主流的做法主要有以下两种路径:
1. 图转文(Image-to-Text / Captioning):在数据预处理阶段,调用视觉语言大模型(VLM,如 GPT-4V 或 Gemini 1.5 Pro),让模型为图片生成详尽的文本描述(Caption)或深度总结。将生成的文本描述连同图片前后的上下文文本合并,像普通文本一样切块、向量化并存入数据库。
2. 原生多模态嵌入:使用支持多模态的 Embedding 模型(如 OpenAI 的 CLIP 系列,或最新的商业级多模态 API),直接将图片本身和文本特征映射到同一个高维向量空间。图片直接作为独立的 Chunk 进行向量化。当用户输入文字查询时,系统可以在同一个空间内直接计算“文本-图片”的相似度。
嵌入模型(Embedding)选型
嵌入模型决定了语义理解的天花板,索引文档和编码查询必须使用同一个模型,更换意味着重新索引整个语料库。所以这个决定要慎重,一旦选定就是长期绑定。
2026 年主流嵌入模型对比
| 模型 | MTEB 分数 | 上下文长度 | 维度 | 成本(/M tokens) | 自托管 | 许可证 |
|---|---|---|---|---|---|---|
| Qwen3-Embedding-8B | 70.58 | 32K | 7168 (可调) | 免费 | ✅ | Apache 2.0 |
| NV-Embed-v2 | 69.32 | 32K | 4096 | 免费 | ✅ | CC-BY-NC ⚠️ |
| Gemini embedding-001 | 68.32 | 2K | 3072 | $0.15 | ❌ | 专有 |
| voyage-3-large | ~67+ | 32K | 2048 | $0.06 | ❌ | 专有 |
| Cohere embed-v4 | 65.2 | 128K | 1024 | $0.10 | VPC | 专有 |
| text-embedding-3-large | 64.6 | 8K | 3072 | $0.13 | ❌ | 专有 |
| BGE-M3 | 63.0 | 8K | 1024 | 免费 | ✅ | MIT |
| Jina embeddings-v3 | ~62+ | 8K | 1024 | $0.018 | ✅ | CC-BY-NC |
| all-MiniLM-L6-v2 | 56.3 | 512 | 384 | 免费 | ✅ | Apache 2.0 |
注意:MTEB 总分包含分类、聚类等任务。RAG 场景应重点关注 Retrieval 任务的 NDCG@10 分数。
五步选型决策框架
Embedding 模型选型决策树
向量数据库选型
六大主流向量数据库对比
| 数据库 | 类型 | 最大规模 | 混合检索 | 过滤能力 | 运维复杂度 | 成本效率 |
|---|---|---|---|---|---|---|
| Milvus/Zilliz | 开源+云 | 万亿级 | ⭐⭐⭐ | ⭐⭐⭐⭐ | 高(依赖 K8s) | 中 |
| Qdrant | 开源+云 | 十亿级 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 中 | 高 |
| Weaviate | 开源+云 | 亿级 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 中 | 中 |
| Pinecone | 云 SaaS | 十亿级 | ⭐⭐⭐ | ⭐⭐⭐⭐ | 极低 | 低(贵) |
| Chroma | 开源 | 百万级 | ⭐⭐ | ⭐⭐⭐ | 低 | 高 |
| pgvector | PG 扩展 | 千万–亿级 | ⭐⭐⭐ | ⭐⭐⭐⭐ | 低 | 最高 |
快速选型决策
| 你的情况 | 推荐 | 理由 |
|---|---|---|
| 不想管基础设施 | Pinecone | 全托管零运维 |
| 需要混合检索(向量 + BM25) | Weaviate / Qdrant | 原生融合向量与关键词搜索 |
| 十亿级向量,工业级规模 | Milvus / Zilliz | 存算分离,索引类型最全 |
| 快速原型,开发测试 | Chroma | pip install 即用 |
| 已有 PostgreSQL,不想加系统 | pgvector | 零额外基础设施成本 |
| 已有 Elasticsearch 生态 | ES kNN | 利用现有搜索引擎能力 |
多路召回与重排序(Recall → Coarse Rank → Fine Rank)
这是 RAG 系统中信噪比提升最大的环节。工业界已经形成了成熟的多阶段检索流水线:先用低成本方法广撒网(召回),再用高精度方法精挑细选(重排)。
三阶段流水线架构
多路融合策略
两种方式都好用,RRF 更稳健:
| 策略 | 公式 | 优势 | 适用场景 |
|---|---|---|---|
| 加权分数融合 | 简单直观 | 同类型检索器组合 | |
| RRF | , | 不依赖分数量纲 | 异构检索器组合 |
重排序模型选型
| 模型 | 类型 | 多语言 | 适用场景 |
|---|---|---|---|
| BGE-reranker-v2-m3 | 开源 | ✅ 100+ | 有 GPU 的多语言生产环境 |
| ms-marco-MiniLM-L-6 | 开源 | ❌ 仅英语 | 极速原型 / 英文场景 |
| ZeroEntropy zerank-2 | API | ✅ 100+ | 无 GPU + 多语言 |
| Cohere Rerank 3.5 | API | ✅ | 追求稳定性的企业 |
架构决策矩阵
| 知识库规模 | 推荐架构 | 是否需要重排 |
|---|---|---|
| < 10K 文档 | 单阶段向量检索 | 通常不需要 |
| 10K – 1M 文档 | 多路召回 + 重排 | 需要 |
| > 1M 文档 | 双塔召回 + 粗排 + 精排 | 必须 |
参考资料
基础论文
- Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
- Karpukhin et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020.
- Gao et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey.
Agentic RAG
- Singh et al. (2025). Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG. arXiv:2501.09136.
- Edge et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 微软研究院.
评测
- Es et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217.
- Wu et al. (2024). RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models. NeurIPS 2024.
进阶技术
- Gao et al. (2022). Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE). ACL 2023.
- Asai et al. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ACL 2024.
- Sarthi et al. (2024). RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. ICLR 2024.
- Yan et al. (2024). Corrective Retrieval Augmented Generation (CRAG). arXiv:2401.15884.
- Wei et al. (2024). InstructRAG: Instructing Retrieval-Augmented Generation via Self-Synthesized Rationales. arXiv:2406.13629.
- Lu et al. (2025). AgentFlow: In-the-Flow Agentic System Optimization for Effective Planning and Tool Use. arXiv:2510.05592.
RAG vs 微调
- Ranjan, Chembachere, Lobo (2025). Enhancing LLMs for Agentic AI: RAG vs. Fine-Tuning. Springer, Agentic AI in Enterprise.
内网资源
- [iWiki 4017211004] — RAG(检索增强生成)起源、演进与思考研究报告
- [iWiki 4018378951] — RAG 技术前沿共识与大厂战略定位分析报告(2025–2026)
- [iWiki 4018563918] — RAG(检索增强生成)评测深度调研报告
- [iWiki 4019012020] — 论文精读:Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
工具与基准
- BEIR: https://github.com/beir-cellar/beir
- MTEB 排行榜: https://huggingface.co/spaces/mteb/leaderboard
- GraphRAG: https://github.com/microsoft/graphrag
- RAGAS: https://github.com/explodinggradients/ragas
- TruLens: https://github.com/truera/trulens
- Arize Phoenix: https://github.com/Arize-ai/phoenix