之前我讲过对于STT(Speech to Text)方案的使用体验，这次来讲一下对于高质量TTS的使用体验。
1、普通听感
TTS也是个挺早的领域了，大模型时代之前的TTS听感其实不算好，特别是很多场景就是图便宜、图自主可控。例如说滴滴司机端的TTS，相信很多人都听过，效果只能说能知道文本是啥，但我是不想用。
现在各大云服务商都有TTS，听感明显要好一些，例如Azure的TTS就被很多人推荐。现在各家也开始增加了带有感情的TTS功能。这一档的TTS其实已经算可以用了。不过Azure的付费门槛还是有的，有些视频就拿一个国产西游记孙悟空的嗓音进行配音，大概也有掩盖它使用的TTS听感较差的考虑。
更好的TTS是高端数字人定制的场景，例如《得到》万维钢专栏的配音已经从怀沙真人换成了怀沙AI，但我作为用户几乎听不出差异，这类就已经算是目前效果最好的方案了。
当然我对于语音的要求可能算相对低的，因为已经听惯了各种劣质的TTS。
2、音色的多样性
对我来说，目前TTS方案的一大问题是，音色多样性太低。从供给的角度上来说，各家TTS供应商的可选音色就那些，而且还有一些是像前面孙悟空那样很“特色”的音色。
从目前各平台上音视频的内容来看，音色的重复很普遍，很多时候我可以第一反应靠对音色的熟悉程度就意识到这是个TTS配音的，都还没到发现声音中的问题。
当然重复的TTS音色能满足最低下限的需求，但对于用户来说，我感觉这是明显能感知到的体验瑕疵。感觉说不定以后会出现像之前肥皂剧与高帧率观影体验绑定的情况——在用户心智中大量使用的TTS音色与低质量的内容相绑定。
当然现在各家TTS厂商都已经开始提供音色克隆，但它尚不能完全满足本节的需求：
但从音色的多样性来说，其实并不需要很像原声音，需要的是多样性，消除那种重复感。特别是在模拟多人对话的场景下，需要有差异性的音色来让用户区分不同的说话人。
所以目前的音色克隆其实并不能满足上述这类需求。目前我看到只有两类方案相对接近这个需求：
以前者为例，FishAudio、CosyVoice等就可以根据短参考音频进行TTS，但是：
所以如果追求音色的多样性、并兼顾成本和综合效果，我目前看到的大概只有Minimax的音色生成。但它的可控性也不太好，如何生成prompt是个问题，而且经常生成与期望的原始音频听感差异很大的结果，例如期望是一个中年人，但最终音色总是听起来偏年轻。
最近播客的生成开始成为热点，在播客生成的场景下，目前的方案说实话我觉得都不是很适合。理想的情况应该是：提供单独的接口，输入所有说话人的内容并标记说话人；每个说话人提供参考音色。输出效果并不追求完美复刻说话人原始音色，因为这会有滥用风险，但应该追求大致类似原参考音频，并与其他说话人的音色要有明显的听感差异。在提供多人多轮对话的场景下，也能够更好地来做不同人之间的停顿、情绪匹配等等。这些靠目前每次只生成一个人的音频然后拼起来的方式很难实现。
3、特殊文字的读法
同STT一样，只有在实际场景中使用后，才能意识到语音也是一种语言，具有语言的复杂性。
例如说：
CosyVoice在配中文的时候，不会读英文，只会一个一个字母念。这就导致了对于混英文人名、术语等的内容直接一票否决，老老实实去用调教更认真的商用API。
Minimax的TTS对于“5,000”这样的数字会读作“五零”，因为它把数字中的分隔符当成了逗号。
当然Minimax可以在输入的时候对于文字的读音进行干预，但连常见的数字写法都不会正确朗读，可见它在这方面的处理也很欠缺，把大量这方面工作甩给了API调用者。
实际上文字中还有各种读法和写法不同的内容，例如：80/20（来自80-20法则）、“3:2”（比例）、日期的各种格式……要是认真处理的话，这可能不是应该靠规则处理的了，而是要先用LLM做类型识别，然后转相应的读法。
而很明显，目前的TTS还没有达到先用LLM做预处理的程度。
4、写法和读法的转换 与 新词的处理
正如前面所举例的，实际上读法和写法可以当成是两个不同的语言，他们之间需要认真地进行转换才能实现一个较好的效果。
即使是目前STT最好的Azure，在做数字读法到写法的转换中，也时常会遇到一些明显的硬规则导致的错误case。
是否应该引入一个中间的读法表示层是可以选择的。但我想说即使是追求端到端方案的人，也需要认真地去合成数据来针对性训练端到端模型的短板问题，而不是以这是个端到端模型为挡箭牌，放任常见的badcase无所作为。
在STT方面，由于新词的持续出现，想要完全端到端是很难的，现在各大STT API厂商也都不得不支持热词配置。（但说实话从目前热词配置API的难用程度和各种限制来说，真的在用这些功能的用户应该不多）
现在STT方面让用户来配置热词已经是行业习惯，但我并不认为这是对的。我目前主推Azure的STT也是因为它在一些新词和术语的自动处理上明显好于其他。
如果把语音也看成一种语言，那这方面可以对标LLM生态。LLM Chatbot会让用户教他一个概念吗？从产品的角度上应该是Chatbot自己调用搜索，产品内有自己的通用知识库，大部分的情况应该有产品方解决，而且也只有产品方（而不是用户）才能分摊这个成本。LLM API方面似乎更慢一点，如果不是模型内已有的知识，还是需要在prompt中注入/调用搜索tools/RAG等来解决。但由于LLM包含的庞大知识量，很多时候并不需要靠用户进行额外指定。而且LLM的供应商知道要更新数据，知道这是自己的职责，而不是把它推给用户。反观STT和TTS，我目前没有看到他们有向用户说明他们在持续的更新数据，以应对不断出现的新词。
5、场景TTS 与 音频生成
第2节末尾的多人对话TTS接口可以进一步推广，扩展成对于常见场景的TTS，甚至是通用的音频生成。
举个例子，如果认真观察多人访谈的录像，就会发现其中有不少细节不能靠目前简单的单人TTS结果进行合成。例如：
两个说话人切换的时间间隔与内容有关，特别是在有人抢话的时候，经常会有一点重叠，也就是负时间间隔。
其他人可能会进行简单的附和、“是”、笑等等反应，时间上也可能会与当前发言人重叠，但又不是简单的发言。
在讨论等场景下，每个说话人的音调、语气、语速等都会与上一个说话人的内容有关。
这些都是需要一个更“端到端”的生成多人对话的音频方案才能实现的，而不是现在给每个说话人进行切片生成。
当然沿着这个思路下去，未必要只做对话，可以像视频领域一样，根据类似分镜头脚本的指令来直接生成完整音频，这很“端到端”。
当然现在无论是分层分阶段、还是端到端都可以做，但关键还是要将效果做到用户能接受的最低水平。无论是规则还是端到端，做出来的垃圾我们都看得太多了。甚至可以说，打着端到端旗号做出来的劣质产品更多，因为这条路线的“门槛低”。现在来看，端到端大模型并没有解决本质问题，只是把问题转移到了针对性的数据合成方面，而这个数据合成流程又和传统分阶段的方案有共性。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，获取联系方式请点击 -> 联系方式。
本文于2024.11.13首发于知乎与微信公众号
知乎链接 https://zhuanlan.zhihu.com/p/6626396338
