RAG 基础

RAG 基础

RAG（Retrieval-Augmented Generation，检索增强生成）是让模型「知道」私有知识、降低幻觉的主流方案：先检索相关资料，再让模型基于资料回答。这一范式由 Lewis 等人于 2020 年提出，核心是把「参数化记忆」（模型权重中固化的知识）与「非参数化记忆」（外部资料库）结合：回答知识密集型问题时先查资料、再作答（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks）。

本文讲 RAG 的知识机制：为什么需要、基本流程、关键环节、失败模式与产品设计要点。工程落地的案例与选型见 RAG 产品化实战 与 知识库问答；检索技术的原理细节见 检索技术；查询改写、GraphRAG、Agentic RAG 等进阶方案见 高级 RAG。

为什么需要 RAG

• 模型不知道你的私有知识：公司文档、产品手册、用户数据……这些内容从未出现在训练数据里，模型天然不知道，无论问多少次都只能「编」
• 训练截止日期之后的信息它不知道：模型的知识停留在训练截止点，新政策、新版本、新流程都无法覆盖，除非重新训练
• 纯靠模型记忆回答容易幻觉：模型对不熟悉的事实会自信地编造，而且无法指出哪些内容是确定的，用户无从分辨
• 合规与溯源：金融、医疗、法律等场景要求「回答可追溯、可审计」，只有检索能给出一手依据，模型记忆给不出

幻觉从哪来：为什么模型会「一本正经地胡说」

要理解 RAG 的价值，先理解幻觉的根源。大模型本质是按概率续写文本的机器：它学的是「给定上文，下一个 token 最可能是什么」，而不是「记住一条事实，需要时原样取出」。所以：

• 知识以概率分布的形式存在于权重里，没有「数据库记录」式的确定条目，相近的知识会互相干扰
• 训练目标偏好在「流畅、像人话」的方向输出，流畅性优先于事实性——编得通顺的假话比生硬的真话更像模型会说的话
• 长尾事实（小公司制度、冷门条款）在训练数据里出现次数少，模型记住的概率低、遗忘的概率高

结论：幻觉不是 bug，是生成式模型的默认行为。RAG 的作用不是消灭幻觉，而是把「凭记忆编」换成「查资料答」，把幻觉关进「资料之外」的笼子里——模型只能基于检索到的资料发挥，资料里没有的它就无从编起。

模型记忆 vs 检索：边界在哪里

边界结论：高频稳定的常识靠模型记忆，动态的私有事实靠检索。「公司成立于哪年」这种稳定事实可以直接答；「本月报销政策」这种会变的、私有的事实必须检索。判断一句话「模型该不该知道」：问自己「它出现在模型训练数据里的概率有多大」——概率低、又要求准确，就该走检索。

RAG 适用与不适用场景

RAG 的基本流程

1
2
3
4

                        入库侧（离线，一次性/按更新触发）
源文档 → 解析 → 切块 → 嵌入 → 向量库（含元数据）
                                  ↑ 检索（在线，每次问答）
用户问题 → 查询处理 → 嵌入 → 取回 top-k 候选 → 重排 → 组装提示词 → 模型生成 → 引用标注 → 回答

1. 文档处理：解析源文档（PDF、Word、HTML、Markdown），提取正文与结构。常见坑：PDF 表格被拆乱、扫描件需要 OCR、Word 中的文本框丢失、代码块被当成正文
2. 切块：把长文档切成检索单元（chunk）。常见坑：在句子中间切断导致语义断裂、块太大导致检索不精确、切法与 embedding 模型不匹配（策略详见 检索技术）
3. 嵌入：把每个块用 embedding 模型转成向量。常见坑：用错语言（中文文档用英文 embedding 模型）、查询与文档的文本分布不一致
4. 入库：向量连同元数据（来源、页码、更新时间、权限标签）存入向量数据库。常见坑：忘记存元数据，后续权限过滤、引用溯源、新鲜度排序全都做不了
5. 检索：用户问题转成向量后检索最相关的块，通常取 top-k（如 20-50 个）候选。常见坑：纯向量检索漏掉精确术语（型号、编号、人名），需要混合检索兜底（详见 检索技术）
6. 生成：把重排后的检索结果（通常 3-5 个块）+ 问题 + 指令组装成提示词，要求「只基于资料回答，资料不足就明说」。常见坑：检索结果塞得太多导致模型注意力被稀释；提示词没有约束「不得使用资料之外的知识」
7. 引用：回答时标注每个论断对应的来源，用户可点击核对原文。常见坑：模型引用了与论断无关的来源，引用正确性需要单独评估（见下文「产品经理的评估视角」）

流程速查：每步做什么、坑在哪、决策点是什么

一个最小示例：「员工手册问答」走一遍全流程

假设要把一本 50 页的《员工手册》做成问答产品：

1. 文档处理：PDF 解析出正文，目录章节、页眉页脚被剥离，表格（如「各职级年假天数表」）单独提取保留
2. 切块：按章节递归切块，每块约 200-500 token，「年假制度」一节自成一块；块与块之间留 20% 重叠，防止答案切断在边界
3. 嵌入：中文场景选 bge 或 text-embedding-3 系列，每个块转成 1024 维向量
4. 入库：向量 + 元数据（文档名「员工手册 v3」、章节「第五章 休假制度」、页码、更新时间、可见权限）入向量库
5. 检索：用户问「年假几天」，问题转向量，取回 top-20 候选；关键词路命中「年假」相关块，两路融合
6. 生成：重排后取 top-3 块 + 问题 + 指令喂给模型：「只基于资料回答，标注来源编号」
7. 引用：回答「正式员工每年 10 天带薪年假 [1]」，[1] 指向手册第五章第 3 节，用户可点击核对

关键环节与常见问题

关键环节详解

文档处理与切块

• 格式解析：PDF 要先判断是文本型还是扫描型，扫描件需 OCR；表格是最容易翻车的结构——多行合并单元格、跨页表格被拆成两半，切块后语义断裂，检索时整表信息丢失。Word 文档要注意文本框、页眉页脚里的信息；HTML/Markdown 先剥掉样式与导航噪音
• 表格陷阱实例：「职级-年假天数」对照表被切成「职级表头块」与「天数数据块」两半后，问「P7 年假几天」就检索不到完整对应关系——表格类内容优先整表保存、带标题一起切块，或转成「一行一条」的文本再切
• 结构化优先：HTML、Markdown、JSON 等有结构标记的格式，先用对应解析器提取标题层级，把「标题 + 正文」绑定在一起，检索命中时能带上章节上下文——「检索到第 3.2 节的内容」比「检索到一段不知出处的话」好用得多
• 元数据：每个块携带来源文档、章节路径、页码、版本、更新时间、权限标签。元数据是后续权限过滤、引用溯源、时间衰减排序的地基，入库时就要打好；事后再补等于重跑一遍入库
• 切块策略：块大小、重叠量、切分方式（固定 / 递归 / 语义 / 父子块）直接影响检索质量，没有普适最优解，要用评测集对比定参——「切块是 RAG 的第一工程决策」，详见 检索技术 的「切块策略」一节

检索

• 向量检索：语义相似匹配，能命中「换个说法」的查询（「报销流程」命中「差旅费用报销规范」），但对精确术语不敏感——「A100」可能只召回「A1000」的语义邻居
• 关键词检索：精确词匹配，型号、编号、人名、专有名词靠它，但不懂同义改写
• 混合检索：两路互补合并，通常好过任何单一路；再加 rerank 精排，是检索质量提升最大的单点改进之一（LangChain 官方 reranker 文档）
• 机制与选型细节：见 检索技术

检索质量自检清单

每次改完检索相关配置，按清单快速自查：

1. 同一问题换个说法（「报销」→「差旅费用」），还能检索到吗？——测语义路
2. 同一问题用精确术语（型号、编号），能检索到吗？——测关键词路
3. top-k 里相关块排第几？前 3 名相关，还是第 15 名才相关？——测排序
4. 检索延迟在预算内吗？p95 呢？——测性能
5. 权限标签过滤生效吗？低权限用户能检索到高权限块吗？——测安全

生成

• 提示词组装：把「检索到的块（按相关度排序）+ 用户问题 + 指令」拼进提示词。指令要点：只基于资料回答、资料不足时明确说明、每个论断标注引用编号、不要编造资料外的内容
• 长度控制：检索结果过多会稀释注意力并推高成本，常见做法是重排后只保留 3-5 个块；回答也建议限长（如「300 字以内分点回答」），避免模型凑字数
• 生成参数：事实问答场景通常用较低温度（0-0.3）减少发散；max_tokens 限制回答长度；流式输出改善首 token 体验——生成侧参数与提示词一样，属于要进评测集回归的变量

• 指令模板示例（示意，实际按你的模型调）：

  1 2 3 4 5 6 7 8 9

  你是一个基于资料回答的助手。只使用下面资料中的事实回答用户问题； 资料不足时明确说明「根据现有资料无法回答」。回答中每个关键论断后标注 对应资料的编号，如 [1]、[2]。不要使用资料之外的知识。 资料： [1] 报销流程：…… [2] 差旅标准：…… 问题：……

• 与提示词工程的关系：RAG 的生成侧本质是提示词工程的一个特例，通用技巧（角色、格式约束、few-shot）同样适用，见 提示词工程

引用

• 来源标注：回答中的关键论断带 [1]、[2] 编号，下方列出对应来源（文档名 + 章节 + 页码/链接），用户可点击直达原文
• 编号机制的实现：给每个进入上下文的块分配固定编号（如 [1]-[5]），指令要求模型「引用必须取自资料编号」；生成后用程序校验——回答里出现的编号必须都在资料编号集合内，越界编号视为引用错误
• 引用正确性：模型可能「答案对但引用错」或「引用对但答案错」，这是两类需要分别修的缺陷；实现上可以在生成时强制模型只引用提示词里真实存在的块编号，并单独评估引用正确率
• 引用与权限：引用的原文可能属于不同权限级别，展示来源时也要做权限过滤，不能「答案脱敏、来源泄密」

常见失败模式

失败模式的层级关系

失败模式不是并列的，而是有因果层级：切块失败 → 检索失败 → 生成失败 → 引用失败，前面环节的失败会传染给后面。所以排查时永远先查上游：检索不到先看切块，幻觉仍有先看检索到的块里有没有答案。评测时也按层级拆指标，才能在「整体变差了」的时候定位到具体环节。

先分清「检索不到」与「检索不准」

两个症状相似但修复手段完全不同：

• 检索不到（该检的块没进 top-k，回答「没有相关资料」）：问题在切块、embedding 或查询侧——换个说法搜一下、直接搜块里的关键词，能定位是哪一环
• 检索不准（检到了但排位靠后，或检到错的，答非所问）：问题在排序侧——rerank 没上、融合权重不对、top-k 太小把相关块挤掉了

排查第一步先问：「相关块到底在不在检索结果里？」在 → 排序问题；不在 → 召回问题。方向错了，后面的修复全是白费。

RAG vs 微调 vs 长上下文

• RAG 不是万能：当「正确性依赖稳定的行为模式」而非「事实内容」时——如固定输出格式、特定语气风格、特定任务流程——微调更合适。OpenAI 官方 Cookbook 的检索问答范例明确：事实性回忆场景检索优于微调，微调更适合风格与任务教学（Question answering using embeddings-based search）；微调机制详见 模型训练与对齐
• 什么时候直接用长上下文：一次性大文档问答（合同、财报、论文）、不需要持续更新、不需要权限区分、单次成本可接受——直接塞全文比搭建检索管线更简单可靠
• 长上下文的边界：文档体量超过模型窗口、需要多文档交叉引用且体量总和超窗、知识会频繁更新——这些情况长上下文要么塞不下、要么每次都要重塞、要么按 token 计费扛不住，回到检索更优
• 组合使用是常态：RAG 负责事实、微调负责风格与格式、长上下文兜底大文档，三者并不互斥；选型用评测数据说话，不要「因为流行所以上 RAG」

决策流程（按顺序问自己）

1. 知识会变吗、需要权限隔离吗、回答要可溯源吗——任一为「是」，RAG 优先
2. 行为模式（格式、风格、流程）要固化吗——是，叠加微调
3. 文档是一次性、不用更新、体量可负担吗——是，直接长上下文更简单
4. 拿不定？建 30-50 条评测集，三种方案各跑一遍，用指标说话

组合架构示例

1
2
3

用户问题 → 路由（简单问题 → 直接长上下文/快模型；事实问题 → RAG；格式任务 → 微调模型）
RAG 路径：检索 → 生成（基座模型，未微调，因为事实由资料负责）
微调模型路径：固定格式输出（风格、流程由微调负责）

进阶方案

• 混合检索 + 重排：向量检索 + 关键词检索 + rerank 精排，显著提升召回质量，是当前产品化的标配——原理见 检索技术
• 查询改写 / 多查询 / HyDE：检索前先处理问题本身，让「问得不好」的问题也能检索到对的内容——见 高级 RAG 的「查询处理」
• 知识图谱与 GraphRAG：把实体关系结构化，适合「找关联、多跳推理」类问题——见 高级 RAG
• Agentic RAG：把检索做成多步决策（先查目录 → 再查章节，检索结果不满意 → 重新检索），复杂问题更准——见 高级 RAG

产品设计要点

• 知识治理在前：文档质量决定问答质量——先治理知识（结构化、去重、版本化、明确哪些可被问哪些保密），再做检索优化；给烂数据打补丁式的检索优化毫无意义（详见 知识库问答）
• 知识更新节奏：明确「源文档变更 → 索引同步」的触发方式（定时任务或事件驱动）与同步延迟 SLA；文档改版后旧块要删除或替换，避免「幽灵引用」；更新链路要可监控、可回溯。增量更新（按文档 id + 内容哈希去重，只刷变化的文档）是推荐模式，配套做法见 RAG 产品化实战 的「知识治理与更新」
• 权限与可见性：不同用户能看到的知识范围不同——权限过滤必须作用在检索层（检索前按用户权限标签过滤），而不是只在 UI 隐藏结果；权限标签随元数据入库，查询时直接过滤。「答案脱敏、检索不过滤」等于没做权限
• 引用可验证：回答必须带来源，用户能点开原文核对；「无法验证的回答」对高信任场景等于没有回答。引用要能回溯到具体版本（来源带版本号），而不是只给一个文档名
• 评估体系：检索线（命中率、MRR）+ 回答线（忠实度、相关性）+ 引用线（引用正确率）三条指标线齐备，评测集持续扩充；评测方法论见 评估与评测，RAG 专属指标见 高级 RAG 的「RAG 评测体系」
• 拒答与降级：资料里没有就明确说「没有相关资料」，不要硬编；拒答不是缺陷，而是可信度的一部分（dair-ai Prompt-Engineering-Guide 的 RAG 综述把负面拒答列为 RAG 鲁棒性评测的维度之一）。低置信时还可引导澄清问题、给 FAQ 链接或转人工
• 成本与延迟预算：embedding、rerank、LLM 生成每一轮都花钱，量上来后账单会超预期；检索 + 重排 + 长上下文生成层层叠加会变慢——上线前按预估调用量算成本，按场景设延迟预算（客服 2-3 秒、实时助手秒级）
• 用户引导：告诉用户「怎么问得好」（FAQ 建议句式）、在回答旁展示「依据来源」增强信任感；不要指望用户自动学会与 AI 沟通
• 埋点与监控：上线后监控无命中率（检索空结果比例）、top-1 相关率（抽样人工标注）、用户点踩率、拒答率、检索延迟分位数；错案回流 → 归因（修文档 / 修检索 / 修提示词）→ 修复 → 补进评测集防回归——这条闭环是 RAG 产品长期质量的生命线
• 灰度上线：换 embedding、换 rerank、改切块这类改动先在评测集回归，再小流量灰度对比线上指标，确认无劣化再全量

产品经理的评估视角

评估 RAG 产品，核心看三类指标：

1. 召回率：该检索到的内容检没检索到。口径上常用 hit rate（top-k 里有没有应命中的块）与 MRR（应命中的块排在第几位），需要人工标注「问题 → 应命中的文档/块 id」
2. 答案准确率：回答是否正确、是否忠实于资料。需要人工判分或 LLM-as-judge 打分，并区分「忠实于资料但资料错了」与「资料对但答错了」两种错误——前者是知识治理问题，后者是生成问题
3. 引用正确率：引用的来源是否真的支持答案。单独统计「答案对但引用错」的比例，这类缺陷修复方式与答案错误不同（强制引用真实块编号、加引用校验）

怎么测：指标口径

• hit rate / 召回率：评测集里标注了「应命中块 id」的问题，检索 top-k 结果包含应命中块的比例——衡量「检没检到」
• MRR：对每个问题，取「第一个应命中块在结果中的排名」的倒数，再对所有问题平均——衡量「排得靠不靠前」，前 5 位与第 20 位都算命中，但体感完全不同
• 答案准确率：端到端人工判分（正确 / 部分正确 / 错误 / 拒答），或 LLM-as-judge 打分——注意分「忠实于资料」与「正确」两个维度，资料错了但回答忠实，是知识治理的事
• 引用正确率：逐条核对「论断 → 引用来源」是否真的互相支持；来源支持但答案错、答案对但来源张冠李戴，是两类缺陷

评测集构建

1. 来源：从真实用户日志、客服工单、FAQ 收集，而不是自己「出题自己答」——真实分布才反映真实失败
2. 规模：30-50 条起步即可暴露主要问题，随后随反馈闭环持续扩充
3. 覆盖五类：常见问题、长尾问题、应拒答问题（资料里没有的）、跨文档问题（答案散在多份文档）、多轮追问
4. 标注：答案由领域专家标注；「应命中的文档/块 id」同样人工标注——检索线的评测依赖它
5. LLM-as-judge 规模化 + 人工抽检校准：自动打分可以跑大量样本，但判断器可能偏爱冗长或自带立场，需要定期人工抽检校准（详见 评估与评测）
6. 每次改动重跑：改切块参数、换 embedding 模型、换 rerank、改提示词，都重跑同一评测集，防止「改好了 A 坏掉了 B」；错答案例持续回流补进评测集

指标速查：

常见误区

• 只测端到端「答得好不好」，不拆检索线——答错了不知道是没检到还是没答好
• 评测集不更新——线上错案不回流，评测集与真实分布渐行渐远
• 用公开 benchmark 代替自建评测集——通用基准与你的用户分布几乎必然不同
• 改完不回归——「这次应该没问题」是 RAG 迭代里最常见的翻车现场

常见问题 FAQ

• 为什么加了 RAG 还会答错？ 按层级排查：切块 → 检索 → 生成 → 引用。经验上大多数「答得不好」死在检索之前——先确认「相关块到底进没进 top-k」
• 知识库多大多小才需要 RAG？ 几十篇文档就有价值（文档越多越值得）；量级影响的是技术选型（向量库、ANN 索引），不是「要不要做」的判断
• RAG 会不会很慢？ 延迟构成：查询 embedding（毫秒）+ 向量检索（毫秒）+ rerank（每候选一次推理）+ LLM 生成（秒级大头）。优化顺序：先压检索链路，再考虑生成侧（换快模型、流式输出）
• 用 embedding 还是 BM25？ 语义匹配 vs 精确匹配，单用都有盲区——混合检索是产品化标配，不要二选一
• 一次检索 vs 多次检索（Agentic）？ 简单问题一次检索最稳；「一次拿不全」的复杂问题才值得决策循环（详见 高级 RAG）
• 文档更新后要重新嵌入吗？ 按文档 id + 内容哈希做增量更新，只重刷变化的文档，不要全库重跑
• RAG 和 Elasticsearch 是什么关系？ Elasticsearch 是关键词检索的生产化实现（分词、倒排、打分全套），可以作为 RAG 的关键词路复用；它缺的是语义路与向量检索，两者互补
• RAG 能保证 100% 不幻觉吗？ 不能。RAG 是「降低」幻觉并让错误可追溯，不是消灭；资料错、检索错、生成无视资料都会产生错误答案——所以评估与监控才不可或缺

术语速查

来源说明

本文为原创整理，主要依据以下权威来源（截至 2026-08-23 均已核实可达，引用日期 2026-08-23）：

1. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 2005.11401）——RAG 范式原始论文：参数化记忆 + 非参数化记忆
2. dair-ai Prompt-Engineering-Guide：RAG 综述——基础 RAG 的局限、切块研究、鲁棒性评测维度
3. OpenAI Cookbook：Question answering using embeddings-based search——检索问答范式、「开卷考试」类比、检索优于微调的事实场景
4. LangChain 官方文档：Cross encoder reranker——rerank 是 RAG 质量提升最大的单点改进之一
5. RAGAS 官方文档：Metrics——faithfulness、answer relevancy、context precision 等端到端指标
6. Anthropic 官方工程博客——「只在评测证明必要时增加复杂度」的工程原则

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用