More Related Content
Similar to Approximate Scalable Bounded Space Sketch for Large Data NLP
Similar to Approximate Scalable Bounded Space Sketch for Large Data NLP (20)
More from Koji Matsuda (18)
Approximate Scalable Bounded Space Sketch for Large Data NLP
- 2. Abstract
• Count-Min sketch(以下CM)という sketch-based アル
ゴリズムを単語ペアの計数に用いる
• CMを用いることで、単語ペアそれ自体を保持する
ことなく、共起頻度の近似値を(空間,時間ともに)
効率よく保持することができる
• 共起頻度の近似値を以下の三つにタスクに適用
し、state-of-the-artな手法、及びExact Countと性能
を比較
– 単語の感情極性判別
– 分布アプローチに基づく単語の類似性判別
– 教師なし係り受け解析
• 49GBのテキストからの共起情報を8GBほどのメモ
リで扱うことができる事を示す
2
- 3. Introduction
• NLPで利用可能なデータはテラバイト級に達しつ
つある
• 大規模なクラスターを用いた計算が主流
– Brants et al. (2007) : 1500台で 1.8TB
– Aggire et al. (2009) : 2000コアで 1.6 Terawords
• しかしながら、多くの研究者は大規模な計算資源
を持っていない
– 何らかの「妥協」をしながら大規模なデータを扱う
研究も盛んになってきている
– Streaming, Randomized, Approximate…
• しかし、それらは汎用性に欠けるものであること
が多い
3
- 4. Introduction
• 本論文では、 Count-Min sketch(Cormode and
Muthukrishnan 2004)というデータ構造を用い
る
• 「一つの」モデルで以下のような複数のタス
クで効果があることを示す
– Semantic Orientation of the word
– Distributional Similarity
– Unsupervised Dependency Parsing
• 多くのNLPタスクで重要な、PMI, LLRのよう
な、関連性尺度を効率的に計算できることを
4
示す
- 5. ストリーム計数界隈の最近の動
向
• Nグラム(あるいは共起)情報をワンパス、コンパク
ト、高速に格納する研究が盛んに行われている
• Counter-based Algorithm
– 高頻度の要素に絞って、多少の誤差を許してカウン
ト
– 高頻度の要素であればあるほど、より正確な値が得
られる
• Sketch-based Algorithm
– 要素自体は陽に保存せず、複数のhash関数の値を用い
てカウントを格納(問い合わせにもhash関数を用いる)
– Count-Min sketchなど
今日扱うのはこちら
5
- 6. Counter-based Algorithm
• 高頻度のデータをストリームから抽出する手
法として開発
– Frequent(2002), Lossy Counting(2002) etc…
• N個のデータ中で Nε (0 < ε < 1) 回以上出現す
るアイテムの近似頻度を効率よく保持するア
ルゴリズム
• Pros.
– 高頻度のものについてはデータを陽に保存する
• Cons.
– 低頻度のデータについては保存されない
– (私があまり勉強してないので説明できない)
6
- 7. Sketch-based Algorithm
• 複数のハッシュ関数の値を用いて、データを陽に保存せず、ハッ
シュの値とカウントを関連づける
– CountSketch (2002), Count-Min sketch(2004), Multistage Filter(2002)
etc.
– ルーツはBloom filter(1970)にさかのぼる
• Pros.
– Update, Query, 共に定数時間(ハッシュ関数の個数に比例)
– 低頻度のitemについても(正確性はともかく)何らかの値を保持
できる
• Cons.
– 確率 δ で overestimate する
• ハッシュの衝突に起因するFalse Positiveが起こる
– データを陽に保存しない
• つまり、sketch中に何が保存されているかは問い合せてみないと分からない
7
- 8. Bloom Filter Algorithm
• Bloom(1970)
– itemがデータベースに「存在するか否か」を効率よく保持する
アルゴリズム
– mビットのビット配列, k個の(pairwise independentな)ハッシュ関
数
– 確率 δ で False Positive(実際は存在しないのに真を返す)
• データベース/辞書に問い合わせる「前段階」でクエリをフィ
ルタリングする用途に用いられることが多い
– Google日本語入力 (Mozc)
– 分散KVS (Cassandra, HBase等)
– Google Code searchで検索するとワサワサ出てきます
• 最近(実用レベルで)よく見かけるようになってきたデータ構
造なので、興味があれば調べてみてください
– Wikipediaに理論的なところも含めて解説があります
8
- 9. Count-Min sketch (1/3)
• d × w の二次元テーブル、d個のハッシュ関数で表される
データ構造
– d : ハッシュ関数の個数
• 大きくすると、ハッシュの衝突に対してロバストになる
– w : ハッシュ関数の値域
• 大きくすると、ハッシュの衝突が起こりにくくなる
ハッシュ関数の値域
ハッシュ関数の個数
各セル(カウンタ)はゼロで初期化(4Byteのintで実験を行っている)
9
- 10. Count-Min sketch (2/3)
• Update Procedure
– xがc個観測された場合、xに対して、それぞれの
行に対応するハッシュを求めて、該当するセルに
+ c する
• Query Procedure
– 対応するハッシュを求めて、セルの最小値をとる
– なぜ最小値?
• ハッシュの衝突が発生した場合 の値は実際
の頻度値よりも大きくなるため
• dを大きくするとハッシュの衝突に対して頑健になる
10
- 11. Count-Min sketch (3/3)
• 基本的性質
– Update, Query共に定数時間(ハッシュをd個計算す
るだけ)
– メモリ使用量は w × d
– 確率δで誤差がεNを超える(が、必ずoverestimate)
• その他の性質
– 線形性 : sketches s1, s2 をそれぞれ別々のデータか
ら計算した場合も、単純に足すだけで合計頻度を
求めることができる
– そのため、分散計算にも向いている
11
- 13. Evaluating sketch count(1/2)
• ARE(Average Relative Error)で評価
• Gigaword Corpus(Graff 2003)のうち200万文
– 窓幅7以内に共起する語ペアの頻度を調査
– 88Mペア
• 低頻度のペアで
エラーが多い
• CMよりCUの方が
誤差が少ない
• 20Mではd=3が最良
• 50Mではd=5が最良
以後、d=5のCUを実験に使用
13
- 14. Evaluating sketch count(2/2)
• d = 5 ( δ = 0.01 )に固定して、モデルのサイズを変化
させる
– 要は, w(ハッシュ関数の値域)を変化させる
– コーパスはGigaword(88Mエントリ)
• 結果
– 100Mカウンタでほぼ誤差は0に
– 素直に単語ペアを保存すると
1エントリあたり平均12バイト
そのため、4バイトintで保持
できるというだけでかなりの領域
が削減できている
エントリのサイズが大きいタスクなら
更に顕著に領域削減できると思われる
14
- 15. Evaluating association ranking
• 単語ペアの関係性を評価
– PMI(Pointwise Mutual Information)
– LLR (Log Likelihood Ratio) Recallでの評価になっているのは
SketchからTopKを取り出すことが
できないから?
R : Exactから計算したペア集合に対するRecall
ρ : Exactから計算したペア集合との順位相関係数
PMIの性能がすぐれない
理由:低頻度ペアに高い値
を与えすぎる傾向があるから
が、モデルサイズを大きくする
改善することが分かる
15
- 16. 復習 : PMI と LLR
• どちらもアイテムの共起性、独立性を示す指標
• PMI ( Pointwise Mutual Information)
– x,yの出現確率の独立性を直接に用いている。頻度自体は考
慮しないので、低頻度のアイテムに不当に高い値がつくこ
とがある
p(x.y)
PMI(x, y) = log
p(x)p(y)
• LLR ( Log-Likelihood Ratio)
– 数式は省略。分割表に基づいて L(データ|従属)と L(データ|
独立) の比を求めることによって、共起性をはかる
– “尤度比検定”に用いられる
• 分割表の各セルの値がそれなりに大きい値を持つことを期待
• 低頻度のペアに対しては概して小さい値が得られる
16
- 17. 実際のタスクに適用
• データ
– Gigaword Corpus + Web Data
• 三つのタスクに適用
– Semantic Orientation
– Distributional Similarity
– Unsupervised Dependency Parsing
17
- 18. Semantic Orientation (1/2)
• 単語のPositive / Negative を判定するタスク
– 種語との関連性に基づく単純なモデル(Turney and Littman, 2003)
– 正解データ: General Inquirer lexicon (Stone et al., 1966)
モデルサイズを増やすことで性能
向上がみられる
PMIを用いたほうが精度が良く、
20億カウンタ(8GB)でExactと差が
見られなくなる
精度のモデルサイズに対する変化 18
- 19. Semantic Orientation (2/2)
• コーパスサイズを変化させて精度を確認
– モデルサイズは 2Billion (8GB) に固定
• Webデータを加えることで精度の向上が見られる
• どのコーパスサイズでもExactと同等の精度を達成
• 2B個のカウンタで GWB20 (6.05B), GWB50 (13.2B) の情報を保持できた
• このタスクのstate-of-the-art (82.84%) に近い結果をより小さなコーパスで得られた
• (Turney and Littman, 2003)の結果. 1000億語使っているらしい・・・ 19
- 20. Distributional Similarity (1/4)
• 「(意味的に)似た単語は、似たコンテキスト
に出現する」という仮説に基づく語の類似性
判定
• 提案されている効率的な計算方法
1. 単語それ自体に対してはExactカウント, 単語ペ
アに対してはCU-sketchを用いて近似値を計数
2. ある対象語 “x” に対してすべての語との共起尺
度(PMI, LLR)をsketchを用いて計算
3. Top K( K= 1000 ) だけを保持して、 K個のベクト
ルとのcosine尺度を計算
4. cosine尺度が高いほど “x” との類似性が高い
20
- 21. Distributional Similarity (2/4)
• 用いた Gold-standard データセット
– どちらも (Aggire et al. 2009)で用いられている
もの
– WS-353 ( Finkelstein et al. 2002)
• 353ペアに対して 0(無関係) 〜 10(同じ意味)のアノ
テート (13〜16人による平均)
– RG-65 (Rubenstein and Goodenough 1965)
• 65ペアに対して51人に同様の調査を行った古典的
データ
• それぞれに対して、スピアマンの順位相
関係数で評価を行った
21
- 22. Distributional Similarity (3/4)
• Gigawordコーパスにおいてモデルサイズを
変化させた場合の性能の変化
– WS-353で実験
恐らく ρ の間違
い
PMIはほとんどダメ、モデルサイズを増やしても相関係数が上がらない
PMIは絶対頻度を考慮しないので、稀なペアに高いスコアをつけすぎるのが要因
22
(そもそも正解データに「稀なペア」はあまり無い...)
- 23. Distributional Similarity (4/4)
• コーパスサイズを変化させた場合の順位
相関係数の変化 ( higher is better )
• データを増やすことによってそれほど大きな性能向上はみられな
い
• コーパスサイズを増やしても、 Exactとほぼ同じ性能を出すことが
できている
• state-of-the-art (Aggire et al. 2009)と同等の性能
• 1.6 Terawordsから PMI を2000コアMapReduceでガリガリ求め
る手法 23
- 24. Dependency Parsing (1/5)
• MST Parser (McDonald et al. 2005)のフレームワーク
のもとで実験
– すべての語のペアに重みつきのエッジがあり、その
合計の重みを最大化する全域木を求める問題
– エッジの重みは MIRA 等で学習するのが普通
• 要は、 unsupervisedに 最適な重み w(wi,wj) を求め
ることが出来るかどうかという問題
– 結論:「明らかに無理」
• PMIは稀なペアに高いスコアを付け過ぎる傾向
– 主に内容語同士
• LLRは頻出するペアに高いスコアを付け過ぎる傾向
• 言語学に基づくヒューリスティックスを入れてみ
よう
24
- 25. Dependency Parsing (2/5)
• ヒューリスティックス入りの重み
関連度に基づく 係り受けの距離 文法ヒューリスティックス
重み(PMI, LLR) に基づく重み に基づく重み
• 係り受け距離に基づく重み
•
• 右向きの短いエッジに大きな値がつくように設計 αをどのように
• 文法的なヒューリスティックスに基づく重み 求めるか?
• (Naseem et al. 2010)で提案されているもの(p258 下段)
• いずれかのルールにマッチしたら1, そうでなければ0
• データとしては Pen Treebank の Section23を使用
• 評価指標は directed , unlabeled dependency accuracy.
25
- 26. Dependency Parsing (3/5)
• OPTIMAL
• 二変数のグリッドサーチで最適な重み
• BALANCED
• すべての項を同じ重み (各項ゼロ平均で分散が1になるようにスケーリングする
• SEMISUP
• 10文だけ使ってそれらに対してグリッドサーチで最適化(20回実験した平均)
26
- 27. Dependency Parsing (4/5)
• COHEN-DIRICHLET, COHEN-BEST
• (Cohen and Smith, 2010) state-of-the-artなUnsupervised Bayesian parser
• JMLRの論文. ヘビーなので読んでません・・・
• ORACLE
• Pen Treebankから学習したLLR ??
• BASELINE, BASELINE+LING
27
• Simple Right-branching tree (+LING は ルールにマッチするものはルールを使う)
- 28. Dependency Parsing (5/5)
• 全体としてPMIを用いたほうが少しだけ結果が良い
• BALANCED が健闘、OPTIMAL は最良の結果を得ている
• OPTIMALが良いのは当たり前といえば当たり前・・・
• BALANCED, SEMISUPの二つの設定で、state-of-the-artに匹敵
28
- 29. Discussion and Conclusion
• コーパス中のすべての語に対してPMI, LLRといっ
た関連性指標を効率よく計算するために、 sketch
技法が有効であることを示した
• 三つのタスクで実験を行い、 Exactカウント、
state-of-the-artのいずれとも同等の性能を得ること
ができた
– 49GBのコーパスから得た共起情報(13.2Bエントリ)を
2B個のカウンタ(8GBのメモリ)で扱うことができるこ
とを示した
• sketchは線形性があるので、分散環境でも有効に
用いることができる
• sketchから得られる関連性指標は他のタスクにも
用いることができる
– randomized LM, WSD, スペル訂正, 関連学習, 換言, MT等
29
- 30. Web上で参考になる資料等
• Sketching data structures — next big thing syndrome
– http://lkozma.net/blog/sketching-data-structures/
– 英語による簡単なBloom Filter, CM-sketchの解説記事
• Everything counts - ny23の日記
– http://d.hatena.ne.jp/ny23/20101108
– さまざまな近似カウンティングの手法がまとめられている(実装もある)
• ブルームフィルタ - Wikipedia
– http://ja.wikipedia.org/wiki/ブルームフィルタ
– Wikipediaの日本語ページにしては充実している
• Count-Min Sketch
– https://sites.google.com/site/countminsketch/
– 公式?サイト. 実装も配っている
• Amit Goyal
– http://www.umiacs.umd.edu/~amit/
– 第一著者のサイト (NAACL-HLT 2010の論文が直接のprior work, 扱ってい
るデータ、タスクが違うが論旨はほぼ同じ)
30