雑談対話システム構築フレームワークPyChatに基づく特定シチュエーション向け対話システム

雑談対話システム構築フレームワーク

PyChat

に基づく

特定シチュエーション向け対話システム

A Chat Dialogue System for a Specific Situation

based on PyChat Framework

中島 圭祐

1∗

_{駒谷 和範}

1

_{中野 幹生}

2

Keisuke Nakashima

1

_{Kazunori Komatani}

1

_{Mikio Nakano}

2

1 _{大阪大学 産業科学研究所}

2 _{(株）ホンダ・リサーチ・インスティチュート・ジャパン}

1_{The Institute of Scientific and Industrial Research (ISIR), Osaka University} 2_{Honda Research Institute Japan Co., Ltd}

Abstract: This paper presents OHBot, a text-based chat dialogue system developed for the situation track in the second Dialogue System Live Competition. For developing a system that produces human-like utterance sequences, system developers need to manually adjust surface ex-pressions of system utterances through trial and error. It is crucial to enable such an adjustment easily, and thus a framework to support the adjustments is required. We construct OHBot on a framework for constructing chat dialogue system of specific domains, PyChat, by which we can easily edit system utterances and write the dialogue flow. We tried to improve human likeliness of the system by adjusting branching conditions based on language understanding results, which may be incorrect or missing in actual cases, and surface expressions of system utterances.

1

はじめに

第 2 回対話システムライブコンペティション [1] のシ チュエーショントラックにエントリーするために開発 した，雑談対話システム OHBot について述べる．この トラックは，ユーザとシステムが学生時代の友人関係 にあるという設定のもとで，一番印象に残った旅行や 場所に関する話題から雑談を始めるというものである． 評価基準は，「どれくらい（シチュエーションに適した） 人らしい会話か」である．したがって，この基準によ る評価が向上するようにシステムを開発した．OHBot の開発には，(株) ホンダ・リサーチ・インスティチュー ト・ジャパンで開発された特定ドメインの雑談対話シ ステム構築フレームワーク PyChat[2] を用いた． 本稿では開発にあたり検討した，「人らしさ」を向上 させるために必要となるデザインや，そのための戦略 について述べる．具体的には，ユーザ発話を理解してい ることをなるべくユーザに示すようにしたうえで，理 解できなかった場合にも対話が破綻しないようにした． また，今回は開発期間が限られていたため，その制約 の中で，優先的に実現した事項や，今回は見送った事 ∗_{連絡先： 大阪大学産業科学研究所}        〒 567-0047 大阪府茨木市美穂ケ丘８−１        E-mail: [email protected] 項についても触れる．

2

対話戦略の設計

シチュエーションタスクにおける対話のデザインと して，大きく以下の 4 つの方針を立てた． 1. 対話をいくつかのフェーズに分割する 2. 状態遷移ネットワークを用いた対話管理 [3] を行う 3. なるべくユーザに質問されないようにする 4. ユーザ発話が理解できなくても破綻しないような システム発話の表現を設計する これらについて順に説明する． まず対話がシステムからの質問ばかりになることや， 逆にシステムから一方的に話すだけになるのを避ける ために，対話全体をいくつかのフェーズに分けた．具 体的には OHBot では 3 つに分け，始めにユーザの話を 聞くフェーズ，次にシステムが話すフェーズ，最後にそ の両方が短く混ざったフェーズとすることで，対話が 一方的にならないようにした．またこれにより，フェー ズごとに開発を比較的独立に行えるようにした． 人工知能学会研究会資料 SIG-SLUD-B902-13

次に，人らしさを実現するには，対話の流れ，つま り文脈が重要である．このため，各ユーザ発話個々に 対して応答を考えるという一問一答型を基本とはせず， 状態遷移ネットワークを用いることで，文脈を管理す ることにした．このネットワークにおいて，ユーザ発話 の言語理解結果を分岐条件として状態を遷移させるこ とにより，ユーザの発話に応じた対話の実現を図った． ユーザが質問をした場合には，システムはそれに対 して応答する義務が生じるが，あらゆる質問に対して 適切に応答するのは極めて困難である．このことから， できるだけユーザに質問されないようにするという方 針を立てた．具体的には，システムのターンをできる だけ疑問文で終えることや，そうでない場合はユーザ が共感を示すにであろう発話を行うなどした． システムから質問をした場合，本来はそれに対する ユーザ応答を理解する必要があるが，これも常に理解 することは困難である．とりわけ，短期間でシステム を開発するには，この部分は後回しにせざるを得なかっ た．このため，ユーザの応答内容によらず対話が成立 するようなシステム発話をデザインするという方針を 立てた．

3

実装

3.1

全体像

OHBot は，PyChat の統計的言語理解と状態遷移ネッ トワーク対話管理を用いて開発した．統計言語理解の 訓練データと，ネットワーク対話管理のための知識，す なわち対話フローは手作業で構築した．バックエンド の知識ベースは，FoodChabtot[2] で用いたグラフデー タベースを拡張したものを用いている． OHBot に関して図 1 を用いて解説する．OHBot で のユーザ発話の入力に対して応答を行うまでの処理は 以下のようにまとめられる． 1. ユーザ発話に対する言語理解を行う 2. 言語理解結果を利用して次の状態を決定する 3. 決定した状態に基づきシステム発話を出力する 上記の処理は，PyChat の機能を用いている．OHBot 構築にあたっては，このシステムにおいて必要となる 各種知識を作成した．具体的には，対話フロー，グラ フデータベース，言語理解の訓練用例文などである．

3.2

雑談対話システム構築フレームワーク

PyChat

PyChat とはユーザの発話に対して言語理解を行い， その結果をもとにエキスパートと呼ばれる対話管理モ 図 1: OHBot の概略図 ジュールの一つを選択して応答を行う雑談対話システ ム構築のためのフレームワークである．PyChat では ネットワークエキスパートと応答エキスパートを利用 可能であるが，OHBot ではネットワークエキスパート のみを利用した．このネットワークエキスパートは，作 成したフローに沿って言語理解結果などに応じてシス テム発話を決定する． PyChat で対話システムを構築する際には以下の作 業が必要となる． 1. 言語理解のための発話行為タイプを定義 2. 言語理解モデルの訓練のための例文の作成 3. 辞書データの作成と辞書にアクセスするための関 数の実装 4. エキスパートで用いる対話知識の記述と対話知識 の中で用いられている関数の実装 5. 言語理解やエキスパート選択のパラメータの決定 言語理解のための発話行為タイプは，粗いタイプ su-pertype と細かいタイプ type に分けられ,susu-pertype は PyChat で定義されており，type は例文とともに定義 できる．詳細は 4 章で述べる．PyChat の言語理解で はユーザ発話のタイプ推定には bag-of-words を特徴量 とした LR(ロジスティック回帰) を，場所や時間などの クラスに則った名詞を取り出すスロット抽出には単語 や品詞の連鎖などを特徴量とし IOB2 タグを出力する CRF（Conditional Random Field）を利用している． OHBot では CRF により発話から「FOOD-DRINK」， 「TIME-EVENT」，「PLACE」という 3 クラスの名詞を 取り出す．抽出した名詞はスロット値として利用する． 言語理解モデルの訓練のための例文，辞書データと エキスパートで用いる対話知識は Excel ファイルで記 述が可能であり，編集が容易である． また，関数は Python のプログラムとして実装でき る．引数に言語理解結果のスロット値を利用する事が でき，辞書の参照を行う事も可能である．

図 2: 対話フローの記述例

状態 システム発話  ユーザ発話例  タイプ推定や関数による条件 遷移先の状態

1 first ところで，これまで 「去年行った not-empty(TIME-EVENT) Q-reason

行ったところで一番印象 福岡かな」 に残った場所ってどこ？

2 first 「首里城かな」 check-Okinawa(PLACE) Q-Okinawa

3 first 「小樽だよ」 check-Hokkaido(PLACE) Q-Hokkaido

4 first 「長崎かな」 not-empty(PLACE) Q-place

5 first Q-when

．．．

9 Q-reason ＜TIME-EVENT＞かあ。 Q-how

何しに行ったの？

10 Q-Okinawa 沖縄行ったんだ！ Q-how

海綺麗だし最高だよね!

いつ行ったの？ ．．．

31 T-Okinawa ユウコもゴーヤ好き？ 「うん」 superttype=acknowledge T-O-yes

32 T-Okinawa 「嫌い」 type=not-like T-O-not

図 3: グラフデータベースの一部

4

OHBot

開発のための知識記述

グラフデータベースの準備 PyChat では辞書およびドメイン知識を表現するために グラフデータベースを利用できる．グラフデータベース とは概念間の関係をグラフ構造で表現したデータベー スである．例えば図 3 のように，「きつねうどん」の「種 類」が「和食」であり「材料」が「うどん」であるこ とを表現できる．OHBot ではそれぞれスロット抽出で きる「FOOD-DRINK」，「TIME-EVENT」，「PLACE」 という 3 クラスの名詞について記述したグラフデータ ベースを使用している．FoodChatbot[2] に使用してい たものをベースにし，地名に関する情報を加えて拡張 を行った．使用したデータには全体で 38000 個以上の 単語と関係が含まれている． 言語理解モデルの訓練 PyChat では言語理解モデルの訓練に利用する例文を 図 4 のように表形式で記述できる．superttype は 19 ク ラスに分けられており，type は例文作成時に定義する ことができ，属する supertype も定義する必要がある． 図 4 の一つ目の例文のように文中にスロットタグを入 図 4: 言語理解モデルの訓練に用いた発話例 supertype type 発話例

refer refer-place ＜PLACE:福岡＞が

よかったよ

refer refer-place ＜PLACE:沖縄県＞かな

acknowledge yes そうだよ provide-info not-like 嫌いかな れることで，スロット抽出のモデルを訓練することが 可能である．さらに，スロット内の名詞句をデータベー スに存在する同じクラスの別の名詞句と置き換えるこ とで例文を増やすことができる．スロットのクラスは 3.2 節で述べた３クラスである． OHBot では図 4 のように例文を 432 文作成し，それ らを 20000 文に増やして訓練を行なった． 対話フローの記述 ここでの対話フローとは，ネットワークエキスパートで 用いる状態遷移ネットワークを指す．図 2 は OHBot の 対話フローに関する記述の一部である． 各状態にはそ の状態に至った時に出力されるシステム発話が設定で きる．また条件と遷移先の状態を設定することで．ユー ザ応答が条件を満たした時の遷移を記述できる．状態 first のシステム発話は「ところで，これまで行ったとこ ろで一番印象に残った場所ってどこ？」となる．ユーザ 応答が条件を満たしているかを上から順に確認し，満 たしていれば遷移先の状態に遷移する．ユーザ発話例は 条件部分を満たすような例文を記述できる．もし，ユー ザが状態 first のシステム発話に対して「首里城かな」 と回答した場合，次の遷移先は Q-Okinawa となる．条 件部分に記述している関数はスロット抽出で得られた place クラスの名詞句が沖縄の地名ならば真を返すとい うものである．沖縄の地名かどうかの判定にはグラフ データベースを参照する．もしユーザ発話が条件部分 に一致するものがない場合は，条件部に記述のない状

図 5: フローの一部を可視化した図

態が遷移先となる．図 2 の場合，遷移先は Q-when に なる．

31 行,32 行目の T-Okinawa の場合は，タイプ推定の 結果を条件としている．31 行目であればユーザ応答の supertype が acknowledge であれば T-O-yes に遷移す る．OHBot の対話フローの状態数は 92 である． 関数の実装 条件分岐で用いる関数をいくつか実装した．これらに ついては 5.2 節で述べる．

5

対話戦略に基づいたフローの構築

2 章で述べた対話戦略に基づき，具体的に対話を設計 し，図 2 に例を示した対話フローとして記述した．本章 ではまず対話フローの具体的な設計について述べ，続 いてシステム発話の調整について述べる． このような設計や調整には，かなりの試行錯誤が必要 であった．PyChat の仕様として，対話フローを Excel ファイルとして複数の開発者間で共有できるため，コ メントや編集が容易にでき有益であった．また対話の 状態遷移をチェックするのに，図 5 のように Graphviz を使って遷移が正しく記述されているかをチェックし た．これも開発時には有用であった．

5.1

対話の流れの具体的な設計

フェーズ構成 OHBot では、対話全体を大きく 3 つのフェーズに分け た．この中身は以下のように構成した． 最初のユーザの印象を聞くフェーズでは，ユーザの 印象に残っている地名について，いつ行ったのか，そ の感想，そこで食べたものを尋ねるようにした．なお この際に，既にユーザが言及した内容を再度尋ねない よう注意した．例えば「去年の夏に沖縄に行った」と 図 6: システムが話すフェーズの内容の変化 S1: ところで，これまで行ったところで一番 印象に残った場所ってどこ？ U1: 宮古島はよかったよ ... ... S6: そっか。そうそう、最近、北海道での スイーツ巡りにハマってるんだ♪ いうユーザ発話の後に，「いつ行ったの？」と尋ねるの は不適当である．これを防ぐために，ユーザ発話の言 語理解（スロット抽出）結果を保持し，それに応じた 状態分岐条件を記述した． システムが話すフェーズでは，システムが自分の旅 先での思い出を語るようにした．ここでは，ユーザの 興味を喚起するような内容となるように，一連のシス テム発話を作成した．また話が単調にならないように， 途中で簡単なクイズを入れた．この正解判定に関する 分岐も記述した． 最後の両方が混ざったフェーズではユーザと今後の 予定を話し合うようにした．ユーザの行きたい場所を 確認し，システム側が旅行を予定しているのでユーザ も一緒に行かないかと勧誘するような対話の構成とし た．全体を通して旅行についての話をすることで，話 題転換に対してユーザが違和感を感じないようにした． 印象に残った場所の重複を避ける システムが話すフェーズでは基本的にシステムは沖縄 に関する思い出や知識を語るが，最初のフェーズでユー ザが沖縄について語った場合には，それと重複しないよ うに，北海道についての思い出を語るようにした．ここ で，ユーザが沖縄について語ったかどうかを判定するた めには，ユーザの話した地名が沖縄かどうかを判定する 必要がある．このため，グラフデータベースの地名階層 を用いて，ある地名が沖縄の地名かどうかを調べる関数 を作成した．これは 4 章で述べた関数で，図 2 の 2,3 行 目の check-Okinawa(place) と check-Hokkaido(place) である． 図 6 はこの機能により，システムが話す内容が変化 した場合の例である．ユーザの入力が沖縄の地名では なかった場合には，システムは沖縄に関する思い出を 語る．これに対して，ここでは U1 に含まれる宮古島 が check-Okinawa(”宮古島”) により沖縄の地名である と同定できたため，システムが話すフェーズの内容と して，北海道の思い出を話すように変化している． 第一印象の強化 人間同士の関係で第一印象が重要とされるように第一 印象はシステムの評価においても同様に大きな影響を 与えると考えた．そのため最初の質問の答えに対する 分岐を OHBot の分岐の中で重点的に多く構成した．

図 7: 地名の理解を想起させる発話 S1: ところで，これまで行ったところで一番 印象に残った場所ってどこ？ U1: 石垣島かなー S2: 沖縄行ったんだ！海綺麗だし最高だよね！ いつ行ったの？ S1: ところで，これまで行ったところで一番 印象に残った場所ってどこ？ U1: 札幌かなー S2: 北海道行ったんだ！食べ物美味しいし最高 だよね！いつ行ったの？ 図 8: 依存しない発話の比較 (発話は一部省略) S1: 旅行とか一緒にどう？ U1: いいね．いつ行く？ S2: じゃあさ，今度一緒にご飯でも行かない？ S1: 旅行とか一緒にどう？ U1: 忙しいから無理かな S2: じゃあさ，今度一緒にご飯でも行かない？

5.2

システム発話表現の調整

ユーザ発話を理解したことを示す ユーザ発話内容をシステムの発話に加えることで良い 印象を与える [4] ことを利用して，ユーザの発話内容を 含んだ発話を中心に作成した．最初の発話にてスロッ ト抽出によって取り出した地名を組み込む発話に加え て，観光地として有名な場所の多い沖縄と北海道の固 有の地名が抽出された時に場所についてのみ遷移する 発話を実装した．これには先述した関数を利用した．図 7 は具体的な対話例である．このような発話を入れる ことでシステムがユーザの発話を理解しているような 印象を与えることを図った． ユーザの発話内容に依存しない応答 対話の流れを考えるうえでユーザの応答を予測するこ とは重要であるが，予想される発話を全て網羅するの は不可能である．そのため，設定したいずれの条件に も合致しなった場合の遷移先ではどのようなユーザ発 話であっても成立するような発話をすることでユーザ の不快感の低減を図った． 図 8 のシステムの最後の発話が依存しない応答の一 つである．図 8 の場合，相手が誘いに対して興味があっ た場合でも無い場合でも話の流れから逸脱していない ことがわかる． 相槌の導入 ユーザの発話に対して反応をせずに質問やシステムが 話をするだけではシステムがユーザの話を聞いていな いように捉えられる可能性がある．そこで質問の後の システム発話に相槌を加えた．具体的には「なるほど」 や「そうなんだ」のような相槌である．また相槌に同 じものを連続して使用することもユーザへの印象が悪 くなる可能性があったため，同じ相槌を連続して使わ 図 9: 対話ログの一部 S1: 旅行とか一緒にどう？ U1: うーん、春は仕事が忙しいしね。 さすがに有給はとれなさそうかな。 S2: じゃあさ，今度一緒にご飯でも行かない？ U2: そうだね、ランチしましょう。 パンケーキ食べたい。 ないようにした． 言語理解結果に依存しない発話 分岐の作成にあたり条件を記述するが，タイプ推定や スロット抽出に失敗してしまう場合が多くある．その ため分岐の条件を満たさない場合に遷移する状態の発 話ではどんな発話にでも対応できるように作成した． キャラクター性に合わせた発話 システムの設定を女性としたため，発話の内容や文調 が一貫するように注意した．この点については，開発 者のうちの女性がチェックし，付与したキャラクター性 から逸脱しないようにした．

6

評価結果・分析

6.1

予選結果

対話システムライブコンペティション２の予選では， 「どれくらい (シチュエーションに適した) 人らしい会 話か」という評価軸でクラウドワーカーにより 5 段階 で評価された．その結果，OHBot は 50 人の評価者の 平均点が 4.1 となり，予選に出場した 7 チームの中で 最もスコアが高い評価であった． 対話ログを確認したところ，図 9 のように誘いに対 して否定的な回答であっても自然な会話になっている 箇所がいくつかあった．これは，5 章で述べた「ユーザ の発話内容に依存しない応答」の設計がうまくいって いた例である．

6.2

予選ログ中の失敗例の分析

誤った遷移 タイプ推定が誤った場合のことを考え，遷移の条件を 満たさない発話に対しても可能な限り自然な対応がで きるよう，無条件遷移後の応答を設計した．しかし，タ イプ推定が誤ったがために，誤って遷移の条件をみた してしまい，ユーザの発話と関係ない応答をしてしま う場合が存在した（図 10）． 図 10 の最初のシステム発話 S1 に対して「信州って 何があるの？」といった内容の質問の場合に遷移し，条 件を満たさない場合は「友達の実家が旅館なんだけど 一緒に行かない？」といった発話で話の流れを少し変 える設計をしていた．しかし図 10 の場合，ユーザ発話

図 10: タイプ推定による失敗例 S1: 私ね，実は来年の春あたりに信州に行こうと 思ってるんだ U1: 信州もいいね，スキーとかスノボとかやるの？ S2: りんごのお菓子とか美味しいものがいっぱい あるよ♪友達の実家が... 図 11: 分岐不足による失敗例 ... (沖縄についてシステムが話すフェーズ) S1: ...行きたいところとかある？ U1: アイちゃんの話聞いてたら沖縄行きたくなって きたよー S2: ほほう！そのわけは？ を誤って「信州って何があるの？」と同じタイプの文 であるとみなしてしまったために，誤った遷移が行わ れ，関係のない応答をしてしまった． 分岐の不足 準備期間が足りなかったことから，条件分岐の記述は 必ずしも十分ではなかった．図 11 ははユーザが既に理 由を述べているのにユーザに理由を聞いてしまう例で ある．この例ではユーザが理由を行きたい場所と同時 に述べてしまう可能性とシステムの話を聞いて行きた くなる可能性を想定に入れていなかったために，必要 な遷移を用意していなかった．ユーザテストを繰り返 すことでこのような問題は少なくできると考えている．

7

おわりに

本稿では対話システムライブコンペティション２の シチュエーショントラック用のシステム OHBot につい て述べた．シチュエーションに合わせた対話戦略を有 限状態ネットワークに基づく対話管理と統計的言語理 解により実現することで，良い評価を得た． 今後の改善点として以下が考えられる． 一般ユーザの対話ログを用いた言語理解の向上 開発期間が短かったこともあり，チーム内や一部の人 に試してもらうなどのテストしか行えていない．その ため，言語理解の性能は依然不十分である．予選のよ うに多くのユーザに対話してもらったログのユーザ発 話にアノテーションを付与し，言語理解モデルの訓練 に用いれば，6.2 節で述べたような言語理解の誤りを減 らすことができると考えられる． グラフデータベースのさらなる利用 今回利用したグラフデータベース内のリレーションは 沖縄と北海道に関する地名の階層のみであった．他の 観光地の地名階層や，観光地とその土地の有名な食べ 物や土産の関係などを利用することで，ユーザが言及 した地名から話を広げることができる． 応答エキスパートの利用 今回ネットワークエキスパートのみを用いたが，PyChat には応答エキスパートも用意されている．応答エキス パートを併用することで，システム主導で対話をすす めながらも，ユーザからの質問に答えることもできる ようになる．しかしながら，ユーザが質問をしていな いのにタイプ推定を誤って質問だと判定してしまうと， 対話が破綻してしまうため，今回はなるべく質問され ないようにシステム発話を工夫した．言語理解の訓練 データが十分得られてタイプ推定の精度を高められれ ば応答エキスパートの利用を検討したい．

参考文献

[1] 東中竜一郎, 船越孝太郎, 稲葉通将, 角森唯子, 高橋 哲朗, 赤間怜奈, 宇佐美まゆみ, 川端良子, 水上雅博. 対話システムライブコンペティション 2. 人工知能 学会 言語・音声理解と対話処理研究会第 87 回 (第 10 回対話システムシンポジウム), 2019.

[2] Mikio Nakano and Kazunori Komatani. A frame-work for building closed-domain chat dialogue systems. Computing Research Repository, Vol.

arXiv:1910.13826, , 2019. [3] 杉山弘晃, 成松宏美, 水上雅博, 有本庸浩. 文脈に 沿った発話理解・生成を行うドメイン特化型雑談対 話システムの実験的検討. 人工知能学会 言語・音 声理解と対話処理研究会第 84 回 (第 9 回対話シス テムシンポジウム), 2018.

[4] Takahiro Kobori, Mikio Nakano, and Tomoaki Nakamura. Small talk improves user impressions of interview dialogue systems. In Proceedings of

the 17th Annual Meeting of the Special Interest Group on Discourse and Dialogue, pp. 370–380,