一つのエンジンでは足りない理由：エンジンを増やして効くのは、間違える場所が違うときだけ

42 分のビジネスインタビューで比較を行いました。一方の文字起こしは ElevenLabs からそのまま出したもの。もう一方は私たちのパイプラインを一通り通したもの。両者は 91% 一致していました。

残りの 9% こそ、リサーチャーが最も気にする部分でした。

「ほぼ正しい」が危ない

インタビューから重要な用語を 19 個選びました。ブランド名、型番、地名、業界用語です。エンジンから出したままの文字起こしでは、10 個が誤り、4 個が一部誤り、5 個が正解でした。あるブランド名は六回出てきて、一度も正しく書かれませんでした。毎回、発音は似ていても意味がまったく違う普通の単語になっていました。

ElevenLabs の名誉のために言えば、この日の出来は良好でした。崩れた箇所も抜け落ちた箇所もなく、話者の判定も約 98% 正しかった。全体として評価するなら、欠点を見つけるのは難しいでしょう。

そこが問題なのです。流暢な文を読んだ人には、その真ん中にある名詞を疑う理由がありません。しかも手元にあったほかの三つのエンジンも、同じ用語を同じように間違えていました。つまり、ある一つのエンジンが悪いという話ではありません。どのエンジンも単独では、初めて出会う業界用語を聞き違えるということです。

自分たちの「最適化」は、カードを切り直しただけだった

音声をエンジンに送る前に、私たちは音声を区間に分割し、フォーマットを揃えています。これで精度が上がると考えていました。

結果は、直ったものが 22 件、壊れたものが 25 件。ほぼコイントスです。

最終的に理由がわかりました。このエンジンは、音声のどこから聞き始めるかに非常に敏感なのです。同じ型番が、区間がゼロ秒から始まると「X6」、1:30 から始まると「X-six」と綴りで出てきました。加工していない文字起こしですら一貫しておらず、最初の 32 分は「X-six」、それ以降は「X6」でした。

そこにたどり着くまでに、対照実験を三回行い、そのたびにありがちな説明を一つずつ潰しました。ファイルの長さでもなく、音声フォーマットでもなく、言語設定でもない。最初のもっともらしい答えで止めていたら、間違った原因を自分たちのドキュメントに書き込んでいたはずです。

文字起こしを本当に良くしたのは、エンジン同士の照合だった

ほかの三つのエンジンが同じ音声を文字起こしし、用語集を使いながら、それらすべてを突き合わせます。分割で壊れた 25 件のうち、14 件、つまり 56% が回復しました。

型番も同じようにして正されました。別のエンジンが毎回欠かさず「X6」と書いていたので、メインエンジンが揺れても、最終稿には正しい書き方の拠り所が残っていたのです。

エンジン同士で決着がつかない箇所は、読み手の代わりに決めることはしません。誰かがその一秒を聞き直せるよう、存疑として印を付けます。このインタビューでは印が 7 か所でした。

エンジンは多ければ良いわけではない

エンジンが多いほど結果が良くなる、と結論したくなります。私たちはそれを試しました。そうはなりません。

ローカルで動くオープンソースの中国語エンジンを八つ試し、投票させました。結果は、最良の単独エンジンより悪くなりました。八つのうちの大半は同じ会社のもので、学習データが大きく重なっていたため、同じ単語で間違える傾向がありました。投票はその誤りを正すどころか、固定してしまったのです。

四つの異なる技術方式に基づくエンジン四つに切り替えると、状況が変わりました。どの二つを取っても、同じ箇所に落ちた誤りは 32.6% から 45.8% にとどまり、合わせればどの単独エンジンよりもはっきり優れていました。

ですから、ある言語の補助エンジンを選ぶとき、私たちはそれぞれの精度だけを問うのではありません。メインエンジンとは違う箇所で間違えるかを問います。韓国語がその例です。あるエンジンは単独では問題なく見えましたが、最悪の誤りがほかの二つとほとんど同じでした。三つとも同じ単語を同じように間違えていたのです。私たちはそれを、誤りの重なりが小さい Soniox に置き換えました。

慎重になった理由がもう一つあります。AssemblyAI が新バージョンを出したとき、多言語混在音声について公表された誤り率は、前世代の 9.07% から 7.69% に下がりました。私たちは六つの言語で単語ごとに確認しました。結果はどれも、悪化したか、良くなっていないかのどちらかでした。新バージョンは、誰も言っていない単語を足していたのです。ある英語の文には「Bruh」が加わりました。あるイタリア語の「50,000 lire」は「50 million」になりました。誤り率で見れば、六つのほぼすべてが改善に見えます。余計な単語が一つ増えても、この指標はほとんど動かないからです。公式ドキュメントに答えがありました。新バージョンは大規模言語モデル型のデコーダーを使っているのです。私たちは旧バージョンに戻しました。

ベンダーのスコアカードが測っているのは、ベンダーが選んだ条件です。あなたのインタビューではありません。

まだ負けているところ

複数エンジンの利点を述べてきたので、ここからは私たちが間違えたことです。

最終稿にはまだ 10 件の誤りがあり、すべて日常語でした。その一つでは、インタビュー相手が「my wife」と言ったのに、文字起こしは「my sister」でした。

同じ入力を三回与えると、照合のステップが回復した誤りは 0 件、3 件、3 件でした。このステップにも揺らぎがあるのです。

照合のルールを変えて A/B テストもしました。効果がなかったので元に戻しました。さらに掘り下げると、問題はルールではなく、その一つ前のアラインメントの段階にありました。正しい単語は補助エンジンの文字起こしのいくつかに存在していたのに、区間の境界が揃っていなかったため、照合までたどり着かなかったのです。正解が入力に含まれていなければ、どんなルールもそれを選べません。

これはまだ完全には解決していません。それでも書くのは、ここまでの話と同じ教訓だからです。複数エンジンの価値は、実際に持ち込める証拠の量で決まります。