现有 search agent 每一步只发一个查询，哪怕两个子查询在逻辑上互不依赖。
论文用 RL 训练模型在 <search> 里用 ## 拆分可并行子查询，
一次动作里并发检索，再用四项奖励约束「该拆的拆、不该拆的不拆」。
代价是：只验证了 Qwen2.5-7B + E5 + 2018 Wikipedia，且 α 与 λf 的数值未在原文给出。
问题不是「搜索次数不够」，而是独立的比较子查询被当成有依赖： Search-R1 这类代理严格串行，Monet / Pissarro 的例子要 3 次 LLM 调用、2 轮 search（§1）。
论文的并行扩展只有一条语法约定：在 <search> 内用 ## 分隔子查询；
Algorithm 1 解析后并行检索，把结果拼进同一个 <information>。
学习信号是四项奖励之和：结果、分解、搜索次数、格式（Eq. 3–7）。
七个基准上，Qwen2.5-7B-Base 的平均 EM 为 0.458， 比 Search-R1 的 0.434 高 2.4 个百分点； Instruct 为 0.425，比 ZeroSearch 的 0.391 高 3.4 个百分点；两档平均 +2.9 个百分点（Table 2）。 并行子集六行平均 #Turns 从 3.36 降到 2.34，对应 LLM 调用相对减少 30.4%（Table 3）。
边界：MultihopRAG-par 的 Base 行 EM 只从 0.569 到 0.573（+0.4 个百分点）， 且低于 Search-R1+Parallel Prompt 的 0.598；可并行 / 不可并行的标签来自数据集问题类型， 不是模型在线判断的真实依赖。
先建立共同认知：串行不是「慢一点」，而是把本可并行的比较题拆成多轮 LLM 调用。
Search-R1 这类 search agent 用 RL 训练 LLM 在多轮里交替推理与检索：
每轮先生成 <think>，再生成 <search> 查询，
拿到 <information> 后继续推理，直到写出 <answer>（§3.1）。
这个循环默认「后一个查询依赖前一个查询的结果」，即使两个子查询在逻辑上互不依赖。
Current search agents must first generate and execute a query for Claude Monet's birth date, analyze the results, then separately query for Camille Pissarro's birth date, before finally synthesizing both results. This workflow requires three LLM calls and two sequential search operations.
论文的关键观察是：很多复杂查询天然包含逻辑上独立、可并发的子组件， 并发检索并不会牺牲推理质量（§1）。上面的 Monet / Pissarro 例子就是两个实体各查一次生日， 两次检索之间没有依赖。
§3.3 的定义：comparison 查询比较两个实体，可以拆成两个子查询，每个实体一个。
Table 7 的案例就是这种结构：<search> location of Laleli Mosque ## location of Esma Sultan Mansion </search>。
§3.3 的定义：bridge 查询需要在桥接段落上推理，因此不可分解。 例如先查「2014 S/S 是哪个组合的专辑」，再查「谁创立了这个组合」； 第二问的查询词依赖第一问的答案（Table 9 的案例）。
所以问题不是「检索不够多」，而是执行图被固定成一条链： 能并行的边也被排成串行。论文要学的是「什么时候可以并行、什么时候必须串行」， 而不是简单地让模型多搜几次。
Table 7 与 Table 9 的完整轨迹未转录；上面只引用查询行作为例子。
两条现有路线：端到端 RL 搜索代理，和 prompt 式并行提示；后者的轮次收益在 Table 3 里并不整齐。
Search-R1 用 RLVR 训练 LLM 交替 think / search，轨迹写成
(t0, s0, c0, …, tn, a)（Eq. 1）。
奖励主要看最终答案是否正确，不约束检索的执行顺序（§2.1、§3.1）。
卡在哪：每一步 search 都等上一步的 information；比较类问题也要两轮检索。
把 Table 1 的模板（含 ## 示例）直接给 Search-R1，模型可以输出分解后的查询，
但策略没有经过「分解是否正确、轮次是否该降」的奖励训练。
卡在哪：Table 3 里它的 #Turns 并不稳定下降，Base 三行甚至从 4.00 升到 4.98 / 4.97 / 4.95。
ZeroSearch 用模拟搜索引擎降低训练成本；StepSearch 做 step-wise PPO；
OTC 用奖励函数惩罚更长的交互轨迹（§4.2：OTC proposes a reward function to give a penalty to trajectories with longer interactions.）。
它们改进的是检索质量或轨迹长度，不是「把独立子查询放进同一轮」。
论文在 §2.1 的总结是：Despite these advances, existing search agents execute queries in a strictly sequential manner.
这句话把已有方案的范围划得很清楚：检索质量可以继续提升，但执行图仍然是一条链。
§4.3 的原句是：However, the number of turns is not reduced, and we believe that Search-R1 cannot correctly follow the parallel instruction.
但 Table 3 的 2wiki-par / Instruct 行，Search-R1+Parallel Prompt 的 #Turns 是
2.64，低于 Search-R1 的
3.05；同一张表的另外五行则高于 Search-R1
（HotpotQA-par Instruct 2.46 vs 2.37；Base 4.98 vs 4.00；2wiki-par Base 4.97 vs 4.00；MultihopRAG-par Instruct 3.37 vs 2.73；Base 4.95 vs 4.00）。
页面把原句和表格并列，不替原文做概括。能确认的是：prompt 式并行在 Table 3 的多数行没有降低轮次， 但 2wiki-par / Instruct 这一行确实降低了。
并行扩展只有一条语法约定；学习信号靠四项奖励拼出来。
<search> 里提交多个子查询
Table 1 的模板要求模型在 <search> 与 </search> 之间写查询，
多个子查询用 ## 分隔：
Table 1 的完整模板未转录；这里只引用 <search> 与 ## 的语法示例。
Algorithm 1 的执行顺序是：先从 <search> / </search> 之间取出拼接查询，
按 ## 拆成 {qi}，并行调用搜索引擎得到
{di = R(qi)}，再把所有结果拼进同一个
<information>[d1, …, dn]</information>（Algorithm 1 第 15–18 行）。
如果模型既没输出 search 也没输出 answer，算法会追加一句
「My action is not correct. Let me rethink.」继续 rollout（Algorithm 1 第 22 行）。
最终奖励是四项之和：r = ro + rd + rs + rf（Eq. 7）。
下面按 Eq. 3–6 逐项拆开。
ro = EM(agold, apred)（Eq. 3）。
精确字符串匹配为 1，否则为 0。它只看最终答案，不看过程。
rd 按查询是否可并行 q ∈ P 和模型是否分解
D(q) 分三种情况（Eq. 4）；α > 1 让可并行查询的分解奖励高于
λd，因为训练集里可分解查询明显更少。
Eq. 4 · §3.3 · 分解奖励 · P = 可并行查询；D(q) = 模型是否分解；λd 为正、α > 1。
| 条件 | 含义 | rd |
|---|---|---|
q ∉ P 且未分解 | 不该拆，也没拆 | λd |
q ∈ P 且已分解 | 该拆，拆了 | α λd |
| 其它 | 该拆却没拆，或不该拆却拆了 | 0 |
按 Eq. 4 逐项读：「不该拆却拆了」拿的是 0，不是负值；
它相对「不拆」少拿了 λd。真正的负值来自
rs 的轮次惩罚，或 rf 在「答对但格式错」时的扣分；
ro 答错只是 0。
rs 对 q ∈ P ∨ q ∈ S 用
−λs|count<search> − 1|；
对其它查询（不可分解的多跳）用
−λs|min(count<search>, 2) − 2|（Eq. 5）。
count = 0 时两项都为负，用来抑制「不检索、直接凭参数记忆作答」（§3.3）。
rf：答案对但格式错，扣 λf；
答案错但格式对，加 λf；其它为 0（Eq. 6）。
论文只要求 λf 为正，正文与 Appendix A.4 都没有给具体数值。
Eq. 5 · 搜索次数奖励 · S = 单跳查询；count<search> 是轨迹里 search 动作的个数。
| 条件 | 目标轮次 | rs |
|---|---|---|
q ∈ P 或 q ∈ S | 1 轮 | −λs |count − 1| |
| 其它（不可分解多跳） | 2 轮 | −λs |min(count, 2) − 2| |
Table 5 的样本数解释了为什么 α > 1 有必要：HotpotQA 的 parallel 子集只有
1,487 条，sequential 有
5,918 条；2WikiMultiHopQA 是
3,040 vs 6,785。
MultihopRAG 则接近平衡（856 vs
816）。
推断（依据：Table 5 的样本数；论文只说「decomposable queries are significantly fewer」，没有对三个数据集分别下结论。）
Table 5（转录） · parallel / sequential 子集的样本数。
| Dataset | Type | # Samples |
|---|---|---|
| HotpotQA | Parallel | 1,487 |
| HotpotQA | Sequential | 5,918 |
| 2WikiMultiHopQA | Parallel | 3,040 |
| 2WikiMultiHopQA | Sequential | 6,785 |
| MultihopRAG | Parallel | 856 |
| MultihopRAG | Sequential | 816 |
rd + rs 怎么变
这个读数器只算 Eq. 4 与 Eq. 5 两项。λd、λs 取 Table 4 中效果最好的
0.15 / 0.35 这一行；α 原文只给 α > 1，页面默认 2.0 并可拖动。
常数 λd=0.15、λs=0.35 来自 Table 4；公式与读数口径来自 §3.3（Eq. 4–5）；α=2.0 为页面设定。
第 1 组，P + 已分解 + count=1，α=2：r_d = α λ_d = 2 × 0.15 = 0.30；r_s = −0.35 × |1 − 1| = 0.00；合计 0.30。
第 2 组，N + 未分解 + count=1，α=2：r_d = λ_d = 0.15；r_s = −0.35 × |min(1, 2) − 2| = −0.35；合计 -0.20。
口径：只算 Eq. 4 的分解奖励与 Eq. 5 的搜索次数奖励；r_o（Eq. 3 的 EM）和 r_f（Eq. 6）不在读数里，因为 λ_f 原文未给数值。没有标准差。
覆盖了什么：P / S / N 三类查询、D(q)=0/1、count=0…4 的分支；未覆盖：r_o、r_f、PPO/GRPO 更新、真实检索与多轮 rollout。α 原文没有给具体值，页面默认 2.0；λ_d、λ_s 取 Table 4 的 0.15/0.35 这一行。
工程可行性：并行化减少轮次，但上下文长度、并发检索和训练稳定性都要单独处理。
训练数据是 NQ 与 HotpotQA 的训练集合并（§4.1）；评测覆盖 7 个基准： NQ、TriviaQA、PopQA 三个通用 QA，以及 HotpotQA、2WikiMultiHopQA、Musique、Bamboogle 四个多跳 QA。 Table 2 用 † 标 in-domain（NQ、HotpotQA），⋆ 标 out-of-domain，‡ 标训练集不同的方法。
Appendix A.4 的训练配置 · 只转录原文给出的值；没有列出的项表示原文未给。
| 项目 | 值 |
|---|---|
| Backbone | Qwen2.5-7B Base / Instruct |
| Retriever / corpus | E5；2018 Wikipedia dump（MultihopRAG 用 benchmark 自带 corpus） |
| 每问检索段落数 | 3 |
| 硬件 | 8 × NVIDIA H100 |
| PPO 学习率 | policy 1e-6；value 1e-5 |
| 训练步数 / warm-up | 500；policy 0.285，value 0.015 |
| GAE | λ = 1，γ = 1 |
| Batch | total 512；mini 256；micro 64 |
| 最大序列 / 最大回复 | 4,096 tokens；500 tokens |
| 检索内容长度 | max 500 tokens |
| rollout | vLLM，TP=1，GPU memory 0.6，temperature 1.0，top-p 1.0 |
| KL / clip | β = 0.001；ε = 0.2 |
| 显存优化 | gradient checkpointing；FSDP + CPU offloading |
并行化的收益写在轮次上：一次 <search> 动作里提交 N 个子查询，
Algorithm 1 并发调用搜索引擎，再把 N 份结果一起塞回上下文（§3.2.1）。
论文的说法是这减少了 turns / rollouts，从而降低推理延迟，也降低了顺序调用搜索引擎的 overhead（§3.2.1）。
代价是同一轮上下文里要容纳 N 份检索结果；A.4 只给了「retrieved content max 500 tokens」，
没有给不同 N 下的上下文长度或并发压力测试。
Table 3 的 Inference 列给的是每问推理时间（秒）。例如 HotpotQA-par / Base 从 2.59 降到 2.16（差 0.43 秒，相对 16.6%）； MultihopRAG-par / Instruct 则是 2.37 vs 2.37，持平。 这些是论文实验环境下的单问读数，不是生产吞吐或美元成本。
§3.1 写 search agent 常用 PPO 与 GRPO 两种算法来比较检索增强推理的表现； Appendix A.4 给出的学习率、GAE、batch、KL/clip 都是 PPO 的配置。 原文没有在同一处说明主表每个配置逐项用的是哪一种算法， 也没有给 GRPO 的超参数。复现时这是一个需要确认的空白。
一张图看清两条执行路径的差别：LLM 调用次数与 search 轮次。
覆盖：Search-R1 的 think→search→info 串行链；ParallelSearch 在单次 <search> 中用 ## 分隔子查询、并行检索并把结果拼接进 <information>；两条路径的 LLM 调用次数与 search 轮次。
未覆盖：Algorithm 1 第 22 行的 rethink 分支；检索 token 的 loss masking；PPO/GRPO 更新；真实检索文档内容与文档长度；N>2 的子查询情况。
简化：把 N 固定为 2，与 §1 的 Monet / Pissarro 例子和 Table 7 的 Laleli Mosque / Esma Sultan Mansion 例子一致；图中「并发检索」只画了两次 R(q) 调用，没有画搜索引擎内部实现。
推断：并行路径的「2 次 LLM 调用」是由 §1 的例子推断的：串行路径 3 次（生成 q1、生成 q2、综合答案），并行路径把两个查询合并到一次生成，剩 2 次。原文 Figure 1 只说减少了 LLM 调用，没有给这个具体次数 推断（依据：§1 的 3 次串行调用与 Figure 1 的对照）。
先看主表平均，再看并行子集的分层结果、消融，以及原文聚合数字与 Table 3 的口径差。
Table 2 是七个基准的 EM。Qwen2.5-7b-Instruct 上，ParallelSearch 的 Avg. 是 0.425，表中基线最高的是 ZeroSearch 的 0.391；Qwen2.5-7b-Base 上， ParallelSearch 是 0.458，基线最高的是 Search-R1 的 0.434。 两个点差分别是 3.4 和 2.4 个百分点，平均 2.9 个百分点。
Table 2（全文转录） · Exact Match (EM)；† in-domain，⋆ out-of-domain，‡ 训练集不同。高亮行为 ParallelSearch，只表示方法所在行，不表示该行每个单元格都是最高分。
| Model | Method | NQ † | TriviaQA ⋆ | PopQA ⋆ | HotpotQA † | 2wiki ⋆ | Musique ⋆ | Bamboogle ⋆ | Avg. |
|---|---|---|---|---|---|---|---|---|---|
| Qwen2.5-7b-Instruct | |||||||||
| Instruct | R1 | 0.270 | 0.537 | 0.199 | 0.237 | 0.292 | 0.072 | 0.293 | 0.271 |
| Instruct | Search-R1 | 0.383 | 0.593 | 0.399 | 0.376 | 0.317 | 0.151 | 0.371 | 0.370 |
| Instruct | OTC | 0.389 | - | - | 0.381 | - | - | - | - |
| Instruct | ZeroSearch ‡ | 0.436 | 0.652 | 0.488 | 0.346 | 0.352 | 0.184 | 0.278 | 0.391 |
| Instruct | StepSearch ‡ | - | - | - | 0.386 | 0.366 | 0.226 | 0.400 | - |
| Instruct | ParallelSearch | 0.462 | 0.628 | 0.429 | 0.429 | 0.424 | 0.197 | 0.411 | 0.425 |
| Qwen2.5-7b-Base | |||||||||
| Base | R1 | 0.297 | 0.539 | 0.202 | 0.242 | 0.273 | 0.083 | 0.296 | 0.276 |
| Base | Search-R1 | 0.488 | 0.644 | 0.469 | 0.436 | 0.412 | 0.187 | 0.403 | 0.434 |
| Base | OTC | 0.446 | 0.623 | 0.425 | 0.383 | 0.363 | 0.152 | 0.391 | 0.398 |
| Base | ZeroSearch ‡ | 0.424 | 0.664 | 0.604 | 0.320 | 0.340 | 0.180 | 0.333 | 0.409 |
| Base | StepSearch ‡ | - | - | - | 0.380 | 0.385 | 0.216 | 0.467 | - |
| Base | ParallelSearch | 0.492 | 0.658 | 0.455 | 0.457 | 0.452 | 0.229 | 0.468 | 0.458 |
Table 2 的 Instruct OTC 与两档 StepSearch 有缺格（原文为「-」），这些行的 Avg. 也留空；Base OTC 七列俱全，Avg. 0.398，本页照录。Avg. 列照录论文（0.425 / 0.458）；按行内七格复算为 0.4257 / 0.4587，四舍五入到三位小数会各高 0.001，页面不改论文 Avg.。
§4.2 的原句是：The improvement of the instruct model is larger than the base model. We achieve absolute improvements of 3.4% and 2.4% using the Instruct and Base models, respectively. Interestingly, the performance of the model trained on Base outperforms that of the model trained on Instruct by 3.3%.
两个说法可以同时成立：Instruct 的基线（ZeroSearch 0.391）低于 Base 的基线（Search-R1 0.434），点差因此更大
推断（依据：0.425−0.391=3.4 vs 0.458−0.434=2.4；原文 §4.2 的解释是 the parallel search capabilities are more effectively utilized by models that have not been instruction-tuned，没有把点差归因于基线高低）。
Base 的最终分（0.458）比 Instruct（0.425）高
3.3 个百分点。
这里论文把「absolute improvements」写成百分号，页面按「百分点」读。
Table 3 只看可并行问题子集：HotpotQA-par（in-domain）、2wiki-par 与 MultihopRAG-par（out-of-domain）。 每行给 EM、Decomposition Ratio（DR）、每问推理时间与 #Turns。六行（3 个子集 × 2 个模型）的 #Turns 平均为 3.36（Search-R1）与 2.34（ParallelSearch），相对减少 30.4%；剩下的调用比例是 69.6%。
Table 3 的六行 #Turns 平均 · 柱高按 3.36 轮归一化；69.6% = 2.34 / 3.36。
Table 3（全文转录） · EM / DR / Inference (s) / #Turns；† in-domain，⋆ out-of-domain。DR 为「-」表示原表未给该值。高亮行为 ParallelSearch，只表示方法所在行，不表示每个单元格都是最高分。
| 子集 | Model | Method | EM ↑ | DR (%) ↑ | Inference (s) ↓ | # Turns ↓ |
|---|---|---|---|---|---|---|
| HotpotQA-par † | ||||||
| HotpotQA-par | Instruct | Search-R1 | 0.580 | - | 2.28 | 2.37 |
| HotpotQA-par | Instruct | Search-R1+Parallel Prompt | 0.620 | 83.20 | 2.22 | 2.46 |
| HotpotQA-par | Instruct | ParallelSearch | 0.656 | 94.30 | 2.03 | 2.08 |
| HotpotQA-par | Base | Search-R1 | 0.641 | - | 2.59 | 4.00 |
| HotpotQA-par | Base | Search-R1+Parallel Prompt | 0.634 | 9.06 | 2.74 | 4.98 |
| HotpotQA-par | Base | ParallelSearch | 0.673 | 97.03 | 2.16 | 2.13 |
| 2wiki-par ⋆ | ||||||
| 2wiki-par | Instruct | Search-R1 | 0.476 | - | 2.37 | 3.05 |
| 2wiki-par | Instruct | Search-R1+Parallel Prompt | 0.573 | 97.59 | 2.22 | 2.64 |
| 2wiki-par | Instruct | ParallelSearch | 0.650 | 99.75 | 2.06 | 2.03 |
| 2wiki-par | Base | Search-R1 | 0.624 | - | 2.60 | 4.00 |
| 2wiki-par | Base | Search-R1+Parallel Prompt | 0.617 | 19.14 | 2.83 | 4.97 |
| 2wiki-par | Base | ParallelSearch | 0.691 | 99.86 | 2.25 | 2.34 |
| MultihopRAG-par ⋆ | ||||||
| MultihopRAG-par | Instruct | Search-R1 | 0.509 | - | 2.37 | 2.73 |
| MultihopRAG-par | Instruct | Search-R1+Parallel Prompt | 0.488 | 59.77 | 2.34 | 3.37 |
| MultihopRAG-par | Instruct | ParallelSearch | 0.641 | 88.67 | 2.37 | 2.57 |
| MultihopRAG-par | Base | Search-R1 | 0.569 | - | 2.42 | 4.00 |
| MultihopRAG-par | Base | Search-R1+Parallel Prompt | 0.598 | 19.66 | 2.55 | 4.95 |
| MultihopRAG-par | Base | ParallelSearch | 0.573 | 60.94 | 2.24 | 2.89 |
这一行里，ParallelSearch 的 DR 是 60.94%， 高于 Search-R1+Parallel Prompt 的 19.66%；#Turns 相对 Search-R1 的 4.00 降到 2.89（相对 Search-R1+Parallel Prompt 的 4.95 也下降）。 但 EM 只有 0.573， 比 Search-R1 的 0.569 高 0.4 个百分点， 却低于 Search-R1+Parallel Prompt 的 0.598。 并行分解确实降低了轮次，但在这个 out-of-domain 子集上没有同步带来更高的 EM 推断（依据：DR 60.94 vs 19.66、#Turns 2.89 vs 4.95、EM 0.573 vs 0.598；原文未解释这一差异）。
2wiki-par / Base 上，ParallelSearch 的 EM 是 0.691， Search-R1 是 0.624，差 0.067； #Turns 从 4.00 降到 2.34。和 MultihopRAG-par / Base 的 +0.004 相比， 同样是 out-of-domain，两个数据集的结果差别很大。 论文没有给逐数据集的原因分析；这里只并列数字，不做归因。
Table 4 在 HotpotQA-par 与 2wiki-par 上扫 λd 和 λs。 §4.4 的结论是 λd=0.15、λs=0.35 最好。 把 λd 设为 0，HotpotQA-par 的 DR 从 94.30 降到 90.94 （差 -3.36，相对 -3.6%），EM 从 0.656 降到 0.636 （差 -0.020），#Turns 从 2.08 升到 2.22 （差 0.14）。 把 λs 设为 0，HotpotQA-par 的 #Turns 从 2.08 升到 2.67 （差 0.59），2wiki-par 从 2.03 升到 2.96 （差 0.93）；EM 也分别降到 0.610 与 0.605 （HotpotQA-par 差 -0.046）。
Table 4（转录） · 原表 8 行中 λd=0.15、λs=0.35 这一行出现两次（第 2 行与第 7 行）；下表合并重复行，保留 7 行。原表共 8 列：λd、λs 加两组各 3 个指标（EM / DR / #Turns），两组指标分别对应 HotpotQA-par 与 2wiki-par。
| λd | λs | HotpotQA-par EM | DR (%) | #Turns | 2wiki-par EM | DR (%) | #Turns |
|---|---|---|---|---|---|---|---|
| 0.00 | 0.35 | 0.636 | 90.94 | 2.22 | 0.610 | 98.33 | 2.13 |
| 0.15 | 0.35 | 0.656 | 94.30 | 2.08 | 0.650 | 99.75 | 2.03 |
| 0.35 | 0.35 | 0.620 | 91.02 | 2.32 | 0.599 | 96.91 | 2.45 |
| 0.50 | 0.35 | 0.641 | 95.63 | 2.06 | 0.606 | 99.61 | 2.03 |
| 0.15 | 0.00 | 0.610 | 96.41 | 2.67 | 0.605 | 99.72 | 2.96 |
| 0.15 | 0.15 | 0.650 | 92.89 | 2.13 | 0.621 | 98.54 | 2.13 |
| 0.15 | 0.50 | 0.641 | 95.63 | 2.06 | 0.606 | 99.61 | 2.03 |
论文摘要在并行问题上给出「12.7%」的性能提升。 按 Table 3 的 Instruct 三行 EM 对 Search-R1 逐行取点差再平均： ((0.656−0.580)+(0.650−0.476)+(0.641−0.509))/3×100 = 12.73 个百分点，和 12.7 吻合 推断（依据：0.076 / 0.174 / 0.132 的平均 = 12.73；原文未写计算式）； 原文写成 12.7%，单位应是百分点，不是相对提升。
§4.3 又写「平均提升 3.05%」。这个数对不上 Table 3 的几种复算： Instruct 三行点差平均 12.73 个百分点、Base 三行点差平均 3.43 个百分点、六行点差平均 8.08 个百分点、六行相对平均 15.3%。 原文没有给 3.05 的计算式；页面把原句和这些复算并列，不替原文选一个口径。
主张—证据映射 · 第一列引论文原句与位置；第二列列可核对值；第三列写口径判断。表格之外的推断在文中标「推断」。
| 论文主张（原句 · 位置） | 可核对值 | 口径判断 |
|---|---|---|
outperforms state-of-the-art baselines by an average performance gain of 2.9% across seven question-answering benchmarks（Abstract；§1 与 §5 复述同一结论） |
Table 2：Instruct 0.425 vs 0.391（+3.4 个百分点）；Base 0.458 vs 0.434（+2.4 个百分点）；平均 +2.9 个百分点 | §4.2 自己写作 2.9% absolute improvement；2.9 是百分点平均，不是相对提升 |
on parallelizable questions, our method achieves a 12.7% performance improvement（Abstract；§1 与 §5 复述同一结论） |
Table 3 的 Instruct 三行 EM 点差平均 +12.73 个百分点（0.076 / 0.174 / 0.132）；与 12.7 吻合 | 原文写成 12.7%，按 Table 3 应为 12.73 个百分点，不是相对提升 |
ParallelSearch achieves an average improvement of 3.05% compared to the baseline method（§4.3） |
Table 3：Instruct 三行点差平均 +12.73；Base 三行 +3.43；六行 +8.08；六行相对平均 +15.3% | 3.05 对不上以上任何一种复算；原文未给计算式 |
reducing LLM calls by 30.4%（§1；§5；Abstract 对应表述为 requiring only 69.6% of the LLM calls） |
Table 3 六行 #Turns 平均 2.34 vs 3.36；相对减少 30.4%，剩余 69.6% | 口径是每问平均轮次，作为 LLM 调用次数的代理；Table 3 的 #Turns 不是总调用数 |
However, the number of turns is not reduced, and we believe that Search-R1 cannot correctly follow the parallel instruction.（§4.3） |
Search-R1+Parallel Prompt vs Search-R1 #Turns：HotpotQA-par Instruct 2.46 vs 2.37；Base 4.98 vs 4.00；2wiki-par Instruct 2.64 vs 3.05；Base 4.97 vs 4.00；MultihopRAG-par Instruct 3.37 vs 2.73；Base 4.95 vs 4.00 | 2wiki-par Instruct 一行从 3.05 降到 2.64，其余五行高于 Search-R1；原文概括与 Table 3 该行并列呈现 |
适用边界：哪些结论有实验支撑，哪些只是这套设定下的结果。
Eq. 4 只要求 α > 1，Eq. 6 只要求 λf 为正；
正文、Table 4 与 Appendix A.4 都没有给这两个常数的数值。
Table 4 只扫了 λd 与 λs，而且只在 HotpotQA-par 与 2wiki-par 两个并行子集上扫，
没有在 MultihopRAG-par 或 sequential 子集上做同样的消融。
Table 6 报告 sequential 子集，本页未完整转录该表，只引用下面这一行。论文（Appendix B）称 ParallelSearch 在 sequential 问题上 也有 EM 提升（HotpotQA-seq / 2wiki-seq / MultihopRAG-seq 平均为 6.34% / 1.30% / 8.86%），但 #Turns 并非都下降：例如 HotpotQA-seq / Instruct 上， ParallelSearch 是 3.55 轮， Search-R1 是 2.34 轮（Table 6）。 这说明「并行化」在必须串行的问题上不会自动带来轮次收益 推断（依据：Table 6 的这一行；Appendix B 只汇总 sequential 子集的 EM 增益，没有逐数据集讨论轮次）。
页面只覆盖 v1（arXiv:2508.09303v1）。Figure 3、Figure 4、Figure 5、Figure 6 未转录： 它们是 CDF、响应长度、训练曲线与 top-k 曲线，正文没有给逐点数值；本页没有使用这些图的逐点数值。