RAG还在用基础版？句子滑动窗口·自动合并·索引·融合·CRAG·Self-RAG全讲透（附代码）

📢 本文是「108张AI知识卡片·大模型通关手册」系列第 7 篇。上一篇把 RAG 的 6 个调优旋钮（相似度/意图识别/召回/ReRank/排序/混合检索）拧了一遍，效果确实提了——但调来调去，还是"检索→生成"一条路走到黑。这篇讲的是更根本的升级：让检索结果不再被 Chunk 边界截断、让多路结果更聪明地合并、让系统自己判断检索结果靠不靠谱、甚至自己决定要不要检索——从"调优"到"自省"，RAG 才算真正进阶。

目录

• TL;DR 太长不看
• 一、句子滑动窗口检索：Chunk边界截断语义？滑动一下就解决
• 二、自动合并检索：小粒度检索，大粒度回溯
• 三、索引：亿级数据的检索速度，全靠它
• 四、融合：多路检索结果怎么合并才聪明
• 五、CRAG：检索不靠谱？自动纠正拒绝垃圾上下文
• 六、Self-RAG：让大模型自己决定要不要检索
• 七、一张图串起RAG进阶链路
• 八、代码：CRAG + Self-RAG 实战
• 写到最后
• 系列导航 & 持续更新

TL;DR 太长不看

⚡30 秒版：先记这 7 条，细节往下翻。

• 🔴句子滑动窗口：Chunk 边界把一句话切成两半？滑动窗口让检索片段前后延伸，上下文不断裂。
• 🟠自动合并检索：小 Chunk 检索精准，大 Chunk 上下文完整——自动合并两者优势，按需回溯。
• 🟡索引：HNSW 图索引快但费内存、IVF 分桶省内存但精度略降、PQ 压缩向量省空间——选错索引，亿级数据直接卡死。
• 🟢融合：多路召回结果怎么合并？RRF 看排名、互信息融合看分数——量纲不同时用 RRF，同量纲时用加权融合。
• 🔵CRAG：检索结果不靠谱？用 LLM 评估相关性，不相关的纠正或重检索，拒绝垃圾上下文污染生成。
• 🟣Self-RAG：让大模型自己决定要不要检索、检索结果要不要用、要不要重检索——自省式 RAG。
• 🎁进阶口诀：滑动窗口保上下文 → 自动合并选粒度 → 索引撑速度 → 融合合多路 → CRAG 纠错 → Self-RAG 自省。

一、句子滑动窗口检索：Chunk边界截断语义？滑动一下就解决

你把一篇文档切成 512 字的 Chunk，有一条关键信息恰好跨在第 3 段末尾和第 4 段开头——被一刀切成两半，检索时哪段都搜不到完整语义。这不是模型的问题，是切分的锅。

句子滑动窗口检索解决的核心问题：固定 Chunk 边界会截断语义。滑动窗口让每个检索片段都带上前后文的"余量"，不再因为切分位置不对而丢失关键信息。

它到底在干嘛（机制层）：传统 Chunk 是"硬切"——按固定 token 数切分，切完就完。句子滑动窗口的做法是：以句子为最小切分单位（不会把一句话切成两半），同时设置一个窗口大小（如 3 句）和滑动步长（如 1 句）。每次取连续 3 句作为一个检索片段，然后向前滑动 1 句，取下一段 3 句——相邻片段有 2 句重叠。这样，即使关键信息跨越两个传统 Chunk 的边界，在滑动窗口中它也会完整出现在某个片段里。

你能感受到什么（体感层）：假设文档有 5 句话 A-B-C-D-E，窗口=3句，步长=1句，检索片段是：ABC、BCD、CDE。关键信息在 B 和 C 之间？ABC 和 BCD 都完整包含它。传统硬切（AB | CDE）呢？B 和 C 被分到两个 Chunk，哪个都不完整。重叠的代价是存储量增加——5 句话生成了 3 个片段而非 2 个，但换来的是"不漏语义"。

🎛️ 动手感受：硬切 vs 滑动窗口

操作：同一篇文档，分别用固定 512 token 切分 vs 句子滑动窗口（窗口=3句，步长=1句），搜一个跨 Chunk 边界的问题。
你会看到：

• 硬切：关键信息被分到两个 Chunk，检索时哪个 Chunk 的相似度都不够高，排不进 Top-K。
• 滑动窗口：关键信息完整出现在某个重叠片段中，相似度直接拉满。
• 变化说明了什么：不是模型不行，是切分位置不对——滑动窗口用"重叠"换"完整"，代价可控、收益明显。

🤔 想一想

重叠越多，存储越大——窗口=5句、步长=1句的重叠率远高于窗口=3句、步长=2句。你的业务能容忍多少存储膨胀？如果文档库有 1000 万篇，重叠带来的存储增量可不是小数目。

🔗 顺着他想：滑动窗口解决了"边界截断"，但检索回来的片段还是固定粒度的——有时你需要更粗的粒度（一整段），有时需要更细的粒度（一句话）。能不能"检索时用小粒度，回溯时自动合并成大粒度"？这就是自动合并检索做的事。

二、自动合并检索：小粒度检索，大粒度回溯

滑动窗口解决了"边界截断"，但粒度问题还在——小 Chunk 检索精准但上下文不够，大 Chunk 上下文完整但检索噪声多。能不能两全其美？

自动合并检索解决的核心问题：检索精度和上下文完整性之间的矛盾。它用小粒度 Chunk 做检索（精准），命中后自动回溯到包含该 Chunk 的大粒度文档（完整上下文），两者优势兼得。

它到底在干嘛（机制层）：自动合并检索的核心是层级索引——同一篇文档被切成多个粒度：叶子节点（小 Chunk，如 128 token）、中间节点（段落级，如 512 token）、根节点（全文或章节级）。检索时只在叶子节点（小 Chunk）上做相似度匹配——小粒度精准，噪声少。命中某个叶子节点后，系统自动向上回溯：如果同一父节点下的多个叶子节点都被命中，说明这一整段都相关，直接返回父节点（大粒度）；如果只有零星叶子节点命中，就只返回那些叶子节点（小粒度）。这就是"自动合并"——系统根据命中密度，自动决定返回的粒度。

你能感受到什么（体感层）：问"退货政策和退货流程有什么区别"——小 Chunk 检索命中了"退货政策"和"退货流程"两个叶子节点，它们恰好属于同一个段落节点，系统自动合并返回整个段落，上下文完整。如果只问"退货政策"，只命中一个叶子节点，系统就只返回那个小 Chunk，不浪费上下文窗口。“按需给量”——问题涉及的范围大，返回大粒度；问题聚焦，返回小粒度。

🎛️ 动手感受：固定大 Chunk vs 自动合并

操作：同一批文档，分别用固定 512 token Chunk 检索 vs 自动合并检索（叶子128 token + 段落512 token），对比两种问题的结果。
你会看到：

• 固定大 Chunk：宽泛问题命中完整段落✅，但精准问题也返回整个段落，混入大量无关内容❌。
• 自动合并：宽泛问题自动合并返回大段落✅，精准问题只返回小 Chunk✅。
• 变化说明了什么：自动合并不是"更聪明的切分"，是"按需决定返回粒度"——同一个索引，不同问题自动适配不同粒度。

🤔 想一想

自动合并的前提是构建层级索引——同一篇文档要切多个粒度，索引构建成本和存储都增加。如果你的文档库更新频繁（如新闻），每次更新都要重建层级索引，这个成本你愿意承担吗？

🔗 顺着他想：层级索引建好了，检索速度靠什么保证？亿级文档、多层级索引，暴力扫描肯定不行——这就引出了"索引结构"的话题：HNSW、IVF、PQ，选错索引，亿级数据直接卡死。

三、索引：亿级数据的检索速度，全靠它

100 万条向量做暴力搜索，每次查询要算 100 万次相似度——延迟从毫秒变秒级。1 亿条呢？分钟级。索引结构就是让检索从"全量扫描"变成"近似查找"的关键。

索引解决的核心问题：向量数量大到暴力搜索不可接受时，怎么快速找到近邻？索引结构通过"空间换时间"或"精度换速度"，让亿级数据的检索延迟保持在毫秒级。

它到底在干嘛（机制层）：三大主流索引结构各有取舍。HNSW（分层可导航小世界图）：把每个向量连成一张多层图，检索时从顶层入口开始，逐层向下贪心搜索——跳过大量不相关区域，直达近邻。速度快（log 级）、精度高，但内存占用大（要存图结构）。IVF（倒排文件索引）：先把向量空间用 K-Means 分成 N 个簇（桶），检索时只搜索离查询最近的几个簇——把全量搜索变成"局部搜索"。省内存、速度快，但精度取决于簇的划分质量。PQ（乘积量化）：把高维向量切成 M 个子空间，每个子空间用码本量化成短编码——向量从 1024 维 float 压缩成几十字节的编码。存储暴降 10-50 倍，但精度有损。实战组合：IVF + PQ 是最经典的搭配——IVF 先缩小搜索范围，PQ 再压缩向量加速距离计算，亿级数据毫秒级检索。

你能感受到什么（体感层）：10 万条向量，暴力搜索和 HNSW 差别不大——都很快。但到 1000 万条，暴力搜索延迟飙到秒级，HNSW 仍在毫秒级。到 1 亿条，HNSW 内存可能撑不住，换成 IVF+PQ，牺牲 5% 精度换回毫秒级延迟——这个交换在生产环境里几乎总是值得的。

🎛️ 动手感受：不同索引的延迟对比

操作：同一批 100 万条向量，分别建 HNSW / IVF / IVF+PQ 索引，测查询延迟和召回率。
你会看到：

• HNSW：延迟 2ms，召回率 98%——快且准，但内存占用 4GB。
• IVF：延迟 5ms，召回率 95%——稍慢稍低精度，但内存只要 2GB。
• IVF+PQ：延迟 3ms，召回率 92%——精度有损但存储暴降，内存只要 500MB。
• 变化说明了什么：没有"最好的索引"，只有"最适合你场景的索引"——数据量、内存预算、精度要求，三个维度决定选择。

🤔 想一想

PQ 量化有损，损失的那 5-8% 精度到底影响什么？如果你的业务是"法律条文检索"，5% 的精度损失可能意味着漏掉关键法条——不可接受。如果是"商品推荐"，5% 的损失用户根本感知不到。精度换速度，值不值，取决于业务对"漏答案"的容忍度。

🔗 顺着他想：索引解决了"单路检索的速度"问题，但上一篇讲的混合检索是两路——向量路和关键词路各出 Top-K，合并后统一排序。合并策略怎么选？RRF 和互信息融合有什么区别？这就是"融合"要讲的事。

四、融合：多路检索结果怎么合并才聪明

向量路召回 Top-20，关键词路召回 Top-20，两路合并 40 条——但两路的分数量纲不同（余弦相似度 0-1，BM25 分数 0-∞），怎么排谁前谁后？

融合解决的核心问题：多路检索结果的分数不可比，怎么合并成一个统一排序？融合策略不看绝对分数，看相对排名——或者把分数归一化后再加权。

它到底在干嘛（机制层）：两种主流融合策略。RRF（Reciprocal Rank Fusion）：不看分数，只看排名。每条文档的 RRF 分数 = Σ 1/(k+rank_i)，k 通常取 60。两路都排得靠前的文档天然得高分——"两路共识"比"单路高分"更可靠。RRF 的优点是量纲无关（余弦和 BM25 的分数不需要归一化），缺点是丢了分数信息（排名第 1 和第 2 的差距可能巨大，但 RRF 只看排名差 1）。互信息融合（Score Fusion）：先对每路的分数做归一化（Min-Max 或 Z-Score），统一到同一量纲，再按权重加权：final_score = α×norm(向量分) + β×norm(BM25分)。优点是保留了分数信息，缺点是归一化方法选择影响结果、极端分数会扭曲归一化。

你能感受到什么（体感层）：向量路第 1 名相似度 0.95，第 2 名 0.52——差距巨大；关键词路第 1 名 BM25 分 28.3，第 2 名 27.1——差距微小。RRF 不管这些差距，只看"谁排前面"；Score Fusion 会把向量路第 1 名的巨大优势体现出来。如果你的场景里"第 1 名远超其他"是常态（如精确匹配场景），Score Fusion 更合适；如果分数分布比较均匀，RRF 更稳定。

🎛️ 动手感受：RRF vs Score Fusion

操作：同一批双路召回结果，分别用 RRF 和 Score Fusion（Min-Max归一化 + 等权）合并，看 Top-5 差异。
你会看到：

• RRF：两路都排得靠前的文档排前面，“共识优先”。
• Score Fusion：某路分数特别高的文档排前面，“高分优先”。
• 变化说明了什么：RRF 更稳定（不受极端分数影响），Score Fusion 更灵敏（能捕捉"远超其他"的信号）——选哪个取决于你的数据分布。

🤔 想一想

RRF 的 k 值怎么选？k=60 是经验值，k 越大，排名差异的影响越小（更平滑），k 越小，排名靠前的优势越大（更陡峭）。k=10 和 k=100 的结果可能差很多——这个参数没有万能值，要靠你的数据调。

🔗 顺着他想：融合做完，多路结果合并成了一个统一排序——但这个排序就一定靠谱吗？如果某一路的召回结果全是垃圾呢？融合只会让垃圾的排名稍微低一点，不会把它踢出去。那"检索结果靠不靠谱"谁来评估？这就是 CRAG 要解决的问题。

五、CRAG：检索不靠谱？自动纠正拒绝垃圾上下文

检索回来 5 条文档，3 条是垃圾——但模型不知道，照单全收，生成出来的答案一半是幻觉。问题不在模型，在"检索结果没过质检"。

CRAG（Corrective RAG）解决的核心问题：检索结果可能不靠谱，但基础 RAG 无条件使用所有检索结果。CRAG 加了一道"质检"——用轻量评估器判断检索结果的相关性，靠谱的用，不靠谱的纠正或重检索，拒绝垃圾上下文污染生成。

它到底在干嘛（机制层）：CRAG 的流程在"检索"和"生成"之间加了一个评估-决策-纠正循环。检索结果回来后，先用轻量评估器（小模型或 LLM）给每条文档打相关性分。然后根据分数做决策：**高分（靠谱）**→直接送进生成；**中分（半靠谱）**→纠正：对文档做精炼（提取关键句、去噪），再送进生成；**低分（垃圾）**→丢弃，触发重检索（换关键词/换检索策略再搜一次）。整个流程是：检索→评估→决策→{直接用/纠正/重检索}→生成。

你能感受到什么（体感层）：问"2024 年退税新政策"，检索回来 3 条：1 条 2024 年新政策（高分，直接用）、1 条 2020 年旧政策（中分，纠正：提取"2020 年"标记为过时信息）、1 条完全不相关的"退税诈骗新闻"（低分，丢弃+重检索）。CRAG 让模型只吃"经过质检的食材"，而不是"检索到什么就吃什么"。

🎛️ 动手感受：开/关 CRAG 对比

操作：故意构造一个"检索结果大部分不靠谱"的场景（如问冷门问题），开/关 CRAG，看生成质量差异。
你会看到：

• 关 CRAG：模型把垃圾文档也当知识用，生成出包含错误信息的答案。
• 开 CRAG：评估器识别出垃圾文档，丢弃后重检索或直接用模型自身知识生成，答案更准确。
• 变化说明了什么：CRAG 不是让检索更准，是让"不准的检索结果不污染生成"——质检这道关，拦住的是幻觉的源头。

🤔 想一想

CRAG 的评估器本身也有误判风险——把靠谱的文档判为垃圾丢弃，比保留垃圾更糟（丢了正确答案）。评估器的精度怎么保证？用大模型做评估器精度高但延迟大，用小模型快但精度低——这个"评估器的评估"，是 CRAG 的隐藏成本。

🔗 顺着他想：CRAG 是"检索后评估"，但有些问题根本不需要检索——“1+1等于几"你检索什么？如果模型能自己判断"这个问题要不要检索”，不检索的直接生成，需要检索的才走 RAG 流程，效率会高得多。这就是 Self-RAG 的思路。

六、Self-RAG：让大模型自己决定要不要检索

每次提问都检索？问"1+1等于几"也去搜一遍文档库——浪费延迟还可能引入噪音。问"2024年退税新政策"却不检索——模型只能靠训练数据猜，大概率过时。能不能让模型自己判断？

Self-RAG 解决的核心问题：不是所有问题都需要检索，也不是所有检索结果都该用。Self-RAG 让大模型在生成过程中自己插入"反思标记"，决定是否检索、检索结果是否相关、是否需要重检索——自省式 RAG。

它到底在干嘛（机制层）：Self-RAG 在生成流程中插入了 3 种反思标记（Reflection Tokens）。① 检索标记[Retrieve]：模型生成前先判断"这个问题需要检索吗？"——事实性问题（“2024年退税政策”）→需要检索；常识/推理问题（“1+1等于几”）→不需要，直接生成。② 相关性标记[ISREL]：检索结果回来后，模型判断"这条文档和问题相关吗？"→相关则使用，不相关则丢弃。③ 支持性标记[ISSUP]：生成答案后，模型判断"这个答案有检索文档支持吗？"→有支持则输出，无支持则重检索或修正。整个流程：问题→[Retrieve?]→{检索/不检索}→[ISREL?]→{使用/丢弃}→生成→[ISSUP?]→{输出/重检索}。

你能感受到什么（体感层）：问"Python 的 list 怎么排序"——模型判断这是常识，不需要检索，直接生成list.sort()，省了检索延迟。问"LangChain 0.3 的最新 API"——模型判断这是时效性问题，需要检索，走 RAG 流程，拿到最新文档。问"量子计算的未来"——模型判断这是开放性问题，不需要精确检索，直接用自身知识生成。Self-RAG 让每个问题走最合适的路，而不是"一刀切全检索"或"一刀切全不检索"。

🎛️ 动手感受：Self-RAG 的三种决策路径

操作：分别输入三类问题——常识问题、时效性问题、开放性问题，观察 Self-RAG 的决策路径。
你会看到：

• 常识问题："1+1等于几"→[Retrieve: No]→直接生成→快且准。
• 时效性问题："2024年退税新政策"→[Retrieve: Yes]→检索→[ISREL: Yes]→生成→[ISSUP: Yes]→输出。
• 开放问题："AI的未来"→[Retrieve: No]→直接生成→省检索延迟。
• 变化说明了什么：Self-RAG 不是"更准的 RAG"，是"更聪明的 RAG"——它让系统自己决定走哪条路，而不是人写规则。

🤔 想一想

Self-RAG 的反思标记需要模型"学会"什么时候该插入——这需要专门训练或微调。如果你的模型没经过 Self-RAG 训练，它不会自发地输出[Retrieve]标记。用通用模型"模拟"Self-RAG（通过 Prompt 引导模型判断是否需要检索）可行吗？精度够吗？延迟呢？

🔗 顺着他想：Self-RAG 让模型自己决定"要不要检索"，但检索策略本身（向量检索还是关键词检索、K 设多少、要不要混合检索）还是人定的。如果模型连"用什么策略检索"也能自己决定呢？那就是更远的前沿——自适应检索策略，目前还在研究阶段。

七、一张图串起RAG进阶链路

6 个高阶旋钮串成一条从"切分"到"自省"的完整链路：

文档入库 │ ① 句子滑动窗口切分 ← 以句子为单位+重叠，保语义不断裂 │ ② 层级索引构建 ← 叶子/段落/章节多粒度，支撑自动合并 │ ③ 索引结构选择 ← HNSW(快准贵)/IVF(中)/IVF+PQ(省量大) │ 用户提问 │ ④ 多路召回+融合 ← 向量路+关键词路，RRF/Score Fusion合并 │ ⑤ CRAG评估-纠正 ← 检索结果过质检：靠谱用/半靠谱纠正/垃圾丢弃重检索 │ ⑥ Self-RAG自省 ← 模型自判：要不要检索？结果相关吗？答案有支撑吗？ │ Top-N → 拼进 Prompt → 大模型生成

进阶口诀：

• 滑动窗口保上下文——Chunk 边界不再截断语义。
• 自动合并选粒度——小粒度检索精准，大粒度回溯完整。
• 索引撑速度——亿级数据毫秒级，选错索引直接卡死。
• 融合合多路——RRF 量纲无关看排名，Score Fusion 保留分数信息。
• CRAG纠错——检索结果过质检，垃圾不进生成。
• Self-RAG自省——模型自己决定要不要检索，按需走最合适的路。

八、代码：CRAG + Self-RAG 实战

上一篇跑了混合检索 + RRF 融合，这篇加两个高阶升级：CRAG 评估-纠正和Self-RAG 自省决策。

fromopenaiimportOpenAIimportnumpyasnp client=OpenAI(api_key="你的KEY",base_url="https://api.openai.com/v1")docs=["2024年退税新政策：个税起征点不变，专项附加扣除标准提高","2020年退税政策：个税起征点5000元","退税诈骗案例：某市民被骗10万元","Python的list排序用list.sort()方法"]defembed(text):r=client.embeddings.create(input=text,model="text-embedding-3-small")returnnp.array(r.data[0].embedding)vecs=[embed(d)fordindocs]# ① Self-RAG: 模型自判是否需要检索q="2024年退税新政策是什么"need_retrieval=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"system","content":"判断问题是否需要检索外部知识。事实性/时效性问题回答YES，常识/推理问题回答NO。只输出YES或NO。"},{"role":"user","content":q}]).choices[0].message.content.strip()ifneed_retrieval=="YES":# ② 向量检索qv=embed(q)cos_sims=[qv @ v/(np.linalg.norm(qv)*np.linalg.norm(v))forvinvecs]top_indices=np.argsort(cos_sims)[::-1][:3]retrieved=[docs[i]foriintop_indices]# ③ CRAG: 评估检索结果相关性eval_prompt="给以下(问题,文档)对的相关性打1-10分，只输出数字。\n"fordinretrieved:eval_prompt+=f"问题：{q}| 文档：{d}\n"scores=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"user","content":eval_prompt}]).choices[0].message.content# ④ 只用高分文档生成context="\n".join(retrieved[:2])# 简化：取前2条ans=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"system","content":"只根据参考资料回答，资料不足就说不确定"},{"role":"user","content":f"参考资料：{context}\n问题：{q}"}]).choices[0].message.contentprint(f"[检索]{ans}")else:# ⑤ 不检索，直接生成ans=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"user","content":q}]).choices[0].message.contentprint(f"[直接生成]{ans}")

这段代码实现了 Self-RAG 的核心逻辑：先让模型判断是否需要检索，需要则走 CRAG 流程（检索→评估→过滤→生成），不需要则直接生成。生产环境要做的升级：评估器换成真正的 Cross-Encoder、加上重检索逻辑、支持多轮自省循环。

写到最后

三篇 RAG 文章，从入门（核心链路）到进阶（6 个调优旋钮）到高阶（自省式决策），终于把 RAG 的完整图景画完了。基础 RAG 是"检索→生成"，进阶 RAG 是"检索→重排→生成"，高阶 RAG 是"检索→评估→纠正→自省→生成"——每一步升级，都是让系统从"被动执行"变成"主动决策"。

写这三篇的时候我一直在想：RAG 的天花板到底在哪？CRAG 和 Self-RAG 已经让系统会"反思"了，但反思的精度取决于评估器的精度，评估器的精度又取决于训练数据——这个循环能走多远？也许真正的突破不在于"让 RAG 更聪明"，而在于"让模型本身更懂什么时候该用 RAG"。这个话题，后续系列如果有机会再展开。

如果你读下来觉得真有用：

• 👍点个赞，让我知道 RAG 三部曲这种"从入门到高阶一条线"的写法值得继续；
• ⭐收藏起来，这篇的高阶概念（CRAG/Self-RAG）是 RAG 天花板级别的方案，回来翻的概率很高；
• 💬关注一下，下一篇开启新话题"Agent 实战"——从 ChatBot 到数字员工，AI 才真正从"问答"变成"行动"。
  –PC学习效果更好哦！
  

系列导航 & 持续更新

📚系列第 7 篇｜上一篇：RAG效果不好怎么调？6张图讲透相似度·意图识别·召回排序·ReRank·混合检索 ｜下一篇预告：2025最火方向——6张图搞懂AI Agent

如果这篇对你有帮助，点个👍收藏，RAG 高阶方案是天花板级别的知识，回来翻的概率很高。有问题欢迎在评论区交流，我会逐条回复。