SpecHop: 连续推测加速多跳检索代理

# SpecHop：用于加速多跳检索代理的持续推测机制 来源：https://arxiv.org/html/2605.21965 Mehrdad Saberi Keivan Rezaei11footnotemark:1Soheil Feizi 马里兰大学帕克分校 \{msaberi, krezaei, sfeizi\}@umd\.edu 项目页面：https://github.com/mehrdadsaberi/spechop ###### 摘要 大型语言模型越来越多地使用外部工具（如网络搜索和文档检索）来解决信息密集型任务。然而，复杂任务中的多跳工具使用会带来显著的延迟，因为模型必须反复等待工具观察结果才能继续执行。我们研究了如何在保持模型在不加速情况下原本会采用的最终轨迹不变的同时，加速此类轨迹，假设我们可以访问更快但不太可靠的推测器工具。我们为多跳工具使用场景中的无损推测建立了一个理论框架，描述了可达到的最优延迟增益。我们提出了SpecHop，一种持续推测框架，该框架维护多个推测线程，在目标工具输出到达时异步验证预测的观察结果，提交正确的分支，并回滚错误的分支。这种方法在保持精度的同时减少了挂钟延迟。我们证明，只要有足够多的活动线程，SpecHop可以接近理想的延迟增益。在实验中，针对检索增强的多跳任务，SpecHop与理论预测高度吻合，并在某些设置中将延迟降低了高达40%。 ## 1 引言 大型语言模型正越来越多地配备外部工具，包括网络搜索、文档检索、代码执行环境和API[15 (https://arxiv.org/html/2605.21965#bib.bib26),34 (https://arxiv.org/html/2605.21965#bib.bib19),12 (https://arxiv.org/html/2605.21965#bib.bib31),3 (https://arxiv.org/html/2605.21965#bib.bib30),1 (https://arxiv.org/html/2605.21965#bib.bib29)]。这使得更复杂的任务成为可能，例如深度研究、代理工作流、交互式决策以及需要与外部环境交互的信息密集型推理[25 (https://arxiv.org/html/2605.21965#bib.bib21),24 (https://arxiv.org/html/2605.21965#bib.bib20),11 (https://arxiv.org/html/2605.21965#bib.bib33),4 (https://arxiv.org/html/2605.21965#bib.bib34),29 (https://arxiv.org/html/2605.21965#bib.bib2)]。在这些场景中，模型的轨迹不再是单一的前向生成，而是一个推理、工具调用、观察结果以及进一步推理的多步骤过程。本文中，我们专注于信息收集工具，如网络搜索和数据库检索[33 (https://arxiv.org/html/2605.21965#bib.bib4),6 (https://arxiv.org/html/2605.21965#bib.bib36),23 (https://arxiv.org/html/2605.21965#bib.bib5),26 (https://arxiv.org/html/2605.21965#bib.bib37)]。让语言模型能够调用外部工具可以提高性能，但也会引入显著的执行延迟[35 (https://arxiv.org/html/2605.21965#bib.bib1),20 (https://arxiv.org/html/2605.21965#bib.bib22)]。由于推理轨迹是顺序的，模型可能进行推理、等待网络搜索结果、再次推理、从数据库检索文档，并在多个跳上重复这个过程。因此，总延迟不仅取决于模型解码，还取决于外部工具调用。最近的性能分析研究表明，这一瓶颈在实践中非常显著：在深度研究代理中，对于GPT-5，网络搜索平均占端到端延迟的73%，在更复杂的情况下甚至高达91%[13 (https://arxiv.org/html/2605.21965#bib.bib35)]。在本文中，我们加速这类多跳工具使用轨迹，同时保持模型在不加速情况下原本会采用的轨迹不变。Ye等人[35 (https://arxiv.org/html/2605.21965#bib.bib1)]提出了*推测性行动*，该方法假设可以访问一个具有非零成功概率p的推测器，用于预测工具调用返回结果。他们表明，这类推测器在实践中可以以更低的延迟预测目标工具结果。他们的方法是在原始工具调用并行运行的同时推测一个跳，然后验证结果以保持精度，并在推测成功时减少延迟。在此设置基础上，我们为多跳工具使用轨迹的无损推测建立了一个理论框架。我们首先研究一种理想验证设置，其中推测的正确性可立即获知，从而得出任何无损推测方法可实现的延迟改进上限。受我们对这种设置的理论分析的启发，我们提出了SpecHop，一种持续推测框架，目标是接近理想延迟增益。SpecHop并非在每个目标工具调用返回时空闲等待，而是在整个轨迹中保持推测流水线活跃。它维护多个并行线程，每个线程对应同一底层轨迹的不同推测阶段，并在之前的目标调用仍在运行时继续推测未来的跳。当目标输出可用时，验证器检查相应的推测观察结果是否等同于目标观察结果。如果验证成功，SpecHop提交该推测分支并用新的推测线程扩展它；如果验证失败，则丢弃下游的推测工作并从最后验证的状态继续执行（见图1 (https://arxiv.org/html/2605.21965#S1.F1)）。因此，SpecHop在保持原始轨迹验证结果的同时减少了挂钟延迟。我们对SpecHop进行了理论分析，并证明它可以在保持无损的同时缩小与理想延迟增益的差距。我们根据推测器的相对延迟以及外部工具调用所占时间比例，描述了所需的活动线程数量。实验上，我们在检索增强的多跳问答任务（2WikiMultihopQA[6 (https://arxiv.org/html/2605.21965#bib.bib36)]、MuSiQue[23 (https://arxiv.org/html/2605.21965#bib.bib5)]和DeepResearch-9K[29 (https://arxiv.org/html/2605.21965#bib.bib2)]）上评估了SpecHop，使用网络搜索或Wikipedia检索作为外部工具，并使用基于LM的推测器或基于快速缓存的推测器。在这些场景中，延迟与我们的理论预测吻合，SpecHop在保持任务准确率的同时，相对标准的多跳执行实现了高达40%的延迟增益。 图注：图1：SpecHop的持续推测执行概览，查询需要4次外部调用时维护k=3个活动线程。最初，T1调用目标工具获取(a1,o1)。并行地，T2推测第一个观察结果为o^1并继续到下一跳，在那里它调用目标工具获取(a2,o2)；类似地创建T3。当o1返回时，验证器V将其与o^1进行比较。由于验证失败，T2及其下游推测线程T3被丢弃，方法从最后验证的线程继续。系统然后创建新的推测线程T4和T5，同时T1等待(a2,o2)的目标输出。当o2返回时，与T4中o^2的验证成功，因此系统提交T4并继续用T6进行推测。后续验证也成功：系统在o3返回后提交T5，一旦o4返回，T5产生最终答案f。通过保持流水线活跃而不是在每个跳顺序等待，SpecHop减少了挂钟延迟，同时保留了原始验证轨迹。 ## 2 相关工作 ##### 推测解码。大型语言模型中的自回归令牌生成在推理时可能造成内存带宽瓶颈[8 (https://arxiv.org/html/2605.21965#bib.bib11),30 (https://arxiv.org/html/2605.21965#bib.bib13)]。推测解码通过“草稿-验证”范式缓解这一问题，其中较小的草稿模型提出令牌，由较大的目标模型验证，产生与目标模型分布匹配的数学无损输出[2 (https://arxiv.org/html/2605.21965#bib.bib12),8 (https://arxiv.org/html/2605.21965#bib.bib11)]。最近的工作通过多个草稿器[10 (https://arxiv.org/html/2605.21965#bib.bib15)]、并行推测流水线[37 (https://arxiv.org/html/2605.21965#bib.bib14)]以及具有不同词汇空间的草稿/目标模型[21 (https://arxiv.org/html/2605.21965#bib.bib16)]扩展了这一思想。我们的工作共享草稿-验证哲学，但推测的是工具观察结果而非令牌。 ##### 推测执行的基础。推测执行起源于计算机体系结构，用于克服指令级瓶颈并避免条件分支造成的停顿[19 (https://arxiv.org/html/2605.21965#bib.bib6)]。分支预测方法利用历史寄存器和执行模式估计未来控制流[36 (https://arxiv.org/html/2605.21965#bib.bib8)]，而推测机制在保证需要之前就执行预测的指令，一旦真实控制流已知就进行验证，并在预测错误时回滚[18 (https://arxiv.org/html/2605.21965#bib.bib7),22 (https://arxiv.org/html/2605.21965#bib.bib9)]。SpecHop将这一经典系统原理从指令级执行适配到语言模型代理的轨迹级工具使用。 ##### 代理工具使用与检索增强生成。为语言模型配备外部工具，特别是检索[9 (https://arxiv.org/html/2605.21965#bib.bib18)]和搜索，已成为检索增强生成和代理框架的核心[14 (https://arxiv.org/html/2605.21965#bib.bib24),27 (https://arxiv.org/html/2605.21965#bib.bib27),17 (https://arxiv.org/html/2605.21965#bib.bib25),32 (https://arxiv.org/html/2605.21965#bib.bib23)]。加速检索增强代理最近从几个互补角度进行了研究。Wang等人[28 (https://arxiv.org/html/2605.21965#bib.bib17)]专注于流水线开始时的静态检索，使用多个具有不同检索文档的推测性RAG模型，之后用更大的通用型LLM进行验证，从而在不牺牲准确率的情况下减少延迟。Sui等人[20 (https://arxiv.org/html/2605.21965#bib.bib22)]提出通过识别模型生成中的模式来更早地预测工具调用需求，使系统在模型明确到达工具调用点之前就能启动工具。与我们最接近的工作是Ye等人[35 (https://arxiv.org/html/2605.21965#bib.bib1)]，他们表明一些外部调用可以被更快的推测模型取代，提供了个别工具使用跳有时可以通过推测来加速的经验证据。 ## 3 加速多跳工具使用轨迹 能够使用工具的语言模型通过调用外部工具来回答查询，当需要额外信息或计算时。它们通常将查询分解为中间步骤，每一步要么通过参数化知识解决，要么通过工具（如网络搜索、文档检索或Wikipedia文章等文档数据库）解决。这种行为在DeepResearch[29 (https://arxiv.org/html/2605.21965#bib.bib2)]和多跳问答数据集[6 (https://arxiv.org/html/2605.21965#bib.bib36),23 (https://arxiv.org/html/2605.21965#bib.bib5),33 (https://arxiv.org/html/2605.21965#bib.bib4)]研究的设置中很常见。给定一个查询q，模型M遵循迭代的工具增强轨迹：它生成中间推理，调用工具，接收观察结果，更新其状态，并重复这个过程直到产生最终答案。形式上，对于查询q，模型M遵循一个推理轨迹，经过状态s0,s1,...,sN，其中s0由查询诱导，sN是终止状态。在每个状态si（0≤i<N），模型执行以下操作： - 它生成一个推理片段τi+1 = M(si)，解码直到下一个工具调用或终止。在调用工具时，片段以动作ai结束，该动作指定要调用的工具及其参数。 - 然后模型调用工具：oi = T(ai)，休息直到收到工具输出。 - 模型通过合并观察结果来转换到下一个状态：si+1 = Update(si, τi+1, ai, oi)。 总轨迹延迟是所有工具调用时间∑Ttarget,i和所有片段生成时间∑Tseg,i的总和。由于这些部分在典型的顺序执行中是顺序的，并且模型在等待工具时必须暂停，因此总延迟等于∑Tseg,i + ∑Ttarget,i。当模型在调用工具时产生中间推理时，这些工具调用时间往往占主导地位，但并非总是如此。例如，对于短检索调用，数据库查询可能很快，而延迟可能由模型解码主导；但正如[13]所示，对于慢速工具，例如通过网络搜索进行深度研究时，外部调用时间可能是解码时间的数倍。在本文中，我们研究如何利用更快的推测器来隐藏部分工具调用延迟。 ### 3.1 推测器设置 我们假设可以访问一个推测器S，该推测器可以比真实工具T更快地生成观察结果。在某些情况下，推测器也利用上下文来预测所需的证据，但即使没有上下文也可能产生结果（例如，通过缓存）。推测器S在某些设置中可能不太可靠：当它以非零概率p成功时，其生成对于模型下一步而言与真实工具同义。我们形式化这一点。 ###### 定义1（推测器） 推测器S是一个函数，它接受当前状态si、生成的片段τi和动作ai，并返回一个推测观察结果 ôi = S(si, τi, ai)。 ###### 假设1（推测质量） 推测器以概率p > 0成功，这意味着推测观察结果会诱导与目标工具观察结果相同的下一状态。也就是说，以概率p，有Update(si,τi, ai, ôi) = Update(si,τi, ai, oi)。 这发生在所需的事实信息已经被现成模型的参数化知识捕获，或者存在于较小的数据库或缓存中时。现有工作表明，这类推测器在实践中可以是有用的，实现非平凡的成功概率。 ##### 推测器延迟。设Tspec为随机变量，表示推测器的延迟，包括产生推测观察结果并使模型能够转换到下一状态所需的时间。我们假设推测器比目标工具更高效，即Tspec <stochastic> Ttarget，其中≤_stochastic表示随机序，即对于所有t≥0，P(Tspec > t) < P(Ttarget > t) 。期望值满足E[Tspec] < E[Ttarget]。 为了使推测有助于加速，我们还需要能够验证推测观察结果是否与目标观察结果等效。 ###### 假设2（可验证等效性） 存在一个验证器V，可以确定推测观察结果对于模型下一状态的目的而言是否等同于目标工具观察结果。形式上，验证器接收当前状态、生成的片段、动作、推测观察结果和目标观察结果，并返回V(si, τi, ai, ôi, oi) ∈ {0, 1}。当V(si, τi, ai, ôi, oi) = 1时，系统被允许提交推测转换。当验证器返回0时，系统必须丢弃推测分支。 ##### 信息检索中的验证。在信息检索设置中，验证可以检查目标工具和推测器是否提供了所需的信息，例如，相同的事实知识或模型查询的语义等效证据。严格的验证器会降低成功率p，而较宽松的验证器能确保推测观察结果提供足够信息，从而在一定程度上保持轨迹，并以更高的p维持任务准确率。 ### 3.2 利用推测实现快速准确的轨迹 我们使用两个无量纲量来参数化系统的延迟特性。首先，我们定义*相对推测器延迟* α ≜ E[Tspec]/E[Ttarget]。由于推测器被假设比目标工具更快，因此α < 1。其次，我们定义*解码-工具延迟比* β ≜ E[Tseg]/E[Ttarget]。这个量衡量模型端片段生成相对于目标工具执行所花费的时间。我们首先描述使用推测器S可以实现的最高理论延迟增益。为此