RAG：让大模型真正拥有外部知识

大语言模型很强，但它有一个非常明显的问题：它知道的东西，本质上受训练数据限制。

如果你问模型一个公开的、常见的问题，比如 TCP 为什么需要三次握手，它通常可以直接回答。

但如果你问：

• 我们公司最新的产品文档里，退款规则是什么？
• 这份 300 页的 PDF 中，第 72 页提到了什么？
• 今天刚刚更新的技术文档有什么变化？
• 根据我自己的知识库，给客户回答售后问题

单纯依靠大模型本身就不够了。

这时候就需要 RAG。

什么是 RAG

RAG 的全称是：

Retrieval-Augmented Generation

中文一般叫：

检索增强生成。

它的核心思想非常简单：

不要求大模型记住所有知识，而是在回答问题之前，先从外部知识库中找到相关信息，再让模型根据这些信息生成答案。

所以一个最基础的 RAG 可以理解成：

用户提问 → 检索资料 → 把资料交给大模型 → 生成答案

例如用户问：

公司的退款期限是多少天？

系统不会直接让模型猜，而是先去知识库里搜索相关内容，找到：

用户购买商品后，可在 7 天内申请退款。

然后把这段内容连同用户的问题一起发送给大模型。

模型最终回答：

根据公司的退款政策，购买后 7 天内可以申请退款。

这就是 RAG。

为什么需要 RAG

很多人第一次接触 RAG 时，会产生一个疑问：

既然大模型已经知道这么多东西，为什么还需要知识库？

因为模型本身存在几个无法避免的问题。

知识不是实时的

模型的训练存在时间截止点。

今天刚发布的公告、公司内部刚更新的文档、用户自己的私人数据，模型训练时根本不可能见过。

RAG 可以让模型使用最新的数据，而不需要重新训练模型。

大模型不知道私有数据

比如：

• 企业内部 Wiki
• 产品文档
• 客户资料
• 项目代码
• PDF
• 数据库

这些内容本身并不存在于模型的训练数据中。

通过 RAG，可以让模型在需要时读取这些数据。

减少幻觉

如果模型不知道一个问题的答案，它有时仍然会尝试生成一个看起来合理的答案。

这就是常说的：

Hallucination，幻觉。

RAG 给模型提供了真实的参考资料，相当于告诉模型：

不要完全靠记忆回答，先看看资料。

当然，RAG 并不能完全消灭幻觉，但可以明显降低幻觉出现的概率。

成本比重新训练低

如果公司有几万个文档，不可能每更新一次文档就重新训练一次模型。

RAG 只需要更新知识库。

模型本身不需要改变。

所以在企业 AI 应用中，RAG 是非常常见的一种方案。

一个完整的 RAG 是怎么工作的

真正的 RAG 并不是简单地“搜索一下，然后交给模型”。

一个比较标准的流程通常是：

文档 → Chunk → Embedding → Vector Database → Retrieval → Rerank → LLM

我们拆开来看。

Chunk：把文档切成小块

假设现在有一本 300 页的产品手册。

你不可能每次用户提问，都把整本书发送给模型。

这样不仅非常慢，而且会消耗大量 Token。

所以第一步通常是：

切分文档。

例如原始文档：

第一章 产品介绍
……

第二章 退款规则
购买商品后七天内可以申请退款……

第三章 售后服务
……

系统可能会把它拆成很多小段：

Chunk 1
第一章 产品介绍……

Chunk 2
退款规则：购买商品后七天内可以申请退款……

Chunk 3
售后服务……

这些小段就叫：

Chunk。

Chunk 的大小非常重要。

如果 Chunk 太大：

• 会带入大量无关信息
• 占用上下文
• 检索精度下降

如果 Chunk 太小：

• 上下文可能被切断
• 信息不完整

所以 RAG 中经常需要设计：

Chunk Size

以及：

Chunk Overlap

Overlap 就是让相邻的 Chunk 保留一部分重复内容，避免一句话正好被切成两半。

例如：

Chunk 1:
A B C D E

Chunk 2:
D E F G H

这里的 D、E 就是重叠区域。

Embedding：让计算机理解文本的语义

文档切成 Chunk 后，还有一个问题：

计算机应该怎么判断两个文本是否相似？

比如用户问：

商品买了以后多久还能退？

知识库里写的是：

用户购买商品后，可在七天内申请退款。

这两句话几乎没有完全相同的关键词。

但意思是一样的。

如果只是传统关键词搜索，可能无法很好地找到这段内容。

所以 RAG 通常会使用：

Embedding。

Embedding 可以把文本转换成一串数字。

例如：

"七天内可以退款"

↓

[0.12, -0.43, 0.87, 0.21, ...]

这串数字叫：

向量 Vector。

Embedding 模型会尽量让：

语义相似的文本，在向量空间中距离更近。

例如：

退款期限是多少？

商品多久可以退？

购买后七天可以退款

虽然文字不同，但它们生成的向量可能非常接近。

这样就可以进行：

语义搜索。

Vector Database：存储向量

Embedding 之后，每一个 Chunk 都会变成一个向量。

这些向量通常会存储在：

向量数据库 Vector Database

中。

常见的向量数据库包括：

• Milvus
• Qdrant
• Weaviate
• Pinecone
• Chroma

PostgreSQL 也可以通过 pgvector 支持向量检索。

向量数据库主要负责一件事情：

从大量向量中，快速找到和用户问题最相似的向量。

这个过程就叫：

Vector Search。

Retrieval：真正开始检索

当用户提出问题：

商品多久可以退款？

系统首先对这个问题进行 Embedding：

User Query

↓

Embedding

↓

Query Vector

然后拿这个向量去向量数据库中搜索。

数据库可能返回最相似的几个 Chunk：

Top 1:
商品购买后七天内支持退款

Top 2:
退款需要保留订单号

Top 3:
特殊商品不支持退款

这个过程就是：

Retrieval，检索。

通常系统不会只返回一条，而是返回：

Top K

例如：

Top K = 5

表示返回相似度最高的 5 个结果。

Rerank：重新排序检索结果

单纯依靠向量相似度并不一定可靠。

比如用户问：

苹果手机退款规则是什么？

向量数据库可能返回：

1. 苹果水果退款规则
2. 手机退款规则
3. Apple 产品退款规则
4. 苹果手机售后政策

这些内容在语义上都比较接近。

但真正最相关的可能是第四条。

所以很多 RAG 系统会增加一个步骤：

Rerank，重排序。

Rerank 模型会对：

Query + Document

重新进行相关性判断。

例如原来的搜索结果：

A
B
C
D

经过 Rerank 后可能变成：

D
C
A
B

然后系统只选择最相关的几个文档发送给大模型。

因此：

Embedding 负责快速找候选结果。

Rerank 负责更精确地挑结果。

两者解决的是不同的问题。

Generation：把资料交给大模型

完成检索之后，系统会构造 Prompt。

例如：

你是一个客服助手。

请根据以下资料回答用户问题。
如果资料中没有答案，请说明无法确定。

参考资料：

1. 商品购买后七天内可以申请退款。
2. 退款时需要提供订单号。

用户问题：

商品多久可以退款？

然后发送给 LLM。

LLM 最终回答：

商品购买后七天内可以申请退款。

注意这里有一个非常重要的区别：

答案不是数据库直接返回的。

数据库只是提供资料。

真正组织语言、理解问题、生成回答的仍然是：

LLM。

这就是为什么叫：

Retrieval-Augmented Generation

而不是单纯 Retrieval。

RAG 不等于向量数据库

这是一个面试中非常容易被问到的问题。

很多人会把：

RAG = 向量搜索

实际上这是不准确的。

向量搜索只是 RAG 中的一种检索方式。

完整的 RAG 是：

检索 + 上下文构建 + LLM 生成。

甚至 Retrieval 也不一定必须使用向量数据库。

例如还可以使用：

• BM25
• Elasticsearch
• SQL 查询
• Knowledge Graph
• Web Search

甚至可以组合多种检索方式。

所以更准确地说：

RAG 是一种让模型在生成回答之前先获取外部信息的架构。

向量数据库只是实现 Retrieval 的一种常见工具。

Semantic Search 和关键词搜索

传统搜索通常依赖关键词。

例如搜索：

退款

系统会寻找包含“退款”这个词的内容。

这种方式非常快，而且对于：

• 产品型号
• 人名
• ID
• 专有名词

这类精确搜索效果很好。

但如果用户问：

买了以后不想要了怎么办？

这里甚至没有出现“退款”两个字。

关键词搜索就可能效果不好。

Embedding 搜索则可以理解这句话和“退款”在语义上有关。

所以现实中的 RAG 经常不会只使用一种搜索方式。

而是采用：

Hybrid Search，混合搜索。

例如：

BM25
+
Vector Search

这样既可以利用关键词的精确性，也可以利用向量搜索的语义理解能力。

RAG 最大的问题其实是 Retrieval

很多人做 RAG 时会把注意力放在：

用 GPT-5 还是 Claude？

但很多时候，真正决定 RAG 效果的不是模型。

而是：

检索质量。

因为如果检索出来的资料就是错的：

错误资料
↓
LLM
↓
错误答案

再强的模型也很难回答正确。

这就是一个非常重要的原则：

Garbage In, Garbage Out。

垃圾进去，垃圾出来。

所以做 RAG 时真正需要优化的是：

• Chunk 策略
• Embedding 模型
• Query Rewrite
• Hybrid Search
• Top K
• Rerank
• Metadata Filter
• Context 构建

这些部分。

Query Rewrite

用户的问题通常并不适合直接搜索。

例如用户问：

那它去年怎么样？

对于聊天上下文来说，我们可能知道：

“它”指的是某家公司。

但直接拿：

那它去年怎么样

去向量数据库搜索，效果会非常差。

所以系统可以先让模型把 Query 改写成：

BetterYeah 2025 年产品发展情况

这一步叫：

Query Rewrite。

甚至可以把一个复杂问题拆成多个 Query。

例如：

对比 A 公司和 B 公司去年的营收和利润。

可以拆成：

A 公司 2025 年营收
A 公司 2025 年利润
B 公司 2025 年营收
B 公司 2025 年利润

分别搜索。

这样检索效果往往会明显提高。

Metadata Filter

RAG 里还有一个非常实用的东西：

Metadata。

例如一个 Chunk 除了正文之外，还可以保存：

{
  "title": "退款政策",
  "department": "售后",
  "year": 2026,
  "version": "v3"
}

如果用户问：

2026 年的退款规则是什么？

系统就可以先过滤：

year = 2026

然后再进行向量搜索。

这样比直接在整个知识库中搜索更加准确。

RAG 和 Agent 是什么关系

RAG 本身并不一定是 Agent。

一个普通 RAG：

用户问题
↓
检索
↓
生成

整个流程基本是固定的。

而 Agent 通常可以自己决定：

是否搜索
↓
搜索什么
↓
是否继续搜索
↓
调用什么工具
↓
是否需要重新规划

例如一个 Research Agent 可能执行：

用户问题
↓
Planning
↓
Search
↓
Evaluate
↓
证据不足
↓
继续 Search
↓
Rerank
↓
Generate

这时候 RAG 就变成了 Agent 的一个能力。

可以理解为：

RAG 解决“从哪里找知识”。

Agent 解决“下一步应该做什么”。

在很多 AI Agent 系统中：

RAG 本质上就是 Agent 可以调用的一个 Retrieval Tool。

Naive RAG

最简单的 RAG 通常就是：

Document
↓
Chunk
↓
Embedding
↓
Vector DB
↓
Top K Search
↓
LLM

这种架构一般叫：

Naive RAG。

它适合简单知识库问答。

但当数据量变大、问题变复杂后，就可能出现很多问题。

例如：

用户问：

2024 年和 2025 年公司收入分别是多少？

但两个年份的数据可能分别位于不同文档。

一次 Top K 搜索不一定可以把两个答案都找出来。

于是就出现了更复杂的 RAG 架构。

例如：

• Advanced RAG
• Modular RAG
• Agentic RAG

Agentic RAG

Agentic RAG 的核心变化是：

Retrieval 不再是一次固定操作，而变成一个可以不断决策的过程。

例如：

Question
↓
Search
↓
Evaluate
↓
信息够吗？

如果够：

Generate

如果不够：

Rewrite Query
↓
Search Again
↓
Evaluate

直到达到停止条件。

这实际上已经非常接近 Agent 的：

Loop Engineering。

所以现代复杂 Agent 中，RAG 往往已经不再只是：

向量数据库 + LLM

而是一个完整的信息获取系统。

RAG 的核心评价指标

如果需要真正评估一个 RAG 系统，通常可以拆成两部分。

第一部分：

Retrieval 是否正确。

例如：

用户的问题对应正确答案位于 Document A。

那么检索系统有没有把 Document A 找出来？

可以关注：

• Recall
• Precision
• Hit Rate
• MRR
• NDCG

第二部分：

Generation 是否正确。

也就是模型有没有正确使用检索出来的资料。

可以关注：

• Faithfulness
• Answer Relevance
• Context Relevance

其中一个非常重要的指标是：

Faithfulness。

也就是：

模型的回答是否真的来自提供的 Context，而不是自己编的。

对于企业 RAG 来说，这一点尤其重要。

一个真正可用的 RAG

如果只是学习 Demo，可以写：

PDF
↓
Chunk
↓
Embedding
↓
Chroma
↓
Similarity Search
↓
LLM

几十行代码就可以跑起来。

但如果要做真正可用的 RAG 系统，就需要考虑更多问题：

Document Parsing
↓
Cleaning
↓
Chunking
↓
Embedding
↓
Indexing
↓
Hybrid Search
↓
Query Rewrite
↓
Metadata Filter
↓
Rerank
↓
Context Compression
↓
LLM
↓
Citation
↓
Evaluation

这也是为什么：

RAG 看起来简单，但做好很难。

真正困难的通常不是“接一个向量数据库”。

而是：

怎么保证在几十万甚至几百万条数据中，每次都能够找到真正有用的信息。

最后理解 RAG

理解 RAG 最简单的方法，就是记住一句话：

大模型负责思考和生成，Retrieval 负责给它提供知识。

所以完整流程可以压缩成：

用户问题
↓
理解问题
↓
搜索外部知识
↓
筛选相关资料
↓
加入 Context
↓
LLM 生成答案

其中最基础的 RAG 是：

Chunk
→ Embedding
→ Vector Search
→ LLM

而更加成熟的 RAG 会继续加入：

Query Rewrite
Hybrid Search
Metadata Filter
Rerank
Evaluation
Agent Loop

最终，RAG 解决的并不是：

“如何让模型记住更多知识”。

而是：

“如何让模型在需要的时候，找到正确的知识。”