AllSpark Iris 搜索智能体领跑同级别模型，但有一个与评测框架相关的限制

小红书的 AllSpark 团队发布了 AllSpark Iris 搜索智能体，提供 35B 和 397B 总参数量的两个开放权重版本。团队表示，两款模型在多项高难度搜索基准测试中均领先于同级别的开放系统。这一说法值得关注，但最能说明问题的并非排行榜名次，而是外围上下文管理系统带来的性能增幅。

Iris-mini 和 Iris-pro 均提供可下载权重及开放评测框架。AllSpark 还在一篇详细技术论文中介绍了其数据管线和训练流程。团队表示，后续将发布更多训练资产，为研究人员提供复现成果的路径，而不仅仅是展示一个打磨完善的演示版本。

该发布从两个方面给其他开放搜索智能体项目带来压力。Iris 一方面报告了强劲的同级别得分，另一方面也展示了推理封装层能对这些得分产生多大影响。因此，这既是一次模型发布，也是一次关于行业应当衡量什么的讨论。

AllSpark Iris 搜索智能体不只是两个检查点

AllSpark 发布的是一套配对搜索系统，其行为取决于训练权重、工具和明确的上下文控制机制。

Iris-mini 基于 Qwen3.6-35B-A3B 后训练而成。它拥有 350 亿总参数，但每个 token 仅激活约 30 亿参数。Iris-pro 则基于 Qwen3.5-397B-A17B，拥有 3970 亿总参数，其中约 170 亿参数处于激活状态。

两个版本均采用专家混合架构。这种设计会让每个 token 经由选定的专用参数组子集，而不是激活整个模型。因此，总参数量描述模型容量，激活参数量则更能反映每一步生成所需的计算量。

每个版本均支持 256,000-token 的上下文窗口。这一容量很重要，因为搜索智能体在长期研究过程中会累积查询、返回页面、提取段落、中间推理和工具消息。即使上下文窗口很大，智能体在解决困难的多跳问题前也可能将其填满。

Iris-mini 权重和 Iris-pro 权重采用 Apache 2.0 许可证发布。该许可证允许在其条款下广泛使用、修改和再分发。因此，开发者可直接获得两种模型规模，而非只能通过托管界面使用 Iris。

AllSpark 还发布了评测代码，其中包括模型服务配置和支持基准测试的运行配置。该框架使用兼容 OpenAI 的工具调用接口，因此可将智能体连接到搜索和页面阅读功能。

搜索智能体不同于传统聊天机器人，因为它控制着一个迭代式证据循环。它决定搜索什么，解读返回材料，在证据不完整时调整查询，并判断何时可以作答。最终回答取决于这一循环中的每一个决策。

AllSpark 报告的是单个 ReAct 智能体的结果。ReAct 是一种交替进行推理和工具操作的模式，使模型能够在每次观察后调整策略。报告中的配置未使用子智能体，也没有单独的测试时验证团队。

这一细节限定了基准测试结果所代表的含义。Iris 并非通过启动大规模并行智能体组织、再合并其工作来获得主要得分。不过，它仍依赖一个管理工具、上下文、重试和答案格式的推理框架。

因此，这次发布比单纯的一组模型文件更具价值。研究人员可以检查检查点周围的运行假设，也可以测试当 Iris 运行于不同搜索提供商、上下文策略或部署预算下时，哪些增益仍然存在。

对开发者而言，较小的模型是更易于接触的实验目标。35B 专家混合检查点依然颇具规模，但其 3B 激活参数量令其行为尤其值得关注。它提出了一个问题：定向后训练能否在不为每个 token 激活数千亿参数的情况下，产生具备竞争力的搜索能力。

397B 版本则在更大容量下检验同一方案。比较两者可为判断哪些失败可通过规模改善、哪些更依赖推理机制提供依据。

这种区别构成了 Iris 的核心张力。权重是开放的，但复现其宣传中的智能体并不只是加载这些权重，还需要重建产生所报告行为的搜索环境。

同级别搜索智能体为何正面临压力

Iris 提高了开放权重模型在提出领先基准测试主张时应同步披露信息的标准。

AllSpark 将 Iris-mini 与大约 30B 至 35B 范围内的开放权重系统进行比较。其公布的对比包括 MiroThinker-1.7-mini、FORT-Searcher、Apodex-1.0-mini、Nex-N2-mini、Agents-A1 和 XYZ-Aquila-mini。

在 Iris 的主推上下文设置下，Iris-mini 在 BrowseComp 上得分 82.2，在 BrowseComp-ZH 上得分 84.8；在 DeepSearchQA 上录得 86.9，在 Humanity’s Last Exam 的纯文本子集上录得 52.3。

Iris-pro 在 BrowseComp 上得分 88.6，在 BrowseComp-ZH 上得分 85.1，在 DeepSearchQA 上得分 92.9，在 Humanity’s Last Exam 上得分 56.4。AllSpark 将这些描述为各自参数范围内最强的开源搜索智能体整体成绩。

这些基准测试考察研究流程的不同部分。BrowseComp 强调跨分散证据的高难度网页浏览；BrowseComp-ZH 将类似挑战应用于中文网页检索；DeepSearchQA 衡量综合研究回答，而 Humanity’s Last Exam 则强调专家级知识与推理。

评分方法并不完全相同。DeepSearchQA 使用 F1 指标，其他报告任务则使用准确率。AllSpark 在 Humanity’s Last Exam 的 2,158 道纯文本问题子集上进行评估，因此该结果不应被视作该基准测试所有版本的得分。

这些对比也不构成完全受控的模型竞赛。AllSpark 指出，基线数据来自公开报告，而各项目可能采用自身的上下文策略。一些竞争对手的得分由另一团队复现，而非 Iris 研究人员复现。

这一限制并不会抹去结果，而是改变其含义。Iris 展现出强劲的同级别整体方案，但该表格将模型质量与智能体架构、评测流程之间的差异结合在了一起。

这正是其他开放项目面临压力的原因。当替代方案同时披露受管理和未受管理条件下的结果时，只报告顶线分数的模型卡如今显得不完整。开发者越来越需要了解，性能提升究竟来自后训练、更多工具调用、上下文压缩、重试，还是更强的评判设置。

因此，竞争目标正从单个检查点转向一套完整且可复现的智能体。一次有价值的发布需要提供权重、提示词、工具契约、搜索行为、上下文策略和评测设置。缺少其中任何要素，都可能使外部团队无法复现所宣称的结果。

商业研究产品也面临类似挑战。其封闭系统可以组合专有模型、搜索索引、编排层和验证循环。它们或许能够提供更好的端到端可靠性，但外部人员很难分离出究竟是哪一组件带来了优势。

Iris 为开放开发者提供了一套可供审视的具体系统。他们可以更换搜索后端、移除上下文重置、限制轮次预算，或在私有文档上进行测试。相较于单一公开分数，这些实验对部署决策更有意义。

这次发布也强化了评估智能体经济性的理由。一次受限搜索后即可正确作答的系统，与多次重新开始的系统，具备不同的运行特征。若没有工具调用次数、token 使用量、延迟和失败率，准确率无法为买家提供完整比较。

对于构建研究助手的团队而言，近期压力十分实际。他们不仅必须解释智能体是否能找到答案，还必须说明它能否稳定地收集可辩护的证据。他们也需要展示，当页面消失、搜索结果变化，或任务超出名义上下文预算时，系统会如何表现。

Iris 并未解决这些问题，但让竞争项目更难回避它们。

SFT-RL Climbing 训练的是搜索循环，而不只是答案

核心技术贡献是一条围绕复杂证据链和与实时搜索反复交互设计的训练管线。

Iris 研究论文介绍了一条始于网页语料超链接结构的数据管线。它将页面视为节点、链接视为边，然后围绕选定种子页面构建局部图。

该系统利用这些图生成多跳问题。多跳问题需要整合多个位置的证据，而非检索一句包含答案的句子。这种构建方式针对的是让网页研究变得困难的决策序列。

AllSpark 将非答案实体改写为描述性指代。这一步移除了模型可直接输入搜索框的明显名称，目的是避免浅层字符串匹配解决本应用于衡量调查能力的任务。

候选问题随后需通过两项测试：一个参考模型必须无法仅凭其存储知识作答；同一个模型在获得支持证据后则必须成功作答。这一筛选旨在保留确实需要检索、同时能从已确定来源作答的问题。

强大的教师模型将通过筛选的问题转化为搜索轨迹。轨迹记录任务过程中产生的推理步骤、查询、观察和结论序列。AllSpark 在监督微调前，会同时在完整轨迹和单个轮次层面对这些示例进行筛选。

监督微调，即 SFT，会利用经挑选的理想行为示例来训练模型。在 Iris 中，这些示例不止涵盖最终回答，还展现了智能体如何选择查询、处理页面，以及判断是否需要更多证据。

随后，模型会针对实时搜索接受强化学习。强化学习通过奖励信号调整行为，而不是复制固定的目标回复。AllSpark 在训练集群内部部署了奖励评判器和观察摘要器。

团队在名为 SFT-RL climbing 的流程中交替进行 SFT 和强化学习轮次。在强化学习中发现的、成功但困难的轨迹会回到下一监督阶段。该流程也偏好高效解法，鼓励模型在下一轮探索前保留有用行为。

这种循环应对了智能体训练中的一个常见问题。静态示范可以教授可识别的模式，但无法覆盖变化中的网络上遇到的所有失败情况。纯强化学习可以探索新策略，却可能产生嘈杂或低效的行为。交替进行这些阶段，可使每一阶段修正另一阶段的弱点。

长程 rollout 带来了另一个基础设施问题。一项搜索请求可能产生足以超出实际训练限制的工具调用流量和 token。AllSpark 表示，它会在请求层面中断过长的 rollout，随后从已提交的前缀继续执行。

据披露，训练配置包括两个监督训练 epoch、64 的全局 batch size，以及 262,144 token 的最大序列长度。两款模型在进行这项搜索专项后训练之前，均从 Qwen mixture-of-experts checkpoints 初始化。

AllSpark 还表示，评估期间会阻止访问托管基准测试的页面。相关 Hugging Face dataset 和 Space 路径下的页面会从搜索结果中移除，在抓取时被拒绝，并在工具使用后接受检查。这项防护旨在减少基准答案的直接泄露。

这些方法均无法保证评估完全不受污染。训练语料、基础模型预训练数据以及镜像的基准讨论，仍可能使泄露分析变得复杂。不过，公开这些防护措施，也为独立评估者提供了可供质疑的具体流程。

数据配方尤为重要，因为搜索表现无法简化为对事实知识的记忆。智能体必须识别证据缺失，构造有效查询，并在结果无效后恢复推进。这些行为取决于后训练中所使用轨迹的质量和多样性。

这一机制也解释了 Iris 为何可能在公开网页搜索之外发挥作用。类似的证据循环同样存在于技术支持、法律审查、市场研究和内部知识发现中。团队可以让智能体遍历获批的代码库，而非公共互联网。

例如，一个工程团队可以要求智能体关联一份事故报告、一份设计文档和一项代码变更。模型仍需决定去哪里搜索，以及证据是否支持其结论。结构良好的可搜索知识库会成为智能体有效环境的一部分。

这种迁移并非自动发生。基于网页训练形成的查询习惯，可能无法适应私有命名规范或不完整的内部文档。在将系统用于具有重要影响的研究之前，企业需要领域专属测试、访问控制和源级引用。

不过，Iris 提出了一个具体假设：更好的搜索智能体来自对完整证据收集循环的训练。更大的基础模型会有帮助，但只是这一循环的一个输入。

基准领先依赖于有意识的遗忘

Iris 最具影响力的结果是：丢弃上下文对搜索智能体的提升，可能超过许多竞品模型之间已报告的差异。

AllSpark 在有无上下文管理的情况下均评估了 Iris。其主打配置采用一种称为 discard-all 的方法。一旦提示内容超过设定阈值，评测框架便将对话重置回原始问题。

这个名字听起来具有破坏性，因为智能体会失去累积的工具调用记录。但长搜索历史中往往包含重复的页面文本、失败的查询，以及已不再有帮助的推理。移除这些内容可为后续调查恢复空间。

评测框架可以在完整对话之外保留有价值的进展。一项相关的 retry 设置会重启未能产出可解析答案的任务，并保留一份简短摘要，记录已排除的可能性。这使遗忘成为主动搜索策略，而非意外损失。

较小模型的效果最为明显。没有上下文管理时，Iris-mini 在 BrowseComp 上得分为 64.7。启用 discard-all 后，得分达到 82.2，提升 17.5 分。

在相同对比下，BrowseComp-ZH 从 72.3 提升至 84.8。DeepSearchQA 从 81.0 升至 86.9，而 Humanity’s Last Exam 则从 43.2 增至 52.3。

结合 discard-all 和 retry 的配置，使 Iris-mini 在 BrowseComp 上达到 85.9、BrowseComp-ZH 上达到 85.1、DeepSearchQA 上达到 89.9，以及 Humanity’s Last Exam 上达到 52.4。AllSpark 并未在其主打对比中采用这一更激进的配置。

更大的 Iris-pro 也从中受益，尽管效果总体较小。论文认为，Iris-mini 需要更多步骤才能解决相同约束，因此更常耗尽上下文。Iris-pro 则可以在上下文成为关键限制前完成更多推理。

这为理解模型规模提供了有益视角。更大的模型可能不仅知道得更多或推理得更好，还可能以更少的高成本交互找到答案，从而降低对恢复机制的依赖。

结果也因基准而异。上下文管理对 BrowseComp 的帮助大于 Humanity’s Last Exam。AllSpark 将这种差异归因于会话实际耗尽上下文的频率。

BrowseComp 任务要求反复检索、筛选和整合证据。Humanity’s Last Exam 则更重视专家知识和推理，网页检索可以补充答案，但并不主导每一个步骤。

一项结果表明，容量未必总是主要瓶颈。采用 discard-all 加 retry 的 Iris-mini，以及两种受管理设置下的 Iris-pro，在 BrowseComp-ZH 上均达到 85.1。论文指出，这相当于在 289 个问题中答对 246 个。

这种趋同可能有多种解释。剩余问题可能包含歧义、无法获取的证据、评判局限，或是额外模型容量无法解决的搜索失败。在一个基准上观察到的上限，并不能证明存在普遍限制，但它提醒我们，不应假定规模能修复每一种搜索错误。

这正是 AllSpark Iris 搜索智能体发布中最核心的反转。256K 上下文窗口看似巨大，但一次直接重置却能显著改善结果。积累更多上下文，并不总意味着获得更多有用上下文。

这一发现影响产品设计。智能体界面往往将单一对话呈现为天然有价值的连续过程。但在界面背后，一个可靠系统可能需要多次总结、修剪、分支或重启这段对话。

它也使开放与闭源智能体之间的比较更加复杂。两款产品可能使用相同的底层模型，却因其中一方更有效地管理上下文而产生不同结果。反过来，较弱模型也可能因搭配更昂贵的搜索策略而显得更强。

因此，评估 Iris 的开发者应将上下文策略视为可配置组件。他们应在衡量成功率的同时，衡量延迟、token 消耗、搜索请求和重启频率。对于偶发调查，更高分数或许值得额外成本；但对于高吞吐工作流，则可能并不合适。

有意识的遗忘并不意味着上下文窗口已经不再重要。更大的窗口会推迟历史记录变得限制性的时点。Iris 的结果反而表明，智能体仍需要一项策略来决定哪些内容值得保留在窗口中。

Iris 分数尚未证明的事情

报告中的领先表现足以值得测试，但尚不能作为其现实研究能力更强的独立证据。

核心数据来自 AllSpark 自身的评估。团队提供了异常有用的细节，包括未受管理条件下的结果及其评测框架配置。独立团队仍需使用已发布的权重和代码复现这些分数。

基线可比性是另一项局限。竞争项目可能使用不同的搜索引擎、页面解析器、轮次限制、上下文控制和评判器。由不同公开报告汇编而成的表格，无法像共享评估环境那样清晰地分离 checkpoint 质量的影响。

即便基础设施的微小变化，也可能改变搜索结果。搜索排名会随时间变化，网站会阻止自动阅读器，而提取出的页面可能遗漏重要内容。下个月接受评估的模型，面对同一查询时可能获得不同证据。

评判层带来了更多不确定性。Iris 在适用场景中使用各基准的官方评估提示词，并采用基于 LLM 的评判器。这类评判器可能对格式、冗长程度和答案等价性敏感。一份可解析的简短答案，可能会与包含相同核心结论但更具论证性的报告得到不同分数。

这些搜索基准也仅覆盖研究质量的一部分。最终答案正确，并不必然说明每个引用来源都可信。它也无法证明系统能抵御操纵页面、提示词注入、协同虚假信息或过时证据。

AllSpark 表示，主要评估中每个问题只进行一次 rollout。Pass@1 很有用，因为它避免从多次尝试中挑选最佳答案。然而，这并未说明面对不断变化的搜索结果时，系统在重复运行中的波动有多大。

retry 实验让成本问题变得更迫切。一次完整重启可能消耗另一轮搜索和生成序列。AllSpark 明确将重置与 retry 结合的结果视为探索性的性能上限，而非其主要性能设置，因为重试会带来显著的推理成本。

该项目在发布初期的开放性也并不完整。模型权重和评估代码已公开，而更广泛的数据和训练配方预计将分阶段发布。论文解释了相关过程，但完整可复现性仍取决于具体数据集、过滤器、提示词和训练组件的最终发布。

以 Apache 2.0 许可发布 checkpoint，降低了实验的法律门槛。但这并不保证每一份上游语料或生成轨迹都可再分发。用户在构建商业衍生产品前，应审查未来数据发布的来源和条款。

Iris-pro 带来了另一项部署障碍。激活 17B 参数比激活全部 397B 参数更高效，但完整 checkpoint 仍需要大量内存和基础设施。对于无法在可接受延迟和运营限制内提供服务的团队而言，其基准优势可能毫无意义。

Iris-mini 或许是更具启发性的产品候选。其较小的活跃规模为受控部署提供了合理路径，但它对上下文管理的依赖也暴露了周边成本。团队应测试完整任务的经济性，而非仅根据活跃参数推断效率。

现实世界评估还必须纳入弃答能力。一个有用的研究智能体应能识别何时证据相互矛盾、无法获取或不足。公开基准通常奖励最终答案，而商业工作流有时则要求智能体停止并报告不确定性。

安全测试同样重要。搜索智能体会处理来自页面的不可信文本，其中可能包含针对模型的指令。无论是强大的检索分数，还是基准泄露控制，都无法证明系统能抵御间接提示词注入。

这些限制并不会将 Iris 降格为一场营销活动。该项目提供了足够多的材料供严肃审查，并在自身论文中说明了若干局限。这正是独立复现如今如此重要的原因。

正确的近期结论应当保持克制。AllSpark 在有据可查的设置下报告了同等规模模型中的领先结果，其未受管理条件下的分数也仍具竞争力。Iris 能否成为可靠的研究引擎，将取决于超越基准答案准确率的测试。

三个信号将决定 Iris 能否保持领先

下一阶段的重点是可复现性、运营成本，以及在四项已报告基准之外的表现。

首个信号是对其主要结果的独立复现。研究人员应通过公开评测框架运行已发布的 checkpoint，同时记录工具调用、上下文重置、token 使用量及失败情况。若能高度复现，将增强 AllSpark 的主张：该发布代表的是一套可迁移的系统，而非私有评测环境。

较大的差距并不会立即否定这项工作。搜索结果和页面可用性会变化，硬件与服务软件也可能影响长文本生成。复现者应记录这些差异，并测试托管和非托管两种设置。

非托管结果尤其值得关注。由于评测框架提供的恢复辅助更少，它们能更清晰地反映后训练阶段学到的行为。如果外部评估者能够复现这一优势，Iris 的训练流程将成为更具竞争力的参考范式。

第二个信号是其承诺发布训练数据和实现细节。模型权重展示了最终策略，但无法揭示用于生成任务或筛选轨迹的每一个决策。具体工件将让研究人员能够检查难度、多样性、数据泄漏风险和来源覆盖度。

这一发布也将支持消融研究。消融研究会移除某个组件，以衡量其贡献。研究人员可以测试：实体改写、闭卷筛选、轮次级筛选、实时搜索强化学习，或 SFT-RL 循环，究竟哪一项带来了最大的提升。

如果这些组件能够迁移到其他基础模型，Iris 的方法论可能比任一 checkpoint 都更重要。竞争团队可以采用相同流程，缩小排行榜差距。若无法迁移，则表明这些结果可能更依赖特定的 Qwen 基础模型或内部训练条件。

第三个信号是在现实预算与对抗性条件下进行评估。有效测试应限制搜索请求数、实际运行时间和生成 token 数量，同时还应衡量引用、来源质量、弃答能力以及对恶意页面内容的抵抗力。

这些限制条件下的结果，将更清楚地说明 Iris-mini 和 Iris-pro 之间的实际取舍。较大的模型或许能以更少轮次完成任务，而较小模型则可能通过上下文重置和额外搜索来弥补。买家需要的是系统总成本和可靠性，而不只是参数量。

竞争对手的回应将构成这一信号的另一部分。开放智能体项目可以通过发布托管与非托管结果来加强自身报告。封闭式提供商则可以就引用准确性、延迟和重复运行的一致性提供更清晰的证据。

对开发者而言，最好的即时行动是将 Iris 视为一套可测试的研究栈。先从取自自身领域、范围受控的任务集开始。记录该智能体是否获取了正确来源、能否应对不完整页面，以及在证据不足时是否会承认不确定性。

然后每次只改变一个系统组件。禁用上下文重置、限制搜索调用、更换搜索提供商，或缩短上下文窗口。这些测试能揭示 AllSpark Iris 搜索智能体是否确实适用于你的工作负载，以及其基准优势来自何处。

这次发布已经带来了一条持久的经验：搜索智能体的性能存在于模型与其操作系统之间的交互之中。下一个问题是，独立测试是否会证实 Iris 同时改进了两部分，还是它主要只是找到了在上下文填满后继续搜索的更好方法。