End-to-End音声認識の高速化を実現するために　LINEが取り組む研究開発とGPUの効率的な利用

レイテンシーの問題

木田祐介氏：それでは、後半のパートは私、木田から発表します。

まず簡単に自己紹介します。私はLINEでSpeechチームという音声認識技術の研究開発を行うチームのマネージャーをしています。これまで、東芝の研究所やヤフーで音声認識技術の開発に従事していまして、2020年に入社しました。どうぞよろしくお願いします。

私のパートでは、今我々が力を入れている、End-to-End音声認識の高速化を中心にお話ししようと思います。

ヒョクスさんのパートでもお話があったように、End-to-End音声認識は、非常に魅力的な技術です。しかし、あらゆる側面において常に万能というわけではありません。特に精度の高いEnd-to-Endのモデルは、音声信号全体を一度読んだあとに認識をスタートするような仕組みになっていまして、認識結果を出すまでに時間がかかってしまいます。

こちらに簡単な例をお見せします。

（「Highway and freeway mean the same thing.」という音声が流れる）

はい、このように音声が終わってから結果が出るまでの間に、間が空いていることがわかると思います。この間のことをレイテンシーと呼ぶのですが、このレイテンシーが大きいと、リアルタイムの字幕だったり、対話的なアプリケーションに音声認識を適用したりするのが難しくなるのは、想像してもらえるかと思います。

またこのレイテンシーは、処理する音声の時間に応じて長くなるので、長い音声を処理する場合には、さらに深刻な問題となってしまいます。

End-to-End音声認識はなぜレイテンシーが大きいのか

では、End-to-End音声認識はなぜレイテンシーが大きいのか、その理由について説明していこうと思います。こちらは、End-to-End音声認識に使われる代表的なモデルの1つ、Transformerをモチーフにして説明しようと思います。

レイテンシーの原因の1つは、こちらのエンコーダー部分のSelf-Attentionという処理にあります。このSelf-Attentionという処理は、ある時刻の特徴を計算する時に、入力音声全体を参照します。

この図でいうと、左から2番目の丸のところの時刻を計算しようとしているんですが、ここの時刻の特徴を計算する時に、周りのすべての情報を参照しているというのがおわかりいただけるかと思います。

というわけで、先ほど音声信号全体を読んでから認識をスタートしているとお話ししましたが、その理由はここにあるわけです。

そこで、このSelf-Attentionの計算を近似的に行うということで、レイテンシーを小さくする方法が盛んに提案されています。基本的なアプローチとしては、どれもSelf-Attentionを計算する範囲を限定する方式を採っています。

チャンクベースのデコーディング

ここではその1つのやり方である、チャンクベースのデコーディングを説明しようと思います。

この方法は、今黄色の枠で囲っている、固定長のチャンクというのを用意して、そこに入力音声を逐次的に格納していきます。チャンクが満たされた時点でその区間の音声を使ってSelf-Attentionの計算を行って、そのままデコードまでやってしまいます。

当然、ここで出てくる認識結果は途中までのものになるんですが、これを、チャンクを移動させながら繰り返し処理を行うわけです。そうすることで音声がどんどん流れていきますが、その流れに遅れずに追随して認識結果を次々に出せます。そして、結果的にレイテンシーも短くできます。このようなアプローチになります。

また、こうした近似を行うことで、精度にどの程度影響が出るのかは当然気になるところなんですが、やはりチャンクのサイズを短くしていくと、だんだん精度が悪くなっていく傾向があることが、これまでの検討でわかっています。

そのため、精度とレイテンシーのバランスのいいところを取るために、チャンクサイズを調整したり、このモデル構造やアルゴリズム自体を試行錯誤したり、そういったことが実用上は必要になってきます。

自己回帰的な認識の課題

続いて、レイテンシーの発生原因の2つ目についてお話しします。それはこちらの部分、デコーダにあります。Transformerのデコーダは、エンコーダから特徴を一括で受け取ると、前から1つずつ順番に認識結果を出力します。例えばこの音声は最初に「Hightway」としゃべっているんですが、そうするとデコーダのほうでも、何もないところから、1番目は「Hightway」という単語を出力します。

その次が肝なんですが、2番目の単語を出力する時は、1番目に「Hightway」という単語を予測したという事実を利用して、2番目の単語を予測します。こういうような挙動で認識を行います。

こういうやり方を自己回帰的というんですが、こういう自己回帰的な認識は、人間にとっても自然に思える方法ではあるんですが、デメリットとしては、一括して処理が行えない。シーケンシャルに処理するので、そこにどうしても時間がかかってしまうということで、これがレイテンシーの原因になってしまいます。

それに対しまして、最近はこのような自己回帰性をなくした、非自己回帰的、英語でいうとNon-Autoregressiveな認識を行うという手法が、注目を集めています。

この方法は、デコードの処理を、ここの図で表しているように一括で並列に行うわけです。先ほどのように、順々にシーケンシャルするという構造にはなってなくて、すべての文字を並列に、どんと一括で出す方法になります。

そのため、エンコーダ側に、通常のSelf-Attentionを使って、非常に時間のかかる処理を行ったとしても、このデコーダ側の並列化のメリットを活かして、非常に少ないレイテンシーを達成できます。こういうメリットがある手法になります。

ただやはり、前にどういう単語を予測したかという情報をまったく使わずに認識を行うことになるので、精度的にはやはり、自己回帰的なモデルには及ばないというのが現状です。

Non-Autoregressive ASRの新たな手法

今日は、このNon-Autoregressive ASRについて、新たな手法を最近我々が提案しまして、大変よい結果を出せたので、ここからその手法について紹介しようと思います。

我々の手法のベースになるモデルというのは、実はこれまでに説明してきたTransformerのモデルではなくて、「CTC」という別のやり方になります。ただこのモデルも、先ほど説明したNon-Autoregressiveな手法が取れて、すべての結果を並列に出力できる。この点においては同じです。

CTCのモデル構造は、一般的に複数のエンコーダレイヤーと、1層のデコーダレイヤーからなる構造です。

このモデルを学習する際には、音声の信号と、それに対応する人間が書き起こしたテキストをペアで用意しておいて、音声をネットワークに入力すると、そのモデルが予測するテキストと、あとは人間が用意したテキスト、こちらの誤差がなるべく小さくなるように、このモデルのパラメータを学習します。これは一般的な音声認識のモデル学習に通じる話となります。

この時、誤差の情報は、ここの矢印で今書いたように、なるべく出力層に近い部分では強く残るのですが、入力層に近づくにつれて、情報が薄まっていってしまう特性があります。

この図の中でいうと、矢印の色の濃さが情報の濃さをイメージ的に表しています。つまり、入力層に近いエンコーダは、なかなか音声認識に役立つ方向にパラメータを学習させることが難しい特性があるわけです。そこで我々は、ここに改善のポイントがあるのではないかと着目して、提案を行いました。

NAVERから発表されたのは、こちらの「InterCTC」というモデルになります。このモデルは、エンコーダの途中からネットワークを分岐させて、分岐させた先をデコーダに接続するような構造です。ちなみに、この右側のデコーダと左側のデコーダのパラメータは共有しています。

このように、ネットワークを組んで学習を行うことで、先ほどは左側のパスから誤差が降りてくるようなかたちだったんですが、右側のネットワーク、ここではサブネットワークと呼んでいますが、このサブネットワークを経由して、情報が強い状態で入力層の付近に到達できます。

これによって、ネットワークの入り口に近い段階から、音声認識に有用な特徴量が抽出できるのではないかと、そういうことを狙ったアプローチです。

一方、認識する時が、右側の図のInferenceと書いてあるほうですが、認識する時はこちらのサブネットワークは使わずに、通常どおりの計算を行います。なので、ここは少しもったいないような気がします。そこに目をつけてさらに改良を加えたのが、LINEのリサーチャーが提案した、「Self-Conditioned CTC」というモデルです。

この方法では、モデルを学習する時に、サブネットワークに一度認識させて、そのネットワークを使うという部分は先ほどと同じですが、サブネットワークに一度認識させて、その事後確率の分布を次の層のエンコーダの入力に加えるというところが特徴です。

この図でいうと、黄色い太い矢印があると思うんですが、その矢印が左側のレイヤーにまた返ってくるところが特徴になります。こうすることで、サブネットワークでの予測結果に条件づけられた上で、次の最終層の予測を行えます。

わかりやすく言うと、ある程度右側のネットワークを使って、当たりをつけた上で本番の認識を行うアプローチになります。これによって、さらに高い精度が得られるのではないかと考えたのが、こちらのモデルです。

また、先ほどのInterCTCとは違う点として、右側に書いているとおり、認識を行う時にも学習時と同じように、サブネットワークを使うところもポイントです。

それではこちらの手法の実験結果について説明します。この表は、英語とか日本語を含む複数のベンチマークセットに対して、さまざまな手法で音声認識の精度と速度を比較した表です。

点線より下の結果が、非自己回帰型の音声認識の手法をいくつか比較したもので、一番上のCTCと書かれたところが、ベースラインになります。

こちらのSpeedupと書かれている数字が大きいほど認識の速度が速くて、右側にある数字が認識の誤り率を表しています。こちらの数字が小さいほうがよいということを表しています。

ここの9種類の手法が今、NARと書かれているところにあるんですが、この9種類の手法のうち、我々の提案したSelf-Conditioned CTCが、スピード的には最も速くて、かつ、すべてのベンチマークセットに対して最もよい結果を示したということがわかってもらえるかと思います。

というわけで、非常によい結果を出せたのではないかと考えていまして、我々はさらにこの分野での研究も進めていくと同時に、この研究で得た知見をプロダクトのほうにも活かしていこうと思っています。

End-to-Endモデルを使ったサービス運用

ここから少し話題を変えまして、学習したEnd-to-Endのモデルを使ったサービス運用の話をしようと思います。

LINE AiCallのようなサービスでは、同時多並列に音声認識のリクエストがサーバーにやってきます。そのため、一つひとつのリクエストに対して、短いレイテンシーで結果を返す必要が出てくるわけです。

ただし、End-to-Endのモデルを使う場合にそれを行うのは、なかなか一筋縄ではいかない課題となります。まずEnd-to-Endの音声認識で精度を出すためには、ある程度大きなモデルを使う必要がありますが、そうするとハードウェアとしては、やはりGPUを使う必要が出てきます。しかし、リクエストをシーケンシャルにさばくような実装をしてしまうと、GPUの性能を最大限活かせないという課題が出てくるわけです。

ちょっとここに具体例をお見せしますが、この図は、A、B、Cという3つの音声発話がほぼ同時にサーバーに到達したという様子を表しています。

それぞれの発話は、複数のチャンクで構成されていて、今このGPUには2つ、そのチャンクを処理できるスロットがあると仮定します。今単純にこのリクエストが来た順番に1番目のスロットに常に割り当てるというような、あまり賢くない実装をすることを考えると、最初にC1を処理して、次に2番目にA1が来て、次にC2が来てという感じで、シーケンシャルに、1つずつスロットにチャンクを割り当てていくわけです。

そうすると、やはりこのように同時多並列にリクエストが到達してしまいますと、一つひとつのリクエストに対するレイテンシーがすごく大きくなってしまって、これではサービスに活かせないということがあります。また、デコードの中間状態を保持するようなモデルを使う場合には、いったんGPUから情報を退避したり、再度ロードしたりなどをしないといけません。

今こちらの例でいうと、C1を処理したあとにA1に切り替えて、また今度、C2にする。その時にC1の中間結果の状態を一度GPUから退避して、C2を処理する時にもう一度戻す。そういったことをやらないといけなくなるので、このあたりの煩雑な処理がレイテンシーをさらに大きくしてしまう課題もあります。

そこで我々は、この問題に対処するために、GPUの製造元として世界的に知られているNVIDIAさんと協議して、こうしたGPUの効率的な利用の課題などに取り組んでいます。

例えば先ほどの例に対しては、NVIDIAが提供する「Triton Inference Server」をうまく使うことでレイテンシーを大幅に下げられます。このTriton Inference Serverというのは、GPUを使用して機械学習モデルを高速に推論するサーバーを構築するフレームワークです。

先ほどの例で、Tritonを使うことでどのように解決できるのかを少し紹介したいと思います。Tritonを使うと、GPUのスケジューリングをすごく簡単にカスタマイズできます。

例えば、1つのリクエスト、今最初にC1が到達しているんですが、到達したとしてもすぐにこれを処理し始めるのではなく、この2つのスロットにすべてチャンク埋まるまでは少し待つという遊びの時間を設けて、少し待っている間に今度A1が来るので、そこで2つのバッチを構成して、その2つでGPUに、処理を動かします。そういうような処理を行うことで、レイテンシーを下げられます。

また、先ほどの中間状態の退避やロードが頻繁に起きる問題に対しては、一度割り当てたリクエストのIDをスロットのほうに覚えさせておいて、そのIDのチャンクが終了するまではそのスロットを占有させるような制御ができるわけです。

そういう制御を行うことで、全体のレイテンシーが小さくなるようにできます。Tritonを使うことで、今言ったような設定が、コンフィグファイルを書き換えるだけで簡単に可能になります。

LINE・NAVER両社のSpeechチームの研究成果

最後にLINE・NAVER両社のSpeechチームの2021年の研究成果についても触れておきたいと思います。音声分野には、大きく「ICASSP」「INTERSPEECH」という2つのトップカンファレンスがあるんですが、今年は両方の会議でLINE/NAVERのSpeechチーム合計で9件ずつ論文を発表できました。

この数字は、Googleやマイクロソフトなどのグローバルトップに比べるとまだまだではあるのですが、東アジアでは存在感を着実に高められていると思います。今後も、引き続き大学との共同研究などを活かしながら論文発表にも力を入れていこうと思います。

それではこのあたりで、このセッションを締めくくらせていただこうと思います。まず前半のセッションでは、新しい音声記録サービスCLOVA Noteについてご紹介しました。ぜひ日本でのリリースもお待ちいただいて、実際に試してみてもらえるとうれしいです。

次に後半では、End-to-End音声認識の高速化の取り組みについてお話ししまして、NVIDIAのTritonを使ったGPUの効率的な利用などについてもお話ししました。最後に、我々はさらなるイノベーションを生み出し続けるために日々努力しています。LINE、NAVERの音声認識技術の発展に、今後もぜひご期待ください。

それでは、以上でセッションを終わります。ご清聴いただきありがとうございました。