Resource Analysis for Question Answering

  • publish: Proceedings of the ACL 2004
  • authors: Lucian Vlad Lita, Warren A. Hunt, Eric Nyberg

なにこれ

質問応答システムを構築するとき，様々なリソースを知識源とする． この論文では，それらのリソースの比較を行っている． 質問応答初心者なので，どのリソースがどういう特徴を持っているか・またどのタイプの質問に対して有効かをよく知らなかったので読みました．

Gazatteer

Gazetteer(地名集)．

「X(地名)の人口は?」，「Yの首都は?」と言った調子のファクトイド型の質問を扱うデータベース． CIA World Factbookは世界中の国々の地理的，政治的，経済的な特徴を収録している．

天文学に関する情報を収録しているAstronomyやアメリカの50州の情報を収録した50Statesなんかもある．

Gazatteerは常にデータを最新に保っているので，ある時点でのデータは別の時点のデータとは別物である可能性がある(=再現性のない実験結果が得られる可能性がある)． また，「太陽との距離は?」といった質問のように，時期によって解答が異なる質問も時期によって異なる解答が得られる．

Gazatteerの特徴として，非常に精度の高い情報が収録されているという特徴がある(そのかわり再現率はあまり高くならない)． TREC(質問文と解答文のデータセット)の質問のうち，Gazatteerの情報をそのまま利用できるタイプの問題に対しては非常に高い正解率を誇る．

WordNet

WordNetは概念辞書と呼ばれるもので，単語に関する説明を収録している．プリンストン大学で開発された． Web上インターフェースが公開されているので，試しに使ってみると良い． 日本版はないのって話だが，ある．こちらはNICT(国立研究開発法人情報通信研究機構)が提供している．

概念を整理し記述する，オントロジー．

Structured Data Sources

百科事典や辞書，その他のWeb上の資料は主に「Xって何?」，「Xって誰?」と言った定義を問うタイプの質問の解答を得るために用いられる． TRECで最も良い成績を収めたXuら(2003)のDefinitional System(日本語でなんて言えば良いんだろう?)では，WordNet(Miller et al., 1990))，the Marriam-Webstar dictionary，the Columbia Encyclopedia，Wikipedia，biography dictionary，そしてGoogle(これ資料って言うのか?)などの構造化・半構造化されたリソースを用いていた．

質問文からのN-gramをwikipediaやgoogleで検索するだけでもそこそこ解答が見つかることも多い(TRECの質問文での議論が論文中にあるので興味があったら読んでみてください)．

Answer Type Coverage

自分の構築したシステムがどれくらい広範な質問に対応しているのかをテストしたいときには，JAVELINシステム(Nyberg et al., 2003)を使うと良い． 「viscosityって何?」とか「Lacanって誰?」とか「クレオパトラはどのように死んだ?」といった広範な知識を問う問題が収録されている．

Answer Typeは以下のように区分される．

  • object
  • lexicon
  • definition
  • person-bio
  • process
  • temporal
  • numeric
  • location
  • proper

The Web as a Resource

Webはローカルに構築したコーパスよりも極めて巨大なので(web is orders of magnitude larger than local coporaってどういう意味だろう．．．)，簡単な質問とそれに対する解答はより頻繁に出現する． そのため，正しい解答を得るためにとても有用である．

Web上のリソースはパターン獲得や文書文書検索，構造化データの抽出，そして解答の検証のために使われることが多い．

Web Documents

ローカルに構築したコーパスを探索するかわりに，Web上の資料を探索して解答を見つけることを試みる質問応答システムも存在する(Xu et al., 2003::たぶんStructured Data Sourceの章で言及した研究)．

検索エンジンに対して質問文をtokenizeしたものをそのまま投げつける実験してみたら結構精度よかったみたいなことがその後に書かれています(google apiの話していたので読み飛ばした)．

Web Based Query Expansion

擬似適合フィードバックとかみたいな，クエリを拡張する手法もあるよーって話をしている．

まとめ

QAに使えそうなリソースを紹介してもらいました． 手法自体は当時からかなり色々変わっているけれど，データの重要性は変わっていないと思うので，調べてみる価値はあったと思っている．

次に読むべきかもしれない論文

Question Answering with Subgraph Embeddings

  • conference: EMNLP2014
  • author: Antoine Bordes, Sumit Chopra, Jason Weston

どんなもの?

　Facebook AI研の方々の研究．

オープンドメイン質問応答システム．分散表現を使う．

先行研究と比べてどこがすごい?

　質問応答システムは，KBに対してはスケーラビリティが高い一方で語彙や文法に関する知識やKBのスキーマなどに関しては熟練の技術者が注意深く設計しなくてはならなかった．

Faderら(2013)はほとんど人手のアノテーションを必要としないシステムを作ったが，このモデルはBordesら(2014)の分散表現を用いたモデルに負けた．

しかし，このモデルも十分な汎用性を持っているとは言えない．

　そこで，この手法ではBordesらのモデルを改良する．

  • より洗練された推論手続き
  • 解答の符号化がよりリッチになった(よく分からなかった)

　Barent，Liang(2014)のstate-of-the-artなモデルと同等のベンチマーク結果を出した(語彙に関する知識やその他の情報を用いていないにもかかわらず！)．

技術や手法のキモはどこ?

　質問文とEntity(KBの中身?)とFREEBASEのrelation types(FREEBASEは知識をグラフの形で保持しているので，relation typeはエッジの属性に相当するのかなと思う)に出現する単語のembeddingsを学習する．

　質問文を$$q$$，解答を$$a$$として，スコア関数$$S(q, a) = f(q)T g(a)$$と定義する．

質問文と解答文が正しい組み合わせであればスコア関数が大きくなるんだと思う．

$$f()$$は質問文をEmbedding空間にマッピングする関数で，$$g()$$は解答をマッピングする関数．

$$f(q) = \bf{W}\phi(q$$，$$g(a) = \bf{W}\psi(a)$$であり，重み行列である$$\bf{W}$$を最適化する．

$$\phi$$と$$\psi$$は文章をバイナリエンコーディングする関数だと思う．

どうやって有効だと検証した?

　WebQuestionを用いてベンチマークテストを行った．

ベースラインと同等くらいの正解率(40%くらいだけど)．

語彙とか文法とかの情報なしで同等の精度を出せるのは結構すごいと思った．

MLNとかと比較してどうなんだろう(そういえばMLNもEMNLP2014だったっけ)．

次に読むべき論文は?

zatsu

  • 自然言語を解釈するのがそもそも難しくて，そのせいもあって質問応答は難しい
  • 質問応答のstate-of-the-artは二つのアプローチがある
    • information retrieval base
      • KBへのアクセス重視
    • semantic parsing base
      • KBに投げるクエリ重視

筑波大学の科目を検索するやつ「きりのは」を作った

つくった

桐の葉

毎年この時期になると科目検索アプリを作る病気にかかっているまつのきです（去年作ったのはこちら）

github.com

というわけで，今年も作りました．今年は「桐の葉」という名前のアプリです．

github.com

このアプリは大学が作成したものではなく，私が個人的に作成した非公式のアプリです．

科目の詳細画面にツイートボタンを設置しておきました． 友達と「この授業とろうぜ！」というノリで科目情報を共有していただけたら嬉しいです．

筑波大学では，科目を検索する手段として，

  • Twinsの科目検索機能
  • KDB

の２つが利用可能です． KDBの出現により，我々学生は格段に科目を検索しやすくなりました．

もう少し柔軟にクエリを書きたいなぁと思うことが何度かあり，ちょうど新年度だったので作ってみました．

例えば，「数学」に関する科目で，3単位以上，3A棟で開講されている講義を検索したいとすると，桐の葉の検索フォームに

title: 数学 credits >= 3 location: 3A

と入力して検索をすることができます．

ちなみに，検索フィールドは

  • code (文字)
  • title (文字)
  • credits (数値)
  • terms (文字(スペース区切り))
  • instructors (文字(スペース区切り))
  • daytimes (文字(スペース区切り))
  • info (文字)
  • grades (文字(スペース区切り)(本当は数値の配列にしたい))
  • location (文字)

があります． 全文検索エンジン(Apache SolrとかElasticsearchとか)にデータを格納することを念頭にテーブルを作ったので，RDB的にはダメなフィールドが幾つか存在します．

全文検索エンジンを使いたいんですが，お金がないのでいつかやりたいです．今はHerokuの無料枠で頑張ってます．無料枠なので負荷に耐えられないかもしれません．優しくしてください．

また，大学院科目はデータベースに登録していませんので検索されません． Herokuの無料枠ではデータベースに登録できるレコードは10000万件までで，大学院科目を含めると科目データが18000件ほどになるので諦めました．誰かが僕に月に900円くれれば大学院科目も検索できるようになります．

すこしだけ実装の話もしましょう．

今回は全文検索を実現するにあたり，以下のRubygemを用いました．

github.com

特別なことはほぼ必要なく，モデルファイルに「このフィールドを全文検索の検索対象にする」ことを記述してやれば（see: kirinoha/subject.rb at master · himkt/kirinoha · GitHub）全文検索が可能になる，驚愕の一品です．

本当に気軽でとても良いのですが，問題もあります．

  • 検索結果のリランキングができない（多分
  • パフォーマンスが良くない（多分

Apache SolrやElasticsearchでは，特定の検索語やフィールドに対して重みをつけて検索結果をスコアリングし，ランク順で出力することが可能ですが，このsearch_copではそれは不可能です（当たり前だ

また，すべての検索リクエストはRDBに対して行なわれているので，ちゃんとした全文検索エンジンを使ったシステムよりもパフォーマンスは悪いはず？（データが高々10000件なのでそこそこの速度で検索できてるけど

以上，科目検索システム桐の葉の紹介でした． ちゃんとお金をかけて作り直したい気もしますが，大貧民学生にはちょっとしんどい．石油当てたら作り直します．

何か分からない点（たくさんありそう）がありましたら， 松之木 (@himkt) | Twitter までお気軽にお問い合わせください． プルリクエスト待ってます．．．（チラ github.com