Von Bedeutung
英語以外の翻訳は便宜上のみ提供されています。 バインドのバージョンについては、このドキュメントの EN-US
バージョンを参照してください。
このセクションでは、Speaker Recognition のパフォーマンスの意味、Speaker Recognition 機能に関連するパフォーマンス、制限事項、公平性を向上するためのベスト プラクティスについて説明します。
一般的なパフォーマンス ガイドライン
Speaker Recognition はさまざまな用途に対応するため、すべてのシステムに共通して適用できる精度の見積もりはありません。 会議の文字起こしなどの場合、Speaker Recognition は、他のコンポーネントと組み合わせてエンドツーエンドのソリューションを作成できる構成要素です。 したがって、Speaker Recognition のパフォーマンスは、これらの他のコンポーネントの影響を受けます。
精度
話者検証と話者識別の両方の精度は、誤拒否率 (FRR) と誤受け入れ率 (FAR) によって測定できます。 開発者は、各特定のシナリオで FRR と FAR のレートのトレードオフのバランスを取る必要があります。
テキストに依存しない話者検証を例として見てみましょう。 次の表は、2 人の個人が Speaker Recognition を使用する建物またはシステムへのアクセスを要求する可能性のある結果を示しています。 この 2 人は、登録されている 話者 A と、 話者 A を主張する偽装者です。Speaker Recognition は、Speaker A の保存された音声署名に対して音声入力のオーディオをテストします。
結果 | 詳細 |
---|---|
正しい受け入れまたは真陽性 | システムは 、話者 A によるアクセス試行を正しく受け入れます。 |
正しい拒否または真の否定 | システムは、偽装者によるアクセス試行を正しく拒否します。 |
誤受理または誤検知 | システムは、偽装者によるアクセス試行を誤って受け入れます。 |
誤拒絶または偽陰性 | システムは、スピーカー A によるアクセス試行を誤って拒否します。 |
Speaker Identification API の測定は似ていますが、音声入力が複数の既知のスピーカーのいずれかに対してテストされる点が異なります。
偽陽性または偽陰性の結果は、話者認識システムの使用目的によって異なります。 次の例は、このバリエーションと、システムを設計する際の選択が、その対象となるユーザーに与える影響を示しています。 フォールバック メカニズムを含むシステム全体の設計によって、エラーが発生した場合のユーザーの結果が決まります。
銀行アプリにサインインする: 話者認識では、PIN に加えてセキュリティレイヤーを追加できます。 このアプリケーションの誤検知では、誤った一致が発生するため、顧客のセキュリティが低下しますが、誤検知によって顧客が自分のアカウントにアクセスできなくなる可能性があります。 銀行システムの目的はセキュリティであるため、システム所有者は、より高い信頼レベルのしきい値を必要とすることで、誤検知を最小限に抑えたいと考える可能性があります。 ただし、これは、ほとんどのエラーが誤った否定として行われる可能性もあります (アカウントアクセスが失敗します)。 この制限に対処するために、システム所有者は、ユーザーがアプリケーションにアクセスできるようにする別のメカニズムを提供する必要があります。たとえば、顧客の電話にアクセス コード通知を介して代替サインインを提供する必要があります。 この場合、顧客のエクスペリエンスの利便性は低下する可能性がありますが、セキュリティの優先順位が引き続き優先されている間、アカウント アクセスはブロックされません。
スマート デバイスでパーソナライズされたコンテンツを受信する: 個人用デバイスでは、Speaker Recognition を使用して、パーソナライズされたコンテンツに対するデバイス所有者の音声コマンドに応答できます。 偽陽性では不要なアクティブ化が増加しますが、偽陰性ではユーザーコマンドに応答しない可能性があります。 ここで、システムの目的が利便性と効率性であり、セキュリティではない場合、システム プロバイダーに対していくつかの誤検知が許容される可能性があります。 この場合、偽陰性は通常最小限に抑えられますが、またほとんどのエラーは偽陽性の結果となります。 デバイス所有者の音声を複数回登録することにより、Speaker Recognition がその音声を時間が経つにつれてより正確に認識できるようになります。
一致スコア、一致のしきい値、および一致条件
システム構成はシステムの精度に影響します。 事前登録されたスピーカー プロファイルと入力オーディオを比較することで、Speaker Recognition は一致スコアを出力して比較結果の類似性を示し、しきい値を使用して入力を一致として受け入れるか拒否するかを決定します。 誤検知率と偽陰性率のトレードオフを理解することが重要です。 次の表に、詳細な説明を示します。
任期 | 定義 |
---|---|
マッチ スコアまたは類似性スコア | マッチ スコアの範囲は 0 から 1 です。 一致スコアが高い場合は、音声入力が、登録された音声署名を持つ同じユーザーから提供される可能性が高くなります。 |
一致のしきい値 | 一致しきい値は、正の一致と見なすために必要な一致スコアを決定する 0 から 1 までの構成可能な値です。 一致しきい値が 0 に設定されている場合、システムはマッチ スコアを受け入れ、誤許容率は高くなります。一致しきい値が 1 に設定されている場合、1 (100%) マッチ スコアの音声入力のみが受け入れられ、誤拒否率は高くなります。 Speaker Recognition API には、アプリケーションに合わせて変更できる既定の一致しきい値があります。 |
最適なしきい値はユース ケースやシナリオによって大きく異なるため、Speaker Verification API は、既定のしきい値 0.5 に基づいて受け入れるか拒否するかを決定します。 しきい値は、セキュリティ重視のアプリケーションと利便性重視のアプリケーションの要件の間での妥協です。 各シナリオのしきい値を調整し、データを使用してテストして結果を検証します。
結果 | 詳細 |
---|---|
正しい受け入れまたは真陽性 | 実際の Speaker A が Speaker A としてアクセスを要求すると、システムはマッチ スコア 0.8 を返します。これは、既定のしきい値である 0.5 を超えています。 システムはアクセス試行を正しく受け入れます。 |
正しい拒否または真の否定 | 偽装者が Speaker A としてアクセスを要求すると、システムは既定のしきい値 0.5 を下回る 0.2 を返します。 システムはアクセス試行を正しく拒否します。 |
誤受理または誤検知 | 偽装者が スピーカー A としてアクセスを要求すると、システムは 0.6 を返します。これはしきい値 0.5 を超えています。 システムがアクセスの試行を誤って受け入れます。 |
誤拒絶または偽陰性 | 実際の Speaker A が Speaker A としてアクセスを要求すると、システムは 0.4 を返します。これはしきい値 0.5 を下回ります。 システムがアクセスの試行を誤って拒否しました。 |
一致のしきい値を選択する方法
最適なしきい値は、シナリオによって大きく異なります。 特定のシナリオで結果の精度が最適でない場合は、既定のしきい値を調整し、独自のデータでテストした結果に基づいて微調整できます。 実際のデータを収集して、オーディオ サンプルに正しいスピーカー ID のラベルが付いているかどうかを評価できます。 この種類のデータセットは、正答評価データセットと呼ばれます。
その後、評価データを Speaker Verification API にフィードし、返されたマッチ スコアを保持できます。 グラウンド トゥルース ラベルをシステムの出力と比較します。 このシステム パフォーマンスの評価により、関心のあるしきい値に対する FRR と FAR 全体、および誤検知と偽陰性の間のエラーの分布を確立できます。 グランド 真実評価データには、認識対象となる多様なユーザーの適切なサンプリングを含める必要があります。これによって、ユーザーグループ間のパフォーマンスの違いを理解し、是正措置を取ることができます。
評価結果を使用すると、シナリオに合わせてしきい値を調整できます。 たとえば、顧客 ID 検証シナリオでは通常、利便性よりも高いセキュリティが優先されるため、しきい値を既定のしきい値より高く設定して、誤認識エラーを減らすことができます。 これに対し、パーソナル化シナリオでは、セキュリティよりも利便性が高い場合があるため、しきい値を既定値よりも低く設定して、誤って拒否するエラーを減らすことができます。 各評価結果に基づいて、誤検知と偽陰性のトレードオフが目標を満たすまで、一致のしきい値を繰り返し調整できます。
精度を向上させるためのベスト プラクティス
話者認識システムから最適な結果を得るために実行できる具体的なアクションを次に示します。
件名と環境のバリエーションを計画する
登録オーディオと認識オーディオの間に一致条件を持つことで、システムの精度を向上させることができます。 一致条件は、同じデバイスまたはマイクを使用するか、一貫性のある音響環境を持っているか、スピーカーの一貫した話し方 (読み取りスタイルと会話スタイルなど) を使用することを意味します。
一致条件の達成は困難な場合があります。 Speaker Recognition はさまざまな音響条件のデータでトレーニングされていますが、さまざまな条件に対応するために複数の登録をサポートすることをお勧めします。 API は複数の登録をサポートしているため、システムが使用されると予想される条件の範囲内で、時間の経過と同時に話者を登録できます。 Speaker Recognition では、複数の登録を使用して、より堅牢なオーディオ署名を作成できます。
テキストに依存しない検証または識別の場合、登録または認識オーディオ入力の期間も精度に影響します。 有効な音声の長さは、無音セグメントと非音声セグメントを除く、音声の合計長を測定します。 音声検出モジュールを使用して、使用可能なオーディオの合計量をカウントします。 たとえば、ユーザーはテキストに依存しない登録のために 30 秒の音声を送信する場合がありますが、有効な音声の長さは 15 秒に限られます。 登録と認識の音声コンテンツが異なる場合 (テキストに依存しないシステム)、効果的な音声が長いほど、パフォーマンスが向上します。 アクティブな登録が有効になっている場合、登録の開始時のアクティブ化フレーズの長さは、登録の音声の合計長でカウントされます。
仕様を満たす
次の仕様に注意することが重要です。
- オーディオ形式: 現在のシステムでは、モノラル チャネル 16 ビット、16 kHz PCM エンコード WAV のみがサポートされます。 8 kHz サンプリング レートのデータは、サービスに送信される前に 16kHz までサンプリングする必要があります。
- 比較する登録済み音声の最大数: Speaker Identification API では、音声入力は、登録されている音声の指定されたリストと比較されます。 比較対象の候補が少ないほど、結果は正確になります。 現在の Speaker Identification API では、比較するために登録できる音声は最大50個です。
人間の判断をサポートするシステムを設計する
スピーカー認識機能を使用して、プロセスを完全に自動化するのではなく、正確で効率的な判断を行うユーザーをサポートすることをお勧めします。 意味のある人間のレビューは、次の点で重要です。
- 誤識別またはその他の障害のケースを検出して解決します。
- 結果が正しくないと思われるユーザーにサポートを提供します。
たとえば、コール センターのシナリオでは、喉が痛いために正当な顧客を拒否できます。 この場合、人間のエージェントは、セキュリティに関する質問をすることで、介入し、顧客が自分の身元を確認できるように支援することができます。
認証に複数の要素を使用する
高いセキュリティを必要とするシナリオでは、常に多要素認証を構築することをお勧めします。 別のセキュリティ要素を使用すると、スプーフィング攻撃の軽減に役立ちます。
リプレイ (またはスプーフィング) 攻撃のリスクを軽減する
話者認識は、音声がライブの人が話しているか、登録された話者の音声録音であるかを判断するためのものではありません。 高いセキュリティを必要とする検証シナリオでは、音声をセカンダリ認証要素として使用するだけでなく、実行時に読み取る話者のランダム フレーズの生成などの軽減策を検討してください。 これにより、非パラメーター ベースの合成音声を使用する再生攻撃や攻撃のリスクを軽減できます。
アプリケーションは、テキストに依存しない Speaker Verification API と音声からテキストへの API に個別の要求を送信できます。 これらを組み合わせることで、アプリケーションは話者の身元を確認するのに役立ちます。
公平性
Microsoft では、地球上のすべての人がより多くのことを達成できるように力を与える努力をしています。 この目標の重要な部分は、公平で包括的なテクノロジと製品の作成に取り組んでいます。 公平性は多次元の社会技術のトピックであり、製品開発のさまざまな側面に影響を与えます。 公平性に対する当社のアプローチの詳細については 、こちらをご覧ください。
この目標の 1 つの側面は、さまざまなグループのユーザーに対してシステムがどれだけ適切に実行されるかを検討することです。 研究では、すべてのグループのパフォーマンス向上に重点を置いた意識的な努力がなければ、多くの場合、人種、民族性、地域、性別、年齢などの要因に基づいて、グループ間でシステムのパフォーマンスが異なる可能性があることが示されています。
性別、民族性、年齢などの人口統計学的要因を含め、さまざまな要因でシステムをテストします。 各アプリケーションは異なるため、私たちのテストはお客様のコンテキストに完全に合致しない場合や、ユースケースに必要なすべてのシナリオを網羅しない場合があります。 実際のユース ケースを反映した実際のデータを使用して、サービスのエラー率を十分に評価することをお勧めします。 これには、さまざまな人口統計グループのユーザーと異なる音声特性を使用したテストが含まれている必要があります。
Speaker Recognition では、特定のデータセットの言語間でパフォーマンスにいくつかの違いがあります。 テキストに依存しない検証と識別 API について、8 つの言語 (英語、フランス語、スペイン語、中国語、ドイツ語、イタリア語、日本語、ポルトガル語) を調整し、評価しました。 Speaker Recognition の言語とロケールのサポートの詳細 については、こちらをご覧ください。 話者認識は、18 歳未満の未成年者または音声障害を持つユーザーを表すデータでテストされていません。
ご利用のための話者認識の評価と統合
大規模な展開またはスピーカー認識システムのロールアウトの前に、システム所有者は評価フェーズを実施する必要があります。 この評価は、システムを使用するコンテキストと、システムと対話するユーザーと共に行います。 分析および調査チームと協力して、次の項目に対して地上の真偽評価データを収集します。
- ベースラインの精度、誤検知率、偽陰性率を確立します。
- シナリオに適した一致しきい値を選択します。
- エラー分布が特定のユーザー グループに偏っているかどうかを判断します。
評価は反復的なプロセスである可能性があります。 たとえば、50 人のスピーカーと各スピーカーに対して 20 回の試行から始めることができます。 評価には、デプロイ環境と、その環境のバリエーション (マイク チャネルやノイズ レベルなど) が反映されている必要があります。 多様な人物や話者のスタイルを表す地上真偽評価データを使用します。
精度データの分析に加えて、システム出力に基づいて判断したユーザーからのフィードバックを分析することもできます。 さらに、認識対象のユーザーからの満足度データと、既存の顧客の音声チャネルからのフィードバックを分析して、システムを調整し、エンゲージメントを成功させることができます。