做中文TTS评测这些年，我经常被问到同一个问题——"这个声音听起来像不像真人"。这个问题看着简单，真拆开就复杂了。我自己的理解是，"自然度"不是单一维度的感受，它至少包含四个层次的东西：发音准不准、韵律顺不顺、情感到不到位、听久了耳朵累不累。这几个维度之间有时候还会打架，某个模型发音字正腔圆但语调平板得像念课文，另一个模型情绪饱满却偶尔冒出个错别字音，你说哪个更自然？用户场景不同，答案就变了。
发音准确度是最基础的门槛。中文的多音字、生僻字、专有名词，哪一样都能让合成声音翻车。我见过一个模型在新闻测试集上表现挺好，换到医疗文本里"血压"的"压"读成了一声，整句话的信任感就没了。韵律流畅度是第二层，它管的是停顿、重音、语速变化这些节奏问题。同样一句话，停顿位置差半拍，听感就从"播音员"掉到"机器人"。情感表现力和听感舒适度更微妙一些，前者关乎情绪迁移是否自然，后者涉及音质是否干净、长时间听会不会产生疲劳感。我个人的经验是，前两项决定"能不能用"，后两项决定"愿不愿意一直用"。
评测自然度这件事，行业里有一套相对成熟的工具箱。主观MOS评分是最常用的，找一批听测者按1到5分打分，简单直接。CMOS做对比测试时更好用，让听众判断A和B哪个更自然，能规避不同人打分尺度不一致的问题。ABX偏好测试则适合做盲测场景下的细粒度比较，强制二选一往往能逼出真实偏好。客观指标这边，MCD、F0 RMSE、时长偏差这些声学参数能给工程侧提供参考，但它们和人类听感之间的相关性始终是个老大难问题。我的做法是主观为主、客观为辅，两套数据交叉验证，单看任何一边都容易得出片面结论。
中文场景的评测难点，我觉得可以总结成"四个坑"。第一个是多音字，"行长"到底读hang还是xing，脱离上下文谁也说不准。第二个是轻声和儿化，"东西"和"东西儿"在语感上完全两回事，模型经常处理得生硬。第三个是语调边界，中文的句调变化比很多语言都复杂，疑问句末尾的上扬幅度差一点，听起来就像在审问而不是在询问。第四个是长文本稳定性，几百字以上的段落合成下来，有的模型前半段还行，后半段就开始出现吞音、重复、节奏漂移。方言口音这个事更麻烦，普通话测试集上表现优秀的模型，遇到带口音的文本或需要合成方言风格语音时，往往力不从心。我测评时会专门设计一组"陷阱文本"，把这些坑都埋进去。
建立可比对的测评框架，是我认为最容易被忽视却最关键的一步。测试文本集要覆盖新闻、对话、文学、专业术语等不同文体，每种文体至少准备几十条样本。发音人覆盖要考虑男女老少、不同音色类型，不能只拿一个"标准播音腔"打天下。听测样本设计上，我习惯把同一句话的不同模型版本随机打乱顺序，避免听测者产生顺序偏见。评分维度最好拆细一点，发音、韵律、情感、音质分开打分，最后再加一个整体自然度。统计口径要提前定好，是取均值还是看中位数，异常值怎么处理，这些细节不提前说清楚，不同批次的数据就没法横向比较。我吃过这个亏，早期测评没统一口径，回头想复盘发现数据对不上，只能重来一遍。
2.1 主流中文TTS产品与模型盘点
我做这个测评之前，先花了两周时间把市面上能摸到的中文TTS方案捋了一遍。范围大概分三块：云服务、开源模型、端侧方案。云服务这块，阿里云、腾讯云、讯飞、百度智能云、火山引擎这几家是绕不开的，基本上做中文语音合成的团队都会拿它们做基线。开源这边，ChatTTS、CosyVoice、Fish Speech、GPT-SoVITS这几个在社区里热度很高，我挨个拉了代码跑了一遍。端侧方案相对特殊，像一些芯片厂商自带的离线TTS引擎，还有手机系统里内置的语音助手音色，我也纳入了对比视野。
界定这个范围的时候我其实纠结过。云服务和开源模型放在一起比，公平吗？云服务背后是成规模的训练数据和工程优化，开源模型更多是社区迭代的产物，资源投入不在一个量级上。我最后还是决定放在同一套框架下测，理由很简单——用户不关心你是什么出身，他们只关心实际听感。端侧方案我单独标注了出来，因为它的延迟优势和算力限制是绑定的，跟云端方案比自然度的时候得把这个前提说清楚。
我选的这些方案里，有几个是明确面向中文优化的，也有几个是多语言通用模型顺带支持中文。这个差异在测评里体现得很明显。专门做中文优化的模型，在多音字和轻声处理上普遍稳一些，通用模型则在音色多样性和情感迁移上更有想象力。我把产品分成了"云服务组"、"开源组"和"端侧组"三条线来记录数据，后面所有的对比结果都是在这个分组框架下展开的。
2.2 主流中文TTS自然度对比测评设计
测评设计这块我花的心思最多。文本集是我自己攒的，大概分四类：新闻通稿、长篇小说片段、日常对话脚本、专业领域文本。每类选了三十到五十条，长度从十几个字到五六百字不等。采样条件统一用48kHz、单声道、无后处理，所有模型都走一遍相同的文本，避免因为参数不一致导致结果偏差。盲测流程上，我把每个模型的输出随机编号，听测者不知道哪段音频对应哪个模型，评分表里只有编号和文本内容。
听测人员我找了十二个，背景尽量拉开——有做语音算法的工程师，有普通用户，还有两个是播音主持专业的。这样组合的原因是，专业耳朵能听出韵律细节，普通耳朵反映的是真实听感，两边数据对照着看才有意思。评分维度拆成了发音准确、韵律自然、情感表达、音质干净、整体自然度五项，每项1到5分。我特意加了一个"是否愿意持续使用"的选项，这是个二元判断，用来捕捉那些单项分数不错但整体体验劝退的情况。
流程上有个细节我想提一下。每段音频听测者最多听三遍，听完必须立刻打分，不允许反复回听。这个规则是我从早期测评里总结出来的教训——回听次数越多，听测者越容易陷入对细节的过度分析，反而偏离了真实使用场景下的第一印象。整套测评跑下来大概用了三周，中间穿插了两轮校准测试，确保不同批次的听测者评分尺度基本对齐。
2.3 通用朗读场景自然度对比：新闻播报、长文阅读、数字与专有名词处理表现
新闻播报这个场景，几家云服务的表现确实稳。讯飞和阿里云的新闻音色，断句位置准，重音落点也符合播音习惯，听下来有一种"这事儿它练过"的感觉。腾讯云和火山引擎紧随其后，差距主要体现在数字和专有名词的处理上。我拿"2024年GDP同比增长5.2%"这种句子测，有的模型把"5.2%"读成"五点二百分比"，有的读成"百分之五点二"，后者明显更顺耳。百度智能云在这块表现中规中矩，个别长句的尾音收得有点急。
长文阅读是最能拉开差距的环节。我用了五千字左右的科普文章做压力测试，开源组里CosyVoice前半段表现相当惊艳，韵律起伏接近真人朗读，但到三千字之后开始出现轻微的节奏漂移，句子之间的停顿变得机械。ChatTTS的稳定性反而更好一些，虽然单句的韵律精细度不如CosyVoice，但通篇听下来没有明显的"崩坏点"。云服务组在这个环节整体占优，长文本的一致性控制得更到位，不过我也注意到，个别模型在段落切换处的语气衔接略显生硬，像是每段单独合成再拼起来的。
专有名词这块，我专门设计了一组"陷阱文本"，里面塞了人名、地名、化学名词、英文缩写混排的句子。结果挺有意思——开源模型在生僻字上翻车的概率明显高一些，有个模型把"嘌呤"读成了"piāo lìng"，还有一个把"长三角"的"长"读成了zhǎng。云服务组的多音字错误率低不少，但也不是零失误，遇到"银行行长"这种连续多音字组合时，仍有模型会读错其中一个。数字处理上，年份、百分比、小数、电话号码这几类，各家的规则覆盖程度不一样，有的模型对"幺"和"一"的区分很讲究，有的就一律读"一"，在电话号码场景下听感差异很大。
2.4 对话与交互场景自然度对比：口语化表达、停顿节奏、疑问语气与响应自然度
对话场景的测评，我换了一套文本，全是口语化的短句，带语气词、带省略、带打断。这个场景下，传统云服务的短板暴露得比较明显。它们的音色听起来像是"在朗读对话"而不是"在说话"，句尾的语调处理太规整，缺少那种随口一说的松弛感。火山引擎和腾讯云在这方面做了一些优化，加入了口语化的韵律模板，听感上比标准播音腔松弛不少，但离真正的日常对话还有距离。
开源模型在这个场景里反而有惊喜。ChatTTS的对话感是我测下来最接近真人的，它的停顿位置经常出人意料但又合理，疑问句末尾的上扬幅度也拿捏得比较自然。我拿"你今天到底去不去啊"这句话测，ChatTTS读出来的语气带着一点催促和不耐烦，而好几个云服务模型读得像在播报通知。Fish Speech的表现也不错，情绪偏中性一些，胜在稳定，不会出现突然的语气跳变。GPT-SoVITS我试了几个社区音色，个体差异很大，调得好的版本对话感很强，调得一般的版本会有明显的机械感。
疑问语气和响应自然度这两个细项，我单独拎出来说了。中文的疑问句尾音变化很微妙，上扬多了像质问，上扬少了像陈述。测评里我准备了选择疑问句、反问句、一般疑问句各十条，让听测者判断"这句话听起来像不像在问问题"。云服务组在一般疑问句上表现稳定，反问句就参差不齐了，有的模型把反问读得跟正问一模一样，失去了那层反讽意味。响应自然度这块，我模拟的是智能客服场景，让模型合成"好的，我帮您查一下"这类短应答，重点听开头第一个字的起音是否干脆、中间是否有不自然的拖腔。这个环节端侧方案的表现让我有点意外，虽然音质不如云端干净，但短句的起承转合反而更利落，没有那种"憋着一口气读完"的感觉。
2.5 情感与风格化场景自然度对比：多情感迁移、角色化音色与情绪一致性
情感迁移这个维度，我测的是同一句话在不同情感标签下的表现。文本用的是"你真的要走了吗"这种本身带有情绪张力的句子，分别指定开心、悲伤、愤怒、惊讶四种情感。云服务组里，讯飞和阿里云的情感切换比较平滑，悲伤和开心的区分度明显，愤怒和惊讶之间偶尔会混淆。开源组的表现分化严重，CosyVoice的情感迁移能力让我印象深刻，悲伤语调里的气声和放缓的语速处理得很细腻，但换到愤怒情感时，音量上去了，音色却有点劈。
角色化音色这块，我选了几个典型的角色设定——沉稳大叔、活泼少女、温柔旁白、磁性男声。云服务商普遍提供了预置的角色音色库，质量整齐，但个性偏弱，听多了会觉得"这几个角色长得差不多"。开源社区的音色就野多了，GPT-SoVITS的克隆音色在角色化上空间很大，我试了一个评书风格的音色，那种抑扬顿挫的劲儿特别到位，但情绪一致性就顾不上了，同一段文本里前一句还在慷慨激昂，后一句突然平淡下来。
情绪一致性是我这次测评里新增的观察项。具体做法是让模型合成一段三百字左右的多情绪文本，文本本身有情绪起伏，看模型能不能在整段里保持情绪线索的连贯。这个测试淘汰了不少方案。有的模型单句情感很到位，连起来听就像几个人在轮流说话，情绪断层明显。端侧方案在这个环节基本放弃治疗，情感表现普遍扁平，但换个角度想，端侧场景本来就不太追求情感丰富度，稳定和低延迟才是它的主场。我把这个差异在报告里单独标注了，免得读者拿端侧的情感分数去跟云端硬比。
2.6 测评结果解读：不同模型自然度优势边界、稳定性差异与常见失真问题
把所有数据摊开来看，我的整体判断是——没有全能选手，只有场景适配。云服务组在通用朗读和长文本稳定性上优势明显，发音准确率和韵律规整度都靠前，代价是对话场景的松弛感不足，情感表达的个性偏保守。开源组在对话感和情感迁移上更有锐气，ChatTTS和CosyVoice在特定场景下能打出接近真人的听感，短板是稳定性，长文本后半段的质量滑坡是普遍现象。端侧组我不拿它跟云端比综合分，它的价值在于延迟和离线可用性，自然度够用就行。
稳定性差异这个事，我想多说两句。测评里我设置了一个"重复合成一致性"的检查，同一段文本让同一个模型合成三次，看三次输出之间的声学差异有多大。云服务组的三次输出几乎一致，开源组里有的模型三次结果在语速和停顿上就有肉眼可见的波动。这个差异对工程落地影响很大——你做产品不可能接受同一个按钮点三次出来三种语气。开源模型要上生产，后处理和后端稳定性加固是绕不过去的坎。
常见失真问题我归类了一下，大概有这么几种：吞音（句尾字发音不完整）、重复（某个字或词被重复合成）、节奏漂移（长句中后段语速突然变化）、音色跳变（同一段内音色前后不一致）、机械重音（重音位置不符合语义逻辑）。云服务组的失真主要集中在机械重音和个别多音字上，开源组的失真类型更分散，吞音和节奏漂移出现频率更高。我把每种失真的出现场景和触发条件都记了下来，这些记录对后面做优化归因很有用——很多问题不是声学模型本身的锅，文本前端的处理规则没覆盖到，后面怎么调都白搭。
3.1 基于自然度对比结果的选型方法
测评数据出来之后，好几个朋友跑来问我同一个问题：到底选哪家。我每次都反问他们，你拿TTS干什么用。这个问题的答案直接决定了选型方向。做有声书和做智能客服，对自然度的要求根本不在一个维度上。有声书要的是长文本稳定性和情感表现力，音色可以慢慢挑，但读到第四十分钟不能崩。智能客服要的是短句响应快、起音干脆、多轮对话不露馅，情感丰富度反而是次要的。我把这个思路整理成了一个决策矩阵，横轴是场景需求，纵轴是成本、延迟、音色可控性和自然度短板容忍度。
成本这块我得单独说说。云服务按调用量计费，量大之后账单很吓人，开源模型看似免费，但部署、调优、运维的人力成本折算进去，未必便宜多少。我见过一些团队冲着开源免费去，结果搭进去两个算法工程师调了三个月，最后自然度还是没达到业务线的基本要求。延迟这个维度也很有意思，云端方案再快也有网络往返，端侧方案延迟能压到几十毫秒，但音色选择和自然度上限就摆在那儿。我的建议是先把自己的业务场景按”延迟敏感度”和”自然度敏感度”打个分，两个分数交叉一下，筛选范围能缩小一大半。
音色可控性是我在选型里加的一个权重项。有些团队需要定制品牌专属音色，这时候开源方案的优势就出来了，GPT-SoVITS这类工具用几十句录音就能克隆出一个可用的音色。云服务商虽然也提供定制音色服务，但门槛和周期都不一样，有的要几千句语料，有的要签年度框架。可控性还包括情感调节的颗粒度——能不能单独控制语速、音高、情感强度，这些细节在Demo阶段感知不强，真到产品调优的时候天天要用。我一般建议团队在选型阶段就把这些控制接口摸一遍，别等接入了才发现某个关键参数调不了。
3.2 自然度短板归因与优化路径
第二章里我记录的那些失真问题，后来我花了不少时间做归因。吞音和重复这类问题，很多时候根源在文本前端。中文的分词、多音字消歧、数字规范化，这一层没做好，声学模型再强也救不回来。我拿”银行行长”这个经典例子测过好几个方案，有的模型在分词阶段就把”行长”切错了，后面读出来必然是错的。优化路径很明确——把文本前端当作独立模块来打磨，建一个业务场景的多音字词表，用规则加模型双重校验，比单纯指望端到端模型自己学会要靠谱得多。
韵律建模这块的短板更隐蔽。云服务组的韵律规整度高，但规整过头就变成了播音腔，对话场景下那种松弛感出不来。开源组反过来，韵律有灵气但稳定性差。我试过一个折中的做法，在开源模型上叠加一层轻量的韵律后处理，用规则约束句尾语调和停顿上下限，听感上能拉回一些稳定度，又不至于把灵气全磨掉。声学模型和声码器的协同改进是另一个方向，我注意到有些模型的音质问题其实出在声码器上，梅尔频谱预测得不错，声码器重建时高频细节丢了，听起来就发闷。换个声码器或者做联合微调，有时候比重新训声学模型见效更快，这个思路我在几个项目里验证过，性价比很高。
归因这件事我越来越觉得是个系统工程。同一个”听起来不自然”的反馈，可能是文本前端的锅，可能是韵律模型的锅，也可能是声码器的锅，甚至可能是三者的叠加效应。我现在的习惯是拿到一个bad case先做分层排查，从文本输入一路查到波形输出，把问题定位到具体环节再动手。盲目调声学模型参数是最费时间且收效最差的做法，我在这上面交过学费。
3.3 中文TTS自然度评测的落地建议
测评做完一次就束之高阁，这是我最不愿意看到的情况。自然度这件事是动态的，模型在迭代，业务语料在变化，用户耳朵的期待也在往上走。我的建议是把盲测做成常态化的机制，不用每次都搞十二个听测者的大阵仗，小团队三五个人定期跑一轮就行，关键是保持节奏，积累纵向数据。我自己的做法是每个月抽半天时间，用当月业务里真实出现的文本跑一轮快速盲测，记录MOS趋势，这个习惯坚持了半年多，帮我提前发现了好几次模型更新带来的自然度回退。
业务语料回归是另一个容易被忽略的环节。公开测试集上的分数再漂亮，跟你的实际业务文本可能完全不搭边。我做项目的时候会建一个业务语料库，把线上真实请求里的文本脱敏后抽样存下来，每次模型变更都拿这个库跑一遍回归。这个库不需要很大，几百条典型文本就够用，覆盖业务里的高频句式、专有名词和边界情况。有一次我们换了一个新版本的TTS服务，公开指标全线提升，结果业务语料回归发现医学术语的多音字错误率翻了一倍，及时拦住了这次上线。
用户反馈闭环听起来像句套话，落地的时候其实很具体。我在产品里加了一个轻量的听感反馈入口，用户听到不自然的句子可以一键标记，后台把标记的文本和音频存下来，定期分析。这个机制跑起来之后，我收到过一条反馈说某个地名读错了，一查发现是多音字词表没覆盖到，补进去就解决了。用户耳朵比任何测试集都刁，他们每天在真实场景里听，能捕捉到测评环境里漏掉的问题。把这些反馈接进迭代流程，自然度优化的方向就不会跑偏。
3.4 中文语音合成自然度发展趋势
大模型TTS这两年的进展确实快。基于大语言模型架构的语音合成方案，在韵律自然度和情感表现力上展现出了跟传统方案不太一样的潜力。我试过几个基于大模型思路的开源项目，它们在处理长文本时的上下文连贯性明显好于传统的拼接式或参数式方案，句子之间的语气衔接更顺滑。这个方向我还在持续观察，目前的短板主要在推理成本和稳定性上，但迭代速度很快，值得押注。
个性化音色这块，零样本克隆的技术门槛在快速下降。以前定制一个音色要录几千句，现在几十秒的参考音频就能克隆出可用效果，这个变化对中小团队来说是利好。我注意到社区里已经有人在做”音色市场”这种形态，用户上传一小段录音就能生成自己的专属音色。这个趋势往下走，可能会改变TTS产品的交互设计思路——音色从”选一个”变成”造一个”，产品经理得提前想好怎么承接这种个性化需求。
低延迟端侧方案我一直觉得被低估了。云端方案的自然度上限确实更高，但很多场景不需要那么高的上限，够用加上快就够了。芯片算力在涨，端侧TTS的自然度每年都在往上走，我测过几个最新的端侧引擎，短句的自然度已经接近两年前的云端水平。车载、穿戴、智能家居这些场景，端侧方案的实时性和隐私优势是云端替代不了的。
可信评测体系这个话题我想放在最后说。现在各家都在报自己的MOS分数，评测口径五花八门，横向对比的可信度不高。我期待看到更多公开的、可复现的中文TTS评测基准出现，测试集、听测流程、统计方法都透明，大家拿同一把尺子量。这件事靠单个团队做不成，需要社区合力。在那之前，我建议选型的时候别太迷信厂商报的分数，自己搭个小测评跑一遍，哪怕粗糙一点，至少口径是自己可控的。
