GrepSeek、FORT-Searcher、SAAS 对比:三个修法
GrepSeek 改搜索工具(直接 grep 语料,弃用向量索引),FORT-Searcher 改训练数据(抗捷径合成任务),SAAS 改停止时机(检索次数砍半、精度基本持平)。
搜索智能体循环,与三个修法各自落在哪一环
训练过的搜索智能体和没训练过的跑的是同一个循环:决定搜什么、发起检索、读结果、判断要不要再搜、最后作答。2026 年的三篇论文分别攻击这个循环的三个不同环节,而且它们报告的数字几乎不可直接比较,这本身就是本次对比最有用的事实。
GrepSeek 替换的是搜索工具。智能体不查预建好的嵌入索引,而是直接对原始语料跑 shell 命令(grep、管道、正则)。它主张的是检索保真度与基础设施:不用建索引、索引不会过期、在嵌入模糊的地方做到精确。FORT-Searcher 不动工具,重建训练数据:它合成深度搜索任务,刻意让任何单条线索都无法过早暴露答案,再用这些任务做监督微调。它主张的是单位激活参数的能力。SAAS 两个都不动,重训停止决策:用强化学习教会小模型认清自己的知识边界,不再发起不需要的检索。它主张的是同等精度下的成本。
所以诚实的定位是分工,不是赛跑。一个团队完全可以三个都想要:用 FORT 式数据教会真正的取证,语料适合词法访问时上 GrepSeek 式工具,再用 SAAS 式 RL 把推理账单压下来。
GrepSeek:换掉智能体用什么搜
标准 RAG 把每篇文档嵌入一次,靠最近邻查询作答。这个索引是语料的冷冻有损摘要:你只能看到嵌入模型决定编码的内容,语料每次更新都要重新嵌入一遍。GrepSeek 的直接语料交互(DCI)干脆扔掉索引,让智能体像开发者搜代码库一样搜索真实字节:字面或正则模式,读完命中再收窄,顺着线索跨文件追。
训练分两段。先用双角色冷启动构造一批经过验证的轨迹:知道答案的 Tutor 负责把查询引向证据,不知道答案的 Planner 保证轨迹真实,因为部署后的智能体同样不知道答案。只有真正挖到支撑文本的轨迹能留下来。第二段用 GRPO(DeepSeek-R1 带火的无 critic 组相对 RL)按轨迹是否答对来 refine 策略。
让 DCI 可训练的工程件是分片并行执行引擎:把每次 grep 拆到多个分片并发执行,并保证与串行执行字节级一致。并行搜索如果悄悄改变命中顺序,就会污染 RL 奖励信号,所以”字节一致”这一条才把 7.6 倍加速从演示技巧变成训练循环的部件。
论文自己承认的天花板在词法层面:同义改写、复述、形态变化这类查询恰恰是稠密检索的主场,作者的结论也是 DCI 最好与嵌入检索配合使用,而非取而代之。
FORT-Searcher:换掉智能体拿什么训
FORT 从一个尴尬的测量出发:一道多跳题题面上很难,实际却可能崩塌:一个罕见线索第一轮搜索就锁定答案,或者模型凭参数记忆本来就认识这个实体。拿这样的任务训练,教的是”识别暴露线索”,不是搜索。FORT 定义四类捷径风险:证据共覆盖、单线索过强、常数暴露、先验绑定,然后合成同时控制这四类的任务,再加一步对抗式 refinement:让一个强搜索智能体来拆解每道草稿题。捷径太明显的草稿修掉,模糊到不可解的收窄,直到可解且仍然必须搜索。
训出的 FORT-Searcher 在规模上刻意克制:基于 Qwen3-30B-A3B-Thinking,推理时约 3B active 参数,只做监督微调。正是这份克制让”数据质量”主张变得可读:收益不可能被记到更大的模型头上。
最有迁移价值的贡献是诊断而非模型权重。FORT 测量轨迹中答案首次出现的时间(答案命中时间)和真实求解成本。相比 REDSearcher 数据,同一诊断口径下 FORT 把平均答案命中时间从 18.7 推迟到 46.9,平均求解成本从 92.1 抬到 141.0,智能体必须先取到证才能答。消融是这组里最干净的因果证据:拿掉捷径控制后,合成题准确率从 29.0 跳到 81.6,答案命中时间从 46.5 塌到 11.8,题目恰以被设计阻止的方式变容易了。
SAAS:改掉智能体何时停
SAAS 打的是过度搜索:参数记忆本来就能答的问题也发起检索(不必要搜索),或证据已经够还继续查(冗余搜索)。测出来的基线很难看:以效率见长的 HiPRAG 在问题级过度搜索率上几乎是 100%。
方法有三块。搜索边界:对每道训练题对比两次 rollout(一次禁检索、一次开检索),在当前策略下推断该题是否真的需要外部证据,且随策略更新重估。边界感知奖励:对不必要搜索零容忍,但对真正需要检索的题,只惩罚超过”最小充分”阈值的那部分冗余,避免了平坦惩罚的翻车模式:模型学怕搜索,难的多跳题就崩了。两阶段课程:先训推理能力,再打开效率正则,模型没学会怎么搜之前没机会靠拒搜来骗奖励。
Qwen2.5-7B-Instruct 上的结果:平均每题检索次数从 2.19 降到 0.97,平均精度 48.7%,基本持平 HiPRAG 的 49.8%。问题级过度搜索率从 100% 降到 45.9%,步级冗余搜索率从 19.5% 降到 6.3%。Qwen2.5-3B-Instruct(1.13 次)与 Qwen3-4B-Instruct 也有报告,覆盖 TriviaQA、PopQA、NQ、HotpotQA、2WikiMultiHopQA、MuSiQue、Bamboogle 七个 QA 基准。作者自己说得很清楚:精度是换成本,不是提精度;瓶颈是答案质量就用错了工具。
关键数字
| 测量项 | GrepSeek | FORT-Searcher | SAAS | 设置与来源 | 同口径? |
|---|---|---|---|---|---|
| 智能体规模 | 未强调 | 3B active(Qwen3-30B-A3B) | 7B / 3B / 4B instruct | 各自论文设置 | 否 |
| 训练信号 | 冷启动 SFT 后接 GRPO | 只用 FORT 数据 SFT | 边界感知奖励 RL | 各自论文设置 | 否 |
| 深度搜索总评分 | 未报告 | 五基准总体 66.2 | 未报告 | FORT:完整可比同规模结果的五个基准 | 仅 FORT 行内 |
| 具名比较对象 | 检索与智能体基线的 F1/EM 综合领先 | MiroThinker-1.7-mini 64.6,Qwen3.5-35B-A3B 59.9 | HiPRAG 精度 49.8% | 各自基线 | 否 |
| BrowseComp | 未报告 | 72.2(无上下文管理时 55.9) | 未报告 | FORT 论文 | 否 |
| BrowseComp-ZH | 未报告 | 75.0(无上下文管理时 62.1) | 未报告 | FORT 论文 | 否 |
| xbench-DeepSearch-2505 / 2510 | 未报告 | 80.8 / 57.2 | 未报告 | FORT 论文 | 否 |
| Seal-0 | 未报告 | 46.0 | 未报告 | FORT 论文 | 否 |
| 轨迹诊断 | 未报告 | 答案命中 46.9、求解成本 141.0(REDSearcher:18.7 / 92.1) | 步级冗余搜索 6.3%(基线 19.5%) | 各自诊断口径 | 否 |
| 捷径控制消融 | 不适用 | 移除控制后准确率 29.0 → 81.6,命中时间 46.5 → 11.8 | 不适用 | FORT 论文 | 仅消融内部同口径 |
| 平均每题检索次数 | 未报告 | 未报告 | 0.97,HiPRAG 为 2.19(7B);3B 为 1.13 | SAAS 论文,七个 QA 基准 | 仅 SAAS 行内 |
| 效率基线对比下的精度 | 七个 QA 基准 F1/EM 综合领先(聚合) | 未测 | 48.7% 对 HiPRAG 49.8% | SAAS 论文,Qwen2.5-7B | 是,SAAS 对 HiPRAG |
| 过度搜索率 | 未报告 | 未报告 | 45.9% 对 HiPRAG 100% | SAAS 论文 | 是,SAAS 对 HiPRAG |
| 基础设施主张 | 分片并行 grep 7.6 倍加速、字节一致 | 不适用 | 不适用 | GrepSeek 论文 | 不适用 |
读这张表要读它缺什么:三篇之间没有任何一篇正面对比另外两篇。FORT 的 66.2 和 SAAS 的 48.7% 是不同基准、不同指标、不同智能体上的数字;GrepSeek 的”F1/EM 综合领先”和 SAAS 的七个 QA 基准也不是同一批;FORT 的 BrowseComp 数字与另外两篇毫无共同口径。严格同口径的比较只存在于各论文内部:FORT 对具名基线智能体、SAAS 对 HiPRAG,以及各自论文自己的消融。
三者的共性与分歧
三篇都把搜索当成可训练的行为,而不是提示词工程问题;三篇的智能体规模都不大,FORT 甚至刻意用小模型来隔离数据效应。三篇交出的也都比模型权重更可复用:GrepSeek 的冷启动配方、FORT 的轨迹诊断(记录答案首次出现的时间、模型是否在取证前已猜中)、SAAS 的分阶段奖励设计,各自都能搬到别的智能体上。
分歧决定采用路径。GrepSeek 动的是基础设施:你需要对语料的 shell 级访问,并容忍词法失效模式。FORT 动的是数据管线:你需要任务合成回路和一个强对抗智能体,但部署端就是普通 SFT。SAAS 动的是奖励:你需要 RL 基础设施和训练时的边界对比 rollout,换来的部署收益是更小的推理账单。三者的失效模式互不重叠:GrepSeek 输在同义复述多的语料;FORT 的收益在可验证短答案搜索任务之外未经验证;SAAS 在精度上明确不求改进,也不带来改进。
怎么选
- **语料是代码库、文件系统或任何可 shell 访问的文本,而建嵌入索引贵或容易过期:**GrepSeek 的 DCI 是自然选择,与同义复述多的查询走稠密检索混合使用。
- **搜索智能体没搜就答,或一条线索就能拆穿你的多跳任务:**先看 FORT 的诊断。给自己的轨迹记答案命中时间;如果答案总早早出现,换什么模型都救不了数据问题,直接上 FORT 式合成。
- **检索账单(延迟、API 成本、上下文 token)远超模型账单:**SAAS 是三个里唯一直接打成本的,2.19 降到 0.97 的代价是 7B 模型约一个点的精度差。
- **只能做一个:先修数据。**FORT 的消融(移除捷径控制后准确率 29.0 跳到 81.6、命中时间 46.5 塌到 11.8)是这组里最大的实测效应,而坏训练数据会悄悄压住下游所有环节的上限。
- **可以叠加:**FORT 数据教取证,GrepSeek 工具决定怎么取证,SAAS 的 RL 砍掉取证次数。三篇论文互不冲突,作用在循环的不同环节上。
局限与存疑
核心缺口是没有共享口径:没人拿同一个智能体同时训 FORT 数据、装 GrepSeek 工具、加 SAAS 奖励,再对单修法做消融报告。在那之前,上面的分工是从三篇独立论文推断出来的,不是测出来的。规模也没探明:FORT 的智能体 3B active,SAAS 最大 7B,抗捷径数据和边界感知奖励在前沿规模是否仍然有效是开放问题。GrepSeek 的评测偏向适合词法访问的语料,这在复述密集的开放网络环境里偏袒了它,而那正是 BrowseComp 式智能体的主场;FORT 和 SAAS 用的是网络搜索或固定语料 QA 设置,GrepSeek 的字节一致引擎并不覆盖。三篇都只评可验证短答案,没有一个测量开放式研究、企业知识库或需要主观打分的任务里的搜索质量。最后,FORT 的诊断和 SAAS 的边界估计在训练时都依赖强模型裁判或对比 rollout,所以它们的数字是操作性代理指标,不是地面真值。
常见问题
三种方法在同一个基准上对比结果如何?
没有这种对比。FORT-Searcher 报的是深度搜索基准(五基准总体 66.2、BrowseComp 72.2、xbench-DeepSearch-2505 80.8、Seal-0 46.0),SAAS 报的是七个 QA 基准上的精度加检索次数(48.7% 精度、0.97 次检索,对 HiPRAG 的 49.8%、2.19 次),GrepSeek 报的是自己七个基准上的 F1/Exact-Match 综合领先。任何把三者排出名次的表,都是在拼凑从没共享过口径的数字。
FORT-Searcher 的实际结果是什么?
在同规模、成绩完整的开源智能体里总体 66.2(五个基准),高于 MiroThinker-1.7-mini 的 64.6 和 Qwen3.5-35B-A3B 的 59.9,其中 BrowseComp 72.2、BrowseComp-ZH 75.0、xbench-DeepSearch-2505 80.8、xbench-DeepSearch-2510 57.2、Seal-0 46.0。光上下文管理一项就把 BrowseComp 从 55.9 拉到 72.2。
SAAS 比普通搜索智能体精度更高吗?
不,它也没这么宣称。Qwen2.5-7B-Instruct 上平均精度 48.7%,对 HiPRAG 的 49.8%,差约一个点;同时平均每题检索从 2.19 次降到 0.97 次,过度搜索率从 100% 降到 45.9%。它是成本方法,不是精度方法。
GrepSeek 的方法与 RAG 有何不同?
GrepSeek 完全去掉嵌入索引:智能体直接在语料字节上执行 grep、正则等 shell 命令,先由成对的 Tutor 与 Planner 生成经验证的冷启动轨迹,再用 GRPO 强化。其分片并行引擎让这套流程比串行快 7.6 倍且字节级一致。实测代价是弱于同义复述类查询,所以作者把它定位为稠密检索的补充而非替代。
构建搜索智能体应该先试哪个方法?
先诊断再选。如果轨迹显示答案在真正取证之前就出现了,先做 FORT 式数据合成并记录命中时间;如果账单是问题而精度可接受,上 SAAS;如果索引是问题(过期、昂贵、或没有 shell 级访问),上 GrepSeek。错误的第一步是挑标题数字最大的那个,因为三个数字测量的是三件不同的事。