分类： 人工智能

MWER loss 实现

1、paraformer 负例采样策略：

The implementation of Minimum Word Error Rate Training loss (MWER) based on negative sampling strategy from <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>

https://gist.github.com/TeaPoly/234429e6c2d74d10fcb4987bc541d528

def create_sampling_mask(log_softmax, n):
    """
    Generate sampling mask
    # Ref: <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>
    #       https://arxiv.org/abs/2206.08317
    Args:
        log_softmax: log softmax inputs, float32 (batch, maxlen_out, vocab_size)
        n: candidate paths num, int32
    Return:
        sampling_mask: the sampling mask (nbest, batch, maxlen_out, vocab_size)
    """
    b, s, v = log_softmax.size()

    # Generate random mask
    nbest_random_mask = torch.randint(
        0, 2, (n, b, s, v), device=log_softmax.device
    )

    # Greedy search decoding for best path
    top1_score_indices = log_softmax.argmax(dim=-1).squeeze(-1)

    # Genrate top 1 score token mask
    top1_score_indices_mask = torch.zeros(
        (b, s, v), dtype=torch.int).to(log_softmax.device)
    top1_score_indices_mask.scatter_(-1, top1_score_indices.unsqueeze(-1), 1)

    # Genrate sampling mask by applying random mask to top 1 score token
    sampling_mask = nbest_random_mask*top1_score_indices_mask.unsqueeze(0)

    return sampling_mask

2、CTC decoder mwer loss：

https://github.com/Mddct/losses/blob/main/py/mwer.py

关键： 计算前缀束搜索候选路径

self.ctc_prefix_beam_decoer = CTCDecoder(beam_width=beam_width,top_paths=beam_width)

3、其他：wenet

https://github.com/wenet-e2e/wenet/tree/main#

Paraformer-v2: An improved non-autoregressive transformer for noise-robust speech recognition

原始 Paraformer 在非自回归语音识别方面取得了显著成效，尤其在普通话任务中表现突出，但其也存在一些局限性，特别是在跨语言适配和噪声鲁棒性方面。

背景：

1. 多语言适配能力有限（Multilingual Limitations）

  • CIF 模块难以适应非拼音型语言（如英语）：
    原始 Paraformer 使用 CIF（Continuous Integrate-and-Fire） 预测每个 token embedding。该机制假设每个语音片段可以通过声学模式推断出输出 token 数量。但英语等语言往往使用 BPE（Byte Pair Encoding） 等子词单元，token 数量波动大、边界不规则，CIF 很难准确预测 token 数。
  • 在英语、法语等语言上性能显著下降；
  • CIF 在 token 数量估计不准时，会导致对齐错乱、token 重复或丢失。

2、 对噪声敏感（Noise Sensitivity）

  • CIF 预测 α 权重完全基于声学表示，不含语义约束：
    • 如果输入中含有背景噪声（如会议环境），CIF 模块可能将噪声解释为有意义的语音特征；
    • 导致触发 α → β 条件时“错误地触发 token”，产生虚假输出。
  • 噪声环境下 WER/CER 明显上升；
  • 无语音输入时仍有输出（无法正确“输出空白”）。

3. 训练对目标长度高度敏感

  • CIF 模块需预测 token 数量，训练时必须强制调节 α 的归一化，使 token 数接近 ground truth；
  • 若目标长度估计不准，Decoder 会收不到足够 token embedding，导致学习不稳定

原始Paraformer：

Encoder 提取帧级表示：

CIF 生成 token embedding：使用 CIF（Continuous Integrate-and-Fire） 模块将帧级特征聚合为 token embedding 序列：

CIF 中权重 α 的生成：

Decoder 并行预测：

为使预测长度 U′U’U′ 尽可能接近 ground truth 长度 UUU，训练时需要对α1:T​ 做归一化：

Decoder 并行预测：Decoder 是一个 双向 Transformer

Loss：

改进：

利用 CTC 模块来获取 token embedding，事实证明，该模块具有更好的多语言适应性和更强的抗噪性。

使用 CTC 模块提取 Token Embedding：

生成帧级 posterior：类似于标准 CTC 解码头，对每一帧计算 token 分布（含 blank）

Greedy 解码得到 token 序列：

每一帧取最大概率的 token index（可能含 blank 和重复）

压缩 token 序列（Remove blanks & merge repeats）：

对重复 token 合并并平均其 posterior，得到 token 数量为 U′U’U′ 的 embedding 概率序列，去除 blank；

映射为 Token Embedding：

并行 Decoder 解码（Bidirectional）：（没有因果掩码（causal mask）限制上下文访问，每个位置的 token 同时关注其左侧和右侧所有位置）

CTC 压缩后的长度 U′U’U′ 和真实 token 长度 UUU 不一致，导致无法直接计算 CE Loss，解决方法：使用 Viterbi 对齐 将 CTC posterior 对齐到 target：

  • 其中 A1:T​ 是 Viterbi 解码得到的帧与 token 的对齐序列；
  • 这样生成的压缩 posterior 长度严格等于目标长度 U。

Paraformer-v2 同时优化：

  • Decoder 输出与目标之间的 CE Loss；
  • Encoder 输出与目标之间的 CTC Loss。

实验结果：

实际训练疑问：

新一代 Kaldi 热词识别功能

转自：https://mp.weixin.qq.com/s/d7Ab9u1_OAGLF76V1ymHmg

什么是热词

热词 其实是一个特别容易引起歧义的说法，尤其是在语音领域，比如唤醒次/命令词/新词都有人称之为热词，本文中要讨论的热词识别是在语音识别语境下的“上下文词语偏置”对应的英文为 contextual biasing。热词识别到底是做什么的呢？举一个例子就非常清楚了，比如：“今天河南省教育厅有关领导参观了南阳理工大学” 这样一句话，很多的语音识别系统应该会识别成 “今天河南省教育厅有关领导参观了南洋理工大学”，“南阳理工大学”和“南洋理工大学”音同字不同，训练语料中“南洋理工大学”又大概率多于“南阳理工大学”，所以模型非常倾向于输出“南洋理工大学”。热词识别要实现的就是，给定一些外部条件，让系统了解我们当前想要说的是“南阳理工大学”而不是“南洋理工大学”。

热词的实现方法

热词的实现方法大致可以分为两大类，一类是纯字符串匹配方法，一类是NN 神经网络 方法。顾名思义，纯字符串匹配的方法就是将解码过程中的所有可能路径都一一去匹配热词列表，如果匹配上热词就给对应的路径加上分数奖励，这样该路径就更有可能在 beam 剪枝中胜出，从而实现识别热词的功能。这种方法一般是在解码阶段实现，对声学部分是透明的，而且可以随意调整奖励的分数，比较灵活。需要解决的核心问题是高效的查找，一般都是基于自动机来实现，在解码器中附带一个类似于下图的热词图。

NN 方法其实非常多，近年也是大家发论文的热点（贴一个 awesome https://github.com/stevenhillis/awesome-asr-contextualization，有兴趣的同学可以去看论文），但总的来说就是将热词列表作为神经网络的其中一个输入，以此改变神经网络输出的分布，这样神经网络就能更大概率识别出热词。此种方法的使用需要在训练模型时进行干预，也就是说如果你需要一个带热词识别功能的模型，你就得重新训一个模型，最起码得在不带热词识别功能模型的基础上做 finetune。下图是一种可能的实现方式，通过热词列表来对 transducer 的 predictor 网络进行偏置。

实际的使用中也常常将两者一起配合使用，本文讨论的是第一种纯字符串匹配的热词实现方法。

基于 Aho-corasick 的热词实现

上文提到基于匹配的热词识别主要解决的是匹配效率问题，所以基本都使用自动机来实现，openfst 作为一个高效的自动机实现受到绝大部分人的青睐，但对于热词识别，还是有一些欠缺。比如，如果不进行较复杂的状态管理，则一次只能进行一个热词的匹配，这个问题 wenet 在其实现中有举例说明。如下所示，“唯品会”和“欧阳唯一”都是热词，但“欧阳唯品会”这条路径却无法匹配到“唯品会”。（openfst 当然可以实现这些功能，但会增加复杂度以及影响效率。）

热词的实现本质是一个多模匹配问题，它需要在 hypothesis 中搜索是否包含给定的热词列表，而多模匹配的最佳数据结构就是 Aho-corasick 自动机。关于 Aho-corasick 的构建细节本文不做过多叙述，感兴趣的同学可以阅读 （https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm）。

下面将一步一步叙述其怎样用于热词识别，下图是一个包含了热词 { "S", "HE", "SHE", "SHELL", "HIS", "HERS", "HELLO", "THIS", "THEM"} 的状态图（图要有一定复杂度才能够说明问题，爱学习的你一定会认真看的），Aho-corasick 图中主要有三种类型的边，goto 边（黑箭头），failure 边（红箭头） 和 output 边（绿箭头），简单地说，匹配走 goto 边，匹配失败则走 failure 边直到匹配为止或者回到 ROOT 节点，而只要 output 边存在即表示命中热词 (理论上每一个终止节点都有一个指向自己的 output 边，下图中未体现）而且得沿着 output 边的路径一直回溯到没有 output 边为止。

图中每条 goto 边都有一个分数，每个节点含有两个分数（node_score, local_node_score)，node_score 为全局节点的分数即从 ROOT 节点到目前的路径分数和，local_node_score为局部节点分数即从上一个中止节点[匹配到热词的节点]到目前的路径分数和，匹配 failure 的分数为 dest.node_score - src.local_node_score（图中未画出，因为 dest 可能需要回溯几条 failure 边才能到达）。我们想在热词局部命中时就给予一定分数奖励，防止 beam search 过程将可能的热词路径剪掉，所以会有如此复杂的分数设计，部分命中给予奖励需要在匹配失败时对已施加的分数进行补偿或消除。奖励分数究竟应该在完全命中后才施加还是局部命中就预先给予，每个人有不同的看法，笔者未进行过严格的性能对比，k2 中目前的实现参照 Deep context (https://arxiv.org/pdf/1808.02480.pdf) 中 on the fly rescoring 一节所述，每匹配一个 token 都会施加分数奖励。

我们以 “DID_HE_WANT_HERS_SHELF” (注意空格 _ 也是字符），来说明整个过程是如何匹配的，以及奖励分数如何作用到路径。“DID_” 几个字符未匹配任何热词的前缀，状态一直停留在 ROOT （ROOT 的 failure 是它自己）。“H” 匹配 state 0 到 state 2 的边获得奖励 1，“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为2），此时命中 “HE” 获获得奖励 2 （total 为 4），“_” 未匹配上沿着 state 3 的 failure 边回到 ROOT 减去奖励 2 （total 为2），“WAN” 未匹配任何前缀状态一直停留在 ROOT，“T” 匹配 state 0 到 state 15 的边获得奖励 1 （total 为 3），“_” 未匹配上沿着 state 15 的 failure 边回到 ROOT 减去奖励 1 （total 为2），“H” 匹配 state 0 到 state 2 的边获得奖励 1 （total 为3），“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为4），此时命中 “HE” 获得奖励 2 （total 为 6），“R” 匹配 state 3 到 state 10 的边获得奖励 1（total 为7），“S” 匹配 state 10 到 state 11 的边获得奖励 1（total 为8），此时命中 “HERS” 获得奖励 4 （total 为 12），state 11 包含 output 边指向 state 1 即命中 “S”获得奖励 1 （total 为13）， “_” 未匹配上沿着 state 11 的 failure 边回到 ROOT 减去奖励 4 （total 为9），“S” 匹配 state 0 到 state 1 的边获得奖励 1 （total 为 10），此时命中 “S” 获得奖励 1 （total 为11），“H” 匹配 state 1 到 state 4 的边获得奖励 1 （total 为 12），“E” 匹配 state 4 到 state 5 的边获得奖励 1 （total 为 13），此时命中 “SHE” 获得奖励 3 （total 为 16），state 5 还有 output 边指向 state 3 即命中 “HE” 获得奖励 2 （total 为 18），“L” 匹配 state 5 到 state 6 的边获得奖励1 （total 为 19），“F” 为匹配上沿着 state 6 的 failure 边到达 state 12， state 12 依然没能匹配 “F” 沿着 state 12 的 failure 边回到 ROOT 减去奖励 4 （state 6 的 node_score）（total 15），匹配结束。“DID_HE_WANT_HERS_SHELF” 命中 “HE”，“HE”，“HERS” ，“S”，“S”，“SHE”， “HE” 获得 15 的分数奖励。下面还有一些测试样例，可以帮助理解整个匹配过程，实际的热词识别匹配不会这么复杂，能命中一两个热词就已经足够在 beam search 胜出了。

queries = {
        "HEHERSHE": 14,  # "HE", "HE", "HERS", "S", "SHE", "HE"
        "HERSHE": 12,  # "HE", "HERS", "S", "SHE", "HE"
        "HISHE": 9,  # "HIS", "S", "SHE", "HE"
        "SHED": 6,  # "S", "SHE", "HE"
        "HELL": 2,  # "HE"
        "HELLO": 7,  # "HE", "HELLO"
        "DHRHISQ": 4,  # "HIS", "S"
        "THEN": 2,  # "HE"
    }
    for query, expected_score in queries.items():
        total_scores = 0
        state = context_graph.root
        for q in query:
            score, state = context_graph.forward_one_step(state, ord(q))
            total_scores += score
        score, state = context_graph.finalize(state)
        assert state.token == -1, state.token
        total_scores += score
        assert total_scores == expected_score, (
            total_scores,
            expected_score,
            query,
        )

Wenet 中也有基于 Aho-corasick 实现的热词，但暂时还没有合并，可以在 wenet 仓库的 pull requests 里查找。

一些实验结果

热词的实验结果跟测试集关系很大，下面放的是早期的一些测试结果，具体效果怎样，请在自己的测试集上实验。下面测试中的热词均为测试集对应 transcript 文本上用 NER 工具提取的短语，并做了适当筛选去除特别容易识别的短语。

Aishell 测试集（包含 1073 条热词）：

Librispeech 测试集 (包含 487 条热词）：

可以看出，该实现对 contexts 子集有较明显的提升，而对其他测试集基本没有影响。

k2 热词功能现状

k2 的热词功能实现已经有一段时间了，由于作者比较懒忙一直没有全面支持，目前 icefall 中的 librispeech pruned_transducer_stateless4 recipe 和 wenetspeech pruned_transducer_stateless5 recipe 已经支持，zipformer 模型正在 PR 中（很快合并）。sherpa 和 sherpa-onnx 中已经实现了核心功能，并且封装了 python 的 API，因为已经有很好的样例，所以我们当然非常希望社区的小伙伴能一起帮忙完善，但如果你们也很懒忙，也可以在微信群告诉我们或者在 github 仓库提 issue，我们会根据需要来安排优先级，目前我们收到的两个提议是支持 sherpa-onnx android 平台 和 sherpa-ncnn。

Ke-Omni-R :通过思考实现高级音频推理

Github:https://github.com/shuaijiang/Ke-Omni-R 【开源训练和推理代码】

贡献：用于将GRPO/思考过程 加入到语音大模型的强化训练过程中。

  • [1] Xie, Zhifei, et al. “Audio-Reasoner: Improving Reasoning Capability in Large Audio Language Models.” arXiv preprint arXiv:2503.02318.
  • [2] Ma, Ziyang, et al. “Audio-CoT: Exploring Chain-of-Thought Reasoning in Large Audio Language Model.” arXiv preprint arXiv:2501.07246.
  • [3] Li, Gang, et al. “Reinforcement Learning Outperforms Supervised Fine-Tuning: A Case Study on Audio Question Answering.” arXiv preprint arXiv:2503.11197
  • [4] Xu, Jin, et al. “Qwen2.5-Omni Technical Report.” arXiv preprint arXiv:2503.20215

Ke-Omni-R 是基于 Qwen2.5-Omni 构建的高级音频推理模型。构建音频推理模型，通过强化学习引入深度思考过程，提升复杂任务的理解和推理能力。仅使用 10,000 个训练后样本，Ke-Omni-R 就在 MMAU Test-mini 和 Test 基准测试中取得了最佳性能。其开发过程中的关键洞察包括：

  • GRPO 算法 ：GRPO 算法显著增强了已经很强大的基础模型（Qwen2.5-Omni-7B）的性能，即使在看不见的语音领域也表现出卓越的泛化能力。
  • 思考过程 ：融入简洁的思考过程（少于 50 个字）对于提高推理能力起着至关重要的作用。
  • KL 散度 ：通过利用 KL 散度，在 GRPO 训练期间观察到轻微的改进。
  • 领域比例 vs. 数据量 ：领域多样性比数据量更重要。我们仅使用了 10,000 个样本，其中 5,000 个从 AVQA 中随机选取，另外 5,000 个从 MusicBench 中选取。

Performance: Accuracies (%)↑ on MMAU Test-mini and Test benchmark

ModelMethodSound (Test-mini)Sound (Test)Music (Test-mini)Music (Test)Speech (Test-mini)Speech (Test)Average (Test-mini)Average (Test)
–Human*86.31–78.22–82.17–82.23–
Gemini Pro 2.0 FlashDirect Inference*56.4661.7358.6856.5351.6561.5355.6059.93
Audio Flamingo 2Direct Inference*61.5665.1073.9572.9030.9340.2655.4859.42
GPT4o + Strong Cap.Direct Inference*57.3555.8349.7051.7364.8668.6657.3058.74
Llama-3-8B-Instruct + Strong Cap.Direct Inference*50.7549.1048.9348.9355.2562.7052.1053.57
Qwen2-Audio-7B-InstructDirect Inference*54.9545.9050.9853.2642.0445.9049.2052.50
SALAMONNDirect Inference*41.0040.3034.8033.7625.5024.2433.7032.77
Audio-Reasoner(Qwen2-Audio-7B-Instruct)[1]60.06–64.30–60.70–61.71–
Audio-Cot(Qwen2-Audio-7B-Instruct)[2]61.86–56.29–55.26–57.80–
R1-AQA(Qwen2-Audio-7B-Instruct)[3]68.7769.7664.3761.4063.6662.7065.6064.36
Qwen2.5-Omni-7B[4]67.87–69.16–59.76–65.60–
Qwen2.5-Omni-3B[4]70.27–60.48–59.16–63.30–
Ke-Omni-R-3B(Qwen2.5-Omni-3B)GRPO w/ think (ours)72.3771.8765.5759.6064.2664.1767.4065.17
Ke-Omni-R(Qwen2.5-Omni-7B)GRPO w/o think (ours)69.6770.5767.6664.0066.3767.1767.9067.24
Ke-Omni-R(Qwen2.5-Omni-7B)GRPO w/ think (ours)69.3771.9069.4667.1367.8767.1068.9068.71

Performance: CER/WER (%)↓ on ASR benchmark

ModelMethodWenetSpeech test-netWenetSpeech test-meetingLibriSpeech test-cleanLibriSpeech test-other
Qwen2.5-Omni-3B[4]6.38.12.24.5
Qwen2.5-Omni-7B[4]5.97.71.83.4
Ke-Omni-3Bours11.716.11.83.8
Ke-Omni-7Bours7.59.81.63.1

StreamSpeech：“All in One”流式语音模型，支持语音识别、翻译、合成

两种主要结构：编码器-解码器框架（Transformer 及其变体）和多任务框架。 数据难题：数据增强、预训练、知识提炼和多语言建模。 应用：实时性、分段、命名实体、性别偏见和代码转换

 2024年6月，中国科学院计算技术研究所自然语言处理团队发布“All in One”流式语音模型——StreamSpeech。该模型可以在用户说话的同时，以端到端的方式实现语音识别、语音翻译、语音合成的多任务实时处理，延时低至320毫秒。StreamSpeech是能够以端到端方式同时完成多项离线和流式语音任务的开源模型。StreamSpeech可以部署在手机、耳机、AR眼镜等设备，助力国际会议、跨国旅行等场景下的低延时跨语言交流需求。

 StreamSpeech采用先进的two-pass架构，集成了流式语音编码器、实时文本解码器和同步的文本到语音合成模块。通过引入连接时序分类（Connectionist temporal classification，CTC）对齐机制，StreamSpeech能够控制模型在用户说话的同时理解并生成语音识别、翻译和合成结果。StreamSpeech在离线和实时语音到语音翻译上超过Meta的UnitY架构，在开源数据集上取得当前的最佳性能。此外，StreamSpeech还能在翻译过程中生成中间文本结果，为用户提供“边听边看”的流畅体验。

StreamSpeech 采用两遍架构，首先将源语音转换为目标文本隐藏状态（自回归语音到文本翻译，AR-S2TT），然后通过非自回归文本到单元生成生成目标语音。引入源/目标/单元 CTC 解码器，通过语音识别 (ASR)、非自回归语音到文本翻译 (NAR-S2TT) 和语音到单元翻译 (S2UT) 等多个任务学习对齐，从而指导 StreamSpeech 何时开始识别、翻译和合成。

  • 1. StreamSpeech 在离线和同步语音到语音翻译方面都实现了最先进的性能 。
  • 2. StreamSpeech 可以通过 “All in One”无缝模型执行流式 ASR、同步语音到文本翻译和同步语音到语音翻译。
  • 3. StreamSpeech 可以在同声翻译过程中呈现中间结果（即 ASR 或翻译结果） ，提供更全面的低延迟通信体验。
图 2： StreamSpeech 采用两遍架构，首先将源语音转换为目标文本隐藏状态 Dtext
 （自回归语音到文本翻译，AR-S2TT），然后通过非自回归文本到单元生成生成目标语音。引入源/目标/单元 CTC 解码器，通过语音识别 (ASR)、非自回归语音到文本翻译 (NAR-S2TT) 和语音到单元翻译 (S2UT) 等多个任务学习对齐，从而指导 StreamSpeech 何时开始识别、翻译和合成。

StreamSpeech：

Architecture

StreamSpeech 由三部分组成：流式语音编码器、同步文本解码器和同步文本到单元生成模块。引入多个 CTC 解码器，通过辅助任务学习对齐，并据此指导策略。

流式语音编码器： Conformer 架构通过堆叠注意力模块和卷积模块。在语音建模方面展现出显著优势，但在流式语音输入建模方面却存在困难，这主要是由于双向自注意力和卷积运算涉及整个序列的感受野。为此，我们提出了基于块的 Conformer 架构，旨在赋予 Conformer 架构编码流式输入的能力，同时保留局部块内的双向编码。

图 3 展示了基于块（chunk-based）的 Conformer 架构。首先，原始语音输入会被转换为语音特征（在我们的工作中使用的是滤波器组特征，每个语音特征通常对应约 40 毫秒的时长。基于块的 Conformer 会将流式语音划分为若干个块（chunk），每个块包含 C 个语音特征，其中 C 是一个控制块大小的超参数。在基于块的 Conformer 中，自注意力（self-attention）和卷积操作在块内部是双向的，在块之间则是单向的，从而能够处理流式输入。

对于基于块的自注意力机制，特征 xi​ 会关注那些位于相同块内或前面块内的特征 xj，其计算方式如下：

其中，Attn(xi,xj)是标准的多头注意力机制，而⌈⋅⌉ 表示向上取整操作。

对于基于块的卷积（chunk-based convolution），卷积操作的上界会被截断在当前块的边界处。即当使用核大小为 k 的卷积时，其计算方式为：

在实现上，基于块的卷积可以通过掩码操作（屏蔽掉那些被截断的位置）并行计算。通过流式编码器，计算源语音的隐藏状态，记为 H=(h1,⋯,h|H|) 。基于块的 Conformer 使得流式语音编码器不仅能够满足流式编码的需求，还能对语音进行局部双向编码。

H≤g(i)​ 的语义范围：

  • 包括了从起始到第 g(i) 帧为止的语音输入（多个 chunk 累积的结果）；
  • 每一个帧的表示都融合了：
    • chunk 内的 双向上下文（强表征）
    • chunk 之间的 单向依赖（因果性）

同步文本解码器： 在流式编码器之后，文本解码器通过关注源语音隐藏状态 H ，同时生成目标文本 Y 。为了实现这一点，StreamSpeech 需要一个策略来决定何时生成每个目标标记（即，解码器可以关注多少个语音状态）。合理的策略应该确保模型等到识别源语音中的源文本（读取），然后再生成相应的目标文本（写入）。

Simultaneous Text Decoder（同步文本解码器）是在流式语音编码器之后，边接收源语音隐藏状态 H，边生成目标文本 Y。为实现低延迟输出，需要一个策略（policy）来判断：

  • 何时 READ（读取更多源语音）
  • 何时 WRITE（生成目标 token）

核心做法：通过 CTC 对齐引导策略

1. 引入两个 CTC 解码器：

  • Source CTC Decoder：对齐源语音 → 源文本（ASR）
  • Target CTC Decoder：对齐源语音 → 目标文本（NAR-S2TT）

分别计算两个任务的 CTC Loss：

构建 READ / WRITE 策略函数。用上面两个 CTC 的输出计算当前语音段 X≤j对应的：

  • 已识别的源 token 数 Njasr
  • 已预测的目标 token 数 Njnar-s2tt

然后定义策略函数 g(i)，表示在什么时间步 j可以生成目标 token yi：

StreamSpeech 在接收到语音 X≤g⁢(i) 后自回归生成目标标记 yi 

READ 检测（左条件）：ASR 模块识别出一个新的源 token，说明我们“听”到了新语义，应该考虑进入写入阶段。

WRITE 准备（右条件）：非自回归模块预测当前语音内容足以包含第 iii 个目标 token，我们可以放心翻译了。

尽管 NAR-S2TT 用来预测 token 数以对齐，但最终目标 token yi 是通过 AR-S2TT 来生成的，以提升翻译质量：

基于由 ASR 和 NAR-S2TT 派生的对齐策略指导的策略，同步文本解码器在接收到语音 X≤g⁢(i) 后生成 yi ，并通过自回归语音转文本翻译（AR-S2TT， X→Y ）的交叉熵损失进行优化

Non-autoregressive Text-to-Unit Generation：为了同步生成当前目标文本所对应的语音单位（unit），StreamSpeech 采用了一种 非自回归的文本到单位（T2U）架构（Gu et al., 2018），该架构由一个 T2U 编码器 和一个 单位 CTC 解码器 组成。

  • T2U 编码器的输入是来自同步文本解码器生成的隐藏状态 Dtext​。
  • 鉴于音频单位序列 U 通常比文本序列 Y 更长，我们将 T2U 编码器的输出上采样 r 倍作为解码器输入

 it⁢h 输入对应于 D⌈i/r⌉t⁢e⁢x⁢t 。然后，单元 CTC 解码器通过关注位于 D⌈i/r⌉t⁢e⁢x⁢t 之前的 T2U 编码器输出，以非自回归的方式生成单元序列 U 。正式地，单元 CTC 解码器 CTCDecU 的输出 Du⁢n⁢i⁢t 计算如下：

NAR T2U 生成通过 CTC 损失在语音到单元翻译任务（S2UT， S→U ）上进行了优化：

最终，使用一个基于单位的 HiFi-GAN 声码器（Kong et al., 2020）来根据生成的单位序列合成目标语音。注意，这个声码器是预训练的并被冻结，不参与 StreamSpeech 的联合训练。

训练（Training）：

StreamSpeech 中涉及的所有任务都是通过**多任务学习（multi-task learning）以端到端（end-to-end）**的方式联合优化的。总体训练目标L 包括以下几个任务的损失：

  • S2UT（语音到单位翻译）
  • AR-S2TT（自回归语音到文本翻译）
  • ASR（语音识别）
  • NAR-S2TT（非自回归语音到文本翻译）

多任务学习能够有效地将同步策略的学习与翻译能力的学习整合进一个统一框架中。此外，像 ASR 和 AR-S2TT 等辅助任务生成的高质量中间结果，也可以在推理过程中展示给用户，作为补充参考内容。

多块训练（Multi-chunk Training）：在推理过程中，Simul-S2ST（流式语音到语音翻译）可能会面临不同的延迟需求。为每种延迟分别训练一个模型代价很高。为了解决这个问题，我们提出了 多块训练（multi-chunk training），以提升 StreamSpeech 在不同延迟水平下的性能表现。

在多块训练中：

  • 流式语音编码器的块大小 C不是固定的，
  • 而是从 U(1,∣X∣) 的均匀分布中随机采样，其中 ∣X∣ 表示整个输入语音序列的长度；
  • 特殊情况C=∣X∣ 即对应于离线 S2ST设置。

通过多块训练，单个 StreamSpeech 模型就能适应不同的延迟需求。

Inference：

在推理过程中，StreamSpeech 会基于设定的块大小 C 来处理流式语音输入，其中每个语音特征通常对应 40 毫秒的音频时长（例如，C=8 表示每 320 毫秒处理一次语音输入）。

然后，StreamSpeech 会使用 ASR 和 NAR-S2TT 的 CTC 解码器对当前接收到的语音 X^ 进行解码，分别生成源语言 token A^ 和目标语言 token Y^。

当满足以下两个条件时：

  1. 识别出了新的源 token（即 ∣A^∣>∣A∣）
  2. 当前语音中预测的目标 token 数超过已生成的目标 token（即 ∣Y^∣>∣Y∣）

模型将会进入 WRITE 阶段：

  • 更新源文本 A
  • 持续自回归地生成新的目标 token，直到达到 Y^ 的数量上限或遇到 <eos> 结束符
  • 根据目标文本生成对应的单位序列 U
  • 使用声码器合成出目标语音 S

否则，如果上述条件不满足，模型会进入 READ 阶段，等待接收下一个大小为 C 的语音块。

由于引入了多块训练（multi-chunk training），StreamSpeech 可以通过动态调整块大小 C 来控制推理延迟。其中：

  • 较小的 C 意味着更低的延迟；
  • 较大的 C 则带来更完整的上下文，提升质量。

实验

预处理
源语音转换为 16000Hz，将目标语音生成为 22050Hz。对于源语音，我们计算 80 维的 Mel 滤波器组特征，并进行全局的倒谱均值-方差归一化，每个语音特征对应 40 毫秒的时长。对于目标语音，通过 mHuBERT3提取离散单元，并使用预训练的基于单元的 HiFi-GAN 语音生成器进行语音合成。对于源文本和目标文本，我们分别使用 SentencePiece生成大小为 6000 的 unigram 词汇表。

离线语音到语音翻译（Offline S2ST）：StreamSpeech 采用 双阶段（two-pass）架构，相比使用单阶段（one-pass）架构的 S2UT 和 Translatotron，在性能上取得了显著提升。多任务学习（multi-task learning）不仅能指导策略学习，还能为翻译提供中间监督信号，从而进一步提升了离线 S2ST 的性能。

StreamSpeech 推理加速效果
为评估 StreamSpeech 的推理效率，表 2 报告了其相对于 UnitY 的加速比（speedup）。
在该双阶段架构中，StreamSpeech：

  • 第一阶段翻译使用自回归结构（更适合处理复杂语言重排）；
  • 第二阶段语音合成使用非自回归结构（尽管序列较长，但几乎单调对齐，易于并行）。

这种 先 AR 后 NAR 的两阶段架构，在保持翻译质量的同时，实现了 显著的推理速度提升。

Simul-S2ST（同步语音到语音翻译）：

在所有延迟设置下，StreamSpeech 的表现都优于 Wait-k，尤其是在低延迟条件下，BLEU 分数提升约 10 分。

Wait-k 策略是目前使用最广泛的同步策略，在同步文本到文本（T2TT）和语音到文本（S2TT）任务中表现良好。StreamSpeech 在同步语音到语音翻译中，不仅兼顾了延迟与质量，还通过对齐驱动策略实现了更自然的发声节奏，在多个基线之上取得了系统性提升。

语音翻译综述：Recent Advances in Direct Speech-to-text Translation

  • 语音翻译综述：Recent Advances in Direct Speech-to-text Translation

    • 两种主要结构：编码器-解码器框架（Transformer 及其变体）和多任务框架。 数据难题：数据增强、预训练、知识提炼和多语言建模。 应用：实时性、分段、命名实体、性别偏见和语种混合转换

    名词解释：

    • 误差累积（error accumulation）：指在连续的转录或翻译步骤中，由于前一步骤的错误会在后续步骤中积累，导致最终结果的质量逐渐下降的现象。这种误差累积通常在语音到文本（Automatic Speech Recognition, ASR）系统和文本到文本（机器翻译或文本转写）系统之间的多步骤流程中出现。在这些系统中，声音信号首先被转录成文本，然后文本再被翻译成目标语言或者以其他方式进行处理。如果在转录步骤中出现错误，这些错误将传递到后续步骤，影响最终的翻译或文本转写质量。
    • 自回归（Autoregressive）：在 E2E ST（End-to-End Speech Translation）模型中，”autoregressive” 表示模型会逐个生成翻译文本的每个词或子词，每次生成都会依赖于前一个时间步生成的内容。这是一种逐步、串行的生成过程。典型的 autoregressive 模型包括循环神经网络（RNN）、长短时记忆网络（LSTM）、和变换器（Transformer）等。
    1. 早期的语音翻译【Speech-to-text translation (ST)】解决方案是通过级联系统，使用多个子任务进行处理。
      • 比如首先通过ASR（Automatic Speech Recognition）系统，将语音转录为文本，然后再使用 MT（Machine Translation）系统将文本翻译为另一种语言。
      • 对于这样的级联系统，研究方向主要为解决误差累积（error accumulation）的问题。
    2. 端到端语音翻译【end-to-end speech translation (E2E ST)】有这样的好处：
      • 能够减少误差累积
      • 能够减少延迟
      • 拥有更多的上下文建模
      • 适用于不成文语言
    3. 基础建模：
      • ST 的语料库通常包含语音 s，转义文字 x，以及翻译结果 y
      • 基础的 E2E ST 模型框架是基于 Encoder-Decoder 架构的
      • 然而，E2E ST 模型的训练并不容易，其效果也只是接近于级联系统的结果，并不是性能最好的技术。
    4. 目前，E2E ST 模型研究方向主要为：
      • 建模负担（Modeling Burden）：
        • 需要同时处理跨模态（声音到文本）和跨语言（源语言到目标语言）的问题，导致模型建模会很复杂
        • 收敛困难，性能较差
      • 数据稀缺（Data scarcity）：
        • ASR、MT 的语料库非常多，且有些非常大
        • 但是 ST 的语料库其标注难度较高，因此 ST 的数据很少
      • 应用问题（Application issues）：
        • 需要考虑实际应用中的问题，如实时翻译，长格式音频分割等等。

    Tackling Modeling Burden：

    • 对于语音信号这种长序列输入，我们采用高容量端到端模型，通常是 Transformer及其变种架构。
    • 对于建模负担问题，通常采用多任务学习框架，对原始的 Transformer-based 模型进行修改。
    • 对解码效率问题，我们采用非自回归模型，从而提高解码速度

    Transformer ：

    Speech-Transformer
    • 基于 text-to-text Transformer
    • 主要改进点为 acoustic features 在进入自注意力编码器前，首先由卷积层（通常是步长为 2 的两层，将长度压缩 4 倍）压缩，然后再接一个归一化层
    Conformer
    • 主要改进点在于，在每个 encoder blocks 的 多头自注意力模块 和 前馈层 之间加入了 卷积模块
    • 卷积模块包括了注意力和卷积组件，由两个 Macaron-net 风格的前馈层（feed-forward layers）和残差连接（residual connections）所包围。
    SSL-Transformer
    • 这是一种结合了自监督学习（self-supervised learning，SSL）得到的语音表示模型
    • SSL 已经被成功应用到了提取语音特征的任务中去
    • SSL-Transformer 主要就是将原始的音频波形输入到自监督学习模型中，通过多个卷积层和编码层的处理，从而提取语音特征。
    • SSL-Transformer 模型中，自监督学习模型可以被整合到解码器中：或者作为一个独立的编码器，或者作为一个语音特征提取器，然后与整个 Transformer 模型相连接。

    Multitask Frameworks：

    针对模型负担的问题，多任务的核心思想是利用一些辅助工具来辅助目标任务的完成。比如ASR和MT。而有些任务模块和辅助模块的参数是可以共享的，这就导致了辅助任务的可行性。目前有三种类型的多任务框架：

    Decoupled Decoder（解耦解码器）

    额外的解码器用于引导模型学习文本转录（transcript），同时仍然以端到端的方式进行模型训练。主要思想有两种，一种是如何通过生成的文本转录来更好促进翻译，比如采用两遍解码器（two-pass decoder）；还有一种是同时生成文本转录和翻译（dual decoder）

    • Two-pass decoder：先将声学特征通过这个Decoder，然后再把转录结果和解码器结果结合起来用于翻译工作。但由于采用的是顺序生成（sequential generation），失去了低延迟的固有优势。因此有人用非自回归方法进行第一段的解码。
    • Dual decoder：交互式解码（interactive decoding）使用两个解码器同步生成转录和翻译。与此同时还额外使用了交叉注意力模块（cross-attention module）来为两个解码器交换信息。wait-k 策略（wait-k policy）通过首先预测转录文本的标记，为翻译标记的解码（the decoding of the translation tokens）提供了更多有用的信息。
    Decoupled Encoder（解耦编码器）

    对于解耦解码器，当遇到多重推理的时候可能会导致设计与延迟问题。更好的解决方案是通过解耦编码器同时识别和理解原始语音输入的语义。因此我们采用下面这张图的方案，共有两个encoder，低级语音编码器首先对来自语音输入的声学信息进行编码，语义编码器进一步学习翻译解码所需的语义表示。

    • 编码每个阶段都可以通过转录信息进行监督学习
    • 转录也提供了语音的对齐，可以缓解 encoding 负担

    Two-stream Encoder（双流编码器）

    ASR 的数据可以用来增强组件，那么 MT 的数据也可以吗？在训练过程中，我们可以同时接收语音和文字的输入，其各自有各自的编码器，还有个共享编码器。这个结构通常通过多任务训练损失进行优化，例如用于语音翻译（ST）和机器翻译（MT）的负对数似然（NLL）损失。其中的优势在于，通过与 MT 编码器共享，可以学到更好的语义表示，以提高翻译性能。

    在推断过程中，则是输入语音数据，通过语音编码器，共享编码器，解码器，最终生成翻译后的文本。

    • Speech encoder：其需要更有能力单独提取语音输入的声学特征。Wav2vec2 等预训练语音模型可用作语音编码器，以获得更好的 ST 性能
    • Text encoder：文本编码器可以是文本嵌入层（text embedding layer）或文本 Transformer 编码器的几层。同时，还可以用语音音素（phoneme）来代替原始转录作为文本输入，这样可以减少两种输入的模态差异。
    • Interaction：也有很多语音编码器和文本编码器交互的变种。
      • 有使用对比学习法（contrastive learning method）来缩短语音和文字的表达差异的
      • 有提出 Chimera model 来将语音和文字表达长度对齐的。
      • 还有同时考虑到表达和长度差异，从而在共享编码器后面添加交叉注意力正则化模块（cross-attentive regularization module）的，正则化模块首先通过自注意力或交叉注意力从文本或语音编码器生成两个具有相同长度的重构序列，然后优化重构序列之间的L2距离。

    Non-autoregressive Modeling

    端到端模型相比于同等级的级联系统大大降低了计算时延，但是这种优势仅在自回归解码的情况下有效，这个技术研究有两条路线：

    • 参考自动语音识别（ASR）和机器翻译（MT）任务中的方法，如条件掩码语言模型和重新评分技术，来开发非自回归语音翻译模型。
    • 探索更高效的架构，依赖纯粹的CTC（Connectionist Temporal Classification）进行预测，以提高速度。CTC 是一种用于序列标签任务的损失函数，它可以用于训练模型，使其能够将输入序列映射到输出序列。

    未来发展：

    LLM（Large Language Model）

    LLMs 包括 ChatGPT、Bloom等等，它们都有非常强大的能力，那么如何将LLM强大的生成能力融入到 ST 的任务中去，以及如何将语音数据也纳入LLM 的训练中去，是很值得研究的方向。

    • 第一步我们可以先优化语音的表示，使得其能够与文本的表示相媲美。
      • 伪语言——语音离散表示（speech discrete representations as pseudo-language）就是一个不错的方向。
    • 此外，预训练大规模 acoustics-aware LLMs 也是一个很 promising 的方向。

    Multimodality（多模态）

    人工智能生成的文本、图像、语音、视频等多模态信息爆发，推动了ST领域去探索更加复杂的人机交互（HCI，human-computer interaction）场景的研究，比如交流翻译（speech-to-speech translation），视频翻译等等。

    而多模态数据爆炸式的增长也致使在多模态数据上进行上下文学习（ICL，In-Context Learning）也成为了一个很有前途的研究方向，以更好地理解和利用不同模态数据之间的关联，从而实现更准确、更综合的多模态分析和应用。

    多模态预训练也被证明在许多领域中都是有效的。

    多模态之间的信息交互和关联也有待被发掘，比如视频中角色的语音和同一时间段角色的图像帧、韵律环境（prosodic environments，比如声调，音高，音量，语速，停顿等等，可以传达语言的情感、语气等）之间的关联。

    CosyVoice 3：语音合成领域迎来里程碑式突破

    CosyVoice 2 在语言覆盖范围、领域多样性、数据量和文本格式多样性方面存在明显局限性，在实现野外语音生成方面仍有较大改进空间。阿里巴巴团队全新发布的CosyVoice 3，以超越人类基线的自然度、覆盖 9 国语言 18 种方言的超强泛化能力，重新定义了「野外语音生成」的标准。

    摘要

    尽管 CosyVoice 2 在中文和英文广播场景中表现良好，但它在语言覆盖范围、领域多样性、数据规模以及文本格式多样性方面仍存在明显局限，距离实现真实环境中的语音生成还有较大提升空间。此外，针对语音生成模型的模型和数据的扩展规律，以及训练后的优化技术尚未被充分探索。

    为了解决上述问题，我们推出了 CosyVoice 3 —— 一款面向真实环境应用的大规模零样本语音生成模型，具备更广泛的语言覆盖和多样化的使用场景，在内容一致性、说话人相似度和韵律自然度等方面显著超越其前代产品 CosyVoice 2。

    我们的主要贡献如下：

    • 1）通过监督多任务训练开发的新型语音分词器，用于改善韵律自然度，包括自动语音识别、语音情感识别、语言识别、音频事件检测和说话人分析。
    • 2）一种适用于后期训练的新型可微分奖励模型[DiffRO]，不仅适用于 CosyVoice 3，还适用于其他基于 LLM 的语音合成模型。
    • 3）数据集规模扩展：训练数据从万小时扩展到百万小时，涵盖 9 种语言和 18 种汉语方言，跨越多个领域和文本格式。
    • 4）模型规模扩展：模型参数从 5 亿增加到 15 亿，由于更大的模型容量，在多语言基准测试中性能得到提升。这些进展显著推动了野外语音合成的发展。
    • 为应对真实世界中语音合成场景的多样性与泛化挑战，我们发布了面向零样本真实场景语音合成的评测基准集 CV3-Eval。该基准集基于 Common Voice、FLUERS、EmoBox 及网络爬取的真实音频数据构建，涵盖广泛的语言与方言、应用领域与环境、情绪与风格。

    技术方案

    图2：（a）监督式多任务训练的语音分词器 和（b）CosyVoice 3 的训练流程示意图。虚线框中的模块仅在训练阶段使用。语音分词器通过监督训练，涵盖自动语音识别（ASR）、语言识别（LID）、语音情感识别（SER）、音频事件检测（AED）以及说话人分析（SA）等任务。CFM 表示条件流匹配模型（Conditional Flow Matching model）。

     通过监督多任务训练实现语音分词器

    CosyVoice 3 的语音分词器基于 MinMo语音大模型[基于sensevoice-large的encoder]，这是一种在多个语音任务中表现优异的大规模预训练语音理解模型。

    与 CosyVoice 2 将有限标量量化（FSQ）模块插入 SenseVoice-Large ASR 模型的编码器不同，CosyVoice 3 将 FSQ 模块插入到了 MinMo 模型的语音编码器【也是 SenseVoice-Large encoder，但重新进行了多任务训练】中。相比于 SenseVoice-Large ASR 模型，MinMo 是一款更为先进的多模态大语言模型（LLM），在超过140万小时的语音数据上进行了训练，在多种基准任务中展现出更优越且达到了SOTA水平的表现，包括口语对话、多语种语音识别、以及情感识别等任务。

    为了进一步增强语义信息的捕捉能力，我们在 MinMo 的训练数据中选取了约53万小时的数据子集，针对我们的语音分词器进行监督多任务学习，涵盖了多语种ASR、语言识别（LID）、语音情感识别（SER）、音频事件检测（AED）以及说话人分析（SA）等任务。

    在训练阶段，如图2a所示，输入语音 X 首先经过 Voice Encoder1 【 SenseVoice-Large Encoder】得到中间表示 H，其中 Voice Encoder1 包含12个带旋转位置嵌入（RoPE）的Transformer模块。接着，中间表示H 被送入 FSQ 模块进行量化，量化后的表示再传递至 MinMo 的其余模块，包括 Voice Encoder2 和 MinMo LLM，用于预测对应文本标记的后验概率。

    Voice Encoder1、FSQ 模块中的低秩投影器、有限舍入操作（bounded round operation）以及索引计算模块共同构成了 CosyVoice 3 的语音分词器。我们的语音分词器的标记速率为 25 Hz，即每秒生成 25 个语音标记（speech tokens）。

    可微奖励优化的强化学习

    强化学习（RL）在提升生成语音质量方面是有效的，目前尚未建立一个通用适用于语音生成任务的强化学习方法论。与自然语言处理任务中的大语言模型（LLMs）不同，TTS 系统需要额外的下游条件流匹配（CFM）模块和声码器模型，将离散的语音标记转换为音频波形。这些下游模型带来了巨大的计算负担。更严重的是，经过下游处理后生成的语音通常表现出高度相似性，因此在训练奖励模型时，很难区分正反馈与负反馈。

    为了解决这些问题，我们提出了可微奖励优化（DiffRO）方法，该方法直接优化语音标记，而非合成音频。DiffRO 首先在 ASR 训练数据上训练一个类似 ASR 的 Token2Text 模型，并将后验概率作为奖励。为了进一步简化训练策略，DiffRO 使用 Gumbel-Softmax 操作对大语言模型预测的标记进行采样，并通过反向传播直接优化语音标记，以最大化奖励分数，而无需传统的强化学习训练循环。

    Gumbel-Softmax 是一种用来在离散空间中实现可微分采样的技巧，常用于需要从分类分布中抽样但又想保持梯度可传播的场景，比如强化学习中的策略采样、生成模型中的词生成，以及如 DiffRO 中对离散语音 token 的优化。

    其中，µₜ 和 µ̃ₜ 分别表示第 t 个时间步的真实语音标记和其采样预测值。RASR 是基于类似 ASR 的 Token2Text 模型计算得到的奖励函数。由于 RASR(Y) 旨在鼓励 µ̃ 捕捉文本中的全部信息，因此它有助于 TTS 系统更清晰、准确地理解文本。因此，我们可以直接优化大语言模型（LLM），使其输出标记与 ASR 偏好对齐，并使用 Kullback-Leibler（KL）散度来防止模型偏离参考模型太远。与其他强化学习方法不同，我们在输出标记级的 logits 上计算 KL 散度，而非在序列级的后验概率上计算。

    除了 Token2Text 模型之外，DiffRO 还利用情感识别（SER）、MOS 评分预测、音频事件检测（AED）以及其他音频理解任务，用于多任务奖励（MTR）建模。MTR 机制可以帮助 TTS 系统根据指令控制语音属性Ai

    发音修复

    基于大语言模型的语音合成（TTS）系统主要采用基于BPE的文本分词器，输入为原始文本。与传统的基于音素的方法相比，这类系统在发音的可控性方面存在不足。具体来说，对于由多音字或训练数据中稀少或未出现的罕见词引起的错误发音，缺乏基于人工干预的稳健方法。
    为了实现一个在发音上具备有效可控性的工业级TTS系统，我们对CosyVoice 3进行了扩展，使其能够通过扩充分词器词汇表来建模混合的词和音素序列。为实现该目标，我们构建了一个辅助训练集，将中文单音字替换为拼音，将英文单音词用CMU发音词典中的音素替换，并将该辅助数据集加入基础训练集中。

    文本规范化的自我训练

    在文本分词之前，TTS系统通常通过文本规范化（TN）模块处理原始文本，将数字和特殊符号转换为其对应的口语化文本，这一过程依赖大量手工设计的规则；然而，手工规则在覆盖特殊符号方面面临持续挑战。
    我们探索利用大语言模型（LLM）执行文本规范化任务，从而构建更加统一的端到端TTS系统。
    以原始文本为输入，我们采用三种方式构建辅助训练集：
    1）通过内部基于规则的文本规范化模块处理原始文本，得到规范化文本，再通过CosyVoice 2合成音频。
    2）利用Qwen-Max模型进行文本规范化，然后对规范化文本通过CosyVoice 2合成音频。
    3）利用Qwen-Max对已有的文本-音频对中的文本进行逆向文本规范化，恢复为原始（未规范化）文本，将该原始文本与对应音频作为配对样本，直接加入基础训练集。
    我们验证了基于扩展训练集训练的新系统可以直接合成原始文本，同时在处理各种特殊符号时展现出更好的鲁棒性和覆盖能力。

    指导式语音生成

    为了提升CosyVoice 3的可控性和表现力，相较于CosyVoice 2，我们在基础训练集中融入了更多富有表现力的语音数据。高质量指令跟随数据的时长从1500小时扩展到5000小时，覆盖了更广泛的类型，包括情感、语速、声调、方言、口音及角色扮演。类型总数增加到100多种，如表1所示。
    与CosyVoice 2类似，CosyVoice 3也支持语言指令和细粒度指令。对于自然语言指令，在合成语音的输入文本前添加自然语言描述及特殊结束标记“<|endofprompt|>”。
    对于细粒度指令，支持在文本标记间插入声音爆发（vocal bursts）和声音特征标签以实现控制。例如，输入文本中的“[laughter]”与“[breath]”标记可分别用来生成明显的笑声和呼吸声。标签“<strong>XXX </strong> ”用于强调特定词语。

    说话人微调中的能力迁移

    将单语说话人转变为多语者:CosyVoice 3 相较于前代的显著提升之一是语言支持的扩展。为了使单语目标说话人能够说多种语言，我们构建了一个辅助训练数据集，包含来自随机选择说话人的高质量单语录音，覆盖所有支持的语言。每条语音的说话人ID和语言ID均通过自然语言指令进行指定。

    指令生成能力的迁移:通过对预训练模型进行说话人特定数据的微调，可以提升个别说话人生成语音的质量和表现力。我们构建了一个部分标注说话人ID的训练数据集，该数据集包含目标说话人的高质量数据以及预训练时使用的指令跟随数据集。在自然语言指令提示中，我们指定说话人提示和风格提示。例如，一个完整的指令提示可能是：“你是说话人A，请高兴地和我说话。”然而，部分数据条目可能缺少说话人ID或风格标签，此时在提示中对应字段留空。微调过程中，我们还会随机屏蔽说话人提示或风格提示，以增强模型的迁移能力。
    该方法确保了不同说话人间指令的全面覆盖，并有助于防止预训练模型在指令生成时发生灾难性遗忘。

    多语言数据处理流程


    相比中文和英文，获取其他语言的大规模高质量TTS数据更具挑战性。为应对这一挑战，我们主要从网络有声书、视频和播客中收集野外多语言音频数据。随后，实施多语言数据处理流程，产出质量充足的模型训练数据。该流程包括六个步骤：

    1. 语音检测与分段
    2. 降噪
    3. 自动语音识别（ASR）转录
    4. 标点调整
    5. 音量标准化
    6. 过滤异常音频-文本长度比例的数据

    语音检测与分段:原始数据依次通过说话人分离（speaker diarization）、语音活动检测（VAD）和音频事件检测模块处理，得到说话人级别且时长小于30秒的语音片段。该步骤虽采用内部模块，但同类开源方案也能实现类似效果。

    降噪：采用MossFormer2模型进行降噪。接着，根据语句起始和结束帧的能量水平，筛除因异常截断导致开头或结尾单词不完整的语句；剩余语句去除开头和结尾的静音后保留用于后续处理。

    ASR转录：为获得足够可靠的文本转录，首先使用FasterWhisper Large-V3进行语言识别，然后分别使用多款开源ASR模型（包括Faster-Whisper Large-V3、NVIDIA NeMo Canary-1B、Meta FAIR seamlessM4T-V2-large）对语句进行转录。随后进行交叉验证，选取不同系统ASR结果间平均成对字错误率（WER）低于15%的转录结果。

    标点调整：由于ASR生成文本中的标点可能不能准确反映对应音频的实际停顿，我们采用Montreal Forced Aligner计算词与词、句或短语间的时长，并根据预设阈值对标点进行增删（停顿时间≥300毫秒时添加逗号，≤50毫秒时移除表示停顿的标点，如逗号、分号、冒号、句号、问号和感叹号）。

    音量标准化：对音量进行简单直接的归一化处理，

    过滤异常音频-文本长度比例的语句：在完成上述所有处理步骤后，对每个生成的语音-文本对提取语音标记和文本标记，计算并排序语音标记长度与文本标记长度的语句级比例。
    我们丢弃长度比例最小的1%和最大的5%的语句，以过滤可能存在异常的情况，例如：音频很短且无有效人声但对应较长文本转录，或音频较长但仅包含目标语言的短语音片段，从而对应较短文本转录。

    Experimental Settings

    Training Data for Speech Tokenizer

    使用 53 万小时的监督多任务数据集，以标准化转录为标签，训练语音分词器，包括自动语音识别 (ASR)、语种识别 (LID)、语音情感识别 (SER)、音频事件检测 (AED) 和说话人分析 (SA)。训练数据详情如表 3 所示。多语言 ASR 训练数据包括中文、英语、日语、韩语、俄语、法语和德语。

    Scaling up Dataset Size and Model Size for CosyVoice 3

    在 CosyVoice 3 中，我们从多个角度扩展数据量。针对广泛使用的中英文数据，我们采用低成本数据生产流程与自训练数据构建相结合的方式，增强领域、风格、文本格式和稀有案例的多样性。在领域多样性方面，我们收集了电商、导航、金融、教育等多个领域的语音数据。在风格多样性方面，我们添加了对话、演讲、歌唱等多种语言。在文本多样性方面，我们通过文本规范化 (TN) 和逆文本规范化 (ITN) 为同一段语音构建不同的文本格式，增强模型对各种文本格式的鲁棒性。此外，我们利用早期版本的 CosyVoice 3 策略性地自训练构建了大量的稀有案例，以提高合成的稳定性。在语言覆盖方面，我们在中英文数据集中新增了日语、俄语、法语、德语、西班牙语、韩语和意大利语等七种常用语言，数据覆盖比例如图 3a 所示。前期工作表明，监督式多任务语音分词器在一些新语言（例如 CosyVoice 3 中的西班牙语和意大利语）上表现良好。除了标准的常见方言发音外，我们还增加了对汉语口音和方言的覆盖范围，目前已支持 19 种常见口音或方言，数据占比如图 3b 所示。通过这些数据扩展，CosyVoice 3 的训练数据已达到百万小时，涵盖了日常生活中的大多数用户案例，并朝着自然界零样本语音生成的目标迈进。

    除了扩展数据集大小之外，扩大模型大小对于当前的大规模模型至关重要。因此，我们在 CosyVoice 3 中增加了文本转语音语言模型 (LM) 和条件流匹配 (CFM) 模型的大小。具体而言，文本转语音 LM 的参数数量从 0.5 亿增加到 1.5 亿。对于 CFM，我们采用最新的扩散变换器 (DiT) 作为骨干网络，将参数数量从 1 亿增加到 3 亿。初步实验证明了 DiT 架构的强大性能；因此，复杂的文本编码器和长度正则化模块不再需要，并从 CosyVoice 3 中移除。我们通过简单的插值操作解决了语音标记和 Mel 特征之间的帧率不匹配问题。

    为了评估 CosyVoice 3 的零样本语音生成能力，我们关注三个关键方面：内容一致性、说话人相似度和音频质量。对于内容一致性，我们使用 Whisper-large V3测量 ASR 转录文本与给定文本的字符错误率 (CER) 或词错误率 (WER)。对于英文 ASR，我们使用 Paraformer  测量中文 ASR。为了评估说话人相似度，我们使用 ERes2Net 说话人验证模型从生成的语音中提取说话人嵌入，并计算与参考语音嵌入的余弦相似度。对于音频质量，我们使用 DNSMOS 网络对生成的语音进行评分，该网络的得分与人类听觉感知高度相关。

    为了更好地评估 CosyVoice 3，我们建立了一个多语言基准 CV3-Eval，其中包括客观和主观评估的子集。

    Experimental Results

     SEED-TTS-Eval 上的客观 TTS 结果

    CosyVoice 3 与基线在 SEED 测试集上的内容一致性 (WER/CER) 和说话人相似度 (SS) 方面的零样本 TTS 性能比较。对于说话人相似度，括号外的结果由基于 WavLM 的模型测量，括号内的结果由 ERes2Net 测量。 粗体表示最佳结果，下划线表示次佳结果

     在多语言基准 CV3-Eval 上的客观评估：

    对于 CosyVoice 3 来说，生成生僻词、绕口令和领域特定术语仍然很困难，这突显了未来有待改进的地方。

     跨语言语音克隆结果：CosyVoice 3 在跨语言语音克隆方面相较 CosyVoice 2 的显著提升。值得注意的是，由于两种语言的字符重叠，CosyVoice 2 在将语音从日语转换为中文时遇到了困难。CosyVoice 3 通过将所有日语字符转换为假名解决了这个问题。此外，扩大模型规模也带来了益处：与 CosyVoice3-0.5B 相比，CosyVoice3-1.5B 在所有条件下都表现出了更佳的字错误率 (WER)，同时保持了与 CosyVoice 2 相似的说话人相似度。这表明，由于容量的增加，更大的模型可以提升在挑战性任务上的表现。总体而言，CosyVoice3-1.5B 仍然是 zh2en 和 en2zh 跨语言语音迁移任务中的领先模型。

    在与文本无关的任务中，情感准确率显著下降，尤其是“悲伤”和“愤怒”情感。这表明 TTS 系统主要从文本情绪中推断输出音频的情感基调。这一观察结果为了解不太令人满意的表现提供了宝贵的见解，并突出了未来需要改进的地方。

    主观评价结果：

    Qwen3 技术报告

    • MoE 模型：Qwen3-235B-A22B 和 Qwen3-30B-A3B；其中 235B 和 30B 分别是总参数量，22B 和 3B 分别是激活参数量。
    • 密集模型：Qwen3-32B、Qwen3-14B、Qwen3-8B、Qwen3-4B、Qwen3-1.7B 和 Qwen3-0.6B。

    整体架构：

    1) 包含num_experts个轻量级专家网络(Qwen3MoeMLP)的并行计算单元；

    2) 基于注意力机制的路由网络(gate)。

    在计算过程中，路由网络通过动态决策机制为每个输入Token生成路由决策，筛选出匹配度最高的top_k个专家节点。随后，系统将根据路由权重对选定专家的计算结果进行加权融合，最终生成该隐层的表征输出。

    那么同样我们对比DeepSeekMOE，Qwen3MOE有两个点的改变：

    1）没有shared expert。

    2） 优化了MLP架构，变为Qwen3MoeSparseMoeBlock。

    模型特性优化总结表：

    特性实现细节
    注意力机制改进的Qwen3Attention（支持Flash Attention优化）
    MoE路由策略Top-K专家选择（默认K=2），支持权重归一化
    专家结构每个专家为标准MLP（hidden_size → moe_intermediate_size → hidden_size）
    动态专家分配每间隔decoder_sparse_step层使用MoE（其他层使用标准MLP）
    负载均衡机制通过router_logits计算辅助损失，防止专家极化
    计算优化使用index_add操作实现零浪费的专家计算

    对比传统MOE优化效果：

    优化方向Qwen3-MoE实现方案对比传统MoE模型优势
    路由机制Top-K + 动态权重归一化（norm_topk_prob）缓解专家利用不均衡问题，相比Mixtral的固定权重分配更灵活
    稀疏模式分层动态稀疏（decoder_sparse_step控制MoE层间隔）混合密集与稀疏计算，相比全MoE结构降低计算开销
    内存优化logits_to_keep参数支持部分logits计算长序列生成时内存占用减少，优于Mixtral的全序列计算
    注意力机制改进的Flash Attention 3.0集成相比标准Attention实现，训练速度提升，显存占用减少
    负载均衡改进的辅助损失函数（load_balancing_loss_func+自研调整系数）专家利用率从Mixtral的提升，防止专家极化
    动态计算mlp_only_layers参数跳过MoE层支持按需切换密集/稀疏模式，相比固定结构推理灵活性提升

    性能方面，在代码、数学、通用能力等基准测试中，旗舰模型 Qwen3-235B-A22B 与 DeepSeek-R1、o1、o3-mini、Grok-3 和 Gemini-2.5-Pro 等顶级模型表现相当。

    此外，小型 MoE 模型 Qwen3-30B-A3B 的激活参数数量是 QwQ-32B 的 10%，表现却更胜一筹。甚至像 Qwen3-4B 这样的小模型也能匹敌 Qwen2.5-72B-Instruct 的性能。

    性能大幅提升的同时，Qwen3 的部署成本还大幅下降，仅需 4 张 H20 即可部署满血版，显存占用仅为性能相近模型的三分之一。

    核心亮点

    • 多种思考模式

    Qwen3 模型支持两种思考模式：

    1. 思考模式：在这种模式下，模型会逐步推理，经过深思熟虑后给出最终答案。这种方法非常适合需要深入思考的复杂问题。
    2. 非思考模式：在此模式中，模型提供快速、近乎即时的响应，适用于那些对速度要求高于深度的简单问题。

    这种灵活性使用户能够根据具体任务控制模型进行“思考”的程度。例如，复杂的问题可以通过扩展推理步骤来解决，而简单的问题则可以直接快速作答，无需延迟。至关重要的是，这两种模式的结合大大增强了模型实现稳定且高效的“思考预算”控制能力。如上文所述，Qwen3 展现出可扩展且平滑的性能提升，这与分配的计算推理预算直接相关。这样的设计让用户能够更轻松地为不同任务配置特定的预算，在成本效益和推理质量之间实现更优的平衡。

    下图为在 AIME24、AIME25、LiveCodeBech（v5）和 GPQA Diamond 等基准测试集中，非思考模式与思考模式的思考预算变化趋势。

    • 多语言

    Qwen3 模型支持 119 种语言和方言。这一广泛的多语言能力为国际应用开辟了新的可能性，让全球用户都能受益于这些模型的强大功能。

    语系语种&方言
    印欧语系英语、法语、葡萄牙语、德语、罗马尼亚语、瑞典语、丹麦语、保加利亚语、俄语、捷克语、希腊语、乌克兰语、西班牙语、荷兰语、斯洛伐克语、克罗地亚语、波兰语、立陶宛语、挪威语（博克马尔语）、挪威尼诺斯克语、波斯语、斯洛文尼亚语、古吉拉特语、拉脱维亚语、意大利语、奥克语、尼泊尔语、马拉地语、白俄罗斯语、塞尔维亚语、卢森堡语、威尼斯语、阿萨姆语、威尔士语、西里西亚语、阿斯图里亚语、恰蒂斯加尔语、阿瓦德语、迈蒂利语、博杰普尔语、信德语、爱尔兰语、法罗语、印地语、旁遮普语、孟加拉语、奥里雅语、塔吉克语、东意第绪语、伦巴第语、利古里亚语、西西里语、弗留利语、撒丁岛语、加利西亚语、加泰罗尼亚语、冰岛语、托斯克语、阿尔巴尼亚语、林堡语、罗马尼亚语、达里语、南非荷兰语、马其顿语僧伽罗语、乌尔都语、马加希语、波斯尼亚语、亚美尼亚语
    汉藏语系中文（简体中文、繁体中文、粤语）、缅甸语
    亚非语系阿拉伯语（标准语、内志语、黎凡特语、埃及语、摩洛哥语、美索不达米亚语、塔伊兹-阿德尼语、突尼斯语）、希伯来语、马耳他语
    南岛语系印度尼西亚语、马来语、他加禄语、宿务语、爪哇语、巽他语、米南加保语、巴厘岛语、班加语、邦阿西楠语、伊洛科语、瓦雷语（菲律宾）
    德拉威语泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语
    突厥语系土耳其语、北阿塞拜疆语、北乌兹别克语、哈萨克语、巴什基尔语、鞑靼语
    壮侗语系泰语、老挝语
    乌拉尔语系芬兰语、爱沙尼亚语、匈牙利语
    南亚语系越南语、高棉语
    其他日语、韩语、格鲁吉亚语、巴斯克语、海地语、帕皮阿门托语、卡布维尔迪亚努语、托克皮辛语、斯瓦希里语
    • 增强的 Agent 能力

    我们优化了 Qwen3 模型的 Agent 和 代码能力，同时也加强了对 MCP 的支持。

    预训练

    在预训练方面，Qwen3 的数据集相比 Qwen2.5 有了显著扩展。Qwen2.5是在 18 万亿个 token 上进行预训练的，而 Qwen3 使用的数据量几乎是其两倍，达到了约 36 万亿个 token，涵盖了 119 种语言和方言。为了构建这个庞大的数据集，我们不仅从网络上收集数据，还从 PDF 文档中提取信息。我们使用 Qwen2.5-VL 从这些文档中提取文本，并用 Qwen2.5 改进提取内容的质量。为了增加数学和代码数据的数量，我们利用 Qwen2.5-Math 和 Qwen2.5-Coder 这两个数学和代码领域的专家模型合成数据，合成了包括教科书、问答对以及代码片段等多种形式的数据。

    Qwen3模型采用三阶段预训练过程：

    1. 通用阶段 (S1): 在第一阶段，所有Qwen3模型使用4,096 token的序列长度，在超过30万亿token的数据上进行训练 。此阶段旨在建立模型的语言能力和通用世界知识基础，训练数据覆盖119种语言和方言 。
    2. 推理阶段 (S2): 为了进一步提升推理能力，此阶段的预训练语料库增加了STEM、编码、推理和合成数据的比例 。模型使用4,096 token的序列长度，在约5万亿高质量token上进行进一步预训练 。在此阶段还加速了学习率衰减 。
    3. 长上下文阶段: 在最后一个预训练阶段，收集高质量长上下文语料库，将Qwen3模型的上下文长度扩展到32,768 token 。长上下文语料库中，75%的文本长度在16,384到32,768 token之间，25%的文本长度在4,096到16,384 token之间 。报告提及沿用Qwen2.5的做法，使用ABF技术将RoPE的基础频率从10,000提高到1,000,000 。同时，引入YARN和Dual Chunk Attention (DCA)技术，在推理过程中实现序列长度容量的四倍增长 。

    类似于Qwen2.5，Qwen3根据这三个预训练阶段开发了最优超参数（如学习率调度器和批次大小）预测的缩放律 。通过广泛实验，系统研究了模型架构、训练数据、训练阶段与最优训练超参数之间的关系 。最终为每个密集模型和MoE模型设定了预测的最优学习率和批次大小策略。

    由于模型架构的改进、训练数据的增加以及更有效的训练方法，Qwen3 Dense 基础模型的整体性能与参数更多的Qwen2.5基础模型相当。例如，Qwen3-1.7B/4B/8B/14B/32B-Base 分别与 Qwen2.5-3B/7B/14B/32B/72B-Base 表现相当。特别是在 STEM、编码和推理等领域，Qwen3 Dense 基础模型的表现甚至超过了更大规模的 Qwen2.5 模型。对于 Qwen3 MoE 基础模型，它们在仅使用 10% 激活参数的情况下达到了与 Qwen2.5 Dense 基础模型相似的性能。这带来了训练和推理成本的显著节省。

    后训练

    为了开发能够同时具备思考推理和快速响应能力的混合模型，我们实施了一个四阶段的训练流程。该流程包括：（1）长思维链冷启动，（2）长思维链强化学习，（3）思维模式融合，以及（4）通用强化学习。

    后训练部分详细介绍了Qwen3模型的后训练流程和评估结果 。Qwen3的后训练流程策略性地设计了两个核心目标：思维控制和强到弱蒸馏 。

    思维控制 (Thinking Control):

    思维控制涉及将“非思维”模式和“思维”模式集成到模型中，为用户提供灵活性，选择模型是否进行推理，并通过指定思维过程的token预算来控制思考的深度 。

    强到弱蒸馏 (Strong-to-Weak Distillation):

    强到弱蒸馏旨在优化轻量级模型的后训练过程 。通过利用大型模型的知识，显著降低了构建小型模型所需的计算成本和开发工作 。

    如图1所示，Qwen3系列的旗舰模型遵循复杂的四阶段训练过程 。前两个阶段侧重于发展模型的“思维”能力 。后两个阶段旨在将强大的“非思维”功能整合到模型中 。

    初步实验表明，将教师模型的输出logit直接蒸馏到轻量级学生模型中，可以有效增强其性能，同时保持对其推理过程的细粒度控制 。这种方法避免了为每个小型模型单独执行详尽的四阶段训练过程 。它带来了更好的即时性能（通过更高的Pass@1分数体现），也提高了模型的探索能力（通过改进的Pass@64结果反映） 。此外，它以更高的训练效率实现了这些提升，所需的GPU小时仅为四阶段训练方法的1/10 。

    在第一阶段，我们使用多样的的长思维链数据对模型进行了微调，涵盖了数学、代码、逻辑推理和 STEM 问题等多种任务和领域。这一过程旨在为模型配备基本的推理能力。后训练始于策划一个涵盖数学、代码、逻辑推理和通用STEM问题等广泛类别的综合数据集 。数据集中的每个问题都配有经过验证的参考答案或基于代码的测试用例 。该数据集作为长链式思维（long-CoT）训练“冷启动”阶段的基础 。数据集构建涉及严格的两阶段过滤过程：查询过滤和响应过滤 。报告详细描述了过滤过程，包括使用Qwen2.5-72B-Instruct识别和移除不易验证的查询，排除无需CoT推理即可正确回答的查询，以及对生成的候选响应进行多项标准的严格过滤 。此阶段的目标是在模型中注入基础的推理模式，而不过度强调即时推理性能 。

    第二阶段的重点是大规模强化学习，利用基于规则的奖励来增强模型的探索和钻研能力。推理RL阶段使用的查询-验证对必须满足四个标准：未在冷启动阶段使用、对冷启动模型可学习、尽可能具有挑战性、涵盖广泛的子领域 。共收集了3,995对查询-验证对，并使用GRPO更新模型参数 。报告提及使用大批次大小和每次查询多次rollout，以及利用离线训练提高样本效率，对训练过程有益 。通过控制模型的熵，平衡探索和利用，实现了训练和验证性能的持续改进 。例如，Qwen3-235B-A22B模型的AIME’24分数在170个RL训练步骤中从70.1提高到85.1 

    在第三阶段，我们在一份包括长思维链数据和常用的指令微调数据的组合数据上对模型进行微调，将非思考模式整合到思考模型中。确保了推理和快速响应能力的无缝结合。思维模式融合阶段的目标是将“非思维”能力整合到之前开发的“思维”模型中 。这允许开发者管理和控制推理行为，同时降低部署独立模型处理思维和非思维任务的成本和复杂性 。为此，在推理RL模型上进行持续监督微调（SFT），并设计聊天模板来融合两种模式 。

    SFT数据构建：SFT数据集结合了“思维”和“非思维”数据 。为了不损害第二阶段模型的性能，“思维”数据是使用第二阶段模型本身通过对第一阶段查询进行拒绝采样生成的 。“非思维”数据则精心策划，涵盖编码、数学、指令遵循、多语言任务、创意写作、问答和角色扮演等广泛任务 。报告还提及使用自动生成的清单评估“非思维”数据的响应质量，并增加低资源语言翻译任务的比例以增强性能 。

    聊天模板设计：为了更好地集成两种模式并允许用户动态切换模型的思维过程，Qwen3设计了聊天模板 。通过在用户查询或系统消息中引入/think和/no think标志，模型可以根据用户的输入选择适当的思维模式 。即使在非思维模式样本中，也保留了空的思维块，以确保模型内部格式的一致性 。默认情况下，模型在思维模式下运行，因此也包含一些用户查询不含/think标志的思维模式训练样本 。对于更复杂的多轮对话，随机插入多个/think和/no think标志，模型响应遵循最后遇到的标志 。

    思维预算：思维模式融合的另一个优势是，一旦模型学会以非思维和思维模式响应，它自然会发展出处理中间情况的能力——基于不完整的思考生成响应 。这为实现模型思维过程的预算控制奠定了基础 。当模型的思考长度达到用户定义的阈值时，会手动停止思考过程并插入停止思考指令，然后模型根据其累积的推理生成最终响应 。报告指出，这种能力并非显式训练所得，而是思维模式融合应用自然产生的结果 。

    最后，在第四阶段，我们在包括指令遵循、格式遵循和 Agent 能力等在内的 20 多个通用领域的任务上应用了强化学习，以进一步增强模型的通用能力并纠正不良行为。

    通用RL阶段旨在广泛增强模型在各种场景下的能力和稳定性 。为此，建立了覆盖20多个不同任务的复杂奖励系统，每个任务都有定制的评分标准 。这些任务专门针对以下核心能力的提升：指令遵循、格式遵循、偏好对齐、Agent能力和专业场景下的能力（如RAG任务） 。

    报告提及使用了三种不同类型的奖励来提供反馈：基于规则的奖励（用于推理RL阶段和通用任务，如指令遵循和格式遵循）、基于模型的奖励（带参考答案，允许更灵活地处理多样化任务）、基于模型的奖励（不带参考答案，利用人类偏好数据训练奖励模型，处理更广泛的查询并增强模型的互动性和帮助性）。

    强到弱蒸馏 (Strong-to-Weak Distillation):

    强到弱蒸馏流程专门为优化轻量级模型而设计，包括5个密集模型（Qwen3-0.6B、1.7B、4B、8B和14B）和1个MoE模型（Qwen3-30B-A3B）。这种方法在增强模型性能的同时，有效赋予了强大的模式切换能力 。蒸馏过程分为两个主要阶段：

    1. 离线蒸馏 (Off-policy Distillation): 在初始阶段，结合教师模型在/think和/no think模式下生成的输出进行响应蒸馏 。这有助于轻量级学生模型发展基本的推理技能和在不同思维模式之间切换的能力 。
    2. 在线蒸馏 (On-policy Distillation): 在此阶段，学生模型生成在线序列进行微调 。具体来说，采样提示，学生模型以/think或/no think模式生成响应 。然后通过将学生的logit与教师模型（Qwen3-32B或Qwen3-235B-A22B）的logit对齐，最小化KL散度来微调学生模型 。

    通过评估Qwen3-32B模型在不同训练阶段的性能，报告得出结论：第三阶段将非思维模式整合到模型中，模型开始具备模式切换的初步能力 。第三阶段还增强了思维模式下的通用和指令遵循能力 。第四阶段进一步加强了模型在思维和非思维模式下的通用、指令遵循和Agent能力，确保了准确的模式切换 。

    然而，对于知识、STEM、数学和编码等任务，思维模式融合和通用RL并未带来显著改进，甚至在一些挑战性任务上，思维模式下的性能有所下降 。报告推测这种性能下降是由于模型在更广泛的通用任务上进行训练，可能会损害其在处理复杂问题时的专业能力，并表示在Qwen3开发过程中接受了这种性能权衡以增强模型的整体多功能性 。

    高级用法：

    我们提供了一种软切换机制，允许用户在 enable_thinking=True 时动态控制模型的行为。具体来说，您可以在用户提示或系统消息中添加 /think 和 /no_think 来逐轮切换模型的思考模式。在多轮对话中，模型会遵循最近的指令。

    未来发展：

    Qwen3 代表了我们在通往通用人工智能（AGI）和超级人工智能（ASI）旅程中的一个重要里程碑。通过扩大预训练和强化学习的规模，我们实现了更高层次的智能。我们无缝集成了思考模式与非思考模式，为用户提供了灵活控制思考预算的能力。此外，我们还扩展了对多种语言的支持，帮助全球更多用户。

    展望未来，我们计划从多个维度提升我们的模型。这包括优化模型架构和训练方法，以实现几个关键目标：扩展数据规模、增加模型大小、延长上下文长度、拓宽模态范围，并利用环境反馈推进强化学习以进行长周期推理。我们认为，我们正从专注于训练模型的时代过渡到以训练 Agent 为中心的时代。

    CTC 强制对齐-音频和文本

    CTC算法

    CTC算法的关键在于使用一个特殊的标记，通常称为空白标记（blank token）。这是一个我们人为加入词汇表的额外标记。在这个例子中，空白标记被表示为_。我们用这个特殊的标记来表示字母组之间的硬边界。

    CTC模型的完整输出类似于如下的序列：Copied

    B_R_II_O_N_||_S_AWW_|||||_S_OMEE_TH_ING_||_C_L_O_S_E||TO|_P_A_N_I_C_||_ON||HHI_S||_OP_P_O_N_EN_T_'SS||_F_AA_C_E||_W_H_EN||THE||M_A_NN_||||_F_I_N_AL_LL_Y||||_RREE_C_O_GG_NN_II_Z_ED|||HHISS|||_ER_RRR_ORR||||

    该序列中的|标记是单词分隔符。在这个例子中，我们使用|而不是空格作为单词分隔符，这样可以更容易地看出单词的分隔位置，但它们的作用是一样的。

    CTC空白标记使我们能够过滤掉重复的字母。例如预测序列中的最后一个单词，_ER_RRR_ORR。如果没有CTC空白标记，这个单词看起来是这样的：Copied

    ERRRRORR

    如果我们简单地去掉非CTC结果中的重复字符，那么它就变成了EROR。显然这不是正确的拼写。但是有了CTC空白标记，我们就可以在每个字母组中去掉重复的字母：Copied

    _ER_RRR_ORR

    变为：Copied

    _ER_R_OR

    最后我们去掉空白标记_，得到最终的单词：Copied

    ERROR

    如果我们将这种逻辑应用到整个文本，包括|，并将剩余的|字符替换为空格，那么最终的CTC解码输出会变成：Copied

    BRION SAW SOMETHING CLOSE TO PANIC ON HIS OPPONENT'S FACE WHEN THE MAN FINALLY RECOGNIZED HIS ERROR

    总结一下，CTC模型对应每20毫秒的输入音频（包括部分重叠）会生成一个预测标记。这样的预测规则会生成很多重复的字母。利用CTC空白标记，我们可以轻松地移除这些重复的字母，而不会破坏单词的正确拼写。这是一种非常简单和方便的方法，可以解决输出文本与输入音频的对齐问题。💡 在实际的Wav2Vec2模型中，CTC空白标记与填充标记“是相同的。模型会预测很多这样的“标记，例如当当前20毫秒的音频没有明确的字符可以预测时。使用相同的标记作为填充和CTC空白标记可以简化解码算法，并有助于保持词汇表的小规模。

    我们可以在Transomer编码模型简单地加入CTC：将编码器的输出序列进入一个线性层，该线性层将音频特征映射到词汇表。模型使用特殊的CTC损失进行训练。

    CTC的一个缺点在于，它可能会输出听起来正确但拼写不正确的单词。毕竟，CTC分类头只考虑了单个字符，而没有处理整个单词。我们可以使用额外的语言模型来提高音频的转录质量。这个语言模型实际上是作为了CTC输出的拼写检查器。

    CTC（Connectionist Temporal Classification）强制对齐是一种将音频与已知文本精确对齐的技术，广泛应用于自动字幕生成、语音切分、语音合成等领域。其核心原理结合了声学模型的输出和动态规划算法（如 Viterbi 算法）来实现字级别的时间戳对齐。

    核心原理

    1. 输入数据

    • log_probs：模型输出的对数概率张量，形状为 (B, T, C)，其中：
      • B：批次大小（当前仅支持 B=1）；
      • T：时间帧数；
      • C：字符集大小（包括 blank 符号）。
    • targets：目标文本的索引序列，形状为 (B, L)，其中 L 为目标序列长度。
    • input_lengths（可选）：输入序列的实际长度。
    • target_lengths（可选）：目标序列的实际长度。
    • blank：blank 符号的索引，默认值为 0。

    2. 对齐过程

    forced_align 函数通过动态规划算法（如 Viterbi）在所有可能的对齐路径中寻找概率最高的路径。该算法通过填充一个大小为 (S, T) 的矩阵（其中 S 是目标序列长度，T 是时间帧数），并记录每个状态的最优前驱，以便在填充完成后回溯得到最优路径。

    3. 输出结果

    • alignment：每个时间步对应的标签索引，形状为 (T,)。
    • scores：每个时间步对应标签的对数概率，形状为 (T,)。

    通过这些输出，可以确定每个字符在音频中的时间位置，实现字级别的对齐。

    🔧 实际应用

    为了简化强制对齐的流程，torchaudio 提供了高级 API torchaudio.pipelines.Wav2Vec2FABundle，该 API 集成了预训练的 Wav2Vec2 模型和 forced_align 函数，用户只需提供音频和对应的文本，即可获取每个词或字符的时间戳。该工具支持多语言对齐，适用于各种语音处理任务。

    MCP-大模型上下文协议

    MCP：大模型接入万物的通用协议，智能体时代的HTTP！

    一、什么是MCP（Model Context Protocol）

    定义

    MCP（Model Context Protocol，模型上下文协议） ，2024年11月底，由 Anthropic 推出的一种开放标准，旨在统一大模型与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

    Function Calling是AI模型调用函数的机制，MCP是一个标准协议，使大模型与API无缝交互，而AI Agent是一个自主运行的智能系统，利用Function Calling和MCP来分析和执行任务，实现特定目标。

    MCP 的价值

    举个栗子，在过去，为了让大模型等 AI 应用使用数据，要么复制粘贴，要么上传知识库，非常局限。

    即使是最强大模型也会受到数据隔离的限制，形成信息孤岛，要做出更强的大模型，每个新数据源都需要自己重新定制实现，使真正互联的系统难以扩展，存在很多的局限性。

    现在，MCP 可以直接在 AI 与数据（包括本地数据和互联网数据）之间架起一座桥梁，通过 MCP 服务器和 MCP 客户端，大家只要都遵循这套协议，就能实现“万物互联”。

    有了MCP，可以和数据和文件系统、开发工具、Web 和浏览器自动化、生产力和通信、各种社区生态能力全部集成，实现强大的协作工作能力，它的价值远不可估量。

    MCP 与 Function Calling 的区别

    • MCP（Model Context Protocol），模型上下文协议
    • Function Calling，函数调用

    这两种技术都旨在增强 AI 模型与外部数据的交互能力，但 MCP 不止可以增强 AI 模型，还可以是其他的应用系统。

    Function Calling

    数据安全性

    这样一个理想的“万物互联”生态系统看着很让人着迷。

    但是大家是不是担心通过 MCP Server 暴露出来的数据会泄露或被非法访问，这个头疼的问题 MCP 也考虑到了。

    MCP 通过标准化的数据访问接口，大大减少了直接接触敏感数据的环节，降低了数据泄露的风险。

    还有，MCP 内置了安全机制，确保只有经过验证的请求才能访问特定资源，相当于在数据安全又加上了一道防线。同时，MCP协议还支持多种加密算法，以确保数据在传输过程中的安全性。

    例如，MCP 服务器自己控制资源，不需要将 API 密钥等敏感信息提供给 LLM 提供商。这样一来，即使 LLM 提供商受到攻击，攻击者也无法获取到这些敏感信息。

    不过，MCP 这套协议/标准，需要大家一起来共建，这个生态才会繁荣，现在，只是测试阶段，一切才刚刚开始，当然，还会涌现出更多的问题。

    工作原理

    MCP 协议采用了一种独特的架构设计，它将 LLM 与资源之间的通信划分为三个主要部分：客户端、服务器和资源。

    客户端负责发送请求给 MCP 服务器，服务器则将这些请求转发给相应的资源。这种分层的设计使得 MCP 协议能够更好地控制访问权限，确保只有经过授权的用户才能访问特定的资源。

    以下是 MCP 的基本工作流程：

    • 初始化连接：客户端向服务器发送连接请求，建立通信通道。
    • 发送请求：客户端根据需求构建请求消息，并发送给服务器。
    • 处理请求：服务器接收到请求后，解析请求内容，执行相应的操作（如查询数据库、读取文件等）。
    • 返回结果：服务器将处理结果封装成响应消息，发送回客户端。
    • 断开连接：任务完成后，客户端可以主动关闭连接或等待服务器超时关闭。

    MCP 核心架构

    MCP 遵循客户端-服务器架构（client-server），其中包含以下几个核心概念：

    • MCP 主机（MCP Hosts）：发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 或 AI 工具）。
    • MCP 客户端（MCP Clients）：在主机程序内部，与 MCP server 保持 1:1 的连接。
    • MCP 服务器（MCP Servers）：为 MCP client 提供上下文、工具和 prompt 信息。
    • 本地资源（Local Resources）：本地计算机中可供 MCP server 安全访问的资源（例如文件、数据库）。
    • 远程资源（Remote Resources）：MCP server 可以连接到的远程资源（例如通过 API）。

    共分为了下面五个部分：

    • MCP Hosts: Hosts 是指 LLM 启动连接的应用程序，像 Cursor, Claude Desktop、Cline 这样的应用程序。
    • MCP Clients: 客户端是用来在 Hosts 应用程序内维护与 Server 之间 1:1 连接。
    • MCP Servers: 通过标准化的协议，为 Client 端提供上下文、工具和提示。
    • Local Data Sources: 本地的文件、数据库和 API。
    • Remote Services: 外部的文件、数据库和 API。

    整个 MCP 协议核心的在于 Server，因为 Host 和 Client 相信熟悉计算机网络的都不会陌生，非常好理解，但是 Server 如何理解呢？

    看看 Cursor 的 AI Agent 发展过程，我们会发现整个 AI 自动化的过程发展会是从 Chat 到 Composer 再进化到完整的 AI Agent。

    AI Chat 只是提供建议，如何将 AI 的 response 转化为行为和最终的结果，全部依靠人类，例如手动复制粘贴，或者进行某些修改。

    AI Composer 是可以自动修改代码，但是需要人类参与和确认，并且无法做到除了修改代码之外的其它操作。

    AI Agent 是一个完全的自动化程序，未来完全可以做到自动读取 Figma 的图片，自动生产代码，自动读取日志，自动调试代码，自动 push 代码到 GitHub。

    而 MCP Server 就是为了实现 AI Agent 的自动化而存在的，它是一个中间层，告诉 AI Agent 目前存在哪些服务，哪些 API，哪些数据源，AI Agent 可以根据 Server 提供的信息来决定是否调用某个服务，然后通过 Function Calling 来执行函数。

    MCP Client

    MCP client 充当 LLM 和 MCP server 之间的桥梁，MCP client 的工作流程如下：

    • MCP client 首先从 MCP server 获取可用的工具列表。
    • 将用户的查询连同工具描述通过 function calling 一起发送给 LLM。
    • LLM 决定是否需要使用工具以及使用哪些工具。
    • 如果需要使用工具，MCP client 会通过 MCP server 执行相应的工具调用。
    • 工具调用的结果会被发送回 LLM。
    • LLM 基于所有信息生成自然语言响应。
    • 最后将响应展示给用户。

    Claude Desktop 和Cursor都支持了MCP Server接入能力，它们就是作为 MCP client来连接某个MCP Server感知和实现调用。

    MCP Server

    MCP server 是 MCP 架构中的关键组件，它可以提供 3 种主要类型的功能：

    • 资源（Resources）：类似文件的数据，可以被客户端读取，如 API 响应或文件内容。
    • 工具（Tools）：可以被 LLM 调用的函数（需要用户批准）。
    • 提示（Prompts）：预先编写的模板，帮助用户完成特定任务。

    这些功能使 MCP server 能够为 AI 应用提供丰富的上下文信息和操作能力，从而增强 LLM 的实用性和灵活性。

    你可以在 MCP Servers Repository 和 Awesome MCP Servers 这两个 repo 中找到许多由社区实现的 MCP server。使用 TypeScript 编写的 MCP server 可以通过 npx 命令来运行，使用 Python 编写的 MCP server 可以通过 uvx 命令来运行。

    通信机制

    MCP 协议支持两种主要的通信机制：基于标准输入输出的本地通信和基于SSE（Server-Sent Events）的远程通信。

    这两种机制都使用 JSON-RPC 2.0 格式进行消息传输，确保了通信的标准化和可扩展性。

    • 本地通信：通过 stdio 传输数据，适用于在同一台机器上运行的客户端和服务器之间的通信。
    • 远程通信：利用 SSE 与 HTTP 结合，实现跨网络的实时数据传输，适用于需要访问远程资源或分布式部署的场景。

    二、MCP的功能与应用：

    如何使用 MCP

    如果你还没有尝试过如何使用 MCP 的话，我们可以考虑用 Cursor(本人只尝试过 Cursor)，Claude Desktop 或者 Cline 来体验一下。

    当然，我们并不需要自己开发 MCP Servers，MCP 的好处就是通用、标准，所以开发者并不需要重复造轮子（但是学习可以重复造轮子）。

    首先推荐的是官方组织的一些 Server：官方的 MCP Server 列表。

    目前社区的 MCP Server 还是比较混乱，有很多缺少教程和文档，很多的代码功能也有问题，我们可以自行尝试一下 Cursor Directory 的一些例子，具体的配置和实战笔者就不细讲了，大家可以参考官方文档。

    MCP的功能

    MCP通过引入多样化的MCP Server能力，显著增强了AI工具的功能，例如我们常用的Cursor和Claude。以下是一些官方参考服务器，展示了MCP的核心功能和SDK的应用：

    数据与文件系统：

    文件系统：提供安全文件操作，带可配置的访问控制。

    PostgreSQL：提供只读数据库访问，具备架构检查功能。

    SQLite：支持数据库交互和商业智能功能。

    Google Drive：实现Google Drive的文件访问和搜索功能。

    开发工具：

    Git：工具用于读取、搜索和操作Git仓库。

    GitHub：集成仓库管理、文件操作和GitHub API。

    GitLab：支持项目管理的GitLab API集成。

    Sentry：从http://Sentry.io获取并分析问题。

    网络与浏览器自动化：

    Brave Search：利用Brave的搜索API进行网络和本地搜索。

    Fetch：为LLM优化的网络内容获取和转换。

    Puppeteer：提供浏览器自动化和网页抓取功能。

    生产力和通信：

    Slack：支持频道管理和消息功能。

    Google Maps：提供位置服务、路线和地点详情。

    Memory：基于知识图谱的持久记忆系统。

    AI与专业工具：

    EverArt：使用多种模型进行AI图像生成。

    Sequential Thinking：通过思维序列进行动态问题解决。

    AWS KB Retrieval：使用Bedrock Agent Runtime从AWS知识库检索。

    官方集成工具：

    这些MCP服务器由公司维护，用于其平台：

    Axiom：使用自然语言查询和分析日志、跟踪和事件数据。

    Browserbase：云端自动化浏览器交互。

    Cloudflare：在Cloudflare开发者平台上部署和管理资源。

    E2B：在安全的云沙箱中执行代码。

    Neon：与Neon无服务器Postgres平台交互。

    Obsidian Markdown Notes：读取和搜索Obsidian知识库中的Markdown笔记。

    Qdrant：使用Qdrant向量搜索引擎实现语义记忆。

    Raygun：访问崩溃报告和监控数据。

    Search1API：统一的API用于搜索、爬虫和网站地图。

    Tinybird：与Tinybird无服务器ClickHouse平台交互。

    集成工具：

    Docker：管理容器、镜像、卷和网络。

    Kubernetes：管理pod、部署和服务。

    Linear：项目管理和问题跟踪。

    Snowflake：与Snowflake数据库交互。

    Spotify：控制Spotify播放和管理播放列表。

    Todoist：任务管理集成。

    三、怎么使用和开发MCP Server

    使用

    目前支持的部分工具列表（更多见这里）：