言語検出器は、咳に対しても必ず答えを出します。クリアな音声や複数言語が混ざった音声では検出をオンのままにし、ノイズや強いアクセントの中で一つの言語だけが話されている場合は言語を指定してください。
すべての文字起こしは、視聴者には見えない一つの問いから始まります。これは何語の音声か、という問いです。ここで誤ると、その後のパイプラインがどれほど精巧に動いても、流暢でも意味をなさない文字起こしが出来上がります。この記事では、言語検出器が何を手がかりにしているか、ライブ音声とファイルでどのように振る舞うか、そして言語を自分で指定したほうがよいのはいつかを説明します。
言語検出器は、話されている内容を理解しているわけではありません。見ているのは音そのものです。子音と母音の構成、音節のアクセント、フレーズのリズム、そして多くの言語が頼りにしている短くて頻出する単語などです。スペイン語には独自の母音体系とリズムがあります。オランダ語とドイツ語は多くを共有していますが、いくつかの音で分かれます。明瞭な音声の数秒あれば、通常は両者を見分けるのに十分です。
多くの認識エンジンは、単語を認識する過程の副産物としてこれを行います。音声の冒頭から言語を判断し、既知のすべての言語についての確率を出すのです。この設計から二つのことが導かれます。確率の合計は常に1になるため、「言語なし」という答えは存在しません。無音、咳、音楽のジングルにも言語が割り当てられ、しかもそれにはしばしば自信に満ちたスコアが付きます。そして判断は冒頭部分から行われるため、これは最悪のサンプルと言えます。多くの録音は挨拶、人名、地名から始まりますが、これらは言語の手がかりをほとんど含みません。「Good morning, Maria, welcome to Berlin」はほぼドイツ語でもあり、英語でもあるのです。ほかの録音は無音や咳から始まります。その場合、検出器は何も聞こえていないのに、判断を求められれば自信を持って判断してしまいます。実際の音声でも同じことが起こります。部屋の雑音から始まり「Bună dimineața」と言うルーマニア語の説教が、自信満々にイタリア語の「Buona domenica」と聞き取られてしまうことがあるのです。
誤った答えのコストも、思われている以上に重大です。誤った言語で復号するとき、認識エンジンは綴りを間違えるのではなく、書き換えてしまいます。「For God so loved the world」をルーマニア語として復号すると「Forgot to love the world」になりました。ルーマニア語の「mândria slujește」を英語として復号すると「Pride serves」になりました。これは、誰も翻訳を求めていない文を正確に訳した結果と言えるものです。単語は流暢で、文字起こしには何か間違っている兆候がまったく現れません。だからこそ、この誤りは高くつくのです。
検出器を最も惑わせる要因は五つあります。
どれが問題になるかは、音声がライブで届いているのか、それともすでにファイルとして存在しているのかによって変わります。
ライブ文字起こしでは、録音全体を見ることはできません。音声は話されるそばから届き、文字起こしもそれに合わせて届かなければなりません。そのため、言語は話者が話すのに合わせて検出され、話者が切り替えればそれに追随します。ダッシュボードでライブ文字起こしを開始するとき、Spoken language スイッチの下の注記がこれを意味しています。話者の言語は自動で検出され、話者はいつでも切り替えることができる、という意味です。
切り替えは適用される前に確認されるため、一瞬のノイズで文字起こしが別の言語に引きずられることはありません。弱点は冒頭です。最初の言葉がノイズの多い挨拶だと、最初の行が誤った言語で出てくることがあります。言語を指定すればこれを避けられます。
ファイルの場合は仕組みが異なります。
ファイルはより扱いやすい問題です。録音全体がすでにあるため、最初の数秒を信用する必要がありません。ファイルの場合、言語は録音全体から判断されるので、冒頭のノイズの多い挨拶がそれを決めてしまうことはありません。
ただし、ファイルの言語も確定した結論ではなく、作業上の仮定にすぎません。途中で言語が本当に変わる録音、たとえば後半で英語からルーマニア語に移るインタビューは、無理に一つの言語に押し込まれるのではなく、その変化に沿って処理されます。言語が全体を通して行き来する録音も扱えます。
一度だけ判断して二度と見直さない検出器は、誤った場所で自信を持っているにすぎません。
録音全体がノイズだらけの場合、どの検出器もあまり役に立ちません。検出は既定の設定であり、ほとんどの場合正しく、費用もかかりません。しかし録音によっては言語を指定すべきです。どの録音かはダッシュボードが教えてくれます。話されている言語を指定すると、ノイズの多い録音や強いアクセントの音声で精度が向上します。
こうした場合は、検出器が手がかりを最も少なく持っている場合です。ノイズは検出器が頼りにする手がかりを取り除き、強いアクセントはそれらを別の言語の方向へずらし、近縁のペアは最初から手がかりが少ないのです。残響の大きいホールで話す、強いポルトガル語アクセントの英語話者は、音だけでは判別が困難です。検出器がその話者を誤って判定すると、誤りが続く間、英語の発話がポルトガル語として文字起こしされてしまいます。言語を指定すれば問題自体がなくなるため、すべての処理能力を言葉の認識に向けることができます。
簡単なチェックリストです。
言語の指定は文字起こしの設定であり、アカウントの設定ではありません。そのため、録音ごとに判断できます。ここまでの内容は、一つのAPIオプションに集約されます。
spokenLanguageを省略すると検出、ストリーム途中ではsession.updateAPIでは、spokenLanguageはenのような言語コードです。省略すると言語が検出されます。ファイルやリンクの文字起こしではsettingsに、リアルタイムセッションではオプションに含まれます。検出と指定の対象は同じ100言語です。翻訳は最大10言語への翻訳であり、これは別の選択です。検出された言語や指定された言語には依存しません。翻訳が音声にどう追いつくかについては、ライブ翻訳の遅延を解説で扱っています。
{ "name": "Board meeting", "settings": { "spokenLanguage": "en", "speakerLabels": "auto" } }
リアルタイムセッションは、作成時に同じオプションを受け付け、音声が流れている間でも変更できます。新しいspokenLanguageを含むsession.updateのテキストフレームは、その後の音声に適用されます。値を""または"auto"にすると、セッションは検出に戻ります。対応していないコードは無視されます。言語ボタンを備えた字幕ビューでは、オペレーターが最初の行の誤った言語に気づいた時点で言語を指定でき、再接続は不要です。
{ "type": "session.update", "spokenLanguage": "ro" }
言語コードの一覧と名称はGET /v1/languagesで取得でき、キーは不要です。サーバーでセッションを作成してから下書きとコミットを読むまでの完全なリアルタイムの流れは、WebSocketを使ったリアルタイム文字起こしに書かれており、対話型のリファレンスは{{api}}/docsにあります。ダッシュボードでは、同じ選択が新しい文字起こしを開始するときのSpoken languageスイッチになり、APIのキーはDevelopersの下にあります。