概要

　近年, 雑談のように特定のタスクを目的としない非タスク型対話システムの研究が活発になりつつある. 特に昨今ではスマートフォンアプリ等のエンターテインメント分野への応用が期待されている. また，チャットアプリケーション等の普及に伴い，人間同士の会話ログの利用も比較的容易になってきた．このような背景の下，本稿では会話ログを用いた非タスク型対話システム(チャットボット)の提案を行う. 

目次

1.はじめに

　これまで, 路線案内やレストラン検索など, 特定のタスク遂行を目的とするタスク志向型対話システムの研究開発が行われてきた. 近年, 雑談のように特定のタスクを目的としない非タスク型対話システムの研究が活発になりつつある. これらはスマートフォンアプリやペットロボット等のエンターテインメント分野への応用が期待されている. 本稿では, チャットボットと「人間的」な対話を通じることにより, ユーザがチャットボットに対して愛着を深めてゆけるような非タスク型対話システムの実現を目指したプロトタイピングについて報告する. 

2.背景

2-1.チャットボットとは

　対話システムとは, 人間と自然言語でコミュニケーションを行い,情報を授受する機械またはソフトウェアである. 中でも会話の目標を持たないものは非タスク志向型対話システムあるいはチャットボットと呼ばれる[6].

　中野らによると[6]，チャットボットの起源は1960年代初頭のBaseballという自然言語を用いたデータベース検索とされている. この時期の著名なチャットシステムとしてはWeizenbaumによるELIZAがある. これは心理療法士の模擬が目的だが非タスク型的な側面を持ち,以降の研究に大きな影響を与えた. 1970-1980年代は音声対話の研究開発が増え,1990年代には対話的操作機能を搭載したカーナビゲーション等への実用化が行われるようになった.1990年代後半以降は音声以外の領域を含めたマルチモーダルなシステムの研究が増えた. 2000年代後半にはA.L.I.C.E.のようなWeb上のキャラクターエージェントとテキスト対話が可能なシステムが登場した.2010年代以降はスマートフォンアプリケーションにおける自由発話理解システムが増え現在に至っている.

 　尚, 1990年代中頃以降，インターネットの普及に伴い日本でも独自のチャットボットを持つ(「人工無能」と呼ばれることも多い)アプリケーションが増え, 個人の掲示板やチャットルームにチャットボットを設置することが流行した[8].　

 　この「人工無能」の文脈では, システムの構築方法に応じた以下の3分類を用いて説明されてきた[7].

1. 辞書型
2. ログ型
3. マルコフ文生成型(テキスト生成型)

   本レポートのスコープは「非タスク志向型対話システム」のプロトタイピングとする.  ここでは, 1+2のアプローチを採る. 今回, 一発話テキストの生成にマルコフモデルを用いることは実施しないが, 後述のように発話行為分類ラベルのマルコフ性を考慮する. また，本稿で論じるプロトタイプシステムで用いたログは，チャットボットと人間による会話のログではなく，チャットアプリケーション等で交わされた人間同士の会話のログである． 

2-2.関連研究

　会話ログ等のテキストコーパスベースの非タスク志向型対話システムに関する研究事例は近年増加傾向にある. これまでに研究されているテーマとしては, 例えば以下のようなものがある. 

1. コーパスからの隣接ペア抽出に関するもの
   1. 最適な返答候補の選択するための,スコアリング方法に関するもの[4]
   2. 対象候補メッセージのクラスタリングに関するもの[1]
   3. チャットログから発言間の継続性や応答関係を同定するもの
2. トピックにマッチする発話文をコーパスから探し出すことに関するもの
3. コーパスデータのフィルタリングに関するもの
4. コーパスから学習したモデルを用いたテキスト生成に関するもの
5. 対話行為分類に関するもの[2][9]
   1. 対話行為分類に基づく対話制御に関するもの
   2. 対話行為の分類方法に関するもの

　対話行為とは発話者がの意図を持って発話する行為のことであり, その意図がどのような種類のものなのかを判断するために用いられるのが対話行為分類(「対話行為ラベル」とも呼ぶ)である. この分類には「質問」や「肯定」や「相鎚」などの発話の種類に関するものが含まれる.  

　本レポートでは, 上記アプローチのうち1.を部分的に採用しつつも, 特定の手法のみを採ることはしない. 

2-3.対話システムの応用例

　非タスク型/タスク型を問わず, 対話システムは実世界のアプリケーションとして定着しつつある. 代表的なものを以下に挙げる: 

• タスク志向型対話システム
  • 情報の検索・推薦や各種ガイダンス・予約機能等のタスクに特化したシステムが存在している. 部分的に非タスク志向型要素が取り込まれていることもある.  
• 非タスク志向型
  • 例えば恋愛育成アプリ等での利用がみられる. 既にいくつかのアプリケーションが存在する.
  • チーム開発効率化のためのツールとしてのチャットボットへの期待が高まっている. 

　本稿では以降, 次章でシステム概要と構成モジュールの説明を行い, 4章でプロトタイプシステムの説明を行う. 5章では提案システムの評価と考察を行い, 終章にて総括する. 

3.システム概要

3-1.全体概要

　チャットアプリケーション等で生成される会話ログからチャットボットの生成を試みる. 本レポートではコストの観点から, 人手による学習データが必要な手法は採らない(当然ながら比較評価時にはある程度必要になるが,今回は実施しない).

　提案システムはデータ生成部と対話API部により構成される. データ生成部では会話ログの収集, 変換, 分類などを行い, データストアへの蓄積までを担当する. 対話API部では,ユーザからの発話入力に応じて都度データストアを参照しながら最適な会話候補を提示する. 

　以降の節で, 個々のモジュールについて説明する. 

3-2.データ生成部

　本節では基本的なデータ作成フローを示す. 本処理はバッチ実行を前提とする. データ生成処理概要を下図に示す. 

3-2-1. ログデータからのデータ抽出処理

　ここでは生ログから対話モデルの要素データとなるメッセージを抽出し検索インデクスへ登録するところまで説明する. 検索エンジンとしてはElasticsearch-1.4.2, 形態素単位のインデキシングにはKuromojiを用いた.

　データ抽出処理部はさらに前処理部と分類・フィルタ部の2つのサブシステムにより構成される.

　・前処理部

1. 2ユーザで行われた対話を抽出(3-2-3を参照)
2. 複数の発話に跨って記録された同一ユーザの連続発話を1発話にまとめる処理
3. 1対話セッションのレングス(ある2人の発話の総数)が閾値以上のものを抽出

　・分類・フィルタ部

1. NG表現(差別・ポルノ・暴力)や個人情報, 人名が含まれるメッセージを除外
2. 言語判定処理で特定の言語(本稿では日本語を想定)以外と判定されたものを除外
3. 1発話内に含まれる文境界分割処理
4. 文字の正規化(半角カナ→全角カナ変換等)

3-2-2. 対話行為分類 

　本稿で利用した対話行為分類ラベルとその統計情報を表1に示す. 分類には階層関係を持たせており, 第1階層は10分類, 第2階層を含めると40分類を持つ(図は第一階層のみ). 今回対話行為分類の統計用に用いたデータは約20日分の会話ログである. 本稿では, 各発話についてルールベースで40種類の対話行為に分類した. 対話ペアについてはペアの各発話にそれぞれ対話行為ラベルを付与した. 

表1. 対話行為分類とその含有率 　 

3-2-3. 挨拶・相槌表現ペアの抽出

　対話ログ上で見られる, 複数のユーザによる同一対話表現パターンを抽出する. 本レポートでは, 表層レベルでのマッチングを基準とした. 「挨拶・相鎚表現ペアの抽出」とは, 挨拶・相鎚表現が多く抽出されることから便宜上名づけたものであり, 挨拶・相鎚以外にも対象とするログデータ上で多く見られる対話表現ペアが抽出される. 以下に抽出されたサンプルを例示する.

上記データはメモリに展開しても問題ないサイズに収まることから, トライ構造としてストアした. トライ構築にはmarisa-trieを利用した.

3-2-4. 会話ログ以外の知識データの抽出

　以下の知識源からデータを抽出し, チャットボットの返答候補に追加した. 

1. ニュース記事タイトル
   定常的にデータをクロールし, ページをスクレイプすることにより, ニュース記事タイトルとそのリンクURLペアを得た.  
2. Wikipedia記事タイトル
   日本語の記事タイトルのダンプデータを都度取得し, タイトルとそのリンクURLペアを得た(今回はスコープ外)

3-2-5. Document Frequencyの計算

　発話理解部(後述)での利用を想定し, 3-2-1.で作成された発話インデクスデータからDocument Frequencyの値を計算する. 

3-2-6. データストアへの登録

　ここでは,前節までに作成したデータを検索インデクスやトライに登録する. 

1. 生成されたデータを「1発話=1インデクス」として検索エンジンへ登録(以下「発話インデクス」とする)
2. 生成されたデータを「1対話=1インデクス」として検索エンジンへ登録(1対話とは連続する2ユーザの対話ペアのことを指す, 以下「対話ペアインデクス」とする)
3. 3-2-4.で生成されたデータに対して,リンク先の情報を加えた上で検索エンジンへ登録
4. 3-2-3.で生成されたデータをトライに登録
5. 手動で作成した返答テンプレートをトライに登録

3-3.対話API

　本節では,前節のデータが与えられた想定の下, ユーザ発話が入力された際の対話APIでの処理について述べる. 対話APIは, 1)発話理解部, 2)対話管理部, 3)出力生成部 のサブモジュールにより構成される. 入力された発話はまず発話理解部でシステムにとって理解し易い形に変形され, 対話管理部で現在の状態から次の状態へ遷移する際に最適な対話行為を選択する. 発話生成部内ではこれらの情報が検索クエリとして成型され, 検索実行後に返答候補を選択する処理を実行する. 

3-3-1. 発話理解部   

　ここでは入力された発話について以下を実施する:

• 発話行為分類: データ抽出時と同様の分類器を用いて, 入力された発話の分類を行う. この時得られた分類はスタックしておく. 
• 重要語抽出: 発話のメッセージ本文から重要な語句を抽出する. ここでは, 形態素解析とDocument Frequencyの値を用いる. 
• 今回はスコープ外となるが, 発話理解部でトピックやドメインラベルを付与することも試行している. 

　尚, 上記過程で得られた検索クエリは, 本ステップで得られた分類で絞り込んだ状態で検索エンジンに与えられる. 

3-3-2. 対話管理部

　対話開始時から入力された対話行為の列に基づき, システムが出力すべき発話の候補が持つべき発話行為分類を学習したモデルから決定する. 上記タスク指向型システムの場合は、対話管理部のモデリングにおいてPOMDPやMDP等のマルコフ決定過程に基づく手法が用いられることが多い. しかし, 今回のような非タスク志向では適切な報酬を設定することは容易ではない(今後の課題). このため, 提案システムでは上記手法よりも比較的シンプルな, 対話行為分類のN-gramに基づく重み付き有限状態トランスデュータ(WFST)[9]を用いた. トランスデュータはオートマトンの一種であり, 状態間の遷移に重み(スコア)を持つ. 重み付き有限状態トランスデュータの概略図を下図( [9]より引用 )に示す. 

　学習データは対話行為列をセッションごとに区切ったものを1文書と見立てたものを用い, このデータからN-gramベースのWFSTモデルを作成した.　尚, 必要なデータを作成するために言語モデルツールキットkylm[10]を用いた. ツールの設定において, N-gramのnは4, 平滑化手法にはKneser-Neyを用いた. 

3-3-3. 出力生成部

　ここでは, 複数の検索エンジンやデータを用いて返答候補を作成する. 尚, 本処理については目的やニーズに応じて組み合わせを変えることを想定している. 以下に後述のプロトタイプで用いた処理概要を示す. 

尚, 上記「スコア」は検索エンジンが返すスコアを想定している. 閾値はチューニングにより決定した. 

3-3-4. API出力

　API部が生成するレスポンス例を以下に記す.

"input_state"と"input"はリクエストで与えるパラメータでありそれぞれ"入力時のWFSTの状態", "入力文"をそれぞれ意味する. input_daはinputに対する対話行為ラベル, replyは返答文,reply_daは返答文の対話行為ラベル, next_stateは返答文が出力された後のWFST状態, scoreはelasticsearchが返すreplyの検索スコアをそれぞれ表す. typeは返答生成ロジックのタイプであり現在,{greets, 　greets_and_search,　search,　dialogue,　news}の5種類を用意している(それぞれ「挨拶・相鎚」「挨拶+発話インデクス」「発話インデクスのみ」「対話インデクスのみ」「ニュース記事タイトルインデクス」を意味する).

4.プロトタイピングと実験

　本章ではプロトタイピングシステムの説明と出力について例示を行う. 会話データには「アメーバピグ」の会話ログデータ約2ヶ月分を用い, ニュースデータにはアメーバトピックスのトップページ記載の記事約100件を利用し定常更新している. 

4-1. 利用データの統計

　本システムで用いたデータの件数を以下に示す. インデクスについてはインデクス件数, その他は件数とする.

表2. プロトタイプシステムのデータ種別毎の件数

21,991,108 

6,268,067

105

66,221 

65

4-2. 実験に用いたシステム

　今回の実験では1台の仮想マシン(8GB,2Core,Ubuntu)にバッチとAPIの両機能を持たせた. 検索インデクスやトライ等のデータもすべて単一マシン上に収めた. 

まず, システムのAPI構成図を以下に示す. 

　API内のチャットボットクライアントモジュールにより入力メッセージストリングに対する前処理が行われた後に, チャットボットサーバへ渡される. その後, 検索エンジンクエリの形に成型され,複数の検索インデクスに応答要求する. 適合した返答候補を応答生成部に与え, 選ばれた最終的な返答が出力される仕組みである. 

4-3. システムの出力例

　以下にシステム出力例を示す. 

4-3-1. 単体発話に対する出力例

　以下の例中では, Uはユーザ発話を, Bはチャットボットの出力をそれぞれ示す. 

　A) 妥当と考えられる出力例

　B) 妥当であるとは考えられない出力例 

U モトリークルーって知ってる？

B 知らん、モトリークルーのトミーリーってドラマーが凄いっす

U そういえば北海道に行ったことある？

B ぇ～スゴイねっ♪

4-3-2. 複数対話の出力例

　連続する対話の事例を以下に示す. 

4-3-3. チャットボット同士の会話

 　以下は, チャットボット同士で会話をさせた例である.　初期入力文は人手で与えた. 

 この例では, 各発話に対する単体の返答は大きく逸脱していないが, 全体としてトピックが漂流している. 

4-4. プロトタイプシステムの評価

4-4-1. 文脈を考慮しない単体発話に対する出力の評価

　主観評価を実施した. システムはテスト入力文258件に対して, それぞれ出力候補を3つ提示した. この3候補と入力文との妥当性について, 被験者が下記の基準で採点する. 

結果を下表と下図にて示す.

表3. 評価値毎の件数とグラフ

　評価値の平均値は3.225となった. 尚, 評価リソースの関係上, 複数対話セッションに対する評価は今回は見送った. 

4-4-2. レイテンシ

　1発話に対するシステム返答についてレイテンシを計測した. 具体的には, 開発端末から開発サーバへhttpリクエストを30回実行した. この時, ブラウザ(Chrome)にてレイテンシを計測した. 下表にサマリを示す.

表4. プロトタイプシステムのレイテンシ

5.考察

5-1. 実験の考察

　4-4-1の結果については, 値が3を少し上回った. このことは「全体としてみれば2/3強の出力は妥当」と考えることができる.　ただし, 評価値1+2の割合が29%という結果については, 今後の向上の余地が大いにあると考えられる.

　4-4-2のレイテンシについては現段階のデモシステムとしては妥当と考えられる. 今後は負荷テスト等も実施したい.

5-2. 課題と今後の展望

　本節では課題と今後の予定を整理する. 

5-2-1. 課題

• トピックドリフト対応
  今回は文脈のトピックを考慮するモデルを採用しなかったこともあり, トピックドリフトが見られた. 特にチャットボット同士の会話でドリフトが顕著にみられた. 人間とチャットボットの会話においては, 人間によるドリフトに対する修正が機能していると考えることもできる. 今後, NPC間での会話のように, ボット同士の会話についても確度を上げてゆきたい.このためには発話の文脈の各所においてトピック分類等の手法が必要になると考えられる.  
  
• 検索ミスマッチ
  本手法は現状では検索インデクスとのマッチングに依存しているため, 検索ミスマッチを減らすことも大きな課題となる. 特に, 会話ログに多く含まれる平仮名表記への対応は今後の精度向上に寄与する期待できる. また,重要語抽出についても未評価ながら精度向上余地があると考えられる.

5-2-2.今後の展望

• 非タスク指向型システムにおける報酬系の設定　
  今回は見送ったが, 対話における報酬の概念を持つMDP系の対話行為モデルを用いる際には報酬関数を上手く設定することが求められる. 先行研究で用いられたセッションレングスや人手評価値のほかにも, 対話ログ中の語彙や対話完了語のログ, その他のユーザ行動情報等から報酬を設定する等, 人手を介さずに報酬系を学習できるような手法を目下検討している. 今後はこの方法についても追究したい.
   
• チャットボットへのキャラクターの導入　
  本稿では言及しなかったが, ユーザがボットに対して抱く「愛着」の実現のためにはキャラクター性が必要という仮説を持っている. 今後はこちらも追究したい. 
  
• インデクス登録件数の増加　
  今回使用したデータボリュームは数百万から数千万のオーダーであったが先行研究[4]では15億件のメッセージを利用している事例があった. 今後はその値までデータを増やすことに加え, 発話インデクス数と性能の関係についても調査したい. さらに, データ量を増加させた際のあるべき構成をシステム面からも検討したい. 
   
• テンプレートの利用・自動生成
  対象対話行為ラベルを持つ発話がインデクスに存在しない場合に対話行為ラベルごとにテンプレートを用意しておくことや, AIML等の規則セットの導入は有効と考えられるが, 多大なリソースが必要となるため今回は見送った.今後は半自動生成手法などを検討したい.  

6.おわりに

　本稿では, 会話ログを利用した非タスク志向対話システム(チャットボット)を提案し, プロトタイプによる試行とその分析について述べた. 課題はあるが, 現状でも実サービスへの応用が期待できると考える. 

参考文献

[1] R. Higashinaka, N. Kawamae, K. Sadamitsu, Y. Minami, T. Meguro, K. Dohsaka, H. Inagaki, Building a Conversational Model from Two-Tweets, ASRU, 2011.

[2] T. Meguro, R. Higashinaka, Y. Minami, and K. Dohsaka. Controlling listening-oriented dialogue using partially observable markov decision processes. In Proceedings of the 23rd International Conference on Computational Linguistics, pp. 761-769. Association for Computational Linguistics, 2010.

[3] S. Young, M. Gasic, S. Keizer, F. Mairesse, J. Schatzmann, B. Thomson, and K. Yu. The hidden information state model: a practical framework for pomdp-based spoken dialogue management. Computer Speech & Language, Vol. 24, No. 2, pp. 150-174, 2010.

[4] 稲葉通将，神園彩香，高橋健一., Twitterを用いた非タスク指向型対話システムのための発話候補文獲得. 人工知能学会論文誌, Vol.29, No.1, pp.21-31, 2014. 

[5] 洪陽杓, 白井清昭., 対話行為タグ付きコーパスの作成支援. 言語処理学会第11回年次大会, pp. 815-818, 2005. 

[6] 中野幹生, 駒谷和範, 船越孝太郎, 中野有紀子, 奥村学 Ed., 対話システム, コロナ社, 2015.

[7] 冨坂亮太, 鈴木崇史., 人工無能(会話ボット)., 映像情報メディア学会誌. Vol. 64, No.1, 2010.

[8] 人工無能は考える. http://www.ycf.nanet.co.jp/~skato/muno/1intro/history.html.

[9] C. Hori, K. Ohtake, T. Misu, H. Kashioka, S. Nakamura, Dialog management using weighted finite-state transducers, INTERSPEECH, pp.211–214, 2008.

[10] G. Neubig.  Kylm - 京都言語モデルツールキット. http://www.phontron.com/kylm/index-ja.html.