1452 lines
65 KiB
HTML
1452 lines
65 KiB
HTML
<!doctype html>
|
||
<html lang="zh-CN">
|
||
<head>
|
||
<meta charset="UTF-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<meta name="theme-color" content="#f7f6f2" />
|
||
<meta
|
||
name="description"
|
||
content="比较三段式、两段式与原生语音系统,解释160毫秒时间片、实际交互时延与全双工训练,建立可复核的语音系统评测方案。"
|
||
/>
|
||
<meta property="og:title" content="语音双工系统的架构、时延与评测" />
|
||
<meta
|
||
property="og:description"
|
||
content="从160毫秒时间片到任务成功率,理解实时语音系统的设计与证据。"
|
||
/>
|
||
<meta property="og:type" content="article" />
|
||
<link rel="canonical" href="https://voice-duplex.k1412.top/" />
|
||
<link rel="icon" href="favicon.svg" type="image/svg+xml" />
|
||
<link rel="stylesheet" href="styles.css" />
|
||
<title>语音双工系统的架构、时延与评测 · K1412 Research</title>
|
||
<script type="module" src="app.js"></script>
|
||
</head>
|
||
<body>
|
||
<a class="skip-link" href="#main">跳到正文</a>
|
||
<header class="site-header">
|
||
<a class="brand" href="https://blog.k1412.top"
|
||
><span class="brand-mark" aria-hidden="true">k.</span
|
||
><span>K1412 <b>RESEARCH</b></span></a
|
||
>
|
||
<nav aria-label="顶部导航">
|
||
<a href="#latency">时延实验台</a><a href="#evaluation">评测方案</a
|
||
><a href="#sources">来源</a
|
||
><button
|
||
id="theme-toggle"
|
||
class="icon-button"
|
||
type="button"
|
||
aria-label="切换深浅主题"
|
||
>
|
||
◐
|
||
</button>
|
||
</nav>
|
||
</header>
|
||
<div class="page-layout">
|
||
<aside class="contents" aria-label="文章目录">
|
||
<span class="eyebrow">VOICE SYSTEMS / 01</span>
|
||
<nav>
|
||
<a href="#overview">01 架构与信息流</a>
|
||
<a href="#metrics">02 主要指标</a>
|
||
<a href="#latency">03 160 ms 与实时性</a>
|
||
<a href="#implementations">04 代表实现</a>
|
||
<a href="#evidence">05 同场评测数据</a>
|
||
<a href="#higgs">06 Higgs 的比较方法</a>
|
||
<a href="#training">07 双工架构与训练</a>
|
||
<a href="#evaluation">08 判断与验收方案</a>
|
||
<a href="#sources">09 参考来源</a>
|
||
</nav>
|
||
<div class="contents-note">
|
||
<span class="status-dot"></span>资料核对至<br /><strong
|
||
>2026.11.09</strong
|
||
><br /><span>论文与官方报告<br />交互示例单独标注</span>
|
||
</div>
|
||
</aside>
|
||
<main id="main">
|
||
<section class="hero" aria-labelledby="page-title">
|
||
<div class="eyebrow">SYSTEM ARCHITECTURE · REALTIME INTERACTION</div>
|
||
<h1 id="page-title">语音双工系统的<br />架构、时延与评测</h1>
|
||
<p class="hero-deck">
|
||
从一句话怎样被听见,到一次任务怎样被完成。<br />沿着信息流与时间轴,判断一个语音系统好在哪里。
|
||
</p>
|
||
<div class="hero-meta">
|
||
<span>技术研究</span><span>2026 年 11 月 9 日</span
|
||
><a
|
||
href="https://www.boson.ai/blog/higgs-realtime-duplex"
|
||
target="_blank"
|
||
rel="noopener noreferrer"
|
||
>起点 · Higgs Realtime Duplex ↗</a
|
||
>
|
||
</div>
|
||
<div
|
||
class="hero-visual"
|
||
aria-label="持续输入、输出与异步任务共享时间轴的示意图"
|
||
>
|
||
<div class="hero-axis">
|
||
<span>听见</span><span>理解</span><span>回应</span
|
||
><span>继续听</span>
|
||
</div>
|
||
<div class="signal-row">
|
||
<span>用户</span>
|
||
<div class="signal input-signal" aria-hidden="true"></div>
|
||
<span class="signal-label">持续输入</span>
|
||
</div>
|
||
<div class="signal-row">
|
||
<span>系统</span>
|
||
<div class="signal output-signal" aria-hidden="true"></div>
|
||
<span class="signal-label">按需输出</span>
|
||
</div>
|
||
<div class="signal-row task-row">
|
||
<span>任务</span>
|
||
<div class="task-signal"><i>异步执行</i><b>结果返回</b></div>
|
||
<span class="signal-label">独立推进</span>
|
||
</div>
|
||
<div class="visual-caption">
|
||
概念示意 · 三条轨道在同一时间轴上推进
|
||
</div>
|
||
</div>
|
||
<p class="lead">
|
||
架构决定信息如何流动,以及有哪些优化空间。系统的价值需要同时用<strong>任务正确率、交互行为、用户端时延和完整成本</strong>来证明。
|
||
</p>
|
||
<p>
|
||
一次“帮我订周五的票,嗯……改成周六”的请求,同时考验语音理解、句中停顿、参数修正、工具执行与回应时机。只看首次发声速度,会遗漏这条链路中的大部分问题。
|
||
</p>
|
||
</section>
|
||
|
||
<section id="overview" class="article-section">
|
||
<div class="section-number">01 / ARCHITECTURE</div>
|
||
<h2>段数、原生语音与双工分别描述什么</h2>
|
||
<p>
|
||
这里按<strong>推理时的信息流</strong>区分三段式、两段式和原生
|
||
S2S。两段式在业界存在不同用法,本页采用“语音理解模型输出回答文本,再接语音合成”的工作定义。带
|
||
Thinker、Talker 和共享隐藏状态的模型单列为混合设计。
|
||
</p>
|
||
<p class="terminology">
|
||
ASR 或 STT 表示语音识别,LLM 表示语言模型,TTS 表示语音合成。S2S
|
||
表示从语音输入到语音输出,codec 是声音的编解码器。
|
||
</p>
|
||
<div class="interactive-figure architecture-figure">
|
||
<div class="figure-heading">
|
||
<div>
|
||
<span class="figure-label">信息流比较</span>
|
||
<h3>语音在哪一步变成了文字</h3>
|
||
</div>
|
||
<span class="evidence-tag inference">工程分析</span>
|
||
</div>
|
||
<div class="segmented" role="group" aria-label="选择架构">
|
||
<button
|
||
type="button"
|
||
data-architecture="cascade"
|
||
aria-pressed="true"
|
||
>
|
||
三段式</button
|
||
><button
|
||
type="button"
|
||
data-architecture="two"
|
||
aria-pressed="false"
|
||
>
|
||
两段式</button
|
||
><button
|
||
type="button"
|
||
data-architecture="native"
|
||
aria-pressed="false"
|
||
>
|
||
原生 S2S
|
||
</button>
|
||
</div>
|
||
<div
|
||
id="architecture-flow"
|
||
class="architecture-flow"
|
||
aria-live="polite"
|
||
></div>
|
||
<div id="architecture-detail" class="architecture-detail"></div>
|
||
</div>
|
||
<div class="three-concepts">
|
||
<div>
|
||
<h3>流式处理</h3>
|
||
<p>输入或输出尚未结束,就可以开始处理、传输和播放。</p>
|
||
</div>
|
||
<div>
|
||
<h3>全双工交互</h3>
|
||
<p>
|
||
系统说话期间,持续利用新输入,判断继续说、让出话轮或修正任务。
|
||
</p>
|
||
</div>
|
||
<div>
|
||
<h3>原生语音建模</h3>
|
||
<p>
|
||
语音特征直接进入模型,或由模型生成语音表示。具体系统仍需验证双工行为。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
DuplexCascade 把流式 ASR、文本 LLM 和流式 TTS
|
||
用微轮次连接,提供了级联全双工的研究实例。段数与双工能力因此需要分别记录。语音编码器、codec
|
||
和波形解码器也可以存在于端到端模型中,直接清点模块数容易得到含混分类。<a
|
||
class="citation"
|
||
href="#source-cascade"
|
||
>[2]</a
|
||
>
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<caption>
|
||
三类信息流的工程取舍。以下为机制推断,具体性能由实现与训练决定。
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th>维度</th>
|
||
<th>三段式</th>
|
||
<th>两段式</th>
|
||
<th>原生 S2S</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>输入声学线索</th>
|
||
<td>仅传 ASR 文本时,语气、重叠和非语言声音难以传递</td>
|
||
<td>可保留在音频特征中,取决于模型与训练</td>
|
||
<td>可直接联合建模,需要相应数据支持</td>
|
||
</tr>
|
||
<tr>
|
||
<th>首音关键路径</th>
|
||
<td>残余识别、话轮判断、LLM 首段、TTS 首块</td>
|
||
<td>语音理解生成、话轮判断、TTS 首块</td>
|
||
<td>听说决策、音频表示生成、波形解码</td>
|
||
</tr>
|
||
<tr>
|
||
<th>知识与工具</th>
|
||
<td>易接入成熟文本模型和工具生态</td>
|
||
<td>依赖语音适配后模型的能力保留</td>
|
||
<td>依赖语音训练与工具训练,常配合后台模型</td>
|
||
</tr>
|
||
<tr>
|
||
<th>语音输出</th>
|
||
<td>韵律和表现力主要由 TTS 决定</td>
|
||
<td>文本接口与 TTS 约束仍然存在</td>
|
||
<td>可把内容与声学表现联合生成</td>
|
||
</tr>
|
||
<tr>
|
||
<th>调试与控制</th>
|
||
<td>文本接口明确,分段替换、审计和定位较直接</td>
|
||
<td>输出文本清楚,输入理解过程更紧耦合</td>
|
||
<td>需要音频对齐、事件和播放状态等观测</td>
|
||
</tr>
|
||
<tr>
|
||
<th>持续双工</th>
|
||
<td>需流式调度与话轮策略</td>
|
||
<td>需输入持续更新与调度策略</td>
|
||
<td>需因果听说训练与可持续的实时推理</td>
|
||
</tr>
|
||
<tr>
|
||
<th>总成本</th>
|
||
<td colspan="3">
|
||
统一计算监听、前后台模型、编解码、工具、网络和所需并发。段数本身不足以给出成本排名。
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
|
||
<section id="metrics" class="article-section">
|
||
<div class="section-number">02 / METRICS</div>
|
||
<h2>主要指标围绕完整交互组织</h2>
|
||
<p>
|
||
主指标负责回答“系统有没有把事情做好”,诊断指标负责定位问题发生在哪个环节。每项统计都需要固定起止事件、分母、超时规则和系统边界。
|
||
</p>
|
||
<p class="terminology">
|
||
P50 为中位数,P95 表示 95% 样本不超过的值。Pass@1
|
||
是一次尝试的成功率。 WER、CER 分别衡量词和字的识别错误,MOS
|
||
是主观质量评分的均值。
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>主要问题</th>
|
||
<th>建议主指标</th>
|
||
<th>测量与诊断</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>多久开始回应</th>
|
||
<td>用户端首音时延 P50 / P95</td>
|
||
<td>
|
||
从标注的用户话轮结束,到客户端实际播出的首段非静音语音。另报端点判断耗时。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>多久得到有用结果</th>
|
||
<td>有效答案时延、任务完成时延</td>
|
||
<td>
|
||
“我查一下”与首个正确、相关信息的实际播放分别计时。工具最终状态与语音告知分别验收。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>该停时能否停</th>
|
||
<td>真打断检出率、停止说话时延 P95</td>
|
||
<td>
|
||
从有效打断开始到扬声器停止,包含取消传播、在途音频和播放缓冲。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>该继续时能否继续</th>
|
||
<td>误打断率、附和与旁人对话处理正确率</td>
|
||
<td>
|
||
分别测试“嗯、对”、对旁人说话、背景广播。按情境判断期望行为。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>说话时有没有听懂</th>
|
||
<td>双讲条件下的信息保留与修正成功率</td>
|
||
<td>
|
||
模型输出期间插入新的编号、约束或改口,检查后续回答和工具参数。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>任务有没有完成</th>
|
||
<td>Pass@1、正确工具链与最终状态</td>
|
||
<td>
|
||
包含无响应、超时、错参数、过期结果和取消失败。WER、CER
|
||
与实体准确率用于归因。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>任务是否高效完成</th>
|
||
<td>有效完成前提下的轮次、冗余步骤、无效工具调用与返工</td>
|
||
<td>
|
||
在相同任务与质量门槛下比较,保留必要澄清的收益,并报告全部尝试的成本。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>声音是否可用</th>
|
||
<td>真人盲评偏好、可懂度、关键信息读对率</td>
|
||
<td>
|
||
内容正确性、韵律、发音与音质分开评分。自动 MOS 可作补充。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>能否稳定长时间工作</th>
|
||
<td>按会话长度分层的成功率、断流与积压</td>
|
||
<td>
|
||
测试长会话、回声、远场、丢包、上下文压缩和后台任务交错。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>能否承担规模与成本</th>
|
||
<td>满足质量及时延门槛的并发、每有效任务成本</td>
|
||
<td>
|
||
同时报告每分钟整机成本、监听占比、前后台调用和 GPU 占用。
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="reading-note">
|
||
Full-Duplex-Bench v1.5
|
||
把重叠场景分成打断、附和、旁人对话和背景语音,并测量行为及停止、重入时间。这组情境适合构成交互测试的基础。<a
|
||
class="citation"
|
||
href="#source-fdb15"
|
||
>[10]</a
|
||
>
|
||
</p>
|
||
</section>
|
||
|
||
<section id="latency" class="article-section">
|
||
<div class="section-number">03 / TIME</div>
|
||
<h2>160 ms 是怎样的一段时间</h2>
|
||
<p>
|
||
Higgs 把连续媒体和工作流按 160 ms
|
||
时间片组织。模型读入当前片段,再生成下一片段的输出,思考和工具调用可以跨多个片段持续。这种设计定义了更新节奏。用户端时延还涉及采集、计算、决策、网络和播放。<a
|
||
class="citation"
|
||
href="#source-higgs"
|
||
>[1]</a
|
||
>
|
||
</p>
|
||
<div class="time-vocabulary">
|
||
<div>
|
||
<span>网络包</span>
|
||
<p>运输的单位,常比模型时间片更小。</p>
|
||
</div>
|
||
<div>
|
||
<span>音频帧</span>
|
||
<p>编码和解码的时间单位。</p>
|
||
</div>
|
||
<div>
|
||
<span>模型时间片 Δ</span>
|
||
<p>一次更新覆盖的媒体时长。</p>
|
||
</div>
|
||
<div>
|
||
<span>单步耗时 C</span>
|
||
<p>完成计算实际经过的墙钟时间。</p>
|
||
</div>
|
||
</div>
|
||
<h3>每块都要在 160 ms 内算完吗</h3>
|
||
<p>
|
||
对单会话、串行关键阶段,要持续按 160 ms
|
||
推进,就需要及时产出每个下一块。长期平均计算耗时低于 160 ms
|
||
是基本条件,还需要给抖动留余量,关注尾延迟、超期比例和缓冲。多阶段流水线可以把吞吐摊开计算,关键路径上的固定延迟仍然存在。
|
||
</p>
|
||
<p>
|
||
用一个简化的单工作者模型说明。当 Δ = 160 ms、C = 80
|
||
ms,计算有余量。当 C = 220 ms,每处理一个新块,等待队列便增加约 60
|
||
ms。Higgs 博客没有披露单步耗时的 P50 / P95
|
||
或超期比例,无法据分块长度确认其实际计算分布。
|
||
</p>
|
||
<div class="interactive-figure latency-lab">
|
||
<div class="figure-heading">
|
||
<div>
|
||
<span class="figure-label">交互实验台</span>
|
||
<h3>改变处理节奏,观察积压</h3>
|
||
</div>
|
||
<span class="evidence-tag simulated">说明性模型</span>
|
||
</div>
|
||
<p class="figure-intro">
|
||
单会话、单工作者、固定耗时、无流水线。数值由下方参数计算。
|
||
</p>
|
||
<div class="lab-controls">
|
||
<label for="chunk-slider"
|
||
>媒体时间片 Δ
|
||
<output id="chunk-value" for="chunk-slider">160 ms</output
|
||
><input
|
||
id="chunk-slider"
|
||
type="range"
|
||
min="40"
|
||
max="1000"
|
||
step="20"
|
||
value="160" /></label
|
||
><label for="compute-slider"
|
||
>单步计算耗时 C
|
||
<output id="compute-value" for="compute-slider">80 ms</output
|
||
><input
|
||
id="compute-slider"
|
||
type="range"
|
||
min="20"
|
||
max="1200"
|
||
step="20"
|
||
value="80"
|
||
/></label>
|
||
</div>
|
||
<div class="lab-presets" role="group" aria-label="参数示例">
|
||
<button type="button" data-preset="160,80">留有余量</button
|
||
><button type="button" data-preset="160,160">刚好赶上</button
|
||
><button type="button" data-preset="160,220">持续积压</button>
|
||
</div>
|
||
<div class="lab-stats" aria-live="polite">
|
||
<div>
|
||
<span>处理 / 媒体时长</span
|
||
><strong id="rtf-value">0.50×</strong>
|
||
</div>
|
||
<div>
|
||
<span>第 8 块等待计算</span
|
||
><strong id="backlog-value">0 ms</strong>
|
||
</div>
|
||
<div>
|
||
<span>每块新增长期积压</span
|
||
><strong id="growth-value">0 ms</strong>
|
||
</div>
|
||
</div>
|
||
<div
|
||
id="queue-chart"
|
||
class="queue-chart"
|
||
role="img"
|
||
aria-label="八个输入块的到达、排队和计算时间"
|
||
></div>
|
||
<div class="chart-legend">
|
||
<span><i class="legend-input"></i>输入块就绪</span
|
||
><span><i class="legend-wait"></i>等待计算</span
|
||
><span><i class="legend-compute"></i>实际计算</span>
|
||
</div>
|
||
<p
|
||
id="queue-explanation"
|
||
class="selected-detail"
|
||
aria-live="polite"
|
||
></p>
|
||
<p class="formula">
|
||
B<sub>k+1</sub> = max(0, B<sub>k</sub> + C − Δ)
|
||
</p>
|
||
</div>
|
||
<h3>分块越短,交互会怎样变化</h3>
|
||
<p>
|
||
事件发生在一个时间片内部时,模型需要等到该事件进入可用输入。事件均匀落在固定边界之间、并且必须等整块时,残余等待平均约
|
||
Δ/2,最大接近 Δ。实际系统还受编码器前视和接收策略影响。
|
||
</p>
|
||
<p>
|
||
缩短 Δ
|
||
可以更频繁地更新感知,也会增加调用、调度和控制开销,并改变每步可用的信息量。MiniCPM-o
|
||
4.5 的作者比较了 1.0 s、0.2 s、0.1 s,在其模型和训练设置下选择 1.0 s
|
||
作为折中。时间片大小要和训练方式、语义稳定性一起评估。<a
|
||
class="citation"
|
||
href="#source-minicpm"
|
||
>[6]</a
|
||
>
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<caption>
|
||
公开资料中的时间粒度与时延。各行测量对象不同,分别保留原口径。
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th>实现</th>
|
||
<th>时间粒度</th>
|
||
<th>公开时延及其含义</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>Higgs Realtime Duplex</th>
|
||
<td>160 ms 统一时间片</td>
|
||
<td>
|
||
博客披露分块设计,端到端首音分布与逐块计算分布待补充。[1]
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>TML Interaction Small</th>
|
||
<td>200 ms 微轮次</td>
|
||
<td>
|
||
作者在 FDB v1 报告轮替时延 0.40 s,属于特定评测设置。[7]
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Moshi</th>
|
||
<td>Mimi 音频帧 80 ms</td>
|
||
<td>
|
||
80 ms 帧与额外声学延迟构成 160 ms 理论路径,作者报告实践约
|
||
200 ms。[4]
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>MiniCPM-o 4.5</th>
|
||
<td>论文选用 1.0 s 时间片</td>
|
||
<td>
|
||
论文的分块消融说明其设计取舍,用户端响应需结合部署测量。[6]
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Qwen3-Omni-30B-A3B</th>
|
||
<td>每帧输入表征约覆盖 80 ms 音频</td>
|
||
<td>
|
||
作者估算音频首包在并发 1 / 4 / 6 时为 234 / 728 / 1172
|
||
ms。该值属于服务端理论首包口径。[5]
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="source-line">
|
||
时间数据来源
|
||
<a href="https://www.boson.ai/blog/higgs-realtime-duplex">Higgs</a
|
||
>、<a href="https://thinkingmachines.ai/blog/interaction-models/"
|
||
>TML</a
|
||
>、<a href="https://arxiv.org/html/2410.00037v2">Moshi</a>、<a
|
||
href="https://arxiv.org/html/2604.27393v1"
|
||
>MiniCPM-o</a
|
||
>、<a href="https://arxiv.org/html/2509.17765v1">Qwen3-Omni</a>。
|
||
</p>
|
||
<h3>用户听到回答的时间取决于关键路径</h3>
|
||
<div class="latency-path" aria-label="首音时延的关键路径">
|
||
<span>边界后残余采集与上行</span><b>→</b><span>话轮或语义决策</span
|
||
><b>→</b><span>关键路径计算</span><b>→</b
|
||
><span>下行与实际播放</span>
|
||
</div>
|
||
<p>
|
||
流式系统会把部分识别、理解与生成提前到用户仍在说话时。核算时只计事件发生后尚未完成的部分,并保留阶段重叠。首次开口、给出有效内容、完成工具动作和停止播放,分别使用自己的起止事件。
|
||
</p>
|
||
<p>
|
||
声音已经生成后,还可能在网络或播放器中排队。Google 的 Live API
|
||
指南明确要求收到打断事件时清空待播音频。客户端缓冲因此会影响用户感知的停止时延。<a
|
||
class="citation"
|
||
href="#source-google"
|
||
>[14]</a
|
||
>
|
||
</p>
|
||
</section>
|
||
|
||
<section id="implementations" class="article-section">
|
||
<div class="section-number">04 / IMPLEMENTATIONS</div>
|
||
<h2>用代表实现建立架构地图</h2>
|
||
<p>
|
||
下面以公开结构或接口描述定位代表路线。闭源模型的内部模块、实际训练数据和服务调度仍有未知项。版本明确的论文适合解释机制,当前系统选型需要固定具体模型
|
||
ID 再测。
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>代表实现</th>
|
||
<th>公开结构</th>
|
||
<th>比较时应核对的边界</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>LiveKit 级联管线</th>
|
||
<td>独立 STT、文本 LLM、TTS,应用控制话轮与打断</td>
|
||
<td>
|
||
流式程度、提前生成、端点策略和播放取消共同决定体验。<a
|
||
href="https://docs.livekit.io/agents/models/pipelines/"
|
||
>官方文档 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>DuplexCascade</th>
|
||
<td>ASR–LLM–TTS,以约 0.6 s 微轮次和控制 token 组织双向流</td>
|
||
<td>
|
||
级联双工的研究样例,文本瓶颈与交互策略分别测量。<a
|
||
href="https://arxiv.org/html/2603.09180v1"
|
||
>论文 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Ultravox 0.7 + TTS</th>
|
||
<td>音频特征经投影进入 LLM,核心输出流式文本</td>
|
||
<td>
|
||
本页按两段式归类。外接
|
||
TTS、话轮控制和具体适配配置须纳入整机边界。<a
|
||
href="https://github.com/fixie-ai/ultravox"
|
||
>官方仓库 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Moshi / PersonaPlex</th>
|
||
<td>用户与系统多路语音流,结合文字和声学 token</td>
|
||
<td>
|
||
同时听说、语音内容能力、角色控制和上下文窗口分别考察。<a
|
||
href="https://arxiv.org/html/2410.00037v2"
|
||
>Moshi ↗</a
|
||
>
|
||
<a href="https://github.com/NVIDIA/personaplex"
|
||
>PersonaPlex ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Qwen3-Omni</th>
|
||
<td>
|
||
Thinker–Talker 分工,支持多模态特征、流式文本与语音生成
|
||
</td>
|
||
<td>
|
||
作为模块化原生音频路线比较。持续输入能否影响正在进行的输出,须在具体接口验证。<a
|
||
href="https://arxiv.org/html/2509.17765v1"
|
||
>论文 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>MiniCPM-o 4.5 / Freeze-Omni</th>
|
||
<td>
|
||
语言骨干连接语音输入和专用语音输出模块,并训练时间对齐或状态控制
|
||
</td>
|
||
<td>
|
||
属于语义骨干与语音头紧耦合的路线,各模式的双工行为与能力保留需单独测量。<a
|
||
href="https://arxiv.org/html/2604.27393v1"
|
||
>MiniCPM-o ↗</a
|
||
>
|
||
<a href="https://arxiv.org/html/2411.00774v1"
|
||
>Freeze-Omni ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>GPT-Realtime / GPT-Live / Gemini Live</th>
|
||
<td>
|
||
公开提供原生语音交互接口,各系列的轮次、工具和持续听说能力有差别
|
||
</td>
|
||
<td>
|
||
OpenAI 文档把 GPT-Live
|
||
的持续听说与后台代理协作单独说明。能力按模型和 API
|
||
版本记录。<a
|
||
href="https://developers.openai.com/api/docs/guides/audio"
|
||
>OpenAI ↗</a
|
||
>
|
||
<a
|
||
href="https://ai.google.dev/gemini-api/docs/live-api/capabilities"
|
||
>Google ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Higgs / TML Interaction</th>
|
||
<td>统一时间片更新输入输出,并行推进交互和后台任务</td>
|
||
<td>
|
||
比较时记录前台独立能力、后台模型配置、委派比例与完整成本。<a
|
||
href="https://www.boson.ai/blog/higgs-realtime-duplex"
|
||
>Higgs ↗</a
|
||
>
|
||
<a
|
||
href="https://thinkingmachines.ai/blog/interaction-models/"
|
||
>TML ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</section>
|
||
|
||
<section id="evidence" class="article-section">
|
||
<div class="section-number">05 / EVIDENCE</div>
|
||
<h2>同场数据怎样揭示不同取舍</h2>
|
||
<p>
|
||
Full-Duplex-Bench v3 的 2026 年 4 月 v1 研究,用 100 条真人录音、12
|
||
名说话者,在统一 LiveKit 框架与本地 mock
|
||
工具下比较多种配置。下面保留其中四项,展示三类信息流的系统表现。这组结果属于该版本和样本的评测快照。<a
|
||
class="citation"
|
||
href="#source-fdb3"
|
||
>[11]</a
|
||
>
|
||
</p>
|
||
<div class="interactive-figure benchmark-figure">
|
||
<div class="figure-heading">
|
||
<div>
|
||
<span class="figure-label">FDB v3 · 2026-04 · 作者报告</span>
|
||
<h3>首次开口与关键回答的距离</h3>
|
||
</div>
|
||
<span class="evidence-tag reported">来源报告值</span>
|
||
</div>
|
||
<div
|
||
id="benchmark-chart"
|
||
class="benchmark-chart"
|
||
role="img"
|
||
aria-label="四种系统首次开口与关键回答起始时延的对照"
|
||
></div>
|
||
<div class="chart-legend">
|
||
<span><i class="legend-input"></i>首次开口</span
|
||
><span><i class="legend-compute"></i>关键回答开始</span>
|
||
</div>
|
||
<div class="benchmark-missing">
|
||
<strong>GPT-Live-1</strong>
|
||
<span>原始论文尚无该配置的两项时延,补充数据见下方。</span>
|
||
</div>
|
||
<div class="table-wrap">
|
||
<table class="benchmark-table">
|
||
<thead>
|
||
<tr>
|
||
<th>配置</th>
|
||
<th>作者报告的 Pass@1</th>
|
||
<th>首次开口</th>
|
||
<th>关键回答起始延迟</th>
|
||
<th>应答率</th>
|
||
<th>抢话率</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>Whisper → GPT-4o → TTS</th>
|
||
<td>45.0%</td>
|
||
<td>8.78 s</td>
|
||
<td>10.12 s</td>
|
||
<td>100.0%</td>
|
||
<td>33.0%</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Ultravox 0.7</th>
|
||
<td>41.0%</td>
|
||
<td>3.88 s</td>
|
||
<td>8.40 s</td>
|
||
<td>96.0%</td>
|
||
<td>47.9%</td>
|
||
</tr>
|
||
<tr>
|
||
<th>GPT-Realtime 1.5</th>
|
||
<td>60.0%</td>
|
||
<td>6.36 s</td>
|
||
<td>6.89 s</td>
|
||
<td>96.0%</td>
|
||
<td>13.5%</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Gemini Live 3.1</th>
|
||
<td>54.0%</td>
|
||
<td>3.95 s</td>
|
||
<td>4.25 s</td>
|
||
<td>78.0%</td>
|
||
<td>19.2%</td>
|
||
</tr>
|
||
<tr class="missing-data-row">
|
||
<th>GPT-Live-1 · 补充配置</th>
|
||
<td>见下方独立报告</td>
|
||
<td>—</td>
|
||
<td>—</td>
|
||
<td>—</td>
|
||
<td>—</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="figure-intro">
|
||
两列时延从用户说完计时,取作者均值。关键回答的终点为关键事实或确认句开始,正确性与无应答样本的均值分母披露有限。抢话沿用负话轮间隔口径。<a
|
||
href="https://arxiv.org/pdf/2604.04847v1"
|
||
>论文表 2、表 6 与附录 A.3 ↗</a
|
||
>
|
||
</p>
|
||
</div>
|
||
<p>
|
||
Pass@1
|
||
沿用作者报告,核心要求工具选择与参数正确,论文另报回答质量和应答率,完整通过判据披露有限。较早开口、关键回答起始和正确完成任务需要分别评价。论文将
|
||
Ultravox 广义归入
|
||
S2S,本页依据其公开核心的音频到文本结构作两段式定位,TTS
|
||
适配的披露有限。系统级差异需要结合模型能力、话轮和部署配置解释。
|
||
</p>
|
||
<h3 id="gpt-live-data">GPT-Live-1 的补充数据</h3>
|
||
<p>
|
||
GPT-Live-1
|
||
已有官方评测和第三方时延数据。下表按来源、后台配置与统计口径分开列出。FDB-v1
|
||
轮替、FDB-v3 工具任务、受控录音与电话链路各自描述不同的工作条件。
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>来源与配置</th>
|
||
<th>公开数据</th>
|
||
<th>测量口径</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>OpenAI API 发布材料<br />GPT-Live-1 + Terra(low)</th>
|
||
<td>
|
||
FDB-v3 工具调用 Pass@1 <strong>87.0%</strong><br />回答质量
|
||
<strong>90.0%</strong>
|
||
</td>
|
||
<td>
|
||
官方另次评测,后台配置见发布正文。与四月论文的历史配置分别呈现。<a
|
||
href="https://openai.com/index/introducing-gpt-live-1-in-the-api/"
|
||
>发布说明 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>OpenAI 发布图<br />GPT-Live-1</th>
|
||
<td>FDB-v1 轮替时延 <strong>0.798 s</strong></td>
|
||
<td>
|
||
从用户结束话轮到系统开始回答。该项使用 FDB-v1 协议。<a
|
||
href="https://images.ctfassets.net/kftzwdyauwt9/6hFWb3bOFoepzg3aUx2zei/2a18b8d1372ee6c2fa937efa4daccb5f/kix.vqxcgk6pb8ef.png?fm=webp&q=90&w=3840"
|
||
>原始发布图 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>InteractionBench<br />GPT-Live-1 + gpt-5.5</th>
|
||
<td>轮替回复起始中位数 <strong>1.210 s</strong></td>
|
||
<td>
|
||
30
|
||
道轮替题,统计按论文规则未提前开口的回复。客户端重建时间轴,计入代理网络与缓冲。<a
|
||
href="https://arxiv.org/html/2611.02430v1"
|
||
>表 3、表 5 与附录 H ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Cekura 电话评测<br />GPT-Live-1 + GPT-6 Sol(low)</th>
|
||
<td>
|
||
延迟 P50 / P90 / P95<br /><strong
|
||
>2.27 / 2.72 / 2.83 s</strong
|
||
>
|
||
</td>
|
||
<td>
|
||
70 场景 × 3,共 210
|
||
通电话。每通先求平均回复延迟,再对这些电话均值取分位数。marin
|
||
声音,服务端轮替检测。<a
|
||
href="https://benchmarks.cekura.ai/speech-to-speech/real-calls/gpt-live"
|
||
>结果 ↗</a
|
||
>
|
||
<a
|
||
href="https://benchmarks.cekura.ai/speech-to-speech/real-calls/methodology"
|
||
>统计方法 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>OpenAI 模型文档<br />GPT-Live-1 前端语音层</th>
|
||
<td><strong>$0.05 / 分钟</strong></td>
|
||
<td>
|
||
按秒计费。后台模型与工具另计,整机成本需合并核算。检索日为
|
||
2026-11-09。<a
|
||
href="https://developers.openai.com/api/docs/models/gpt-live-1"
|
||
>模型与计费 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="reading-note">
|
||
本次所查资料尚缺 GPT-Live-1
|
||
在原图同一统计口径下的首音均值与关键回答起始均值,因此原表保留空缺。
|
||
0.798、1.210 和 2.27 秒各有独立条件,不能合并成一个统一时延排名。
|
||
</p>
|
||
</section>
|
||
|
||
<section id="higgs" class="article-section">
|
||
<div class="section-number">06 / HIGGS</div>
|
||
<h2>Higgs 的论证如何组织</h2>
|
||
<p>
|
||
Higgs
|
||
以自然交互、智能和成本组织设计。其前台模型按时间片持续接收信息,自己思考、调工具,并按需委派后台。博客用交互、问答与任务等多组成绩呈现取舍,FDB
|
||
v1.5 得分 75.5、τ-Voice 69.8,同表仍有更高配置。<a
|
||
class="citation"
|
||
href="#source-higgs"
|
||
>[1]</a
|
||
>
|
||
</p>
|
||
<div class="argument-chain">
|
||
<div>
|
||
<span>需求</span><strong>自然交互 · 办成任务 · 可承担成本</strong>
|
||
</div>
|
||
<div>
|
||
<span>机制</span><strong>时间对齐 · 异步执行 · 按需委派</strong>
|
||
</div>
|
||
<div>
|
||
<span>证据</span><strong>具体场景 · 固定维度 · 多组基准</strong>
|
||
</div>
|
||
</div>
|
||
<p>
|
||
这种比较方法可以转化为评测纪律。每个系统都交代任务范围、完整模型配置、时间预算和成本边界。Demo
|
||
解释机制,测试集衡量覆盖,配对消融说明改善来自哪项设计。
|
||
</p>
|
||
<p>
|
||
前台和后台的分工尤其影响解读。TML
|
||
的表格注明,部分推理与工具成绩启用了后台代理。比较“模型能力”与“整机能力”时,应分别报告前台独立配置和完整系统配置。MoE
|
||
总参数量、音频 token 速率、后台调用和实际价格也需要分别记录。<a
|
||
class="citation"
|
||
href="#source-tml"
|
||
>[7]</a
|
||
>
|
||
</p>
|
||
</section>
|
||
|
||
<section id="training" class="article-section">
|
||
<div class="section-number">07 / TRAINING</div>
|
||
<h2>全双工如何进入架构与训练</h2>
|
||
<p>
|
||
全双工涉及三项设计。输入在输出期间怎样持续进入,听与说怎样按时间对齐,模型怎样学习何时继续、停下或行动。下列组织方式可以组合使用。
|
||
</p>
|
||
<div class="design-routes">
|
||
<div>
|
||
<span>多流联合建模</span>
|
||
<h3>分别表示双方语音</h3>
|
||
<p>
|
||
Moshi
|
||
用用户流、系统流和时间对齐文本联合建模,保留重叠。PersonaPlex
|
||
沿用其架构与权重,加入角色和声音控制。[4][8]
|
||
</p>
|
||
</div>
|
||
<div>
|
||
<span>时间对齐序列</span>
|
||
<h3>持续读写微轮次</h3>
|
||
<p>
|
||
Higgs、TML
|
||
将输入输出按时间切分并交错处理。外部交互连续进行,内部计算遵循因果顺序。[1][7]
|
||
</p>
|
||
</div>
|
||
<div>
|
||
<span>语义骨干与语音头</span>
|
||
<h3>分担内容和声学生成</h3>
|
||
<p>
|
||
MiniCPM-o 用骨干的文本和隐藏状态驱动轻量语音模块。Freeze-Omni
|
||
接入语音模块与逐块状态预测。[6][9]
|
||
</p>
|
||
</div>
|
||
<div>
|
||
<span>级联微轮次</span>
|
||
<h3>同步独立模块</h3>
|
||
<p>
|
||
DuplexCascade 用微轮次和控制 token 协调 ASR、LLM 与
|
||
TTS,训练等待、回应和附和等行为。[2]
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<h3>基于语言模型继续预训练,具体改了什么</h3>
|
||
<p>
|
||
文本模型已学会知识、推理和语言生成。语音系统在此基础上接入声音表示,使语音特征能进入骨干,并让生成端输出语音
|
||
token
|
||
或驱动专用语音头。训练时加入文本与声音对应关系、语音连续性,以及带时间的交互轨迹。
|
||
</p>
|
||
<p>
|
||
骨干可以继续做统一序列预测,音频编码器和波形解码器按各自目标训练。不同项目会选择冻结已有组件、先训新增模块,再逐步联合训练,或始终保留冻结的语言骨干。
|
||
</p>
|
||
<ol class="training-steps">
|
||
<li>
|
||
<span>01</span>
|
||
<div>
|
||
<h3>建立声音表示与模态对齐</h3>
|
||
<p>
|
||
利用语音、转写与配对数据,把音频特征映射到语言表示,训练语音生成模块。编码帧率与压缩影响计算预算和声学信息。
|
||
</p>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<span>02</span>
|
||
<div>
|
||
<h3>混合继续预训练</h3>
|
||
<p>
|
||
混合文本、音频与可选视频数据,学习跨模态预测并保留语言能力。知识问答和文本能力需要在语音训练前后配对评估。
|
||
</p>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<span>03</span>
|
||
<div>
|
||
<h3>按时间训练双工行为</h3>
|
||
<p>
|
||
把双声道、静默、停顿、附和、重叠和改口保留在时间轴上。训练中限制未来信息访问,让输出只依赖当时已到达的输入。
|
||
</p>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<span>04</span>
|
||
<div>
|
||
<h3>交互微调与强化学习</h3>
|
||
<p>
|
||
监督微调(SFT)示范合适动作,强化学习(RL)
|
||
可依据正确答案、指令遵循、行动效果或交互行为优化。具体采用哪些奖励,需要逐模型查证。
|
||
</p>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<span>05</span>
|
||
<div>
|
||
<h3>蒸馏与仿真迭代</h3>
|
||
<p>
|
||
部分系统把专长教师的能力蒸馏到交互模型,并从仿真失败中合成训练数据。模拟器的说话时机、工具返回和噪声会影响学到的行为。
|
||
</p>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<caption>
|
||
代表项目公开的训练路线
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th>项目</th>
|
||
<th>初始化与训练</th>
|
||
<th>理解重点</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>Moshi</th>
|
||
<td>
|
||
用文本 Helium 初始化时间
|
||
Transformer,混合音频与文本预训练,加入双流对话及合成语音指令数据。
|
||
</td>
|
||
<td>
|
||
文本能力迁移、音频生成与双流交互分阶段建立。<a
|
||
href="https://arxiv.org/html/2410.00037v2"
|
||
>训练章节 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>MiniCPM-o 4.5</th>
|
||
<td>
|
||
先冻结已有组件训练新增语音模块,再解冻联合预训练,之后做监督微调(SFT)
|
||
与组相对策略优化(GRPO)。
|
||
</td>
|
||
<td>
|
||
模态对齐、联合表征、行为与推理逐步训练。<a
|
||
href="https://arxiv.org/html/2604.27393v1"
|
||
>训练章节 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Freeze-Omni</th>
|
||
<td>
|
||
保留冻结语言骨干,训练语音输入输出模块,并用逐块状态预测学习双工控制。
|
||
</td>
|
||
<td>
|
||
冻结骨干提供另一种适配选择,整体效果仍须测量。<a
|
||
href="https://arxiv.org/html/2411.00774v1"
|
||
>模型与训练 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Higgs</th>
|
||
<td>
|
||
作者报告从文本模型继续训练约 2T 多模态
|
||
token,以强化学习(RL)
|
||
训练专长教师后蒸馏到学生,并用仿真失败数据迭代。
|
||
</td>
|
||
<td>
|
||
继续预训练、行为后训练与仿真数据机制分别核验。<a
|
||
href="https://www.boson.ai/blog/higgs-realtime-duplex"
|
||
>作者说明 ↗</a
|
||
>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="reading-note">
|
||
语音转写和音质测试覆盖了模态能力的一部分。持续双工还需要验证新输入能否改变当前生成与后续行动,尤其是模型已经开始回答、工具仍在执行时的参数修正。
|
||
</p>
|
||
</section>
|
||
|
||
<section id="evaluation" class="article-section">
|
||
<div class="section-number">08 / EVALUATION</div>
|
||
<h2>怎样证明自己的系统更好</h2>
|
||
<p>
|
||
先确定目标场景及成功条件,再比较质量、交互、时延和成本的共同边界。可以把通过任务正确、交互规则和时间门槛的对话记为“有效完成”,并同时报告各原始指标,保留失败原因。
|
||
</p>
|
||
<div class="evaluation-equation">
|
||
<span>满足交互与时限的有效完成率</span
|
||
><strong>满足全部预设门槛的对话数 ÷ 全部测试对话数</strong
|
||
><span>每个有效任务成本</span
|
||
><strong>整轮测试全部系统成本 ÷ 有效完成任务数</strong>
|
||
</div>
|
||
<p>
|
||
这是可选的项目级验收口径,需要预先确定门槛与超时规则。有效完成数为零时,成本指标记录为不可用并保留完整支出。
|
||
</p>
|
||
<h3>从评测标准推导可视化</h3>
|
||
<p>
|
||
先写清楚怎样判定系统好,再确定需要采集哪些事件,最后选择图形。交互时机、任务完成与效率、时间、成本构成评价主线。模块活跃与工具异步轨迹用来解释这些结果。
|
||
</p>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<caption>
|
||
评测目标、可判定证据与视图的映射。属于项目方案,可按业务裁剪。
|
||
</caption>
|
||
<thead>
|
||
<tr>
|
||
<th>评价维度</th>
|
||
<th>判据与分母</th>
|
||
<th>所需事件或状态</th>
|
||
<th>对应视图</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>交互时机</th>
|
||
<td>
|
||
在标注窗口内执行合适行为的事件数,除以全部应决策事件。过早、过晚、遗漏分别统计。
|
||
</td>
|
||
<td>语义意图、说话对象、期望时间窗、实际听说与停播时间。</td>
|
||
<td>
|
||
期望窗口与实际动作叠加的对话时间线,打断与误打断权衡。
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>任务完成</th>
|
||
<td>
|
||
满足用户约束和最终状态的任务数,除以全部任务。超时和无响应计入。
|
||
</td>
|
||
<td>
|
||
任务规范、约束修订、工具参数、结果、最终环境状态与语音告知。
|
||
</td>
|
||
<td>任务状态轨迹、约束检查表、配置间配对成功与失败对照。</td>
|
||
</tr>
|
||
<tr>
|
||
<th>完成效率</th>
|
||
<td>
|
||
在同一质量门槛下比较总轮次、冗余澄清、重复动作、无效调用和返工,同时呈现成功率。
|
||
</td>
|
||
<td>
|
||
对话轮次、动作因果、工具调用目的、撤销与重试、必要步骤基线。
|
||
</td>
|
||
<td>任务路径与返工支路,成功任务分层与全量尝试开销。</td>
|
||
</tr>
|
||
<tr>
|
||
<th>时间</th>
|
||
<td>
|
||
首音、有效答案、任务完成、停播的
|
||
P50/P95,附超时覆盖率与会话分层。
|
||
</td>
|
||
<td>
|
||
采集、网络、排队、模型、工具、解码、播放的对齐时间戳。
|
||
</td>
|
||
<td>关键路径、阶段重叠、延迟分布与尾部样本复盘。</td>
|
||
</tr>
|
||
<tr>
|
||
<th>成本</th>
|
||
<td>
|
||
完整系统支出、每分钟成本、每个有效完成任务成本,以及满足门槛的并发。
|
||
</td>
|
||
<td>
|
||
监听时长、前后台用量、工具费用、编解码资源与账单边界。
|
||
</td>
|
||
<td>质量—时延—成本配置曲线,成本构成与并发负载曲线。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p>
|
||
结果层回答是否达到门槛,诊断层解释因果链,展示层帮助读者理解过程。单次回放、两配置配对与样本集聚合使用相同事件定义。图中的“计算请求在途”按观测事件标记,内部思考状态需要对应的公开事件才能呈现。
|
||
</p>
|
||
<h3>先把测试条件固定</h3>
|
||
<ul class="checklist">
|
||
<li>
|
||
固定模型
|
||
ID、服务版本、系统提示、工具和后台模型,记录推理预算与委派次数。
|
||
</li>
|
||
<li>
|
||
使用相同输入和设备条件,按实际时间流入音频,在系统实际播放时触发重叠事件。
|
||
</li>
|
||
<li>
|
||
同时记录客户端采集、发送、服务计算、工具、返回与实际播放,标明时钟对齐误差。
|
||
</li>
|
||
<li>
|
||
无响应和超时保留在成功率分母中,时延分布同时标注完成覆盖率。
|
||
</li>
|
||
<li>
|
||
按对话配对比较,多次重复并按会话聚类计算置信区间,避免把一个长对话的多个片段当作独立样本。
|
||
</li>
|
||
<li>
|
||
在相同成本或质量门槛下比较配置,另做前台独立与整机两套结果。
|
||
</li>
|
||
</ul>
|
||
<h3>最小情境集覆盖八类问题</h3>
|
||
<div class="scenario-list">
|
||
<details open>
|
||
<summary><span>01</span>正常轮替与句中停顿</summary>
|
||
<p>
|
||
测试不同长度的自然停顿,检查抢话、等待和端点判断。用户最终意图保持一致,避免换题造成混淆。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>02</span>真打断与参数改口</summary>
|
||
<p>
|
||
系统说话时更新日期、目的地或数量,核对停说、旧任务取消、后续工具参数与最终状态。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>03</span>附和与延续</summary>
|
||
<p>
|
||
插入“嗯、对、你继续”,观察是否误停、重复已经说过的内容或丢失上下文。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>04</span>旁人对话与背景语音</summary>
|
||
<p>
|
||
控制说话对象与远近声源,检查应答对象判断,按场景标注期望继续、暂停或安静。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>05</span>双讲时的信息保留</summary>
|
||
<p>
|
||
系统输出期间提供一个新编号或限制条件,再测试能否正确使用,区分收到音频与理解信息。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>06</span>异步工具与任务变化</summary>
|
||
<p>
|
||
模拟工具延迟、部分结果、失败和过期结果,在等待时加入新问题、修改或撤销请求。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>07</span>中文实体与复杂任务</summary>
|
||
<p>
|
||
覆盖中文人名、地址、数字、专业词、口音和中英混说,同时保留简单与多步工具任务。
|
||
</p>
|
||
</details>
|
||
<details>
|
||
<summary><span>08</span>长会话与真实音频链路</summary>
|
||
<p>
|
||
覆盖长时间监听、上下文压缩、回声、丢包和播放积压。按设备、网络与会话时长分层报告。
|
||
</p>
|
||
</details>
|
||
</div>
|
||
<p>
|
||
可先用少量案例核验采集与评分,再扩充独立测试集。样本量应由要检测的差异与置信度确定。开发案例、公开基准和最终保留测试集分别维护。
|
||
</p>
|
||
<h3>基准各自承担一个判断任务</h3>
|
||
<div class="table-wrap">
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>证据面</th>
|
||
<th>主要回答的问题</th>
|
||
<th>需要配合的证据</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<th>Full-Duplex-Bench v1 / v1.5</th>
|
||
<td>轮替、打断、附和和干扰时怎样行动</td>
|
||
<td>真实设备链路与业务正确性。[10]</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Full-Duplex-Bench v3</th>
|
||
<td>真人不流利语音下的工具调用、行为和时延</td>
|
||
<td>最新配置、真实工具异常和更广场景。[11]</td>
|
||
</tr>
|
||
<tr>
|
||
<th>Audio MultiChallenge</th>
|
||
<td>多轮约束保持、记忆、自洽与语音改口</td>
|
||
<td>
|
||
其固定上下文协议只评分最终回答,持续闭环交互另测。[12]
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<th>τ-Voice</th>
|
||
<td>在可核验环境中是否完成任务,语音与文本能力差多少</td>
|
||
<td>真人与目标语言、设备的实测。[13]</td>
|
||
</tr>
|
||
<tr>
|
||
<th>项目保留集与真人盲评</th>
|
||
<td>目标业务、中文和实际交互体验</td>
|
||
<td>与公开基准分别展示,保留录音、状态与评分依据。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<h3>用消融解释改进来源</h3>
|
||
<p>
|
||
一次只改变一项设计,比较提前处理开关、双工话轮控制、后台委派、播放器缓冲等设置。对时间片大小的实验,需要使用模型支持且训练条件相容的配置。若骨干、数据和服务都不同,证据支持的是整机配置之间的差异。
|
||
</p>
|
||
<p>
|
||
发布结果时给出四组图。任务成功率与有效答案时延的配置曲线,真打断检出与误打断的权衡,质量及时延门槛下的成本和并发,典型成功及失败对话的因果时间线。每个更优结论都应附带适用场景与代价。
|
||
</p>
|
||
<div class="claim-template">
|
||
<span class="figure-label">可复核的结论表达</span>
|
||
<p>
|
||
在预先固定的场景、版本、预算和测试集上,配置 A
|
||
在达到任务质量门槛的同时,改善了有效答案时延或交互行为。给出配对差异、置信区间、整机成本,以及退化场景。
|
||
</p>
|
||
</div>
|
||
</section>
|
||
|
||
<section id="sources" class="article-section sources-section">
|
||
<div class="section-number">09 / REFERENCES</div>
|
||
<h2>来源与证据边界</h2>
|
||
<p>
|
||
资料核对日期为 2026 年 11 月 9
|
||
日。性能数字来自注明版本的论文和官方报告。页面中的队列实验与概念图用于解释机制,尚待执行的项目评测按方案呈现。原始图表均由本页代码重绘,未复制第三方媒体。
|
||
</p>
|
||
<ol class="source-list">
|
||
<li id="source-higgs">
|
||
<a href="https://www.boson.ai/blog/higgs-realtime-duplex"
|
||
>Boson AI · Higgs Realtime Duplex</a
|
||
><span>2026-11-05。时间片、模型设计、训练与作者比较表。</span>
|
||
</li>
|
||
<li id="source-cascade">
|
||
<a href="https://arxiv.org/html/2603.09180v1">DuplexCascade</a
|
||
><span>2026-03,v1。级联流式微轮次架构。</span>
|
||
</li>
|
||
<li id="source-ultravox">
|
||
<a href="https://github.com/fixie-ai/ultravox">Fixie · Ultravox</a
|
||
><span
|
||
>官方仓库,检索日读取。音频输入、流式文本输出及开源版本。</span
|
||
>
|
||
</li>
|
||
<li id="source-moshi">
|
||
<a href="https://arxiv.org/html/2410.00037v2">Moshi</a
|
||
><span>2024-10,v2。多流、音频帧、理论时延与训练过程。</span>
|
||
</li>
|
||
<li id="source-qwen">
|
||
<a href="https://arxiv.org/html/2509.17765v1"
|
||
>Qwen3-Omni Technical Report</a
|
||
><span>2025-09,v1。Thinker–Talker 结构与并发首包估算。</span>
|
||
</li>
|
||
<li id="source-minicpm">
|
||
<a href="https://arxiv.org/html/2604.27393v1">MiniCPM-o 4.5</a
|
||
><span
|
||
>2026-04,v1。Omni-Flow、分块消融、模型结构与分阶段训练。</span
|
||
>
|
||
</li>
|
||
<li id="source-tml">
|
||
<a href="https://thinkingmachines.ai/blog/interaction-models/"
|
||
>Thinking Machines Lab · Interaction Models</a
|
||
><span>检索日读取。200 ms 微轮次、前后台分工与评测配置。</span>
|
||
</li>
|
||
<li id="source-personaplex">
|
||
<a href="https://github.com/NVIDIA/personaplex"
|
||
>NVIDIA · PersonaPlex</a
|
||
><span>官方仓库,检索日读取。基于 Moshi 的角色与声音控制。</span>
|
||
</li>
|
||
<li id="source-freeze">
|
||
<a href="https://arxiv.org/html/2411.00774v1">Freeze-Omni</a
|
||
><span>2024-11,v1。冻结骨干、语音模块与逐块状态预测。</span>
|
||
</li>
|
||
<li id="source-fdb15">
|
||
<a href="https://arxiv.org/html/2507.23159v1"
|
||
>Full-Duplex-Bench v1.5</a
|
||
><span>2025-07,v1。四类重叠情境与行为、时延测量。</span>
|
||
</li>
|
||
<li id="source-fdb3">
|
||
<a href="https://arxiv.org/html/2604.04847v1"
|
||
>Full-Duplex-Bench v3</a
|
||
><span
|
||
>2026-04,v1。真人语音、工具任务、表 2 与表 6 的报告值。</span
|
||
>
|
||
</li>
|
||
<li id="source-audiomc">
|
||
<a href="https://labs.scale.com/leaderboard/audiomc-audio"
|
||
>Scale · Audio MultiChallenge</a
|
||
><span>检索日读取。固定上下文、最终回答与 APR 评价协议。</span>
|
||
</li>
|
||
<li id="source-tau">
|
||
<a href="https://arxiv.org/html/2603.13686v1">τ-Voice</a
|
||
><span>2026-03,v1。语音任务、环境状态与文本能力比较。</span>
|
||
</li>
|
||
<li id="source-google">
|
||
<a
|
||
href="https://ai.google.dev/gemini-api/docs/live-api/best-practices"
|
||
>Google · Live API Best Practices</a
|
||
><span>检索日读取。网络发送块与客户端打断播放处理。</span>
|
||
</li>
|
||
<li id="source-openai">
|
||
<a href="https://developers.openai.com/api/docs/guides/audio"
|
||
>OpenAI · Audio and Voice</a
|
||
><span>检索日读取。实时语音工作流与 GPT-Live 公开能力。</span>
|
||
</li>
|
||
<li id="source-livekit">
|
||
<a href="https://docs.livekit.io/agents/models/pipelines/"
|
||
>LiveKit · Pipeline Types</a
|
||
><span>检索日读取。级联、轮次式与持续双工管线的接口说明。</span>
|
||
</li>
|
||
<li id="source-live-launch">
|
||
<a
|
||
href="https://openai.com/index/introducing-gpt-live-1-in-the-api/"
|
||
>OpenAI · GPT-Live-1 API 发布材料</a
|
||
><span
|
||
>2026-09-10。FDB-v3 后台配置与发布图中的工具、回答质量和 FDB-v1
|
||
轮替指标。图表数值经视觉核对。</span
|
||
>
|
||
</li>
|
||
<li id="source-interactionbench">
|
||
<a href="https://arxiv.org/html/2611.02430v1">InteractionBench</a
|
||
><span
|
||
>2026-11-02,v1。表 3、表 5 与附录 H,包含具体 API
|
||
配置、回复起始中位数与时间轴重建条件。</span
|
||
>
|
||
</li>
|
||
<li id="source-cekura">
|
||
<a
|
||
href="https://benchmarks.cekura.ai/speech-to-speech/real-calls/gpt-live"
|
||
>Cekura · GPT-Live-1 电话评测</a
|
||
><span
|
||
>检索日读取。210
|
||
通电话及电话均值的时延分位数,统计定义见其方法页。</span
|
||
>
|
||
</li>
|
||
<li id="source-live-model">
|
||
<a href="https://developers.openai.com/api/docs/models/gpt-live-1"
|
||
>OpenAI · GPT-Live-1 模型文档</a
|
||
><span>检索日读取。前端语音会话计费与后台独立核算边界。</span>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
<footer class="article-footer">
|
||
<span>K1412 RESEARCH · VOICE SYSTEMS</span>
|
||
<div>
|
||
<a href="https://blog.k1412.top">研究目录 ↗</a
|
||
><a href="https://git.k1412.top/wuyang/voice-duplex">源代码 ↗</a
|
||
><a href="#main">回到顶部 ↑</a>
|
||
</div>
|
||
<small id="release-marker">Release voice-duplex-20261109-v1</small>
|
||
</footer>
|
||
</main>
|
||
</div>
|
||
</body>
|
||
</html>
|