【輪講資料】Fast Candidate Generation for Two-Phase Document【CIKM2012】

2013-06-12に職場で実施した輪講資料を代理アップロードしました．

Transcript

1. 1 Fast Candidate Generation for Two-Phase Document Ranking Postings List Intersection with Bloom Filters Dept. of Computer Science, Institute for Advanced Computer Studies, The iSchool University of Maryland, College Park 2013-06-12 輪講資料
2. 2 1.概要 • 検索エンジンにおけるクエリ処理は前段・後段で分け て考えられる (前段) クエリにHITする文書を十分な量取得する (後段) 取得した文書リストを評価してランキング • この論文は前段についての高速化に関するもの – 対象としているのはANDクエリ – Bloom Filterという単純なデータ構造 – 高速化とトレードオフで精度は劣化する • 評価 – 後段も含めて総合評価 – 精度 通常手法との適合率 3割～数%の幅で劣化 – 性能 10倍以上!?
3. 3 2.手法 • 文書はクエリ非依存な静的スコアの昇順に並べ 替えておく ⇒ そのまま取得すれば静的スコアのTop-nになる • 通常手法(small adaptive)での文書ID取得 • Bloom Filterによる高速判定 ⇒ 2つをミックスした手法
4. 4 2.手法 Bloom Filterとは • 要素が集合のメンバであるかどうかを高速に判 定するアルゴリズム – 集合の要素は複数個のハッシュ関数によって 丸めて、ビット配列に埋め込まれる – 要素の数がどんなに大きくなっても固定O(k) のコストで高速判定 – 偽陽性(false-positive)あり • ハッシュの衝突によって一定の確率でメンバでな いものをメンバであると誤判定 – 偽陰性(false-negative)なし • メンバでないという判定は信じてよい
5. 5 k種類のハッシュ関数から 各々ビット幅rのハッシュ生成 2.手法 Bloom Filter(要素の登録と判定) 1 1 1 1 a h1 hk ： 要素の登録 h2 ビット配列上の対応する 位置へフラグビットを立てる 1 1 1 1 a h1 hk ： h2 ビット配列上の対応する 位置のビットを参照 要素の判定 k個のハッシュ全てのフラグが立っている⇒メンバに含まれると判定 ビット配列 k種類のハッシュ関数から ハッシュ生成 b c
6. 6 2.手法 インデクス形式(1/2) 1 5 7 10 15 … 1 1 1 1 banana 要素登録 単語bananaのpostings list に対するBloom Filter • 構成 – 通常手法で圧縮(PForDelta)されたpostings list – 文書IDを要素としたBloom Filter ⇒ 要素の数 × r[bits/element]の大きさを持つ (単語によって異なる) 7 8 9 11 15 20 … 1 1 1 1 apple
7. 7 2.手法 インデクス形式(2/2) • 課題 頻出単語の場合Bloom Filterのサイズが大き くなりすぎる θI = N(文書ID総数)/r[bits/element]とすると θI < 要素数の場合 Bloom FilterのサイズがNより大きくなってしまう (1..Nの空間があるならば、ハッシュで丸める必要 がなくなる。。) θI < 要素数 ⇒ サイズNのビット配列に格納 (文書IDに対応するインデクスビットを立てる) θI => 要素数 ⇒ Bloom Filter生成
8. 8 7 8 9 11 15 20 … 1 1 1 1 1 1 1 1 1 5 7 10 15 … 1 1 1 1 3 7 7 15 21 22 … banana apple orange ①クエリ単語の内 TF値が低いものを選択 ⇒ “banana” ②選択された単語は既存手法通り 圧縮されたpostings listを走査 ③ 走査している文書IDが他の単語のpostings listに含まているか? をBloom Filterにより判定 ⇒ 全て含まれていれば文書IDを結果へ追加 2.手法 転置インデクスの検索 走査しない
9. 9 3.評価 : 実装 • 提案手法をオープンソースのKamikaze package(by LinkedIn)へ適用 • end-to-endの精度も評価するため、後段部も実 装 ⇒ 43の素性でrerank • 比較のためのベースラインは通常手法(small adaptiveのみでBloom Filter判定なし)
10. 10 3.評価 : データセット • 共通 – ClueWeb09 Dataset – Waterloo spam scores • ClueWeb09へspam (クエリ非依存なスコアとして使用) ⇒ 転置インデクスの元ネタ • 精度評価向け – TREC 2009 web track • 性能評価向け – AOLのクエリログ
11. 11 3.評価 : 精度 • 前段部だけでTop-10000を取得して評価 • 通常手法の結果に提案手法(Bloom Filter判定あ り)の適合率 • 後段も含めてNDCG(normalized discounted cumulative gain)で評価も行って大きな違いはな かったと書いてある、詳細はomitされている。。
12. 12 3.評価 : 性能1/2 • BF無し版 : 平均応答時間 87.3ms ⇒ 10倍以上!? • ハッシュの個数kを増加させると当然劣化(ハッシュ生成 コスト + メモリアクセス頻度増) • 要素当たりのビット数r : 増加させると性能向上(偽陽性 率が現象)
13. 13 3.評価 : 性能2/2 • クエリが長くなると性能が改善! – 低頻度な単語の出現確率が増加? • 提案方式ではpostings listを走査するのは低TFの1 つだけ、他の単語はBloom Filterで高速判定
14. 14 まとめと所感 • 検索エンジンにおけるクエリ処理は前段・後段で分けて考えられる (前段) クエリにHITする文書を十分な量取得する (後段) 取得した文書リストを評価してランキング • この論文は前段についての高速化に関するもの – 対象としているのはANDクエリ – Bloom Filterという単純なデータ構造 – 高速化とトレードオフで精度は劣化する • 評価 – 後段も含めて総合評価 – 精度 通常手法との適合率 3割～数%の幅で劣化 – 性能 10倍以上!? ⇒ • Bloom Filterは使いどころによっては飛躍的に性能を向上させる • 単純なデータ構造なので応用範囲は広い