CE101 检索增强生成(RAG)
Table of contents
原文地址:https://ce101.ifuryst.com/core-tech/rag
一、这个内容真正解决的是什么问题?
当你把模型输出当成“自带最新、可追溯知识的答案”时,最容易在知识过时与自由发挥上栽跟头,结果就是回答看似合理却经不起来源核对。
二、最容易产生误解的地方
以为 RAG 是“让模型变聪明”的训练手段 很多人把它和微调混在一起,是因为都能提升效果;但 RAG 本质是在推理时把外部材料塞进上下文,不改模型参数。误解会导致把预算砸在训练上,却忽略索引、分块、检索与重排这些真正决定命中率的环节。
以为“有检索就不会幻觉” 直觉上“引用了资料=可靠”,但检索可能召回错片段、拼接断章取义、或把不相关内容当证据。后果是幻觉从“凭空编造”变成“拿错材料讲得更像真的”,更难被发现。
把向量检索当成万能搜索 稠密检索能抓语义相似,让人误以为它能覆盖所有查询;但关键词精确匹配、数字/代号/条款、强约束过滤往往更适合稀疏或标量检索。误用会出现“语义上差不多但条件不满足”的召回偏差。
把 TopK 当成越大越好 工程上常见做法是把 k 往上调来“保险”;但上下文窗口与噪声会反过来稀释关键信息,甚至让模型在互相冲突的片段里摇摆。结果是成本更高、输出更长、结论更不稳定。
认为重排只是“锦上添花” 很多系统只做一次向量召回就直接生成,是因为实现简单;但召回阶段追求覆盖,精排阶段追求相关性,二者目标不同。忽略重排会把“能搜到”误当成“能用来答”,最终把生成质量问题错怪给模型。
三、支撑正确理解的核心机制
参数化知识 vs 非参数化记忆:把“知道”变成“可引用” 直观上,模型像把知识背在脑子里,记忆会过时也会串台;RAG 把材料放到外部库里,答题时把相关段落拿来当“开卷资料”。 专业上,RAG 用外部可检索存储承载非参数化记忆,并在推理阶段把检索结果注入上下文以提升知识密集任务的准确性与可追溯性。 位置上,这是整体链路的前提:没有外部可检索材料,就谈不上“增强”。
索引链路决定“能不能被找到”:分块→向量化→存储 直观上,文档不切块就像一本书只给目录,查询时很难精准翻到某一页;切块后再向量化,才能用相似度快速定位。 专业上,chunking 控制语义粒度与上下文可拼接性;embedding 把文本映射到稠密向量空间;向量库提供相似性搜索与 TopK 召回。 位置上,这是检索阶段的地基,错误的分块/入库会让后面的重排与生成无从补救。
检索是“召回候选”,不是“给答案”:TopK 只是候选集合 直观上,检索更像“先把可能相关的资料捞上来”,而不是直接产出结论。 专业上,Retriever 以相似度或打分函数返回候选文档块集合;生成器在 Query + Context 的条件下完成最终回答。 位置上,这是 Query/Retriever/Generation 三段式的分工边界,混淆会造成调参方向错误。
稀疏与稠密的互补:词项命中 vs 语义邻近 直观上,稀疏检索擅长“字面一致”和精确约束,稠密检索擅长“意思相近但不共词”。 专业上,稀疏检索用 TF-IDF、BM25 等基于倒排索引的词项统计;稠密检索用神经编码得到低维稠密向量并用余弦/内积匹配。 位置上,这是混合检索与后续重排策略的依据:先覆盖,再筛精。
重排把“相关性”做第二次判决:召回宽、精排严 直观上,第一次检索宁可多捞,重排负责把真正有用的片段排到最前,减少噪声进入上下文。 专业上,重排可用传统打分、Bi-Encoder/Cross-Encoder、或用 LLM 生成式评分;实践中常见“Bi-Encoder 大规模召回 + Cross-Encoder 小规模重排”。 位置上,这是 Post-Retrieval 的核心手段,直接影响最终送入模型的上下文质量。
进阶形态是在链路各点“加模块”:Pre-Retrieval 与 Post-Retrieval 直观上,问题问得不好就先改写,资料捞得不准就再重排/压缩/融合;不是换一个更大的模型就能解决。 专业上,Advanced RAG 引入检索前优化(查询重写等)与检索后优化(重排、压缩、融合);Modular RAG 把这些能力拆成可组合模块;Graph/Agentic 在多个环节介入扩大覆盖与推理能力。 位置上,这是从“朴素能跑”走向“工程可用、效果可控”的分水岭。
四、关键术语与概念对齐
- RAG(检索增强生成):在生成前检索外部资料并注入上下文,让回答依赖可引用材料而非仅靠参数记忆;不等于微调或训练模型权重。
- Embedding(向量化/嵌入):把文本编码成稠密向量用于相似度检索;不等于关键词匹配或倒排索引。
- Chunking(分块):把文档拆成可检索与可拼接的片段,控制语义粒度与上下文组织;不等于简单按字符截断而不考虑语义边界。
- Sparse Retrieval(稀疏检索):基于词项统计(TF-IDF、BM25)与倒排索引的匹配;不等于“落后技术”,在精确约束上常更强。
- Dense Retrieval(稠密检索):用神经编码得到稠密向量并做相似度匹配;不等于“更准确”,在强条件过滤与可解释性上有短板。
- TopK 召回:检索返回的候选片段集合;不等于最终证据集合,仍需要重排与筛选。
- Reranking(重排):对候选片段二次打分排序以提升相关性;不等于扩大召回范围,目标是减少噪声。
- Query Rewriting(查询重写):把用户问题改写成更利于检索的表达(规范化、同义改写、泛化、多查询、分解);不等于改变用户意图本身。
- GraphRAG:将文本抽取为实体-关系图并形成社区层级与报告,用结构化信息增强检索与汇总;不等于只是在向量检索上“加一层图数据库”。
五、结构全景层:原文笔记(高密度保真)
RAG 的提出动机指向参数知识的局限,并用外部可检索记忆缓解过时与幻觉问题。
- 文本指出 LLM 知识存于参数且难及时更新,容易出现幻觉。
- 方案是引入外部非参数化记忆并在生成时结合检索结果,提高准确性与可追溯性。
RAG 的直观流程被描述为“先把文档处理入库,查询时检索辅助生成”。
- 文档会经历分块、向量化并存储到向量数据库。
- 查询阶段召回 TopK 文档块,与提示词一起交给模型生成最终答案。
RAG 流行的价值点被归纳为数据新鲜度、缓解幻觉与通用模型专业化。
- 它能补足训练语料库过时的问题,尤其适合时间敏感与个人/企业知识库。
- 它能通过上下文参照显著缓解幻觉,并提升垂直领域可靠性。
基础架构被拆为 Query / Retriever / Generation 三阶段,并给出端到端实施步骤。
- 数据先分块、embedding 入库,查询也 embedding 后做相似性搜索。
- 将 top-k 文档块原始内容拼接进上下文,再由大语言模型生成答案。
检索方式被划分为稀疏检索与稠密检索,并指出 RAG 常用稠密检索但趋向融合。
- 稀疏检索基于词频等显式统计,用稀疏向量表示文本并进行匹配。
- 稠密检索用神经网络将文本编码为低维稠密向量,用相似度匹配语义相近文本。
稀疏检索的痛点与改进方法被明确:词频不足以衡量重要性,TF-IDF 与 BM25 解决权重问题。
- 文本给出词表示例说明稀疏向量高维且多为 0,并指出常见词会被高频误判为重要。
- TF-IDF 引入逆文档频率降低常见词权重,BM25 进一步考虑词频饱和与长度归一化,并依赖倒排索引。
稠密检索强调“语义表示”与维度差异,并举例说明 embedding 的本质。
- 稠密向量各维多为浮点非零,维度通常几十到几千,区别于词表规模导致的超高维稀疏向量。
- embedding 被描述为预训练模型学习出的语义表示,可用可视化工具展示相近词在空间中的邻近。
常见稠密检索/排序方法被表格化,并给出 Bi-Encoder 与 Cross-Encoder 的工程搭配。
- DPR、Contriever 属于 Bi-Encoder 召回,Cross-Encoder 用于精排但成本高,ColBERT 走 late interaction,SPLADE 结合稀疏与神经。
- 文本强调常见实践是快速召回后再用重排模型提高排序质量。
融合检索(Hybrid Retrieval)被定义为稀疏+稠密结合,并强调技术选择应由场景驱动。
- 典型做法是 BM25 与向量检索共同召回,再用 Cross-Encoder 等进行重排。
- 文本强调“不会因为技术而技术”,并举出可能需要数据库+ES+向量+重排的组合。
进阶 RAG 被列出多个增强点:标量+向量、重排、多跳、图增强,并给出范式划分。
- 标量检索可结合传统数据库或 ES 与向量检索并用。
- 重排用于在送入模型前重新评分排序, 多跳用于复杂查询,Graph-RAG 用图扩展能力。
Advanced/Modular/Graph/Agentic 的差异被解释为对链路环节的优化与工程化模块化。
- Advanced 引入 Pre-Retrieval(查询重写等)与 Post-Retrieval(重排、压缩、融合等)。
- Modular 把能力拆成最小模块自由编排,Graph 以图结构参与多个环节,Agentic 将 RAG 扩展为可多轮决策的自主流程。
查询重写被作为检索前优化重点,并给出五类策略与示例。
- 规范化重写让问题更标准,同义改写补足上下文省略与表述差异,Step-Back 做泛化以扩大检索范围。
- Multi-query 从多角度生成多个查询,问题分解把复杂查询拆成原子问题并可用 MapReduce 汇总。
检索结果重排被给出三类实现路径,并展示 LangChain + FlashRank 的示例效果差异。
- 重排可用传统打分、语义匹配模型(双塔/交叉编码器)、或 LLM 生成式评分排序。
- 示例中先检索 k=20,再用 ContextualCompressionRetriever + FlashrankRerank 得到不同的 Top 文档集合。
GraphRAG 被定义为结构化分层的 RAG,并详细描述索引与检索两阶段及四种查询模式。
- 索引阶段包括 TextUnits 切分、文档引用关系、实体关系抽取与图摘要、图最终化、声明/共变量提取、Leiden 社区创建、文本单元聚合关联、社区报告生成与多类文本嵌入。
- 检索阶段包括 Global Search(社区报告 MapReduce)、Local Search(实体向量检索并融合实体/关系/文本单元/社区摘要/声明)、DRIFT(HyDE 风格虚拟答案+分解+循环本地搜索+Reduce)、Basic Search(文本单元向量检索)。
六、如何把这个内容讲清楚给别人?
最容易卡住的点是:很多人把 RAG 想成“搜索一下再回答”,却没有意识到它是一条链路——任何一环(分块、入库、召回、重排、拼上下文)做错,都会把错误放大到生成结果里。讲解时抓住一条主线就够:检索只提供候选证据,生成只在证据上做组织与推理;让对方先接受这个分工边界,再讨论稀疏/稠密、重排、重写这些局部优化就顺了。
可以快速带过的内容是:各类检索模型名录与算法细节(DPR、ColBERT、Leiden 等)——它们更多是实现选型,不影响对“为什么需要两阶段(召回+精排)”“为什么需要预处理与后处理”的核心理解。
最小示例: 公司知识库里有两段话——A 段写“报销需在 30 天内提交”,B 段写“差旅报销需附发票原件”。员工问:“出差报销要注意什么?”
- 只做向量召回时,可能只捞到 B 段,模型就回答“附发票原件”,漏掉 30 天期限。
- 加上多查询或问题分解(“报销期限是什么”“材料要求是什么”)后,检索更容易同时召回 A+B;再用重排把“期限”与“材料”都排到前面,最终回答才会同时覆盖“30 天内提交 + 需附发票原件”,而且能指向对应片段作为依据。
七、实践与使用视角的结论
适合的场景
- 知识会变化、需要最新依据的问答(企业制度、产品文档、项目资料)。
- 需要可追溯来源、能落到文档证据的咨询与助理类任务。
- 通用模型进入垂直领域时,用领域知识库快速“专业化”的场景。
不适合的场景
- 没有可用高质量语料、或者语料本身高度噪声与互相矛盾的场景。
- 任务核心是强推理/强计算,但外部资料对答案贡献很小的场景(检索会徒增噪声与成本)。
最常见、也最危险的错误用法
- 只追求“能搜到”,把大量 TopK 片段直接塞进上下文,既不重排也不压缩,最后让模型在噪声里做选择题。
最低使用原则:先保证“能稳定召回正确片段”,再把“进入上下文的片段数量压到最小且最相关”。
八、最终总结
- RAG 的关键不是“多检索”,而是把外部材料作为可引用上下文,让生成依赖证据而非仅靠参数记忆。
- 索引链路(分块、向量化、存储)决定可检索性,检索链路(召回、重排、拼接)决定可用性。
- 稀疏检索擅长词项与强约束,稠密检索擅长语义邻近,融合检索常用于兼顾覆盖与精度。
- 查询重写解决“问得不利于检索”,重排解决“捞到了但顺序不对/噪声太多”。
- GraphRAG 通过实体关系与社区报告把文本结构化,提供从全局到本地、从单跳到多步的多种检索范式。
-- End --