会話の文脈を理解する電話応対AI「LINE AiCall」開発で苦心したこと

電話応対AIの仕組み

KyoungTae Doh氏：それでは、電話応対AIの記述についてお話します。これは非常に一般的なAIスピーカーの仕組みを示したものです。おそらくみなさんご存知かと思います。

ユーザーがリクエストをしますと、これは音声ですよね。AIに話しかけて、それがサーバのゲートウェイに送られます。これはストリームとして送られます。ゲートウェイからSpeech Recognizer、音声認識のシステム（ASR）に送られます。音声をテキスト変換します。そこからNLUとDMを使って合成音声（SYNTH）での答えを生成することになります。

どのようにして答えるかを決めて、そこをテキストにするわけです。その結果、合成音声を作り出して、ユーザーがその答えの音声を耳から聞くアーキテクチャになっています。

一方、電話の場合ですが、少し先ほどのAIスピーカーの場合と比べると違いがあると思います。ゲートウェイと電話の間には、duplex、複信方式という状態が発生しています。送信の部分と受信の部分で送受信がリアルタイムで同時に行われている状態です。

なので、これに関してテクノロジーとして開発していくべきものが発生します。

こちら覚えてますよね？　先ほどお見せしたものです。Overlapがあるとお話ししました。ここでOverlap、割り込みについてフォーカスをしていきます。

システムが話していて、ユーザーがかぶせて話してきたとき……つまりシステムがユーザーからの問いかけなどに対して答えを発していて、ユーザーが割り込んできたとき、どうしたらいいでしょうか？　システムはその瞬間に話すのをやめるか、もしくは音量を下げる必要があります。これがBarge-inのための機能になります。

この開発方法はこのようになります。なので、会話コントローラーが必要になります。Barge-inが発生したときにこのコントローラをこちらに置くことによって、先ほどの機能が可能になります。

音声認識の問題

音声認識ではほかにも問題があります。最近、VoIPでは24KHz以上で、音質も非常によくなってきています。しかし、電話自体は8KHzがスタンダードになっています。なので、8KHzの回線がどこでも接続されている状態になっており、私たちからコントロールできることではありません。なので、新しい音声認識システムが必要となっています。

また、音声合成も向上しました。こちら、AIスピーカーのトーンにフォーカスして、より自然な人間のようなトーンが電話では必要だとわかりました。これはAIスピーカーのように自然な人間の音声でないと、電話では不自然だとわかったためです。

こちらがペルソナと呼んでいる音声の特徴を示しているものです。そのAIスピーカーがおしゃべりなのか、饒舌なのかどうか。また、話す速度はどうか。割り込みをしてくるのか、音量はどうかといった、このような特徴づけの定義が必要になってきます。

また、まったく新しいモデルもこのプロジェクトで開発をしました。どのようにして会話を分析、また予測することで認識の精度を高めるかが大事になってきます。これがContextual Hintsです。

そしてTask Movementについてもお話ししました。また、Barge-inについても先ほどお話ししたとおりです。なので、Multi-turnについてお話をしていきましょう。Multi-turnのNLUについてです。

まずSingle-turnを理解する必要があります。フレームワークについて説明した際にTurnという説明をしたと思います。Single-turnはCommand & Control、指示をして回答を受けるというものですが、Multi-turnというのは会話の文脈を理解するということです。

この数字はSingle-turnとMulti-turnの性能の違いを示しているものです。

2週間前、私たちのチームで問題をAPIの中で発見しました。これは漢字をデータベースに保存するときに発生した問題でした。これは深刻な問題となっていたので、分割統治法を使ってこのNLUにおいての問題を調べてみました。

このコードをまず作成しました。ここではパラメータがあります。これは発話のhistoryのパラメータです。これはutteranceというのはつまりユーザーが発した言葉です。そして、historyというのはつまり文脈を示しているということになります。

これはSingle-turnのコードになります。これでNLUをテストしてみました。

これはMulti-turnになります。

ここでスクリプトを読んでいただければわかるかと思います。historyが書いてあるのがわかります。そして、名前を聞いているのも見えるかと思います。ここでコードを見ていただければ、print(failure)となっているのがわかるかと思います。

こちらが結果です。左のSingle-turnでは、1,138のエラーがNLUで出ていますが、右のMulti-turnでは18しかエラーが出ませんでした。

なので、72パーセント対99パーセントの精度の比較になっています。

なぜUXエンジニアリングが重要なのか

このように、Multi-turn NLUの性能を目の当たりにするのは、私たちのチームにとっては初めての経験でした。APIでエラーが出たおかげで、このような瞬間に立ち会うことができました。これは2週間前に起こったことです。

では、エンジニアリングにおけるほかのイシューを見てみます。では、エンジニアの声を聞いてみます。

（映像が流れる）

システムをビルドする前に、まず電話のネットワークの問題を解決する必要があります。ローカルの通信キャリアおよびインターネットの電話のプロバイダ、TwillioやNexmoといったものがありますが、こちらを利用してスペックの調整が可能になります。

また、PSTN、VoIP、最新のWebSocketといったものを用意しました。ユーザーが利用している電話ネットワークが幅広く多様なためです。

またレイテンシーの問題は、AIスピーカーに比べて電話のほうがセンシティブでした。なので、ここで非同期アプローチを使いました。GPU・ネットワーク・ストリームの最適化の対策に加えて、ここでフォーカスしたいのは、私たちがこの途中結果を利用したということです。

音声認識システムでは、発話のエンドポイントで最終結果を返します。しかし、最終結果の前に認識システムは途中結果も返します。これを見ることで、ユーザーが話し終わる前に結果を取ることが可能になります。

では、なぜUXエンジニアリングが重要なのでしょうか。デザインとエンジニアリングには大きな差があります。設計されたパスは必ずしもユーザーが辿るパスどおりではありません。なので、これを効率よく改善するための方法として、こちらのActivity Taskを見ていただきたいです。

こちらは4つのActivityで最初は設計していましたが、多くの問題が実際のリスケジューリングのTaskで出てきました。ここには、2つ目にスケジュールを入れるべきだったんですね。

このように現実にある問題に直面するので、そちらを解決していく必要があります。

頻繁に起きるTask Movementにどう対処するか

Task Movementについては先ほどもお話ししました。人間は論理的だと思われるかもしれませんが実際そんなことはないんです。このTask Movementはかなり頻繁に起こってくるものです。こちらの例でおわかりいただけるかと思います。

実際に設計をしてからテストをすると、たくさんの問題が出てきます。なぜなら設計どおりにいつもうまくいくわけではないからです。なので、ここでシステムとこの会話をどちらもデザインし直すことで改善する方法を考えました。

Dialog Managementは交通信号機のような役割をしています。

UXデザイナーとエンジニアで使っているグラフは異なっていました。UXデザイナーがどのようにして予約を取るかというグラフを設計して、エンジニアの作るグラフはデザイナーが作ったグラフとは異なっていたのです。なので、その両者のために1つのインターフェースを用意することにしました。これによってDMをプロトタイプ作成ツールとして使えるようにしました。

これはスロットフィリングの例になります。予約をするときに、いつ何時に何人で予約をしたいかという情報があります。そして、実際に予約が可能な時間帯と照らし合わせる必要があります。

では、このプロジェクトから得た教訓などについて、Ph.D.を持っているLee Sang-Wooさんのコメントを見たいと思います。

（映像が流れる）

こちらで私のプレゼンは以上になります。

本当にこのようなプロジェクトが可能なのかというエピソードをお話ししました。今日からは日本でローンチをします。そちらが可能になったことをお伝えして終わりたいと思います。

ありがとうございました。

（会場拍手）