AI大模型进阶系列(06) RAG 原理 | 分块、检索、重排的全链路拆解

RAG 的本质，是把「模型不知道的事」变成「模型读得到的上下文」——而RAG全链路上每一环的质量，最终都会影响模型推理结果质量。

目录

• 一、RAG工程实践常见问题
• 二、原理与机制
  • 2.1 全链路总览
  • 2.2 解析、清洗与分块
  • 2.3 Embedding 与向量检索
  • 2.4 混合检索与两阶段重排
  • 2.5 组装、溯源与 query 改写
• 三、生产级 RAG 的功夫散在每一环
  • 3.1 垃圾进垃圾出：检索内容很重要
  • 3.2 评估怎么做
  • 3.3 知识库更新与增量索引
  • 3.4 成本从哪来
• 四、链路就是答题提纲
  • 4.1 串全链路，站稳及格线
  • 4.2 常见的五个问题

一、RAG工程实践常见的问题

「你们的知识库是怎么接进大模型的？」说的就是 RAG（检索增强生成）。demo 级的 RAG 一个下午就能搭——切块、灌进向量库、检索几段拼进 prompt 就行；而生产级的 RAG，需要把全链路的每一环用心打磨：块怎么切、切多大、chunck有哪些参数调优？向量模型怎么选？检索不准怎么排查？为什么要重排？query 重写如何优化？

二、原理与机制

2.1 全链路总览

一个生产级 RAG 会分成「离线建库」和「在线问答」两条主线，中间通过向量索引来连接。

具体环节包括：解析清洗 → 分块 → Embedding → 索引检索 → 重排 → 组装生成 → query 改写。

2.2 解析、清洗与分块

这一部分的开发工作量是非常大的，至少大于60%。因为知识库来源五花八门：PDF、Word、HTML、扫描件、Excel 表格。PDF 尤其难缠——多栏排版被拉成错乱的一行、页眉页脚混进正文、表格结构被拍平成一堆无意义的数字串。这一步质量差，后面全链路再精致也救不回来，因为模型永远只能读到你解析出来的那份文本。所以生产系统里，表格常要单独抽成结构化文本或 Markdown，图片走 OCR 或多模态描述，页眉页脚、水印这类噪声要清洗掉。

清洗完就要分块（chunking）。为什么非切不可？

其一，Embedding 模型有输入长度上限，整篇文档喂不进去；

其二，检索要的是「精准命中相关段落」，而不是把一整本手册丢给模型——那既撑爆上下文又稀释重点。

分块的难点在于：块太小，语义被切碎，一句话的上下文丢了；块太大，检索粒度糊掉，一个块里混了好几个主题，命中率和精度都掉。

分块的四种主流策略的取舍：

重点看overlap（重叠）：相邻块共享一小段内容（常见块长的 10%~20%），是为了避免恰好被切在边界上的关键句「两头不靠、谁都检索不全」。块大小没有标准答案：常见落在几百 token，但真正的定法是「按文档结构和典型查询粒度先设一个初值，再用评估集调」——FAQ 类短问答块可以小，长篇技术手册块要大些。

2.3 Embedding 与向量检索

分好的块要变成可检索的形式，这就是 Embedding：把一段文本映射成一个高维向量（几百到几千维），让语义相近的文本在向量空间里距离也近。检索时把用户问题也编码成向量，去库里找距离最近的若干个块——距离度量常用余弦相似度，「相似度高」在几何上就是「夹角小、方向接近」。

Embedding 选型主要看：维度（越高表达力越强但存储和计算越贵）、语言（中文库必须选中文或多语训练的模型，拿纯英文模型硬套中文效果会崩）、领域适配（医疗、法律、代码这类专业语料，通用模型可能分不清近义术语，必要时要领域微调或换专用模型）。另外：建库和查询必须用同一个 Embedding 模型，中途换模型就得全量重建索引，否则两套向量根本不在一个空间里，求向量距离没有意义。

2.4 混合检索与两阶段重排

纯向量检索它擅长语义，却不擅长「精确」搜索，比如：产品型号 A100-80G、错误码 ERR_5021、人名、法条编号这类专有 token，语义向量检索他们都有一定的相似度，距离也很近，但实际上没有多大关系。

于是生产系统普遍选混合检索：向量检索管语义、关键词检索（BM25 这类经典倒排打分）管精确匹配，两路各召回一批，再融合排序（常用 RRF 倒数排名融合），彼此互补；

召回之后是重排（rerank），这是最容易被 demo 跳过、却最能拉开效果的一环。为什么要分两阶段？比如搜索系统——搜索引擎从不会拿一个复杂模型去给全库文档逐条打分，那样慢到不可用；它先用轻量手段从海量里粗筛出候选集（图快、图广、宁滥勿缺），再用重模型在小候选集上精细排序（图准）。RAG 的检索是同一套骨架：

两阶段的分工，本质是精度和成本的分层：

• 粗召回用 bi-encoder（问题和文档各自独立编码成向量，可离线预算、在线只算最近邻），几十毫秒从百万级库里捞出几十上百个候选，图的是「别漏」。
• 精排用 cross-encoder（把问题和候选文档拼在一起送进模型，让两者充分交互打分），准得多但慢得多，所以只在几十个候选上跑，图的是「排对」。

粗召回的 topK 召多一点没关系，反正后面还有精排兜底；真正拼进 prompt 的只是精排后的 topN（常见 3~5 段）。这个「先广后精」的分层，就是搜索系统召回+精排架构在 RAG 里的复刻。

2.5 组装、溯源与 query 改写

精排后的片段要组装进 prompt。这不也是简单复制粘贴：片段之间要有分隔和来源标注，指令要明确告诉模型「只依据给定材料回答，材料里没有就说不知道」——这是压制模型「凭记忆瞎编」的关键一招。同时给每段带上来源 ID，让模型在答案里标注引用，实现溯源，用户点开就能看到答案出自哪份文档哪一段。溯源不只是体验，更是可信度的兜底：能定位来源的答案，才敢在生产里给用户看。

最后一环，也是多轮对话里最容易翻车的——query 改写。用户很少每次都问一个完整独立的问题。第一轮问「A100 支持哪些精度？」，第二轮接一句「它功耗多少？」——这个「它」，直接拿去检索必然召回一堆无关内容，因为「它」本身没有任何语义。所以要先做指代消解，用对话历史把「它功耗多少」改写成「A100 的功耗多少」这样一个独立问题，再送进检索。改写这一步还能顺带做查询扩展（补同义词）、拆分复合问题，但核心是让送进检索的 query 自身语义完整。

三、生产级 RAG 的功夫散在每一环

3.1 垃圾进垃圾出：检索内容很重要

RAG 里流传最广、也最实用的一句判断：检索质量决定一切，垃圾进、垃圾出。模型再强，喂进去的片段是错的或不相关的，它只能在错误素材上编出一个像模像样的错答案。

所以答错时的排查顺序是有讲究的，绝不能上来就怪模型。正确的第一步永远是——把这次实际检索出来的片段打印出来看。看到检索内容，问题往往一眼定位：

• 检索到的片段根本不相关 → 问题在检索/embedding/分块，往上游查。
• 片段相关但被切碎、关键信息缺一半 → 问题在分块策略。
• 片段又对又全，模型却答错或答偏 → 这才轮到怀疑 prompt 组装或模型本身。

我们需要建立这套「先看检索、再看生成」的RAG优化思路。

3.2 评估怎么做

「你怎么证明你的 RAG 变好了？」分两步：

• 检索环节看召回相关性：该被召回的相关片段有没有被召回、排得靠不靠前（命中率、MRR 这类指标）。
• 生成环节看忠实度（faithfulness）：答案是不是老老实实基于检索片段、有没有脱离材料自由发挥；以及答案对问题的相关性。

3.3 知识库更新与增量索引

知识库不是一次建好就完事的。文档会新增、会修订、会下线，对应的向量索引必须跟着动:新增文档增量建块入库，修订文档要先删旧块再插新块（否则新旧内容同时被召回，答案自相矛盾），下线文档要能及时清出索引。这里的隐性坑前面提过——一旦要换 Embedding 模型，就是一次全量重建，代价不小，选型时就得想清楚。生产系统还要考虑索引更新和在线检索的一致性，别让用户在重建过程中检索到半截数据。

3.4 成本从哪来

成本这块，上一篇《上下文窗口不是内存》已经把 token 账算透了，这里只做一句回指、不重复：RAG 请求里检索片段是输入 token 的大头，因此 topK 拿几段、每段 chunk 多大，直接乘进你的账单——召回越贪、块越大，输入越长，钱烧得越快。这也是为什么 2.4 强调「拼进 prompt 的只取精排后的 topN」：既是为精度，也是为成本。

四、总结

回到开头那个问题：「你们的知识库怎么接进大模型？」，我们逐层总结。

4.1 完整链路

「RAG 是检索增强生成。离线阶段把知识文档解析清洗、切成块、用 Embedding 模型转成向量存进向量库；在线阶段把用户问题也向量化，去库里检索最相关的若干片段，拼进 prompt 一起给大模型，让它基于这些材料回答。核心价值是让模型能用到它训练时没见过的、私有的或最新的知识，而不用重新训练。 检索我不会只用纯向量——它对专有名词、精确匹配是盲区，所以上混合检索，向量管语义、BM25 管关键词。检索完还要两阶段重排：粗召回图快图广、cross-encoder 精排图准，和搜索系统的召回+精排是同一套架构。多轮对话要先做 query 改写消解指代，否则『它支持吗』这种问题根本没法检索。评估我会分环节做，检索看召回、生成看忠实度」

一句话：「解析 → 分块 → 向量化 → 检索 → 生成」。

4.2 常见五个问题

① chunk 大小怎么定？ 其实没有标准答案——按文档结构和典型查询粒度设初值，再用评估集调；FAQ 短块、长手册大块，配 10%~20% overlap 防边界切断。

② **检索不准怎么排查？需要分层定位：先打印实际检索到的片段，片段不相关就查 embedding / 检索，片段被切碎就查分块，片段对但答错才怀疑 prompt 或模型。

③ 为什么要 rerank，不直接把 topK 给模型？ 分两阶段是精度和成本的分层：粗召回用 bi-encoder 图快图广、宁滥勿缺；cross-encoder 让问题和文档充分交互，准但慢，只在几十个候选上跑，最后只取 topN 拼进 prompt——省 token 也提精度。

④ RAG 和微调怎么选？ 对于知识时效性、需要溯源、频繁更新的走 RAG；要改变模型能力、风格、内化领域技能的走微调，两者常配合用。

⑤ 怎么证明你的 RAG 变好了？ 「用户反馈变好了」接不住。分环节评估：检索看召回相关性（命中率 / MRR），生成看忠实度和答案相关性；建人工小金集做基线，每次改动跑回归，稳定后再上 LLM-as-judge 扩规模。