你有没有想过一个问题——
LLM 训练时读了几万亿字的互联网数据，几乎什么都知道。但它不知道你的业务数据——你的产品手册、售后政策、内部文档、客服对话记录。这些它没读过。
怎么让它知道该知道的？
这就是 RAG 要解决的问题。这篇文章从为什么需要 RAG 开始，一直讲到它的完整架构和最容易翻车的地方。
LLM 什么都知道，但不知道你的业务
LLM 有两个先天缺陷，在实际落地中很难绕过去。
| 缺陷 | 表现 | 影响 |
|---|---|---|
| 知识截止 | 训练数据停在某个时间点 | 问最新政策、实时数据，它不知道 |
| 不知道私有数据 | 没读过你的内部文档、产品手册、客服记录 | 业务场景下基本不可用 |
怎么解决？目前有三条路可以走。
方案一：微调（Fine-tuning）
拿业务数据继续训练模型，让它把新知识学进去。
听起来最直接，但实际操作成本很高。你需要准备高质量的训练数据、处理算力资源，而且每次业务文档更新了，又得重新训一遍。更麻烦的是，微调可能会破坏模型原有的通用能力——模型学会了你的业务术语，但写邮件的能力反而变差了。
方案二：塞长上下文（Long Context）
把所有资料都塞进 Prompt 里，让模型自己翻。
实现最简单，不用动模型。现在有些模型支持 128K、1M 甚至更长的上下文，看起来够用。但实际效果没那么理想：一是 Token 成本会随着内容量线性增长；二是内容太多之后，模型很难从海量信息中找到准确的那一段——这就是著名的"大海捞针"问题。上下文再长，检索精度是会下降的。
方案三：RAG（检索增强生成）
每次提问的时候，先去知识库里检索相关内容，拼到 Prompt 里，再让 LLM 基于这些材料回答。
RAG 是目前最主流的方案。原因很实在：
- 成本低：不需要重新训练模型，省了算力
- 更新快：知识库加个文档就行，不需要重训
- 可追溯：LLM 是看着你给的资料回答的，能知道它引用的是哪份文档
- 幻觉少：基于具体材料生成，比凭空回答可靠得多
当然，RAG 也有自己的问题——它依赖检索质量。如果检索到的内容不对或者不完整，LLM 材料再好也回答不对。后面会详细讲这个。
RAG 不是搜索引擎——它和搜索引擎的区别
很多人第一次接触 RAG 的反应是：这不就是搜索引擎吗？用户搜关键词，系统返回匹配的文档——有什么新鲜的？
这个理解对了一半，错的一半恰好是 RAG 的核心。
搜索引擎（ES/BM25）怎么工作
你搜一个关键词，搜索引擎在你的文档库里找到包含这个词的所有文档，按匹配度排序返回。它做的是关键词精确匹配。
比如说你搜"2025年Q3营收"，它能找到包含这几个词的那份财报。但如果你问"去年第三季度营收怎么样？"，它可能找不到——因为文档里写的是"2025年Q3营收同比增长15.3%"，关键词对不上。
这是一直以来搜索引擎的运作方式。在"搜文档、找文件"的场景下非常好用，但在"回答问题"的场景下就显得力不从心。
RAG（向量检索）怎么工作
RAG 不一样。它先把你的文档库转成一组向量（可以理解成一组数字坐标），用户提问时也把问题转成向量，然后计算问题向量和文档向量之间的距离。距离越近，说明内容越相关。
“去年第三季度营收怎么样？“和"2025年Q3营收同比增长15.3%“在字面上没有共同的关键词，但在语义上是同一件事。向量检索能捕捉到这种语义上的相近。
| 维度 | 搜索引擎（ES/BM25） | RAG（向量检索） |
|---|---|---|
| 匹配方式 | 关键词精确匹配 | 语义匹配 |
| 搜"苹果” | 返回含"苹果"二字的所有文档 | 能区分你在问水果还是手机品牌 |
| 输出 | 文档列表 | 相关内容 + LLM 生成的自然语言回答 |
| 适合场景 | 搜文档、找文件 | 回答问题、知识问答 |
| 局限性 | 同义词、近义词不识别 | 对数字/专有名词匹配不如精确搜索 |
所以搜索引擎和 RAG 不是替代关系，而是互补关系。生产环境最常用的方案是混合检索：向量检索负责语义匹配，BM25 负责精确匹配，两者互补。
但语义检索有一个前提条件：内容必须被正确地理解和切分。这就引出了下一个问题。
一条文档在 RAG 系统中的完整旅程
语义匹配的效果，很大程度上取决于文档在入库时被处理成了什么样子。一条文档从上传到最终被 LLM 用来回答问题，中间经历了一整套加工管道。
RAG 系统完整管道：入库阶段 → 检索阶段（点击图片查看大图）
入库阶段：让机器能"读懂"文档
| 环节 | 做什么 | 为什么重要 |
|---|---|---|
| 文档解析 | 把 PDF、Word、HTML 等格式转成纯文本 | PDF 看着是文字，实际是一堆坐标指令。解析不好，后面的所有环节都白费 |
| 文本清洗 | 去噪、去重、格式归一化 | 把乱码、多余的空格、无关的页眉页脚清掉 |
| 分块 | 把长文本切成语义完整的片段 | 不能整篇检索——太大了检索不准，太小了语境不够 |
| 向量化 | 用 Embedding 模型把文本片段转成向量 | 向量是语义匹配的基础 |
| 存入向量库 | 把向量和原文存入向量数据库 | 供后续检索使用 |
检索阶段：找到相关内容并让 LLM 回答
| 环节 | 做什么 |
|---|---|
| 问题向量化 | 把用户提问也转成向量 |
| 向量检索 | 在向量库里找距离最近的文档片段 |
| 重排序 | 对检索结果重新精排，提升 Top 结果的准确率 |
| 拼入 Prompt | 把检索到的内容拼到 Prompt 里，加上指令让 LLM 基于材料回答 |
为什么检索质量是关键
整个管道里，最核心的瓶颈不是 LLM 本身，而是检索质量。
Andrew Ng 在一个分享里提过一个数据：优化 RAG 系统时，检索质量的提升对最终答案准确率的影响远大于模型本身的升级。换句话说，用更强的模型不能弥补检索结果差的问题——模型再聪明，材料给错了也答不对。
而检索质量又依赖于前面的入库环节：文档解析是否正确、分块是否合理、向量化是否准确。这是一个完整的链路，短板出在任何一环都会影响最终效果。
最容易在哪里翻车？
把各个环节按翻车概率排序，前三个是：
1. 文档解析——最大的坑
你传上去的文档是 PDF。PDF 看着是文本，但本质上是一堆坐标指令的集合——“在坐标 (x,y) 处渲染字符 A，在 (x+5,y) 处渲染字符 B”。它并不知道什么是段落、什么是表格、什么是页眉。
遇到以下几种 PDF，解析很容易翻车：
| PDF 类型 | 难度 | 翻车方式 |
|---|---|---|
| 数字原生 PDF | ⭐ 简单 | 基本没问题 |
| 扫描件 PDF（图片） | ⭐⭐⭐ 中等 | 需要 OCR，识别率取决于清晰度 |
| 双栏/多栏排版 | ⭐⭐⭐⭐ 困难 | 阅读顺序恢复错误，左右栏混在一起 |
| 含表格 PDF | ⭐⭐⭐⭐⭐ 极难 | 无线框表格、合并单元格、跨页表格，很容易解析错位 |
| 含公式 PDF | ⭐⭐⭐⭐⭐ 极难 | LaTeX 公式、化学结构式，专用模型才能处理好 |
2. 分块——切得不合适
解析完的文本不能整篇扔进去检索。整篇检索的问题：一篇文档可能几千字，但用户问的只是其中一小段。整篇匹配会让不相关的内容稀释相关内容的信号。
但切得太细也不行。比如只切一两句话——检索时可能命中了，但上下文缺失，LLM 看了也不知道前因后果。
这就是分块的核心矛盾：检索精度 vs 上下文完整性。切小了检索精准但语境不足，切大了语境完整但检索不精准。
实际生产中有好几种分块策略来解决这个矛盾——按固定大小切、按语义边界切、按文档结构切、父子分块等等。每种策略各有优缺点，选型取决于你的文档类型和场景。
3. 检索——精确匹配 vs 语义匹配的盲区
即使解析和分块都做好了，检索环节仍然可能翻车。典型场景：
- 找不到相关内容：你的文档里确实有答案，但向量检索没把它排到前面
- 找到太多噪音：检索返回了大量不太相关的内容，稀释了有效信号
- 数字/专有名词匹配弱：向量检索对"Q3-2025营收同比增长率15.3%“这种精确表达不如关键词搜索
这也是为什么生产环境通常用混合检索——语义 + 关键词组合，取长补短。
回头看看
把整篇文章的问题串起来：
LLM 不知道你的业务数据
→ 三种方案对比，RAG 最实用（成本低、更新快、可追溯）
→ RAG 不是搜索引擎，是语义匹配
→ 但语义匹配的前提是内容被正确加工
→ 入库阶段：解析 → 清洗 → 分块 → 向量化 → 存储
→ 检索阶段：检索 → 重排序 → 拼入 Prompt → 生成
→ 最容易翻车的地方：解析、分块、检索
RAG 看起来简单——“查资料再回答”——但做了才发现，每一步都有坑。理解了这个全貌，后续不管是选型还是排查问题，都知道问题可能出在哪一环。
参考资料
- Andrew Ng, Building RAG Agents with LLMs, DeepLearning.AI, 2025 — 检索质量对 RAG 效果影响的分享
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv:2005.11401, 2020 — RAG 论文原文