Selection-Based Structured Reasoning: Toward Efficient Multimodal Search Agents
Feiyu Gavin Zhu, Xiaoyu Zhu, Jiqi Yang, Rui Yang, Arnab Kumar Mondal, Yancheng Wang, Xinke Deng, Jean Oh, Reid Simmons, Joerg Liebelt, Xiang Kong, Zhongyu Jiang
cs.LG, cs.AI
2026-10-01
Apple 提出 SSR,把搜索 agent 每轮推理改成从 6 条候选里选一条并行打分;4B 模型 7 基准平均 61.37% 持平 SOTA,每轮推理延迟降逾 90%。
ReAct 范式的多模态 agent 在每个动作前先自由生成一段思考,再决定调什么工具、传什么参数。这个设计对大模型不算负担,对小模型很贵:2B/4B 规模推理能力有限,常常写出一长串思考,却给动作生成提供不了多少指导,而自回归解码的延迟一分不少。论文里的测量说得更直接:4B 模型用 GRPO 训练后,自由思考在七个基准上的平均成功率是 58.65%,完全不思考反而有 58.91%。这个规模上,思考块没赚到钱,成本是实打实的。
已有的高效推理方案,比如 Chain-of-Draft 式的简短提示、奖励更短推理的 RL,都在压缩文本量,token 之间的串行依赖原样保留。这篇 Apple 与 CMU 合作的工作换了方向:搜索 agent 的高层推理高度重复,「认出了实体但缺事实,就去搜实体名加属性」这类判断跨题目通用,推理空间不需要铺满整个自然语言。
SSR(Selection-based Structured Reasoning)把每轮推理从开放式生成改成从固定库里选一条。推理库只有 6 条手写的自然语言候选,训练与评测全程不变,七个基准共用,覆盖搜索 agent 的通用情形:认不出实体就反搜图、认出了但缺事实就文本搜索、关键区域太小就放大细看、证据齐了直接作答,外加从图片直接答和用常识答两种。
选法是拿模型自己当分类器,不加任何新组件:
提速靠并行。候选文本预先写好,teacher-forced prefill 一次前向就能算出单条候选内所有 token 的似然,6 条候选又共享同一份历史 KV cache 同时打分,推理阶段模型不生成任何新 token。论文的例子:自由思考 156 个 token 花 1821.92ms,SSR 选中并注入的 31 个 token 只要 32.66ms。
设计上把「下一步做哪类事」和「具体怎么做」拆开:候选只陈述意图,query 和坐标留给动作生成,同一条候选可以服务不同题目。消融支持这个拆法:只对候选编号打分的变体,平均成功率从 61.37% 掉到 58.98%,说明打分需要读到候选的语义。
训练直接套现有目标。SFT 把类别选择损失和动作 token 损失联合优化;GRPO 里,推理部分的逐 token 重要性比率换成一个类别比率,动作 token 照旧。由于推理被结构性限制在库里,RL 可以从 base 模型直接开训,省掉了这类工作常见的 SFT 热身。GSPO、SAPO 用同一套组件也能训。
七个基准(MMSearch、HR-MMSearch、FVQA-test、InfoSeek、SimpleVQA、LiveVQA、MAT-Search),Qwen3-VL 2B/4B 底座:
| 对比 | 指标 | 结果 |
| SSR 4B(GRPO)vs TAPO+GSPO 4B | 七基准平均成功率 | 61.37% vs 61.25%,居 4B 组最佳 |
| SSR vs 自由思考(GRPO 4B) | 每轮推理延迟 | 0.896s → 0.061s,降 93.2% |
| SSR vs 自由思考(GRPO 4B) | 每题模型总延迟 | 5.456s → 2.514s,降 53.9% |
| SSR vs 自由思考(GRPO 4B) | 有效推理吞吐 | 72.7 → 3029.9 toks/s |
| SSR vs 对比方法(测速子集) | 子集成功率 / 每轮推理 p95 | 58.36%(最高)/ 0.071s,对比方法 p95 在 0.798–1.892s |
对比 Chain-of-Draft、Sketch-of-Thought 等四个高效推理基线,SSR 的推理段提速约 7 倍以上,成功率也最高。成功率并非处处持平:GRPO 下 4B 升 4.6%、2B 升 2.6%,SFT 持平,GSPO 降 3.1%,SAPO 降 1.3%;每题总延迟的降幅区间是 28.7%–53.9%。库大小的消融更能说明问题:从 1 条泛泛候选(内容就是「I am a helpful assistant」)到 6 条具体候选,平均成功率从 37.24% 单调升到 61.37%,仅从 1 条到 2 条(作答或调工具)就涨 17.27 个点。行为对得上选择:99.9% 的轮次里,生成的动作类型与所选候选的预期工具一致。2B 版平均 51.26%,接近零样本 8B 模型的 51.33%。
延迟的稳定性同样突出。SSR 每轮推理 p95 只有 0.071s,比均值高约 10ms,打分是固定工作量的计算;自由生成长度方差大,基线 p95 最高到 1.892s。对在线和端侧场景,这种可预测性和均值一样值钱。
对做端侧或成本敏感 agent 的团队,这篇给了一条可复用的路径:在搜索这类任务上,小模型的自由思考可以整体换成一个小而固定的选择空间,成绩不掉,推理段延迟砍九成,实现只需要现有推理引擎的 prefill 通道,没有新组件、没有热身要求,GRPO/GSPO/SAPO/SFT 都能套。它还留下一个刺眼的数字:4B 上自由思考平均不如不思考。问题可能不在想得多少,在想的方式。
适用边界也清楚:最合适的是推理模式重复、每步近似「选下一类动作」的任务;推理空间发散的任务不在验证范围内。
作者自己承认:GSPO 和 SAPO 下成功率降 3.1% 和 1.3%,归因于选择器梯度的 detached-competitor 近似在 rollout 复用多次更新后失准,效率增益在这两个目标下不免费。
读下来另有几处存疑。推理库是手写的 6 条,只为搜索域设计,数学、代码、开放规划这类推理空间发散的任务怎么建库、库要多大,论文没有碰,自动构建库被列为 future work。90%+ 的降延迟只覆盖思考段,整题模型延迟降 28–54%,环境侧的工具执行延迟还被排除在测量外。并行打分省延迟不省算力:所有候选的 prefill 都要算,论文自己算了笔账,在 RTX PRO 6000 上生成 100 个自回归 token 的时间约等于处理一个 15,200 token 的库,库变大优势会被侵蚀。延迟测量每个基准只抽 100 题;非选择题由 Qwen3-VL-32B 当 judge;SFT 轨迹由 Gemini 3.1 Pro 合成,这条管线本身没有单独验证。