RAG 的原理与完整链路：检索、重排、生成

RAG 已经成为 AI 面试里最常见的系统设计题之一。因为今天很多企业级大模型应用，本质上都不是“从零训练一个模型”，而是“让一个通用模型会查公司自己的知识库”。

如果只用一句话概括：

RAG = Retrieval-Augmented Generation，先检索，再生成。

但真正高质量的面试回答，不能只说“查知识库再喂给模型”，而要讲清：

为什么需要 RAG
它的完整链路是什么
各环节为什么会出错
如何优化召回、重排、上下文构造和生成效果

一、先理解：RAG 解决了什么问题？#

大语言模型很强，但它有几个天然问题：

知识截止
幻觉（Hallucination）
很难引用企业私有知识
更新知识成本高
回答缺少可追溯来源

例如你问一个通用大模型：

“我们公司 2026 年新的报销制度是什么？”

它大概率回答不了，因为：

这个知识不在预训练数据里
或者根本是公司内部私有知识

如果强行让模型“猜”，就容易幻觉。

RAG 的思路就是：

不要求模型把所有知识都记在参数里，而是让它在回答前，先去外部知识库里找资料。

二、RAG 的基本思想：参数记忆 + 外部记忆#

RAG 最初的论文强调一个关键点：

模型参数内部是 parametric memory（参数记忆）
外部知识库是 non-parametric memory（非参数记忆）

也就是说，RAG 不是让模型“重新学知识”，而是：

让模型在生成前，临时读取外部知识。

这带来几个直接好处：

知识更新更快
回答更可追溯
更适合私有数据
不一定要重新微调模型

三、RAG 的整体架构#

RAG 的典型结构图如下：

RAG architecture

你可以把它抽象成 5 个核心阶段：

文档准备
索引构建
查询召回
重排与上下文构造
LLM 生成

真正面试里，核心不是背定义，而是把这 5 步讲明白。

四、第一步：文档准备#

RAG 的上限，很多时候并不在模型，而在文档准备。

典型数据来源包括：

公司内部知识库
产品文档
Wiki
FAQ
PDF
数据库导出的结构化信息
客服记录

4.1 为什么不能直接把整篇文档塞进去？#

因为：

太长
上下文窗口有限
检索粒度太粗
很容易召回一大段不相关内容

所以文档通常要先做：

清洗
去噪
分段（chunking）
元数据标注

4.2 Chunk 切分为什么重要？#

如果切得太大：

一次召回信息太杂
噪声多

如果切得太小：

上下文不完整
容易把答案拆散

所以 chunk 的边界设计，常常直接影响召回质量。

常见切分方法：

按固定长度切分
按段落/标题切分
按语义切分
滑动窗口切分

五、第二步：向量化与索引构建#

文档切好之后，下一步是把它们转换成向量。

5.1 Embedding 是什么？#

Embedding 模型会把一段文本映射成一个高维向量，使得：

语义相近的文本
在向量空间里更接近

例如：

“退款规则”
“退费政策”

在词面不同，但语义接近，向量也会更接近。

5.2 为什么要建向量索引？#

因为文档可能非常多：

几万条
几百万条
上亿条

如果每次查询都全量暴力比对，成本太高。

所以通常会放进向量数据库或 ANN 索引中，例如：

FAISS
Milvus
Weaviate
Pinecone
pgvector

这一步的目标是：

让系统能够快速找到和问题语义最相关的 Top-K 文档。

六、第三步：查询召回（Retrieval）#

用户输入一个问题后，RAG 并不是直接让 LLM 回答，而是先走检索。

例如问题：

“员工出差住宿报销上限是多少？”

典型流程：

对问题做 embedding
去向量库搜索最相近的文档块
返回 Top-K 候选 chunk

6.1 召回为什么不是越多越好？#

很多人会觉得：

“多召回一点总没错吧？”

其实不是。

召回太多会带来：

噪声增加
上下文被冲淡
Token 成本上升
模型注意力分散

所以 RAG 的难点不只是“召回得到”，而是：

召回到最有用的那几段。

七、第四步：为什么很多系统还要重排（Rerank）？#

向量召回能找出“语义接近”的内容，但不一定能保证“最适合当前问题回答”。

因此很多工业级 RAG 会加一个重排阶段。

7.1 召回和重排的分工#

召回：快速缩小候选范围
重排：更精细地判断哪些文档最相关

7.2 为什么要重排？#

因为 embedding 相似度只是一种粗粒度判断。

它可能会出现：

语义相近但并不回答问题
关键词匹配但缺少核心事实
旧版本文档得分过高

重排模型通常会更精细地看：

Query 和 chunk 的相关性
答案覆盖度
语义匹配强度

所以很多高质量 RAG 流程其实是：

粗召回 + 精重排

八、第五步：上下文构造（Context Construction）#

拿到 Top-K 文档后，并不是简单拼接就结束了。

还要考虑：

文档顺序
截断策略
来源标注
去重
结构化模板

例如：

1
你是一个企业知识库助手。请严格基于以下资料回答：
2

3
[文档1]
4
...
5

6
[文档2]
7
...
8

9
用户问题：
10
...

这一步看起来像 Prompt 工程，但其实是 RAG 非常关键的工程细节。

上下文构造得不好，会导致：

模型忽略关键片段
相关证据被噪声淹没
回答不稳定

九、第六步：生成（Generation）#

到这一步，LLM 才真正开始回答。

此时模型输入通常包含：

系统提示词
用户问题
检索文档
可能还有历史对话

模型的作用不再是“凭空想答案”，而是：

基于检索到的上下文做理解、整合、归纳、生成。

这也是为什么 RAG 往往比裸模型更稳定：

回答更有依据
幻觉概率更低
更适合私有知识问答

十、RAG 为什么常常比“直接微调”更合适？#

这是 AI 面试里非常常见的一道追问。

10.1 微调解决的是“行为模式”#

微调更适合：

输出风格
任务格式
指令遵循
领域表达方式

10.2 RAG 解决的是“知识接入”#

RAG 更适合：

频繁更新的知识
私有文档
需要引用依据的问答
企业知识库场景

10.3 为什么很多场景优先做 RAG？#

因为重新微调模型：

成本高
更新慢
不容易追溯来源
容易把知识“写死”进参数

而 RAG 的优势是：

更新文档就能更新知识
不一定动模型参数
能展示引用来源

所以很多真实产品的路线是：

先 RAG，必要时再微调。

十一、RAG 最常见的失败点有哪些？#

真正懂 RAG 的回答，一定要能说出它为什么会失败。

11.1 召回错了#

如果召回阶段就没找到正确文档，后面模型再强也没用。

11.2 文档切分不合理#

答案被切碎、上下文断裂，会直接影响召回和生成。

11.3 噪声太多#

召回了很多“相关但没用”的内容，模型会被干扰。

11.4 Prompt 构造不好#

即使召回正确，如果提示词不强调“必须基于文档回答”，模型仍然可能幻觉。

11.5 上下文窗口不足#

如果放入太多 chunk，关键内容可能被截断或被注意力稀释。

11.6 文档过时#

如果知识库本身没更新，RAG 也会输出过期答案。

十二、工业级 RAG 常见优化方向#

12.1 Hybrid Search#

把：

向量检索
关键词检索（BM25）

结合起来。

这样既能处理语义相近，也能处理精确关键词问题。

12.2 Query Rewrite#

先让模型把用户问题改写得更适合检索。

例如：

补全上下文
去掉歧义
拆成多个子问题

12.3 Multi-hop Retrieval#

复杂问题往往不是一次检索就够，需要多跳推理、多次检索。

12.4 Rerank#

在 Top-K 候选中进一步提高相关性排序质量。

12.5 Citation / Grounding#

要求模型在回答中显示引用来源，提高可追溯性和可信度。

12.6 Evaluation#

RAG 不能只看用户“感觉还行”，要建立评估指标，例如：

命中率
召回率
NDCG
回答正确率
引用覆盖率
幻觉率

十三、RAG 适合哪些场景？#

非常适合：

企业知识库问答
客服助手
法律 / 医疗文档问答
技术文档问答
内部 SOP 查询
多文档总结

不太适合纯靠实时检索就能解决的场景时，也要小心：

强逻辑推理任务
需要复杂长链决策的工作流
完全结构化数据库查询型任务

这些场景可能要结合：

Agent
SQL 查询
工具调用

一起做，而不只是单一 RAG。

十四、面试里怎么回答“RAG 的原理与完整链路”？#

建议按这个结构回答：

第一步：先讲定义#

RAG 是 Retrieval-Augmented Generation，即在生成前先从外部知识库检索相关文档，再把检索结果作为上下文提供给大模型生成答案。

第二步：讲完整链路#

文档清洗与切分
文档向量化
建立向量索引
用户问题向量化
Top-K 召回
重排
上下文构造
LLM 生成答案

第三步：讲为什么有效#

它能把模型参数记忆和外部知识库结合起来，降低幻觉、支持私有知识、便于知识更新和来源追踪。

第四步：讲难点#

难点不在“把文档塞给模型”，而在：

chunk 如何切
召回是否准确
是否需要重排
上下文怎么拼
怎么评估效果

这样回答，就不只是“知道概念”，而是具备系统设计视角。

十五、总结#

RAG 的本质，不是给 LLM “外挂一个搜索框”这么简单，而是构建一条完整的知识增强链路：

把外部知识转成可检索索引
在回答前召回相关证据
把证据和问题一起交给模型生成

所以真正准确的总结是：

RAG 解决的不是“模型不够聪明”，而是“模型参数不适合承载频繁变化、私有且可追溯的知识”。