来源ICLR 2026Oral论文arXiv:2511.07328 · Q-RAG核心标签Agentic RAG · 强化学习 · Embedder 微调 · 多步检索 · 10M tokens 为什么你现在应该读这篇2026 年做 RAG 系统的人面临一个尴尬现实单步检索已经不够用了。用户问的问题越来越复杂需要跨多个文档、多个事实才能拼出答案。于是业界开始做多步检索——让检索 agent 做多轮搜索每一轮基于上一轮的结果决定下一步查什么。问题来了现有的多步检索方法几乎都在微调一个小 LLM 来做检索决策。微调 LLM 有多贵一张 H100 跑一天起步而且微调完的模型没法直接用大模型推理。你为了检索决策花大价钱训了个小模型推理还得分两段。Q-RAG 的反直觉发现是不需要微调 LLM只需要微调 Embedder。用强化学习训练 Embedder 学会在嵌入空间里逐步选取支撑事实LLM 本身保持冻结。结果是。检索决策成本从训小 LLM降到微调 Embedder差距是数量级的。三件做 RAG 工程的人不能不知道的事① 多步检索的瓶颈不在检索算法在检索决策的计算成本传统思路是把检索算法做得更聪明——更好的排序、更精准的匹配。但当问题变复杂真正需要的是多轮决策而多轮决策意味着每一轮都要调用模型做判断。如果这个判断模型是 LLM成本就是天文数字。② Embedder 比 LLM 更适合做检索决策Embedder 的职责就是把文档和查询映射到同一个向量空间。Q-RAG 的洞察是与其让 LLM 在每一轮重新理解上下文再决定查什么不如让 Embedder 直接学会在嵌入空间里走路径——这本质上是一个强化学习问题而 Embedder 的参数量远小于 LLM训练成本低一个数量级。③ 10M tokens 上下文不是吹牛是 Embedder 路径规划的副产品当检索变成在嵌入空间里逐步选取每一次选取都是一次向量运算不涉及 LLM 推理。这意味着理论上可以处理任意规模的上下文10M tokens 只是当前实验的上限。如果你正在做(1) 企业知识库 RAG 系统(2) 需要多跳推理的问答场景(3) Agent 工具链里的检索组件下面的细节可以直接搬。论文元信息来源/项目ICLR 2026 Oral · arXiv:2511.07328关键数据支持 10M tokens 上下文、BabiLong RULER 基准 SOTA、代码开源 github.com/griver/Q-RAG核心创新用 RL 微调 Embedder 实现多步检索LLM 保持冻结核心场景你的 RAG 系统开始答不上来想象一下你花了三个月搭好了一个企业知识库 RAG 系统用户问去年 Q3 的华东区销售额是多少系统秒回。但有一天用户问去年 Q3 华东区销售额最高的产品线它的负责人是谁那个负责人最近发了什么关于 Q4 目标的邮件——这种多跳问题单步检索根本拿不到答案。传统做法是把多跳写成固定 pipeline先查销售额 → 再用结果查产品线 → 再用产品线查负责人 → 再用负责人查邮件。每一步都要调用 LLM 做理解检索决策4 步就是 4 次 LLM 调用。Q-RAG 的做法不同让 Embedder 在嵌入空间里自己走出一条路径。不需要 LLM 参与检索决策Embedder 通过强化学习学会了当前查询 已有上下文 → 下一步该查哪个 chunk的映射。LLM 只在最后一步负责生成答案。关键数据上下文规模最高 10M tokensvs 传统 RAG 通常 8K-128K训练成本只微调 Embedder不微调 LLM代码已开源技术细节Value-Based Embedder Training核心机制把多步检索建模为 MDPQ-RAG 的核心思想是检索过程就是一个马尔可夫决策过程MDP。每一步的状态是当前查询 已检索到的上下文动作是从嵌入空间中选择下一个最相关的 chunk奖励是最终答案的正确性。传统方法的问题在于如果用 LLM 做决策每一步都要跑一次 LLM 推理成本线性增长。Q-RAG 的解法是让 Embedder 直接学会这个决策映射。训练流程初始化用标准对比学习如 E5、BGE预训练 EmbedderRL 微调用 PPO 或类似算法reward signal 来自最终答案质量如 QA 准确率推理时Embedder 在嵌入空间中做 k 步路径规划每一步选出最相关的 chunk最终把所有 chunk 拼接后送入 LLM 生成答案为什么是 Embedder 而不是 LLM维度微调 LLM 做检索决策微调 Embedder 做检索决策Q-RAG参数量7B-70B0.5B-3B训练成本数千美元/实验数十美元/实验推理成本每步都要 LLM 推理只有向量运算无 LLM 推理上下文规模受 LLM context window 限制理论无上限模型迭代换模型要重训Embedder 可适配任意 LLMSo What三类人的行动清单 工程师把检索决策从 LLM 移到 Embedder—— 如果你的 RAG 系统有多步检索需求先评估是否可以用 Embedder 做路径规划而不是直接上小 LLM 做 retriever用 Q-RAG 代码库做 PoC—— github.com/griver/Q-RAG 有完整的训练和推理代码可以直接跑 BabiLong/RULER 基准对比明天就能做在你的 RAG pipeline 里加一个Embedder-only 检索的实验分支对比LLM 检索决策和Embedder 检索决策的成本和效果 技术管理者重新评估 RAG 系统的 cost structure—— 如果你的 RAG 系统每轮检索都要调 LLMtoken 成本可能占总推理成本的 30%Q-RAG 类方案可以显著降低关注 Agentic RAG 趋势—— 2026 上半年顶会 RAG 论文中超 60% 引入 Agent 机制传统 top-k 检索 pipeline 已成基线而非主流明天就能做让 RAG 负责人做一个检索决策成本的摸底量化每一轮检索的 token 消耗 创业者/PM把检索决策成本纳入产品经济模型—— RAG 产品的边际成本主要来自推理如果检索决策占大头产品规模化会遇到成本墙关注 Embedder-as-Agent 的范式迁移—— 不只是 Q-RAG整个让小模型/Embedder 做决策、大模型只做生成的趋势值得押注明天就能做在下一次 RAG 系统评审会上专门讨论检索决策的成本结构和优化空间⚠️ 方法论局限RL 训练的稳定性问题强化学习训练 Embedder 在实践中可能面临 reward hacking——Embedder 学会走捷径而非真正理解语义泛化性待验证Q-RAG 在 BabiLong/RULER 上的 SOTA 表现是否能迁移到真实业务场景如企业知识库尚未有大规模验证Embedder 选择敏感方案效果高度依赖基础 Embedder 的质量不同 Embedder 的 RL 微调效果差异可能很大调试困难Embedder 的决策过程不透明出了问题比 LLM pipeline 更难定位延伸阅读 论文https://arxiv.org/abs/2511.07328 代码https://github.com/griver/Q-RAG 互补阅读A-RAG让 Agent 自主决策检索粒度—— Q-RAG 解决检索决策成本A-RAG 解决检索策略编排 同类对比RAG-MCPMCP 工具数量爆炸时的 RAG 工具路由⏱️如果只有 5 分钟看 10M tokens RL 微调 Embedder 两个点就够了。核心 takeaway 是检索决策不需要 LLM。路易乔布斯 © 2026 · AI论文观察 · Agentic RAGICLR 2026 Oral · Q-RAG · 2026.06.24基于公开论文研读