Posts Tagged ‘クエリ拡張’

(論文メモ) Query Weighting for Ranking Model Adaptation / ACL-HLT 2011

月曜日, 6月 27th, 2011

ACL-HLT 2011から面白そうな論文4件目。


出典情報: P11-1012: Peng Cai; Wei Gao; Aoying Zhou; Kam-Fai Wong, Query Weighting for Ranking Model Adaptation, ACL-HLT 2011

Joint Annotation of Search Queriesと同様、ドキュメント検索時にクエリに対して適切なドキュメントを紐付けしようという話らしい。Joint Annotation との違いは、クエリをアノテーションすることで意図を解釈しやすくしようというのではなく、直接クエリを特徴ベクトルとして表現した上で、「既に別の問題領域で学習済みの知識」を活用することで重み調整することで高精度で紐付けましょうという点。

前置き

ランキングアルゴリズム

ある検索要求(ここではクエリ)に対して適切だと思われるコンテンツ(ここではドキュメント)を提示するため、その適切さを何らかの形で点数化し、順位付けるためのアルゴリズムの総称。有名どころはご存知PageRank。ただし、Blog、SNS、Twitter等のユニークなURL付きコンテンツの増加といった環境変化の影響も少なくなく、常に改善が試みられており、今回の論文はその一例です。

特定ランキングアルゴリズムに特化することの問題

検索って便利ですよね。でも何事にも良い面悪い面があるものです。例えば、Coding Horror: Googleに問題アリではスパムサイトを例に問題点を指摘しています。

他にも、例えばGoogleがデファクトスタンダードになってしまうと、事実上Googleの恣意的な考えに基づいてランキングされてしまう一種の検閲に近い状況になってしまうことを問題視している人も少なくないようです。

ここで気に留めて欲しいことは、Googleのランキング手法に問題があるという点ではなく、どのような手法であれ(人手による判断であっても)何らかの作用を受けたランキングになってしまうということです。なので、なるべく「何らかの作用」ができるだけ分かりやすい形で明示されており、作用の種類が自由に選べるぐらい豊富にあるような世界が好ましいだろうと考えています。

(Twitterでもfavotterとかが一つのランキングを実現していますが、今のままで面白いという人もいれば、Twitterが広まり過ぎて上位に来るツイートが有名所ばかりになってつまらないという人もいるでしょう。どちらが良いというよりは、どちらも、それ以外にもあった方が楽しみやすそうですよね)

クエリに適切なドキュメントを紐付けるという問題設定において、
 ・クエリ:要求そのもの
 ・ソース文書:既にある程度学習した知識を有する問題領域(ドキュメント群)
 ・ターゲット文書:今回改めて紐付けしたい問題領域(ドキュメント群)
と用語を使い分けているらしい。

検索対象がAmazonみたいな商品の場合でもそうですが、Webページの場合にはそれどころじゃないぐらい対象が多い。Webページ全てに教師データを用意することは当然不可能なので、教師データを用意する試みがいろいろあります。一つは先に紹介した能動学習(Active Learning)のように「ある程度教師データを用意したからこれを元に学習進めておいて、難しい所は聞いてね」というもの。この論文では能動学習とは異なる方法がベースになっていて、転移学習(Transfer Learning)や知識転移(Knowledge Transfer)と呼ばれる「関連したドメインの知識やデータを転移して目標ドメインの問題をより高精度で解く」ことで教師データの準備コストを削減するアプローチの一種らしい。

この転移学習をベースにしたランキングアルゴリズムを Ranking model adaptation と呼んでいるらしい。異なる領域で学習した知識なりを転移して使うことになるので、領域同士が似ている方がより効果的に学習できるっぽく、クラス分類の転移学習においては(多分その似ている事例を識別して)インスタンスへの重み付けを行うことでうまくいくということが示されているらしい。

一方、そのクラス分類学習における転移学習と、ランキングにおける転移学習には、質的な違いがありこれが大きな問題になる。具体的には図1に示される通り、クラス分類におけるインスタンスは「ソースもターゲットも文書だけ」なのに対し、ランキングでは「クエリと文書の2種類あり、文書がどのクエリに属するか」が存在することを考慮する必要がある。つまり、「どの文書がどのクエリに属するかの情報」を考慮してやらないと高精度な学習結果が得られないはず。

この問題を解決するために、クエリの段階で重要度を直接算出したい。そのイメージが図2に示されていますが、「転移元と転移先において、文書集合が似ているクエリ同士は転移する価値が高く、似ていないなら転移する価値が低い」というようにクエリに紐付けた知識毎に価値を重み付けする(Query Weighting)っぽい。従来の手法だと、クエリが特別扱いされてなく、「素朴に文書アイテムに対して重み付けする(document instance weighting scheme)」形で転移学習しようとしてしまうため、どの知識が似ているかどうかの判断がしづらいらしい。

ところが話は簡単ではなく、クエリの価値を推定するのが(多分計算コスト的に)容易ではないので、(1)各クエリを文書インスタンスを加味した特徴ベクトルに圧縮してから重み付けする方法、(2)ソースとターゲットのクエリ間で類似度を算出することでクエリの価値を算出する方法を提案する。というのがこの論文の主題らしい。

上記2手法を評価するため、計算機実験ではLETOR3.0に基づいたベンチマークとしてTREC-2003とTREC2004で比較検証しているらしい。LETORは「Learning to Rank for Information Retrieval」の略らしい。へー。実験では転移元と転移先をHP03→TD03、HP04→TD04、NP03→TD03、NP04→TD04の4ケース分で結果を確認していて、DSモデルベースで重み調整した方が良い傾向(重み調整無し時で50~70%に対し、4ケースとも数パーセント改善)にあるらしい。ただ、重み調整の仕方によっては「重み調整しない方が良い」ケースもあるので、要調整なんだろうなと想像。

いずれにせよ「素朴にドキュメントと同様に扱う」のではなく、クエリで結びつけたドキュメント集合をクラスタ的に扱って調整してみるというアプローチは面白い。精度的には思った程改善していないように見えるのは、教師データにノイズがあることを加味したアプローチになっていないのが主要因なのかしら。それともこれぐらいの改善でも結構凄いのだろうか。

(論文メモ) Joint Annotation of Search Queries / ACL-HLT 2011

金曜日, 6月 24th, 2011

ACL-HLT 2011から面白そうな論文3件目。
面白そうと書きつつ自然言語処理にそれほど詳しくないから誤解してる部分多々ありそうなんだけど。


出典情報: P11-1011: Michael Bendersky; W. Bruce Croft; David A. Smith, Joint Annotation of Search Queries, ACL-HLT 2011

検索エンジンにおいて検索窓に入力される文字列はクエリと呼ばれています。そのクエリをhogehogeしましょうという話らしい。

前置き

クエリから意図を読み取るのは難しい!

一般的にクエリは検索対象となるドキュメントと比べて圧倒的に情報量が少ないです。キーワード1つとか2つといった状況や、構文がハッキリしない曖昧な文章っぽいものが入力されるケースも少なくない。そういう状況下で「ユーザが求めているドキュメントはこれだ!」という判断をする必要がある。単純なキーワード・マッチングだけだと検索漏れが多すぎるので、なんとか工夫して意図を汲み取りましょうという研究事例が多いらしい。

意図を汲み取るために使われる技術の例(*注1

例えば、自然言語処理でいうと、以下のような技術を利用されます。

形態素解析, タガー(tagger): 単語単位で品詞を判定する。
 →動詞や名詞判断すると少しは意図が汲み取りやすくなるかも?
構文解析, パーサー(parser): 文を句や節単位に区切り、それらがどのような構造になっているかを解析する。
 →クエリに現れた名詞はどんな単語が形容しているのか、作用しているのか、名詞を対象とした何を探そうとしているのかといった情報を利用して意図を汲み取れないか?

ある程度ボリュームがあって綺麗に編集された文章ならばこれらの技術を利用しやすいですが、クエリの場合には文としても不自然だったり不十分だったりするので、既存技術を単純に利用するといったことが困難! ということで様々な取り組みがあるらしい。

クエリにおける自然言語処理以外の解析例

クエリは確かに文章としては扱い難いのだけど、文章とは異なる特徴もあり、それを利用して意図を汲み取ろうとする解析例もあります。

例えば「一つ目のクエリでめぼしい結果が得られない場合、続けて複数回異なるクエリで試しやすい」という傾向を利用して、時系列順に複数クエリをグルーピングすることができます。これを利用して、そのグルーピングされたクエリ集合をクラスタリングすることで似たクエリ集合を作り、それらの時系列情報を利用して「こういう順序でクエリを入力するユーザはこういう情報を得ようとしている可能性が高い」といったことを抽出しやすくなります。

「もしかして」も、似たクエリ集合から追加キーワードとかキーワード自体の編集を促そうとする形で望んでいるだろうページへの誘導を図る例ですね。ただし、追加キーワードについては割と単純な話じゃなく、「そもそもユーザのクエリがおかしい」ケースも多々あるので、適切な追加キーワードを精度良く提供するという話もあるらしい。

そしてクエリ拡張へ

良く分からないのだけど、「クエリ拡張(query expansion)」というキーワードがあって、こういう「クエリから得られる情報を増やす」とか「クリックされる頻度を利用して返すコンテンツの順番を調整する」といったことでクエリ⇄コンテンツのマッチングを改善する手法の総称をそう呼んでいるのかなと想像。Wikipedia見る限りでは自然言語処理寄りっぽいけど。

この論文におけるベースになる部分は、クエリから意図を汲み取りやすくするために、「ある程度文章っぽいクエリ(例文: who wan the 2004 kentucky derby)」に対して各単語に下記3種のアノテーションすることが大前提になっているらしい。
 ・CAP: 各単語が小文字/それ以外。
 ・POS TAG: 名詞/動詞/それ以外。
 ・SEGmentation: チャンクの開始/チャンクの中。(チャンク=文節等の塊)

上記のアノテーションがある程度実現出来ているという前提で、それらを利用してクエリを適切に(言語学的に)構造化したいということらしい。イメージ的には、単語毎にアノテーションされている状態から、「単語1番目と単語2番目」といったシーケンシャルな単語集合(shallow sequence)に対して「1つのクエリ語句(a single query term)」であるというアノテーションをしたいっぽい。多分、先の例文でいうところの「who wan the 2004 kentucky derby」では「who wan」、「the 2004 kentucky derby」という2つのサブクエリが組み合わさった一つのクエリなんだ、ということを認識しようということなのかな。この部分がタイトルにある Joint Query Annotation のことっぽい。

SEGmentationタグだけでもこのぐらいならできそうだけど、実際にはこんな綺麗な文章だけじゃないので、CAP、TAG、SEGを組み合わせて利用することでより精度良く Joint Query Annotation を実現しようという試みなんだと思います。

実験では、3種のアノテーションを独立した状態で Joint Query Annotation させた場合(i-QRY, i-PRF)と、3種を組み合わせて利用する場合(j-QRY, j-PRF)とで比較検証しているらしい。ただ、ここを見ると「i-QRY, i-PRF」では、CAP,POS,SEGmentationのアノテーションを独立して処理していて、「j-QRY, j-PRF」ではその3種を合算して最適化する処理をしているように見える。何が違うかというと、3種アノテーションする際に「前者は一度付けたらそれをそのまま正解とみなしており、後者は他アノテーションとの兼ね合いからちょっとおかしそうだから調整し直そうとする」という違いに見える。

大分斜め読みしてるのでどっちの解釈が正しいのかは良く分かってませんが、どちらのアプローチもありだよね。

P.S.

生駒日記によると、
本研究では、これらの3つの系列ラベリングのタスクを同時学習することで、精度を大幅に向上させることができた、という話。

と読むのが正しいらしい。後者の方が正しかったか。



*注1: 実際にはユーザの意図を必ずしも汲み取る必要はありません。結果的にユーザが望んでいる検索結果を提示できれば、クエリに対して望む結果を提示することができれば良い。ここではイメージしやすいようにこう書いています。