ウミガメのスープ自動回答AI

背景

　ウミガメのスープは、シチュエーションパズルの別名です。同名のタイトルのクイズが有名であることから、シチュエーションパズル全体を指して「ウミガメのスープ」と呼ばれることが一般的です。シチュエーションパズルの定義を以下に示します。

シチュエーションパズルは通常何人かのグループで遊ぶ。一人が問題を出し、他の人はイエス（はい、肯定）・ノー（いいえ、否定）で答えられる質問を出す(場合によっては「関係ありません」などのイエス・ノー以外の答もあり得る)。質問者は、出題者が考えているストーリー、あるいは物を推測して語る。それがすべての謎を説明できたとき、このパズルは解けたことになる。　― Wikipedia

ウミガメのスープをWeb上で遊べるサービスが公開されています。例えば以下リンクのCindyがあります。

課題提起

　ウミガメのスープを遊ぶ場合、正解を知っている者が質問に答えなければなりません。つまり、最低でも質問する人1人、回答する人1人の2名が必要ということになります。また、一度解かれた問題を繰り返し遊ぼうとすると、回答する人(多くの場合、出題者)の負担が大きくなってしまいます。

先行手法の比較

　先行手法は大別すると3種類あります。

コミュニティ型ウミガメのスープを出題したい人、ウミガメのスープに参加したい人が集まるコミュニティ上で出題を行います。出題者が参加者からの質問に答えます。
質問提示型問題文、質問例を出題側が提示し、参加者は問題文と質問例に基づいて推理します。
有限質問型質問のバリエーションを出題者が提示します。その中から、参加者が推理に基づいて重要そうな質問を選んでいくことで、正解にたどり着きます。

　各手法のメリットとデメリットを整理すると以下のようになります。

提案手法

概要

　ウミガメのスープ出題の新しい手法として、「自動回答型」を提案します。

　Deep Learningの一種であるSentence BERTとCross Encoderを組み合わせることで、自動回答の機能を実現します。出題者が用意するものは、問題文と正解の文のみです。

要求機能

問答機能質問に対して、はい/いいえ/どちらともいえませんを判定して応答する必要があります。
正解判定機能推理したシチュエーションが想定した解答と一致する場合に、正解したことを応答する必要があります。

実現方法

　問答判定機能について、Cross Encoderを用いて質問文と正解についての含意関係認識のタスクを行います。　rinna/japanese-roberta-baseモデルをJSNLIデータセットでファインチューニングしたものを使います。

　正解判定機能について、Sentence BERTを用いて質問文と正解をそれぞれベクトル化し、Cosine Similarityが閾値を超えた場合に正解と判定します。　sbert-base-jaモデルを、同じくJSNLIデータセットでファインチューニングしたものを使います。

実証実験

概要

　作成した機能の妥当性(モデルが目的通りの出力をできていること)と有効性(利用者から見て自動回答できていると感じられること)を検証します。また、Webサービスとして運用するのに必要なクラウドリソースを検証します。

　学習済みモデルをGoogle CloudのCloud Functionsにデプロイし、API化しました。ただし、今回は検証用のため、データベースは使っていません。正解の文をCloud Functionsにハードコーディングしました。フロントエンドはVueで作成してNetlifyにデプロイしました。

　また、問題への参加者はウミガメのスープ出題サイトCindyで募りました。

結果

　参加者数：10名

　正解にたどり着いた人数：2名

考察：機能の有効性と妥当性

　質問と判定結果の情報は定量評価するには少なかったため定性評価のみ行います。

うまくいった例　正解にたどり着けた例が2例ありました。AIとのやり取りのみから、自分が正解したことを認識できているため、正解判定機能が有効に機能したと考えられます。
問答機能の解答が誤っている問題　ファインチューニングに用いたJSNLIデータセットは、2文間の関係についてentailment(含意), contradiction(矛盾), neutral(どちらでもない)というラベル付けを行っています。　提案手法ではentailmentを「はい」、contradictionを「いいえ」、neutralを「どちらともいえません」と読み替えましたが、実際のウミガメのスープ出題時の問答を元にデータセットを作ることで精度が向上する可能性があります。
基礎質問に答えられない問題　基礎質問とは問題のメタ情報を知るために使われる汎用的な質問のことで、「非現実要素があるか」「現代でも成り立つか」などがあります。　今回の手法では、正解の文と質問文の組をCross Encoderの入力としているため、正解の文に含まれないメタ情報に対する質問には正しく答えられなかったと考えられます。
正解判定機能のFalse PositiveとFalse Negativeの問題　False Positiveは、不正解な質問を正解と判断してしまう誤り、False Negativeは、正解している質問を不正解と判断してしまう誤りです。両者はトレードオフの関係にあります。　今回は、False Positiveが数例見受けられました。False Negativeはありませんでしたが、サンプル数が十分でないためFalse Positiveが有意に多いとは言えなそうです。　実際の利用シーンを考えると、明らかな不正解を正解と判定してしまうことよりは、正解しているのに不正解となってしまうことの方が困ると考えられるため、False Positiveを減らすように調整することが有効であると考えられます。

考察：クラウドリソース

2GB RAMではメモリあふれが発生したため、4GB RAMに変更したところ、安定稼働しました。
Cloud Functionsのコールドスタート時はインスタンス起動に時間がかかります。Cloud RunのメトリクスによるとContainer startup latencyの値は30～40秒程度でした。Request latencyは～1秒程度と、一度起動してしまえばレスポンスに問題はなさそうです。
学習済みモデルはpickleしてCloud Storageに置きました。問答と正解判定でそれぞれ423.4MB×2のストレージが必要でした。

結論

　自動回答型のウミガメのスープ出題方法を提案しました。　今後の課題として、提案手法の妥当性・有効性の定量評価、正解判定用モデルのファインチューニングに使うデータセットの改良、Cross Encoderのインプット文の工夫、False Positive/False Negativeの調整が挙げられます。　今後の展望として、コミュニティ型のウミガメのスープ出題サービスで一度出題された問題が、出題者がいなくてもいつでも遊べるようになることが挙げられます。

前へ多は小を兼ねる次へメンバー

最終更新 2 年前

種類

メリット

デメリット