15种高级rag技术从预检索到生成

RAG 跑通不难，难的是答不准、答不全、答得慢：明明资料里有，模型就是没检索到；检索到了，几段噪声把答案带偏；多跳问题一次检索根本不够。这时候就会去看各种「高级技术」，名词一大堆却不知道各自插在链路的哪一环。这篇按预检索、检索、后处理、生成四个阶段把技术分位，给判断标准和排查顺序，具体数值去站内页面核对。

RAG 跑通不难，demo 阶段感觉什么都能答。真上线才发现问题五花八门：明明资料库里白纸黑字写着，模型就是没检索到；好不容易检索到了，夹着几段无关内容，答案就被带偏；用户问个需要绕两下的问题，一次检索根本不够用。这时候人会开始搜「高级 RAG 技术」，然后被一堆名词砸晕——假设性提问、混合检索、重排、自反思、多跳，听着都厉害，不知道该往哪插。

这篇不按名词首字母排序，按链路位置分。把一条 RAG 请求拆成预检索、检索、后处理、生成四段，每项技术归到它真正起作用的那一段，先说你现在的失败样本长什么样，再决定动哪一段。具体模型价格、跑分、版本号这类会变的东西，正文里一律不写死，需要时到站内对应页面核对当时的数字。

先按阶段分位：一项技术插在链路哪里

选型最容易犯的错是「听说某技术好就往里塞」，结果塞在一个根本不起作用的环节上。先做定位：拿一批答错的真实问题，逐个看它错在哪一段，而不是先想加什么技术。同一项技术在不同文章里叫法可能不一样，混检索和融合排序经常被混着讲，先统一口径再谈选型，分不清的到站内技术栈图谱对名词。

• 先判断瓶颈落段，别上来就堆技术，顺序错了后面全是无用功
• 判断依据是失败样本，不是你觉得哪项技术高级
• 一次只加一项，加完在同一批问题上对比，几项一起上看不出是谁的功劳
• 延迟和成本敏感的场景，后处理那层比前面两层更值得抠

预检索阶段：分块、改写、扩展、元数据

预检索是整条链路的天花板：块切得不好，后面再贵的重排也救不回来。很多人调了半天生成提示词，其实问题出在分块——文档里一段完整说明被从中间切开，模型拿到半截话，怎么答都别扭。这一段值得花的时间，通常比后面几段加起来还多。

分块：按结构切还是按字数切

按固定字数切实现最简单，也最容易切断语义，适合格式统一的日志、工单这类正文。文档有明显标题层级、章节结构的，按结构切更稳：一个标题下的小节作为一块，块之间留一点重叠，避免答案正好卡在接缝处。块太大噪声多，块太小上下文断裂，具体多大要拿你的语料试，别照抄别人的参数。

查询改写与扩展

用户的口语提问和资料里的书面用词经常对不上，这是召回失败的高频原因。查询改写就是用一轮模型把口语问题转成更贴近资料表述的检索词，有时候还会生成几个变体分别去查。代价很实在：多一轮模型调用，延迟和成本都涨。什么情况下别用——问题本身就是专有名词或编号，改写反而把它改没了，这时候直接原样检索更准。

元数据、父子块、摘要索引

元数据过滤

给每块挂上来源、时间、分类等标签，检索时先按条件筛一遍，适合文档有明显时间或归属属性的场景

父子块

检索时用小块的精准度去命中，送回给模型时用大块补上下文，缓解块小断语义、块大噪声多

摘要索引

先检索摘要定位到章节，再取原文细读，适合长文档、报告类语料

这三样的共同前提是文档本身有结构或标签。纯散文、聊天记录这类没层级的语料，收益有限，硬上容易增加维护负担。判断方法：随机抽二十篇文档，看能不能人工填出稳定的元数据字段，填不出来就别急着上。

检索阶段：混合检索、多路召回、路由

检索阶段要解决的就一件事：把真正相关的内容放进候选池，并且位置别太靠后。向量召回擅长语义相近，用户换个说法也能命中；关键词召回擅长专有名词、编号、型号这类必须精确匹配的东西。两者单独用都有明显盲区，混着用通常比单吊一种稳。

• 向量召回：适合意图相近但用词不同的问法，对错别字和口语也宽容
• 关键词召回：适合产品编号、条款号、人名地名，精确匹配不会漏
• 混合检索：两路各查一遍再合并，命中率一般更稳，代价是查询次数翻倍
• 按问题类型路由：判断这是事实型还是流程型，路由到不同索引或不同知识库
• 多路召回融合：把多路结果合并成一份，要处理分数口径不一致的问题

多路召回融合里有个坑：不同召回方式的打分尺度不一样，直接按分数排序，等于悄悄给某一路上权重。稳妥做法是每路先各自取前几名，再做融合，而不是把原始分数混在一起比大小。路由同理，语料本来就分域（比如产品文档和售后政策分开）时效果好；语料混杂、边界模糊时，路由判断错了，整条链路直接走偏。

后处理阶段：重排、压缩、去重、裁剪

后处理是候选池到上下文之间的那道闸门，做的是「优中选优」和「省着用」。这一层最容易被过度设计：召回和排序还没理顺，就开始研究上下文压缩，等于地基没打好先装窗帘。顺序上，先保证召回里有对的东西，再保证排序把它排到前面，最后才考虑压缩和裁剪。

重排与压缩的分工

重排的工程实现要点站内已有专文讲得比较透，这里只说判断标准：拿一批「答案其实在候选里但没排上来」的失败样本去测，重排带来的提升能直接量化；没有这类样本，说明你的瓶颈不在排序，做了也看不出效果。压缩和去重一样，先有噪声导致答偏的实际案例再上。

裁剪要按预算来，别按感觉。最终塞几段、每段多长，取决于模型窗口上限和单次请求能承受的成本。成本怎么估算、不同模型的计价口径，到站内成本计算器页面看当时的数字，把数带回来算，比拍脑袋靠谱。

这一层的坑

• 压缩剪掉关键连接词，答案变得断章取义，剪之前留好回退开关
• 重排模型本身也有成本和延迟，别在高并发接口上默认开
• 去重按内容哈希做时，措辞不同但意思相同的块去不掉，要接受这个不完美
• 顺序反了最亏：先做压缩再做重排，等于把好东西也压掉一部分

生成阶段：引用、自检、多跳与多轮

生成阶段管的是「怎么用拿到的东西回答」。到这一步还能救回不少问题，前提是前面的上下文没跑偏。这一段的改动通常最便宜也最快见效，所以排查时经常被放在最后，其实可以先小成本试一轮提示词约束。

要求带出处

让模型在回答里标出每句话来自哪一段资料，有两个实际好处：一是能把「编得像」和「真有依据」分开，二是人工复核时有据可查。代价是回答会长一点，格式要求也更严，需要模型比较听话。什么情况下别用——纯闲聊式问答、用户根本不关心出处的场景，强制引用只会让回答变啰嗦。

自检、多跳与多轮

自检类做法让模型先判断「手上的资料够不够回答这个问题」，不够就再查一轮。多跳问题（答案需要串起两三个事实）上这类做法确实有用，单跳事实问答上基本是白花钱——明明一段话就能答，非要绕两圈。多轮和工具化检索把检索变成可反复调用的动作，灵活但调用次数不可控，必须配上步数上限和成本上限，否则一个复杂问题能把预算吃穿。

生成阶段调不动的时候，先回头看提示词里有没有明确约束「只用给定资料回答，资料里没有就说没有」。这条约束看着朴素，能拦掉相当一部分张口就编的回答。别急着上复杂策略，先把这条加上测一批。

选型顺序与不适用场景

高级技术不是越多越好，堆上去的每一项都在增加延迟、成本、维护面和出错点。下面是推荐的排查顺序，从上往下走，卡在哪一步就解决哪一步，别跳步。

1. 第一步：确认召回有没有捞失败样本，看正确片段在不在召回结果里。不在，检查分块策略、查询改写、召回路数，改完用同一批样本复测。
2. 第二步：确认排序对不对正确片段在候选里但位置靠后，上融合排序或重排，用「答案在候选但没排上来」的样本量化提升。
3. 第三步：确认上下文够不够模型答不全但资料里有，看塞进去的段数是不是太少，或者关键块被压缩剪没了，先关压缩再对比。
4. 第四步：最后动生成策略前面都顺了还是跑偏，才考虑引用、自检、多轮，这些改动小、见效快，但救不了召回层面的缺失。

评测要有固定的问题集，覆盖简单事实、多跳、边界情况各若干条，每次都跑同一批，不然感觉会骗人。具体评测方法、榜单和跑分到站内测评榜单页面看当时的数字，别拿单次手感当结论——同一条链路，样本换一批结论可能就反过来。

什么情况下不适用

• 语料量很小，几百篇以内，检索本身就准，堆高级技术不如把分块和提示词弄干净
• 问题集中在单文档抽取，一次检索一段就够，多路召回和重排基本是空转
• 延迟敏感且预算紧，多轮检索、自检反思这类多一次模型调用的做法要慎重
• 语料格式混乱、没有稳定结构，元数据过滤和父子块落地成本高，先解决数据质量

落地清单：把技术变成可维护的配置

技术选对了只是开始，能不能维护下去才决定它活多久。核心原则两条：能配的别写死，能观测的别偷懒。把每项技术做成开关加参数，按流量灰度，出问题能一键回退；每次请求记录命中了哪条链路、召回几段、用了多少 token，日志字段怎么设计站内有专文。定期翻失败样本，判断是技术没生效、参数没调对，还是这个语料压根不适合这项技术。