ドメイン知識を用いてユーザを楽しませる
ルールベース雑談対話システム
TokoChanBot
TokoChanBot, a Rule-based Chatbot for Entertaining Users
with Domain Knowledge
Dolça Tellols
∗小河晴菜
Dolça Tellols
Haruna Ogawa
東京工業大学
Tokyo Institute of Technology
Abstract: In this work, we present TokoChanBot, a rule-based chatbot with domain knowledge implemented to participate in the 2nd Dialogue System Live Competition. The dialogue system processes users’ input and decides what kind of utterance will come next according to a Finite State Machine-based system. Then, it produces an appropriate utterance making use of information extracted from the users’ input, a knowledge base obtained by scraping from the Internet and manually prepared utterance templates. Since we gave TokoChanBot the personality of a high school girl who loves music, utterances revolve around this topic. In this paper, we also present the competition’s preliminary round results, where we achieved the first position.
1
はじめに
本稿では，対話システムライブコンペティション２[1] に参加した雑談対話システム「TokoChanBot」（以降， 「本システム」とする）に関して述べる． 雑談のような目的のないやりとりを行う対話システ ムを，非タスク指向型対話システムという．このような システムとして有名なものに，ELIZA [2]やALICE [3] がある．ELIZAは1960年代にテキストを通したコンピ ューターと人間のコミュニケーションを可能にした．ま た，ALICEはAIML[4]で作られたチャットボットで， ELIZAに基づいている． 一方，ユーザが目的を達成するために対話を行うシス テムはタスク指向型対話システムと呼ばれる[5]．このよ うな対話を行うApple社のSiriやAmazon社のAlexaなどが普及し対話システムへの関心が高まる中で，人間 に親しみを感じさせる対話を行うことのできる非タスク 指向型対話システムへの需要も高まりつつある． 本システムは，「短時間ユーザを楽しませる」ことを 方針とした雑談対話システムである．ライブコンペティ ∗連絡先: 〒 152-8550 東京都目黒区大岡山 2-12-1 W8-73 E-mail: [email protected] ションに特化することでシステムの目的を明確にし，ド メイン知識の利用や，ルールベースによる発話生成を行 うことで高い評価を得ることを狙った．
2
対話戦略
本章では，本システムの対話戦略について説明する． 本システムは今回のライブコンペティション（オープン トラック）専用のシステムとして作成しており，以下の オープントラックの特徴をもとに戦略を決定した． • 評価軸は「どれくらいまた話したいと思うか」と いう1つのみである． • 基本的に1人のユーザとは1回のみ対話する． • 1対話あたりの発話は原則16回である． これらの特徴から，仮にシステムが同じ内容の対話しか 行うことができなくとも，対話が自然で面白さを持つも のであれば，高い評価を得ることができると推測できる． 実際，昨年優勝したシステム[6]は，対話のドメインを土 地に絞ることで自然な受け答えを実現することを狙って いる．このため我々は，対話内容の多様性よりも自然さ を重視するべきだと結論付け，本システムの目標を「決 められた発話数まで，自然に見える対話を続け，相手を 楽しませる対話システム」と定めた．以降の節で，より 人工知能学会研究会資料 SIG-SLUD-B902-10 － 50 －詳しい戦略について述べる．
2.1
ルールベース
対話システムは，生成ベースのものとルールベースの ものが主流である． 基本的に，生成ベースのシステムは対話データから学 習されたエンコーダー・デコーダーモデルを通して発話 を生成する．どのような発話に対しても返信が返される ため，ユーザが入力しうる内容を考えなくてよいという 利点がある．しかし，このアプローチには様々な問題が ある．まず，学習には非常に大量のデータを必要とする． 学習で使ったデータが足りない場合，文脈に合わない発 話が生成される可能性が高い．さらに，発話が文法的な 間違いを含む可能性もある． ルールベースのシステムは，ルールに従って相手の発 話から出力を生成する．内容が限定されない雑談対話に おいて，相手の発話を予測することは難しい．そのため 一般に，ルールベースのシステムでは雑談対話に対応で きない場合が多い．しかし，今回のコンペティションで は発話数が限定されているため，対話テーマを誘導して 制限することで，人手で作成したルールで対応すること が十分現実的になる．また，ルールベースのシステムで は発話内容を手書きのテンプレートを元に生成できるた め，文法的に自然な出力を返すことができる． 以上の理由より，ルールベースのシステムの方が適し ていると考え，ルールベースのみでシステムを作成した．2.2
対話テーマ
前述したように，ルールベースで自然な対話の流れを 維持するためには，自由なテーマでの対話は難しい．そ のため，テーマを1つに絞り，システム側が質問を投げ 続けることで対話をコントロールし，ルールから逸脱す ることを防いだ．テーマには，サブトピックが豊富で優 れていることから音楽を選んだ．サブトピックの例を挙 げると，楽器，コンサートなどがある．2.3
キャラクタ
対話システムにキャラクタ性を付与することで，ユー ザに親しみを感じさせ，楽しませることができると考え られる．そこで，前述の対話テーマを踏まえ，システム には「音楽好きの女子高校生」というキャラクタを設定 した．他に，名前や好きな楽器などの詳細も設定し，対 話内で言及させることで親しみやすさを更に高めること を狙った．また，女子高校生という属性は，Microsoft社 の雑談対話システムであるりんな[7]にも採用されるな ど現代の日本文化において人気があるため，キャラクタ の魅力を高める目的で付与している．3
システム構成
本システムのルールベースシステムはSECA(Sentient Embodied Conversational Agents) 構築[8]に基づい ている．ここで，本コンペティションにおけるシステム 出力ではテキストのみが利用できると定められている． そのため，絵文字など他の要素は使用することができな い．SECAは具体化(embodiment)[9]を持つ対話シス テムのための構造であるが，具体化はシステムに表情や アバターを持たせるための機能であり，本システムには 必要ない．そのため，その機能を削除し，大幅に簡易化 している．具体的には，システムの表現とアプリの埋め 込みに関するモジュールを削除し，対話管理機構に関す るモジュール(対話モジュール，知識モジュール，記憶 モジュール)を変更した． SECA構築と同様，対話モジュールはFSM（ finite-state machine，有限オートマトン）を通して対話の流 れを決定する．対話管理機構に関しては，3.1節でさらに 詳しく述べる．知識モジュールは，アイディアは維持し ているものの大幅にリファクタリングを行った．本シス テムの知識モジュールはユーザ・キャラクタ情報（名前， 音楽の好み，弾ける楽器など）を保存し，さらにAIML を用いた発話パターンや，アーティストの情報などの知 識ベースを持つ．3.2節では知識ベースに関してさらに 詳しく述べる．記憶モジュールは，同じ内容が繰り返さ れないように出現したトピックなどを記憶する．3.1
対話管理機構
図1 TokoChanBotの構造 図1が表すように，対話管理機構は対話・知識・記憶 モジュールを用いてユーザの入力に対するシステムの出 力を準備する． 対話モジュールはFSMを通して会話の流れを決める． 図2は本システムのFSMの大枠を示す．FSMは，対 話トピックを選択するメインFSMと，各トピックの対 話の流れを管理するネストFSMに分けられる．例とし － 51 －図2 メインFSMの構成 図3 アーティスト・トピックのFSM て，図3にアーティスト・トピックのネストFSMを示 す．FSMにおける各ノードの説明を以下に示す． • トピック選択ノード：メインFSMにおいて，記 憶モジュールを用いてまだ選ばれていないものの 中から次のトピックをランダムに選択する． • 出力生成ノード：ユーザ入力並びに知識モジュー ルが管理するキャラクタ情報・音楽知識・発話パ ターンを用いて発話を生成し，出力する．例えば， 図3における「キャラクタ情報提示〜」ノードは， キャラクタ情報と発話パターンから「＜アーティ スト名＞って，知ってる？私，このアーティスト も好きなんだ．」というような出力を生成する． • 入力処理ノード：ユーザ入力を受理し，その処理 を行った後に次の状態を選択する．例えば「肯 定/否定判断」はユーザ入力から肯定か否定かを 判断し，その結果によって次のノードが決まる．
3.2
知識ベース
システムは，音楽知識と発話パターンの2つの知識ベ ースを持つ． 音楽知識は，国内，海外のアーティストそれぞれ1961 グループと115グループ，クラシック音楽の作曲家49 名についての，別名，代表曲名，使用楽器，ジャンルの情 報を含む．これらの情報は，Wikipedia*1および複数の 歌詞情報サイト*2から取得した*3．歌詞情報サイトから は，アーティスト名と代表曲名のみを取得している．シ ステムは音楽知識を元に，ユーザが好きなアーティスト に関する情報を発話に含めることができる．これにより， ユーザに「システムが自分の好きなアーティストを知っ ている」という喜びや驚きを感じさせることを狙った． 発話パターンは，手書きで作成したAIML形式の発話 テンプレートである．システムは発話を生成する際，現 在の状態に応じたテンプレートの中からランダムで1つ 選び，それを元に出力を生成する．発話は，「相槌+本 文」のように複数のテンプレートを組み合わせて生成す ることができ，それぞれがランダムに選択される．この ため，同じ状態であっても，組み合わせによって一定の 多様性を確保している．4
評価
クラウドソーシングを用いて対話システムの評価が行 われた．ワーカーは，本システムと対話を行った後，「ど れくらいまた話したいと思うか」を5段階（1が最低点， 5が最高点）で回答する．評価には45名のワーカーの評 *1https://ja.wikipedia.org/ *2https://www.uta-net.com/，https://utaten.com/ *3国内アーティストは自動取得のため，重複を含む可能性がある． － 52 －S:じゃあ，＊＊＊さんの好きなアーティストっている？ U:槇原敬之さん大好きです． S:槇原敬之かー！もう恋なんてしないを歌ってる人だよ ね？ U:そうそう！詳しいんだね！ S:やったー，当たった！私はいきものがかりが好きで，あ りがとうとかおすすめだから，良かったら聴いてくれ たら嬉しいな！槇原敬之のどこが好き？ U:トーコさんはいきものがかりが好きなんだね，今度聴 いてみるね．マッキーは透明感のある歌声が好きだな． 図4 上手くいった対話例（Sがシステム，Uがユーザ） S:はじめまして〜！トーコです！今は高校に通ってます． あなたのお名前は？ U:はじめまして．＊＊＊です． S:なるほど〜！そしたら，はじめまして．さん，って呼ん でもいいかな？ S:良かった！TTって曲がいいんだよね〜．聴いたことあ る？ U:ないんですけど，どんな曲なんですか？ S:おすすめだから，よかったら聴いてみてね！ところで， ＊＊＊さんは楽器って演奏できる？ 図5 問題のあった対話例（Sがシステム，Uがユーザ） 価点の平均値が用いられた．本システムの平均スコアは 4.2だった．結果，対話システムライブコンペティショ ン2の予選で1位タイとなり，決戦に進んだ． ワーカーによるフィードバックを見ると，「楽しかっ た，良かった」という趣旨の意見が7つ，キャラクタが 良かったという意見が3つ，ドメイン知識を評価する意 見が2つあり，対話戦略が比較的有効に働いたと考えら れる．さらに，「スムーズ」という意見が4つ，「反応 が早い」という意見も2つあった．これは，設計時には 考慮していなかったルールベースの利点である．毎回発 話を生成する必要がある生成ベースの対話システムと比 べ，ルールベース対話システムはテンプレートを利用す るため，ユーザ入力を受け取ってから出力を返すまでの 時間が短い．そのため，ユーザを待たせることなく対話 を続行することができる．対話のテンポを失わなかった ことも，高い評価に繋がった要因であると推測できる． 図4に高評価を得た際の対話例を示す．システムからの 質問により想定内のユーザ発話を引き起こすことで，自 然な対話の流れが実現されていることがわかる． 一方，発話理解力不足と対応力不足の指摘もそれぞれ 2つあった．前者については，ユーザ入力処理を非常に 単純なルールで行ったことが理由であると考えられる． 後者については，想定していない入力が行われた際，シ ステムが内容を無視したり，入力と噛み合わない反応を 返す例があった．これは，入力を予測する必要があるル ールベース発話生成の大きな弱点である．図5に，内容 が不自然になった対話の例を示す．発話理解に失敗した 場合や，ユーザに質問された場合など想定外の事態への 対応力が弱いことが分かる．特に発話理解力不足による ミスが大きく目立つため，その点を改善することで大幅 にシステム全体が良くなることが期待できる．
5
おわりに
本稿では，対話システムライブコンペティション２に 参加した雑談対話システム「TokoChanBot」に関して 述べた．本システムは音楽に関するドメイン知識を持つ ルールベース対話システムとして設計されており，ユー ザ入力とFSMの状態を元に出力を決定する．知識ベー スを用いることで，システムがユーザの発話を深く理解 しているように見せかけ，ユーザを楽しませることを狙 った．コンペティション予選ではクラウドワーカーによ る評価が行われ，9チーム中1位を得た．キャラクタ付 けや，ルールベースによるテーマを限定した対話など， コンペティションの特徴に合わせた設計を行ったことが 高い評価に繋がったと考えられる．一方，ルールベース の弱みである発話理解不足や対応力不足への指摘もあっ た．発話理解部の改良や，FSMの想定対話からのずれを 検知した際の対応などを用意することにより，ルールベ ースの利点を残しながら，より違和感のない対話を行う ことができると考えられる．これらは今後の課題である．参考文献
[1] 東中竜一郎, 船越孝太郎, 稲葉通将, 角森唯子, 高橋哲朗, 赤間怜 奈, 宇佐美まゆみ, 川端良子, and 水上雅博. 対話システムライブ コンペティション 2. In 人工知能学会言語・音声理解と対話処理 研究会第 87 回 (第 10 回対話システムシンポジウム), 2019. [2] Joseph Weizenbaum et al. ELIZA—a computer program forthe study of natural language communication between man and machine. Communications of the ACM, 9(1):36–45, 1966.
[3] Richard S Wallace. The Anatomy of A.L.I.C.E. In Parsing the Turing Test, pages 181–210. Springer, 2009.
[4] Richard Wallace. The elements of aiml style. Alice AI Foun-dation, 139, 2003.
[5] 奥村学監修. 対話システム. コロナ社, 2015.
[6] 杉山弘晃, 成松宏美, 水上雅博, 有本庸浩, et al. 文脈に沿った発 話理解・生成を行うドメイン特化型雑談対話システムの実験的検 討. SIG-SLUD, 5(02):118–123, 2018.
[7] Xianchao Wu, Kazushige Ito, Katsuya Iida, Kazuna Tsuboi, and Momo Klyen. りんな: 女子高生人工知能. 言語処理学会第 22 回年次大会発表論文集, pages 306–309, 2016.
[8] Dolça Tellols, Maite López-Sánchez, Inmaculada Ro-driguez, and Pablo Almajano. Sentient embodied conversa-tional agents: Architecture and evaluation. In CCIA, pages 312–321, 2018.
[9] Justine Cassell, Joseph Sullivan, Elizabeth Churchill, and Scott Prevost. Embodied conversational agents. MIT press, 2000.
