係り受けを利用した雑談チャットボット実験例

対話型のチャットボットを作成する上で、ユーザーと雑談できる機能は特にパーソナルアシスタントを志向する領域においては不可欠だろう。
旅行の予約、飲食店の検索など何らかの目的があったとしても雑談をするユーザーが必ず存在することが知られている。また、雑談をすることで信頼性が増すことはリアルの店舗などでのやり取りでも実感があるところなのではないだろうか。

雑談を行うには、どのような対応が必要なのだろう。ユーザーは自ら話題を広げる必要がある場合、その手間を苦痛に感じて離脱する可能性が高い。また、関連性の低い話題が振られると、いかにも非人間的であると感じるだろう。よって、関連性の低い話題を避けつつ、関連する話題を適切に導入する、という両面を両立させなければならない訳だ。

上記を達成するために係り受けを利用した雑談対応の実験例を紹介する。

ルールベースアプローチ

雑談を行う対話システムは、ユーザーの発言に含まれる単語をトリガーにして予め用意しておいた返答を返す、いわゆるルールベースのアプローチが多い。特に有名なものとしてはALICEが知られており、下記のようなやり取りを行うことができる。

一方で、ルールベースの欠点としては多様な話題をチャットボット側から提供し続けることが非現実的であり、出力するデータを拡充していくには莫大なコストがかかるという問題があると指摘される。

Web/Twitterアプローチ

一つの試みとしては、Web上での会話を事例として、適切な回答例を検索し提示するというものがある。しかし、これも対話において長すぎたり不自然な場合も多い。
そこで、Twitter上の短文をベースにしてはどうか、というアプローチが存在する。具体的には、IR status、IR response、MT chatという3つの手法が存在し、まず元ツイートをstatus、返信ツイートをresponseとして一対のペアとする。IR statusは、ユーザーの発言に似たようなツイートを検索し、このペアとなるresponseを返信するという方法だ。逆に、IR responseはstatusの代わりにresponseを用いて類似文を検索し、そのままチャットボット側の発言とするものである。残念ながらどちらも、完全なアプローチとは言い難い。MT chatは、responseとstatusを元に、機械翻訳の手法を用いてチャットボットの発言を生成するというアプローチであり、文法的な誤りが生まれやすいものの、ユーザーに好まれる返答をすると評価されているが、やはり完全な返答を作成するものではない。

係り受けアプローチ

これは、係り受け関係にある文節をペアとしてユーザーの発言に含まれる係り受けのペアと、コーパス内にある係り受けペアを組み合わせて回答を作成するというアプローチだ。

例えば、「東京に行きたいです」というユーザーの発言を受けた場合、まず、係り受け抽出部で係り受け解析を行い、「東京に→行きたいです」という係り受けペアを得る。
次に、関連係り受け検索部では、得られた係り受けペアについて、「東京に」「行きたいです」というそれぞれに関連する係り受けペアを検索する。
例えば、「行きたいです」に関連する係り受けペアは「行ったら→登りたいな」というものがあり、「登りたいな」という文節に関連する係り受けペアとしては、「東京タワーに→登りたいな」を得ることができる。
発話合成部では、上記で得た係り受けペアを元に、「東京に行ったら東京タワーに登りたいですか？」という文を生成する。
最後に発話選択部で、候補となる回答例を並び替え、最良の候補を選択する、という流れである。

係り受け抽出部

ここでは、ユーザーの発言に含まれる文節ペアの全てを入力係り受けペアの候補とする。ただし、特定の意味を持たない単語を候補としても係り受けの特徴を生かすことができないため、ストップワードと言われる意味がない単語は除外する。例えば、代名詞、「する、いう、なる、ある、いる」などの特定の意味を伴わない補助的な動詞、「こと、の」などの抽象名詞、「昨日、来年」などの時間に関連する名詞などをストップワードとしている。

合わせて、下記のような文節情報を同時に抽出する。

これは、具体例として「ようやく／朝ごはん／食べ始めた」という文節中の「食べ始めた」を利用したものである。

意味タイプのうち、評価表現は評価表現辞書中の有無に基づいて判定、それ以外は形態素解析器を用いる。

関連係り受けペア検索部

係り受けペアデータベース

係り受けペアデータベースを用いて入力係り受けペアに関連するペアを検索する。このデータベースは上記文節情報のいずれかをクエリとして、一致する文節情報を持つ係り受けペアを検索できるようにしたデータベースである。「お腹も→空いたし」というペア例を考えると、まず文のみが含まれたコーパスから重複分を除去し、各文に文IDを付与してID付与済みコーパスを構築する。これに含まれる文と文IDについて、係り受けペアと文節情報を抽出し、文IDと合わせてデータベースに保存する、という流れだ。ここでは文コーパスとしてTwitterが用いられる。

データベースから関連係り受けペアの検索

具体例を示す。例えば、「新宿で→食べた」という入力係り受けペアがあるとする。文コーパスには、「新宿で→食べた→ラーメンが→美味しかった」という例があった場合を考える。

すると、「新宿で→食べた」、「食べた→ラーメンが」、「ラーメンが→美味しかった」という関連係り受けペアの組が得られる。これらの入力係り受けペアと関連係り受けペアの組について、主辞が同一のものをまとめる。さらに、得られた関連係り受けペアの文節のうち、最も文節IDが大きい文節（出現した文中で最も文末に近いもの）が事態表現（品詞が動詞、形容詞、形容動詞、事態性名詞（「推薦」、「綺麗」などの行為や状態、出来事を表す名詞）のみを残し、「新宿で→食べた」、「食べた→ラーメンが」などの係り受けの組を除外する。これは、ボット側の反応を生成する際に、事態表現で終わる文の方が適切な文となりやすいからである。

発話合成部

検索された関連係り受けペアの元々含まれていた文での使い方をできるだけそのまま利用する形で回答例を生成する。各係り受けペアに含まれる文節表記を文節IDに基づいて文節が現れた順に接続し、得られた文字列は係り受けペア間での関係を適切に表現する助詞や、その文字列が出現する上で自然ととらえられる文法表現が補われた形になると考えられる。

次に、文末表現が回答例に利用しやすいように文末変換を行う。例えば、「～ですか？」という疑問文は「～ですね。」という平叙文にすることで自然な受け答えを目指す。ま高い「どんなのですか？」という質問を代わりに出力する。これは、「なんでこうもお腹がすくのかなぁ」というような自らの問いかけが多く、これに対して「なんでお腹がすくんですか？」というような質問が不自然な対話となるためである。

さらに、入力係り受けペアが固有名詞を含み、かつ検索された関連係り受けペアの数が少ない場合、上記方法での対話生成が難しくなるため、「（固有名詞）ってあまり知らないんですが、どういうのですか？」というテンプレートに当てはめて返答することとする。

発話選択部

上記で得られた回答例候補をコーパス中の出現数などに基づく数式に当てはめて妥当な発話を選択する。ここでは、関連性が強い話題であっても一般的な話題でなければユーザーが違和感を感じる可能性が高いため、そのような候補例を落とす、またスラングやタイプミスを除外するような施策を講じており、不適切な発言を抑制することを意図している。

実験1：一問一答

今回用いたのは、①雑談対話コーパス（1対1のテキストチャット形式を3680対話、約13万文取得）、②Twitterコーパス（1億5千万ツイート）の2種類。各コーパスからランダムに150文（明確に内容が記述されているもの）を選択し、計300文を抽出（実際は入力係り受けペアを抽出できなかった20文を除いて、280文）。下記5種類のアプローチを用いて結果を比較した。

①係り受けアプローチ

係り受けペアデータベースを構築するため、別に約10億ツイートを収集した。特に、Twitterのリツイートを表す「RT」が含まれる文、返信を示す「＠」で始まる文、URLが含まれる文、「【】」などのカッコを含む文、2文字以上の単語が3回以上含まれる文（「ねえねえねえ」など）、10文字以下の文を除外し、最終的に1億2千ツイートを得た。

②単語ベースアプローチ

係り受けアプローチと類似するが、係り受けペアではなく単語を話題の単位とすることで異なる。単語のみでは発言の内容を十分にとらえられない可能性があるものの、構造が単純なため理解が容易な文が生成されやすい。

③IR status

Twitterから、発言内容に近いツイートを検索し、対応付けられた返信ツイートを回答例として選択する仕組み。

④IR response

 IR statusに比べてユーザーの発言内容からかけ離れた内容が生成されにくいという利点があるが、単なる繰り返しと感じられる欠点がある。

⑤ルールベースアプローチ

ルールはAIML（Artificial Intelligence Markup Language）というマークアップ言語で記述されており、各ルールは入力文との一致を調べるパターンと、それに紐づいた出力文のペアからなる。ルール総数は149,300個で、入力文の先頭単語から合致するルールである先頭一致優先型検索を用いた。

実験結果1

まず、雑談コーパスを用いた場合の結果（1-bestのケース）である。

雑談コーパスはルールベースで用いたコーパスと同一であり、優位に他アプローチを上回る評価結果が出ている（Bold体は最大の評価値を表す）。

一方で、Twitterコーパスを用いた場合の結果（1-bestのケース）は下記の通りである。

こちらは、提案手法である係り受けアプローチの評価が高い。Twitterコーパスを用いた場合、ルールベースでは「天一食べた」というような単純な発言に対しては「おいしかったですか？」という定型回答を行うことで固有名詞のバリエーションの弱さを補ったが、複雑な構造の発言については先頭一致では適切なルールを発見することが難しく評価が低くなったと考えられる。

一方で、単語ベースのアプローチ手法も比較的評価が高い。これは、話題の明瞭性が高い文を入力文とした、例えば「秋刀魚が好きですね」というような単語のみで話題を表現可能な入力文が多かったためと想定される。したがって、「秋刀魚→食べたいです」という話題に合致した文を生成しやすくなる。また、単語の組み合わせのみで文を生成するためシンプルで理解しやすいという特徴がある。

提案手法である係り受けアプローチはというと、検索によって得られた関連係り受けペアが少ない場合には、ごく特定の文脈で出現する話題が多くなるため、評価が伸びなかったと思われる。また、発話選択部にて回答例をリランキングする仕組みが適切でなく、理解困難な文が選択されるというような場合があった。

ちなみに、IR statusとIR responseを比較すると、全ての指標においてIR responseが優れていた。これは、IR responseがオウム返し的な反応が多いものの発言に対する回答の矛盾が少ないという点が評価を受けているものと考えられる。

それぞれの回答例をまとめた表を示す。

提案手法である係り受けアプローチが良い例としては、「都会の中」という入力係り受けペアから「都会の中でも自然を感じられる」という、関連性の高い話題を含む回答を、適切な助動詞「でも」とともに生成していた。

IR responseが良い例としては、「テザリング」というあまり一般的ではない話題から「WiMAXがイチバン」という関連する話題を検索できていた。一方で係り受けアプローチでは「限界」を用いた回答が生成されており、「テザリング」という出現数の低いワードに対する関連係り受けペアを検索できなかった。ルールベースでは「テザリング」に対応したもののやや不自然な回答であり、単語が一致してもそれのみでは適切な応答文の生成は困難だと思われる。

実験2：対話システムへの組み込み

上記の対話システムに組み込んだ場合、どの手法が最も評価が高いかについて実験を行った。

詳細な説明は割愛するが、実験の設定としては以下の通りである。日本人28名（20代から60代男女）がテキストチャットによる対話を、実験1で用いたアプローチのうち、単語ベースを除く4パターンと2回ずつ、計8回実施した。

実験結果2

実験結果は以下の通りであった。全体的にルールベースでの対応が最も高い評価を得ており、特に文法の正しさ、1ターンの適切さにおいて優位な差を見せている。

ちなみに、IR status、IR responseについては、IR statusは対話への意欲と多様性以外の項目でIR responseより低い評価だった。文法や1ターンの適切さが低いことから理解困難な回答が多かったものと考えられる。しかし、多様性、意欲に関する項目ではIR responseを上回り、IR responseにおける話題の展開性の欠如がこの結果に影響していると思われる。

以上、係り受けを利用した雑談チャットボット実験例を紹介した。やはり現時点での対話システムにおいては完全な物はなく、着実に、適切な回答を行う仕組みを構築することになりそうだ。

参考：任意の話題を持つユーザ発話に対する係り受けと用例を利用した応答文の生成（人工知能学会論文誌2015）