自适应检索增强生成 Adaptive RAG

Adaptive RAG

根据用户问题的复杂度、领域、歧义度动态选择检索策略、召回深度和生成模型的 RAG 框架,避免所有问题一刀切使用相同链路。

详细解释

Adaptive RAG(Adaptive Retrieval-Augmented Generation) 一句话定义:所有普通 RAG 都是「任何问题先向量召回 Top-10 chunk → 塞给同一个模型生成」的固定流水线,而 Adaptive RAG 在流水线最前面加了一个「问题路由器」,先判断这个问题属于什么类型、什么难度,再动态选择最合适的检索-生成路径。最典型的反例:用户问「公司年假多少天」这种 FAQ 里就有的一句话答案,普通 RAG 也要走 embedding → 向量检索 → rerank → 送 10 个 chunk → GPT-4o 生成,成本 ¥0.05 延迟 800ms;Adaptive RAG 路由器判断「这是 FAQ 类,直接去 BM25 精确匹配 FAQ 库」,命中就直接返回原文,成本 ¥0.001 延迟 100ms。

2024 年斯坦福和 LlamaIndex 联合提出的「Self-RAG」和「Corrective RAG(CRAG)」是 Adaptive RAG 家族的两个开山之作。Self-RAG 的思路是让 LLM 在生成过程中「自我反思」:生成一半发现自己知识不够就主动触发一次检索;CRAG 的思路是在召回之后、生成之前加一个「召回质量评估器」——评估召回的 chunk 和问题相关性 ≥0.7 就直接送生成,0.3 至 0.7 之间就去用 HyDE 扩展查询再召回一轮,<0.3 直接判定「召回失败」,触发网络搜索或 Graph RAG 多跳。

唯元智创 的 RAG 路由器是开箱即用的:每条用户问题先跑 10 个维度的轻量分类器(是否含实体、是否多跳、是否含数字、是否代码、是否安全敏感、是否 FAQ 高频等),根据分类结果自动在 8 条预设路径中挑一条;用户也可以自己写路由规则(比如「包含 SKU 编号的问题强制走 SQL+RAG 混合」)。实测在真实企业客服场景,相同答案准确率下,Adaptive RAG 比固定路径 RAG 成本降 62%,P95 延迟从 1.8s 降到 0.7s。

问题路由器的七个常用决策维度(Adaptive RAG 路由表)

把每个用户问题打到下面的标签组合,就能决定走哪条路径:

标签维度判定信号触发路径选择
复杂度实体个数 ≥3 / 含「分别」「对比」「汇总」「排名」等聚合词召回深度 ×2,Graph RAG 开启,强制送强模型
答案确定性问「多少钱」「电话多少」「几月几号」等有唯一标准答案走精确匹配(BM25 + FAQ 库 + SQL),不生成,直接返回原文
时效性含「今天」「最新」「今年」「实时」等时间词跳过向量检索,直接触发联网搜索 / 企业内部实时 API
代码/结构化问题含代码块 / 要求输出 JSON / SQL / YAML走代码片段专用索引 + 语法校验器,生成阶段强制 Structured Output
安全敏感含退款 / 医疗 / 法律 / 财务建议词强制走 Guardrails 双审路径,生成模型禁用强模型温度=0,召回必须命中 2 份以上互证
已有缓存命中和过去 30 分钟内 1 条历史问题 cosine ≥0.95直接返回历史答案(可选人工确认),不走任何检索生成
领域分类器判定属于合同 / 代码 / 商品详情等垂直域跳转到该域专用知识库 + 专用微调模型,不走通用库

三条最容易落地、ROI 最高的 Adaptive RAG 改造

不要一上来就搞 10 条路径的大路由,90% 的场景先做以下三条就能拿 70% 的收益:

  1. FAQ 直出旁路:把历史上问过 5 次以上、答案稳定的问答对,单独建一个 FAQ 库(几千条量级)。每个新问题先和 FAQ 库的问题做 BM25 + embedding 融合打分,分数 ≥0.9 且历史答案 30 天内没被标错过,直接返回答案原文,跳过生成。这一条通常能旁路掉 30% 至 50% 的请求。
  2. 召回质量看门狗 + 重试:召回之后用一个小分类器(3B 级别 20ms 搞定)判断「召回 Top-3 的平均相关性是不是 ≥0.6」,不够就自动触发 HyDE 扩写查询 + 换 chunk size(从 512 切 256 或 1024)再召一轮,再不行才判定失败。这一条能把「召回垃圾导致答案错误」的比例直接砍 50%。
  3. 大小模型分流:路由器判定为「简单 + 低风险」的问题(FAQ、聊天寒暄、格式化任务)直接走 8B 或 70B 开源小模型,成本是强模型的 1/20 至 1/50;只有「复杂 + 高风险」的才走 GPT-4o / Claude Opus。实测 70% 的请求走小模型答案质量不掉,30% 走强模型兜底,总成本降 80% 以上。

常见问题

路由器本身判断错了(把复杂问题判成 FAQ 直出导致答错)怎么办?
路由器是概率系统,不可能 100% 对,必须设计「旁路不命中兜底 + 线上反馈闭环」两道保险。具体做法:(1)所有「FAQ 直出」返回的答案,都必须带一个「这个答案帮到你了吗?是/否」的按钮,点「否」的问题 100% 自动进入「走强模型 + 全量召回」的兜底路径,用户几乎感知不到只觉「系统想了一下给出了更详细的答案」;(2)所有路由决策(命中了什么标签、选了哪条路径)都打日志,每周把「用户点了否」和「客服人工介入标为答错」的 case 拉出来,重新训练路由分类器,让它下个月错得更少;(3)简单粗暴但有效的阈值:路由判定置信度 <0.85 的,不要硬猜,直接走保守路径(强模型+全量召回),错判率直接降到原来的 1/3。按这套运行 3 个月,路由器准确率通常能从 75% 爬到 92% 以上。
Adaptive RAG 会不会导致 P99 延迟反而变高?因为多了路由器判断和重试。
P95/P99 延迟升高是很多团队第一次上 Adaptive RAG 踩的坑,原因是「路由器是同步串行的」——等路由器结果回来才开始下一步,每步都叠加。正确做法是「并行启动 + 悲观取消」的流水线设计。工程实现:(1)用户请求进来的同一瞬间,并行启动三个任务:①路由器分类(30ms)、②普通向量召回 Top-20(100ms)、③小模型快速生成首 token(TTFT 200ms);(2)等路由器 30ms 返回之后,如果判定是「FAQ 直出」,直接取消任务②③,返回 FAQ 答案;如果判定是「普通问题」,任务②的召回结果已经好了,直接送任务③的生成继续跑,不额外加延迟;只有判定「需要 Graph RAG / 联网搜索」这种非常规路径,才取消②③启动新路径。按这套并行设计,Adaptive RAG 的 P50 延迟会比固定 RAG 下降 40% 至 60%,P99 延迟几乎不变(只增加了极少数需要重试的长尾),完美解决问题。
怎么衡量 Adaptive RAG 改造有没有效?应该看哪些指标?
Adaptive RAG 是成本/延迟/准确率的三角权衡,所以必须同时看三组指标,只看一组一定会被误导。建议的观测看板固定 6 个指标:(1)答案质量类:正确率(人工抽样 200 条/周)、「答案有用」点击率、无答案率(系统主动说「我不会」的比例);(2)成本类:单请求平均 token 消耗、单请求平均 ¥ 成本、大小模型请求占比;(3)延迟类:P50 / P95 / P99 首 token 延迟、端到端完成延迟、各路径命中比例。上线前必须做 A/B 实验:50% 流量固定 RAG、50% Adaptive,跑 1 至 2 周,只要满足「正确率不差 ±2%、有用点击率不差 ±3%」的前提下,成本降 ≥30% 或 P95 降 ≥30%,就算上线成功,否则要回调路由阈值。很多团队只看成本降了但没看正确率偷偷掉了 5%,3 个月后用户投诉飙升才发现,这个教训要牢记。