---

RAG 全面解析：为什么大模型离不开"外挂记忆"

一、你有没有遇到过这种情况？

想象一下这个场景：

你兴冲冲地打开 ChatGPT，问它：“我们公司最新的报销流程是什么？” 它不慌不忙地给了你一个听起来非常合理的答案——但你越看越不对劲，因为那根本不是你们公司的规定，甚至你们公司压根就没有这个部门。

或者你问它：“这个行业今年 Q1 的最新数据是多少？” 它依然言之凿凿——给了你两年前的数字。

这不是 ChatGPT 在"耍你"，这是大型语言模型（LLM）的结构性局限：

1. 知识截止日期：模型训练完成后，世界继续转，但模型的知识冻结了
2. 无法访问私有数据：你的公司文档、内部系统、私人笔记，模型完全不知道
3. 幻觉（Hallucination）：当模型不知道答案时，它倾向于"编"一个听起来合理的答案，而不是说"我不知道"

RAG（Retrieval-Augmented Generation，检索增强生成） 就是为了解决这三个问题而生的。它不是让模型"变聪明"，而是给模型配了一套"查资料的系统"——让它在回答前先翻书，而不是全凭记忆。

---

二、什么是 RAG？

一个考试类比，让你秒懂

先不说技术，说一个你一定经历过的场景：

没有 RAG 的大模型 = 闭卷考试
它只能凭自己训练时"背下来"的内容作答。考试范围以外的，或者训练集里没有的，它要么答错，要么胡编。

有 RAG 的大模型 = 开卷考试
它可以在答题前，先去翻参考资料，找到和问题最相关的段落，然后综合资料给出有据可查的答案。

这个类比几乎就是 RAG 的全部精髓了。

RAG 的全名和三步骤

RAG 全称 Retrieval-Augmented Generation，直译是"检索增强生成"，2020 年由 Meta AI 研究院在论文中正式提出，此后迅速成为 LLM 落地应用最重要的技术范式之一。

整个流程拆成三个动词就能说清楚：

Retrieve（检索）→ Augment（增强）→ Generate（生成）

1. 检索（Retrieve）：根据用户的问题，从外部知识库里找出最相关的文档片段
2. 增强（Augment）：把检索到的内容塞进 Prompt，作为模型回答的上下文参考
3. 生成（Generate）：模型结合参考资料和问题，生成最终答案

RAG 解决的三大问题

问题	RAG 的解法
知识过期	知识库随时更新，不需要重新训练模型
私有数据无法访问	把私有文档建成向量库，检索时动态调用
幻觉风险高	有真实文档来源，答案可追溯、可验证

---

三、RAG 的工作原理

3.1 完整流程：两个阶段

RAG 的整个系统分为 离线阶段 和 在线阶段 两个部分，理解这两个阶段，你就理解了 RAG 的骨架。

---

离线阶段：把文档"喂"进去

这个阶段发生在用户提问之前，是一次性（或定期更新）的数据准备工作。

第一步：文档加载（Document Loading）

支持 PDF、Word、Markdown、网页、数据库、Excel……几乎任何形式的文档都可以作为知识来源。LangChain 提供了上百种 Document Loader，一行代码就能把一个 PDF 加载进来。

第二步：文档切块（Chunking）

为什么不直接把整篇文档喂给模型？因为：

• 文档可能有几百页，远超模型的上下文窗口限制
• 把整篇文档都检索出来会引入大量无关噪声
• 精准的小块比模糊的大块更有利于语义匹配

所以需要把文档切成小片段（Chunk）。每个 Chunk 通常是 200～1000 个 token，具体大小取决于场景。

第三步：向量化（Embedding）

这是 RAG 最核心、也最"魔法"的一步。

什么是 Embedding（向量化）？

简单说：把文字转成一串数字（向量），让计算机能"理解"语义的相似性。

用一个空间坐标的比喻来理解：

想象每一段文字都是宇宙中的一个星球，语义相近的文字，它们的"星球"距离更近。"苹果"和"水果"可能在同一个星系，而"苹果"和"量子力学"则相距数光年。

Embedding 模型就是这个"宇宙坐标测量仪"——它把每一段文字映射到一个高维空间中的坐标点，语义越相近，坐标越靠近。

第四步：存入向量数据库（Vector Database）

把所有 Chunk 的向量存进专门的向量数据库，等待查询时被检索。

---

在线阶段：用户提问时的实时检索

第一步：用户提问

用户输入问题，比如"我们公司的差旅报销政策是什么？"

第二步：问题向量化

用同一个 Embedding 模型，把用户的问题也转成向量。

第三步：向量相似度搜索

在向量数据库里，找出和问题向量"最近"的若干个文档 Chunk（通常取 Top-K，比如 Top-3 或 Top-5）。

第四步：组装 Prompt

把检索到的文档片段 + 用户原始问题，拼装成一个完整的 Prompt，类似于：

参考以下内容回答问题：

[检索到的文档片段 1]
[检索到的文档片段 2]
[检索到的文档片段 3]

用户问题：我们公司的差旅报销政策是什么？

第五步：大模型生成答案

模型读取参考资料后，给出有据可查的最终答案。

---

3.2 向量相似度是什么？

你可能会问：向量数据库怎么知道哪个 Chunk"最相关"？

答案是 余弦相似度（Cosine Similarity）。但不需要理解数学公式，只需要理解这个直觉：

两个向量在高维空间中的"方向"越一致，它们的语义就越相近。
就像两个人面朝同一个方向走路，他们的"意图"更接近；而一个朝东走、一个朝西走的人，目标截然不同。

"差旅报销政策"这个问题，和文档里"员工出差报销规定"这一段的向量方向会非常接近——即使它们用的词不完全相同，但"意图"相似，向量方向就相近，余弦相似度就高。

这正是向量检索相比传统关键词搜索的优势：语义匹配，而非字面匹配。

---

3.3 主流向量数据库

数据库	定位	特点
Chroma	本地/轻量	零配置，适合开发测试，Python 原生支持
Pinecone	云端托管	全托管，生产级，开箱即用
Weaviate	开源全能	功能丰富，支持混合检索，社区活跃
Milvus	大规模开源	阿里开源，十亿级向量，高性能
pgvector	PG 插件	直接在 PostgreSQL 里加向量能力，适合已有 PG 用户

作者提示：如果你是第一次做 RAG 项目，强烈推荐从 Chroma 开始。本地运行，无需任何配置，5 分钟就能跑起来一个最小可用的 RAG demo。

---

四、RAG 的核心组件拆解

4.1 文档切块策略

切块看起来简单，但这往往是影响 RAG 效果最被低估的环节。

固定大小切块（Fixed Size Chunking）

最简单的方式：每 N 个字符切一刀，不管内容是否完整。

• 优点：实现简单，速度快
• 缺点：可能在句子中间切断，破坏语义完整性

递归字符切块（Recursive Character Splitting）

LangChain 的默认策略，按照段落 → 句子 → 词语的优先级递归切割，尽量保证每个 Chunk 在语义上是完整的。这是目前最推荐的通用切块方式。

语义切块（Semantic Chunking）

按文档的自然结构（章节、段落、标题）切块。对于结构清晰的文档（如产品手册、技术规格书），效果很好。

重叠切块（Chunk Overlap）的重要性

想象你在读一本书，每次只能看一页，但两页之间会重复最后一段。这样即使关键信息跨越了"切块边界"，你也不会漏掉它。

一个典型的切块示例代码：

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,      # 每块最多 500 个字符
    chunk_overlap=50,    # 相邻块重叠 50 个字符
    separators=["\n\n", "\n", "。", "！", "？", " ", ""]
)
chunks = splitter.split_documents(documents)

---

4.2 Embedding 模型选择

模型	提供方	维度	特点
text-embedding-3-small	OpenAI	1536	性价比最高，推荐首选
text-embedding-3-large	OpenAI	3072	英文最强，但成本更高
bge-large-zh	BAAI（北京智源）	1024	中文场景最强开源模型
bge-m3	BAAI	1024	支持多语言，稀疏+密集混合
nomic-embed-text	Nomic AI	768	本地部署友好，效果出色

提示：做中文 RAG 系统，优先考虑 bge-large-zh 或 bge-m3。OpenAI 的 Embedding 模型对中文支持也不错，但如果数据敏感不想走 API，BAAI 的开源模型是最佳替代。

---

4.3 检索策略

密集检索（Dense Retrieval）

就是前面讲的向量相似度检索。优点是能捕捉语义相似性，缺点是对专有名词、型号、代码等"精确词汇"匹配能力弱。

稀疏检索（Sparse Retrieval）

传统的 BM25 关键词匹配算法。优点是对精确词汇匹配效果极好，缺点是不懂语义。

混合检索（Hybrid Search）

把密集检索和稀疏检索的结果合并，再用 RRF（倒数排名融合） 等算法综合排序。这是目前效果最好的检索策略，大多数生产系统都用这个。

重排序（Reranking）

检索完成后，用一个专门的 Cross-Encoder 模型 对 Top-K 结果重新精排，过滤掉"看起来相关但实际上关联度低"的结果。

初步检索（召回 Top-20）→ Reranker 精排 → 保留 Top-3 → 送给 LLM

---

五、RAG 的进化：从 Naive RAG 到 Advanced RAG

5.1 Naive RAG（基础版）的问题

Naive RAG 指的是最直接、最简单的实现：问题向量化 → 相似度检索 → 拼 Prompt → LLM 生成。

它的问题主要有四个：

1. 用户问题描述不清：用户可能问"那个什么政策"，这种模糊问题直接去检索，找不到准确内容
2. 检索质量不稳定：有时检索到的内容和问题高度相关，有时则风马牛不相及
3. 上下文窗口限制：Top-K 的内容如果太多，超过模型的上下文长度就会被截断
4. 文档和问题描述方式不一致：文档里写"报销金额上限"，用户问"最多能报多少钱"，向量距离可能不够近

5.2 Advanced RAG 的优化方向

查询优化（Query Enhancement）

HyDE（假设文档嵌入，Hypothetical Document Embedding）

与其直接用"问题"去检索"答案"（两者向量空间差异较大），不如先让 LLM 生成一个假设的答案，再用这个假设答案去检索真实文档。
因为"假设答案"和"真实文档"在向量空间里更接近，检索效果更好。

Query Rewriting（查询改写）

让 LLM 先把用户的问题改写成更适合检索的形式。例如：

• 原始问题：“那个 Q1 的数据怎么样？”
• 改写后：“2025 年第一季度的销售业绩数据”

Multi-Query（多角度查询）

对于复杂问题，让 LLM 生成 3～5 个不同角度的子问题，分别检索，再合并结果。覆盖面更广，不容易漏掉关键信息。

---

检索优化

父文档检索（Parent Document Retriever）

解决一个矛盾：切块越小，语义越精准；但上下文越少，模型越难理解。

解法：检索小块，返回大块。把文档切成小块用于精准匹配，但检索到小块后，返回它所属的大块（父文档）给 LLM。

Self-Query（自我查询）

让 LLM 自动解析用户问题，生成元数据过滤条件。例如用户问：“2024 年之后发布的关于 RAG 的论文”，模型自动提取 date > 2024 的过滤条件，大幅提升精度。

---

后处理优化

Contextual Compression（上下文压缩）

检索到的文档片段里，可能只有几句话是真正有用的，其余都是噪声。Contextual Compression 用 LLM 自动过滤和压缩检索结果，只保留和问题最相关的部分。这样不仅节省 token，还能让模型更专注于真正有用的信息。

---

5.3 Modular RAG（模块化 RAG）

这是最新的研究方向。

研究者发现，RAG 的每个组件——检索器、生成器、重排序器、查询改写器——都可以被独立替换和组合。就像搭积木一样，根据不同场景选择不同模块，而不是一套固定的流程。

这种设计让 RAG 系统更灵活、更可扩展，也让学术界能更系统地研究每个组件对最终效果的贡献。

---

六、RAG vs 微调（Fine-tuning）：该选哪个？

这是很多工程师和产品经理最常问的问题。

维度	RAG	Fine-tuning（微调）
知识更新	实时，改文档即可	需要重新收集数据、重新训练
私有数据安全	数据留在本地向量库	数据进入训练过程
成本	低（主要是推理时的检索开销）	高（GPU 训练费用不菲）
准确性来源	外部文档，可引用来源	模型权重，不可溯源
上手难度	中等（需要搭建检索链路）	高（需要数据准备、训练调优）
适合场景	知识库问答、文档分析、实时信息	特定写作风格、专业能力培养
幻觉风险	低（有文档依据）	较高（知识融入权重，难以校验）

一句话概括：RAG 给模型"外挂知识"，微调给模型"改造大脑"。

大多数企业知识库场景，RAG 是首选：成本低、可解释、安全性高、更新方便。

微调更适合这些场景：

• 让模型学会特定的"说话方式"（比如客服品牌语气）
• 培养特定的专业推理能力（比如医学诊断逻辑）
• 处理大量结构化、格式化的输出任务

作者提示：很多时候你不需要"二选一"。RAG + 少量微调的组合拳是当前企业 AI 应用的最佳实践：微调让模型懂你的语气和风格，RAG 让模型用你的数据。

---

七、RAG 的实际应用场景

RAG 不是一个学术玩具，它今天已经运行在大量真实系统里。

企业内部知识库

这是 RAG 最典型的应用。把 HR 手册、产品文档、技术规范、运营 SOP 全部向量化，员工可以直接用自然语言提问，得到有依据的精准回答。再也不用在 Confluence 里翻半天找不到那篇文档。

法律 / 医疗助手

法律和医疗领域有海量专业文档——法规条款、判例库、医学指南、药品说明书。RAG 让 AI 助手能够引用具体条款给出建议，而不是凭空生成一个"听起来像那么回事"的答案（在这两个领域，幻觉的代价极高）。

智能客服

将产品 FAQ、用户手册、历史工单全部建成知识库。客服机器人在回答前先检索相关内容，给出准确、有依据的解答，实在不知道再转人工。

代码助手

把整个代码仓库的文档、注释、API 说明向量化，让代码助手真正"了解"这个项目的上下文，而不只是靠通用编程知识瞎猜。

研究助手

上传数十篇论文，让 AI 帮你快速梳理研究现状、找出不同论文的共同观点和分歧，对比各方法的优劣。文献综述的效率可以提升 10 倍。

---

八、RAG 的局限性与未来

当前局限

任何技术都不是银弹，RAG 也有它解决不好的问题：

• 检索质量瓶颈：文档本身写得很烂，或者切块策略不当，检索出来的内容就是噪声——垃圾进垃圾出
• 多跳推理弱：需要跨多个文档联合推理的问题，基础 RAG 难以处理
• 多模态支持有限：处理图表、图片、复杂 PDF 表格时效果仍然较差
• 实时性依赖更新机制：知识库需要配套的文档更新流程，不然会出现"明明更新了政策，但 AI 还是说旧的"这种问题

未来方向

Graph RAG（知识图谱增强）

把文档中的实体和关系抽取出来，构建知识图谱，检索时沿着关系边游走，而不仅仅是找相似文本。对于复杂推理和多跳问答，效果远超传统向量检索。微软的 GraphRAG 和 LightRAG 都是这个方向的代表项目。

Agentic RAG（主动检索）

让 AI 像一个"主动调研的研究员"，而不是被动地等用户问一个问题、检索一次。Agent 可以自主决定"我还需要查什么"，进行多轮迭代检索，直到信息足够充分再生成答案。

长上下文模型的冲击与共存

随着 Gemini 1.5 Pro、Claude 3.5 等模型的上下文窗口扩展到 100K～1M token，一个自然的问题是：干脆把所有文档都塞进上下文，还需要 RAG 吗？

答案是：需要，但形态会变化。长上下文解决不了延迟、成本和超大规模文档库的问题，而且"大海捞针"在超长上下文里的准确性仍然不稳定。RAG 和长上下文不是替代关系，而是互补关系，未来的系统大概率是两者的有机结合。

---

九、总结

回到最开始的问题：为什么大模型需要 RAG？

因为知识不等于智能。

一个模型可以非常聪明——擅长推理、写作、代码——但它永远不知道你公司今天下午才更新的那份合同，不知道你的产品上周刚发布的新功能，不知道你三年前写的那篇内部报告里藏着什么结论。

RAG 做的事情，就是把"你的数据"和"模型的智能"连接起来。

它不是让模型变聪明，而是让模型能用你的知识，回答你的问题，给出可溯源、可验证的答案。

如果你想动手实践，推荐的入门路径是：

LangChain 或 LlamaIndex（框架）
    + ChromaDB（向量数据库，本地零配置）
    + bge-large-zh 或 OpenAI Embedding（Embedding 模型）
    + GPT-4o-mini 或本地 Qwen（生成模型）

这套组合可以在一个下午让你跑起来一个真实可用的 RAG 系统。

RAG 不是终点，它是大模型从"聪明的玩具"变成"实用的工具"的关键一步。而这一步，正在被越来越多的工程师和产品团队踏实地走着。

---

• 🎬 博客主页：https://xiaoy.blog.csdn.net

• 🎥 本文由 呆呆敲代码的小Y 原创 🙉

• 🎄 学习专栏推荐：Unity系统学习专栏

• 🌲 游戏制作专栏推荐：游戏制作

• 🌲Unity实战100例专栏推荐：Unity 实战100例 教程

• 🏅 欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！

• 📆 未来很长，值得我们全力奔赴更美好的生活✨

• ------------------❤️分割线❤️-------------------------

资料白嫖，技术互助

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Unity系统学习专栏	入门级	本专栏从Unity入门开始学习，快速达到Unity的入门水平
💛 Unity实战类项目	进阶级	计划制作Unity的 100个实战案例！助你进入Unity世界，争取做最全的Unity原创博客大全。
❤️ 游戏制作专栏	难度偏高	分享学习一些Unity成品的游戏Demo和其他语言的小游戏！
💚 游戏爱好者万人社区	互助/吹水	数万人游戏爱好者社区，聊天互助，白嫖奖品
💙 Unity100个实用技能	Unity查漏补缺	针对一些Unity中经常用到的一些小知识和技能进行学习介绍，核心目的就是让我们能够快速学习Unity的知识以达到查漏补缺