Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Approximate Scalable Bounded Space Sketch for Large Data NLP
Similaire à Approximate Scalable Bounded Space Sketch for Large Data NLP (20)
Plus de Koji Matsuda
Plus de Koji Matsuda (18)
Approximate Scalable Bounded Space Sketch for Large Data NLP
- 1. Approximate Scalable Bounded Space Sketch for Large Data NLP Amit Goyal and Hal Daume III (EMNLP2011) 紹介者 : 松田 2011/10/13 1
- 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 – 対応するハッシュを求めて、セルの最小値をとる – なぜ最小値？ • ハッシュの衝突が発生した場合 の値は実際 の頻度値よりも大きくなるため • ｄを大きくするとハッシュの衝突に対して頑健になる 10
- 11. Count-Min sketch (3/3) • 基本的性質 – Update, Query共に定数時間(ハッシュをd個計算す るだけ) – メモリ使用量は w × d – 確率δで誤差がεNを超える(が、必ずoverestimate) • その他の性質 – 線形性 : sketches s1, s2 をそれぞれ別々のデータか ら計算した場合も、単純に足すだけで合計頻度を 求めることができる – そのため、分散計算にも向いている 11
- 12. Conservative Update • Update時にQueryを挟むことによって、誤差 を小さくできることが経験的に知られている – ただし、更新はちょっと遅くなる • ARE (後述) で 1.5 倍程度の精度向上 • 以後の表記 – Count-Min sketch : CM – Count-Min sketch with Conservative Update : CU 12
- 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