本文梳理了严重影响日语文本转语音(TTS)质量的音调重音问题,并提出了一种结合最小音对(MOS)、自动化G2P工具和人工标注最小音对数据集的多层评估方法。此外,本文还阐述了在本地部署TTS系统时,许可、质量和硬件之间的平衡问题。
发布日期:2026年5月
TTS领域的格局每六个月都会发生变化。本文中的技术判断截至发布日期,并将定期更新。
--
引言
近年来,基于语言学习模型(LLM)的文本转语音(TTS)模型发展迅猛。ElevenLabs、Google Cloud TTS、Azure Speech 等平台如今都能生成英语及多种语言的自然语音。
然而,任何经常使用日语合成语音的人都可能遇到过这种情况:“为什么这语音听起来不太自然?”“发音是对的,但意思好像不一样……”
造成这种情况的罪魁祸首通常是音调重音。
本文将梳理音调重音问题,该问题会显著影响日语 TTS 的质量,并从 SolanaLink 的实践经验出发,分享量化评估语音准确度的方法。
--
什么是音调重音?它为何如此重要?
同音异义
日语(基于东京方言的标准日语)有一套称为音调重音的系统。高音和低音的音调模式可以区分词义。
以下是一些典型的最小对立词:
| 単語 | アクセント型 | 意味 |
|---|---|---|
| 雨 | HL(頭高型) | rain |
| 飴 | LH(平板型) | candy |
| 橋 | LH | bridge |
| 箸 | HL | chopsticks |
| 神 | HL | god |
| 紙 | LH | paper |
音素(元音和辅音)相同。只有音调的变化不同。这是日语的一个特点,因为它决定了词义本身。
与英语使用者和一些亚洲语言使用者的区别
英语也有重音,但它没有“通过音调区分词义”的系统。因此,当母语为英语的工程师评估TTS模型时,他们经常会忽略音调重音错误。
声音是可以听出来的,意思也可以从上下文推断出来。然而,对于日语使用者来说,感觉就像**“说了另一个词”**——这是最大的差距。
为什么TTS模型普遍存在错误?
许多现代的大规模TTS模型都使用大量的多语言语音数据进行训练。英语、中文、西班牙语……其中,日语的训练数据相对较少,因此存在每个词的音调重音模式无法被准确学习的情况。
结果,出现了以下现象:
-
本来应该是“It's raining”,听起来却像“It's raining candy”。
-
“Crossing the bridge”听起来像“Crossing chopsticks”。
-
专有名词、外来词和专业术语的重音变得模糊不清。
这些错误在一般的语音导航或文本转语音应用中可能仅被视为“略微奇怪”。然而,根据应用场景的不同,它们可能至关重要。
-
语言学习材料(学习者可能会记住错误的发音)
-
客户服务语音应答(损害品牌信誉)
-
医疗、法律和金融等领域的商业语音,在这些领域,任何误解都是不可接受的
评估的难点:如何衡量“正确性”
假设我们承认音调重音的重要性,那么接下来我们将面临评估问题。
简单的 MOS(主观评估)无法体现的内容
目前最常用的 TTS 质量评估方法是平均意见得分 (MOS)——一种 5 分制的主观评估。然而,MOS 衡量的是整体听起来是否自然,而无法单独衡量重音是否正确。
尤其需要注意的是,如果评估者并非日语母语者,重音错误可能很难在得分中体现出来。仅仅“听起来流利”就很容易获得 4.0 以上的分数。
与自动 G2P 工具比较的“自我反思陷阱”
接下来要考虑的方法是与自动音素转换 (G2P) 工具进行比较。在日语中,pyopenjtalk 就是一个典型的例子,它会在输入文本后返回带有重音信息的音素序列。
入力: 雨が降る
pyopenjtalk の出力(簡略化): a:HL me:LL ga:L fu:LH ru:LH分析 TTS 生成的语音并自动检查其是否与 pyopenjtalk 预测的重音模式匹配——乍一看似乎合情合理。
然而,这里存在一个结构性问题。
**由于 pyopenjtalk 本身就是一个模型,它必然存在误差。**对于词典中不存在的单词、新词以及上下文相关的重音变化(复合词、与助词的互动),pyopenjtalk 的预测并非总是正确的。
那么会发生什么呢?
-
一个完美的 TTS 可能会做出与 pyopenjtalk 不同的判断,从而被评为低分。
-
一个完美复现 pyopenjtalk 错误的 TTS 却会被评为高分。
这是一个典型的“用模型 B 来评估模型 A”的自指陷阱,评估结果将变得完全不可靠。
实用解决方案:手动标注的最小对数据集
SolanaLink 正在考虑以下方法来解决这个问题:
- 核心评估将使用手动标注的“无可争议的最小对”进行。
-
准备 50-100 个日语母语者可以立即判断重音类型的词对,例如 rain/candy、bridge/chopsticks、god/paper、sake/salmon。
-
这将作为绝对正确答案。
- 使用 pyopenjtalk 作为补充指标。
-
利用其高速处理大量文本的优势,将其用于回归测试(“是否回归到之前通过的案例?”)。
-
然而,与 pyopenjtalk 的一致性率不会作为唯一的合格标准。
- 根据目标用途扩展评估集。
-
对于语言学习,使用初级到中级常用词汇。
-
对于商务语音,使用行业术语和专有名词。
-
这种扩展过程本身就体现了项目的独特性。
- MOS 仅在每月的大型里程碑节点实施。
-
使用 5 位或更多日语母语评估员。
-
每次学习重复都进行评估,无论从时间还是成本上来说都不切实际。
-
每日自动评估将基于音调重音的准确性。
为什么“本地/部署”方案正在兴起
以下是我们从 SolanaLink 客户那里收到的另一个常见问题:我们不想将自己的数据和语音数据发送到基于云的 TTS 系统。
-
我们希望根据客户交互日志创建合成语音,但我们不想将语音数据委托给第三方。
-
由于公司内部政策的限制,将包含专业医学和法律术语的文本发送到云端非常困难。
-
费用是按字符计费,因此难以预测长期运营成本。
为了满足这些需求,在本地或边缘环境中运行的 TTS 系统(利用最新的开源 LLM-TTS 模型)正逐渐成为一个切实可行的选择。
然而,本地部署的 TTS 系统也面临着以下独特的挑战:
-
许可:模型代码和权重(训练参数)通常需要单独授权,因此需要仔细核实商业使用权。
-
日语语言质量:面向全球的开源模型在日语语言质量方面往往存在不一致,尤其是在音调重音方面。
-
硬件:最佳配置因操作系统环境而异,包括 Apple Silicon、NVIDIA GPU 和纯 CPU 系统。
虽然本文重点讨论音调重音,但这些问题相互关联,最终构成一个多维度的优化问题:“运行一个语法正确、拥有商业许可且硬件成本可接受的日语文本转语音 (TTS) 系统。”
总结
-
音调重音是影响日语文本转语音(TTS)质量的一个常被忽视但影响显著的因素。
-
仅使用常用的MOS或自动化G2P工具进行语速匹配不足以充分评估重音准确度。
-
实际上,采用多层评估方法更为现实,该方法以**最小成对数据集(含人工标注)**为核心,使用pyopenjtalk进行回归测试,并将MOS作为每月里程碑。
-
随着对本地部署TTS的需求不断增长,平衡许可、日语语言质量和硬件的设计变得至关重要。
来自 SolanaLink 的信息
SolanaLink 提供语音合成(主要针对日语)的实施支持,并支持构建自定义模型。我们尤其在以下领域提供咨询服务:
-
基于商业许可的开源 TTS 模型选择
-
音调重音质量的量化评估设计
-
TTS 在本地/混合环境中的运行
-
开发行业专用发音词典(医疗、法律、教育、金融等)
我们欢迎您就内部概念验证 (PoC) 的考虑、现有 TTS 系统切换评估以及自有品牌语音的开发进行咨询。请随时通过以下渠道联系我们。
注:信息有效期
本文提及的技术判断(评估方法、开源软件模型现状等)截至2026年5月。技术转语音(TTS)领域瞬息万变,相关假设可能在六个月内发生变化。在做出任何重要决定之前,请务必查阅最新信息或联系我们。
注:信息有效期
本文提及的技术判断(评估方法、开源软件模型现状等)截至2026年5月。
参考资料
-
关于日语音调重音的语言学背景,请参阅小泉文雄的《日本之声》以及角田忠信的一系列研究。
-
pyopenjtalk(日语 G2P + 重音提取库):https://github.com/r9y9/pyopenjtalk -
JSUT 语料库(日语 TTS 研究语音数据库):https://sites.google.com/site/shinnosuketakamichi/publication/jsut
-
JVS 语料库(多说话人日语语音数据库):https://sites.google.com/site/shinnosuketakamichi/research-topics/jvs_corpus
本文由 SolanaLink 的工程师 Tony 撰写。欢迎评论和提问。

コメント
コメント (0)