你有没有遇到过这种情况：让大模型回答公司内部文档的问题，它要么编答案，要么说"我不清楚"？你花了几万块买的GPT-4 API，结果在业务场景里跟个摆设一样。

这就是大模型的两个致命缺陷：幻觉（一本正经胡说八道）和知识截止（不知道训练之后发生的事）。RAG（Retrieval-Augmented Generation，检索增强生成）就是来填这个坑的——先从你的文档里找到相关内容，再让模型基于这些内容回答，而不是凭记忆瞎编。

RAG是目前AI落地最成熟的方案，没有之一。企业知识库、智能客服、法律助手、医疗问答……底层全是RAG。今天这篇我把RAG的核心原理、三代架构演进、跟微调和长上下文的对比一次讲清楚，帮你建立正确的认知框架。

RAG到底在干什么？一个比喻秒懂

把RAG想象成开卷考试：

  • 闭卷考试（纯LLM）：靠脑子里的记忆答题，记不清就编

  • 开卷考试（RAG）：先翻资料找到相关内容，再基于资料作答

核心流程就四步：

<span leaf="">用户提问</span><br><span leaf="">&nbsp; &nbsp;↓</span><br><span leaf="">[1. 检索]：从知识库里找到跟问题最相关的文档片段</span><br><span leaf="">&nbsp; &nbsp;↓</span><br><span leaf="">[2. 增强]：把检索到的内容塞进提示词，跟问题一起给模型</span><br><span leaf="">&nbsp; &nbsp;↓</span><br><span leaf="">[3. 生成]：模型基于检索内容生成回答</span><br><span leaf="">&nbsp; &nbsp;↓</span><br><span leaf="">[4. 验证]：（可选）检查回答是否忠于检索内容</span><br>

就这么简单。但"简单"和"能用"之间隔着十万八千里——检索不准、切分不对、模型不按文档回答……每个环节都能让你的RAG从"智能助手"变成"人工智障"。

三代RAG架构演进：从能跑到好用

RAG从2023年到现在，经历了三代演进。搞清楚它们的区别，你才知道自己该用哪一代。

第一代：Naive RAG（能跑就行）

最朴素的实现：切块→向量化→Top-K检索→拼Prompt→生成。

<span leaf="">用户Query → 向量化 → 向量库检索Top-K → 拼接Prompt → LLM生成答案</span><br>

典型技术栈：

| 组件

|

常用方案

文档解析

|

LangChain DocumentLoader

| |

分块

|

RecursiveCharacterTextSplitter（512字符）

| |

Embedding

|

text-embedding-ada-002

| |

向量库

|

FAISS / Chroma

| |

生成

|

GPT-3.5 / GPT-4

|

致命问题：

  1. 固定分块破坏语义：按字符数切割，可能把一段完整的论述切成两半，检索到的chunk缺乏上下文

  2. 向量检索≠语义相关：向量相似度高不代表真正相关，“苹果手机"和"水果商店"向量可能很近

  3. Top-K塞太多噪音：召回10条文档，可能只有2条有用，其余8条反而干扰模型

  4. 无法处理复杂问题：问"对比A公司和B公司的Q4财报差异"这种跨文档推理问题，单次检索根本搞不定

第二代：Advanced RAG（精度提升）

在Naive RAG的三个环节分别加优化：

检索前优化（Pre-Retrieval）：

  • 查询改写：用户问"怎么退货”，改写成"退换货流程 退货条件 退货步骤"

  • 查询路由：判断问题该走知识库还是走搜索引擎

  • HyDE：让模型先猜一个答案，用答案去检索（猜的答案比原始问题检索效果更好）

检索中优化（Retrieval）：

  • 混合检索：向量检索+关键词检索（BM25），两路召回再融合

  • 细粒度检索：从文档级检索改为段落级、句子级

检索后优化（Post-Retrieval）：

  • Rerank重排序：用Cross-Encoder模型对检索结果精排

  • 上下文压缩：去掉检索结果中的冗余信息，减少Token浪费

  • 父文档检索：小块检索保精度，大块返回保语义

<span leaf="">用户Query → 查询改写 → 混合检索 → Rerank重排 → 上下文压缩 → LLM生成</span><br>

Advanced RAG是目前生产环境最主流的架构。如果你做企业RAG，至少要上这一代。

第三代：Modular/Agentic RAG（自主决策）

前两代都是固定流程——检索几次、怎么检索都是写死的。第三代让Agent自己决定：

  • 要不要检索：简单问题直接答，复杂问题才检索

  • 从哪里检索：知识库、数据库、API、搜索引擎，按需选择

  • 检索几次：单次不够就多轮检索

  • 检索结果够不够：不够就换个query再检

  • 结果对不对：自己验证，不对就修正

<span leaf="">用户Query → 查询规划 → 动态路由 → 多步检索 → 结果融合 → 自我修正 → LLM生成</span><br>

Agentic RAG是2025-2026年最受关注的方向，但说实话90%的Agentic RAG项目在生产中失败——不是技术不行，是太复杂了，出了问题你根本排查不过来。我建议先用Advanced RAG把基础打牢，再逐步引入Agent能力。

RAG vs 微调 vs 长上下文：到底选哪个？

很多团队纠结这个问题，我给你一张对比表：

| 维度

|

RAG

|

微调

|

长上下文

知识更新

|

实时（插入即生效）

|

慢（需重新训练）

|

实时（但受长度限制）

| |

领域适应

|

低（建知识库即可）

|

高（标注+训练）

|

低（但Token成本高）

| |

幻觉控制

|

强（答案可溯源）

|

中（仍可能编造）

|

弱（越长越容易编）

| |

私有数据

|

可控（本地部署）

|

有泄露风险

|

有泄露风险

| |

推理成本

|

低（轻量模型即可）

|

中（需专用模型）

|

极高（长上下文极耗算力）

| |

实现复杂度

|

中

|

高

|

低

|

我的建议：

  • 知识密集型场景（客服、法律、医疗）：RAG是首选，没有之一

  • 风格/格式定制（特定写作风格、输出格式）：微调

  • 简单问答（上下文不太长）：长上下文够用，不用上RAG

  • 复杂场景：RAG+微调组合拳——微调让模型学会"怎么回答"，RAG让模型知道"回答什么"

千万别搞混了：微调改的是模型的行为模式，RAG补的是模型的知识盲区。

RAG的四个核心指标

评估RAG效果，盯住这四个：

  1. 召回率（Recall）：该找到的文档，找全了没有？漏检=回答缺信息

  2. 精确率（Precision）：找到的文档，有多少是真正相关的？误检=干扰模型

  3. 忠实度（Faithfulness）：模型的回答是否忠于检索到的文档？不忠于=模型在编

  4. 回答相关性（Answer Relevancy）：回答是否直接解决用户的问题？答非所问=白搭

这四个指标分别对应RAG的四个环节：

| 环节

|

对应指标

|

出问题怎么办

切分

|

召回率

|

调整chunk_size、换分块策略

| |

检索

|

召回率+精确率

|

换Embedding、加混合检索、Rerank

| |

生成

|

忠实度

|

改提示词、换模型

| |

整体

|

回答相关性

|

改查询改写、优化检索策略

|

发现问题别瞎调，先定位是哪个环节的锅，再针对性优化。

80%的RAG项目问题出在哪里？

我帮十几个团队review过RAG系统，问题分布基本是这样的：

40%的问题出在文档处理：切分粒度不对、PDF解析丢表格、元数据没提取。这些是"地基"问题，地基没打好，上面再怎么优化都是空中楼阁。

30%的问题出在检索策略：纯向量检索不够用、没有Rerank、query没做改写。这些是"管道"问题，东西在那里但你找不到。

20%的问题出在提示词：没告诉模型"只基于检索内容回答"、没限制模型编造、没要求标注来源。这些是"最后一公里"问题。

10%的问题出在模型选择：模型能力不够（用太小的模型做复杂推理）或模型太大（简单问答用GPT-4纯属浪费）。

所以我的优化优先级永远是：先改文档处理→再调检索策略→再优化提示词→最后换模型。反过来做是很多团队效率低下的根源。

下篇预告

下一篇我专门讲RAG中文档处理和切分策略——这是整个RAG的地基，也是最容易出问题的地方。我会对比6种切分方式、讲PDF/Word/Markdown的解析技巧、给出不同场景的chunk_size推荐值。地基打好了，后面的检索和生成才有意义。