PACE：阿里锚定播放边界，打断指代率从25%提至96.3%

PACE: A Playback-Aligned Context Engine for LLM-Based Full-Duplex Voice Dialogue

论文原文 ↗ 论文发布 2026-08-07 解读发布 2026-09-09 解读：AI前沿分享

在大语言模型支持的实时全双工语音交互中，用户体验最直观的飞跃是“可打断性”——用户无需等待助手将整段话讲完，随时插话即可打断并切换话题。然而，当工程师把全双工语音系统推向实际业务时，一种极其隐蔽却破坏力极强的系统性错误开始频繁出现：用户在听到助手罗列的第 2 项时插话询问“这个该怎么走？”，模型却基于自己内部已经生成完毕的第 4 项给出了条理清晰但完全答非所问的路线建议。

ArXiv URL：https://arxiv.org/abs/2608.07631v1

这种现象被阿里巴巴的研究团队正式定义为生成式上下文错位（Generative Context Mis-anchoring，简称 GCM）。它既不是语音识别（ASR）丢字，也不是大模型的幻觉，而是一个由端到端分布式异步流水线引发的一致性故障：服务器端大模型与语音合成（TTS）的生成速度远快于客户端扬声器的实际播放速度；当用户开口打断时，模型内部的对话状态已经“超前”跑出去了几句话，后续的用户指代因此被绑定到了用户根本没有听到的内容上。

针对这一交互硬伤，阿里团队提出了 PACE（Playback-Aligned Context Engine，播放对齐上下文引擎）。这是一个独立于具体模型厂商的中间件层，它把客户端真实的音频播放边界作为物理代理锚点，将模型侧可见的上下文强行回退并修正到用户发声瞬间“真正听到”的内容范围内。在团队构建的 108 个全双工指代基准评测集 GCM-Bench 上，传统的简单打断机制仅有 25.0% 的指代准确率，而引入 PACE 后直接拉升至 96.3%，在提升 71.3 个百分点的同时，完全保留了全双工语音原有的低延迟与流畅交互能力。

为什么说全双工打断是一个分布式一致性问题？

在传统的半双工（Push-to-Talk 或严格轮流发言）模式下，人机交互的状态机极其简单：用户讲完一句话，系统开始处理；模型生成文本，TTS 渲染成音频，音频播放完毕；在此期间麦克风静音或输入被忽略，直到播放结束才开启下一轮录音。在这种模式下，系统生成的内容天然等于用户接收到的内容，对话历史的时序单调递增，不会出现认知偏差。

一旦进入全双工交互，这种时序对称性被瞬间打破。为了保证交互的极致低延迟，现代语音模型或流式级联系统通常采用流式推流策略：大模型吐字速度往往超过每秒 10 到 20 个 Token，TTS 模块通常具备数倍于真实时间的合成速度。服务器早在半秒或一秒内就已在内存中生成并归档了整段长难句，而客户端的 Web Audio 缓冲区、本地音频播放队列、网络抖动缓冲才刚刚播到第一个短语。

这就产生了严峻的物理不对称：模型假设用户已经收到的上下文，远远超前于用户耳朵真正接收到的音频信号。

当用户听到感兴趣的内容立刻插话打断时，例如助手在介绍“我们提供北京、上海、广州、深圳四地的直飞航班”，当客户端刚播放完“上海”时，用户立刻开口问“飞那里的机票多少钱？”，但服务器端的状态早已完整记录了包含“深圳”的整段回复。大模型在处理随后的音频或文本时，会把弱代词“那里”绑定到上下文最后一个出现的实体上，于是模型非常自信地向用户报出了深圳的票价。

更致命的是，这种错位在传统体系下是不可自愈的。即便用户感到困惑并再次追问“不对，我说的是刚才那个”，模型依然会根据其内部超前的上下文继续误判，导致人机对话陷入恶性死循环。传统的解决方案往往只是发送一个取消信号，让客户端停止扬声器发声、让服务端终止当前 Token 生成。这种“仅取消播放”（Cancellation-only）的逻辑只能阻止多余声音继续传给用户，却根本没有去修复服务端早已经向前漂移的对话上下文历史。

即使像 OpenAI Realtime API 这类商业方案提供了项截断（Item Truncation）机制，允许删除服务端未播放的上下文内容，但它不仅深度绑定在特定的商业私有协议与内部会话抽象上，而且往往假定调用者自身已经知道如何准确映射客户端播放毫秒数到大模型的 Token 或状态，而在复杂的网络延迟、音频抖动和黑盒模型面前，这种映射往往并不成立。

PACE 的核心思想：分离“推测生成”与“物理对齐”

PACE 的核心设计哲学是将全双工对话中的两项职责解耦：生成可以超前推测，但对话状态的最终确立必须等待物理播放的确认反馈。

在架构层面，PACE 被设计为驻留在传输层（如 WebTransport / WebSocket）与模型推理服务之间的轻量级中间件。无论底层是基于 Qwen-Audio 这类直接处理语音信号的黑盒端到端模型，还是传统的 VAD-ASR-LLM-TTS 级联管线，PACE 都能以统一的状态机进行接管。

为了量化播放状态，PACE 在服务端和客户端之间建立了两个最核心的抽象契约：

服务端输出账本（OutputTurnLedger）：中间件对模型生成的每一次 Assistant 发言分配唯一的 audio_turn_id，并记录流式下发给客户端的所有音频分片及样本点累加值。
客户端播放确认（PlaybackAck）：客户端的音频渲染引擎（如浏览器的 Web Audio API）具备绝对可靠的本地硬件时钟。客户端在回传上行麦克风音频流的同时，在每一个上行数据包的头部嵌入当前正在渲染的 audio_turn_id 以及已渲染的采样点绝对偏移量 $A = \langle\texttt{audio_turn_id}, \texttt{played_samples}\rangle$。

通过这种“伴随传输”的机制，PACE 实现了极其关键的发声时刻锚定（Onset Anchoring）。以往的系统在检测到打断时，通常依据服务端检测到打断的时间点去倒推播放进度，这一过程夹杂了网络下行、上行往返时间（RTT）以及服务器端语音活动检测（VAD）的决策延迟，误差可高达数百毫秒。而在 PACE 中，服务端 VAD 一旦判定用户在某一时刻触发了真实打断，中间件只需要直接提取打断瞬间用户上传的那一帧音频包头中所携带的 played_samples，即可无视网络抖动，精准锁定用户张嘴的那一微秒，客户端扬声器究竟振动到了哪一个采样点。

双层边界投影与黑盒模型的音频再注入

在拿到物理播放采样点后，系统如何将这一低级物理量转换为大模型能理解的对话上下文？PACE 在这里定义了两个层次的边界：

物理播放边界（Physical Playback Boundary, $B^p$）：
\[B_{i}^{p} = \langle\texttt{audio\_turn\_id} = i, \texttt{played\_samples} = n\rangle\]
这个边界代表客观事实：在第 $i$ 轮回复中，采样点 $n$ 之前的内容已经从扬声器发出，而 $n$ 之后的内容属于用户绝不可能听到的“推测性废话”，必须在物理层面全部撤回。
语义提交边界（Semantic Commit Boundary, $B^s$）：

如果底层模型或系统能够提供精准的词级别/句级别时间戳（例如合作型级联架构），PACE 可以在物理边界 $B_i^p$ 的基础上向前寻找最后一个完整播放完毕的语义单元 $s_j$（对应结束点 $e_j$ 满足 $e_j + \epsilon \le n$），把未播放完整的半句话截断，确保模型看到的上下文是由完整的命题构成的。

然而在工业级实践中，许多语音大模型是纯黑盒的端到端音频模型，外部既无法获取流式文本与音频的毫秒级对齐，也无法直接操纵模型的内部 KV Cache 或注意力遮罩。面对这种极端受限的环境，PACE 展现出了非常精巧的系统工程设计——音频域重投影（Audio-only Projection）。

当打断发生时，PACE 的处理流水线按极其严密的时序推进：

阻断前向门控：立刻关闭新用户音频的转发门控，将打断后用户正在输入的音频暂存至缓冲队列，防止模型在旧状态未清理前吸收新输入。
状态撤销与下行清理：向模型发送取消信号终止后续生成，并向客户端发送撤销指令，丢弃客户端本地音频队列中超过 $B^p$ 的所有缓冲音频帧。
音频重注入（Re-injection）：由于黑盒模型没有暴露修改对话历史的接口，PACE 会从服务端的账本中精准切出从该轮开始到 $B^p$ 位置的已播放音频片段（通常为截断点前数秒的音频），在末尾拼接一个特殊的声音边界分隔符，作为先验上下文重新推入模型的对话流中。
释放用户输入：在模型吸收完这段经过真实物理对齐的已播放音频后，PACE 再开启门控，将打断发生后暂存的用户真正提问音频按序灌入模型。

对于外部黑盒大模型而言，它感知到的时序变成了一个完美的因果链：自己刚刚只说到了香蕉这一项（未播放的后续音频从历史中被抹除），紧接着听到了用户插话“介绍一下这个”，因此注意力机制被强制约束在用户听到的香蕉上，消解指代歧义水到渠成。

此外，PACE 还针对全双工系统中最危险的不可逆操作设立了防护门控。在支持外部工具调用（Tool Calls）的 Agent 场景中，模型常常一边生成语音“我正在为您退订该服务”，一边直接向业务后台触发 API。PACE 强制规定：任何具有不可逆副作用的工具调用，其前置命题必须越过语义提交边界 $B^s$ 并获得客户端播放确认后方可触发执行。这从根本上杜绝了因用户在最后一秒打断反悔、但后台工具早已提前提交的系统性风险。

GCM-Bench：专为测试打断指代错位建立的基准

为了全面验证 GCM 现象的存在性以及评估上下文修复的有效性，研究团队不仅分析了真实场景，还构建了业内首个针对全双工打断指代错位的标准化评测集 GCM-Bench。

现有的全双工语音评测基准（如 Full-Duplex-Bench）主要关注系统是否能迅速让出话语权（Turn-Obedience Rate）、打断响应的延迟以及泛化的语义相关性。然而研究团队指出，这些传统指标掩盖了指代错位。例如在全双工基准测试中，用户打断说“换个话题吧，我们聊聊电影”，这属于话题切换（Topic Switch），无论模型上下文是否超前，它都能很好地响应；又或者当用户打断时，模型即便基于未听到的第 4 项给出了错误回答，传统的 LLM Judge 在评估相关性时，由于只比对文本逻辑的连贯度，依然会给出满分。

GCM-Bench 专门设计了严密的阶乘级对比矩阵：

12 种序列化对话场景：包括 4 种概念列表（如不同编程语言的特性）、4 种步骤列表（如西红柿炒鸡蛋的烹饪步骤）以及 4 种准备清单（如出国旅游所需证件材料）。这些任务的共性在于每一项内容边界清晰，外部评测者可以客观判定物理播放截断瞬间扬声器停留在哪一个实体。
3 种打断延迟（Interruption Delay）：分别在助手开始发声后的 12 秒、16 秒和 20 秒发起打断，模拟不同对话深度下的生成超前程度。
3 种指代操作类型：包含“详述当前项”（如“这个具体怎么弄？”）、“对比操作”（如“这个和刚才那个有什么区别？”）以及“属性确认”。

通过 $12 \times 3 \times 3$ 的全排列，GCM-Bench 构成了 108 个具有确定因果关系的测试案例。评测不采用文本仿真的形式，而是让端到端自动化测试程序扮演用户，通过真实的浏览器端 Web Audio 播放音频，产生真实的客户端 PlaybackAck，并在精确的时间点向系统注入合成的打断音频，全链路走完实际的网络流式传输。

评测的核心指标为指代锚定准确率（Referent Anchoring Accuracy, RAA）：系统在打断后的回应中，所绑定的实体对象必须与打断时刻客户端正在播放的实体完全吻合，答错或向用户反问“你指的是哪一个”均计为失败。

数据见真章：从 25.0% 到 96.3% 的跃迁

在基于阿里开源的 Qwen-Audio 实时语音服务环境下，研究人员将 PACE 驱动的原型系统与工业界通用的基线系统（仅执行音频停止与生成取消，不修复历史上下文）进行了严密的成对评估（Paired Evaluation）。

实验结果呈现出了极其悬殊的对比：

在 108 个 GCM-Bench 案例中，基线系统与 PACE 的让出话语权比率（TOR）均达到了 100%，意味着两者都能敏锐地感知到打断并停止发声。但在最为关键的指代锚定准确率（RAA）上，基线系统仅取得了 25.0% 的准确率（27/108），而搭载了 PACE 的系统直接达到了 96.3%（104/108），绝对提升幅度高达 71.3 个百分点。麦克尼马尔检验（McNemar’s test）显示该差异在统计学上极具显著性（$p < 10^{-15}$）。

从具体的交互个案可以直观感受到这 71.3 个百分点背后的体验鸿沟：在基线系统中，当助手播放到介绍“香蕉”的营养价值时，模型实际上已经生成到了后面的“苹果”与“橙子”，用户打断提问“详细说说这个”，基线系统要么产生幻觉大谈橙子的维生素含量，要么陷入茫然，反问用户“您指的是哪种水果？”；而在 PACE 系统下，模型接收到的重投影上下文被精确截断至香蕉播放完毕的那一刻，模型立刻顺畅地接话：“香蕉富含丰富的钾元素，非常适合在运动后补充体力……”，两者的智能感差异立竿见影。

实验还进一步剖析了打断延迟对系统的影响。在 12 秒、16 秒和 20 秒三个打断时间点上：

基线系统的准确率持续低迷，分别为 33.3%、19.4% 和 22.2%；
PACE 则分别维持在 91.7%、100.0% 和 97.2% 的高位。

这一数据也印证了一个现象：在没有播放边界对齐的情况下，生成越长，服务端与客户端的“认知缝隙”累积越大，系统靠巧合猜对指代目标的几率也就越低；而 PACE 依赖物理样本点级别的强同步机制，其表现几乎不受对话持续时间的影响，始终能将上下文稳定吸附在用户的感知边界上。

兼容性与延迟代价：给全双工系统的实用解法

在系统设计中，一致性机制往往伴随着延迟代价。为了检验 PACE 是否会牺牲语音交互最在意的“秒回”体验，阿里团队将该系统挂载到 Full-Duplex-Bench v1 官方提供的 200 个真实用户打断测试集上进行了兼容性验证。

这 200 个样本大多数属于常规的话题打断与切换。测试结果显示：

回复质量未受任何负面影响：在 LLM Judge 的 0–5 分打断响应质量评测中，基线系统的平均得分为 4.975 分，而引入 PACE 后平均得分微升至 4.995 分，证明剔除未听到的超前内容并不会破坏常规打断的语义连贯性。
打断响应延迟代价可控：在发生打断的场景下，由于 PACE 需要执行下行音频撤销、物理切片、注入分隔符以及重新推入先验音频，其端到端打断回复延迟相比基线仅增加了约 200 到 300 毫秒。对于人机语音交互而言，这个轻微的开销完全落在可接受的自然对话停顿范围内。
正常对话零开销：对于未发生打断的普通轮次，或者用户在助手静默期发起的正常提问，请求完全遵循原始的流式传输通道直通大模型，PACE 机制处于旁路监听状态，不会引入哪怕 1 毫秒的额外处理延迟。

消融实验还针对重投影时的上下文回看窗口（Lookback Window）长度进行了比较。结果显示，回看 5 秒至 10 秒的已播放音频，能够为模型提供最充足的声学与语义线索来完成代词消解；同时，在已播音频与新输入之间插入清晰的控制分隔符，对于引导自回归模型区分“我说过的”与“用户刚问的”至关重要。

全双工语音交互走向工业级落地的一面镜子

过去两年，语音大模型的研究热点大量聚焦在端到端统一建模、情感合成、端点检测（VAD）以及音色克隆上。学术界与工业界往往默认：只要模型的推理速度足够快、网络延时足够低，全双工对话就能自然而然地丝滑运转。

但 PACE 的研究成果揭示了一个被长期忽视的系统工程本质：在异步流式传输构成的物理世界里，速度的提升不仅不能自动解决一致性问题，反而会加剧系统内部状态与用户认知状态的偏离。模型生成得越快，模型以为用户听到的与用户真正听到的差距就越大。

PACE 并没有试图去重构大模型内部的神经元结构，也没有强行要求所有语音模型必须开源自己的 KV Cache 状态，而是立足于传输层与模型层之间的中间件位置，以客户端播放硬件的时钟作为不可动摇的“真理源”，设计了一套优雅的物理回滚与音频重投影协议。

这套方案为正在走向落地的大模型车载语音助手、智能音箱、穿戴设备以及实时客服 Agent 提供了一个极具实操价值的解题思路：不要让大模型凭空猜测用户的耳朵听到哪里，用明确的物理 ACK 建立边界，才是让全双工语音真正摆脱“鸡同鸭讲”的必由之路。