Clovaを支える自然言語処理の秘密

Clovaを支える自然言語理解の仕組み

佐藤敏紀氏（以下、佐藤）：こんにちは。このセッションを選んでいただき、ありがとうございます。最初に自己紹介をさせていただきます。私は佐藤敏紀と申します。2012年に中途で入社して以来、自然言語処理と検索を専門にしているソフトウェアエンジニアです。

Clovaでは、とくに日本語の自然言語理解システムの開発を担当しております。プライベートでは、NEologdというオープンソースのプロジェクトを主導しています。

このプロジェクトでは、新語や未知語を集めて漏れなく読み仮名をふるということを1週間に1回から2回行って、その成果をみなさまに配っています。成果物はClovaでも利用されていますし、みなさまのパソコンやスマホなどでも役に立っています。

このセッションでは、AIアシスタントプラットフォームであるClovaのNLUの開発に携わっているエンジニアの私の目線から、Clovaのことをお話ししていきます。ClovaのNLUシステムの中身とそのインターフェースである音声インターフェースの話題が軸になっています。

ここまで出てきたキーワードに関して、まったくわからない方でも、具体的な事例について取り上げながらお話しいたしますので、よくわかっていただけると思います。同業の方や、今後Clovaの開発に取り組んでくださる方がピンとくるような話題をお話しできたらいいなと思っております。

スマートデバイスとは何か

まずは、よく話題になるキーワードについて、お伝えしていこうと思います。最初は「スマートスピーカー」という言葉です。

マイクとスピーカーによって構成された家電で、いろんな会社から発売されており、量販店に行くと売っています。

2つ目は「スマートディスプレイ」という言葉です。もうすでにいろんな会社が発売しているんですが、弊社でも開発中です。

こちらについて、弊社では大規模な社内テストをしているという状況です。本気で作っておりますので、かなり便利なデバイスになると思っております。

ほかにも、スマートウォッチ、スマートTVなど、いろいろな「スマート〇〇」というものがありますが、この発表ではそれらをまとめて「スマートデバイス」と呼んで進めていきます。

ちなみにこの会場の中で、こういうスマートデバイスを1個でも2個でも買ったことがあるという方はいらっしゃいますか？　

（会場挙手）

買っていないよという方も、少しいらっしゃるんですよね（笑）。買ってくださった方、ありがとうございます。たぶん、便利だと思います。僕は他社様のデバイスもたくさん買うんですが、それぞれにいろいろないいところがあって便利だなと感じています。

これらのスマートデバイスに共通して実装されている機能は、音声でデバイスを操作するためのインターフェース、「VoiceUI」です。このプレゼンテーションでも、何回も登場します。

これは何かと言うと、既存のデバイスには指で操作できる部分がありますが、そこを声で操作できるようにするインターフェースの実装のことだと思ってください。

デバイスに音声用のユーザーインターフェースを用意することによって、すごく直感的な操作ができるようになります。幼児でもご老人でも、簡単に操作を試すことができます。

僕が毎日どんなことを検索するかと言うと、一番調べることは天気についてです。天気を調べる機能は、みなさまの関心がとても高いおかげで、ほとんどのスマートデバイスに実装されています。

例えばClovaの場合、「ねぇ、新宿の天気は？」と問いかけると、「今日の新宿の天気は晴れ。気温は……」みたいなかたちで返ってくるわけです。

聞きたい情報がこのように音声で返ってくると、目を使って見る必要がないので、いろんなことをやりながら聞けますし、両手も自由ですよね。料理を作りながら、「今日着ていく洋服、何にしようかな？」みたいに考えられるので、とても便利です。

Clovaの中で起こっていること

Clovaは、このときにどのように動作しているのかを、簡単に説明させていただきます。

点線から右側がClovaのプラットフォームの中だと思ってください。Clovaは「ねぇ、Clova？」と話しかけられるまでは、ジーッと待ってるんですね。

「ねぇ、Clova？」と話しかけられたら、ユーザーの具体的な命令が入っていそうな部分をキャッチして、Clovaのプラットフォームに投げます。

Clovaのプラットフォームは音声を受け取ったら、この音声を入力にして音声認識サーバーにリクエストします。音声認識サーバーがこの結果を得て、認識した結果をリストで返します。今回は「ねぇ、Clova」の後ろの「天気は？」がきちんと取れたみたいですね。

「天気は？」という内容が取れたあと、これをNLU/DMというコンポーネントに投げます。

このNLU/DMというコンポーネントは、自然言語処理の技術や機械学習の技術を用いて、ユーザーが求めている行動をClovaが理解できる様に解析するパートです。このパートについては、あとで詳しくお話ししたいと思います。

その結果、このような表が得られました。

この表からは、ユーザーが知りたい情報は天気で、一般的な天気の情報を知りたいということまでわかります。

しかし、どこの天気なのか、いつの天気なのかはわかっていない状況です。こういうケースは本当によくあります。どうするかと言うと、Clova自身が知っている情報を補っていくことになります。

このユーザーは、たまたま新宿にいるようなので「新宿」という情報を足しますし、Clovaのプラットフォームでは時間の情報のデフォルト値は現在になっているので、現在という情報を足して、この表を補完することができました。

この5値が揃っていると天気のコンテンツAPIを叩くことができるので、この情報をもとにコンテンツAPIに対してリクエストを投げます。

すると、このAPIからこのあとに返すテキストとして、「現在の新宿の天気は晴れ」といったものを生成してくれます。

これを受け取ったClovaは、それを音声合成のサーバーに対してリクエストして、音声合成の結果を受け取って、それをそのままユーザーにお返しします。

これを聞いたユーザーは、これで満足することができたら、その時点でリクエストが終了します。もしうまくいかなかったら、ちょっとイラッとしながらもう1回リクエストしていただくような流れになると思います（笑）。今回はうまくいったみたいです。

先ほどまで並べてきた要素を一度に表示すると、こんな流れになっています。

音声認識をして、言語を理解して、さらに対話の管理をして、コンテンツを取得して、音声合成をして、というかたちで流れています。

ボイスUIを使ったAIアシスタントを実現するには、こんなにたくさんのことをしなければいけません。ですが、将来的にスマートデバイスのカメラを使ってユーザーの状況をモニタリングすることを求められる時代が来たら、さらに画像認識用のサーバーも入ってきて、もっとすごいことになります。

NLUシステムの役割

さて、ここからが本題です。先ほど、AIアシスタントのNLU/DMパートというものをご紹介しましたが、その中のNLUシステムについて、より深くご紹介していこうと思います。

このNLU/DMというパートは、私が所属しているチームで開発と運用を担当しております。Clovaの賢さに直接関連しているので、緊張しながら作っています（笑）。

NLUとはNatural Language Understanding、つまり自然言語理解のことです。DMはDialog Managementで、対話の管理を担当しています。この2つのコンポーネントがAIアシスタントを実装していくうえで、どうしても必要になります。

ちなみに、このNLU/DMに関する処理領域というのは、先ほどの図だと、この赤い四角で囲った部分でした。

入力はユーザーのクエリの情報で、音声認識の結果を入力してあげます。出力はClovaのNLU/DMから先のコンポーネントがうまく動くようにするための解析結果になっています。

この赤枠の部分だけに着目した図に切り替えてみると、こんな図になります。

処理の流れはまったく同じなんですが、その過程でNLUシステムは中身でいろいろな処理をしています。

例のNLUの結果というのは、先ほどお話ししたDomain、Intention、Main Goal、Place、Timeのような5値が取り上げられています。しかし実は、内部的にはDomainとIntentionとMain Goalを組み合わせた、もう1つの値を持っています。

1つずつ見ていきましょう。Domainは機能を表す名前です。天気、音楽、LINEのメッセンジャーみたいなものですね。Intentionというのは、そのDomainにおいて、ユーザーは一体どんな行動をClovaにしてほしいのかを表しています。

そしてMain Goalは、ユーザーがどんな情報を提供してほしいと思っているかです。この3つの値を組み合わせると、だいたいClovaがやるべき行動が1つの方向に定まります。

PlaceとTimeは、今回のケースではお天気のAPIを叩くうえで必要なパラメータになっています。この6値に関しては、これから先のプレゼンテーションの中ではとくに解説なく出てきますので覚えていただければと思います。

具体例で見るNUL

さて、詳しくお話しするための事例も考えなればいけないので、いろいろ考えた結果、「今日の13時の八芳園の天気は？」というベタな例を考えることにしました（注：LINE DEVELOPER DAY2018は八芳園で開催）。この音声を入力されたClovaが、どのようにしてNLUの結果を出すのかを考えていくことになります。

今日は晴れて本当に良かったです。晴れのつもりでプレゼンテーションを作ったので、雨だったらどうしようかなと思いました（笑）。

まず、いきなりClovaが音声認識の結果を得て、それをNLU/DMに対して入力するところからはじまります。NLUに対する入力は、先ほど申し上げたように音声認識の結果の認識済みのテキストのリストになっています。

リストには確信度みたいなスコアがふられていて、そのスコアの降順で並んでいます。NLUは、内部処理で入力されたクエリについて、リストの上位から情報の獲得に必要な情報が取れないかということで取得を試みたり、やっぱりいらない情報だということで削除を試みたりします。

NLUのシステムは、ルールベースの1個の手法だけが動いているわけではありません。ルールベースの手法もありますし、機械学習ベースの手法もありますし、多数のプロセスが同時に動いています。最終的な結果をガーッと集めて結果を取得して動いていく仕組みになっています。

また、我々は開発エンジニア以外にも運用スタッフがいて、結果の品質をツールで管理しています。その結果は機械学習のモデルや辞書のエントリーなどに反映されて、各フェーズに対してきちんと影響を及ぼすようにしてフィードバックされています。

NLUの処理の流れ

では、最初はどのステップからはじめるかと言うと、キーワードの抽出からになります。

このキーワードの抽出においてやらなければいけないことは簡単で「今日の13時の八芳園の天気は？」と言ったときに、どこがキーワードなのか、人間だったらわかりますよね。これが取れたらいいわけです。

そこを取れるのであれば、ルールベースの手法でも機械学習の手法でもなんでもいいわけです。そこで、最初はルールベースから紹介していきます。事前に必要な準備というのは3ステップあります。順番に見ていきましょう。

ステップ1は、「事前にちゃんと辞書を作らなきゃいけないよ」ということです。これは、ルールベースの手法でも機械学習ベースの手法でも同じです。事前にカテゴリーごとに分けた辞書を、どんどん作っていく必要があります。

今回の場合は、時間表現の辞書と、Point of Interest、いろんな地名が書いてある辞書などを用意しておく必要があります。

それぞれの辞書の中を見ていくと、その辞書の表記がどうなっているかという表層表現の列と、それがどう読まれているかという読み仮名が書いてある列があります。

もしも、その表層表現が正しくない、または省略されている場合には、正しい表記をマッピングできる場合があります。辞書には正しい表記が書いてある列、さらにそれらが全体に対して紐付いているメタデータのようなものが入っています。

事前に計算がたくさん必要な値があとで必要な場合もあります。その場合には、辞書資源の中にあらかじめ突っ込んでおくということもやっています。

辞書を作る上で考慮すべきこと

辞書を作成する際、いろいろと考慮しなければいけないことがあります。例えば、音声認識の揺れです。13時というエントリーがDatetimeの辞書にあり、1つは英数字の13、もう1つは漢数字の十三になっています。

これらは、どちらも音声認識の結果としては間違っていません。どちらも正しいです。事前に正しいことがわかっているので、運用としてどちらか1つにまとめることを行います。例えば、お隣の雅叙園さん……雅叙園と略してしまいましたが、本当は目黒雅叙園なんですね。

ですので、目黒雅叙園にまとめるといったように、正しい表記を登録していくということを全体的に行います。手作業で行うよりは、すでに整頓されているデータがあるので、それをいかに取り込んでいくかというところがポイントです。

次に、それらの辞書の表層表現に対して、Trieというデータ構造を使ってインデックスを作っておきます。これは、キーワードの抽出処理で頻繁に使います。また、key-valueデータベースのほうに辞書ごとのインデックスを作っておきます。

Keyのほうには、先ほどのTrieを作るときに使った表層表現を使って、Keyを作ってあげます。その表層表現に紐付く辞書のエントリー全体を、Value側に入れてあげます。

こうすることによって、サッとデータを引けるので、低レイテンシーにNLUの結果に対して辞書の持っているメタデータを付与できるようになります。

だいたいの辞書は、最初にエントリーを作ったあとは追加されていくペースがすごく緩やかなので、リソースの増加がどのくらい行われていくのかは事前に見積もることが可能です。

処理の流れ

どうしてこんなことを言っているかという流れを順番に見ていきます。まず、クエリ全体の中で「今日の13時」という5文字の範囲がスロット語として抽出できて、その中には、おそらくDatetimeが入っているということがわかったとします。

ここでどのようにサーチしていくのかと言うと、こんなかたちでサーチしていきます。

その過程で「今日」という単語と「13時」という単語は、Datetimeの辞書に入っていることがわかりました。

ここがわかったら、Keyを使ってkey-valueストアからデータを引いてきます。それによって、NLUの結果全体にメタデータ……例えば"days”:0や"hour”:13のような値を入れることができます。

このようにスロットの範囲を絞れないこともありますが、その場合は最大ウィンドウ幅を適切に指定しておくことで、同様の処理を行えます。

スマートデバイスのクエリは無限に長いわけではありません。ユーザーが狙いをもってクエリを投げてくれるので、けっこう乱暴に検索しても全体として問題は起きていません。

応答時間は早くなければいけない

NLUがなぜこんなに早くがんばらなければいけないのかと言うと、このキーワード抽出や分類の処理だけではなく、全体の処理をだいたい50msくらいで行わなければいけないからです。

Clovaは、音声で応答を返すための持ち時間がかなり厳しく設けられています。例外処理などを含めて、このくらいの速度で終わらないと、後続の処理がもっと時間を消費してしまうため、最終的にユーザーに「わかりませんでした」という結果を返さなければいけなくなったりして、困ってしまいます。

ですので、コストの高い計算や応答時間の分散が大きい計算は、なるべく少なくするように、全体的な工夫を行わなければいけません。

具体例に戻ります。「今日の13時の八芳園の天気は？」というクエリに対してルールベースで見ていったところ、「今日」と「13時」と「八芳園」の位置にあるところに、それぞれdatetimeとPoint of Interestのスロットがありそうだということがわかりました。

それに対して、先ほど行ったようなTrieのデータベースを用いたサーチを行い、その結果、このようなメタデータを抽出することができました。ユーザーの言い澱みがなかったので、datetimeの情報を素直に抽出することができましたし、同様に、八芳園という単語はウィキペディアに載るようなすごく有名なキーワードなので、検出がかなり容易でした。よって、3つの値を取ることができました。

実際には、この3つのdatetime、datetime、POI以外の組み合わせにも、なにか可能性はあるかな？　ということをサーチしていきます。今回は、ひとまず次の段階に進んでいきます。

機械学習ベースの場合には、この処理を、ルールでスロットを見つけていくというよりも、系列ラベリングの問題を解いていき、ここはdatetimeっぽいといったことで識別していきます。

ルールベース・機械学習で分類する

では、次の段階に進んでいきます。次は分類です。分類も、まずはルールベースの処理について話していきましょう。すでに先ほど抽出したキーワードのおかげでPlaceのスロットとTimeのスロットはもう埋まっています。

先ほども見たようなdatetime、datetime、POIというスロットの組み合わせに、さらにクエリの中には天気という具体的なキーワードが出てきてしまっています。

こういったときには、DomainとIntentionとMain Goalの組み合わせがこうなるということが事前にわかってしまいますので、こうして埋めればいいよね、といったことが決まったりします。

ルールベースで進めていくときには、キーワードをいかに抽出できるのかが、ユーザーのやりたい行動を正しく検出することに大きく影響しています。

機械学習の手法については、分類器をいくつも並行して走らせたり、ほかの分類器の結果がどうなったかという状況に基づいて、さらに推定を実行するというアプローチを取っていきます。

機械学習の場合も、とくにすさまじく特別なことは必要ありません。今後、より発展した内容に取り込んでいけるのを今から楽しみにしています。

Clovaのデバイスが公開されて以来、機能がどんどん増えています。

最初は、実は天気と音楽だけでした。機能が増えていった結果、NLUシステムが判別しなければいけない機能の数や、我々が把握しているスキルだけでも多岐に渡っています。

さまざまなクエリに対して、正しく認識を行っていかなければいけないので、分類のフェーズをより改善していくことは、ユーザーによりよいClovaの状況を提供していくために必要です。ですので、ここをなるべく早く改善していこうと取り組んでいます。

フィルタリングとランキングについて

残っている処理は、フィルタリングとランキングです。先にフィルタリングについて話していきます。フィルタリングは、複数のNLUの結果が得られた場合に不要なものを削る処理です。

なぜ削らなければいけないかと言うと、先ほど軽く触れましたが、NLUのシステムはルールベースの手法が1種類だけ動いているわけではないからです。

機械学習のベースの手法も含めて、いろいろな種類の手法がガーッと動いているので、最後の段階に進むまでもなく削ったほうがいいね、という結果もたくさん含まれていますので、その場合は削ります。ただ、今回の事例は1個しかないので、フィルタリングの必要はなさそうです。

次に、ランキングをどこで行うかと言うと、さらに後段の処理で、コンテンツを獲得できるかという参照情報や、実際にコンテンツの品質や、獲得できた状況、NLUシステム自体の処理に関するスコアの具合などを加味して、ランキングしていくことになります。

そうすることによって、複数得られた結果のうち、ユーザーに具体的に示す情報はこう決まっているんですが、このうち「これを返したほうがいいよ」といった動きをするようにできます。ただし、今回の事例は1件しかないので、ランキングしても順位が変わりません。そこで、このまま進むことになります（笑）。

NLUの処理における課題

ということで、この例におけるNLUより後段の処理では、このNLUの結果をフィルタリングとランキングが終わったということで、実行していくことになります。ここまでは、NLUシステムの一連の動作の例になっています。ご理解いただけたらうれしいなと思います。

ここから先は、NLUの処理の流れの中で、いろいろな場所に問題と言いますか、少し根深い課題みたいなものがあります。それについて、どのように解決していったかという話に触れていこうと思います。

最初は、音声認識のことから話していきましょう。NLUの結果を改善するためには、音声認識の結果についても関心を払う必要があります。

意外だと言う方がいらっしゃいますが、なぜかと言うと、言語理解のパートでは、入力はだいたいテキストでやって来るんですね。

そのテキストに、エラーが避けられない不具合みたいなものが入ってしまった場合には、最初のNLUのスタート時点における入力のクオリティが低くなっているということなので、そのエラー率が、次のNLUが行う処理に伝播してしまいます。

ですので、NLUとしても、音声認識の結果について関心を払って改善するべきものは改善するし、助けるべきものは助ける必要があるわけです。

最初は、先ほどから度々言っている新語の発生が問題になります。正しい音声認識をするうえで、最も大きな課題の1つだと言っても過言ではないと思っています。

幸いなことに、八芳園はすごくメジャーな言葉なので、なにも問題が起きません。僕はClovaに対して、がんばって八芳園のことを誤るように言っても、ぜんぜん誤りませんでした。

20回くらいがんばったら「花公園」になったんですけれど、スーパーレアケースみたいで、なかなか八芳園以外で認識してくれないという問題……問題じゃないですね！（笑）。そういうことがありました。

新語は正しく認識させるのが難しい

まったく新しい言葉だったらどうでしょうか？　これは6日前に発表されたプレスリリースのスクリーンショットです。渋谷に「渋谷フクラスという名前の建物ができるよ」というプレスリリースでした。

つまり、かなり新しい固有名詞で、かなり新しい地名です。この認識結果を見てみるとどうなるかと言うと、渋谷フクラスは1回も認識できませんでした。

ほとんどの場合、「渋谷服屋」「渋谷二クラス」「渋谷Sクラス」みたいなかたちになってしまいます。これはダメだなと思いますが、こういったことはとてもありがちなことです。

なぜかと言うと、音声認識の結果を調整するにはすごく時間がかかりますし、世の中で新たに登場する新語は「渋谷フクラス」だけではありません。すごくたくさんの言葉が出てきます。

例えばアーティストさんが「今回新しいアルバムを発売するから、10個新曲を作った」と言ったら、10個新語が出ちゃうわけです。そういうことが起きるので、そこに対応していくということを地道に行っています。短期的には、NLUのパートがこれを助けていくことになります。

判別が難しい単語における問題

では、この渋谷フクラスに関して、NLU側ではどんなかたちで処理が行われているのかを見ていきます。

先ほど申し上げたような、3ステップのデータを用意する処理がすでに終わっていれば、渋谷フクラスというデータが無事に取れますので、なにも問題はありません。

間に合わなかった場合はどうなるかと言うと、サーチするため、渋谷くらいは取れますよね。おそらくフクラスは入っていません。すると、渋谷フクラスは渋谷区渋谷にあるので、なにも問題がないと思いますよね。

しかし、これは実際は大問題です。なぜなら、Point of Interestの表現に対して最適な粒度の位置の地名表現が入っているとは限らないからです。

例えば、県名のようなものが入っていて、それを部分表現として取れた場合、その位置情報のヒントは県庁所在地くらいしかありません。それでは困ってしまいます。よって、Clovaとしては新語や未知語の問題をちゃんと解決しなければいけないと思い、そこに取り組んでいます。

さらに、既知の単語についても、同じ読み仮名だけれども異なる表層になってしまう場合がどうしてもあります。例えば「今日の13時の八芳園の天気」というふうに認識してほしかったのに、前方にあるノイズのせいで「今日」が都（みやこ）を表す「京」になってしまう場合もあります。

あとは、先ほど申し上げたように、まったく正しいんですが、13時と十三時の表記が英数字と漢数字で入れ替わってしまうといったことがあります。

こうしたものはすごく典型的な例なので、前者の場合、典型的な例であればNLUでちゃんと対処します。後者の場合は、synonym辞書を充実させていくことによって、全てのDomainに対して影響するようなかたちで、効率よく解決していく必要があります。

話者の癖に寄って意図しない結果になることも

そのほかにも、ユーザーの発話の品質によってまったく意図していない認識結果になってしまう場合もあります。例えば、ユーザーがなにか1つキーワードを言うたびに「えーと」と言ってしまう癖があるとします。

そうすると、「えーと、今日の……」と言った場合には、「えーと今日の」となってしまう。少しわかりにくいんですが、繰り返し言ってみてください。そうすると、「あ、東京のってなってる」と気が付くと思います

後者の場合は「えーと、13時の……」の「えーと」が、直後に13という数字が明らかにあるせいで、「えーと」はもしかして「８（エイト）」じゃないのかといった動きをして、813時になってしまいます。

そうすると、813時というのはなかなかないもので、最終的に部分文字列である13時が取れるため、問題がおきなさそうなんですが、同じような問題が起きることは多々あります。

今回はたまたま大丈夫ですが、同じ現象でもっとひどい問題が起きる可能性があります。ですので、少し気をつけなければいけなかったりします。

ここまで、3つの事例についてお話ししてきました。新語が現れると、音声認識が難しいですし、既知のキーワードに関しても、どうしても表現が揺れてします。あとは、いかに音声認識ががんばってもユーザーの発話の揺れがあることによって、課題が発生するということです。

NULの難点をどう解決するか

今度はNLUのプロセス自体にどんな困難があるのか、それをどう解決するかについてお話ししていきます。最初の課題はユーザーがとても自由に発話できるし、してくるということですね。音声認識が100パーセント完璧だとしても、ユーザーの発話というのが事前の想定どおりになることはありません。

例えば、ここに天気に関するキーワードを含んだクエリをたくさん取り上げているのですが、要するに、キーワードが入っているか入っていないのか、その数などもバラバラになっていますよね。

でも、これがもしもみなさんと同じ状況で八芳園にいて、さらに13時以前だったら、すべて同じ意味を表しているんです。例えば「今日の13時の八芳園……」と言っても、「八芳園の今日の13時……」と言っても同じです。

「今日の」が、自分にとっては当たり前のことなので「今日の」はいらないだろうと削除する場合もあります。自分が八芳園にいることが当たり前だったら、八芳園は消えるしといったかたちで、最終的にどのくらいまで削れていくかと言うと、一番短くなると「天気は？」くらいまで削られていきます。

さらに、なにがしたいかを最初に言い切ってしまったあとに、パラメータを入れてくるようなケースもあります（笑）。「天気教えて」「今日の13時の」みたいなかたちで、後ろにパラメータが断続的についてきます。これを抽出するの大変だなということになったりします。

よくあるものに関しては、ルールベースでがっちり取りますし、実際に使われるユーザーが少ないようなクエリに関しては、機械学習ベースでカバーを広げていくという取り組みをしています。

また、音声認識の結果を利用しますので、音声認識の多義性に関する問題というのはそのまま伝播していきます。この説明は先ほどしましたので、次に進みます。

実行できる機能が複数ある時はどうするか

最後に、実行できる機能が複数ある場合が考えらます。例えば「今日って寒いかな？」とユーザーがおっしゃった場合、返せることとしては天気のDomainで、「今日は最低気温が14度です」と返すことで、「あ、寒いんだな」とユーザーに思ってもらうというものです。

もしくはチャットとして返せる場合です。11月は寒いに決まっているので「はい、セーターが必要です」と返しておけば、東京の場合は大丈夫かもしれません。

もう1つは、両方が合わさったケースを返したほうがいい場合もあります。これはサービスの設計とも関連しますし、一般的にどのように返したほうがよいのかは、必ずしも決まっているわけではないため難しいです。

今後は、どんどんスキルが増えていきますし、外部の方が開発されるスキルもどんどん増えていきます。

そうすると、実行できる機能もどんどん増えていってしまうので、現実的にはユーザーから情報を提供していただいて、どうするとユーザーが喜んでくださるかを考えたうえで対処していくことになると考えています。

ここまで、3つのお話をしてきました。これらの課題について、どこまで解決できるかということがClovaの基本的な性能を底上げするために必要な取り組みです。ですので、継続的な改善やよりよい手法の研究を続けていきますし、みなさまにお伝えできるようなよい手法が生まれた場合には、きちんと伝える努力をしていこうと思います。

分類方法におけるそれぞれの利点と欠点

ここまで、Clovaの分類とキーワード抽出に2つの手法、ルールベースと機械学習の手法があることをお話ししました。それぞれの代表的な長所と短所は、ルールベースの手法に関してはユニークユーザーやクエリカウントが多いクエリに対するベストな正解率を実現でき、いろいろな人からの要求というものを柔軟に、そして完璧に実装することができます。

機械学習ベースの手法は、ルールベースの手法が持っている短所を完全に埋めるような長所を持っています。ユニークユーザーやクエリカウントが少ないクエリに対する高いカバー率を、ルールベースよりも低コストで実現することができます。

ただ、どうしてもコールドスタート問題を回避できませんし、データが大幅に更新されたときには事前に想定していた結果を出しづらいという問題も含まれています。

しかし、これらの手法の長所を同時に全部出し切るような手法というのは実はありません。よって、両方を状況に合わせて組み合わせて対処しています。

具体例の最後に、ユーザーがアニメやドラマ、映画のタイトルに関する曲をかけたいときに、Clovaが何をしているかを紹介していきます。とくに魔法があるわけではありません。事前にWebをクローリングして同意語辞書を作り、検索エンジンに組み込んでいるのです。

アニメソングの同意語に関してはいろいろ使っています。例えばしょぼいカレンダーさんなどにはかなりお世話になっています。その結果として「エヴァンゲリオンの曲」で『残酷な天使のテーゼ』をかけたりできます。

今後取り組んでいく課題

Clovaについていろいろ述べてまいりましたが、今後課題としてどんなことが残っているかについて言及したいと思います。

AIアシスタントの開発エンジニアとして感じる大きな魅力は、これまで話してきた人間の話し言葉に対して、機械が話し言葉で返せるという点にあると思います。この挙動はユーザー目線ではすごく自然なんですが、開発者目線では課題が山積みです。

しかし、課題が山積みだからこそ、もっと便利にできると考えています。例えばどんな課題が発生するかと言うと、今後弊社で画面付きデバイスを発売していくというお話をしましたが、その結果「今日の天気を教えて」が「今日の天気を見せて」に変わったりします。

さらに、Clovaが認識した文字列が画面に表示されたり、Clovaがユーザーにお伝えしたい情報が画面に直接表示されるということになります。こうなると、ユーザーの行動が、スマートスピーカー状態のデバイスを使っている場合に比べて大きく変わります。我々はそれに対処する必要があります。

このようなデバイスの進化は、開発に大きな影響を与えます。スマートデバイスのユーザーインターフェースを最終的に定義するのは、ユーザー一人ひとりだと思っています。

命令を声に出して使っていただく以上、気持ちよく言えるコマンドもあるし、しっくりこないコマンドもありますので、なるべくユーザーが思い思いのコマンドを使える方向で進化していくと思います。

最後に、これからAIアシスタントがやるべきことを一言で表すと、「人間よりも人間のことを考えなければならない」ということだと思います。

AIなら、ユーザーの周りの誰よりもユーザーのことを考えることができます。高い知性を表現できないのであれば、それを補う愛嬌も身につけることができると思います。結果として「あ、なんか俺、Clovaから好かれてるかも」みたいに感じていただけるとうれしいです。

そういった大きな目標をブレずに見据えて、より早く、より便利で身近な存在としてのClovaをご提供できるように、これからも開発を進めていきます。ここでお話をお聞きのみなさまと一緒に、Clovaを作れたらうれしいなと思っております。

発表は以上です。どうもありがとうございます。

（会場拍手）