RAG 基础与完整流程

RAG 是当下大模型落地最核心、面试最高频的方向之一。本文系统讲清它解决什么问题、完整流程的每个环节、核心组件、范式演进、评估与生产化考量，是 RAG 的总纲。Embedding/向量库选型见 Embedding 与向量数据库，进阶优化见 RAG 进阶与优化。

一、什么是 RAG？为什么需要它？

RAG（Retrieval-Augmented Generation，检索增强生成）= 检索外部知识 + 让模型基于检索结果生成回答。一句话：先从知识库找到相关资料，再把资料连同问题一起喂给模型，让它「开卷答题」。

它针对性地解决了大模型的几个固有痛点：

痛点	RAG 如何解决
知识陈旧	模型知识截止于训练时间 → 接入实时/最新数据
缺乏私有知识	模型不知道企业内部文档 → 外挂私有知识库
幻觉	模型倾向「编得流畅」→ 基于给定材料作答并附出处，显著降低编造
不可溯源	黑盒输出难核查 → 给出引用来源，可追溯
更新成本高	微调注入知识贵且难更新 → 只需更新知识库，无需重训

二、RAG vs 微调 vs 长上下文

这是 RAG 必问的「选型题」，三者都是「给模型更多知识/能力」，但各有适用：

维度	RAG	微调	长上下文
解决什么	注入实时/私有事实知识	改变风格/格式/特定能力	单次塞入大量上下文
知识更新	改知识库即可，最灵活	需重新训练	每次重新塞
成本	中（检索+更长 prompt）	训练贵、推理常便宜	输入 token 多、贵
可溯源	强	弱	弱
适合	企业问答、知识库、事实型	垂直风格、稳定任务能力	单文档深读

结论：不是三选一。改风格用微调、注入事实用 RAG、单文档深读用长上下文，三者常组合（微调改表达 + RAG 供知识）。详见微调范式、长上下文。

三、完整架构总览

RAG 分**离线索引（Indexing）和在线检索生成（Retrieval + Generation）**两大阶段：

═══════════ 离线：构建索引 ═══════════
 原始文档(PDF/Word/网页/DB)
      │ 1.加载解析
      ▼
   纯文本
      │ 2.切分(Chunking)
      ▼
   文本块 chunks
      │ 3.向量化(Embedding)
      ▼
   向量 + 原文 + 元数据
      │ 4.入库
      ▼
   [向量数据库]
═══════════ 在线：检索 + 生成 ═══════════
 用户问题
      │ 5.(可选)查询改写
      │ 6.查询向量化(同一 Embedding 模型)
      ▼
 在向量库中相似度检索 → Top-K chunks
      │ 7.(可选)Rerank 重排精筛
      ▼
 8.拼进 Prompt 模板(问题 + 检索内容 + 指令)
      ▼
 9.LLM 生成带依据/引用的回答

四、离线索引详解

4.1 加载与解析（Load & Parse）

把各种来源转成纯文本：PDF、Word、PPT、HTML 网页、Markdown、数据库、API。难点在于保留结构：表格、标题层级、图片中的文字（需 OCR）、代码块。解析质量直接影响后续效果——「脏」文本进去，再好的检索也救不回来。

4.2 切分（Chunking）——最关键、最易被深问

为什么要切分？① Embedding 模型有最大输入长度；② 块太大检索不精准（一块里混入无关内容、稀释语义）；③ 喂给 LLM 的上下文有限且越长越贵。

常见切分策略：

策略	做法	特点
固定长度	按字符/token 数硬切 + 重叠	简单，但可能切断语义
递归字符切分	按段落→句子→词的层级优先切	最常用，尽量在自然边界断开
按结构切分	按 Markdown 标题/章节切	保留文档层级，适合结构化文档
语义切分	用 Embedding 找语义断点切	块内更聚焦，成本高
父子分块	小块用于检索、命中后返回所在大块	兼顾检索精度与上下文完整

两个核心参数：

chunk size（块大小）：没有银弹，常见 256~512 token。太大稀释、太小丢上下文，需在自己数据上实验。
overlap（重叠）：相邻块重叠 10~20%，防止把一个完整语义单元从中间切断，保证关键信息不因边界丢失。

4.3 向量化与入库

用 Embedding 模型把每个 chunk 编码成稠密向量，连同原文、元数据（来源、时间、标题、权限标签）一起存入向量数据库（Milvus、Qdrant、pgvector 等），底层用 ANN 索引（HNSW/IVF）支持海量快速检索。

五、在线检索与生成详解

5.1 查询处理（Pre-retrieval）

用户问题往往口语化、含糊、与文档表述不一致（语义鸿沟）。可先做查询改写/扩展/HyDE/多查询等优化（详见 RAG 进阶）。

5.2 检索（Retrieve）

把 query 用同一个 Embedding 模型编码，在向量库做相似度检索，召回 Top-K 个最相关 chunk。进阶用混合检索（向量 + BM25 关键词，RRF 融合）兼顾语义与精确匹配。

⚠️ 高频坑：query 和文档必须用同一个 Embedding 模型编码，否则向量空间不一致、检索失效。

5.3 重排（Rerank，可选但高性价比）

向量召回（bi-encoder）快但粗。用 Rerank 模型（cross-encoder） 把 query 和每个候选拼一起精细打分，对召回的几十条精排，只留最相关的少数几条。这是「向量召回粗筛 + Rerank 精排」两段式的由来，详见 Embedding 与向量库。

5.4 上下文组装（Augment）

把检索到的内容填进 Prompt 模板，和问题组成最终上下文。关键技巧：

明确指令：「只依据以下材料回答，材料中没有就说不知道，不要编造」。
引用溯源：让模型标注答案出自哪条材料（提升可信度、便于核查）。
位置安排：把最相关内容放在 prompt 首尾，缓解「lost in the middle」。
控制总长度：避免无关内容稀释、控制成本。

5.5 生成（Generate）

LLM 基于上下文生成带依据的回答。可配合低温度、结构化输出（返回答案 + 引用列表）、约束「不确定就拒答」来进一步降幻觉。

六、向量检索原理

Embedding 把语义相近的文本映射到向量空间中相近的位置。检索时计算 query 向量与文档向量的相似度（余弦/内积），取最近的若干个。由于在海量向量上精确检索太慢（O(N)），实际用 ANN（近似最近邻） 算法（HNSW、IVF-PQ）在精度和速度间折中。原理详见 Embedding 与向量数据库。

七、RAG 范式演进

范式	特点
Naive RAG	朴素的「检索→拼接→生成」，简单但召回不准、答非所问问题多
Advanced RAG	加查询改写、混合检索、Rerank、上下文压缩等优化（详见）
Modular RAG	模块化、可编排的 RAG 流水线，灵活组合各环节
GraphRAG	构建知识图谱，擅长跨文档关联、全局总结类问题
Agentic RAG	把检索当作 Agent 的工具，模型自主决定何时检索、检索什么、是否多轮

详见 RAG 进阶与优化。

八、RAG 评估

RAG 效果难量化，要分两部分评（详见 RAG 进阶）：

检索质量：命中率（Hit Rate）、MRR、上下文相关性/召回率。
生成质量：忠实度（Faithfulness，是否忠于检索材料、不编造）、答案相关性（是否切题）。

常用框架 RAGAS、TruLens，多采用 LLM-as-a-Judge 自动评测。建评测集 + 量化指标 + 持续迭代 是 RAG 工程化的关键，也是面试加分点。

九、常见失败模式与排查

现象	可能原因	排查方向
召回里没有相关内容	切分不当 / Embedding 弱 / 语义鸿沟	调切分、换 Embedding、查询改写、混合检索
召回相关但回答差	上下文太长稀释 / 位置不佳 / prompt 差	Rerank、上下文压缩、调 prompt、调整顺序
答案脱离材料（幻觉）	约束不足 / 检索内容不足以回答	强化「只依据材料」指令、引用溯源、多跳检索
专有名词/编号查不到	纯向量检索弱于精确匹配	加 BM25 混合检索
多跳问题答不好	单轮检索不够	多查询 / Agentic RAG / 迭代检索

排查口诀：先分清是「检索问题」还是「生成问题」——用评测集看检索命中率和生成忠实度，再对症下药。

十、生产化考量

增量更新：文档变更后重新切分/向量化并 upsert，按文档 ID 管理向量，避免全量重建。
权限与多租户：元数据打权限标签，检索时按用户权限过滤，做数据隔离。
缓存：相同/相似问题用（语义）缓存复用答案，省成本降延迟。
成本控制：控制 K 值与上下文长度、模型分级、前缀缓存，详见 LLM 应用开发实战。
安全：防间接 Prompt 注入（检索到的外部内容可能藏恶意指令）。
完整系统设计见 AI 系统设计专题与 AI 项目实战案例。

十一、高频追问

Q：RAG 的完整流程是什么？ 离线：加载→切分→向量化→入库；在线：query（改写）→向量化→检索 Top-K→（Rerank）→拼上下文→LLM 生成带引用的回答。

Q：RAG vs 微调 vs 长上下文怎么选？ 注入实时/私有事实、需溯源、频繁更新 → RAG；改风格/格式/固定能力 → 微调；单文档深度理解 → 长上下文。常组合使用。

Q：为什么需要 chunk overlap？chunk 大小怎么定？ overlap 防止把完整语义单元从边界切断（关键信息丢失）。大小没有银弹，常见 256~512 token + 10~20% 重叠，需在自己数据上实验；可用父子分块兼顾精度与完整。

Q：为什么是「向量召回 + Rerank」两段式？ bi-encoder 向量召回快、可在海量库粗筛；cross-encoder Rerank 准但慢、只对粗筛出的几十条精排，兼顾效率与精度。

Q：query 和文档为什么必须用同一个 Embedding 模型？ token 向量空间由模型决定，不同模型空间不一致，混用会导致相似度无意义、检索失效。

Q：召回率高但回答还是差，问题在哪？ 多半是生成环节：上下文过长稀释、相关内容位置不佳、prompt 模板差，或检索内容虽相关但不足以回答（需多跳/补充检索）。

Q：RAG 怎么降低幻觉？ 基于检索材料作答 + 引用溯源 + 明确「材料中没有就说不知道」+ 低温度 + 必要时事实校验。RAG 是事实性幻觉最有效的缓解手段之一。

Q：怎么评估一个 RAG 系统？ 分检索（命中率/MRR/上下文相关性）和生成（忠实度/答案相关性）两部分，用 RAGAS 等做 LLM-as-a-Judge 自动评测，并建评测集持续迭代。

Q：专有名词/产品编号检索不到怎么办？ 纯语义向量检索对精确匹配弱，加 BM25/关键词的混合检索（RRF 融合）互补。

Q：文档更新了向量库怎么同步？ 增量更新——对变更文档重新切分、向量化并 upsert，删除失效向量；按文档 ID 维护映射，避免全量重建。

Q：RAG 系统的主要安全风险？ 间接 Prompt 注入——检索到的外部内容里可能藏恶意指令劫持模型。需做指令/数据隔离、内容过滤、权限控制，详见大模型安全。

RAG 基础与完整流程 ​

一、什么是 RAG？为什么需要它？ ​

二、RAG vs 微调 vs 长上下文 ​

三、完整架构总览 ​

四、离线索引详解 ​

4.1 加载与解析（Load & Parse） ​

4.2 切分（Chunking）——最关键、最易被深问 ​

4.3 向量化与入库 ​

五、在线检索与生成详解 ​

5.1 查询处理（Pre-retrieval） ​

5.2 检索（Retrieve） ​

5.3 重排（Rerank，可选但高性价比） ​

5.4 上下文组装（Augment） ​

5.5 生成（Generate） ​

六、向量检索原理 ​

七、RAG 范式演进 ​

八、RAG 评估 ​

九、常见失败模式与排查 ​

十、生产化考量 ​

十一、高频追问 ​