質問応答
Analytical QA の課題の一つは、質問と答えの間にまったく共通する単語がないケースが多いことだと思われます。
例えば、「過去五年に起こった重大な事件について知りたい」というQueryがあるばあい、事件とはなんなのか？ 地震、津波、洪水、9/11やサリン事件のような攻撃、それとも、殺人や誘拐？ 日本国内の事件なのか、といったことが問題になってきます。
手前味噌ですが、HITIQAという質問応答のシステムにかかわったことがあります。
http://www.ils.albany.edu/paper.html
HITIQAシステムでは、「アルカイダは資金、武器などをどう調達しているのか？」などの質問の場合、大まかにTransferというFrameを持っているものと解析します。 売るのも、買うのも、寄付するのも、援助するのも、調達するのも、全てTransferです。 Transferされるものは、兵士であったり、武器であったり、お金や麻薬などです。
質問を解析した後は、 IRで見つけたドキュメントからもTransferのFrameを見つけて比べて見ることで、賢く会話や要約をしようとします。 parsingより、抽象度はかなり高くなります。 HITIQAでは、この、Transfer Frame という、抽象的な概念に質問と答えの両方を持っていくことで、QueryとAnswer間の言葉のギャップを塞いでいるわけです。 FrameにはEntity同士の関係を規定しているのですが、Semantic Role Labelingよりも更にアブストラクトで、まず、どちらが主語で、どちらが目的語なのか、などは関係なくて、Knowledgeとして何処から何処へ物の移動があったかが分かればいい、と言った感じです。 こうして質問と答えのギャップをontologyっぽいものとrelationの両方で塞いでいるわけです。 FrameNetなどでも、lingusticsの色が強くなると、頑張っているんですが、ちょっと fine-grain になる傾向があるような気がします。
さらに、Entity Detection & Tracking ですとか、Query basedClustering/Summarizationといった話が重要になってくると思うのですが、QAのシステムは伝統的にpipelineやコンポーネントが多すぎて、綺麗に統合された良いモデルを作るのが難しいのが課題の一つであると思います。 他の人が作ったコンポーネントはブラックボックス、一番単純なシステムを構成して繋げるだけで
一苦労という、結構泥臭いソフトウェア開発になってしまいがちで、そのせいで、いい研究がやりにくくなっている側面があります。
良いPrincipledな方法でQAシステムを作るには、まず、Query と Answer のギャップを埋め、結びつける核となる革新的な洞察が必要で、理想的にはその洞察をきちんとテストすることが大切です。
どの研究所でもフォーマルな形でこういうことは出来ていないと思うのですが、例えば、Query と Answer を結びつけるのは Case Frame と、IRでいうところの Vector Space Modelである、と、まずHypothesisを立てます。 これが核となる洞察です。 そうしたら、そこにあわせて、全てのコンポーネント、IR, Clustering, Summarization, Dialogue Componentのそれぞれを、Case Frame + Vector Space Model の全ての情報を使いきるよう設計、最適化して構築します。 トータルで見て、全てのコンポーネントがしっくりと繋がるような核が必要です。 それができたら、次に別の核を作ります、例えば核となるのはHITIQA Frame + Latent Sematic Indexingのほうが良い、ということもありえます。 ふたたび、HITIQA Frame + LSIの全てを使いきったIR, Clustering, Summarization, Dialogue Componentを作り、最適化します。
HITIQA Frameの良い所は、これを使って、図書館の司書の方と会話をするかのように、欲しい情報へとユーザをガイドできることです。 例えば、「日本について知りたいのですが？」「日本の歴史について知りたいのですか？」「それとも、日本の経済ですか？」などと、会話が出来るわけです。 その結果、要約した内容でユーザが欲しがった物だけを見せることができます。
もしかしたら、これはずるい方法ですが、核にする部分はQuery -> Answer ペアが大量にあるFAQの巨大なデータベースが良いのかもしれません。 企業のユーザ・サポートのQAシステムだと、そういったFAQがある可能性もあります。 AQUAINTで、あるグループの論文は、そのどおりにつくっても同じ性能をreplicateできず、そのグループは論文の内容も作ってはいるが、実際は、バックアップとして人海戦術で上の方法を取ったために性能が高くみえるだけではないか、と疑われています。
話がそれましたが、二つシステムがあって、ようやく意味のある比較が出来ます。きちんとした社会科学系のユーザ・スタディを実験の形で行い、ユーザが、どんな使い方のシナリオで、どんな質の情報を、どれぐらいの時間で得られ、どちらのシステムでどれぐらい満足したか、という統計をとります。 もしかしたら、シナリオによっては、Case Frameの方が Factoid QAに強く、HITIQA Frameの方がAnalytical QAに強いということが起こるかもしれません。 あるいは、エラー分析の結果、どこのコンポーネントからエラーが増えて、それを補うには何か別な情報がいる、という方向で改良が進むかもしれません。 それを何回か繰り返して改良して、はじめて良いQAの研究をした、と言えるのではないでしょうか。 そうでないと、Ad Hocにコンポーネントをつなげて、なにかけど一つシステムが出来た、で終わる可能性が高く、誰が見ても分かるsignificantな質の違いがある、というような結果は出せないのではないでしょうか。 Pipelineの、どこがまずいのかも分かりにくいし、ここまでやるには強力なプログラマーが何人か必要だし、研究ではない部分の実装や実験もかなり出てくると思います。
興味がないコンポーネントを仕様がかなり指定された段階で担当してしまうと、人によっては研究者として素質が良いがために逆に生産性が落ちるケースがでてきますし、ひとつの論文を十人で書くというのは、核となるアイディアに十人が振り回されるということで難しい面もあるかと思います。 ただ、その分、QAのような大きなシステムに携わるのは、やりがいもあると思います。
