MongoDBで自然言語処理

－1 －

NLP with MongoDB

－2 －

NLP おさらい

－3 －

NLPおさらい■自然言語処理

読者の為に書かれた普通の文章を処理する手法

■典型的な流れ●Tokenize–あるドキュメントからそれを構成する単語単位に分割単語検索が可能になる

●Vecterize–単語の重みを加味しドキュメントを代表するパラメータ（ベクトル）を生成重みを加味した検索が可能になる

●Clusterize–文章同士のパラメータを比較し関連度を算出しグループ化関連ドキュメント検索が可能になる

－4 －

NLPおさらい■Tokenize

White space：ドキュメントを単純にスペースで区切るラテン系の言語の場合は大体コレで良いアジア（漢字）圏の言語では用を成さない。。

N-Gram：ドキュメントをN文字ずつ区切る『本日は晴天なり』の2-Gram＝＞（本日｜日は｜は晴｜晴天｜天な｜なり）大量の意味の無い単語が抽出されるが、頻出したモノを単語とみなす単語辞書を使わないので汎用的だが精度が低い

形態素解析：単語辞書を使う辞書を使うので品詞を特定でき、文法上の用法を加味出来るので高精度辞書の網羅率に依存し、言語毎に辞書が必要で汎用性がない

－5 －

NLPおさらい■Vectorize

TF-IDF：

　　小難しい事は端折る！！要は ・そのドキュメント内に頻出する単語は重要！（『宇宙』など） ・大量のドキュメントに出現する単語は不要！（『私』など）

－6 －

NLPおさらい■Clusterize

Canopy：大まかなクラスタを見つける（要は碁石拾い）

K-means：重心→クラスタ分類、クラスタ平均→重心、と繰り返す単純なアルゴリズムで扱い易いが、極値解を求めるため初期条件に強く依存

…

　　　　初期重心の与え方が肝！

－7 －

MapReduce in

MongoDB

－8 －

MapReduce in MongoDB■MongoDBのMapReduceの癖

primary mongodで処理が走るそもそも『ＤＢでロジック走らせる』ってどうなのよ？

PL/S○Lとかも色々アレじゃん？

並列化がshard毎膨大なshardを管理するの大変だし、データ配置的に非効率なことも多い

emit問題一時的に使うemitコレクションがレプリケーションされる。。超無駄！！

NaN等で下手打つとDBが死ぬ（aggrigation FWも同じ）やっぱりnoscriptじゃないと危険。。

－9 －

MapReducein

MongoDB使えたもんじゃねぇ！

－10 －

じゃあ、どうするよ？■代替案の候補

mongo-hadoop + Mahout最有力候補、MRはhadoopに流しとけば鉄板でもJavaが面倒・・・もう昔に戻れない（ＴＴ；

nodeで書けば？JSなら簡単なMR位、さらっと書ける！・・・非同期地獄・・・コールスタック足りないよ・・・

そう言えばmongo shellってV8！敢えて、、ね。→ 他の人と違う事やりたいし。。ベンチ取ったら、nodeより早かった（多分V8バージョンの違い）

　　　　十分使えそう！！

－11 －

Monmoちゃん

－12 －

Monmoちゃん■JOB 単純なJobキュー

■MAP（reduceはemitのkey毎のMAP）

－13 －

Monmoちゃん■必要なもの

–MongoDB–Monmoソース（git clone）–Linux（bash）　こんだけ！

■セットアップ– git clone– mongo.env を適当に編集（MongoのパスやＤＢの場所）– 適当にworkerを起動（ex> ./bin/worker.sh -j 4）　超簡単！

– もうサンプルJOB投入～♪./bin/jobctl.sh -f ./sample/jobs/samplejob.js -s test.T -o test.R

■GIT●https://github.com/monmo

－14 －

Monmoちゃん■特徴（ウリ）

セットアップが超簡単！＝＞他に何も要らない構成変更も楽！＝＞workerを増減するだけMongoDBに優しい設計JS（mongo shell）で開発できるまさに language impedance が ０！

一通りの自然言語処理関連のアルゴリズム実装– 形態素解析– 熟語解析（C-VALUE）– TF-IDF– Canopy , K-means徹底的に並列化なるべくV8のJITに掛かるように工夫

－15 －

Monmoちゃん■問題（困った点）

●開発力が１馬力・・・　white space tokenizerが無かったり、英数の正規化を全角に寄せてたり、、　　色々やる事いっぱい。。思いつきで始めたからね・・・

●まだSharding関連の実装がない（効率的に使えない）●Workerのバージョンチェック作らなきゃ・・・●本当の大規模環境がテストできない・・・個人のツラさ・・・マシンパワー欲しい。。マジで。。

●Mongo shellが色々対応してないので、細やかな制御がムズいsignal とか log とか

■色々連絡貰えると助かります！[email protected]

－16 －

NLP with

Monmoちゃん

－17 －

NLP with Monmoちゃん■手順

以下をgit cloneする– monmo（本体）– monmo-NLProcessing

■monmoセットアップREADME.jpのクイックスタートを流す

■monmo-NLProcessing順にクイックスタートを流す

tokenize/READMEvectorize/READMEclusterize/README

－18 －

細かい話はREADME読んで！

－19 －

NLP with Monmoちゃん■tokenize（形態素解析）戦略

●IPA辞書を元に独自の辞書をコンパイルしてMongoDBに保持– MongoDBの高度な配列インデックスが利用できる– 活用形や先頭Ｎ文字を配列インデックスし、速度・精度を上げる{ w :["行く","行ける","行け","行こ","行か","行き","行い"], t :["動詞","非自立","自立"], h :["行く","行け","行こ","行か","行き","行い"] 　　　　　　：}

– その他、活用形毎の接続分類用のカラムもあったり。。

品詞周りをカナリ頑張ってるので精度は高いよ！！

－20 －

NLP with Monmoちゃん■vectorize（TF-IDF）戦略

● 特別なことはあまりない。。● 効率の面から TF → DF → IDF → TF-IDF の順で処理する● 語句の重みはIDFの段階で決まる（チューニングはIDFでやる）● 正規化● 熟語はをどう取り扱えば良いんだろうか・・・？● READMEで差分戦略までは練った。実装はまだ・・・

－21 －

NLP with Monmoちゃん■clusterize（Canopy）戦略

● ユークリッド距離とcos距離に対応● T2サンプリングを並列化し、高速化！！● T1サンプリング後に追加処理– 小さなクラスタを削除– 近すぎる（T2内）クラスタを削除– ココだけ並列化出来ない・・・

■clusterize（K-means）戦略● ユークリッド距離とcos距離に対応● 極々普通の実装● 並列処理と待ち合わせの繰り返し– クラスタ分類→（待ち合わせ）→ 重心算出 → （待ち合わせ）→ ・・・

－22 －

NLP with Monmoちゃん■課題や、なんとなく判ったこと

● MongoDB的にはTokenizeが一番厳しい– 辞書参照が激しいから– 辞書の動的更新止めてローカルに持つのも手？

● Vectorize以降はＤＢ負荷はほぼ無い– MAP対象のデータをJOB化する時、同じ数のＪＯＢドキュメント生成する　このときはDB負荷が上がる– JOBコレクションをshardingするのは効果がありそう– が、今の環境の規模では効果の判断は無理・・・

● BSON→JSONの変換でJIT対象になる– ３回以上使うオブジェクトは考慮の余地がありそう– 大きい部分は既に対応したが、細かいところは要チェック

－23 －

さーやってみよー

－24 －

サーバーほしーよー