📄 边听边搜:端侧级联语音助手用投机执行隐藏工具延迟
英文题目:Hiding Tool Latency in On-Device Cascaded Voice Agent through Speculative Execution
标签:#语音代理规划与工具使用 | #工具增强与约束解码 | #流式处理 | #端侧运行
评分:6.0/10 | 创新 1.2/2 | 技术严谨 1/1.5 | 实验充分 1/1.5 | 清晰度 0.7/1 | 影响力 0.8/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1/1.5
👥 作者与机构
- Kyudan Jung:机构信息未在 arXiv HTML 中可靠披露
- Hyunsin Park:机构信息未在 arXiv HTML 中可靠披露
- Yoonhyung Lee:机构信息未在 arXiv HTML 中可靠披露
- Jinhwan Park:机构信息未在 arXiv HTML 中可靠披露
- Jinhyeok Yang:机构信息未在 arXiv HTML 中可靠披露
- KiHyun Nam:机构信息未在 arXiv HTML 中可靠披露
- Jaegul Choo:机构信息未在 arXiv HTML 中可靠披露
- Jinkyu Lee:机构信息未在 arXiv HTML 中可靠披露
📌 核心摘要
级联式语音助手把自动语音识别、大语言模型推理与文本到语音依次串行,输入为流式语音、输出为首段语音回答,远程搜索须在说话结束并由模型确认意图后才执行,延迟直接计入等待,而部分转写虽能提前暴露意图,却面临纠正与变更风险。流式部分转写先进入基于规则的预测器,预测器切分子句并行预判可能需要的只读搜索请求,并在用户说话期间经远程搜索接口提前发起调用。取回结果存入推测结果缓存,说话结束时已完成结果与最终转写一起直接拼入回答模型提示词,供生成回答时直接使用。若模型仍发出工具调用,系统先做缓存校验,命中复用、未命中走常规路径,模型保留自主调用兜底;与基线不同,该设计把部分网络延迟重叠到说话时间内。在自建146条英文合成语音评测集的真机实测中,相对级联基线,端到端首音频延迟中位数从5.79 s降至4.60 s,工具调用F1从44.8%提高到60.6%,标准差从3.49 s降至2.81 s。实测用Samsung Galaxy S26 Ultra,识别与合成跑在CPU、量化Llama-3.2-3B跑在NPU;对抗样本下21次浪费调用构成额外网络成本,但推测限于只读工具,不改写闹钟、日历等数据。结论适用于英文信息检索与本地受限算力,遇关键词干扰或中途纠正、撤回与主题变更时提前结果可能作废,原文未报告训练费用、能耗等项目。
🔗 开源与复现资源
本次未形成可展示的已核验资源记录,开放状态尚未核实。
可达状态仅表示本次链接检查结果,不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
这篇论文要解决的等待问题是什么
论文研究的是带工具的端侧级联语音助手。输入是用户说的一段话,目标是听懂后调用日历、闹钟或联网搜索等工具,再用语音回答。必须保留的信息是用户原意和工具返回的事实,不能靠模型编造。输出是第一段可播放的语音和最终文本回答。级联指自动语音识别、大语言模型、语音合成依次串行:先等用户说完并定稿转写,大模型再判断调哪个工具,工具跑完大模型再写回答,最后才合成。
问题在于远程搜索很慢,这段耗时完全落在用户说完之后,用户能直接感知到等待。论文想把这段等待藏进用户还在说话的时间里。读者需要先建立这个串行时间线的概念,后面才能理解投机提前跑的价值。论文在手机上实测了完整链路,不是只仿真其中一段,这种端到端实测保留了真实网络波动和端侧推理开销。
级联与端到端在工具调用时机上有何不同
论文把相关路线按输入、目标和运行阶段来区分。级联助手的优点是模块之间是显式文本,可以检查和改写,可靠性思路更直接,但代价是必须等转写定稿,大模型才能看到完整请求并点名工具。端到端语音系统可以在流式生成过程中更早启动工具,但那是另一类架构,输入处理和监督方式都不同,不能直接把它的延迟数字拿来对比。论文还提到增量口语理解和投机执行的思想,即意图往往在话没说完时已经明显,可以做预期计算。
论文的定位很明确:不改级联的基本分工,只在识别进行中加一个轻量预测分支,提前做长延迟的只读搜索,最后仍由大模型决定怎么用。这种比较没有把不同架构的胜负混为一谈,只是说明为什么级联需要额外的隐藏延迟手段。理解这一点可以避免误以为论文在宣称级联全面优于端到端。
时间线是如何定义和要隐藏哪一段
论文用一组时间戳把基线说清楚。t0 是用户开始说话,tASR 是识别定稿时刻,tLLM-call 是大模型第一次判断并选定工具完成的时刻,tTool 是工具执行完成时刻,tLLM-resp 是第二次大模型写完回答的时刻,tTTS 是合成完成时刻。基线顺序是 t0 之后依次经过这些时刻,总时长是 tTTS 减 t0。论文要隐藏的是 tTool 减 tASR 这一段,也就是定稿之后才开始的工具等待,把它尽量挪到 tASR 之前、与识别重叠。如果提前猜对了,用户说完时搜索结果已经回来或已经在路上,剩下的主要是本地模型推理,波动更小。
论文举例说,一个约 15 秒的提问若需要约 10 秒搜索,基线首音频要 17 秒,投机后可到 8 秒,这只是一个说明重叠效果的例子,不是承诺所有请求都省这么多。最坏情况下大模型仍可自己调工具,所以延迟上界就是原来的串行链路,这一点是设计的兜底保证。
整体流程如何把搜索提前到说话期间
整体流程有 3 条路。识别还在流式输出部分词语时,预测器持续观察,猜到可能的搜索请求就经搜索接口提前执行,结果放进投机结果缓存。等识别定稿,已完成的投机结果通过路径 b 直接放进大模型提示词,大模型先看到转写和提前搜到的资料再生成。若大模型仍发出工具调用,系统走路径 c 先查缓存,命中就复用,不命中才走路径 a 正常联网执行。这是一个先提前跑、再直接给、最后核对的三步设计。
部署上识别和语音合成跑在 CPU,量化后的 Llama-3.2-3B 跑在 NPU,预测和缓存管理等在 CPU 侧处理,搜索走远程网页搜索接口。下面的时间框图可以帮助建立重叠的直觉,先看基线工具块都在定稿之后,再看投机方法如何把工具块前移到识别条带下方。
流式语音识别 × 投机工具执行: 流式语音识别指用户还在说话时就不断给出部分转写,投机工具执行指不等最终转写和大模型点名就先按部分转写猜测并提前联网搜索。两者分工是前者提供越来越完整的线索,后者利用等待时间提前干活,组合后把原本落在说话结束后的搜索耗时叠加到说话进行中,后面可直接复用结果。
读图说明:下面这张是基线与投机的时间块对比图,上面是串行等待,下面是提前执行加缓存命中,请重点看工具耗时相对说话结束点的前移情况。
看图路径: 1. 对比上下两条时间轴上工具块相对说话结束点的位置;2. 看投机分支中预测与搜索块与流式识别的重叠方式;3. 看缓存命中时省掉了哪一段串行等待
论文图 1。原论文 Figure 1::“Timing block diagram of speculative tool calling.”。
这张图上半是级联基线,非流式识别结束后依次是大模型选工具、两次工具执行、大模型写回答、合成。下半是投机方法,流式识别进行中就出现预测和工具小块,定稿后大模型可缓存命中,只剩一次工具、一次大模型和合成,后面标出更低延迟。图注还说明图中画的是两个所需工具调用中有一次缓存命中的情形,不是每次都全命中。理解这张图的关键是重叠不是省掉搜索,而是把搜索换个时间做,从而让说话结束后的等待变短。
预测器何时触发又如何切分多个意图
预测器是一个基于规则的轻量模块,不是每次来一个词就跑,而是在固定节奏触发:看到最少 6 个词后开始,之后每多 5 个词检查一次,或者检测到超过 300 毫秒的句末停顿时也检查。这样既不会太早乱猜,也不会错过较长的停顿。每次触发时,它把当前累积的部分假设按标点和 and、but、also、then、while 等连接表达切成互不重叠的从句,每个从句独立判断。例如查波士顿天气、找附近餐馆、问日元汇率的一句话会被切成 3 段,分别对应 3 类搜索候选。
主题来自固定的 12 类粗粒度信息需求集合,一句话里的多个意图可以并行发出。论文说这种从句级分析的动机是增量口语理解,目的是早发现、早并行。下面系统总览图展示了预测器输出如何变成搜索调用,读图时先跟主转写箭头,再看分支。
预测器 × 投机结果缓存: 预测器负责在识别过程中按规则切分从句并猜测搜索意图,投机结果缓存负责保存搜索接口返回的文本。预测器只管提前触发,缓存管保存和后续复用,组合后大模型既能在生成前直接看到提前搜到的资料,也能在自己要点工具时先查缓存避免重复联网。
读图说明:下面是方法总览图,左侧是说话人和流式识别,中间是预测器与搜索接口,右侧是大模型与缓存的 3 条路径,请按输入到输出的箭头顺序仔细观察。
看图路径: 1. 沿左侧语音输入找到预测器与搜索接口的触发箭头;2. 区分路径 a 正常调用、路径 b 直接注入、路径 c 校验复用的走向;3. 确认识别在 CPU、大模型在 NPU 的部署标注
论文图 2。原论文 Figure 2::“Overview of our methodology. During streaming ASR processing, the Predictor anticipates potential tool calls and retrieves relevant information via a Search API.”。
图中左侧例子是查首尔机票价格并问仁川机场到江南的路线,预测器提前给出两个 searchWeb 查询,经搜索接口后结果存入投机结果缓存,缓存里示例包括方向和汇率信息。路径 b 是直接注入给大模型,路径 c 是已验证回退,路径 a 是正常调用。部署标注写明流式识别在端侧 CPU,大模型是端侧 NPU 上的量化版本。这张图的教学价值在于把猜测、缓存、复用三者的位置一次讲清,看到提前搜索并不经过大模型点名,而是独立分支。
直接注入与缓存校验如何分工防纠正
在识别定稿时刻,已完成的投机结果和最终转写一起放进提示词,大模型带着这些资料生成输出。这是直接注入,它省掉了先选工具再等结果的过程。用户说话中可能自我纠正,直接注入的资料可能已经过时,所以论文加了基于规则的校验,只把有效的缓存结果注入,并在大模型仍要点工具时做二次核对。核对时刻若缓存有匹配就直接返回,避免重复检索,否则走正常路径。这个设计保留了大模型原有的工具调用能力作为兜底。
论文报告在评测集中大模型仍有部分情形发出工具调用,其中一部分是信息已给却重复要工具,这与所用的小量化模型能力限制有关。也就是说直接注入不是强制大模型闭嘴,而是提供资料加保留点菜权。
直接注入 × 已验证回退: 直接注入指在最终转写确定时把已完成的投机结果直接放进大模型提示词,已验证回退指当大模型仍然发出工具调用时先核对缓存,命中则复用,未命中才走正常联网。直接注入省掉等大模型选工具的时间,已验证回退保证猜错或没猜中时仍能正常执行,两者一快一稳。
理解这部分要抓住两件事:提前拿资料是为了快,校验和兜底是为了在用户改口时不错写日历闹钟。论文把投机限制在只读工具,也是为了让猜错只浪费一次联网,不改用户数据,这种读写分离是控制风险的关键。
本研究训练了什么以及规则如何确定
本研究没有训练语音识别、大模型或语音合成,所用的流式 Conformer 识别、语音合成和量化大模型都是已有模型直接调用,规则预测器也不需要梯度训练。实际的计算过程是规则触发、从句切分、意图映射、搜索接口调用、缓存读写和提示词拼接。触发阈值按真实用例分布选为最少 6 词、步长 5 词、停顿 300 毫秒,论文明确说这是基于实际分布,不是搜索出来的最优超参。12 类主题是预先固定的粗分类,预测器只做映射不更新权重。
大模型侧没有微调,监督信号来自评测集的人工标注,只用于评价工具选得对不对,不用于回传梯度。因为无训练,不能从参数冻结推出输出确定,联网搜索结果和识别部分假设都会随输入和网络变化。缺失的信息是规则模板的具体写法和缓存匹配的相似度细节,原文没有给出完整实现,复现时只能按描述重做,这一点需要如实指出。
在什么手机和数据上实测延迟与准确率
评测在一台三星旗舰手机上完成,芯片标注为骁龙新一代型号。识别和合成跑 CPU,量化大模型经高通栈跑 NPU,音频输入输出、规则预测、缓存管理和网络分发在 CPU 侧,搜索走远程接口。数据集是自建的,因为没有公开的面向安卓语音助手工具使用的数据集。包含手写英文,覆盖单搜索、多搜索、日历闹钟和无需工具的请求,每条标注了期望工具和参数,另加含搜索关键词但不需要搜索的硬负例和含纠正撤回、延迟意图或换话题的对抗样本。
为可复现,每条用合成语音实时播给设备,全集约一个多小时音频,含合成和联网的一轮完整运行约 3 小时。主要延迟指标是首音频延迟,从输入语音结束到第一段合成音频输出,方向是越小越好。搜索评价看所需搜索结果是否被最终回答使用,还报告查准查全、误读率、浪费调用和缓存就绪率,这些口径决定了后面数字的含义。
投机方法把等待时间缩短了多少
主结果要回答在同样手机和同样请求下,投机是否更快更稳且工具选得更准。比较的是级联基线与完整投机方法,延迟指标越小越好,工具分数越高越好,条件是同一自建集上的端到端实测,含真实网络波动。下表整理了中位延迟、离散程度和工具分数,基线是等定稿后才调工具,投机是提前搜索加缓存注入。
| 条件 | 延迟口径 | 基线中位 | 投机中位 | 离散程度变化 | 工具分数变化 |
|---|---|---|---|---|---|
| 同机实测 | 说话结束到首音频 | 5.79 s | 4.60 s | 3.49 s 到 2.81 s | 44.8% 到 60.6% |
上表显示中位首音频延迟从 5.79 秒降到 4.60 秒,标准差从 3.49 秒降到 2.81 秒,工具分数从 44.8% 升到 60.6%,论文把更稳归因于把易波动的远程搜索挪到说话期间,说完后剩下主要是本地推理。长话叠加长搜索时的例子说明长尾改善的来源,但那是单个示例,不能当作平均提升。限制是这些数字只在该手机、该量化小模型和特定搜索的条件下成立,换网络、换模型或换请求分布结果会变。未胜出项是长尾绝对值依然很高,投机只是缓解不是消除。
首音频延迟 × 工具调用 F1: 首音频延迟指从用户说话结束到系统播出第一段合成语音的时间,越小越跟手,工具调用 F1 指搜索工具选得准不准,综合查准和查全。论文同时看两者是因为提前搜索既可能掩盖延迟,也可能给小模型更多上下文而改善选工具,两个指标分别回答快了多少和选对了多少。
遇到关键词干扰和中途改口时会怎样
鲁棒性要回答猜错的代价有多大。硬负例考验含关键词但不应搜索,对抗样本考验纠正撤回换话题。两组都是同一自建集的困难子集,条件与主结果一致。下表是原文鲁棒性诊断表,展示了样本数、延迟、分数、误读和浪费调用,表头第二行是单位行。
| Set | nn | p50 | F1 | False read | Spec calls | Wasted |
|---|---|---|---|---|---|---|
| (s) | (%) | (%) | calls | |||
| Hard negatives | 22 | 6.24 | N/A | 9.1 | 2 | 2 |
| Adversarial | 24 | 8.40 | 90.2 | 12.3 | 21 | 21 |
上表硬负例子集样本少,中位延迟较高但误读率只有个位数,投机调用很少,说明很少只按关键词乱搜。对抗子集分数保持在 90% 左右,误读率略高,但有较多浪费调用,反映提前搜的网络成本。关键限制是投机只限只读工具,所以猜错不会改闹钟日历等用户数据,这句话有原文明确支持。负结果是浪费调用在对抗下明显增多,若计费或流量敏感,这就是主要代价。还需要补的验证是中文或更口语化的纠正是否同样能被规则校验丢弃,现有结论只在英文手写集上成立。
硬负例 × 对抗样本: 硬负例指话里有搜索关键词但实际不需要搜索的请求,用来考验是否乱触发,对抗样本指中途纠正、撤回、换话题的请求,用来考验猜错后能否丢弃。两者分工不同,一个测误触发,一个测意图变化后的纠错,组合起来说明投机只做只读搜索且有校验时风险可控。
数据集由哪些请求组成
数据构成要回答结论依赖什么样的输入分布。下表按论文自建集的分组整理,样本数越多覆盖越广,标注决定了分数和误读率的计算方式,条件是英文合成语音实时输入。表前先说明比较对象都是同一套自建集的不同子集,指标方向在表后解释。
| 请求类型 | 样本构成 | 是否需搜索 | 是否含改口 | 标注与用途 |
|---|---|---|---|---|
| 正常请求 | 100 | 部分需搜索 | 否 | 期望工具参数,主结果 |
| 硬负例 | 22 | 不需搜索 | 否 | 搜索表达,测误触发 |
| 对抗样本 | 24 | 视改口而定 | 是 | 纠正换话题,测纠错 |
| 总计 | 146 | 混合 | 混合 | 全量标注,端到端实测 |
上表 100 条覆盖正常需求,硬负例和对抗共几十条,专门放大了易误触发和意图变化的比例,所以鲁棒性数字是在困难子集上的表现,不能直接当作日常分布的误触发率。全集约一个多小时音频、完整运行约 3 小时说明评测成本不低,复现时要预留联网和合成时间。限制是没有公开对照集,外人很难做同条件横向对比。论文还做了离线神经路由参考,显示用端侧大模型看更多转写时路由准确率更高,但那是离线实验且未计推理延迟,不能当作可部署的提升。
直接注入与校验回退各自贡献了什么
消融要回答延迟和准确率的改善主要来自哪一步。从级联基线开始逐步加预取、校验回退和直接注入,延迟越小越好,分数越高越好,浪费调用越少越好,缓存就绪率越高越好,同一设备同一数据集。下表对比只加直接注入与完整方法的平均延迟和分数变化,基线与注入后的分数并列可看出增益来源。
| 条件 | 平均延迟变化 | 基线分数 | 注入后分数 | 比较含义 |
|---|---|---|---|---|
| 直接注入 | 6.69 到 6.17 seconds | 44.8% | 63.0% | 均值降分数升 |
上表显示直接把预取结果放进提示词带来最大变化,平均延迟下降且分数明显上升,论文推测是给小模型补了任务上下文,类似小模型受益于提示信息的先前观察,但这只是假设不是因果证明。仅预取而沿用原选工具流程时中位略升、均值相当,说明并发本身没有明显惩罚,但选工具的等待还在。只在选完工具后查缓存的校验回退改善有限,因为必须等大模型选完才能查。完整方法再加校验回退后中位和均值最低、就绪率最高、浪费最少,但部分指标略逊于单用直接注入,总体是速度、复用和浪费之间的平衡。尚未评测的是更大模型下直接注入是否还有同样增益。
这些结论在什么边界之外不再成立
首先延迟结论依赖设备与网络,本地推理稳定而远程搜索波动大,投机只是把波动前移,若用户话很短、意图出现很晚或网络极差,重叠窗口就很小,改善会打折扣。其次准确率提升依赖所用的小量化模型,直接注入给上下文对小模型帮助明显,换更大模型或换任务后增益可能消失,论文自己也写的是假设。再次规则预测器只覆盖固定的粗分类信息需求和简单的从句切分,超出此范围的工具或更复杂的改写可能猜不中,只能靠兜底回到串行。
还有评测是英文合成语音,若用真实口音、噪声或中文,识别部分假设的质量会变,触发节奏也要重调。容易产生的误解是把离线大模型路由的高准确率当成在线可用,原文明确说那没有计延迟,且提前跑大模型会抢端侧资源。另一个误解是把浪费调用少当作零成本,对抗下仍有较多浪费,只是因只读而不改数据,费用和流量仍需考虑。
复现第一步要搭什么才能测出同样延迟
复现第一步是搭出可计时的端到端链路,而不是先调预测规则。需要准备流式识别、量化大模型、合成、缓存和搜索接口的完整通路,并在说话结束到首音频之间打点。论文没有公开代码模型数据,来源清单显示无可用作者资源,所以只能按描述重做。触发参数可先用最少 6 词、步长 5 词、停顿 300 毫秒,主题先用粗分类的占位实现。数据侧先合成少量单搜索和多意图请求,验证提前搜索能否在说话期间返回,再加硬负例和改口样本验证校验是否丢弃。
关键超参和信息条件要保留:触发阈值、从句切分规则、缓存匹配条件、提示词拼接位置、大模型是否保留自主工具调用。计时要区分中位、均值和高分位与标准差,因为投机的主要收益在长尾。联网部分要记录浪费调用数,否则只看延迟会低估代价,长期运行还要统计命中与费用。
什么时候值得尝试以及还缺哪项验证
当助手是级联结构、常用长延迟只读搜索、用户话术较长且意图出现较早、设备端侧推理资源紧张但允许提前联网时,这种方法值得尝试。它不改模块分工,只加轻量分支和缓存,最坏情况退回串行,工程风险相对小。不值得照搬的情形是工具以写操作为主、请求都很短、网络计费敏感或已有端到端流式工具调用。复现时先做最小链路计时,再补规则与校验。
还缺的验证包括真实用户语音而非合成语音、中文与噪声下的触发效果、不同大模型规模下的分数变化、以及长期运行的缓存命中与费用统计。只有补上这些,才能知道延迟更稳和分数更高是否超出本文的手机、模型、搜索接口和英文自建集,研究生在引用时应把这些边界一起说明。
📎 论文与评分元数据
排名:前50% | 文档类型:系统技术报告 | arXiv 原文
⚖️ 评分明细
评分属于系统判断,不是论文实验结果;八维数值与总分见页首,原始审计记录保留在后端。
评分规则:type-aware-v1
评分模型:muse-spark-1.3-contributor
评分请求协议:openai_responses
