端侧实时语音同传小模型实战教程

一、教程目标：做出“边说边译、延迟可控”的端侧同传

最近端侧同传小模型受到行业关注：相关团队完成数千万元融资，并宣称其端侧同传小模型已经实现商业化落地。这类产品的共同点是：不依赖云端算力，在手机、耳机、会议终端等设备上完成“听—识—译—播”的全过程。本教程以这一技术方向为主线，把产品层面的能力拆解为一套可复现的工程流程。

读完并完成全部步骤后，你应当能够：

1. 明确端侧实时语音同传的核心指标（延迟、质量、体积、功耗），并为自己的语种对和场景设定可量化的目标；
2. 构建一条“语音流式识别 + 实时翻译 + 增量输出”的端到端处理链路；
3. 把精度较高但体积较大的教师模型，蒸馏、量化成能在移动端流畅运行的小模型；
4. 在客户端完成音频采集、模型加载、解码调度与结果展示的集成；
5. 用标准化测试集验证效果，并针对延迟高、结果反复跳变等典型问题进行排查和优化。

二、适用场景与目标读者

适合的业务场景：

• 跨语言沟通：涉外接待、旅游出行、跨境会议、国际展会等需要即时翻译的场合；
• 音视频实时字幕：直播、网络课程、视频会议中生成双语字幕；
• 离线翻译：飞机、地铁、境外无网络环境下，仍可使用基础翻译能力；
• 隐私敏感场景：医疗问诊、法律咨询等原始音频不便上传云端，需要本地处理。

适合的读者：

• 客户端与端侧开发工程师：负责在移动端完成模型集成与音频链路搭建；
• 算法工程师：负责模型训练、蒸馏与量化压缩；
• 技术负责人：需要评估端侧同传方案的可行性、成本与上线风险。

阅读本文只需了解语音识别、机器翻译和移动端开发的基础知识，具体框架用法以各自官方文档为准。

三、原理铺垫：端侧同传要解决的核心矛盾

传统翻译建立在“完整输入、完整输出”之上：等一句话说完，再把整句送入模型翻译。同传则要求边说边译，必须在信息不完整时提前给出译文。再加上端侧设备的算力、内存和电量都有限，整个方案要同时平衡四对矛盾：

1. 延迟与质量：等得越久，上下文越完整，译文越准确；输出越早，延迟越低，但早期译文可能不准确。
2. 准确与稳定：为了追求准确不断修正前面的内容，用户看到的文字就会反复跳变，阅读体验很差。
3. 算力与体积：高精度模型动辄数百 MB 甚至数 GB，而移动端需要把模型和运行时内存控制在可接受的范围内。
4. 功耗与时长：长时间实时推理会让设备发热、耗电，必须让平均算力占用远低于设备的实时处理能力。

因此，端侧同传小模型本质上是一个“联合优化”问题：模型结构、推理调度和交互策略三者要配合设计，任何一环失衡都会直接影响体验。

四、前置准备：环境、数据与权限

4.1 硬件与开发环境

用途	建议配置	说明
模型训练与蒸馏	配备独立显卡的训练服务器或云端算力实例	先用离线大模型做教师，再训练学生模型
量化与导出	可复用训练环境，支持通用模型格式转换	导出为端侧推理框架可加载的格式
端侧开发与测试	一台主流配置的手机，外加低、中、高档各一台	低端机决定性能下限，不能只在高配设备上验证
客户端工程	移动端开发工具链与调试环境	用于音频采集、模型加载与界面联调

模型量化的目标是控制体积和内存，并不要求终端具备训练能力。训练、压缩在云端完成，终端只负责推理。

4.2 数据准备

同传模型通常需要两类数据，规模量级可根据语种对灵活调整：

• 平行语料：源语言文本与目标语言文本的句对，常见来源包括公开的多语平行语料、字幕语料、会议记录以及自有业务数据。建议先用单语语料做预训练，再用平行语料做训练，这样可以充分利用容易获取的单语资源；
• 语音—文本对齐数据：每条数据包含音频、对应转写文本和时间戳，时间戳用于训练流式识别与音频对齐。公开的语音数据集可以覆盖基础场景，会议、客服等垂直领域往往还需要补充自有数据。

数据清洗规则：

• 统一格式：音频统一采样率为 16 kHz、单声道、16 bit PCM，避免不同来源数据混用；
• 过滤异常样本：剔除过短（不足 0.5 秒）、过长（超过 30 秒）、转写与音频明显不符、译文乱码或几乎完全复制的样本；
• 控制长度比例：统计源句与目标句的长度比，剔除明显不对齐的句对；
• 敏感信息处理：涉及个人身份信息的文本先做脱敏或替换，再进入训练流程。

4.3 评测集与基线

• 准备三类测试集：通用测试集用于横向对比；领域内测试集（如医疗、金融术语）用于检验专项效果；真实场景录音用于验证噪声、远场等复杂条件下的表现；
• 建立基线：选用的教师模型或离线大模型在测试集上的结果，是学生模型的质量上限参照；
• 评测指标：
  • 识别环节用词错误率（WER），中文可用字错误率（CER）；
  • 翻译环节用 BLEU 等自动指标；
  • 延迟指标见下一节。

4.4 端侧运行约束与设备权限

• 明确运行约束：模型体积、推理时的峰值内存、目标设备的芯片型号与内存大小，都会直接影响后续的压缩策略；
• 权限声明：需要麦克风权限；如果提供语音播报，还需在相应系统平台上正确配置后台音频能力；
• 云端接口（可选）：如果需要端云协同，或仅面向云端链路验证，可评估使用百度智能云等云平台提供的语音识别、机器翻译、语音合成等通用能力作为对照基线；
• 合规准备：若会上传音频或文本，需要完成隐私政策说明和用户授权流程。

五、关键指标定义：先定目标，再动手

不少端侧模型项目失败于“先训练、后找场景”。建议在动手前，先用一张表把目标固定下来。

指标	含义	目标示例（需结合设备实测调整）
首字延迟	说话开始到屏幕上出现第一段译文的时间	1 秒以内
平均滞后	译文覆盖范围相对说话进度的平均落后时长	2～3 秒
最终结果延迟	说话结束到输出定稿译文的时间	1 秒以内
译文质量	定稿译文相对参考译文的 BLEU 分数	接近教师模型得分的 90% 以上
识别质量	词错误率相对教师模型的上升幅度	控制在 10% 以内
模型体积	端侧安装包中模型文件的大小	视语种对和模型结构而定
运行时内存	推理期间的峰值内存占用	不超过设备可用内存的三分之一
实时率	处理 1 秒音频所需的推理时间	目标机型上低于 0.5

其中“平均滞后”是衡量同传体验最直观的指标，可参考业界常用的定义：

对输出中每个词 w：
    滞后(w) = 输出 w 的时刻 − 说话人说出 w 的时刻
平均滞后 = 所有词滞后值的平均

设定目标时要注意三点：

1. 先测硬件上限：在目标机型上跑一遍教师模型，记录实时率和内存峰值，据此判断是否需要蒸馏和量化；
2. 按机型分档：高、中、低三档设备可以使用不同规格的模型，或开启不同的优化选项；
3. 延迟目标以真实设备为准：因为模拟器与真机的性能差异很大，所有延迟指标都必须在真机上复测。

六、实施步骤：从数据到端侧的完整链路

整体流程如下，后续每一步都建立在前一步的产出之上：

① 任务定义与指标设定
        ↓
② 流式数据准备与对齐
        ↓
③ 流式学生模型结构设计
        ↓
④ 教师模型蒸馏训练
        ↓
⑤ 端侧量化与模型导出
        ↓
⑥ 双通路解码与推理调度
        ↓
⑦ 端侧音频链路与增量输出集成
        ↓
⑧ 效果验证、压力测试与上线监控

步骤一：明确任务边界与指标目标

做什么：确定输入语种与输出语种、输入形式（单语单向还是多语互译）、使用领域（通用、会议、客服等）以及设备档位，并按上一节完成指标设定。

为什么：同传系统的资源预算非常紧张，语种越多、领域越杂，模型容量需求越大。先做减法，明确“先支持什么、暂不支持什么”，才能把有限的模型容量用在刀刃上。

注意：如果业务需要双向翻译（双方各说一种语言），不要简单复制两套模型，否则体积翻倍。可以在输入端增加语种识别，让一套模型处理双向输入。

步骤二：准备流式训练数据

做什么：按 4.2 节完成数据收集与清洗，并为语音数据生成时间戳对齐。

为什么：同传模型需要在句子结束前输出部分结果，因此训练时必须让模型“看到”与真实使用一致的输入方式，即按块逐步到达的音频，而不是一次性拿到的完整句子。

注意：

• 训练时模拟流式输入，推荐使用“分块全序列训练”方法：把完整序列切成多个块，随机选择截止位置截断输入，只计算截断位置之前的损失；
• 翻译模块在训练时应使用“前缀强制”策略：把模型自己前一步生成的内容作为下一步输入，让模型在训练阶段就学会面对不完整、可能含错的前文，否则上线后极易出现重复、乱译；
• 公开语料和真实场景录音的分布差异很大，领域内数据至少应占训练集的一定比例，避免模型只会翻译书面语。

步骤三：设计流式学生模型结构

做什么：设计以轻量语音编码器为核心、翻译模块共享语义表示的小模型。结构可参考以下层次：

┌──────────────────────────────────────────────────────────────┐
│  音频输入（16 kHz PCM 分块）                                  │
│      ↓                                                       │
│  ① 声学特征提取（梅尔频谱等）                                 │
│      ↓                                                       │
│  ② 流式语音编码器：因果卷积下采样 + 限窗注意力                 │
│        · 每个块只关注左侧历史与少量右侧未来帧                  │
│        · 输出定长语义向量序列，带位置与块索引                  │
│      ↓                                                       │
│  ③ 跨模态适配层：将语义向量投影到文本隐空间                    │
│      ↓                                                       │
│  ④ 轻量翻译解码器：前缀强制 + 流式注意力（只关注已收到的向量）  │
│      ↓                                                       │
│  ⑤ 词表输出层：词表可按语种对裁剪，减少参数与计算              │
└──────────────────────────────────────────────────────────────┘

为什么：

• 因果卷积和限窗注意力让模型无需等待整句音频即可计算，这是流式能力的基础；
• 共享语义表示避免“先识别成完整文本，再交给独立翻译模块”的两段式设计，减少信息传递损耗，也降低整体体积；
• 裁剪词表能明显减少输出层参数量，对大词表的多语模型尤其有效。

注意：

• 右侧未来帧数直接决定延迟，一般控制在 200～500 毫秒，需与首字延迟目标一起权衡；
• 注意力窗口并非越大越好，过大的窗口会让每个块的计算量明显上升，在低端设备上难以实时运行。

步骤四：用教师模型蒸馏学生模型

做什么：以离线大模型作为教师，指导学生模型学习。训练流程如下：

1. 在目标语种对上，用平行语料和语音数据对教师模型做微调，使其适配业务领域，并记录测试集结果作为基线；
2. 用教师模型对训练集批量生成译文，形成软标签；
3. 按以下损失训练学生模型：

总损失 = λ1 × 硬标签交叉熵损失（参考译文）
       + λ2 × 软标签蒸馏损失（教师输出分布）
       + λ3 × 序列级蒸馏损失（对教师生成的完整译文）

为什么：小模型直接从零训练难以达到可用质量，而教师模型通常包含小模型数倍乃至数十倍的参数。让学生模仿教师的输出分布，相当于把大模型学到的“翻译习惯”迁移过来，能用更小的容量获得接近教师的效果。

注意：

• 教师生成的译文可能存在漏译、错译，需要过滤：用自动指标筛选低质量句对，或抽样人工复核；
• 各项损失的权重（λ）需要反复调参，建议先从软标签损失权重较大的配置开始，再逐步提高硬标签权重；
• 如果目标语种与教师预训练语料差异很大，可以为翻译模块加入低秩适配等参数高效微调模块，只训练少量新增参数，以降低训练成本。

步骤五：端侧量化与模型导出

做什么：把训练好的学生模型压缩并导出为端侧推理框架支持的格式。具体顺序如下：

1. 把模型权重导出为通用模型交换格式；
2. 使用端侧推理框架对应的转换工具转换为运行时格式；
3. 执行量化；
4. 在目标设备上加载并逐层比对输出，确认数值误差在可接受范围内。

常用量化方式对比如下：

量化方式	做法	优点	风险
训练后动态量化	权重离线量化为整型，激活值推理时动态量化	操作简单，体积明显缩小	部分算子在移动端支持有限
训练后静态量化	用一批校准数据统计激活值范围	推理更快	需要代表性校准集
量化感知训练	训练时模拟量化误差，让模型适应低精度	精度损失小	需要额外训练成本
分层混合量化	敏感层保留较高精度，其余层低比特量化	兼顾精度与体积	需要逐层分析敏感度

为什么：端侧设备的 CPU、NPU 对低精度整数运算有专门优化，量化后通常能获得明显的体积与速度收益。但不同层的敏感度不同，例如输入嵌入层、输出层、跨模态适配层对量化误差通常更敏感。

注意：

• 固定输入形状：导出时尽量固定音频块长度等输入尺寸，便于推理框架提前规划内存与算子；如果业务确实需要可变长度，需确认目标运行时是否支持动态形状；
• 导出后再裁剪：导出模型后再裁剪无用分支，如训练时的辅助分类头；
• 不要以压缩比为目标：模型大小不是目的，应先在目标设备上确认实时率达标，再逐步加大压缩力度，直到精度下降到不可接受为止。

步骤六：实现双通路解码与推理调度

这是端侧同传中决定流畅度的关键环节。先看清问题：同传推理同时存在两条工作负载特征完全不同的通路：

• 音频处理通路：声学特征提取和语音编码。计算量稳定，持续运行，对时延极其敏感；
• 文本生成通路：翻译解码。每个时间步只生成一个词，计算量小但次数多，主要消耗访存带宽。

如果用单线串行调度，两条通路会互相阻塞：音频通路等待解码结果时无法处理新到的音频，造成音频积压、延迟上升；解码通路等待音频编码时又会造成算力闲置。这也与近期业界在离线大模型推理中关注的方向一致：处理长输入的计算与逐字生成的访存压力差异很大，需要分开调度。

做法：在端侧把两条通路拆成独立的执行单元，它们之间只传递必要的中间数据：

┌────────────────────┐   语义向量块（按块索引）   ┌────────────────────┐
│ 通路A：音频处理     │ ─────────────────────────→ │ 通路B：文本解码     │
│ 特征提取 + 语音编码 │ ←───────────────────────── │ 翻译 + 增量输出     │
│ 固定节奏、高优先     │   消费确认 / 回溯请求      │ 事件驱动、可抢占     │
└────────────────────┘                            └────────────────────┘
            ↑                                               ↑
     音频输入队列                                    译文输出队列

调度规则如下：

1. 音频通路高优先：音频处理单元以最高优先级运行，新音频块到达即处理，保证编码进度始终领先；
2. 解码通路事件驱动：新语义向量块就绪后触发一次解码，输出当前译文；
3. 回溯请求 limited：需要重译时，解码通路向音频通路请求指定范围的语义向量，而这些向量已经在上一通路缓存，无需重新计算；
4. 限长缓存：语义向量缓存按“最大保留块数 × 单块向量大小”限定内存上限，超出后丢弃最早的数据。

为什么：

• 两条通路解耦后，各自的节奏互不影响，端到端延迟由最慢的那条决定，而不是两条之和；
• 缓存语义向量后，回溯重译几乎不增加计算量，可以更放心地使用重译策略换取质量；
• 内存占用可预估，避免长时间运行后内存持续增长。

注意：

• 端侧并发方式取决于平台和推理框架，可以使用线程、协程或框架自带的异步执行接口，但要避免频繁加锁；
• 如果推理框架支持计算图并行或异步执行，可把两条通路放入同一个执行计划，由框架统一调度；
• 解码通路的每次执行要设置超时时间，超时后跳过本轮输出、保留上一结果，绝不能阻塞音频采集。

步骤七：端侧集成：音频采集与增量输出

做什么：在客户端完成从麦克风到屏幕的完整链路。

1. 音频采集：以 10～20 毫秒为一帧采集音频；如果采样率不是 16 kHz，需要重采样。录音线程与 UI 线程必须分离；
2. 前端信号处理：依次做回声消除、自动增益、降噪，给编码器和端点检测提供干净的信号；
3. 端点检测：在本地运行轻量语音活动检测，判断“说话开始”“说话持续”“说话结束”；
4. 增量输出：同传结果采用“稳定前缀 + 未定稿后缀”两段式展示：

[稳定前缀：深色的译文] [未定稿后缀：浅色的译文]

• 稳定前缀只增不改；
• 未定稿后缀允许随新音频到达而更新；
• 收到端点信号后，把未定稿后缀固化为稳定前缀，并开始下一句。
  1. 语音播报（可选）：如果朗读译文，需要按句子或短语排队，播报进度要与文本展示同步，避免“念到一半文字已经变了”。

为什么：把“会变”的部分限制在后缀，用户既能第一时间看到译文，又不会被反复跳变的文字干扰。两段式展示也为后续的“稳定策略”提供了界面基础。

注意：

• 音频缓冲要用环形缓冲区，按采样点计数而不是按字节计数，避免声道数或位宽变化时出错；
• 切换到后台、来电或耳机插拔时，要正确处理录音中断与恢复，防止音频线程泄漏。

步骤八：稳定策略：让“未定稿”更快变成“定稿”

做什么：采用“稳定前缀—未定稿后缀”双流策略，决定每个输出词何时固化：

• 一个词连续 N 次输出结果不变，或其后已经出现 M 个新词，就把它固化为稳定前缀；
• 一旦固化，后续不再修改；
• 端点检测确认说话结束后，剩余部分全部固化。

伪代码如下：

def update_output(words, stable_count, cfg):
    # words：当前时刻模型输出的完整译文词序列
    if len(words) <= stable_count:
        return stable_count, ""            # 没有新增内容
    new_words = words[stable_count:]
    # 与上一轮输出对比，找出从本轮起持续不变的前缀长度
    keep = common_prefix_length(new_words, last_emitted[len(stable_count):])
    # 达到连续稳定帧数，或其后已有足够多的新词，则固化
    if keep >= cfg.stable_frames or len(new_words) - keep >= cfg.commit_lookahead:
        stable_count += keep
    stable = words[:stable_count]
    pending = words[stable_count:]
    return stable_count, f"{stable} | {pending}"   # pending 以浅色展示

为什么：重译质量更好，但会让整句译文反复变化；稳定策略只在“局部区域”允许变化，兼顾质量与体验。稳定帧数越少，输出越快，但跳变越多；越多则越稳，但滞后增加。

注意：参数需要用真实录音回放调优。可以统计“平均修改次数”和“平均滞后”两个指标，寻找二者的平衡点。

步骤九：效果验证、压力测试与上线监控

做什么：分三层验证。

1. 离线精度：在测试集上计算 WER 和 BLEU，并与教师模型对比；
2. 真实延迟：在目标机型上用标准测试音频实测首字延迟、平均滞后和最终结果延迟，统计 P50、P95 分位值；
3. 稳定性：进行 30 分钟以上连续运行测试，观察内存、CPU、温度和电量变化。

为什么：离线指标只反映翻译质量，用户实际感受到的是“延迟 + 稳定性 + 质量”的综合结果。低端设备上的延迟表现往往与高端设备相差数倍，必须分机型验证。

注意：

• 回放测试要在安静、嘈杂、远场、多人交谈等多种环境下进行；
• 上线后通过客户端埋点统计延迟分布、崩溃率和用户反馈；模型支持热更新时，按小流量逐步放量。

七、配置说明：关键参数怎么调

下表参数为通用命名，具体名称以所选推理框架为准。

配置项	含义	常见取值逻辑	调整风险
音频块长度	每次送入模型的音频时长	200～500 毫秒	过小则调用频繁、效率下降；过大则延迟增加
右侧上下文帧数	编码器可看到的未来音频	10～30 帧（每帧 10 毫秒左右）	增大可提升识别准确率，但直接增加延迟
解码温度	控制输出随机性	同传场景通常取较低值	过高会出现译文不稳定、重复
最大解码步数	单次输出允许的最大词数	按语种和块长估算	过小会截断长句，过大会拖慢响应
稳定帧数	词连续不变多少次后固化	2～4 次	过小则跳变多，过大则滞后增加
提交前瞻词数	其后出现多少新词后固化前词	3～6 个	与稳定帧数联合调优
端点静音时长	判定说话结束的静音时间	500～800 毫秒	过短容易误断句，过长则最终结果延迟
最大保留块数	语义向量缓存上限	按最大句子时长估算	过小会导致回溯重译失败
解码超时	单次解码最长执行时间	目标块长或略高	过短会频繁跳过输出，过长会阻塞链路

调参方法：

1. 先定延迟相关参数：音频块长度、右侧上下文帧数、解码超时；
2. 再调体验相关参数：稳定帧数、提交前瞻词数、端点静音时长；
3. 最后根据端侧日志微调：所有参数都应以真机日志为依据，不要照抄其他项目的默认值。

八、常见问题与排查

现象	可能原因	排查思路
首字延迟偏高	音频块过大、右侧上下文过多、前端处理耗时、低优先级抢占	用日志打点拆分各阶段耗时，找出最大的一段
译文反复跳变	稳定策略参数过松，或训练时未使用前缀强制	提高稳定帧数，检查训练配置
出现重复、死循环	模型面对不完整前缀时解码异常	降低解码温度，设置最大解码步数，补充流式训练数据
结尾内容丢失	端点检测过于灵敏或静音时长过短	适当延长静音时长，检查降噪是否削弱了句尾语音
长句运行一段时间后内存上涨	语义向量缓存、输出缓冲无上限	设置最大保留块数和最大输出长度
设备发热、帧率下降	实时率过高、解码过于频繁	合并部分解码调用，启用低精度推理
只显示原文没有译文	翻译模块初始化失败或模型格式不匹配	检查模型加载日志和算子兼容性
数字、单位翻译错误	领域数据不足	补充领域语料，接入文本规范化模块
说话时自己朗读的译文被录入	回声消除未生效	检查回声消除配置，优先建议使用耳机

其中“模型加载失败”最常见，按以下顺序排查：

1. 确认模型文件完整，哈希校验一致；
2. 确认模型所用算子在目标推理框架和芯片上受支持，必要时替换不支持的算子后重新导出；
3. 确认输入尺寸与导出时一致；
4. 在目标设备上加载最小模型做连通性测试，再逐步替换完整模型。

九、优化建议

1. 性能优化

   • 合并相邻的小算子，减少内核启动次数；
   • 优先使用推理框架提供的高性能算子实现；
   • 把模型权重常驻内存，避免每次推理重复加载；
   • 在支持的芯片上使用低精度推理。

2. 隐私与安全

   • 原始音频默认只在本地处理；
   • 需要上传时，先脱敏再传输，并使用加密通道；
   • 明确告知用户数据用途与保留时长；
   • 在客户端日志中避免打印原始音频和完整译文。

3. 稳定性

   • 为解码通路设置超时与熔断机制；
   • 准备降级策略：端侧模型异常时，可临时切换到云端通用识别与翻译能力，或仅保留识别结果；
   • 模型支持热更新，并保留上一版本以便回滚。

4. 可维护性

   • 模型按“版本 + 语种对 + 量化方式”命名管理，每次更新附带测试集评测报告；
   • 把精度评测和延迟基准纳入持续集成流程，防止模型迭代引起效果回退。

5. 成本控制

   • 训练阶段使用弹性算力，按需申请和释放；
   • 教师模型只在离线阶段使用，端侧只部署学生模型；
   • 端侧推理不消耗云端算力，可显著降低规模化服务成本。

十、总结与后续方向

本教程围绕“把实时语音同传放进端侧”这一目标，完整走过了以下环节：指标定义 → 流式数据准备 → 学生模型设计 → 教师模型蒸馏 → 量化导出 → 双通路解码调度 → 端侧集成与稳定策略 → 效果验证与排查。

其中最值得记住的三点是：

1. 先定指标再训练：延迟、质量、体积、功耗是同一组约束，不能只优化其中一项；
2. 模型结构决定流式上限：因果编码、限窗注意力和前缀强制训练，是端侧同传能否“边听边译”的基础；
3. 调度与交互策略决定体验：双通路调度、限长缓存和“稳定前缀 + 未定稿后缀”策略，决定了用户看到的是“流畅跟译”还是“反复跳变”。

随着端侧同传模型逐步进入商用阶段，后续可重点关注：

• 多语种扩展：用一个模型覆盖更多语种，控制体积增长；
• 音视频联合处理：结合视觉信息（如唇形、画面）提升嘈杂环境下的识别效果；
• 端云协同：端侧负责低延迟初译，云端负责复杂句的重译与润色；
• 智能体交互：在具备自主规划能力的智能体场景中，实时语音通道将成为人机交互的重要入口。

按本教程流程完成第一版原型后，建议先用真实场景录音做一轮回放评测，再逐步扩大语种和场景范围。