GOOG-411の構築体験[一人称視点]

M.バッキアーニ、F。ボーフェイ、J。シャルクウィック、M。シュースター、B。ストロープ



注釈

音声を使用した完全に自動化されたビジネス検索であるGOOG-411の開発と最適化の最初の経験について説明します。 システム開発への反復アプローチの採用により、システムのさまざまなコンポーネントを最適化し、ユーザーが対話する指標を徐々に改善する方法を示します。 認識精度に対するさまざまなデータソースの寄与を示します。 ビジネスオブジェクトのリストに基づいて構築された言語モデルの場合、トレーニングデータの対数全体で生産性がほぼ線形に向上します。 これまでに、正しい認識率が25％増加し、接続成功率が35％増加しました。



1.はじめに

GOOG-411 [1]は、音声を使用してビジネスオブジェクトを検索するためのサービスです。 ユーザーは、都市と州に名前を付けてから、特定のビジネスオブジェクトまたはビジネスカテゴリの名前（たとえば、「コンピューターストア」）を入力するように求められます。 音声認識システムは、音声ユーザーのリクエストを、ビジネスオブジェクトであるGoogleマップ[2]を検索するためにインターネットシステムに送信されるリクエストに変換します。 Googleマップは、ビジネスのソートされたリストを返します。 これがユーザーのクエリにどれだけ一致するかに応じて、音声合成（TTS）を使用して1〜8個のクエリ結果が生成されます。 ユーザーは、特定の結果を選択したり、電話でビジネスオブジェクトに接続したり、情報と地図を含むSMSを要求したりできます。 GOOG-411は現在、英語でのみ動作し、米国の何万もの都市にまたがっています。



411音声参照サービスの概念はかなり長い間研究されており（たとえば[3、4、5]を参照）、555 Tell [6]、Live Search 411 [7]、Free 411 [8]などのさまざまなサービスで実装されています。 ]アメリカで。 GOOG-411は実装された最初の411サービスの1つであり、ビジネスオブジェクトとカテゴリによる完全な検索が含まれており、難しい要求を処理する際にオペレーターへの切り替えはなかったようです。 この選択の主な前提は、データおよび関連するインジケータの処理に反復アプローチを実装することにより、システムが時間とともに自動的に改善されることでした。 オペレーターに切り替えることができると、ユーザーがシステムと対話する方法が変わります。 これを回避し、最終的なソリューションに集中するために、最初から演算子を使用しないことにしました。 システムアーキテクチャの概要を説明した後、GOOG-411を改善するために行うデータと測定の準備プロセスについて説明します。 次に、音響モデルと言語モデルの2つの主要コンポーネントにさらに焦点を絞り、高レベルの特性（UI）のレビューと時間の経過による改善で議論を終了します。



2.システムアーキテクチャ

図1は、GOOG-411システムの主要コンポーネントを示しています。 電話ネットワーク、音声アプリケーションを起動するアプリケーションサーバー、TTSサーバー、音響モデル、言語モデル、音声モデル（AM、LM、PM）を備えた認識サーバー、ビジネスリクエストを実行するためのGoogleマップサービス、およびモバイルユーザーへの情報転送。 これらの各コンポーネントには、独自のバックアップコピーと負荷分散の可能性が含まれています。これは、多くのプロセスが非同期であるこのダイアログシステムが全体としてかなり複雑な構造的構成であるためです。 冗長性、自動配信にはGoogleインフラストラクチャ（マシングリッド、GFS [9]、Bigtable [10]）を使用しています。 サービスの信頼性とスケーラビリティを確保するための、複数のネットワークによるプロセスの実装（マルチホーム実装）も同様です。 現在のインジケータを使用してシステムを監視し、リアルタイムで新しく受信したデータを使用して、システムの品質を制御できます。





図 1. GOOG-411フローチャート



3.データの準備プロセスと測定

システムの重要な側面は、データの最適化です。 この目的のために、広範なデータ準備システムを作成しました。 すべての着信呼び出しを分析してシステムの実行可能性を判断し（コンポーネントの障害などを確認）、その品質を監視します（たとえば、呼び出しのどの部分がダイアログのエンドポイントに到達したかなど）。 その後、このデータは保存され、復号化されて、さらなる分析、およびシステムの主要コンポーネントの再配置に使用されます。 次に、このデータは機能しているシステムで更新されます。 その間、テストには新しいデータが使用され、残りのデータはトレーニングセット用にグループ化されます。 このテストアプローチにより、ユーザーインターフェイスとインフラストラクチャの変更を制御し、使用パターンの変化を追跡し、古いテストセットアップの使用を回避できます。



認識精度を評価するための主な指標は受信動作曲線（ROC）です。これは、正しく認識された信号（correct-accept、CA）と誤認識された信号（false-accept、FA）の比率を示します。 それらは、認識結果の意味解釈において文レベルで評価されます。 たとえば、「イタリアンレストラン」ではなく「イタリアンレストラン」の認識は正しい認識と見なされます（信頼係数が特定の所定のしきい値を超える場合、仮説は除外されます）。



システムレベルで、成功した接続のレート（転送レート）、つまり ユーザーが企業に接続するか、要求の結果の詳細を含むSMSを受信するコールの割合。 多少簡略化すると、この指標は、最初の近似値では、ユーザー満足度の確実な指標であると言えます。 第6章に示すように、ユーザーインターフェイスの変更、インフラストラクチャの改善、精度の向上が反映されています。



最後に、製品レベルで、トラフィックの変化を監視します。これは、このサービスの成功を示す別の指標です。 次の2つのセクションでは、音響学と言語モデリングの分野での実験をさらに詳しく調べます。 ここおよび第6章で結果を提示するとき、絶対値のインジケータを意識的に避け、代わりに相対的なもののみを示します。 一部は競争上の理由によるものであり、一部は絶対数がコンテキストから簡単に誤ってしまうためです。 たとえば、絶対数は、理解できない発話または無音を含むテストセットから文を保存するか削除するか、およびそれらの頻度に依存します。 また、バックエンド検索が計算に含まれるかどうかにも依存します。 成功した接続の速度（転送速度）は、ユーザーが何かを言う前に電話を切るときに統計に呼び出しを含めるかどうかによって異なります。 それでも、相対的な指標が科学界にとって有益であることを願っています。

以下で説明する実験は、関心のある読者が1-800-GOOG-411（1-800-466-4411）を呼び出すことで使用できる既存のサービスのパフォーマンスを反映しています。 一般に、このサービスはユーザーから肯定的なフィードバックを受け取り、音声認識の高精度（50〜80％の範囲の認識精度レベル）を実証しており、ユーザーにとって有用であり、商用システムに匹敵します。



4.音響モデル

音声認識システムは、GMMトライフォンHMM、ツリーモデル、STC [11]およびFST検索[12]に基づいた、PLPおよびLDAプロパティを備えた大きな辞書で実行される標準認識エンジンです。 システムをトレーニングするには、mapreduceフレームワーク[13]で最大限の最適化を実行する必要があります。これにより、現在数百台のマシン上に大量のデータがある場合でも、数時間以内に既製のモデルを取得できます。 このセクションで比較される音響モデルは、性別に依存しない単一サイクルであり、GOOG-411サービス音声サンプルのみでトレーニングされています。





図 2.トレーニング音響データの量に応じたパフォーマンス指標。



図2は、増加するデータ量でトレーニングされた多数のモデルの相対的な有効性を示しています。 このテストは、3,000以上の都市を対象とする「会社名またはカテゴリを教えてください」という質問（「会社名またはカテゴリを教えてください」）に応えて、最近収集した約20,000の文で構成されます。 音響モデルと言語モデルの構造は、常に一連の実験を経ています。 トレーニングセットはグループ化されているため、年の前半、第1四半期、第1か月などに収集したすべてのトレーニング資料の結果を表示できます。 最も広範なトレーニングセットには、数千時間のスピーチのサンプルが含まれています。



トレーニングデータの量によって認識の品質が劇的に向上するわけではないことに注意してください（トレーニングデータの増加率が64で、誤認識[FA]の10％による正しい認識[CA]の8％）。 理由の1つは、トレーニングデータが音声セットと音響セットの両方でトレーニングセット用に定性的に準備されていることです（リクエストのある同じユーザーがシステムのトレーニングとそのテストに参加できますが、おそらく異なる呼び出しで同じデバイスで、同じリクエストを行うこともあります）。 もう1つの理由は、この事実をまだ十分に研究していないことです。



5.言語モデル

言語モデルは、n-gram統計言語モデル（SLM）と文脈自由文法の組み合わせです。 これらは3つのデータソースでトレーニングされ、データセットの処理におけるROCの最適化を促進します。



そのため、まず、ビジネス施設と場所に関するデータがあります。これらは必要なカバレッジを提供しますが、会社の正式名称は、たとえばGoogleなどの人々の呼び名と必ずしも一致しません。 「Google Inc.」または「Starbucks」vm。 スターバックスのコーヒー。



次に、Google MapsサービスへのWebリクエストのログがあります。これは、GOOG-411サービスに最適な印刷されたリクエストの広範なボディです（ユーザーは、「Google」または「Starbucks」を入力して必要な答えを得ることができることをすでに知っています） リクエストデータはLMの可能性を判断するために使用されますが、GoogleマップとGOOG-411での優先順位は常に一致するとは限りません。たとえば、「不動産」は頻繁なWebリクエストですが、まれな音声リクエストです。



第三に、音声ベースがあります。GOOG-411サービスの呼び出しを通じて収集された書き起こし音声は、最も適切なタイプのデータであることがわかりました。 以下のすべての実験では、リアルタイム認識に近づき、システム全体の待機時間を制限するために、言語モデルが削減されています。





図 3. LMデータのタイプに応じたパフォーマンスインジケーター。



図3は、LMデータ型に応じたシステムパフォーマンスを示しています。 現在、Webログデータは、2 LM間で10％の誤った認識に対して6％の正しい認識の割合で、最適な言語モデルが音声ベースで構築されたものであることを示しています。 ビジネスオブジェクトのパフォーマンスは非常に悪くなります。 3つのデータソース（コンボ）を組み合わせると、さらに5％の正しい認識（Web LMの上）が得られます。





図 4. LMトレーニングデータの合計の関数としての音声データに基づくLMパフォーマンスインジケーター。



図4は、音声データの量の関数として、音声データでのみ取得されたビジネスオブジェクトのLMの効率を示しています。 ここでも、トレーニングデータの指標は2ポイント異なります。 対応するROCはほぼ同じ位置にあるため、トレーニングデータログから、LMの精度が直線的に向上すると結論付けることができます。 このインジケーターの場合、音声データの貢献度は（現在の）Web要求の貢献度に対応します。これは、4倍の音声データを収集する場合に限ります（Webデータの量よりも1桁少ない場合でも）。





図 5. LMトレーニングデータの種類と量の関数としてのパフォーマンスインジケーター。



図5は、LMスピーチトレーニングデータの種類（Web、スピーチ、組み合わせ）とサイズに応じた「askCityState」ダイアログの有効性を示しています。 askCityStateは単純なタスクであるため、直線的には増えません。 ここで、音声データはWebデータのように機能し、多くのメトリック（完全な住所など）を使用して、リクエストから都市と州を分離するために大幅に処理されています。 このような処理を行わないと、Webデータは指標の非常に大きな偏差を示しました。 音声と（処理された）Webデータの組み合わせにより、最高品質の認識が提供されます。 サイトおよび場所のデータベースには、追加の利点はありませんでした。



6.改善のための一般的な方向

このセクションでは、GOOG-411の経時的な進化の一般的な見解を示します。 統計モデルの変更、ユーザーインターフェイスの変更、サービスの内部構造の変更、エラーの修正、休日などの外部イベントなど、多くの要因がこのサービスの使用の構造に影響します。





図 6.常時パフォーマンス指標。



図6は時間認識機能を示しています。 各ROCは、異なるテストセットで収集されました（セクション3で説明されているテスト概念を参照）。 これらの数値は、過去7か月間で10％の正確な認識率で、約25％向上したことを示しています。





図 7.一時的な機能としての毎日の交通





図 8.経時的な成功率。



図7と8は、1日あたりの着信コール数と、1年間の接続成功率を示しています。 ここにいくつかの興味深い点があります。 グラフのポイントAとBは、広告キャンペーンを増やしたときのトラフィックの増加を示しています。 ポイントC-システムの一時的な中断。 両方のグラフのポイントEは、トラフィック量の大幅な増加と接続成功率の大幅な低下を伴うGOOG-411サービスの正式な開始を示しています。ユーザーはシステムを実験しており、企業に到達しようとはしていません。 ポイントDは、正式なローンチ前の穏やかな期間に対応します。サービスの広告掲載を停止（通話料金の減少）したため、加入者は主に予約によりこのサービスに接続したユーザーでした（接続成功のピーク率）。



成功した接続のグラフのポイントFは、ユーザーインターフェイスでの実験の開始を示しており、ユーザーへの発行結果を減らしました。 これにより、人々は会社をより頻繁に呼び出すようになります。 ポイントGは、アメリカ全州へのサービスの配信を示します。 かなりの数のリクエストに対して発信者の一部に誤った結果が提供された場合、ポイントHは興味深いエラーを示します。 これは、正常な接続の低下に反映されていました。 ポイントJおよびKは、テレフォニーインフラストラクチャの障害を示しています。これは、接続の成功率の低下とも関連しています。 ポイントIは7月4日[独立記念日]であり、ユーザーはおそらくショッピングのためにビジネスオブジェクトに接続することに関心を持っていたでしょう。

曲線をより詳細に分析できます。 しかし、トラフィックのインジケータも接続インジケータも、イベントに関する驚くほど広範な側面を反映し、システムの運用と開発を監視するのに非常に有用であるという事実にもかかわらず、ユーザーに関するすべてを教えてくれないことは明らかです。 曲線には、決定が困難な多くの要因の結果である多くの障害があります。 これはオンライン実験を複雑にします。 もちろん、ユーザーインターフェイスのわずかな変更は可能ですが、接続が成功したことを示すインジケータへの影響は明確ではありませんが、間違いなく最終的に表示されます。 これを行うには、より少数の指標を見つけることに頼らなければならず、最終的には認識モデルを最適化するときと同じように、すべてをより良い方向に行っていると信じなければなりません。



7.結論

そこで、反復的なアプローチを使用して、音声クエリに基づいたかなり複雑なシステムを作成、適用、開発しました。 データ、測定値に焦点を合わせ、システムを絶えず改善することにより、音声認識の精度などの低レベルの指標と、ユーザーに関連する高レベルの特性を迅速に改善できることを示しました。 一般的に、製品スタック全体に自由にアクセスして柔軟に変更できる機能と、増加するデータの安定したストリームを使用できることが、時間とともにサービスを一貫して改善するための重要な要因であることがわかりました。



8.リンク



[1]「GOOG-411」 http://www.google.com/goog411



[2]「Googleマップ」 http://maps.google.com



[3] L. Boves等、Proc。の「自動ディレクトリ支援のためのASR：SMADAプロジェクト」。 ASR、2000、pp。 249–254。



[4] N. Gupta et al。、「AT＆T音声言語理解システム」、IEEE Trans。 ASLP、2006、pp。 213–222。



[5] D. Yu et al。、「ディレクトリ支援の自動化-理論から実践まで」Proc。 Interspeech、2007年。



[6]「555 Tell」 http://www.tellme.com/products/TellmeByVoice 。



[7]「ライブ検索411」 http://www.livesearch411.com



[8]「無料411」 http://www.free411.com 。



[9] S. Ghemawat et al。、Procの「The google file system」。 SIGOPS、2003、pp。 20–43。



[10] F. Chang他、「Bigtable：構造化データ用の分散ストレージシステム」Proc。 OSDI、2006、pp。 205〜218。



[11] MJFゲイルズ 「隠れマルコフモデルの準結合共分散行列」Proc。 IEEE Trans。 SAP、2000年5月。



[12]「OpenFstライブラリ」 http://www.openfst.org



[13] J.ディーン他、「Mapreduce：大規模クラスターでのデータ処理の簡素化」、Proc。OSDI、2004、pp。137-150。



おそらく、完全を期すために、Bill ByrneがGoogleサービスの音声回線について語っているビデオへのリンクを提供します。