「応答速度」「演算量の多さ」「カスタマイズの難しさ」　End-to-End音声認識のプロダクト化でハードルになる3つの課題

応答速度が遅い理由

次にプロダクト化に向けての課題と取り組みについて話します。こちらは、僕が考えるプロダクト化の阻害要因を挙げています。1つが応答速度が遅い、1つが演算量が多い、1つはカスタマイズが難しいという点です。一つひとつ説明します。

課題の1つ目は応答速度。音声認識は、昔からですが、2つのタイプに分けることができます。1つがバッチ型で、もう1つがストリーミング型です。バッチ型というのは、長い音声を全部受け取って、それを一括で処理して一括で返すようなやり方です。例えば長い議事録を書き起こすときはこちらが使われます。

こちらは応答時間に制約がないので、系列全体を使った処理が可能になるというのが特徴です。なので、BLSTMやSelf-Attention、Self-Attentionを使ったTransformerも採用できます。なんでもできるというわけですね。

一方でストリーミングの場合は、音声検索やスマートスピーカーみたいに、ユーザーがしゃべったらすぐに結果を返さないといけないという制約があるので、順方向に処理するモデルしか採用できません。というわけで、LSTMやCNN、さっきのEnd-to-EndだとCTCやRNN-Transducerが採用可能です。

今はTransformerの精度がすごく魅力的なので、Transformerの精度を保ちつつストリーミング化するという研究が盛んに行われています。今日はそこを深堀りしていこうと思います。

Transformerの応答時間が遅い理由として、2つあると考えています。1つは系列全体でSelf-Attentionを計算するというところ。系列全体で計算するので、当然ながら系列全体を入力したあとにそのSelf-Attentionの計算を開始することになるので、遅延が多いということです。

この解決策としては、いろいろな方式がありますが、1つは単純にブロック単位にして、あるブロックの入力が溜まった段階で、その範囲でSelf-Attentionを計算するというような「Neural Transducer」や、あとはもう少し工夫してAttendの範囲を適応的に変動する「MoCha」というやり方があります。

MoChaについて

今日はMoChaについて簡単に紹介します。こちらは通常のSelf-Attentionで、Soft attentionとも書いてありますが、これはある文字を、例えば「こ」というのを出力するときに、この入力のどこに強くAttendしたかというのを表した図になります。色が濃いほど、注目度が高いです。

当然音声はLeft-to-Rightで、左から右に進んでいくので、注目度が高い特徴は当然ながら右のほうに遷移していく性質をもっています。

次にHard Monotonic Attentionを説明します。こちらは文字ごとにAttendする特徴を、1つだけに限定するというやり方です。先ほど言ったように音声はLeft-to-Rightなので、Attendする特徴はLeft-to-Rightで遷移していく制約をもっているわけです。

こうすることで、逐次的にデコードができる。これはAttendするところを決めるときに、ここがダメならここ、ここが違かったらここという感じで決めていくので、系列全体を読む必要がないわけです。そういうやり方でできるので、遅延が非常に少ないという特徴があります。一方で、やはりAttendする特徴を1つだけに限定してしまうので、精度が大きく劣化してしまうという特徴があります。

MoChaはMonotonic Chunkwise Attentionの略なのですが、先ほど説明した2つの間をとったようなものです。最初にHMAでAttendする特徴を選択して、その選択した特徴を含む過去方向の固定長の窓内で、Self-Attentionを計算するやり方です。

こうすることで、先ほどのHard Monotonic Attentionの遅延が少ないというメリットを活かしたまま、精度の劣化を緩和できるやり方になります。

応答速度が遅い理由その2

Transformerの応答時間が遅い理由その2ですが、今度はこちらのデコード側の問題です。Transformerのデコードは、前の出力の文字を使って、つまり自己回帰構造を経て、逐次的にデコードするやり方を取ります。

例えば最初の文字を予測するときは、最初の文字なので、SOSとなってy1となると。次はSOSとy1がある状態で、次のy2を予測するのですが、そういう逐次処理をすることで、並列処理ができないという性質をもちます。なので、処理遅延が多いということになります。

この解決策として、今機械翻訳で注目されているNon-Autoregressive Transformerというのがあります。こちらが、最近音声認識にも適用されています。自己回帰ですね。今説明した自己回帰構造をなくして、すべての文字を並列予測することで、高速化しています。

こちらのアルゴリズムを簡単に紹介します。Non-Autoregressive Transformerが学習するときのやり方はこちらです。先ほど説明したように、普通のTransformerだと正解の文字列があって、それであるところまで正解文字列を使います。例えばy1、y2というのを入力したときに、次のy3は何かというような次の文字を予測させるタスクを、このモデルに解かせていたんです。

これがNon-Autoregressive Transformerだと変わってきます。何をやるかというと、正解の文字列に対してランダムにマスクをかけます。そして隠した状態でその隠したところが何なのかを当てるというタスクを、このモデルに解かせることをします。

認識するときはどうするのかというと、これは非常におもしろいのですが、まずイタレーティブにやります。最初のイタレーションでは何もテキストに関する情報がないので、全部マスクした状態でスタートします。なのでエンコーダの特徴だけから文字を予測します。そうすると大部分が信頼性が低い結果が出るんですが、中には精度が高く信頼性が高く認識できそうだというところが出てきます。これは色の濃さが信頼度なのですが、中には色の濃いところがあると。

そうすると次のイタレーションではその信頼性が高かったところを正解だと思って予測するわけですね。そうすると、条件が増えたことによって、さっきの信頼性が低かったところも信頼性が今度は上がり、認識結果も変わります。このように結果をどんどんRefineしていくようなやり方です。これを繰り返して、最終的な認識結果を確定するというやり方です。

この手法は、こうすることですべて並列に計算ができるので、デコードの速度がめちゃくちゃ速いです。確か100倍ぐらい速くて、音声認識の劣化も10パーセントぐらいで済んでいたかと思います。この秋の音響学会でも早稲田の樋口陽祐さんやヤフーの藤田悠哉さんなどがNon-Autoregressive Transformerに関する研究を発表されていました。

演算量の削減

課題の2つ目は演算量削減ですね。End-to-Endモデルは非常に大きなモデルを使うので、計算量がとても多いという特徴があります。なので、場合によっては計算量を削減したいという必要性が出てきます。それはどういうことかと言いますと、当然みなさんご存知だと思いますが、ハードウェアコストが下げられるという話ですね。

GPUでしか動かないようなモデルでは、当然LINEやヤフーみたいに日本中から常々クエリが飛んでくるようなサービスをもっている会社では、それだけ計算機のインフラを用意してやる必要があるので、GPUでしか動かないというよりもCPUで動くもののほうが好ましいわけです。あるいはデバイスで認識したいという場合には、当然計算コストを削減してやる必要があると。

あとは応答時間ですね。これは単純に、応答時間を下げるために演算量を削減することが有効だということです。計算量を削減するために有効な方法として、一般的なのはモデルを量子化するとか、単精度演算にするとか、あとはDistillationとか、特異値分解でモデルを小さくするということも有効になります。

音声認識の例でいうと、すでにGoogleがデバイスで動くモデルをEnd-to-Endモデルで開発しています。これは今年のICASSPの論文ですね。以前のGoogleは、RNN-Transducerだけのモデルを作ってそれをPixelというスマートフォンで動作させていたんですが、最新の文献では、このRNN-TransducerにLASを加えて、2パスの構成でオンデバイスの音声認識機器を作っています。

それでそれがストリーミング動作するものも発表しています。構成としては、RNN-Transducerが仮説を生成して、LASがリスコアリングするというやり方。演算量を削減するために、いろいろ細かいテクニックは入れているんですが、今日はその詳細には触れません。

PFNの益子さんは僕の東芝での先輩ですが、ICASSPの2019年の論文読み会で、こちらの解説をしているので、もし興味のある方はそちらをご参照ください。

モデルのカスタマイズ

3つ目はモデルのカスタマイズです。LINEもそうなんですが、B to B事業をやっている会社だと、ある大口のお客さんには特有の語彙に対応する必要がある。「この言葉を認識させてください」というような要望があったりします。DNN-HMMのときは、そういう要望に応えるために、比較的やりやすい言語モデルと発音辞書に対応すればよかったというのがあります。

具体的にいうと、言語モデルはお客さんのテキストをもらってきて、それでN-gramをカウントし、そのすでにもっているN-gramとスムージングする、あと「発音辞書」には、単純にお客さん特有の単語に発音を付与しています。エントリーを追加していれば、それだけでけっこうちゃんと認識できるようになるというやり方ができました。

End-to-Endだとそれが難しくなるという課題があります。End-to-Endでは言語モデルだけを今説明したようなやり方をしても、効果は限定的です。というのは、先ほども説明したように、「言語モデル」は、End-to-Endだとこちらで予め仮説を出した上でそのリスコアリングしかできないので、この上位N個の仮説に正解がないと、いくら言語モデルががんばっても復活しようがないということですね。

なので、もうこちらのEnd-to-Endモデルも対応するしかありません。理想的にはEnd-to-Endモデルのファインチューニング、お客さんに音声とテキストのペアデータをいっぱいもらってきてそれをファインチューニングができたらいいのですが、当然難しいんですね。なので、DNN-HMMのときと同じように、テキストデータだけでEnd-to-Endモデルを改善できれば、それは利便性として非常に高いことになります。

そのやり方をどうするかという話ですが、音声合成を利用したアプローチがあります。音声合成を利用して、Data Augmentationするというやり方が一番単純なやり方なわけです。ただこのように、音声を作ってData Augmentationするやり方も、一定の効果はあるものの、その場合そもそも認識に不必要な非言語情報、話者の情報などそういった情報を含んでしまうという性質があります。

それに対する別のアプローチとして、こちらは名古屋大学の林さんが少し前に発表した論文ですが、Back-Translation-Style Data Augmentationという論文があります。こちらは、テキストからEnd-to-Endモデルのエンコーダ出力を直接予測する方式です。そのモデルとして、Tacotron2を利用するというやり方が提案されています。このやり方は非常に有望だと思うので、今日紹介します。

ちょっと簡単に中身を説明しますと、この方式はまずはテキストとオーディオのペアを使って、普通にEnd-to-Endモデル学習を行います。学習したモデルがここにある状態です。次に、もともとペアデータとしてあった、テキストとそれに対応する音声のエンコード特徴は、この音声認識機器に入力するとエンコード特徴が出るので、テキストとエンコード特徴のペアができるわけです。

そのペアを使って、テキストからエンコード特徴を予測するというモデルを作ります。そうすると、このUnpaired Text、これはお客さんの音声のないテキストだけの情報ですが、そのテキストからこのTTE modelに入力することで、推測したエンコードの特徴が得られることになります。

そして、この生成したエンコード特徴ともともとの音声特徴を混ぜて、End-to-Endモデルを再学習するとすると、テキストからお客さんの固有名詞とかを認識しやすくするようなEnd-to-Endモデルが学習できます。以上です。

というわけで簡単ですがプロダクト化に向けての課題と取り組みについて紹介しました。

LINEの音声認識

最後にLINEの音声認識について紹介します。LINEには、AIアシスタント「LINE Clova」とと、法人向けにAI技術を提供する「LINE BRAINと」いう事業があったんですが、つい最近、LINE CLOVAというブランド名に再定義して、その下にいわゆるAI技術、OCRや顔画像認識、テキスト分析などと、あとは音声認識、音声合成技術のソリューションがぶら下がるという位置関係に変わりました。

音声認識関係ではみなさんご存知の方も多いと思いますが、CLOVA FriendsやCLOVA Deskなどといったスマートスピーカーを作っています。あとはその知見を応用して、サードパーティのデバイスにLINE CLOVAのAIアシスタントを入れたりしています。あとは、自社のスマホアプリ、例えばカーナビなんかにも音声認識を入れています。

あとはB to Bビジネスですね。これはLINE AiCallという、最近正式にローンチされた自動応答音声です。電話すると、音声認識で会話ができるソリューションも提供しています。というわけで、非常にいろいろな形態で音声認識を提供しています。

開発体制としては、LINEはNAVERと一緒に共同開発をしています。LINEの中に、音声合成をするSpeechチームがあって、そこで音声認識をやっています。Speechチームの全体マネージャーは戸上真人さんが務めていて、その中に2つのサブチームがあります。リサーチャーは小松達也さんや戸上さん、ロビン・シャイブラーさんが在籍していて、エンジニアは音声認識のエンジンを作るチームになります。

リサーチャーの成果を簡単に紹介しますが、今は環境音識別技術を小松さんがやっていて、今年のDCASEで世界1位を獲得しています。あとブラインド音源分離は、戸上さん、ロビンさんがやっています。DNNベースの音源分離も、戸上さん中心にやっています。ちょっと3人という人数とは思えないパブリケーションが出ている感じですね。

一方の音声認識エンジニアですが、我々エンジニアチームはDNN-HMMの音声認識システムが今のプロダクトで動いているので、そちらの改善を進めています。あとはEnd-to-Endの音声認識技術も開発を進めています。そして3つ目はプロトタイプシステムですね。これは新規プロダクトを作るために、ボトムアップの活動としておもしろいものを作ることをやっています。

最後は広告ですが、音声リサーチャー、エンジニアを幅広く募集しています。LINEに興味がある方は、カジュアル面談を受け付けていますので、よろしくお願いします。あと最後に。LINE DEVELOPER DAY2020が11月25日から27日までありまして、そこでLINEで開発中のEnd-to-End音声認識についても発表がありますので、ご興味のある方は、そちらをご登録ください。よろしくお願いします。

以上です、ありがとうございました。