「Fickle Creek Farmについて知りたい」と言われても、場所を知りたいのか、商品を購入できる場所を探しているのかは分かりません。対話AIが一つの意味を選んで回答すると、利用者が求めていない情報を返す可能性があります。

一方で、意味を一つに絞れる要求にまで毎回聞き返すAIも使いにくいものです。確認質問を扱うには、質問文を生成できるだけでなく、「この要求には確認が必要か」「候補のうち、どの質問が検索結果の改善に役立つか」も評価しなければなりません。

今回は、オープンドメイン検索の確認質問を扱うClariQから、聞き返す必要性、質問、利用者の回答をどのように一組のデータへしたのかを見ていきます。

本記事は公開論文と公開データを紹介するものです。株式会社イングクラウドが当該研究やデータセット制作に関与したことを示すものではありません。

「いつ聞くか」と「何を聞くか」を別の課題にした

ClariQは、2020年のConversational AI Challenge(ConvAI3)で実施された、対話型検索における確認質問のデータチャレンジです。

研究では、確認質問に関する問いを二つに分けています。

課題 システムが判断すること
いつ聞き返すか 利用者の要求だけで回答できるか、確認が必要か
何を聞くか 候補の中から、意図を絞り込むのに適した質問を選べるか

第1の課題では、利用者要求に対して確認の必要度を1~4で予測します。1は要求だけで内容を理解でき、確認が不要な状態です。4は非常に曖昧で、確認なしに正しい意図を推定することが難しい状態を表します。2と3はその中間です。

第2の課題では、確認が必要な要求に対し、収集済みの質問バンクから最も適切な質問を選びます。質問しないという判断も、専用の質問IDを選ぶ形で表現されています。

要求・確認質問・回答を一組にした

ClariQの基本単位は、次の三つです。

  1. 利用者の最初の要求
  2. システムが提示する確認質問
  3. 想定された情報要求に基づく利用者の回答

論文では、「What is Fickle Creek Farm?」という要求に対して、「Fickle Creek Farmの場所を知りたいですか」という確認質問が示されています。利用者が商品を購入できる場所を探している場合は、「いいえ、商品をどこで購入できるか知りたい」という回答になります。

ここで重要なのは、確認質問の文面だけを評価しないことです。一見自然な質問でも、利用者が求める側面を区別できなければ、検索結果の改善にはつながりません。ClariQでは、質問と回答を元の要求へ加えた後、関連文書の順位がどの程度改善するかによって質問の有用性を評価します。

検索意図を「ファセット」として先に用意した

ClariQは、2009~2012年のTREC Web Trackで使われた検索トピックと、そのトピックに含まれる複数の側面を基礎にしています。この側面は「ファセット」と呼ばれます。

例えば、同じ短い検索語でも、場所、購入方法、人物、歴史など、利用者が本当に探している情報は異なります。元の要求だけでは見えない目標をファセットとして保持し、そのファセットを想定した利用者回答を質問ごとに作ることで、質問後に意図がどこまで絞られたかを評価できます。

公式リポジトリによると、学習用187トピックと検証用50トピックがあり、その中には141件の多面的なトピック、57件の複数解釈を持つトピック、39件の単一トピックが含まれます。ファセットは891件、質問は3,929件、学習・検証用の単一ターン対話は11,489件です。

リポジトリ全体では、単一ターン対話が約1万8,000件、合成した複数ターン対話が約180万件と説明されています。論文とリポジトリでは集計対象やデータ更新時点が異なるため、質問数などに差があります。

基になったQulacは四段階で作られた

ClariQは、新しくクラウドソーシングしたデータに加え、先行するQulacを拡張して構築されています。Qulacでは、確認質問と回答を次の四段階で収集しました。

  1. TRECの検索トピックとファセットを選ぶ
  2. クラウドワーカーが候補となる確認質問を作る
  3. 専門アノテーターが質問の妥当性と重複を確認する
  4. 各トピック・ファセット・質問の組み合わせに対する回答を集める

質問作成者には、利用者から曖昧な検索語を受け取った対話エージェントになったつもりで質問を書くよう依頼しました。作業者は検索結果の最初の3ページや検索候補を確認し、考えられる側面を探したうえで、1トピックにつき6問を作成しました。

1件の作業には2人を割り当て、最初の収集では1トピックにつき12問を得ています。同じ人の言い回しへ偏らないよう、質問作成は1人最大2件までに制限されました。対象は米国在住で、Amazon Mechanical Turkの承認率が97%を超える作業者です。

専門アノテーターが重複と不足を確認した

集めた質問は、そのまま採用されていません。2人の専門アノテーターがトピックごとの質問を読み、無効な質問と重複した質問を判定しました。

さらに、各質問を対応するファセットへ割り当てました。質問への回答がそのファセットの情報要求を表現できる場合に、関連する質問と判断します。質問が存在しないファセットには、専門アノテーターが新しい質問を追加しました。

この工程により、文法的に成立しているかだけでなく、想定された情報要求を区別する質問になっているか、各ファセットを少なくとも一つの質問がカバーしているかを確認しています。

回答者には一つの質問だけを見せた

回答収集では、作業者へ元のトピックと想定するファセットを提示し、その情報を探している利用者として一つの確認質問へ答えるよう依頼しました。

同じファセットに対する複数の質問を一度に見せると、ほかの質問の文面が回答へ影響します。そのため、1回の作業で提示する確認質問は一つだけにしました。与えられたファセット情報だけでは答えられない質問には、「No answer」というラベルを付けます。

回答作業者は米国在住で、Mechanical Turkの承認率が95%以上という条件でした。言い回しの多様性を保つため、回答作業は1人最大100件に制限されています。

回答は作業者ごとに抜き取り検品した

回答収集中は、各作業者の提出物の10%を定期的に人手で確認しました。抜き取った回答に無効なものが見つかった場合は、その作業者の全提出物を調査しています。

無効な回答は削除し、別の作業者へ再割り当てしました。低品質な提出を検出する補助策として、入力欄のコピー&ペーストを無効にし、キーボード入力も記録しています。

質問の作成、専門家による質問確認、別作業者による回答、回答の抜き取り検品を分けることで、一人の判断だけで質問と正解回答が決まらない工程になっています。

確認質問の品質を検索結果の改善で測る

ClariQの自動評価では、選択した確認質問と、それに対応する利用者回答を元の要求へ追加し、文書検索をやり直します。その順位をMRR、Precision、nDCGなどの情報検索指標で測ります。

これにより、「自然に見える質問」を選ぶだけでなく、その質問が利用者の求める文書を上位へ移動させたかを評価できます。また、質問バンクの中から関連する確認質問を上位へ並べられたかも、Recallによって評価されます。

チャレンジの第2段階では、上位システムを実際の人と対話させました。評価者は会話の参加者としてシステムへ応答し、各回答や確認質問について、情報要求への関連性と、会話としての自然さを評価しています。

関連性と自然さを分けるのは、必要な側面を尋ねていても、質問を何度も小分けにすると不自然な対話になる場合があるためです。

ClariQが扱うのは検索意図の確認である

ClariQの対象は、オープンドメインの情報検索です。送金先、ファイル削除、医薬品、安全管理など、誤った実行による損害を考慮した確認判断は収録されていません。また、確認後に外部システムで処理を実行し、その成功や失敗まで記録するデータでもありません。

そのため、ClariQから直接学べるのは、短い検索要求に確認が必要かを段階評価する方法、複数の検索意図を区別する質問の作り方、質問後の検索改善を測る方法です。

業務指示や操作を扱う日本語データへ応用する場合は、ClariQの構造に加えて、誤解した場合の影響、操作の取り消し可否、参照できる会話履歴、確認回答を反映した最終処理などを別途設計する必要があります。これらはClariQに含まれるラベルではありません。

RESEARCH DATA SUPPORT

確認の必要性から回答後の処理まで扱う日本語対話データをご相談いただけます

株式会社イングクラウドでは、曖昧な利用者要求、確認必要度、候補となる確認質問、利用者回答、明確化された意図、回答後の処理を一組にした日本語対話データの制作を支援しています。研究上の問いを作業者への提示情報、質問・回答の収集手順、評価尺度、検品基準へ落とし込む段階からご相談いただけます。

学術研究・実証実験支援について相談する