可复现的 AI 声音克隆 A/B 测试方法

声音克隆对比最容易犯的错误，是一次同时改变太多东西。

如果 A 使用一条 reference、短句、中性 emotion 和模型 A，而 B 同时换成另一条 reference、更长文本、更慢 pace 和模型 B，你当然能听到差异，但你无法解释差异到底由什么造成。

真正有用的 A/B 测试，必须围绕一个明确问题设计。

IndexTTS Online 的 Voice Lab 适合做受控模型比较；同样的方法也可以用于 reference recording、文本格式、emotion preset 或 speaking pace 的测试。

生成前先把问题写下来

好的 test question 应该很窄，例如：

• 哪一个 reference 能让 speaker identity 更稳定？
• period 相比 comma 是否让这个停顿更自然？
• 在同一英文/中文输入下，哪个模型更适合这条制作任务？
• 较慢 pace 是否提高这段文字的可理解度？

不好的问题通常很宽：

• 哪套设置最好？
• 哪个模型最像真人？
• 什么配置能得到完美音频？

窄问题的价值在于，它直接告诉你：哪个变量可以变，其他哪些变量必须固定。

明确定义 control variables

建立一份简单的测试记录。

模型 A/B 至少记录：

• reference file；
• target text；
• target language；
• emotion mode；
• pace；
• model A；
• model B；
• test date；
• repeat count。

两边必须使用相同 reference 和 target text。

如果一边支持某个 language/control、另一边不支持，不要假装这是对称比较，而应明确标记 capability difference。

例如当前 hosted IndexTTS2 主要聚焦英文和中文，而 IndexTTS 2.5 暴露中文、英文、日语、西班牙语、阿拉伯语以及 pace controls。日语测试可以评价 2.5 的真实能力，但不能包装成对一个并未暴露日语路径的 IndexTTS2 的公平 A/B。

使用干净、已授权的 reference

Reference 应该只有一名说话者、低背景噪声、无音乐，并尽量保持录音环境稳定。

不要拿一条本身就很差的 reference 去做所谓 model benchmark。否则你测到的是“模型 × 坏输入”的交互，而不是单纯的模型差异。

公开 benchmark 还必须记录 reference provenance 和 rights。

未经明确许可，不要拿客户音频或私有用户 reference 做公开测试样本。

上游官方 reference 可以在来源明确、用途适当时作为输入，但本站通过 hosted workflow 生成出来的 output，应与上游官方 sample 清楚区分，不能混在一起让用户以为是同一类证据。

选择真正能回答问题的 target text

测试句应该足够暴露你关心的属性，但不要同时塞入一堆无关 edge case。

如果测试 identity/naturalness，就用普通 connected speech。

如果测试 punctuation，就设计一个真正有意义的 pause。

如果测试 numbers，就放一个简短、代表性的 numeric form。

如果测试 multilingual generation，就使用由目标语言使用者编写或审核的自然句子。

除非你的目标域本来就包含这些问题，否则不要把姓名、acronym、日期、情绪对白和 code token 全塞进一条“通用 benchmark”。那会让你不知道哪一个因素造成结果差异。

重要候选必须重复运行

生成式输出本身可能有波动。

一条 sample 可能特别好，也可能特别差。单次结果不能自动代表普遍表现。

真正影响生产决策的候选，建议至少把 finalists 重复两三次。并用清楚文件名保存：

• case01-modelA-run1.wav
• case01-modelA-run2.wav
• case01-modelB-run1.wav
• case01-modelB-run2.wav

这样不仅方便当下试听，也方便后来 audit。

如果 run1 A 胜、run2 B 胜、run3 又接近，就说明稳定性本身就是一个重要结果。

尽可能先 blind review

标签会影响主观判断。

如果条件允许，第一次试听时先暂时把文件改成 A、B，而不要显示具体 model name。先写完 notes，再揭示 mapping。

团队 review 时，也尽量让每个人先独立写下判断，再一起讨论。

否则第一个很有自信的人说“B 明显更自然”，后面的人很容易被 group discussion 带偏。

这不等于严格学术双盲，但已经能减少很多不必要的 label bias。

把“更好听”拆成多个 listening dimension

“Sounds better”无法指导下一步制作。

至少可以分成：

Speaker identity

从头到尾是否仍然像已授权的目标说话者？

Intelligibility

不看文本时，词是否都能听懂？

Pronunciation

姓名、数字、缩写、目标语言词汇是否按预期朗读？

Prosody

重音、节奏、pause、sentence ending 是否符合内容？

Stability

同一 clip 前后以及多次 repeat generation 之间，声音是否稳定？

Artifacts

是否出现 metallic sound、glitch、重复音素、截断、奇怪 breath 或类似背景噪声？

Task fit

即使 A/B 都高质量，哪一个更适合实际任务：旁白、dialogue、本地化、support content 等？

拆开这些维度后，notes 才能变成 action。

内部评分可以用，但不要随便叫 MOS

1–5 分的内部量表可以帮助团队快速比较多个 clip。

但它不会因为“用了 1 到 5 分”就自动成为科学意义上的 Mean Opinion Score。

MOS 通常意味着明确的 listening-test methodology、多位 listener 和规定的 aggregation 方法。

如果没有做正规 study，就诚实叫：

• internal review score；
• reviewer preference；
• production note；
• sample comparison。

这种命名不是“降低专业度”，而是避免 false precision。

不要编造 latency benchmark

延迟不仅由 model 决定，还会受到：

• queue state；
• provider infrastructure；
• network path；
• reference upload；
• text length；
• cold start；
• retries；
• geographic region。

如果要公开 latency，必须定义清楚：

• 从哪里开始计时；
• 在哪里结束；
• sample size；
• region；
• text length；
• test date；
• failure 是否被排除。

没有 protocol 就说“Model X 快 30%”，不是可信 benchmark。

上游 technical report 可以作为 upstream evidence 引用，但不能伪装成本网站 hosted product 自己测出来的结果。

把 upstream evidence 与 first-party measurement 分开

一张 benchmark 页面可能同时出现三类东西：

1. hosted product facts：本站真正暴露了哪些 language/control；
2. upstream published findings：模型作者发布的结果；
3. first-party measurements：本站实际跑出来的测量。

这三类必须清楚标注。

否则一个 upstream number 放在 hosted product 旁边，用户很自然会理解成“本站已经复现”。这会直接损害可信度。

记录准确测试日期和配置

model、provider、infrastructure 和产品 controls 都可能变化。

一个可复现的公开结果，应至少包含：

• test date；
• model identifier；
• reference provenance；
• target text；
• language；
• controls；
• number of runs；
• evaluation method。

以后结果过时，可以重新更新，而不是假装旧测试永远代表所有未来版本。

最终还要测试真实 production task

benchmark sentence 有用，但真正的 project decision 应该包含一个代表性任务。

如果做 audiobook，就用接近真实长度的 paragraph。

如果做 UI prompt，就测真实短 instruction。

如果做西语视频 localization，就测试真实 Spanish narration，而不是拿英语 demo 代替。

通用 sample 上“最好”，并不保证在你的 production workflow 里最好。

示例：model A/B

问题： 同一 English narrator reference 下，哪个模型更稳定？

固定： 同一个 voice_01.wav、相同 target sentence、相同 neutral/follow-reference emotion、同样适用的 pace。

变化： model only。

Runs： 每个模型三次。

Review： identity、pronunciation、prosody、artifacts、preference。

这样的结果可以支持“在这个 case 下选择谁”的实际建议，但不能证明其中一个 model universally superior。

示例：reference A/B

问题： 哪一条 reference 更适合重复旁白？

固定： model、target text、language、emotion、pace。

变化： reference file only。

先比较 output，再用第二条 target sentence 复核赢家。

如果同一条 reference 仍然表现更好，再把它保存成 project baseline。

可复用 benchmark template

每个 case 建议记录：

它可以存在 spreadsheet、Markdown 或内部数据库中。

格式本身没有持续记录重要。

没有明确赢家也是正确结果

有时 A/B 都很好，有时 repeat run 会反转第一次偏好。

这本身就是结果。

不要为了让文章“有结论”而强行选一个 winner。

应该记录：

然后再根据 supported languages、controls、cost 或 workflow simplicity 做产品选择。

诚实的 inconclusive result，比虚构确定性更有价值。

最终测试规则

可信的 voice A/B 应遵循：

1. 一个 narrow question；
2. 一次只改一个 variable；
3. reference 与 text 受控；
4. 重要候选 repeat；
5. 分多个 listening dimension 评价；
6. 不把 preference score 包装成 standardized MOS；
7. 记录 provenance 与 test date；
8. 分离 upstream findings 与 hosted first-party measurements；
9. 不强做 unsupported language/model comparison；
10. 把 limitation 和结果一起公开。

A/B testing 的价值，是减少猜测。

它的可信度来自克制：控制你能控制的，只描述你真正测到的，不声明实验没有支持的东西。