一、一个反直觉的 0.3 分
2026 年 9 月 14 日,AllSpark Research 放出了开源搜索智能体 Iris。
两个模型同日上了 Hugging Face,权重协议是 Apache 2.0。
Iris-mini 总参数 350 亿,推理时只激活 30 亿。
Iris-pro 总参数 3970 亿,激活参数 170 亿。
参数差了一个数量级,分数却没拉开多少。
英文 BrowseComp 上,两者差距是 6.4 分。
中文 BrowseComp-ZH 上,差距只剩 0.3 分。
35B 的小模型在中文上几乎追平了 397B 的大模型。
论文给出的解释很直接:上下文管理比堆参数更有效。
这条结论值得拆开看,因为它改写了搜索智能体的成本逻辑。
先看货,再挖机制,最后落到工程选择。
二、先看货:两张基准表
Iris-mini 从 Qwen3.6-35B-A3B 后训练而来。
Iris-pro 的基座是 Qwen3.5-397B-A17B。
两个都是混合专家结构,上下文窗口 256K。
| 模型 | 总参数 | 激活参数 | 基座 | BrowseComp | BrowseComp-ZH | DeepSearchQA | HLE |
|---|---|---|---|---|---|---|---|
| Iris-mini | 35B | 3B | Qwen3.6-35B-A3B | 82.2 | 84.8 | 86.9 | 52.3 |
| Iris-pro | 397B | 17B | Qwen3.5-397B-A17B | 88.6 | 85.1 | 92.9 | 56.4 |
英文项差距最大的是 BrowseComp,相差 6.4 分。
中文项 BrowseComp-ZH 几乎持平,只差 0.3 分。
DeepSearchQA 按 F1 计,差距 6.0 分。
HLE 是更难的科学推理,差距 4.1 分。
两个模型都拿到了各自参数档位的开源最佳成绩。
BrowseComp 要求模型在开放网页里自己找答案。
它的题面经常涉及多跳推理与实时信息。
BrowseComp-ZH 是它的中文镜像版本。
DeepSearchQA 衡量检索问答的精确度。
HLE 用人类考试级题目考验科学推理。
四个基准覆盖了搜索任务的四个侧面。
三、三档上下文管理对照
搜索历史越滚越长,是搜索智能体的核心难题。
团队测了三种推理时策略:什么都不做、discard-all、retry。
| 策略 | 做法 | 代价 |
|---|---|---|
| 什么都不做 | 完整保留全部工具调用历史 | 窗口越滚越满,噪声累积 |
| discard-all | 超阈值清空历史,从原问题重来 | 有效线索一起被丢弃 |
| retry | 把已排除线索摘要后继续 | 保留证据链,只压体积 |
开上下文管理之后,两个模型都涨分。
关键差异在于:Iris-mini 涨得比 Iris-pro 多。
对小模型来说,管住越滚越长的搜索历史,比堆参数更有用。
这说明 0.3 分不是偶然,而是策略红利。
搜索智能体的能力,一半在模型,一半在调度框架。
discard-all 的问题在于把有效线索也一起扔了。
retry 的聪明之处,是只压缩、不遗忘。
摘要保留了"排除过什么"的证据链。
模型据此判断是否要回溯,而不是盲目重搜。
四、为什么开源两年追不上闭源
通用对话和代码上,开源已经追得差不多了。
搜索是掉队最久的一块,原因很现实。
闭源产品把模型和框架两头一起调。
开源侧往往只放模型,不放框架。
框架缺失,让权重很难发挥出榜单上的效果。
Iris 这次把三样一起放出:权重、上下文策略、数据构造。
训练流水线代码标注为即将放出。
GitHub 仓库致谢了 MiroThinker、Relax、ms-swift 和 slime。
前两个是过去一年做搜索智能体的开源尝试。
这条线正在从"只给模型"走向"给完整包"。
搜索智能体要自己决定搜什么、看完要不要接着搜。
还要判断什么时候证据够了、可以收手。
这些决策逻辑分散在框架里,不在权重里。
只放权重,等于给了引擎没给方向盘。
这也是为什么各家都在抢执行层的话语权。
搜索智能体的下一场竞争,注定在框架层。
五、SFT-RL climbing:在真实搜索里交替训练
训练流程被论文称为 SFT-RL climbing。
监督微调和强化学习交替进行。
强化学习这一段跑的是真实搜索,不是离线快照。
判分用的奖励模型部署在训练集群内部。
给观察结果做摘要的模块,同样内联在集群里。
训练时每一步都要真的发出网络请求。
这种配置工程成本不低,但效果直接。
模型在真实反馈里学会"什么时候证据够了"。
它还得自己决定搜什么、要不要接着搜、何时收手。
这些判断,正是搜索智能体和对话模型的本质区别。
SFT 阶段负责学会基础的工具调用格式。
RL 阶段负责优化长程搜索策略。
交替训练防止策略退化,也防止格式遗忘。
真实搜索让奖励信号不再来自模拟器。
模型见过的失败模式,和线上一致。
六、数据构造:专治字面匹配
榜单数据也不能靠背题,团队从源头防作弊。
先从网页语料的超链接结构里挑一个种子页。
顺着种子页的出链,蒸出一张实体图。
再在实体图上编多跳链条。
最后把题面改写一遍,保证线索不能靠字面匹配解决。
多跳链条让答案不能从一个页面直接抄到。
题面改写让检索不能靠关键词直击。
这套构造,让评测分数更接近真实搜索能力。
每一条线索都要求模型做一次推理跳跃。
检索词与答案之间隔着至少两层关系。
这样刷榜没有捷径,只能靠真检索真推理。
数据集的高质量,是榜单可信度的地基。
也正因如此,复测门槛被抬高了。
想验证分数,就得先复现整套数据流水线。
七、最小可运行:本地搭一个搜索循环
35B 总参、3B 激活的规格,单机就能起。
配上论文里的上下文策略,直接做深度搜索。

先加载模型,再给一段搜索计划提示词。
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
# Iris-mini: Qwen3.6-35B-A3B 后训练,激活约 3B
model_name = "AllSpark-Research/Iris-mini"
tok = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
model_name, torch_dtype=torch.bfloat16, device_map="auto"
)
prompt = (
"你是搜索智能体,给出搜索计划。\n"
"问题:2026 年 9 月开源搜索智能体在 BrowseComp 的最高开源分数是多少?\n"
"计划:"
)
inputs = tok(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=512)
print(tok.decode(out[0], skip_special_tokens=True))
这个流程依赖 transformers 与模型权重,可直接执行。
真实部署时,还要在外面接检索与浏览器工具。
摘要模块负责把已排除线索压成一句话。
retry 策略在每次工具调用后决定保留还是摘要。
这套编排,就是论文里涨分最多的那条路径。
轮次之间把旧的观察结果做成摘要。
摘要与原始问题一起喂回上下文。
窗口压力小了,小模型的推理空间就大了。
轮次收益会递减,摘要不是越多越好。
每轮保留最关键的三条证据即可。
过多证据会稀释注意力,适得其反。
八、检索循环的工程骨架
完整循环不止一次推理,而是多轮查询与总结。
下面这个循环是论文策略的落地骨架。
import json, requests
def search(query):
resp = requests.get(
"https://api.example-search.dev/v1",
params={"q": query, "n": 5}, timeout=20)
return [r["snippet"] for r in resp.json()["results"]]
def summarize(model, ctx, budget=800):
text = "\n".join(ctx[-budget:])
out = model.generate(text, max_new_tokens=256)
return out
history = [""]
trail = []
for step in range(6):
q = model.query(question, history)
hits = search(q)
trail.extend(hits)
if len("\n".join(trail)) > 4000:
trail = [summarize(model, trail)]
history = trail + ["继续用一句结论描述进展"]
每个工具调用之后,先判断历史体积。
超过阈值就把旧线索摘要,而不是清空。
摘要保留排除过什么,模型可据此回溯。
循环步数限制在六轮以内,防止失控。
这就是 retry 策略的最小实现。
换成 discard-all,只需清空列表重来。
两行差异,榜单上就是几分差距。
摘要的粒度需要单独调优,太粗丢细节。
太细则没有起到压体积的作用。
论文的默认做法是按轮次批量摘要。
每轮结束,把该轮所有观察合并成一段。
下一轮带着这段摘要继续检索。
阈值取在窗口的五分之一到四分之一。
这个比例在实测里涨分最明显。
对自托管用户,这是最值得抄的参数。
九、真实场景:把 Iris 接到自己的知识库
搜索智能体的价值,不只在于开放网页检索。
企业知识库同样受益于多跳检索。
一个常见落地是把 Iris 的循环接到向量库。
查询改写、子问题分解、证据汇总都能复用。
先让模型把用户问题拆成多个子查询。
每个子查询命中不同文档片段。
多个片段合起来,才能回答一步之遥的复合问题。
这正是 BrowseComp 多跳题在内部的镜像。
Iris 的上下文管理在长会话里尤其值钱。
客服、审计、合规问答,会话往往跨越几十轮。
老线索不清理,上下文很快写满。
摘要策略让旧结论长期可用,记忆不丢失。
部署侧,3B 激活可以压进单卡推理。
配合量化,成本进一步下降。
唯一要留意的,是摘要本身的准确性。
摘要出错时,错误会沿链路传播。
关键轮次建议保留原文,只压缩次要线索。
这是把策略用好的工程纪律。
另一个落地点是终端助手,比如代码仓库问答。
开发者用自然语言问跨文件的问题。
子查询拆到相关模块,聚合后给出结论。
这类场景的检索路径比开放网页更可控。
命中质量高,摘要负担也轻。
对 3B 激活的模型,这是最容易出效果的场景。
九、上下文为什么比参数更值钱
搜索任务里,上下文本身就是推理工作台。
线索越多,噪声越多,注意力越分散。
大模型靠容量扛噪声,小模型扛不动。
所以同样的管理策略,小模型受益更大。
retry 把噪声压成摘要,保留关键证据。
注意力集中在有效线索上,推理更稳。
这正是中文差距只有 0.3 分的机制来源。
英文检索线索长、噪声多,大模型优势放大。
中文检索线索结构更集中,策略红利更明显。
参数负责上限,策略负责实际到达的高度。
对小模型,策略是杠杆;对大模型,是锦上添花。
同样的线索集,喂给不同上下文管理,结果完全不同。
这就是 0.3 分背后真正的技术含金量。
十、成本账:小参数为什么划算
搜索式任务的特点是输入重、输出轻。
一次搜索回合要吞进大量网页与工具结果。
Iris-mini 的激活只有 3B,推理成本极低。
上下文管理砍掉的是重复输入,不是内容。
对长任务来说,省 token 比省参数更实在。
Iris-pro 适合预算充足的强推理场景。
Iris-mini 适合高频批量、需自托管的场景。
Apache 2.0 授权,留足了商用空间。
256K 上下文意味着单任务可以跑很久。
配合摘要策略,窗口利用率大幅提升。
自托管免去了按次计费的顾虑。
小模型加好策略,可能是性价比最高的组合。
费用模型还要算上检索服务本身。
网页搜索接口按量计费时,轮次越多越贵。
高质量的摘要策略能直接压低检索预算。
每省一轮,就省一次搜索调用费。
这层账,往往被只看推理成本的人忽略。
十一、落地清单与三个盲点
想自跑一套深度搜索,直接选 Iris-mini 起步。
权重、上下文策略、数据方法都已经公开。
训练流水线代码放出后,可以复刻完整配方。
三个盲点需要留意。
第一,闭源模型的逐项数字没有在摘要里展开。
报告对"同规模领先"的措辞限定在开源范围。
第二,AllSpark Research 的机构归属没有公开。
公开报道把它和中国一家内容平台联系在一起。
arXiv 与 GitHub 都没有写明单位。
第三,BrowseComp 之外的独立复测还很少。
榜单分数需要人工实测交叉验证。
拿到的权重可以先跑一次本地评测再决策。
开放权重的好处,就是可以随时自证。
搜索智能体的战场,正在从拼参数转向拼上下文。
Iris 把这条路的门票,一次性交到了开源手里。