機械学習による自動応答の今　外部知識に基づく応答生成に関するサーベイ結果 Part2

QA分野とConversation分野における研究紹介

坂田大直氏：ここからは、大日方さんに代わりまして、坂田が発表させていただきます。

今日は時間の都合上、サーベイを行ったすべての論文をご紹介することはできないのですが、今回紹介できなかった分はどこかに上げておきますので、のちのちconnpassにリンクを載せてもらいます。

また、スライドがまだできていないものもありまして、それはGitHubに一緒にまとめています。これらのスライドにできていない分に関しても、随時スライドにして追加していこうと考えております。

今回ご紹介するのは、QA分野で4本、Conversation分野で6本です。

これは実際論文を読みたいという方がいらっしゃったときに参考にしていただこうと思って載せました。

それでは、まずはQA分野から始めます。まずはCNNとFreebaseと使った質問応答システムの研究をご紹介します。

MCCNNは、3チャネルのCNNによって、3つの観点から質問文をEmbeddingします。

語と語の関係性に着目したAnswer Path、応答の種類を表すAnswer Type、質問の文脈を表すAnswer Contextの3種類が使われています。

下の表は、それぞれの観点から類似している質問の一覧です。字が小さくて見えないかもしれませんが。

例えば、一番左の「語と語の関係性」の中の2つ目の「所有」というところですが、ここには「who own skywest」「who start mary kay」、これは会社名ですが「who be the owner of」みたいな感じで、「who」のところに当てはまる語が動詞のあとの目的語を所有しているという関係性になっていて、これはFreebase内のリレーションに相当するようなものになります。

こちらがアーキテクチャです。

例えばこの質問の例として、「When did Avatar release in UK?（『アバター』はイギリスでいつ公開されましたか？）」というような質問があります。この質問は、左のほうの下のほうにいっぱい矢印が出てくるところに一つひとつの単語があるのですが、この中でまずはエンティティを抽出します。

エンティティとは何かというと、Freebaseの中のエントリーというか、Freebaseの中のノードになっているようなものです。それを抽出して、今回の質問の中のエンティティはAvatarですけど、そのAvatarが、右の図の赤い斜線になっている四角のところ、青い円の左側にあるようなところにあります。

ここから求めたい答えは、いつ『アバター』がイギリスで公開されたかということなので、Avatarからいつなのか、release_dateのリレーションをたどって、そののちに、イギリスなのでイギリスの場所を表すリレーションをたどって、最終的に解答に到達する。これがAnswer Pathということになります。

Answer Contextとして、そのAvatarの周辺のリレーションやエンティティを、これをコンテキストとしてEmbeddingしています。また、日付を聞いているので、それぞれのノードにある、今回はwhenと聞いているので、date属性を持っているようなエンティティを解答として抽出してきます。

Hybrid QA

次が、FreebaseやDBPediaの構造化データとWikipediaなどの非構造化データを組み合わせた質問応答システムの研究です。

まず、図のように、質問をtripletの形で表わせる細かい質問に分割します。

この質問例は「who is the front man of the band that wrote Coffee & TV」となっていますが、「『Coffee & TV』を書いたバンドのボーカルは誰ですか？」という質問を細かく分割していきまして、最終的にはボーカルの名前を答えてほしいわけです。それを、<ans, is the front man of, var1> <var1, is a, band> <var1, wrote, Coffee & TV> のように、3つのtripletに分割します。

それぞれのtripletに関して、例えば一番下の「なにか変数があって、それがCoffee & TVを書きました（<var1, wrote, Coffee & TV>）」というtripletを見たときに、これに関して3つの処理を行います。

1つ目がEntity Linkingといって、字面が同じだけれども意味が違うというようなエンティティを、実際何なのかを判定するものです。例えば、この『Coffee & TV』というのは番組名としてもあるものなので、これが曲名であることを判定します。

真ん中の図になるのですが、これは、wroteという「書く」というものが、DBPedia内でどういうリレーションに相当するのかというようなものです。それがDBPedia内のassociatedBandに質問文中のwroteが対応しています。

また、質問の中の「is the front man of」というフレーズをWikipediaの自然文の中から検索して、その解答の根拠とするのですが、これに関してはまったく同じ表現でなくても対応できるように別のデータベースを使ってパラフレーズ化しています。

Evidence Aggregation

次が、自然文を外部データとして保持し、各パッセージを質問に対する根拠にしようというアプローチになっています。

質問文を用いて検索を行い、その質問への解答を予測します。みなさんもGoogleで検索を行ったときに、上から見て複数の同じような解答が得られればそれが答えだと思うかと思いますし、より多くの観点から説明されているページがあれば、それを求めていた解答だとみなすのではないかと思います。直感的にはそういったことを実現しているものです。

もう少し流れを詳しく見ていきたいと思います。

まず、質問文を使って関連するパッセージの検索を行います。そして、得られたN個のパッセージから解答に相当する範囲を予測するモデルで、上位K個の解答候補を抽出します。その後、2つの手法を使って解答候補のre-rankingを行います。

この1つ目の手法が、解答候補がどれだけ出現するのかをカウント、もしくは確率値を考慮するものです。もう1つは、解答候補をすべて結合させて、その中で質問文の質問に対する解答のどれぐらいカバーできているのかを考慮するものです。

このパイプラインは、検索と機械読解と、あとは複数文の情報の統合という3つのコンポーネントに分かれていますので、それぞれが置き換え可能になっています。

この手法では、まず最初に検索結果に正解が含まれているかどうかが最終的な正答率の上限になっていまして、この論文の中では、最初の検索結果の中に正解が含まれている割合と最終的なスコアは10パーセントほど差があるので、まだまだのちのちのコンポーネントの改善の余地がありますが、もしそこが一致してくると、検索から改善をする必要が出てきます。

次は、常識を考慮しなければ解けないような質問を集めたデータセットの提案です。こちらはNAACL 2019のBest Resource Paperに採択されています。1万2,247個のQAデータで、1つの質問に対して5つの解答候補から正解を当てるタスクになっています。

CommonsenseQA

人間によるaccuracyが88.9パーセントであるのに対して、BERT-Largeでのaccuracyが55.9パーセントということで、やはり既存のモデルでは難しいタスクになっています。

問題の作成フローにはかなり気を使っています。

まずConceptNetというようなKnowledge Graphからエンティティをストックしまして、そのエンティティと、あとは、1つリレーションを選んできて、その質問文の中の……1つのエンティティリレーションまで共通して、もう1つリレーションを当てはまるものを当てはめた、この3つのtripletを使って質問を作成します。1つ目のエンティティが質問文の中に含まれるようにして、2つ目のエンティティのこの3つの中の1つだけが答えになるようにします。

例えば、「tera located in tokyo」とか「tera located in kyoto」「tera located in nara」みたいな感じになったときに、teraを使って、例えばnaraだけが解答になるような質問を作ってください、みたいな感じですね。

そして、そのあと別のCrowdworkerに、1つ目のエンティティと2つ目のリレーション……質問の選択肢に使ったのと同じような条件のtripletから、別の選択肢を1つ足してもらいます。また、もう1つ任意な選択肢を足してもらって、合計5つの選択肢を作成します。

それで、さらに質問が簡単・難解になりすぎていないかどうかをダブルチェックするなど、かなり良い問題を作ろうというような気を使われているフローになっています。

Conversationの研究紹介

ここからがConversationタスクになります。

Persona-chatは前半でも出てきましたが、個人が一貫していないということで、「国はイギリス出身だけど、街はパリ出身だとか、そういうものはおかしいよね」ということに取り組んだものです。

Wizard of Wikipediaは、Crowdworkerを2種類の人に分けていまして、1人目のWizardというものにWikipediaのパッセージが与えられています。もう1人のApprenticeというのは、なにも知らない状態でWizardに質問をしていくと。WizardはそのWikipediaのパッセージを根拠としながら質問に答えていくという、こういった対応の中から収集したデータセットです。

ベースラインモデルとして、Transformerを使ったモデルを提案しています

こちらは、「I don’t know」みたいなつまらない発話をボットがしてしまうという問題に取り組んだものです。

この研究は評価は人で行っていまして、例えば「情報量」や「適切さ」という2つの観点から評価を行っています。

この赤のほうが提案モデルで、Seq2Seqと比べて、この下の4/7や5/7というのは、7人中何人が提案モデルのほうを良いと言ったか、というものになっています。

こちらは、先ほどのCommonsenseQAのところで出てきましたけれども、ConceptNetを使った対話の生成モデルです。

このように、例えば「Why are you so breakable?（あなたはなぜ怒りっぽいのですか？）」と言われたときに、Seq2SeqだとOut-of-Vocabulary（OOV）が出てきてしまっています。MemNetでも出てきてしまっていますね。

CopyNetは自動要約の文脈で出てくるCopyNetを応用したもので、これではOOVは出ていませんが、ぜんぜん意味が通っていません。「違う。私はただ見ていただけだよ」というぜんぜん関係ないことを言ってしまっているんですが、提案モデルは「なぜなら私は怒りっぽいからだ」とちゃんと答えていますよ、というようなものになっています。

こちらは、今まで外部知識から知識を選択するときに入力文に Attentionをかけるなどして、応答文に関してまったく考慮していなかったのですが、この応答文を、「どういう応答文があるのかを考慮しつつ知識を選ばないといけないのではないか？」というモチベーションの中で生まれたものです。

下の黄色のほうにありますが、これは応答文を考慮した上でどう知識を選ぶのかという事後確率分布があって、上が入力文だけを考慮した事前確率分布です。KL divergenceを使ってこれを近づけていくことで学習しています。

最後に、このAliMe Chatは実運用まで考慮したところが大事なところです。

既存の応答文とそれと生成モデルを使った2種類の組み合わせなんですが、本来の実験の中で出てきた「これぐらいで組み合わせたらいい」というようなしきい値よりも、実は既存の応答文を利用するほうに重きを置いているというか、実運用においてはニューラルネットを使った文は破綻しやすいので、既存の文をちょっと多めに使うよということも書いてありました。

まとめです。

モデルの評価がなかなか難しくて人手でいろいろ行っていることがあります。

Knowledge Baseは……ACLでもKnowledge GraphとかCommonsenseといったワードが増えてきたりしていまして、自然言語処理の未来のためにKnowledge Baseを使ったものをこれからみんなでやっていきましょう、というようなことで発表を終わらせていただきます。

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

（会場拍手）