私がチャレンジしたSBMデータマイニング

私がチャレンジしたSBMデータマイニング 7月12日 SBM研究会@東工大筑波大学大学院システム情報工学研究科M1 神林亮

まずは自己紹介から 2008年7月12日 SBM研究会 2

自己紹介(1) 筑波大の筑波大のM1の学生専門は専門はHPC ・クラスタコンピューティング・スーパーコンピュータ・グリッドコンピューティングテーマの例・簡便にボランティアコンピューティングを実現するためのフレームワーク・仮想マシンを用いた分散システムの耐故障性評価環境 etc…… 2008年7月12日 SBM研究会 3

自己紹介(2) 物作りが大好き物作りが大好きりが大好・いろいろ作ったいろいろ作最近だとひらめいっただとひらめいったー・最近だとひらめいったーとか学部3 (2年前年前) ・学部3年(2年前)の時に SBMにハマる SBMにハマる今回の今回の話 2008年7月12日 SBM研究会 4

自己紹介(3) with はてブはてブ主に使うSBMははてブブログのブクマ数 = 794 サービスの置いてあるアドレスのブクマ数 = 736 合計 = 1530 余談: みなさんはどれぐらいブクマされてます？ 2008年7月12日 SBM研究会 5

2008年7月12日 SBM研究会 6

やっと自己紹介が終わりましてやっと自己紹介が自己紹介方針の説明を方針の説明をば 2008年7月12日 SBM研究会 8

発表の方針発表の SBMデータマイニングサービス開発体験記・別に、深い洞察があるわけではないです^^; ・泥臭い話をしようかと思います・誰でもできると伝えたい俺の屍を越えて行け!! 2008年7月12日 SBM研究会 9

アジェンダ各SBM関連のサービス開発記・開発を始めた経緯・Kikker ・はてブおせっかい・はてブまわりのひと・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 10

やっと肝心のやっと肝心の話が始まります肝心 2008年7月12日 SBM研究会 11

開発に至った経緯開発にった経緯 Ceekz氏がはてブニュースというサービスを作ったベイズ推定によってはてブのホッテントリを自動分類これはすばらしいものだ! しかし、並びかえただけでフィルタリングとかをしているわけじゃない情報収集の手間はそれほど変わらない http://labs.ceek.jp/hbnews/ 自分専用のフィルタリングがいい 2008年7月12日 SBM研究会 12

Kikker 学習するユーザーカスタマイズドなニュースサイト・ユーザ(はてブの)ごとにページを推薦・学習機能付き 2008年7月12日 SBM研究会 15

全体動作 0. Kikkerがはてブをクロールして各ページの情報を集める(常に) １．ユーザ登録 1.1 はてなのアカウントを設定 1.2 自身の興味のあるキーワードを重みとともに登録 2.ユーザがKikkerにアクセス 3.Kikkerが各ページについて評価値を計算．評価の高かったN ページをユーザに推薦 4．ユーザが推薦されたページを閲覧すると、Kikkerがそのページを対象ユーザの趣向であると学習 5. ステップ2に戻る 2008年7月12日 SBM研究会 16

評価値の計算方法評価値のアルゴリズム・ベクトル計算・ページ内容のベクトルとユーザの趣向のベクトルの角度(距離)を計算・得られた値はすなわち評価値．対象のページが対象の得られた値はすなわち評価値対象のページが対象の評価値．ユーザにどれだけおめかを意味にどれだけお薦意味するユーザにどれだけお薦めかを意味するユーザの趣向ベクトルユーザの趣向ベクトル？ページの内容ベクトルページの内容ベクトル 2008年7月12日 SBM研究会 17

まずはページの内容を表現するベクトルの求め方 (ユーザの趣向についてのベクトルはその後で) 2008年7月12日 SBM研究会 18

ページの内容を表現するベクトルページの内容を表現するベクトルするページ内の各単語ごとの重み・意味は見ていない Ex)[SBM,web,ajax]=[10,10,40] ベクトルの抽出 1.はてブのキーワードを集める 2.ページの内容を形態素解析して単語に分解(1のも含む) 3.名詞だけ選択 3.各単語の重みとTF・IDFで決定 4.重みの上位N個と手順1のキーワードでベクトルを構成 2008年7月12日 SBM研究会 19

形態素解析対象言語の文法の知識（文法のルールの集まり）や辞書（品詞等の情報付きの単語リスト）を情報源として用い、自然言語で書かれた文を形態素（Morpheme, おおまかにいえば、言語で意味を持つ最小単位）の列に分割し、それぞれの品詞を判別する作業を指す。 (http://ja.wikipedia.org/wiki/%E5%BD%A2%E6%85%8B%E7%B4%A0%E8%A7%A3%E6%9E%90) Mecab ・日本ではchasenの次に有名？・言語がJavaだったのでJavaポート版のSenを使用 2008年7月12日 SBM研究会 20

TF-IDF 単語の文章中での重みの指標ある単語iのドキュメントjの中での重みを求めたい計算するために必要な情報・TF:対象ドキュメント中の対象単語の出現数 (文書長で割って正規化する場合もある) ・N:世界中に存在するテキストの数・DF:対象単語を含むドキュメントの数検索エンジンを使えばオケ・Yahoo APIを叩く・ http://nais.to/~yto/clog/2005-10-12-1.htmlを参照 2008年7月12日 SBM研究会 21

今度はユーザの趣向を表現するベクトルの求め方 2008年7月12日 SBM研究会 22

ユーザの趣向を表現するベクトルユーザの趣向を表現するベクトルする各ユーザは自身の趣向を表現したベクトルを持つ・見たページの趣向を自分に足しこむ・はてブでブクマしたページから学習 (ユーザ登録時の一回だけ) ・ユーザがKikkerに勧められたページを閲覧するとKikkerが学習・自身でも指定可能学習の仕方については後で説明します 2008年7月12日 SBM研究会 23

材料が揃ったので評価値を計算 2008年7月12日 SBM研究会 24

ベクトル間の角度(距離)の計算ベクトル間計算方法・式に2つのベクトルをつっこんでやる・下の式のSc Scがすなわち評価値で、あるページがあるユーザに Sc どれだけお薦めかという値・各ページについて求めたら、ソートして上位のものを推薦 2008年7月12日 SBM研究会 25

全体動作 0. Kikkerがはてブをクロールして各ページの情報を集める(常に) １．ユーザ登録 1.1 はてなのアカウントを設定 1.2 自身の興味のあるキーワードを重みとともに登録 2.ユーザがKikkerにアクセス 3.Kikkerが各ページについて評価値を計算．評価の高かったN ページをユーザに推薦 4.ユーザが推薦されたページを閲覧すると、Kikkerがそのページを対象ユーザの趣向であると学習 5. ステップ2に戻る 2008年7月12日 SBM研究会 26

学習の仕組み学習の仕組みユーザが推薦されたページを見るたびに学習・ユーザが見たページのベクトルをそのユーザの趣向ベクトルに足しこむユーザがお勧めされたページのうちのどれを実際に見たか知る必要がある・推薦ページのリストのURLはKikkerのサイトのものにしておき、ユーザには一回転送することでアクセスさせる 2008年7月12日 SBM研究会 27

システム構成システム構成ページ生成、ユーザ管理ページ生成、ユーザ管理生成 Ruby on Rails クローリング、クローリング、計算処理 Java + Crossfire DB DB MySQL OS (CentOS CentOSのもあった) Windows XP (CentOSの時もあった) Ruby部とJava部の間はXML RPCで接続

よくできました 2008年7月12日 SBM研究会 29

ひとまず出来上がったけどひとまず出来上がったけど出来上ベクトルの計算処理は妥当な処理時間で行えたただ、ページ情報のクロールが重すぎ Yahooに異様な数のクエリを投げているのでバンされるのではないか・・・・・ 2008年7月12日 SBM研究会 31

クエリを減らす工夫クエリをらす工夫文章中の全てのキーワードをYahooに検索かけるのは無理・bulkfeedsのキーワード抽出APIで間引きをするクエリの数はかなり減らせた重みの情報も取れればよかったけど、それはできなかった・mecabの辞書が持っている生起コストを使うよくわからないけどTF-IDFのIDFと置き換えてＯＫらしい by ceekz氏クエリの数を0にできた。わーい。 (参照: http://labs.cybozu.co.jp/blog/kazuho/archives/2006/04/summarize.php) 2008年7月12日 SBM研究会 32

よりよい精度を求めてよりよい精度を精度推薦の精度はあまり高くない気がする・キーワード抽出の精度が低い？・タグやキーワードが分散し過ぎていてベクトルによる類似度計算がうまくいっていない Future Work!!!!! 前者の問題を改善する方法・少なくともタグの揺らぎはどうにかしたいところウェブ？Web?はてなブックマーク？はてブ？後者の問題を改善する方法・潜在的意味インデキシング(Latest Semantic Indexing:LSI)という手法がある・特徴を表現するのに最適なベクトル空間を見つけて、元の空間からその空間に写像してしまう (ベクトル空間の圧縮?) ・おおざっぱに言うと、必要最低限のキーワード(元のキーワードに対応しない場合もあるが)だけを使うという感じ・ベクトルの次元も小さくなるので計算量も減らせる

実は・・・ここだけの話・最初はKikkerのような事をHTTPプロキシを使ってやるつもりだった・HTTPプロキシでユーザの通信を解析して趣向を抽出してほげほげ・非集中のP2P型にしようとも考えていた簡単なところから始める意味で簡単なところから始める意味で今のKikkerを作ったなところから意味 Kikkerを難しい方は途中でやる気が失せて今に至る

そんな事そんな事はどうでもいいですよね 2008年7月12日 SBM研究会 35

アジェンダ各SBM関連のサービス開発記・開発を始めた経緯・Kikker ・はてブおせっかい・はてブまわりのひと・Kookle 個人による高性能データマイニングの可能性 Futue of SBM まとめ 2008年7月12日 SBM研究会 36

はてブおせっかいはてブ・各人のブックマーク履歴を利用して推薦を行う・Kikkerと異なりページの内容の情報は使わない・アルゴリズムはコラボレイティブフィルタ・ユーザ登録不要 2008年7月12日 SBM研究会 37

コラボレィティブフィルタ p1 p2 p3 p4 p5 p6 p7 Bob ○ ○ ○ Tom ○ ○ ○ ?→○ ?→× Joe ○ ○ ○ John ○ ○ ○ Tom[i] =( (sim(Tom,Bob)*Bob[i] + sim(Tom,Joe)*Joe[i] + sim(Tom,John)*John[i])/3 > 閾値 ) 2008年7月12日 SBM研究会 38

式 Mixがドキュメントxがユーザiにどれだけお薦めかの値 Mixが0.5以上なら推薦、0.5以下なら推薦しない (はてブおせっかいでは閾値をいじったけど) MiはMixのXに関する平均 Cijはユーザiとユーザjの相関係数。一つ前のスライドのsim関数に相当 (参照:http://www.nec.co.jp/rd/DTmining/members/yamanishi/Webmining.pdf)

システム構成システム構成 Kikkerと同様

余談: 労力のお話労力のおのお話システムの大部分はKikkerと共通であったため、新たに実装したのは計算アルゴリズムのところだけそんなわけで実装は一日で終了実装で大変なのはクローリングやらDB周りの処理であって、推薦のための計算処理自体は大した労力は必要ない (ということはクローリング周りをみんなで共通化できるとうれしいかも)

ひとまず出来上がったけどひとまず出来上がったけど出来上計算処理が重すぎてユーザがイライラ・Kikkerでは転置インデックスを作ることで全てのページに対して計算を試行することは避けられていた・はてブおせっかいはそれはできない解決策・計算処理で利用するユーザとページをどうにかして間引く仕組みが必要かユーザに関してはユーザのクラスタリングで対応できないだろうか？ 2008年7月12日 SBM研究会 42

はてブまわりのひとはてブ・はてブのお気に入り、られを見てクラスタリング・自分の周りでクネクネしてるのは誰？・自分はどこらへんとクネクネしてるの？ 2008年7月12日 SBM研究会 44

http://www.coins.tsukuba.ac.jp/~i041184/distribute/ hatebu_mawarinohito/hatebu_mawarinohito.html で遊べます。べます。

クラスタリング・ソーシャルブックマークサービスを利用した情報リコメンデーション [白土ら ’06] を参考に実装。ただ、この論文だけだとクラスタリングの処理を実装できなかったのでリファーされていた論文も読んだ。・Finding local community structure in networks [Aaron Cluset ‘05] で、実装したのだがクラスタリングの結果がしっくりこなかったので、論文で説明されていたアルゴリズムのフィーリングの基にオレオレなアルゴリズムを考えてそれを使用。

クラスタリングアルゴリズム前提:ユーザ間の接続関係を表現したグラフがある下準備1: 空の集合Aと全ユーザを含む集合Uを用意する下準備2: 集合Aに起点となるユーザ(まわりのひとを発見したい人)を追加・以下の繰り返しステップを集合A内のユーザ数が一定数を越えるまで行うステップ: 繰り返しステップ集合U内で集合A内のユーザからの総被リンク数が大きいものを選択し集合Aに追加・結果出力集合Aを発見したユーザ群として出力 ※全ユーザからの被お気に入り数も考慮しなければ、被お気に入りの多い人間がどうしても選択されてしまうことになってしまうが、このアルゴリズムはその問題をあえて考慮していない

システム構成システム構成 Javaアップレット製クラスタリングの計算処理はアップレットで行う計算に必要となるデータは事前にRubyで生成してサーバに置いておき、アップレットは必要に応じてそれをロード

Kookle ・はてブのタグ情報から生成するウェブディレクトリサービス・要はSBMのタグから Yahooみたいなディレクトリを作ってみようという試み・ミソはタグ間の共起頻度 2008年7月12日 SBM研究会 50

Kookleを作ろうと思った経緯ろうと思った経緯いくつかのサイトで分類法としてディレクトリによる方法とタグによる方法の違いが考察されていたディレクトリでのファイル管理をタグに置き換えることは簡単そうだ (ディレクトリ -> タグ) ・ディレクトリ名をタグとしてファイルに付けるだけだし・・・逆(タグ -> ディレクトリ)はできるかな？

ディレクトリは本当にできる？ディレクトリは本当にできる？にできるタギング時に大分類と小分類をつけることがある気がする・[web][ajax] ・[neta][非モテ] ・[政治][中国] これはディレクトリでの親と子に他ならない! できそうだ!

では実装について 2008年7月12日 SBM研究会 53

やらなければいけない事やらなければいけない事ディレクトリを作って、それをさらにウェブディレクトリサービスに仕立てるには以下の2つのことをしなければならない 1: タグの共起頻度からディレクトリ構造を構成 2: 各タグについて、それが多く使われているサイトを集計

共起頻度あるタグとあるタグがどれだけ同時に利用されたか全タグ x 全タグのテーブルを作ればよい・ほとんどの箇所に値がない疎なテーブル・ハッシュを使えば空間効率がよいクローリング時に集計 Ex)[web][ajax][mixi]とタグ付けされたブクマがあったとする table[“web”][“ajax”]++; table[“web”][“mixi”]++; table[“ajax”][“web”]++; table[“ajax”][“mixi”]++; table[“mixi”][“web”]++; table[“mixi”][“ajax”]++;

1: タグの共起頻度からディレクトリ構造を構成

アルゴリズムを考えるアルゴリズムを仮定1 大分類のタグは中・小分類のタグよりたくさん使われているタグ数大分類中分類小分類

アルゴリズムを考えるアルゴリズムを仮定2 ○共起頻度の関数関連するタグの共起頻度は高い co-occur (tag1,tag2) Co-occur(web,sns) Web 政治 is high. SNS Blog スキャンダル外交 Co-occur(政治,外交) is high. 上のような構造があるとすれのような構造があるとすれ構造 Co-occur(web,外交) is low. のように観測観測されるはずば右のように観測されるはず

これらの仮定をこれらの仮定を踏まえまして仮定

ヒューリスティクスによる簡易なディレクトリ構成アルゴリズム WIDTH: ひとつの階層に含まれるタグの数を表現する定数ステップ1 ステップ1 タグを総出現数に従ってソートして一列に並べるステップ2 ステップ2 ステップ1のタグ列を出現数の高い方からWIDTH, WIDTH ^2, WIDTH ^3・・・・という間隔で区切り、それぞれ階層1,2,・・・・とするステップ3 ステップ3 階層nに含まれる各タグについて,階層(n-1)に含まれるタグの中から最も共起頻度の高いものを選びそれに所属させるステップ4 ステップ4 ステップ3で作成した関係をツリーとして出力する

アルゴリズムの図示1 アルゴリズムのステップ1:ソートステップソートステップ2:分割ステップ分割 WIDTH WIDTH^2 WIDTH^3 タグ数ステップ3:親ステップ親の決定 ※図では一部の接続のみ表示では一部接続のみ一部ののみ表示

アルゴリズムの図示2 アルゴリズムのステップ4:ツリーのステップツリーの出力ツリー ※小分類以降は図示省略 Root Blog SNS Ajax 大分類中分類小分類

2: 各タグについて、それが多く使われているサイトを集計

タグごとのサイト集計1 タグごとのサイト集計ごとのサイト各タグのページにはそのタグが多くつけられたサイトサイトを列挙したいサイトページじゃなくてサイト! ページじゃなくてサイトじゃなくてサイト個々のページについてのブクマは、そのページを含むサイトに対してのブクマと認識しなければならないあるページのURLから、それを含むサイトをどう判断する？ http://d.hatena.ne.jp/kanbayashi/20080713/p1 なら http://d.hatena.ne.jp/ かな？ http://d.hatena.ne.jp/kanbayashi/ かな？それとも http://d.hatena.ne.jp/kanbayashi/20080713 かな？

タグごとのサイト集計2 タグごとのサイト集計ごとのサイト感覚的なルールに基づいて判断・http:/XXXX/YYYY/ZZZZ/SS?QQ=Q サイトはhttp:/XXXX/YYYY と判断・http:/XXXX/ZZ?QQ=Q サイトはhttp:/XXXX/ と判断・http:/XXXX/YYYY/SS?QQ=Q サイトはhttp:/XXXX/YYYY と判断要はサイトのURLは最大で第一パス区切りまでというルールサイトのは最大で第一パス区切りまでというパス区切りまでというルール (ブログやホスティングサイトを想定すると、それなりにうまくいく)

タグごとのサイト集計タグごとのサイト集計3 ごとのサイト前のスライドの説明で示したように、かなり適当サイトURLの判断を誤った場合のためにリカバー用リンク(抽出したサイトURLとタグ名を用いてGoogleとはてブで検索) を設置最悪、ユーザがサイトの最悪、ユーザがサイトのURLを見つけられるをでも、やっぱりもっとちゃんとした手法で対応するのがベスト・ソーシャルな枠組みでページURLとサイトURLの対応付けをして、その結果をウェブAPIで提供してくれる人とかいないかな・・・

システム構成システム構成クローリング、集計、ページ生成の全てをRubyスクリプトで行う ≠ CGI ページ自体はRubyスクリプトで生成した静的なもの (動的にディレクトリをアップデートしていければベストだけど)

よくできました

[はてな]タグのページタグのサイトURLの抽出に失敗してるこんな時のためのリカバー用リンク

リカバー用リカバー用リンク(はてブ)の結果はてブ

リカバー用リカバー用リンク(Google) の結果

Kookleの展望 4つのサービスの中では一番有望(だと思っている) が、ディレクトリ構造の構成がかなりヘッポコ・トップに[社会]や[教育]があるのはいいが、[はてな]や[これはひどい] もあるのはおかしいディレクトリを構成する手法のディレクトリを構成する手法の改善する手法・シソーラス(語彙分類表)を手に入れて、それとマッチするように構成？・Yahooのディレクトリ構造をベースに構成する？・階層的クラスタリング？・Intersection rateを使うとうまくいくらしい (http://d.hatena.ne.jp/Makots/20080118#tagHierarchy)

個人による高性能データマイニングの可能性個人による高性能データマイニングのによる高性能データマイニング専用プロセッサによる高性能・近年、PS3に搭載されたCellプロセッサや、グラフィックカード(GPU:Graphic Processor Unit)などの非汎用プロセッサを用いて高性能計算を行う試みがなされている・CellプロセッサやGPUでは汎用的な処理は難しいが、ベクトル化(複数のデータを同時に処理)できるような処理であれば極めて高い性能を発揮できるデータマイニングはばっちり(のはず)

CellやGPUの性能 CellやGPUの数万円で手に入るのに速い PS3のCellプロセッサで218GFlops (Core2 2.8GHzの約15倍) GPUで数百～千数百 GFlops (数十倍～百倍) の性能が理論的には理論的にはある理論的には実アプリケーションにおいて理論的な性能に比例する効用が得られるとは限らないが、それでもうまくすれば普通のPC10台～2-30台ぐらいの性能は達成できそう (ただし特殊なプログラミングが必要になるのでコーディングは大変) 個人でも頑張れば結構な規模のデータマイニングができるのでは？

“このサービスはPS3で動いていますこのサービスはこのサービスでいています” とか書いてあったらとか書いてあったらCoolじゃないですか？じゃないですか？じゃないですか

Future of SBM 正直よくわからないただなんとなく、人と人の関係をもっとうまく使う事が必要なのではないかと思う Ex) ・はてブのお気に入り機能をもっとうまく生かすようなもの・・・・とか？マイニングももっと進んでいくだろう企業がやるとした時に、必要な計算処理を提供するためのコストはペイするの？ 2008年7月12日 SBM研究会 78

まとめ 4つのサービスの開発について説明した・Kikker、はてブおせっかい、はてブまわりのひと、Kookle ・概要や工夫した点、展望について述べた・同じようなものを作るための情報は網羅したつもり・SBMのデータマイニングは楽しい個人によるデータマイニングとSBMについての展望を述べたみんなもSBMのデータをいじって遊ぼう! 2008年7月12日 SBM研究会 80

私がチャレンジしたSBMデータマイニング

by Hiroshi Ono on Nov 02, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 20

Statistics

私がチャレンジしたSBMデータマイニング — Presentation Transcript

http://www.slideshare.net	19
http://webcache.googleusercontent.com	1