再現可能なAI音声クローニングA/Bテスト手法

複数のinputを同時に変えたvoice-cloning comparisonは、差が聞こえても原因を説明できません。

Aがreference A、short sentence、neutral emotion、model Aを使い、Bが別reference、longer script、slower pace、model Bを使うなら、比較対象が多すぎます。

有用なA/B testは1つのquestionを中心に設計します。IndexTTS OnlineのVoice Labでも同じ原則を使い、reference、text formatting、emotion preset、paceの比較にも応用できます。

audioを生成する前にquestionを書く

良いquestionはnarrowです。

• どちらのreferenceがspeaker identityをより安定させるか
• commaよりperiodの方がこのpauseを改善するか
• 同じEnglish/Chinese inputでどちらのmodelがこのtaskに向くか
• slower paceはこのparagraphのcomprehensionを改善するか

一方、「どのsetupがbestか」「どちらがhuman-likeか」「perfect audioの設定は何か」は広すぎます。

narrow questionが、何を変えてよいか、何を固定すべきかを決めます。

control variablesを明示する

model A/Bなら少なくとも次を記録します。

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

両側でreferenceとtarget textを同一にします。

片方だけが特定language/controlを持つ場合、symmetric comparisonと表現しません。

現在のhosted IndexTTS2はEnglish/Chineseを中心にし、IndexTTS 2.5はChinese、English、Japanese、Spanish、Arabicとpace controlを提供します。Japanese testは2.5 capabilityの評価にはなりますが、Japanese pathを提供しないIndexTTS2とのfair direct A/Bではありません。

cleanでauthorizedなreferenceを使う

1 speaker、low noise、BGMなし、stable recording environmentを基準にします。

questionable referenceでmodel benchmarkを始めると、model差ではなくpoor source qualityとのinteractionを測ることになります。

public exampleではprovenanceとrightsも記録します。customer audioやprivate user referenceを明示的なpermissionなしで公開benchmarkに使用してはいけません。

upstream official referenceをtest inputとして使う場合も、そこで生成したhosted outputとupstream sampleは別カテゴリとしてlabelします。

questionに合うtarget textを選ぶ

identity/naturalnessならordinary connected speech。

punctuationなら意味のあるpauseを1つ。

numberなら検証対象のnumeric formだけを含むshort line。

multilingualならtarget languageを理解する人が書くかreviewしたnatural sentence。

name、acronym、date、emotional dialogue、code tokenを全部1つの「general test」に入れないでください。それらが実際のtarget domainでない限り、原因の切り分けを難しくします。

1回だけで決めずrepeatする

generative outputにはvariationがあります。

1 takeだけが偶然非常に良い、または悪い可能性があります。重要なproduction decisionではfinalistを2〜3回程度repeatすると、single sampleでは見えないinstabilityが分かります。

file nameも明確にします。

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

これで後からauditしやすくなります。

可能なら最初はblind reviewする

model labelはperceptionへ影響します。

first passではfileを一時的にA/Bへrenameし、notesを書いてからmappingを明かします。

team reviewでは、discussion前に各reviewerが自分のchoiceを書くようにします。最初の強い意見へ他のlistenerが引っ張られるbiasを減らせます。

listening dimensionを分離する

“better”だけではactionableではありません。

Speaker identity

reference speakerらしさがclip全体で保たれているか。

Intelligibility

textを見ずにwordsを理解できるか。

Pronunciation

name、number、abbreviation、target-language wordが意図通りか。

Prosody

stress、rhythm、pause、sentence endingが自然か。

Stability

clip内とrepeat generation間でvoiceが安定するか。

Artifacts

metallic sound、glitch、repeated phoneme、clipping、odd breath、background-like noiseがないか。

Task fit

narration、dialogue、localization、support contentなど実際の役割にどちらが適するか。

分けて記録すると、次の改善につながります。

1–5 scaleを自動的にMOSと呼ばない

internal five-point scaleはproduction comparisonには使えます。

しかしMean Opinion Scoreは通常、定義されたlistening-test methodologyと複数listenerのaggregationを意味します。

proper listener studyをしていないなら、次のように正直にlabelします。

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

数字があるだけでscientific MOSにはなりません。

latency benchmarkを捏造しない

latencyにはmodel以外にもqueue、provider infrastructure、network、reference upload、text length、cold start、retry、regionなどが影響します。

公開するなら、start/end point、sample size、region、text length、date、failure handlingを明示します。

protocolなしに「Model X is 30% faster」と言うのは信頼できません。

upstream technical reportを引用する場合はupstream evidenceと明示し、hosted productで再現したmeasurementのように見せないでください。

upstream evidenceとfirst-party measurementを分ける

benchmark pageには次の3種類が混在し得ます。

1. hosted product facts
2. model authorが公開したupstream findings
3. 自サイトが実際に計測したfirst-party measurements

これらを別々にlabelします。

upstream numberをhosted productの隣に置くだけで、userはsiteが再現したと誤解する可能性があります。

exact test dateとconfigurationを残す

model、provider、infrastructure、product controlは変化します。

public testには最低でもtest date、model ID、reference provenance、target text、language、controls、runs、evaluation methodを記録します。

後でresultが古くなっても、当時の条件を明示していれば再テストできます。

actual production taskを試す

generic benchmarkだけでproject decisionをしないでください。

audiobookならrealistic paragraph、UI promptならshort instruction、Spanish localizationならactual Spanish narrationを使います。

generic sampleでbestでも、特定workflowでbestとは限りません。

model A/B例

Question: 同じEnglish narrator referenceでどちらがよりstableか。

Fixed: 同じvoice_01.wav、同じtarget sentence、同じneutral/follow-reference emotion、同じ適用可能なpace。

Changed: model only。

Runs: 各3回。

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

この結果はそのcaseのrecommendationには使えますが、universal superiorityを証明しません。

reference A/B例

Question: どちらのreference recordingがrepeated narrationに向くか。

model、text、language、emotion、paceをfixedし、referenceだけ変更します。

winnerを別target sentenceでもrepeatし、同じreferenceが引き続き良ければproject baselineとして保存します。

reusable benchmark template

各caseで次を残します。

spreadsheet、Markdown、databaseのどれでもよく、consistent documentationが重要です。

inconclusive resultを無理にwinnerへ変えない

AとBが同等に良い、またはrepeatでpreferenceが反転することがあります。

それは失敗ではなくresultです。

と記録し、supported language、control、cost、workflow simplicityなどで選択します。

fabricated certaintyよりhonest inconclusiveの方がproductionには役立ちます。

最終testing rules

信頼できるvoice A/Bは：

1. narrow questionを1つ設定する
2. 1 variableだけ変更する
3. referenceとtextをcontrolする
4. important runsをrepeatする
5. 複数listening dimensionで評価する
6. preference scoreをstandardized MOSと偽らない
7. provenanceとdateを記録する
8. upstream findingsとhosted first-party measurementsを分ける
9. unsupported language/model comparisonを作らない
10. limitationをresultと一緒に公開する

A/B testingの価値はguessingを減らすことです。

そのcredibilityは節度から生まれます。controlできるものをcontrolし、測ったものだけをlabelし、experimentがsupportしない結論を足さないこと。