知財求人 - 知財ポータルサイト「IP Force」
▶ マイクロソフト テクノロジー ライセンシング，エルエルシーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-03-10
(54)【発明の名称】認識レイテンシを削減するための適応的バッチ処理
(51)【国際特許分類】
G10L 15/04 20130101AFI20230303BHJP
G10L 15/16 20060101ALI20230303BHJP
【ＦＩ】
G10L15/04 300Z
G10L15/16
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022542461
(86)(22)【出願日】2020-12-15
(85)【翻訳文提出日】2022-07-11
(86)【国際出願番号】 US2020065034
(87)【国際公開番号】W WO2021146009
(87)【国際公開日】2021-07-22
(31)【優先権主張番号】62/960,240
(32)【優先日】2020-01-13
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/773,205
(32)【優先日】2020-01-27
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】314015767
【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】カリル，ホサム エー
(72)【発明者】
【氏名】ストイメノフ，エミリアン ワイ
(72)【発明者】
【氏名】ゴン，イファン
(72)【発明者】
【氏名】リウ，チャオジュン
(72)【発明者】
【氏名】バソグル，クリストファー エイチ
(72)【発明者】
【氏名】アガーワル，アミット ケー
(72)【発明者】
【氏名】パリハール，ナヴィーン
(72)【発明者】
【氏名】パターク，サヤン
(57)【要約】
実施形態は、オーディオ信号のアコースティック特徴フレームの第1バッチを収集するステップであって、第第1バッチのアコースティック特徴フレームの個数は第1バッチ・サイズに等しい、ステップと、第1バッチを音声認識ネットワークに入力するステップと、音声認識ネットワークにより出力されたワード仮説の検出に応じて、オーディオ信号のアコースティック特徴フレームの第2バッチを収集するステップであって、第2バッチのアコースティック特徴フレームの個数は、第1バッチ・サイズより大きな第2バッチ・サイズに等しい、ステップと、第2バッチを音声認識ネットワークに入力するステップを含むことが可能である。
【特許請求の範囲】
【請求項1】
処理ユニットと、プログラム・コードを含むストレージ・デバイスとを備えるシステムであって、前記プログラム・コードは、前記処理ユニットによって実行されると、前記システムに：オーディオ信号を処理するための第1バッチ・サイズを決定するステップ；
前記オーディオ信号の生のアコースティック特徴フレームを第1個数含む第1バッチを収集するステップであって、前記第1個数は前記第1バッチ・サイズに等しい、ステップ；
前記第1バッチを音声認識ネットワークに入力するステップ；
前記音声認識ネットワークにより出力されたワード仮説に基づいて第2バッチ・サイズを決定するステップであって、前記第2バッチ・サイズは前記第1バッチ・サイズより大きい、ステップ；
前記オーディオ信号のアコースティック特徴フレームを第2個数含む第2バッチを収集するステップであって、前記第2個数は前記第2バッチ・サイズに等しい、ステップ；及び
前記第2バッチを前記音声認識ネットワークに入力するステップ；
を実行させる、システム。
【請求項2】
請求項1に記載のシステムにおいて、前記ワード仮説に基づいて前記第2バッチ・サイズを決定することは、前記音声認識ネットワークにより出力された第1の非サイレント・ワード仮説を検出することと、当該検出に応じて前記第2バッチ・サイズを決定することとを含む、システム。
【請求項3】
請求項1に記載のシステムにおいて、前記プログラム・コードは、前記処理ユニットによって実行されると、前記システムに：複数のバッチを収集するステップであって、前記複数のバッチの各々は、前記オーディオ信号のアコースティック特徴フレームを前記第1個数含む、ステップ；
前記ワード仮説が前記音声認識ネットワークにより出力されるまで、前記複数のバッチを前記音声認識ネットワークに入力するステップ；
を実行させる、システム。
【請求項4】
請求項1に記載のシステムにおいて、前記プログラム・コードは、前記処理ユニットによって実行されると、前記システムに：スピーチ終了フレームを検出するステップ；及び
前記スピーチ終了フレームを、次に収集されるバッチの最終フレームとして含むように、アコースティック特徴フレームの次に収集されるバッチのサイズを減らすステップ；
を実行させる、システム。
【請求項5】
請求項1に記載のシステムにおいて、前記第1バッチ・サイズは第1個数のルック・アヘッド・フレームを含み、前記第1バッチは第1ルック・アヘッド・フレームを含み、前記第1バッチの第1ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しく、前記プログラム・コードは、前記処理ユニットによって実行されると、前記システムに：前記オーディオ信号のアコースティック特徴フレームを第1個数含む第3バッチを収集するステップを実行させ、前記第3バッチの複数のフレームに関連付けられる期間は、前記第1バッチの第1ルック・アヘッド・フレームに関連付けられる期間とオーバーラップしており；
前記第2バッチ・サイズを決定することは、ルック・アヘッド・フレームの第2個数を決定することを含み；及び
前記第2バッチは第2ルック・アヘッド・フレームを含み、前記第2バッチの第2ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第2個数に等しい、システム。
【請求項6】
請求項5に記載のシステムにおいて、前記音声認識ネットワークは、レイテンシ制御型の双方向長-短期メモリ・モジュールを含む、システム。
【請求項7】
請求項1に記載のシステムにおいて、前記第1バッチ・サイズは第1個数のルック・アヘッド・フレームを含み、前記第1バッチは第1ルック・アヘッド・フレームを含み、前記第1バッチの第1ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しく、前記プログラム・コードは、前記処理ユニットによって実行されると、前記システムに：前記オーディオ信号のアコースティック特徴フレームを第1個数含む第3バッチを収集するステップを実行させ、前記第3バッチの複数のフレームに関連付けられる期間は、前記第1バッチの第1ルック・アヘッド・フレームに関連付けられる期間とオーバーラップしており；
前記第2バッチは第2ルック・アヘッド・フレームを含み、前記第2バッチの第2ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しい、システム。
【請求項8】
請求項7に記載のシステムにおいて、前記音声認識ネットワークは、コンテキスト・レイヤ・トラジェクトリ型の長-短期メモリ・モジュールを含む、システム。
【請求項9】
コンピュータが実行する方法であって：オーディオ信号のアコースティック特徴フレームの第1バッチを収集するステップであって、前記第1バッチのアコースティック特徴フレームの個数は第1バッチ・サイズに等しい、ステップ；
前記第1バッチを音声認識ネットワークに入力するステップ；
前記音声認識ネットワークにより出力されたワード仮説の検出に応じて、前記オーディオ信号のアコースティック特徴フレームの第2バッチを収集するステップであって、前記第2バッチのアコースティック特徴フレームの個数は第2バッチ・サイズに等しく、前記第2バッチ・サイズは前記第1バッチ・サイズより大きい、ステップ；及び
前記第2バッチを前記音声認識ネットワークに入力するステップ；
を含む方法。
【請求項10】
請求項9に記載の方法において、前記ワード仮説の検出は、前記音声認識ネットワークにより出力された第1の非サイレント・ワード仮説の検出を含む、方法。
【請求項11】
請求項9に記載の方法において、スピーチ終了フレームを検出するステップ；
前記スピーチ終了フレームを検出したことに応じて、前記スピーチ終了フレームを、第3バッチの最終フレームとして含むように、前記オーディオ信号のアコースティック特徴フレームの第3バッチを収集するステップ；及び
前記第3バッチを前記音声認識ネットワークに入力するステップ；
を更に含む方法。
【請求項12】
請求項9に記載の方法において、前記第1バッチ・サイズは第1個数のルック・アヘッド・フレームを含み、前記第1バッチは第1ルック・アヘッド・フレームを含み、前記第1バッチの第1ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しく、前記方法は：前記オーディオ信号のアコースティック特徴フレームを第1個数含む第3バッチを収集するステップを実行させ、前記第3バッチの複数のフレームに関連付けられる期間は、前記第1バッチの第1ルック・アヘッド・フレームに関連付けられる期間とオーバーラップしており；
前記第2バッチは第2ルック・アヘッド・フレームを含み、前記第2バッチの第2ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第2個数に等しい、方法。
【請求項13】
請求項12に記載の方法において、前記音声認識ネットワークは、レイテンシ制御型の双方向長-短期メモリ・モジュールを含む、方法。
【請求項14】
請求項9に記載の方法において、前記第1バッチ・サイズは第1個数のルック・アヘッド・フレームを含み、前記第1バッチは第1ルック・アヘッド・フレームを含み、前記第1バッチの第1ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しく、前記方法は：前記オーディオ信号のアコースティック特徴フレームを第1個数含む第3バッチを収集するステップを更に含み、前記第3バッチの複数のフレームに関連付けられる期間は、前記第1バッチの第1ルック・アヘッド・フレームに関連付けられる期間とオーバーラップしており；
前記第2バッチは第2ルック・アヘッド・フレームを含み、前記第2バッチの第2ルック・アヘッド・フレームの個数は、前記ルック・アヘッド・フレームの第1個数に等しい、方法。
【請求項15】
請求項14に記載の方法において、前記音声認識ネットワークは、コンテキスト・レイヤ・トラジェクトリ型の長-短期メモリ・モジュールを含む、方法。【発明の詳細な説明】
【背景技術】
【0001】
ニューラル・ネットワーク・ベース・モデルは、自動音声認識（automatic speech recognition，ASR）を実行するために一般的に使用されている。幾つかの例では、ニューラル・ネットワーク・ベースのアコースティック・モデルは、入力オーディオ・フレームからセノン識別特徴（senone-discriminative features）を抽出し、抽出された特徴に基づいてセノンを分類するように訓練される。デコーダは、分類に基づいてワード仮説（word hypotheses）を生成し、対応するテキストを出力する。
【0002】
入力オーディオ・フレームは、精度とパフォーマンスを向上させることを目的として、一緒に処理と認識を行うことを可能にするために、2つ以上のフレームのバッチにバッチ化されることが可能である。しかしながら、バッチ化は、バッチをASRにサブミットする前に、バッチの全てのフレームを受信するまで待機することをシステムに要求する。この待機は、ASRの処理速度によらない、ユーザーが知覚する望ましくないレイテンシ（latency）を招く可能性がある。
【0003】
従来のASRシステムは、所与の配備の中で異なるレイテンシ要件を満足するために、幾つかの物理的に異なるモデルを使用することができる。このアプローチは、プロセッサに関連する訓練及び配備コストを増やしてしまう。システムは、並列モデルに頼ることなくレイテンシを改善するように望まれる。
【図面の簡単な説明】
【0004】
【図1A】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0005】
【図1B】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0006】
【図1C】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0007】
【図1D】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0008】
【図2】幾つかの実施形態による初期レイテンシ・センシティブ適応バッチ処理のためのプロセスのフローチャートである。
【0009】
【図3A】幾つかの実施形態による動作中に終期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0010】
【図3B】幾つかの実施形態による動作中に終期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システムのブロック図である。
【0011】
【図4A】幾つかの実施形態による初期及び終期レイテンシ・センシティブ適応バッチ処理のためのプロセスのフローチャートを示す。
【図4B】幾つかの実施形態による初期及び終期レイテンシ・センシティブ適応バッチ処理のためのプロセスのフローチャートを示す。
【図4C】幾つかの実施形態による初期及び終期レイテンシ・センシティブ適応バッチ処理のためのプロセスのフローチャートを示す。
【0012】
【図5A】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0013】
【図5B】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0014】
【図5C】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0015】
【図5D】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0016】
【図6A】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドを利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0017】
【図6B】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドを利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0018】
【図6C】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドを利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0019】
【図6D】幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドを利用するルック・アヘッド・イネーブル音声認識システムのブロック図である。
【0020】
【図7A】幾つかの実施形態による初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドのためのプロセスのフローチャートを示す。
【図7B】幾つかの実施形態による初期レイテンシ・センシティブ適応バッチ処理及び適応ルック・アヘッドのためのプロセスのフローチャートを示す。
【0021】
【図8】幾つかの実施形態によるクラウド・ベースの音声認識サービスのブロック図である。
【0022】
【図9】幾つかの実施形態による音声認識サービスのブロック図である。
【発明を実施するための形態】
【0023】
以下の説明は、説明される実施形態を当業者が生産及び使用することを可能にするために提供される。しかしながら、種々の変更は当業者にとって容易く明らかなことであろう。
【0024】
幾つかの実施形態によれば、アコースティック・モデルに同時に入力されるフレームの数（即ち、バッチ・サイズ）は、ASR処理中に動的に制御される。例えば小さなバッチ・サイズは、ワード仮説が生成されるまで使用される。小さなバッチ・サイズを使用することは、より大きなバッチ・サイズの場合よりも小さなレイテンシしかもたらさない可能性があり、なぜなら小さなバッチを収集するためには、同じサイズのフレームのより大きなバッチを収集する場合よりも少ない時間しか必要とされないからである。次いで、バッチ・サイズは、ワード仮説が生成された後に増やされてもよく、これは処理効率を改善する可能性があり、なぜなら、多数のフレームの同時処理は、より少ないフレームの処理よりもCPU効率やキャッシュ効率が良いからである。従って、ユーザーは、より大きなバッチ・サイズの処理の利点の大部分を維持しつつ、迅速にワード仮説の提示を受けることが可能である。
【0025】
幾つかの実施形態は、入力フレームの各バッチ内でルック・アヘッド・フレーム（look-ahead frames）を利用するモデルとともに動作可能であり、ここで、ルック・アヘッド・フレームの個数は、入力フレームの連続するバッチ間でオーバーラップする度合いに関連する。これらの実施形態はまた、上述したようにバッチ・サイズを動的に制御して、初期には低いユーザー知覚レイテンシを提供し、最初の仮説の後では、改善された処理効率を更に提供することができる。
【0026】
幾つかのモデルは、種々の数のルック・アヘッド・フレームを含む種々のサイズの入力バッチを受け取るように動作可能である。最初の仮説に応答してバッチ・サイズを動的に増加させることによって、このようなモデルを使用する実施形態は、初期には低いユーザー知覚レイテンシを提供し、その後、上述したように処理効率は改善される可能性がある。更に、認識精度の向上は、最初の仮説に応じてルック・アヘッド・フレームの個数を増加させることによって達成される可能性がある。
【0027】
この点に関し、このようなアコースティック・モデルは、初期に使用されるルック・アヘッド・フレーム数よりも大きい特定数のルック・アヘッド・フレームを考慮して訓練されることが可能である。従って、初期の動作は準最適ではあるが、ルック・アヘッド・フレーム数を、アコースティック・モデルが訓練された基礎とされたルック・アヘッド・フレーム数に変更することで、認識精度を向上させる可能性がある。また、実施形態は、バッチ・サイズを一定に維持しつつ、ルック・アヘッド・フレームの個数を変更することを許容する可能性がある。
【0028】
追加的又は代替的に、幾つかの実施形態は、スピーチ終了状態（end-of-speech state）を検出するために、仮説生成とは独立に入力フレームを監視する。この状態を検出すると、バッチ・サイズは、非スピーチ・フレームを待機することを回避するように削減されることが可能であり、そうでなければその非スピーチ・フレームが入力フレームの現在のバッチに加えられてしまうであろう。バッチ・サイズは、追加的又は代替的に、ストリームの終了、ターゲット最大処理時間、又はその他の状態、の検出に応答して削減されてもよい。従って、そのような実施形態は、バッチ・プロセスからの早期退出をサポートし、最終的な仮説の生成におけるレイテンシを減少させることができる。
【0029】
図1Aは、幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を利用する音声認識システム100を示す。システム100は、ハードウェア及びソフトウェア構成要素の任意の適当な組み合わせを使用して実現することができる。システム100の図示された機能、又は本件で別の方法で説明される機能の各々は、1つ以上の演算デバイス（例えば、コンピュータ・サーバー）、ストレージ・デバイス（例えば、ハード又はソリッド・ステート・ディスク・ドライブ）、及び当技術分野で既知である他のハードウェアによって実現されることが可能である。構成要素は、互いに離れて配置されることが可能であり、また、ソフトウェア・アズ・ア・サービス、プラットフォーム・アズ・ア・サービス、及びインフラストラクチャ・アズ・ア・サービス・プラットフォームを含むが、これらに限定されない1つ以上のクラウド・コンピューティング・プラットフォームの要素であるとすることが可能である。幾つかの実施形態によれば、1つ以上の構成要素は、1つ以上の訓練されたニューラル・ネットワーク・モデルを実行する1つ以上の専用仮想マシンによって実装される。
【0030】
フレーム生成ユニット110は、オーディオ信号を受信し、当該技術分野で知られているように、オーディオ信号のそれぞれのフレームに対応するフレーム・レベル振幅スペクトル、又は生のアコースティック特徴フレームを生成する。例えば、25msのオーディオ・フレーム・サイズを仮定すると、フレーム生成ユニット110は、到来するオーディオ信号の最初の25msに基づいて、最初の生のアコースティック特徴フレームs0を生成する。この点に関して、図1Aは、到来するオーディオ信号に基づくASRの開始の様子を示す。
【0031】
次の生のアコースティック特徴フレームは、到来するオーディオ信号の次の25msに基づいて生成されることが可能である。幾つかの実施形態では、時間的に隣接する生のアコースティック特徴フレームは、オーディオ信号のオーバーラップするフレームを表現することが可能である。例えば、第1の生のアコースティック特徴フレームs0は到来するオーディオ信号の第1の25msに基づいて生成されることが可能であり、第2の生のアコースティック特徴フレームは到来するオーディオ信号の15msから40msのフレームに基づいて生成されることが可能であり、第3の生のアコースティック特徴フレームは到来するオーディオ信号の30msから55msのフレームに基づいて生成されることが可能である。
【0032】
幾つかの実施形態によれば、生成された生のアコースティック特徴フレームは、当該技術分野で既知であるように、メル周波数ケプストラム係数又はログ・フィルタバンク特徴（Mel-Frequency Cepstral Coefficients or log-filterbank features）である。フレーム生成ユニット110は、到来するオーディオ信号のそれぞれのフレームに対応する生のアコースティック特徴フレームを決定するために、任意の適切な信号処理を実行することが可能である。例えば、フレーム生成ユニット110は、カスタム設計の高速フーリエ変換及びカスタム・フィルタバンク・パラメータを実装してもよい。
【0033】
バッチ化部120は、生のアコースティック特徴フレームをバッチにまとめ、そのバッチを、訓練済みのアコースティック・モデル130に提供するように動作する。訓練済みのアコースティック・モデル130は、種々のバッチ・サイズを有する入力フレームのバッチを処理することが可能な任意のアコースティック・モデルを含むことが可能である。例えば、訓練済みのアコースティック・モデル130は、片－方向の長・短期メモリ・モデル（LSTM）、双－方向のLSTM（BLSTM）モデル、又はレイヤ・トラジェクトリ（ltLSTM）モデルを含んでもよいが、実施形態はこれらに限定されない。
【0034】
以下に説明される幾つかの実施形態によれば、訓練済みのアコースティック・モデル130はまた、ルック・アヘッド・フレームを含む入力フレームのバッチを処理することが可能である。訓練済みのアコースティック・モデル130は、固定数のルック・アヘッド・フレームのみをサポートしてもよいし（例えば、文脈階層トラジェクトリ型のLSTM（contextual layer-trajectory LSTM，cltLSTM）モデル）、又は、変動する個数のルック・アヘッド・フレームを含むバッチをサポートしてもよい（例えば、レイテンシ制御型BLSTM（LC-BLSTM）モデル）。
【0035】
デコーダ140は、訓練済みのアコースティック・モデル130の出力に基づいてワード仮説を形成する。幾つかの非網羅的な実施例によれば、モデル130は、受け取った入力フレームのバッチに応じて、セノン事後確率（senone posteriors）を出力する。事後的隠れマルコフモデルに基づいて、デコーダ140は、所与の入力フレームS=s0…snの下で、最も確からしいワードのシーケンスW^=w0...wmを出力する（W^はWハットを表す）。
【0036】
バッチ化部120は、バッチが集められる基準となるルック・アヘッド・フレームの数及び／又はバッチ・サイズを決定することができる。本件で説明されているように、その決定は、デコーダ140によって生成されたワード仮説、及び/又は他の方法で検出されたスピーチ終了状態に基づいていてもよい。従って、バッチ化部120は、受信したワード仮説及び/又はスピーチ終了信号に基づいて、バッチ・サイズ（及び、幾つかの実施形態では、ルック・アヘッド・フレームの数）を決定する機能を実装してもよい。
【0037】
図1Bは、本実施例によるシステム200の引き続き行われる動作を示す。図示されるように、フレーム生成ユニット110は、入力オーディオ信号の第2の（オーバーラップしている可能性がある）フレームに基づいて、フレームs1を生成したところである。初期バッチ・サイズは2に設定されているものと仮定する。
【0038】
バッチ化部120は、図1Aに示すように、既にフレームs0を受け取っている。2という初期バッチ・サイズに起因して、バッチ化部120はフレームs0とs1をバッチ150にまとめて、バッチ150を訓練済みアコースティック・モデル130に提供する。モデル130は、当該技術分野で既知であるように、モデルのアーキテクチャ及び訓練済みパラメータ値に基づいて、対応する事後確率を出力する。事後確率はデコーダ140によって受け取られ、デコーダ140は仮説を形成しようと試みる。
【0039】
幾つかの実施形態によれば、上記のプロセスは、オーディオ信号のその後に受信されるフレームに関しても説明されたように続く。例えば、図1Cは、オーディオ信号のそれぞれのフレームに基づくフレームs10の生成を示す。この時点において、バッチ化部120は既にフレームs8とs9を集めてバッチ152に入れており、これらのフレームをモデル130に渡す。
【0040】
デコーダ140は、現時点に至るまでに受け取ったバッチに基づいて、非サイレントで非ノイズの仮説を生成するものと仮定されている。図示されているように、仮説はバッチ化部120に返される。仮説の生成に基づいて、バッチ化部120は、バッチ・サイズを増加させることを決定する。
【0041】
仮説に基づいてバッチ・サイズを変えること及び/又は新しいバッチ・サイズを決定することは、バッチ化部120とは異なる構成要素によって実行されてもよい。従って、このような構成要素は、新たなバッチ・サイズをバッチ化部120に送信することが可能であるので、バッチ化部120は、その後のバッチ処理を新しいバッチ・サイズに適合させることができる。
【0042】
新たなバッチ・サイズの決定は、最初に生成されたワード仮説によってトリガーされることが可能であるが、実施形態はそれに限定されない。決定は、n番目に生成されたワード仮説によって、ワード仮説の特定のサブセットのうちの1つ（又はそれ以上）の生成によって、又はデコーダ140によって出力されるワード仮説の任意の他の機能によってトリガーされてもよい。
【0043】
図1Dは、幾つかの実施形態による新たなバッチ・サイズの実装を示す。新たなバッチ・サイズは4であると仮定されているが、実施形態はこれに限定されない。従って、図1Cに示すように、バッチ152の出力の後に、バッチ化部120は、フレームs10ないしs14を集めてバッチ154に入れて、バッチ154をモデル130に提供する。これに対して、仮にバッチ・サイズが2のままであったならば、バッチ化部120は、フレームs10とs11のみを集めてバッチに入れて、そのバッチをモデル130に提供したであろう。
【0044】
図示されたプロセスは、ASRが終了するまで（例えば、オーディオ信号の終了に到達するまで）、4つのフレームから成るバッチを用いて継続することが可能である。幾つかの実施形態によれば、バッチ・サイズは、デコーダ140の出力に基づいてサイレンス（silence）を検出すると、初期バッチ・サイズ（例えば、2）に縮小され、また、ワード仮説に応答して上述したように再び増やされる。
【0045】
幾つかの実施形態において、バッチ・サイズは、ターゲット・バッチ・サイズまで徐々に増加してもよい。上記の例に関し、バッチ化部120は、特定の期間にバッチ・サイズを2から3に増加させ、次いで、バッチ・サイズを3から4に増加させてもよい。この増加は、経過時間の代わりに、又はそれに加えて、更なる仮説の作成に基づいて達成されてもよい。
【0046】
図2は、幾つかの実施形態による動的なバッチ処理を提供するためのプロセス200のフローチャートである。プロセス200及び本件で説明される他のプロセスは、ハードウェア及びソフトウェアの任意の適切な組み合わせを使用して実行されることが可能である。これらのプロセスを具現化するソフトウェア・プログラム・コードは、固定ディスク、揮発性又は不揮発性のランダム・アクセス・メモリ、DVD、フラッシュ・ドライブ、又は磁気テープを含む任意の非一時的な有形媒体によって記憶され、プロセッサ、プロセッサ・コア、及びプロセッサ・スレッドを含むがこれらに限定されない任意の数の処理ユニットによって実行される可能性がある。実施形態は、本件で説明される実施例に限定されない。
【0047】
プロセス200は、オーディオ信号に対してASRを実行するためのリクエストに応答して開始されてもよい。プロセス200は、例えば、クラウド・ベースのミーティング・プロバイダからリクエストや音声信号を受信するクラウド・ベースのASRサービスによって実行されることが可能である。オーディオ信号は、幾つかの実施形態に従って、ほぼリアル・タイムのストリームとして受信されてもよい。幾つかの実施形態において、プロセス200は、到来するオーディオ・チャネルに存在する何らかの信号を処理するために連続的に動作する。
【0048】
オーディオ信号を処理するための初期バッチ・サイズは、S210で決定される。初期バッチ・サイズは、予め定められた実験的に決定された値であってもよい。初期バッチ・サイズは、幾つかの値の中から、所望の初期レイテンシに基づいて選択されてもよく、ここで、より低いレイテンシは、より小さなバッチ・サイズに対応する。図1Aないし1Dの例を参照すると、2つのフレームの初期バッチ・サイズがS210で決定されている。
【0049】
オーディオ信号の生のアコースティック特徴フレームは、S220で収集される。収集された生のアコースティック特徴フレームの数は、決定された初期バッチ・サイズに等しい。従って、上記の例では、フローはS220で止まっている一方で、バッチ化部120はフレーム生成ユニット110からフレームs0とs1を受け取るまで待機する。
【0050】
収集されたフレームは、S230において、バッチとして音声認識ネットワークに入力される。音声認識ネットワークは、アコースティック・フレームのバッチに基づいて、ワード仮説を生成することが可能な任意のシステムを含むことが可能である。図1Aないし1Dの訓練済みアコースティック・モデル130及びデコーダ140は、何らかの実施形態による音声認識ネットワークを備える。
【0051】
次いで、S240において、ワード仮説が音声認識ネットワークによって生成されたか否かが判定される。より具体的には、S240は、音声認識ネットワークが、現在の時点に至るまでに受け取ったバッチに基づいて、非サイレント、非ノイズの仮説を生成したかどうかの判定を含んでもよい。生成していない場合、フローはS220に戻り、初期バッチ・サイズに一致する、フレームの別のバッチを収集する。従って、ワード仮説が音声認識ネットワークによって生成されるまで、S220、S230、及びS240の間でフローは循環する。上述したように、S240における決定は、最初に生成されたワード仮説の同定に限定されない。
【0052】
直線的なフローとして示されているが、S240における決定は、S220とS230の間のフローの循環とは独立して且つ並行して行われてもよい。例えば、フレームのバッチの収集及び入力は、生成されたワード仮説の別個の決定によって中断されるまで進行してもよく、その後、フローはS250に進む。
【0053】
S250では、オーディオ信号を処理するための次のバッチ・サイズが決定される。次のバッチ・サイズは、実験に基づいて予め決定されていてもよいし、及び/又は幾つかの可能なバッチ・サイズの中から選択されてもよい。幾つかの実施形態によれば、次のバッチ・サイズは、80フレームである。
【0054】
図1Dに関して説明したように、次のバッチ・サイズの生のアコースティック特徴フレームがS260において収集され、S270において音声認識ネットワークに入力される。幾つかの実施形態によれば、S280においてサイレンスが検出されるまで、S260とS270の間でフローは循環し、フレームのバッチを収集して入力する。S280におけるサイレンス検出は、一定期間を越える、音声認識ネットワークによって生成されるワード仮説の欠如の検出を含んでもよく、或いは及び／又は、それ以外の発見的な方法に基づいていてもよい。
【0055】
図示される例によれば、S280におけるサイレンスの検出は、プロセス200をS210に戻し、バッチ・サイズを初期バッチ・サイズにリセットすることを引き起こす。従って、オーディオ信号の後のフレームが音声を含む場合、その音声を処理するユーザーの知覚する待ち時間は、より大きなバッチ・サイズの結果として生じる待ち時間より小さくすることが可能である。
【0056】
初期バッチ・サイズから次のバッチ・サイズへ切り替えることは、顕著な遅延を処理に導入してしまう可能性がある。幾つかの実施形態は、S240における決定に応答して、バッチ・サイズをターゲット・バッチ・サイズまで徐々に増加させる可能性がある。例えば、バッチ・サイズは、ターゲット・バッチ・サイズに到達するまで、S260のn回の反復毎に所定数だけ増やされてもよい。
【0057】
プロセス200は、オーディオ信号の終端に到達した場合に終了してもよい。幾つかの実施形態では、プロセス200は、スピーチ終了状態の検出に応答して終了する。図3A及び3Bは、幾つかの実施形態によるそのような処理を示す。
【0058】
システム300は、上述したシステム100の構成要素にスピーチ終了検出器360を追加している。スピーチ終了検出器360は、生のアコースティック・フレームを、フレーム生成ユニット310から直接的に受信し、それに基づいてスピーチが終了したかどうかを判定する。スピーチ終了検出器360は、入力フレームに基づいてスピーチ終了状態を検出するための任意のシステムを含むことが可能であり、1つ以上の訓練済みのニューラル・ネットワークを含むことが可能である。一例において、検出器360は、デコーダ仮説とは独立に定式化され訓練されたLSTM分類器であって、過去のフレームのみに基づいてクエリの終了を予測するものである。検出器360は、オペレーショナル・ヒューリスティックス（operational heuristics）に関連して動作してもよい。
【0059】
動作の一例では、構成要素310、320、330、及び340は、上述のように動作して、初期バッチ・サイズを、4フレームの次のバッチ・サイズに修正するように動作している。従って、バッチ化部320は、モデル330への入力のために、フレームs10ないしs13のバッチ350を収集している。図3Aはまた、フレーム生成ユニット310からバッチ化部320及び検出器360へのフレームs16の伝送を示す。従って、フレーム生成ユニット310は、フレームs14とs15を既に生成しており、これらは次の4フレームのバッチを生成することを予想して、バッチ化部320によって収集されている。
【0060】
スピーチ終了検出器360は、フレームs16の受信に応答して、スピーチ終了状態を検出するものであると仮定されている。これに応じて、スピーチ終了検出器360は、検出された状態をバッチ化部320に通知する。次いで、バッチ化部320は、現在のバッチの最後のフレームとして、フレームs16を収集する。図3Bは上記の動作を示し、バッチ化部320がフレームs14，s15，s16を含むバッチ352を生成し、バッチ352がモデル330に入力されている。従って、最後のバッチのバッチ・サイズは、非スピーチ・フレームを待機することを避けるために縮小され、非スピーチ・フレームは、この例のようでなければ、入力フレームの現在のバッチに追加されていたであろう。従って、そのような実施形態は、バッチ処理からの早期の撤退をサポートし、最終的な仮説の生成におけるレイテンシを減少させることができる。上述のように、最終バッチ・サイズは、幾つかの実施形態による他の条件に応じて低減されてもよく、他の条件は、ストリーム終了状態の検出、及び最大認識時間経過の検出を含むがこれらに限定されない。
【0061】
図4Aないし4Cは、幾つかの実施形態による動的なバッチ処理を提供するためのプロセス400のフローチャートを含む。プロセス400は、図3のシステム300によって実施されてもよいが、実施形態はこれに限定されない。
【0062】
ステップS405、S410、S415、S420、及びS425は、プロセス200のステップS210、S220、S230、S240、及びS250のそれぞれと同様に進行することが可能である。説明されるように、到来するオーディオ信号を処理するための初期バッチ・サイズがS405において決定され、オーディオ信号の生のアコースティック特徴フレームの対応するバッチがS410において収集される。
【0063】
収集されたフレームのバッチは、S415において音声認識ネットワークに入力される。次いで、S420において、適切なワード仮説が音声認識ネットワークによって生成されたか否かが判定される。生成されていなければ、フローはS410に戻り、初期バッチ・サイズに一致する、フレームの別のバッチを収集する。生成されていれば、音声信号を処理するための次のバッチ・サイズが、上述したようにS425で決定される。
【0064】
次いで、S430において、次の生のアコースティック特徴フレームに基づいて、スピーチ終了状態が検出されたか否かが判定される。S430は、図3A及び3Bに関して説明したように、音声認識ネットワークから独立して動作するスピーチ終了検出器によって実行されてもよい。図3Aを参照すると、S430は、フレーム生成ユニット310からフレームを受信し、受信したフレームに基づいて（及び、例えば、以前に受信したフレーム及び/又は他の発見的方法に基づいて）スピーチ終了状態を評価することを含んでもよい。スピーチ終了状態が検出されなかった場合、フローはS435に続き、S435において次の生のアコースティック・フレームを収集する。フレームは、S435において、フレームの次のバッチ内に含めるために収集されることが可能である。この点に関し、S440において、次のバッチ・サイズに適合するバッチが収集されたか否かが判定される。収集されていない場合、フローはS430に戻る。
【0065】
S430における決定は、所望の数のフレームが収集されるまで、S430、S435及びS440の間のフローが循環するように否定的であり続けるものと仮定されている。次いで、フローはS445に続き、現在のバッチの収集されたフレームを、音声認識ネットワークに入力する。S450においてサイレンスが検出されなかった場合、フローはS430に戻る。従って、サイレンスがS450で検出されるか、又はスピーチ終了状態がS430で検出されるまで、フローは、S430とS450の間で循環し、現在のバッチ・サイズのフレーム・バッチを収集して入力する。S430におけるサイレンスの検出は、フローをS405に戻し、バッチ・サイズを初期バッチ・サイズにリセットすることを引き起こす。上述のように、音声信号の次に受信したフレームがスピーチを含む場合、そのスピーチを処理する際にユーザーに知覚されるレイテンシは、より大きなバッチ・サイズにより生じるレイテンシより低くすることが可能である。
【0066】
次のバッチ・サイズのバッチの収集中に、S430においてスピーチ終了状態が検出された場合、フローはS430からS455に進む。S455において、スピーチ終了状態が検出されたことに基づく次の生のアコースティック・フレームが収集される。図3A及び図3Bの例を参照すると、S430においてスピーチ終了状態がフレームs16に基づいて検出され、次いで、フレームs16はS455において現在のバッチの最後のフレームとしてバッチ化部320によって収集される。次いで、現在のバッチのサイズがS425で決定された次のバッチ・サイズよりも未だ小さかったとしても、S460において、現在のバッチの収集されたフレーム（s14，s15，s16）はモデル330に入力される。
【0067】
S420における決定は、S410とS415との間のフローの循環とは独立して且つ並行して生じてもよい。同様に、S430におけるスピーチ終了判定は、S435からS450までのフローのサイクルとは独立して且つ並行して行われてもよいし、又は代替的に行われてもよい。
【0068】
図5Aないし5Dは、幾つかの実施形態による動作中に初期レイテンシ・センシティブ適応バッチ処理を使用する先読み対応の音声認識システム500を示す。システム500は、当該技術分野で既知の“先読み（又はルック・アヘッド）”入力フレームをサポートする訓練済みのアコースティック・モデル530を含む。訓練済みのアコースティック・モデル530は、ルック・アヘッド・フレームを使用する任意のモデル・アーキテクチャを含んでもよく、そのモデル・アーキテクチャは、既知のもの又は知られつつあるものであり、レイテンシ制御型の双方向長・短期メモリ（LC-BLSTM）アコースティック・モデル及び文脈階層トラジェクトリ型の長・短期メモリ（cltLSTM）アコースティック・モデルを含むが、これらに限定されない。当技術分野で知られているように、cltLSTMモデルは固定数のルック・アヘッド・フレームのみをサポートすることが可能である一方、LC-BLSTMモデルは変動する個数のルック・アヘッド・フレームを含むバッチをサポートすることが可能である。
【0069】
図5Aは、バッチ化部520が、6つの生のアコースティック特徴フレームから成るバッチを収集する例を示しており、これらのフレームのうちの4つ（即ち、フレームs2，s3，s4，s5）がルック・アヘッド・フレームである。幾つかの実施形態において、バッチ・サイズは、開始フレームと終了フレームを含むウィンドウとして定義され、ルック・アヘッド・フレームは、オーバーラップ値によって定められる。例えば、バッチ550は、ウィンドウ{s0，s5}によって且つ4（フレーム）というオーバーラップ値によって定義されてもよい。
【0070】
図5Bは、この例に従って次のバッチ552を収集及び入力する様子を示す。バッチ552は、バッチ550の末尾の4フレーム（s2，s3，s4，s5）とオーバーラップし、ルック・アヘッド・フレームs4，s5，s6，s7を含む。従って、バッチ化部520は、バッチ552を生成するまでに、フレームs6とs7を待機しなければならない。
【0071】
上述したように、モデル130は、当技術分野で知られているように、そのアーキテクチャ及び訓練済みパラメータ値に基づいて、受信したバッチに対応する事後確率を出力する。事後確率は（図示されていない）デコーダによって受信され、デコーダは受信した事後確率に基づいてワード仮説を形成しようとする。
【0072】
ここで、デコーダは、図5Bに示す時点に至るまでに受信したバッチに基づいて、非サイレント、非ノイズ仮説を生成するものと仮定されている。仮説の生成に基づいて、バッチ化部520（又は別の構成要素）は、バッチ・サイズを増加させることを決定する。
【0073】
図5Cは、幾つかの実施形態による新たなバッチ・サイズの実装を示す。図5Cの例によれば、ルック・アヘッド・フレームの個数は固定されているが、実施形態はそれに限定されない。従って、この例は、固定数のルック・アヘッド・フレームを使用するcltLSTMモデルを使用する動作を示すことが可能である。
【0074】
図5Cに示すように、新たなバッチ・サイズは8フレームである。従って、次のバッチ554は、8つのフレームを含み、先行するバッチ552の最後の4つのフレームとオーバーラップしている。ただし、実施形態はこれに限定されない。バッチ554は、ルック・アヘッド・フレームs8，s9，s10，s11を含む。従って、図1Bに示すように、バッチ552の出力後、バッチ化部520は、フレームs8ないしs11を収集し、既に受信されているフレームs4ないしs7に追加して、バッチ554を生成する。
【0075】
図5Dは、修正されたバッチ・サイズに基づく動作を示す。バッチ化部520は、フレームs12ないしs15を収集し、これらのフレームを、既に受信されているフレームs8ないしs11に追加してバッチ556を生成する。バッチ556は、8フレームのバッチ・サイズを有し、4つのルック・アヘッド・フレームを含む。
【0076】
上述したように、バッチ・サイズは、幾つかの実施形態において、ターゲット・バッチ・サイズまで徐々に増加させてもよい。このような増加は、例えば、更なる仮説の作成、及び/又は最初の仮説以来の経過時間、に応じたものであってもよい。
【0077】
図5Aないし5Dは、ルック・アヘッド・フレームの個数が固定されたままである場合に、バッチ・サイズを変更する動作を示す。これに対して、図6Aないし6Dは、初期レイテンシ・センシティブ適応ルック・アヘッドを使用する先読み対応型の音声認識システム600を示す。
【0078】
フレーム生成ユニット610は、オーディオ信号を受信し、オーディオ信号のそれぞれのフレームに対応する、フレーム・レベルの振幅スペクトル又は生のアコースティック特徴フレームを生成する。バッチ化部620は、生成された生のアコースティック特徴フレームを、初期の指定されたバッチ・サイズ（又はウィンドウ）のバッチであって、指定された個数のルック・アヘッド・フレーム（又は指定されたオーバーラップ数）を有するバッチに収集する。訓練済みアコースティック・モデル630は、バッチを受信し、例えばセノン事後確率を出力し、これはワード仮説を生成するためにデコーダ640によって使用される。訓練済みのアコースティック・モデル630は、異なる個数のルック・アヘッド・フレームを含むバッチをサポートし、従って、幾つかの実施形態ではLC-BLSTMモデルを含んでもよい。
【0079】
図6Aの例では、初期バッチ・サイズは3であり、各バッチは2つのルック・アヘッド・フレーム（即ち、バッチ650のうちのフレームs1とs2）を含む。図6Bは次のバッチ652の出力を示し、これは、3つのフレームを含み、バッチ650のうちの2つのルック・アヘッド・フレームとオーバーラップしている。ここで、デコーダ640は、現在の時点に至るまでに受信されたバッチに基づいて、非サイレント、非ノイズ仮説を生成するものであると仮定されている。
【0080】
これに応答して、図6Cや図6Dに示すように、バッチ・サイズは4に変更され、バッチ当たりのルック・アヘッド・フレームの個数は3に変更される。従って、バッチ654は、バッチ652のルック・アヘッド・フレームs2及びs3とオーバーラップし、4つのフレームを含む。バッチ654の4つのフレームは、3つのルック・アヘッド・フレームs3，s4，s5を含む。目下、変更されているバッチ・サイズ及びルック・アヘッド・フレームの個数を考慮して、バッチ化部620は、4つのフレームを含む次のバッチ656を収集する。バッチ656の4つのフレームは、バッチ654のルック・アヘッド・フレームs3，s4，s5とオーバーラップするフレームを含み、また、ルック・アヘッド・フレームs4，s5，s6を含む。
【0081】
従って、実施形態は、バッチ・サイズ及び/又はバッチ当たりのルック・アヘッド・フレーム数を増加又は減少させることが可能である。何れかのパラメータに対する増加又は減少は、検出された仮説に応じて1回又は徐々に生じる可能性がある。
【0082】
幾つかの実施態様によれば、アコースティック・モデル630及びデコーダ640は、図6C及び6Dのバッチ・サイズとルック・アヘッド・フレームの個数を用いて訓練され、従って、第1ワード仮説の検出後に最適に動作する。従って、図6A及び6Bに示されるように、初期バッチ・サイズとルック・アヘッド・フレームの初期個数とに関連して動作する場合、アコースティック・モデル630とデコーダ640の精度は、ユーザーがより短いレイテンシしか知覚しないためのトレードオフとして、最適なものに及ばない可能性がある。
【0083】
図7A及び7Bは、幾つかの実施形態による動的なバッチ処理を提供するためのプロセス700のフローチャートを含む。プロセス700は、システム600によって実施されてもよいが、実施形態はこれに限定されない。
【0084】
入力オーディオ信号を処理するための初期バッチ・サイズは、S710において決定される。また、S710においては、各バッチに含まれるルック・アヘッド・フレームの初期個数も決定される。初期バッチ・サイズはウィンドウ・サイズとして指定されてもよく、ルック・アヘッド・フレームの個数は、ウィンドウ・サイズの特定の分数（例えば、1/2）として定義されてもよい。
【0085】
オーディオ信号の生のアコースティック特徴フレームは、S720において、初期バッチ・サイズとルック・アヘッド・フレームの初期個数とに基づいて収集される。図6Aの例に示されているように、3フレームの初期バッチ・サイズを仮定すると、フローがS720に留まる間に、バッチ化部620はフレーム生成ユニット610からフレームs0，s1，s2を受信するまで待機する。
【0086】
収集されたフレームは、S730において音声認識ネットワークへバッチとして入力される。音声認識ネットワークは、ルック・アヘッド・フレームを含むアコースティック・フレームのバッチに基づいて、ワード仮説を生成することが可能な任意のシステムを含んでもよい。
【0087】
次いで、S740において、オーディオ信号の生のアコースティック特徴フレームが、初期バッチ・サイズとルック・アヘッド・フレームの初期個数とに基づいて収集される。S740において収集されたフレームは、以前に収集されたフレームのルック・アヘッド・フレームとオーバーラップしている。図6Bを参照すると、バッチ652はS740において収集されることが可能であり、これは3つのフレームから成り、バッチ650のうちのルック・アヘッド・フレームs1及びs2とオーバーラップしている。S740で収集されたフレームは、S750において音声認識ネットワークにバッチとして入力される。
【0088】
先に収集されたフレームのルック・アヘッド・フレームとオーバーラップするフレームを収集することは、フレームの現在のバッチのウィンドウの開始を、先のバッチのオーバーラップするフレームの開始に設定することを含むことが可能である。例えば、オーバーラップがウィンドウ・サイズの半分であった場合、フレームの現在のバッチのウィンドウは、先のバッチのウィンドウの中央から始まるように設定される。
【0089】
S760は、ワード仮説が音声認識ネットワークによって生成されたか否かを判定することを含み、上述したように実装されてもよい。ワード仮説がまだ生成されていなかった場合、フローはS740に戻り、フレームの別のバッチであって、初期バッチ・サイズに合致し、ルック・アヘッド・フレームを含み、且つ前バッチのルック・アヘッド・フレームとオーバーラップする別のバッチを収集する。従って、ワード仮説が音声認識ネットワークによって生成されるまで、フローはS740、S750、S760の間で循環する。
【0090】
S760における判定が肯定的であった場合、オーディオ信号を処理するための次のバッチ・サイズがS770において決定される。次のバッチ・サイズの決定は、ルック・アヘッド・フレームの次の個数を決定することを含んでもよい。従って、S770は、バッチ当たりの新たなバッチ・サイズ及び/又は新たな個数のルック・アヘッド・フレームを決定することを含んでもよい。幾つかの実施形態では、S770は、次のウィンドウ・サイズを決定することを含み、次のルック・アヘッド・サイズは、次のウィンドウ・サイズの関数として決定される。上述のように、ルック・アヘッド・フレームの新たな個数は、任意数のルック・アヘッド・フレームを含むバッチを処理することが可能な音声認識ネットワークに関連してプロセス700が実行される場合に限り、決定されることが可能である。
【0091】
図6C及び図6Dに関連して説明したように、先のルック・アヘッド・フレームとオーバーラップする次のバッチ・サイズの生のアコースティック特徴フレームは、S775において収集され、S780において音声認識ネットワークに入力される。フローは、S785においてサイレンスが検出されるまで、S775とS780の間で循環し、フレームのバッチを収集して入力する。次いで、フローはS710に戻り、バッチ・サイズとルック・アヘッド・フレームの個数とをそれらの初期値にリセットし、その後に受け取った音声を処理する際にユーザーに知覚される待ち時間を減らす。
【0092】
プロセス400に関連して説明したように、プロセス700の実施形態は、スピーチ終了状態を独立して検出するためのスピーチ終了検出器を更に組み込んでもよい。検出に基づいて、最終バッチのサイズは縮小され（例えば、ウィンドウは短縮され）、スピーチ終了フレームに至るまでのもののみを含むことが可能である。
【0093】
幾つかの実施形態によるニューラル・ネットワーク（例えば、ディープ・ラーニング、深層畳み込み、又はリカレント型のもの）は、ネットワークに構成された一連の「ニューロン」、例えばLSTMノードを含む。ニューロンは、データ処理及び人工知能、特に機械学習で使用されるアーキテクチャであり、所与のニューロンに与えられた入力のウェイトに基づいて、いつ「想起」すべきか、またいつ「忘却」すべきかを決定することが可能なメモリを含む。本件で使用されるニューロンの各々は、ネットワーク内の他のニューロンから所定数の入力を受け入れて、分析されたフレームの内容に関するリレーショナル及びサブ・リレーショナル出力を提供するように構成されている。個々のニューロンは、発話中の各フレームが互いにどのように関連付けられているかについて相互作用及び関わり合いの学習モデリングを提供するために、ニューラル・ネットワークの様々な構成において、共に連結され及び/又はツリー構造に組織されることが可能である。
【0094】
例えば、ニューロンとして機能するLSTMは、入力ベクトル、メモリ・セル、及び出力ベクトルを処理するための幾つかのゲートを含む。入力ゲート及び出力ゲートは、メモリ・セルに流れ込む情報及び流れ出す情報をそれぞれ制御する一方、忘却ゲートは、ニューラル・ネットワークにおいて先にリンクされたセルからの入力に基づいて、メモリ・セルから情報を選択的に除去する。種々のゲートのウェイト及びバイアス・ベクトルは、訓練する段階において調整され、訓練する段階が完了すると、それらのウェイト及びバイアスは、正常な動作のためにファイナライズされる。ニューロン及びニューラル・ネットワークは、プログラム的に（例えば、ソフトウェア命令を介して）、又は各ニューロンをリンクしてニューラル・ネットワークを形成する特殊なハードウェアにより、構築されてもよい。
【0095】
図8は、幾つかの実施形態による分散されたトランスクリプション・システム800を示す。システム800は、クラウド・ベースであってもよく、その構成要素は、オンデマンド仮想マシン、仮想サーバー、及びクラウド・ストレージ・インスタンスを使用して実装されてもよい。
【0096】
スピーチ・ツー・テキスト・サービス810は、クラウド820を介して受信したスピーチ・オーディオ信号のトランスクリプションを提供するクラウド・サービスとして実装されてもよい。スピーチ・ツー・テキスト・サービス810は、上述のように動作するバッチ化部の構成要素、ASRモデル、及びデコーダを含み、本件で説明されるようなレイテンシ・センシティブ適応バッチ処理を用いてASRを提供する。
【0097】
クライアント・デバイス830，832の各々は、検索サービス840や音声アシスタント・サービス850のようなサービスを要求するように動作することが可能である。次いで、サービス840，850は、スピーチ・ツー・テキスト・サービス810から、スピーチ・ツー・テキスト機能を要求することが可能である。幾つかの実施形態によれば、クライアント・デバイス（例えば、スマート・スピーカ、スマートフォン）は、システム100又はシステム300のようなシステムの全ての構成要素を含み、動作は、クラウド・サービスとの通信を必要としない。幾つかの実施形態において、クライアント・デバイスは、フレーム生成の構成要素、バッチ化部の構成要素、ASRモデル、デコーダ、及びオプションとして、スピーチ終了検出器のうちの少なくとも1つを含み、クライアント・デバイスは、クライアント・デバイスに実装されていないこれらの構成要素のうちの何れかの機能にアクセスするために、遠隔システム（例えば、クラウド・サービス）を呼び出す。
【0098】
図9は、幾つかの実施形態によるシステム900のブロック図である。システム900は、汎用演算デバイスを含んでもよく、本件で説明されるように、レイテンシ・センシティブ適応バッチ処理を用いてASRを提供するためにプログラム・コードを実行してもよい。幾つかの実施形態によれば、システム900は、パーソナル・コンピュータ、スマート・スピーカ、及びスマートフォンのようなスタンドアロン・デバイス、又はクラウド・ベースの仮想サーバーによって実装されてもよい。
【0099】
システム900は、通信デバイス920に動作可能に結合された処理ユニット910と、永続データ記憶システム930と、1つ以上の入力デバイス940と、1つ以上の出力デバイス950と、メモリ960とを含む。処理ユニット910は、プログラム・コードを実行するための1つ以上のプロセッサ、処理コアなどを含んでもよい。通信インターフェース920は、インターネットのような外部ネットワークとの通信を促進することが可能である。入力デバイス940は、例えば、キーボード、キーパッド、マウス又は他のポインティング・デバイス、マイクロホン、タッチ・スクリーン、及び/又はアイ・トラッキング・デバイスを含んでもよい。出力デバイス950は、例えば、ディスプレイ（例えば、ディスプレイ・スクリーン）、スピーカ、及び/又はプリンタを含んでもよい。
【0100】
データ記憶システム930は、磁気記憶デバイス（例えば、磁気テープ、ハード・ディスク・ドライブ、及びフラッシュ・メモリ）、光記憶デバイス、リード・オンリー・メモリ（ROM）デバイス等の組み合わせを含む、任意数の適切な永続的ストレージ・デバイスを含んでもよい。メモリ960は、ランダム・アクセス・メモリ（RAM）、ストレージ・クラス・メモリ（SCM）、又は任意の他の高速アクセス・メモリを含んでもよい。
【0101】
バッチ化部932及びデコーダ936は、本件で説明されるような機能を提供するために実行可能なプログラム・コードを含んでもよい。バッチ化部932及び/又はデコーダ936は、幾つかの実施形態に従よる1つ以上の訓練済みのニューラル・ネットワークを含んでもよい。ノード・オペレータ・ライブラリ934は、当該技術分野で知られているように、ハイパーパラメータ938と訓練済みのパラメータ値939とによって規定されるアコースティック・モデルを提供するために実行可能なプログラム・コードを含んでもよい。また、データ・ストレージ・デバイス930は、デバイス・ドライバ、オペレーティング・システム・ファイルなどのような、追加の機能を提供するため、及び/又はシステム900の動作に必要な、データ及びその他のプログラム・コードを記憶することも可能である。
【0102】
本件で説明される各機能の個性要素及びプロセスは、少なくとも部分的に、当該技術分野で公知のように、コンピュータ・ハードウェアにおいて、プログラム・コードにおいて、及び/又はプログラム・コードを実行する1つ以上の演算システムにおいて実施されることが可能である。このような演算システムは、メモリ・システムに記憶されたプロセッサ実行可能プログラム・コードを実行する1つ以上の処理ユニットを含むことが可能である。
【0103】
上述したプロセスを具現化するプロセッサ実行可能プログラム・コードは、固定ディスク、揮発性又は不揮発性ランダム・アクセス・メモリ、DVD、フラッシュ・ドライブ、又は磁気テープを含む任意の非一時的な有形媒体によって記憶され、プロセッサ、プロセッサ・コア、及びプロセッサ・スレッドを含むがこれらに限定されない任意数の処理ユニットによって実行されることが可能である。実施形態は、以下に説明される実施例に限定されない。
【0104】
前述の図は、幾つかの実施形態によるシステムを説明するための論理アーキテクチャを表現しており、実際の実施形態は、他の方法で配置されたより多くの又は異なる構成要素を含んでもよい。他のトポロジーは、他の実施形態と共に使用されてもよい。更に、本件で説明される各構成要素又はデバイスは、任意数の他の公衆及び/又は私設ネットワークを介して通信する任意数のデバイスによって実施されてもよい。このような演算デバイスのうちの2つ以上は、互いに離れた場所に配置されていてもよく、任意の既知の方法のネットワーク及び/又は専用接続を介して互いに通信することが可能である。各々の構成要素又はデバイスは、本件で説明される機能及びその他の何らかの機能を提供するのに適した任意数のハードウェア及び/又はソフトウェア要素を含んでもよい。例えば、幾つかの実施形態によるシステムの実装において使用される何らかの演算デバイスは、プログラム・コードを実行するためのプロセッサを含んでもよく、その結果、演算デバイスは本件で説明されたように動作する。
【0105】
本件で説明された図は、図示された方法に固定された順序を意味しておらず、実施形態は、実行可能な任意の順序で実施されることが可能である。更に、本件で説明された何れの方法も、ハードウェア、ソフトウェア、又はこれらのアプローチの何れかの組み合わせによって実施されてもよい。例えば、コンピュータ読み取り可能な記憶媒体は、機械によって実行されると、本件で説明された何れかの実施形態に従う方法のパフォーマンスをもたらす命令を記憶することが可能である。
【0106】
当業者は、クレームから逸脱することなく、上述の実施形態の種々の適応及び修正を構築することが可能であることを理解するであろう。従って、クレームは、本件で具体的にされた以外のもので実施されてもよいことが理解されるべきである。
【図1A】
【図1B】
【図1C】
【図1D】
【図2】
【図3A】
【図3B】
【図4A】
【図4B】
【図4C】
【図5A】
【図5B】
【図5C】
【図5D】
【図6A】
【図6B】
【図6C】
【図6D】
【図7A】
【図7B】
【図8】
【図9】
【国際調査報告】