ここ数日、いくつかSiriusに関する記事を読んでみて興味が湧いてきたので、今日は開発者の方々が書かれているペーパーを読んでみました。
Sirius: An Open End-to-End Voice and Vision Personal Assistant and Its Implications for Future Warehouse Scale Computers
先日の記事でも取り上げましたが、Siriusはパーソナルアシスタントをユーザの手で実行できるようにすることや、GPUやFPGAを使ってより効率の良い処理を研究することを目的としています。
本ペーパーでは知的パーソナルアシスタント（以降はIntelligent Personal Asistants=IPAと呼ぶ）のソフトウェアとしての課題よりも、IPAに対するリクエストの増大やそれに対するFPGAなどを使った負荷の軽減などの提案がされています。
IPAはiOS、Androidなどで利用され、その利用者数は増加の一途にあります。また、ウェアラブルデバイスなどより入力が困難なデバイスが普及した場合、音声による操作はより日常的なものになってきます。
In addition, the usage scenarios for IPAs are rapidly increasing with recent offerings in wearable technologies such as smart watches and smart glasses. Recent projections predict the wearables market to be at 485 million annual device shipments by 2018.
スマートウォッチやスマート眼鏡のようなウェアラブルテクノロジーでも需要があり、IPAの利用予測は今後も急速に増加していくことが予想されています。最近の予測の中には2018年にはウェアラブル端末は4億8千5百万デバイスが出荷されるとするものもあります。
class="mute">the design of wearables is heavily reliant on voice and image input, further indicates that rapid growth in user demand for IPA services is on the horizon.
ウェアラブルのデザインは音声や画像による入力に強く依存します。これらのデバイスの普及はIPAに対するリクエストが急速に増加することを意味します。
IPAサービスのサーバへの負荷は過去のWebサービスと比べると巨大なものです。現在のデータセンターはそれに対して最適化されていないというのが本ペーパーの主張です。
This offloading approach is used by both Apple’s Siri and Google’s Google Now as they send compressed recordings of voice command/queries to datacenters for speech recognition and semantic extraction. However, datacenters have been designed and tuned for traditional web services such as Web Search and questions arise as to whether the current design employed by modern datacenters.
AppleのSiriもGoogleのGoogle Nowも、現在は圧縮した音声のコマンド/クエリをデータセンターに送り、音声認識と構文解析が行われています。しかしながら、データセンターはWeb検索用の過去のWebサービス向けに最適化されたままの構成が利用されています。
こうした状況を見ると、下記のような課題が浮かび上がってきます。
- Identifying critical compute and performance bottlenecks throughout the end-to-end lifetime of an IPA query;
- Understanding the performance, energy and cost trade-offs among popular accelerator options given the characteristics of IPA workloads;
- Designing future server and datacenter solutions that can meet the amount of future user demand while being cost and energy efficient
- IPAの処理全体を通して、処理能力を使うクリティカルなシーンとボトルネックを特定すること
- IPAの特徴的な処理において、アクセラレータによる電力およびコストのトレードオフがどう変化するかを理解すること
- 将来のユーザの要求を加味した、コストと電力効率の良いサーバとデータセンターの在り方をデザインする
To address this challenge, we first construct an end-to-end standalone IPA service, Sirius, that implements the core functionalities of an IPA such as speech recognition, image matching, natural language processing and a question-and-answer system.
こうした問題にチャレンジする為に、私たちはまずIPAサービスのすべての工程を含む、Siriusを開発しました。SiriusにはIPAの主要な機能である、音声認識、画像認識、自然言語処理、QAシステムが実装されています。
デモ動画では画像を写真で撮って、それに対して質問するといった用途も提示されています。
A voice and image question such as “When does this restaurant close?”coupled with an image of the restaurant, also leverages image matching with an image database and combines the matching output with the voice query to select the best answer for the user.
音声と写真による質問を考えてみましょう。たとえば「このレストランは何時までやってる？」という音声とレストランの写真があったとします。イメージデータベースと照合して画像マッチングを行い、音声クエリと合わせて最適な回答をユーザに届けなければなりません。
考えただけでも相当なリソースの消費が予想されますね。特に「このレストラン」という画像マッチングに応える為には、どれだけの画像情報が必要になることか。
もう少し具体的に書くと、下記のようなフローになるようです。（Figure2より）
- クライアントが画像と音声を送信する
- 画像を画像データベースとマッチングして内容を特定する
- 音声をspeech recognizeし、それが質問なのかアクションを要求しているのか分類する
- アクションを要求していれば、指定アクションを実行する
- 質問であれば画像データと合わせてQAシステムを実行し、回答をユーザに送信する
アクションの要求とQAを分類する工程がありますが、例えば「Set my alarm for 8am」（目覚ましを朝8時にセットしてくれ）はアクションの要求になります。「Who was elected 44th president?」（44代大統領は誰？）はQAになります。
Siriusではこうした処理を行う為に、その分野で有名な下記のソフトウェアのテクノロジーを利用したり、参考にしたりしています。
- CMU’s Sphinx（音声認識）
- Kaldi（音声認識）
- RWTH ASR（音声認識）
- OpenEphyra（QAシステム）
- IBM Watson（QAシステム）
- SURF（画像認識）
- OpenCV（画像認識）
Siriusのインストール手順の項を見ると、依存しているソフトウェアは下記になるようです。
- Sphinx (sphinxbase and pocketsphinx)
- Kaldi
- Protobuf (v2.5.0)
- OpenCV (v2.4.9)
- Java (v1.7.0_55)
ソース自体は概ねC++で書かれていますが、Javaもいるようです。ソース見てたらSphinxがJavaなのでそこと通信するようなコードを見かけました。
また、それぞれの役割毎の手法としては下記が使われています。
音声認識（Automatic-Speech Recognition）は Gaussian Mixture Model and Hidden Markov Model、もしくはDeep Neural Network。
QA（question-answering）はconditional random field。
画像マッチング（image matching ）にはSURF。
これら各処理の詳細についても記述されています。Sphinx、Kaldi、OpenEphyra、OpenCV周りの資料を読んだ方がより詳しいですが、要点が抑えられているので読みやすかったです。（数式もないぜ。やった）
IPAのパフォーマンスですが、下記の測定では165倍近い違いが出ています。
the average Nutch based Web Search query latency is 91ms on the Haswell based server. In contrast, Sirius query latency is significantly longer, averaging around 15s across 42 queries spanning our three query classes.
Haswell（IntelのCPUの規格。最新のけっこう速いやつ）ベースのサーバで、NutchベースのWeb検索クエリを動かした場合は91ミリ秒だったのに対して、Siriusクエリははっきりと長く処理時間がかかった。3つのタイプの42クエリをの平均を計測した結果、15秒かかっていた。
3つのタイプのクエリはVoice Command（音声によるコマンド）, Voice Query（音声によるクエリ） and Voice Image Query（音声と画像によるクエリ）の3つです。
Latencyが最もキツイところはQAの部分になるので、そこが絡まないVoice Commandは比較的軽い。
NutchはHadoopの作者でもあるDough Cutting氏が作っているOSSの検索システム（クローラーから検索までオールインワン）です。余談ですがNutchの名前の由来はDough Cutting氏のお子さんがlunchをうまく発音できずにnutchと言ってしまうことから来ているとか。
Nutchの場合はトラディショナルなテキストベースの検索ですが（内部的にはLucene）、それとくらべると桁違い（約165倍）の処理能力を使うことがわかります。
まだ途中ですが、長くなってきたので本日はここまで。
続きはまた明日。
