Mitigating Context Interference for Reliable and Efficient Search Agents
Boyang Xue, Bin Wu, Shuofei Qiao, Sheng Wang, Rui Wang, Yiming Du, Hongru Wang, Jeff Z. Pan, Emine Yilmaz, Kam-Fai Wong, Aldo Lipani
cs.CL
2026-08-11
多轮搜索智能体上下文越堆越长,论文先定位干扰主要来自最新检索的文档,再用 GPT-4 蒸馏精炼器接入 GRPO,7B 模型平均 EM 36.6 且检索更少。
多轮搜索智能体是这么一类 LLM 应用:它把一个问题拆成多步,每步先检索再推理,直到答出。IRCoT 这类方法每轮都会把检索回来的一批文档原样塞进上下文。几轮下来上下文越堆越长,里面大半和当前子问题无关,LLM 容易被这些噪音带偏,要么答错要么多绕几轮。作者把这种现象叫「上下文干扰(context interference)」,并问了三件事:干扰到底来自上下文的哪一部分?能不能在生成前清理掉?把清理动作融进训练还能不能再涨?
先做诊断,再给药。
诊断用的是逐类删减。作者在 IRCoT 基础上搭了几个变体:IRCoT-o 删掉历史检索文档,IRCoT-oq 再删历史 query,IRCoT-oqp 连历史思考也删。结果有点反直觉:删掉历史上下文之后效果不降反升,IRCoT-o 优于 IRCoT;但召回率和召回准确率之间的差距依旧很大,说明历史轮次不是主要干扰源。真正的元凶是最新一轮刚检索回来的文档,它体量大、又最贴近当前要生成的步骤,噪音也最致命。
给药用的是蒸馏。作者用 GPT-4 当老师,给定上一轮 query 和本轮检索文档,让它抽出关键信息;再用蕴含模型校验抽取结果完全被原文支撑、不引入新知识,防老师自己幻觉;拿这批「检索文档到关键信息」的对子 SFT 一个小模型,训练出上下文精炼器 F。推理时每轮先让 F 把检索文档压成要点,再交给 LLM 生成。
第三步是 CRRL(Context-Refined RL):把精炼器接进 GRPO 的强化学习管线,轨迹里只保留思考步和精炼后的文档,原始文档不入轨迹,用组相对奖励算优势函数。
七个 QA 数据集(单跳 NQ/TriviaQA/PopQA,多跳 HotpotQA/2Wiki/MuSiQue/Bamboogle),7B 模型,EM 衡量准确率、ART 衡量检索轮次。
| 方法 | 平均 EM | 平均检索轮次 |
| IRCoT(baseline) | 27.5 | 2.6 |
| 仅精炼(不 RL) | 32.2 | 1.2 |
| Search-GRPO | 34.6 | 2.1 |
| Search-o1 | 36.2 | 1.9 |
| CRRL(本文) | 36.6 | 1.7 |
效率收益更明显:CRRL 平均上下文只有 0.7k token,IRCoT 是 2.3k;单题推理时延 16.9 秒对 22.4 秒。要诚实地说,相比最强的 RL baseline Search-o1,CRRL 平均 EM 只高 0.4,准确率提升有限,主要赢在上下文更短、检索更少。而且在 MuSiQue 这种难题上 CRRL(13.2)还略低于 Search-o1(13.4)。
诊断结论本身就有复用价值:长上下文 agent 的噪音,不是越老越多越坏,而是最新输入最致命。这跟「中间迷失」(lost in the middle)发现的「上下文中段容易丢信息」是两个不同维度的结论,合起来对设计 agent 的上下文管理很有指导性。
工程上,蒸馏出的小模型当精炼器,比每轮都调 GPT-4 做压缩(GPT-Refine 33.2/1.2)便宜得多,效果还略好(本文精炼器 32.2/1.2 用的是 7B 自蒸馏)。等于把「先想清楚再看资料」做成了一个可部署的中间层。
作者自述两条:只验证了搜索 agent,工具调用、规划这类 agent 同样有上下文干扰但没覆盖;精炼器目前是外挂模块,还没融进 agent 自身的端到端训练。
读下来再补一点:CRRL 相对 Search-o1 的准确率增益小且集中在多跳任务,蒸馏依赖 teacher 质量,论文没讨论 teacher 抽错时怎么兜底。另外「干扰来自最新文档」这个结论是在 IRCoT 这种特定检索框架下得出的,换一个检索器或更长的上下文窗口,主因会不会变,没有验证。