Iris搜索智能体：把网页超链接拆成考题，逼出真正会查资料的AI

你有没有想过，考一个AI会不会"查资料"，最难的地方不在于它搜得快不快，而在于出题人根本没法出好题？

这听起来有点反直觉。我们平时觉得，只要给AI一堵防火墙，不让它硬背答案，考试就公平了。但AllSpark团队在做搜索智能体训练的时候撞上了一个更麻烦的问题：网上随便找的问题，AI闭着眼睛都能答对，因为答案早就被记在参数里了。要是问题里带着"哈利·波特"这种关键词，模型看一眼就知道答案，压根不需要真的去搜索、去推理、去拼凑证据。这样的题目拿来训练搜索能力，等于用小学数学题训练奥数选手,题目太简单，练不出真功夫。

这篇报告要讲的，就是AllSpark团队怎么解决"出难题"和"教AI学会搜索"这两件事，最终做出了Iris-mini和Iris-pro两个搜索智能体，并且在几个权威搜索基准测试上拿到了开源模型里的最好成绩。

题目太简单，练不出真本事：这个行业的老问题

先说说这个领域到底难在哪。

一个真正能干的搜索智能体，得同时会好几件事：知道该搜什么词，看得懂搜回来的一堆网页内容，判断什么时候该继续挖、什么时候证据已经够了。这跟平时测试语言模型答题不一样，答题的时候题目、上下文、算力预算都是提前定好的，但搜索是个动态过程，模型每一步的决策都会影响下一步能看到什么。

问题是，训练这种能力得先有合适的题目。自然产生的网络问答题往往太容易，因为很多问题的答案就直接写在问题本身能联想到的那几个关键词里，模型闭卷都能蒙对。人工写题又太贵，没法批量生产。所以之前的研究者想了个办法：利用维基百科之类的超链接结构或者知识图谱，把好几个实体串起来构造多跳问题，再把中间那些容易被搜索引擎直接命中的实体名字"抹掉"，逼着模型必须一步步推理才能定位答案。这个思路已经有WebSailor、WebShaper、DeepDive这些工作在做了。

但AllSpark团队觉得，光是把关键词抹掉还不够严谨。他们的做法是设计一套完整的双重验证机制，只有同时满足"闭卷答不出来"和"给了证据后能答对"这两个条件的题目才算合格，这个细节我们下面会展开讲。

同样重要的另一个老大难问题是：搜索这活儿往往要跑很多轮，问一句、搜一次、再问一句、再搜一次，聊到后面聊天记录堆得越来越长，最后模型的"内存"（也就是上下文窗口）被撑爆了，还没找到答案就没地方存新信息了。这个问题在业内叫做上下文管理，英文缩写CM

上下文管理（CM）：指模型在长时间多轮搜索过程中，如何处理不断累积的对话历史，避免超出模型能记住的最大长度限制,常见做法包括清空重来、压缩摘要、只保留关键信息等。

之前很多论文只公布"开了上下文管理"之后的分数，这就有个问题：你根本分不清这个高分是模型本身聪明，还是外部工具帮它擦屁股擦得好。AllSpark团队这次很坚持地把"开CM"和"不开CM"两种情况都测了一遍，逼着自己也逼着读者看清楚：模型的真实底子到底有多厚。

从网页链接里"倒着"造题：怎么让AI没法作弊

先说说这套出题流程的第一步，构建网页图。

研究团队把整个网络语料库看成一张有向图，网页是节点，超链接是边。造题的时候先随机挑一个种子页面,比如一个人物、一个事件的介绍页，然后沿着这个页面往外链接的方向抓取一批相关页面，组成一个局部子图。这里有个技术细节挺讲究：很多网页渲染服务会把网页里的超链接标签"洗掉"，只留下纯文本，这样就没法还原真实的链接结构了。团队的解决办法是同时用结构化的语义镜像数据（比如RDF三元组这种结构化知识表示）和渲染后的网页内容做交叉验证，把两边的链接信息合并起来，尽量不漏掉真正的链接关系。

有了这批网页之后，第二步是把杂乱的网页文本提炼成一张干净的实体关系图,谁跟谁有关系，关系是什么类型,只留下真正能构成多跳推理路径的实体，把无关的?在信息全部剔除。接着在这张图上生成一条至少要跨越好几层关系的推理路径，路径的终点就是答案。

然后是最关键的一步，去掉所有能被字符串匹配直接搜到的线索。举个例子，如果原始问题里出现"史塔克家族"这个具体名字，模型可能直接搜这个词就找到答案了，完全不需要推理。所以团队设计了一个"抽象改写"操作，把除了最终答案之外的每一个实体都换成一段描述性的指代,比如把"史塔克家族"改写成"一部改编自小说的西方奇幻剧中，小女儿流亡海外并加入神秘组织的那个家族"。这样模型没法靠搜关键词偷懒，必须真的一步步推理、消歧、验证才能定位到正确的实体。

这个思路让我想起小时候玩的"猜猜我是谁"游戏,如果直接说出名字，游戏立刻就没意思了，正因为提示都是拐着弯的描述，猜的人才不得不真正动脑子拼线索。如果不做这层抹除，会发生什么？答案是模型会学会一种"伪搜索"的坏习惯：看到关键词就直接搜索引擎一把梭，答案蹦出来就完事，根本没锻炼到真正需要的多步推理和证据整合能力,等真遇到没有现成关键词的复杂问题，这种"伪搜索"能力立刻穿帮。

题目造好之后，还要过最后一道关，双重难度验证。团队会让一个参考模型分别在两种设置下回答同一个问题：闭卷（不给任何工具，纯靠记忆）和开卷（把刚才提炼出的实体关系图直接喂给它）。只有闭卷答错、开卷答对的题目才会被留下来。

这个设计的道理很简单：闭卷答错说明这道题真的没法靠死记硬背蒙过关，开卷答对说明这道题的答案是唯一确定的、不是出题时留了漏洞导致连给了证据都无解。两个条件缺一个都不行,只满足闭卷答错，可能是因为题目本身有歧义或者答案错了；只满足开卷答对，题目可能太简单模型压根不需要推理。

教AI学会搜索：先靠老师示范，再靠自己练

题库有了，接下来就是怎么把这些题目变成能训练模型的数据。

团队先请一个能力很强的"教师模型"，按照ReAct这种"边想边做边看"的交互范式去解每一道题

ReAct：一种让语言模型交替进行推理和行动的框架,模型先写一段思考文字，然后决定调用什么工具（比如搜索或者抓取网页），拿到结果后接着推理，循环往复直到给出最终答案。

教师模型解题过程中留下的完整轨迹（思考、工具调用、观察结果、最终答案的全过程）会被收集起来，但这些原始轨迹质量参差不齐，直接拿去训练效果不好。所以团队设了两道过滤关卡。

第一道是轨迹级别的粗筛。首先答案必须被判定为正确,这里用了一个专门的裁判模型来做语义匹配，判断模型给出的答案是不是跟标准答案说的是一回事。然后要排除各种"抽风"的轨迹，比如陷入重复循环、疯狂调用工具却毫无进展、思考过程写了一半没写完就断掉了。检测这类问题的核心技巧挺巧妙：用文本压缩率来判断,重复的文字压缩起来体积会大幅缩小，流畅正常的文字压缩比就没那么夸张。团队用一个滑动窗口去扫描文本，只要某一段窗口的压缩比超过阈值，就判定这段是循环或者跳针,这个方法不管重复的花样是什么、藏在哪个位置，都能被抓出来。除此之外还有一些辅助检测手段，比如连续调用工具时参数完全一样这种明显偷懒的行为，也会被识别出来。最后还要求轨迹里工具调用的轮次不能太少，太浅显、一搜就出答案的题目对训练没什么价值。

这个过滤逻辑让我想到批改作文,如果一篇作文抄了三段一模一样的话，老师一眼就能看出来这不是正常写作，因为正常写作不会这么"密"。压缩比检测干的就是这个活，把"内容密度异常低"的文本当成信号抓出来。如果不做这层过滤，教师模型示范的一堆歪门邪道（比如反复搜同一个词浪费轮次）会被当成"正确答案"喂给学生模型，学生学会的就是磨洋工而不是真本事。

粗筛通过之后，还有一道更精细的关卡，逐轮次的精筛。有些题目已经逼近教师模型能力的边界了，即便整条轨迹最终答案是对的，中间某一轮可能还是有瑕疵,比如搜了一个明显重复的关键词，或者编造了一个根本不存在的工具名字，又或者这一步的"思考"文字和实际执行的动作完全对不上。

这里的难点在于，怎么让一个AI裁判去判断"这一轮到底算不算有问题"，而且不能太严格，因为有些看起来"多余"的探索步骤其实是合理的试错。团队的解法是让裁判先自由点评一批样本轨迹，把反复出现的问题类型（比如"误解了题目意思"这种）总结归纳成一套具体的评判标准，再拿这套标准去正式打分。每一轮对话会被标记为保留或者屏蔽，为了避免裁判过度删减，规定每条轨迹里最多只能屏蔽10%的轮次。被屏蔽的内容还留在上下文里，只是不参与损失计算，模型看得到但不会被这部分内容"带偏"训练方向。

有了这批经过两层筛选的高质量数据，团队才正式开始做监督微调（SFT），也就是让模型直接模仿教师的输出，一步步学会怎么推理、怎么调用工具、怎么整合信息。

拿真实搜索去练兵：强化学习怎么解决"跑太久"的麻烦

监督微调只是第一步，光靠模仿教师还不够，因为教师的示范再多也覆盖不了所有情况。接下来团队用强化学习（RL）让模型直接在真实的网络搜索环境里试错练习。

这里有个现实问题：搜索这种任务经常要跑很久，有些会话可能几十轮都收不了尾。如果按照传统的同步训练方式，系统得等所有并行跑的会话都结束才能进行下一步更新，那些跑得特别慢的几个会话就会拖垮整批训练进度。

团队的解决办法叫请求级别的部分展开与前缀复用。简单说，就是不再死等每一条搜索会话彻底跑完,一旦某一批已经完成的轨迹数量够了，那些还在跑、跑得特别慢的会话就被中断，但不是直接扔掉，而是把它已经跑出来的那一段内容保存下来，等下一轮训练继续接着往下跑。因为跑这些会话的过程中模型的参数其实一直在更新，所以拼接起来的轨迹里前半段和后半段可能是用不同版本的模型权重生成的，团队用一种叫截断重要性采样的统计技巧去纠正这种"新旧参数混用"带来的偏差。

这就像是接力跑步比赛,如果因为某个选手体力不支跑得特别慢，整个团队就得原地等他跑完全程才能进行下一场比赛，那效率就太低了。更合理的做法是让他跑到哪算哪，先把已经跑出来的这一段成绩记下来，下一场再从这里接着跑，而不是每次都重新从起点开始。如果不这么做，训练系统会被那极少数的"拖后腿"会话严重卡住，GPU算力大量浪费在等待上。

另一个值得说的设计是，团队没有依赖外部API去做训练时的评分和摘要工作，而是直接在训练集群内部部署了几台跑着自家Qwen3.5-397B-A17B模型的推理引擎，让这个模型同时兼任两个角色：一个是生成式奖励模型

生成式奖励模型（GenRM）：不是简单打分数，而是像一个真正的裁判一样，读懂问题、参考答案和模型给出的答案，判断这个回答到底对不对,给出的是一个二元的对错判断。

另一个角色是观察摘要器,每次搜索工具返回一整个网页的内容后，这个内部模型会把长长的网页压缩成一段跟当前问题相关的简短摘要，这个摘要才是模型实际"看到"的内容。这也是整个训练流程里唯一的上下文压缩机制，没有额外做历史消息裁剪或者滑动窗口截断,这意味着模型训练时看到的上下文，跟它实际会用到的上下文是完全一致的，不存在"训练和实际用起来不一样"的落差。

把裁判和摘要器都放在训练集群内部还有个好处：不用依赖外部接口调用，一套算力资源同时覆盖了训练、推理展开和奖励计算三件事，省了不少折腾。

SFT和RL来回攀爬：让好的搜索经验反哺训练

团队给这套SFT和RL交替进行的流程起了个名字，叫SFT-RL攀爬。

思路是这样的：每完成一轮强化学习，就从这一轮探索出来的大量搜索会话里，挑出那些"刚好卡在及格线附近"的题目,具体来说，是那些在多次尝试里成功率大于0但又不超过一半的问题。这类题目说明模型目前偶尔能蒙对，但还不够稳定可靠，正好是最值得再练一练的难度区间。

从这些题目对应的成功轨迹里，团队还要求至少要有一定数量的工具调用轮次（避免选中那些运气好蒙对的浅显答案），并且优先挑选轮次最短的那条成功轨迹（鼓励模型高效搜索，别绕远路）。挑出来的这批精华轨迹会被重新拿去做一轮监督微调，然后强化学习再从更新后的模型继续往下跑。

这个机制挺有意思的地方在于，它是自适应的,因为"哪些题目算刚好卡在及格线"是根据模型当前的实际表现动态划定的，随着模型越来越强，这个"临界难度区间"会自动往更难的题目上移动，相当于模型自己给自己出了一套难度递增的习题集，不需要人工干预调整课程进度。

这就好比健身房里的渐进式负重训练,如果始终举同样的重量，肌肉很快就不再有新的刺激了，得根据自己当下举得起来又不算太轻松的那个重量持续调整。如果不做这种动态调整，模型可能一直在啃自己早就掌握的简单题，或者反过来死磕远超自己能力的难题，两种情况都练不出实质进步。

成绩单：两个体量、四个基准，Iris都跑在前面

说了这么多方法，实际效果到底怎样？

团队把Iris-mini（350亿参数规模，激活30亿）和Iris-pro（3970亿参数规模，激活170亿）分别放在四个搜索类基准测试上，跟同体量段的其他开源模型比拼。

这四个基准分别是：BrowseComp，考验模型能不能通过多个间接、互相牵制的线索找到长尾冷门实体；BrowseComp-ZH是它的中文版本；DeepSearchQA看的不是答案对不对这么简单，而是模型找回的证据有多全面，用F1分数衡量；HLE全称Humanity's Last Exam，考的是跨学科的专家级知识和推理能力，搜索在这里只是辅助手段而不是答案的主要来源。

| 模型 | 参数规模 | BrowseComp | BrowseComp-ZH | DeepSearchQA | HLE |

|---|---|---|---|---|---|

| XYZ-Aquila-mini | 35B | 78.8 | 82.9 | **89.5** | 51.1 |

| Nex-N2-mini | 35B | 74.1 | 79.6 | 87.2 | 37.1 |

| Apodex-1.0-mini | 35B | 71.5 | 80.6 | 82.2 | 46.8 |

| **Iris-mini** | 35B | **82.2** | **84.8** | 86.9 | **52.3** |

| XYZ-Aquila-pro | 397B | 84.8 | 85.1 | 92.5 | 53.3 |

| Nex-N2-Pro | 397B | 83.7 | 79.6 | 92.3 | 50.0 |

| **Iris-pro** | 397B | **88.6** | **85.1** | **92.9** | **56.4** |

在35B这个体量段，Iris-mini在BrowseComp、BrowseComp-ZH、HLE三项上都拿到了第一，尤其是BrowseComp比第二名XYZ-Aquila-mini高出3.4分。唯独DeepSearchQA上稍稍落后于对手（86.9对89.5），这算是一个坦诚的短板承认。

在400B级别，Iris-pro四项全部领先或者持平，BrowseComp领先3.8分，HLE领先3.1分。更有意思的是，报告里提到Iris-pro在标准ReAct设置下的表现，已经能追上MiroThinker-H1和Apodex-1.0-H这些启用了"重度算力"配置（比如多次验证、多路径投票）的对手,也就是说，Iris-pro不靠额外的推理时算力堆砌，光凭训练学到的底子就够打了。

不过团队也很坦率地承认，跟真正的顶级前沿模型比（比如Kimi-K3、GPT-5.6 Sol），还是有差距的，这个差距是留给未来继续努力的空间。

上下文管理到底值多少分：一个容易被忽略的变量

前面提过，团队坚持要把"开CM"和"不开CM"的成绩都摆出来，这一部分的数据其实挺有信息量的。

不开任何上下文管理策略的情况下，Iris-mini在BrowseComp上是64.7分，Iris-pro是72.6分。一旦加上discard-all策略（简单说就是当上下文快撑爆的时候，直接清空聊天记录，从零开始重新答题，只不过题目本身没变），Iris-mini直接跳到82.2分，涨了17.5分；Iris-pro跳到88.6分，涨了16分。

这个涨幅大到让人有点意外。一个纯粹的"清空重来"操作，居然能带来接近20个百分点的提升,这说明很多时候模型不是"不会搜"，而是"记忆装满了没地方存新线索"，问题出在容器不够大，不是脑子不够聪明。

这个现象让我想起收拾行李箱,东西明明都带对了，但箱子塞得太满关不上，不是东西选错了，是没腾出空间。清空重来这个动作，本质上就是把箱子倒空重新装一遍，之前该带的经验教训（比如已经排除了哪些错误方向）用摘要的形式留下来，没用的碎片信息丢掉，腾出空间继续往前走。

团队还测了另一种叫retry的策略（这是MiroThinker团队提出的思路）：当一次尝试没能给出有效答案时，把这次失败的探索过程总结成一段简短描述，附加到下一次尝试的任务里，相当于告诉模型"这几条路已经走过是死胡同，别再走了"。这个策略比discard-all还要更进一步，效果也确实更好，比如discard-all加retry能把Iris-pro在BrowseComp上的分数推到90.3。

但团队很明确地表态：这种策略每失败一次都要再跑一整套完整的搜索流程，推理成本高得多，所以正式报告的主表格里用的是相对朴素的discard-all设置，而不是分数更高但更耗算力的retry组合。这个态度我觉得挺值得点出来:一个基准分数背后如果没有标注清楚花了多少推理成本换来的，这个分数的可比性就大打折扣。DeepSeek-V3.2的论文里也提过同样的观点。

还有一个细节很有意思：CM带来的提升幅度在不同基准上差别很大。BrowseComp上最多能涨21.2分，但HLE最多只涨9.2分。这不是因为HLE本身空间小,HLE不开CM时的基线分数才43.2，理论上应该有很大提升空间。真正的原因是HLE考的是专家级知识推理，搜索只是辅助，答案主要还是靠模型自己的知识储备，上下文塞满与否对答案质量的影响本身就有限。而BrowseComp这类任务需要反复搜索、筛选、拼凑大量证据，聊天记录很容易堆满，清空重来能直接换来更多的搜索"空间"，收益自然更明显。

一个答案对了却被判错的案例：基准测试也有它的毛病

报告里有一段挺诚恳的自我剖析，讲了BrowseComp-ZH第85题的一个案例。

题目描述的是《权力的游戏》里史塔克家族最年长的女儿(桑萨·史塔克)第二次婚姻嫁给了哪个家族。官方给出的标准答案是兰尼斯特，但Iris的答案是波顿。

团队仔细核对了剧情：桑萨确实先与提利昂·兰尼斯特结婚（这是她的第一次正式婚姻），后来又嫁给了拉姆斯·波顿,这才是她的第二次婚姻。按照剧情事实，第二次婚姻嫁的应该是波顿家族，不是兰尼斯特。团队据此认为，这道题的官方标注可能存在错误，而不是模型答错了。

这个案例被专门写进报告里，我觉得是个挺难得的态度。很多团队遇到这种情况可能会选择性忽略，反正吃了一次分数上的亏，糊弄过去也没人追究。但把这个案例摆出来讨论，说明团队真的在关心"我们测的这套基准本身靠不靠谱"这个更深层的问题,毕竟如果连标准答案都可能出错，那所有跑在这套基准上的排行榜数字都得打一个问号。

搜索之外：这套训练方式带来的意外收获

报告最后提到一个挺值得琢磨的观察。团队发现，无论是搜索专用的合成数据，还是那些专门为搜索场景训练出来的模型（被拿来当教师去蒸馏别的模型），都在一些完全没有专门针对训练的领域上表现出了正向迁移,比如通用工具调用能力（用BFCL和τ-bench这两个基准衡量）和办公协作类任务（OfficeQA和APEX）。

这个发现如果成立，意味着"搜索"这件事可能不该被当成一项孤立的垂直技能来看待，更像是一种底层的通用能力,任何需要在信息不全的情况下一步步试探、验证、修正的场景，都能从搜索训练中获益。这跟人类的学习经验其实也挺像：一个人学会了怎么在图书馆里高效查资料，这个能力往往也能迁移到"怎么在陌生城市问路找到目的地"或者"怎么在一堆文档里快速定位关键信息"这类完全不同的场景里,核心不是记住了具体去哪查，而是学会了"面对未知时该怎么一步步缩小范围"这套通用的思维方式。

写在后面

读完这份报告，最触动我的其实不是那几个领先的分数，而是团队对"上下文管理值多少分"这件事的坦白。很多团队发论文时习惯把最好看的那个数字摆在最前面，但这份报告花了整整一节篇幅去拆解，一个discard-all的简单操作能贡献20个百分点的提升,这相当于承认，很多所谓"系统领先"的差距，可能压根不是模型智力上的差距，而是工程包装上的差距。这种拆解对整个行业的评测规范其实是有价值的提醒。

另一个让我意外的细节是那个BrowseComp-ZH第85题的案例。一道《权力的游戏》的婚姻关系题，居然能暴露出权威基准测试标注本身的漏洞。这提醒我们，衡量AI能力的标尺本身也是人造的、会出错的东西，排行榜上的分数差异，有一部分可能根本不是模型能力的差异，而是标注质量的噪音。

搜索能力能正向迁移到办公协作、通用工具调用这些不相关领域，这个发现留了一个没展开的问题：这种迁移的边界在哪？如果搜索真的是一种底层通用能力，那是不是意味着未来训练任何智能体，都应该先让它经历一段"在信息残缺的世界里摸索着找答案"的阶段，再去学具体的垂直技能？这个猜想目前还只是一个观察，但值得继续追问下去。

Q&A

Q1：Iris-mini和Iris-pro是什么？

A：它们是AllSpark团队训练的两个搜索智能体，分别是350亿参数（激活30亿）和3970亿参数（激活170亿）的规模，专门用来做网络搜索类的复杂问答任务，在BrowseComp、BrowseComp-ZH、DeepSearchQA和HLE四个基准测试上取得了开源模型中同体量段的最好成绩。

Q2：为什么Iris训练时要把问题里的实体名字改写成描述性文字？

A：因为如果问题里直接出现具体的人名、地名等关键词，模型可以直接用搜索引擎搜关键词就找到答案，根本不需要真正的推理。改写成描述性指代后，模型必须通过多步推理和证据拼凑才能确定答案，这样训练出来的搜索能力才是真正有用的。

Q3：上下文管理对搜索智能体的表现影响有多大？

A：影响非常大，团队实验发现，仅仅是把清空重来这种简单的上下文管理策略打开，Iris-mini在BrowseComp上的分数就能从64.7涨到82.2，提升17.5分，Iris-pro也能涨16分左右，说明很多性能差距其实来自推理时的工程策略，而不只是模型本身的能力差异。