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

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

7月12日 SBM研究会@東工大

筑波大学大学院システム情報工学研究科M1
神林亮

まずは自己紹介から

2008年7月12日 SBM研究会 2

自己紹介(1)

筑波大の
筑波大のM1の学生
専門は
専門はHPC
・クラスタコンピューティング
・スーパーコンピュータ
・グリッドコンピューティング
テーマの例
・簡便にボランティアコンピューティングを実現するためのフレームワーク
・仮想マシンを用いた分散システムの耐故障性評価環境
etc……


自己紹介(2)

物作りが大好き
物作りが大好き
りが大好
・いろいろ作った
いろいろ作
最近だとひらめいった
だとひらめいったー
・最近だとひらめいったーとか

学部3 (2年前
年前)
・学部3年(2年前)の時に
SBMにハマる
SBMにハマる
今回の
今回の話


自己紹介(3) with はてブ
はてブ

主に使うSBMははてブ

ブログのブクマ数 = 794
サービスの置いてあるアドレスのブクマ数 = 736
合計 = 1530

余談: みなさんはどれぐらいブクマされてます？


やっと自己紹介が終わりまして
やっと自己紹介が
自己紹介
方針の説明を
方針の説明をば


発表の方針
発表の

SBMデータマイニングサービス開発体験記
・別に、深い洞察があるわけではないです^^;
・泥臭い話をしようかと思います
・誰でもできると伝えたい

俺の屍を越えて行け!!


アジェンダ

各SBM関連のサービス開発記
・開発を始めた経緯
・Kikker
・はてブおせっかい
・はてブまわりのひと
・Kookle
個人による高性能データマイニングの可能性
Future of SBM
まとめ


やっと肝心の
やっと肝心の話が始まります
肝心


開発に至った経緯
開発にった経緯

Ceekz氏がはてブニュースとい
うサービスを作った
ベイズ推定によってはてブの
ホッテントリを自動分類
これはすばらしいものだ!
しかし、並びかえただけでフィル
タリングとかをしているわけじゃ
ない

情報収集の手間はそれほど
変わらない
http://labs.ceek.jp/hbnews/
自分専用のフィルタリングがいい

アジェンダ

・Kikker
・Kookle
Future of SBM
まとめ


Kikker

学習するユーザーカスタマイズドなニュースサイト
・ユーザ(はてブの)ごとにページを推薦
・学習機能付き


全体動作

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

評価値の計算方法
評価値の

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

？

ページの内容ベクトル
ページの内容ベクトル


まずはページの内容を表現するベクトルの求め方
(ユーザの趣向についてのベクトルはその後で)


ページの内容を表現するベクトル
ページの内容を表現するベクトル
する

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

形態素解析

対象言語の文法の知識（文法のルールの集まり）や辞書
（品詞等の情報付きの単語リスト）を情報源として用い、
自然言語で書かれた文を形態素（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を使用


TF-IDF

単語の文章中での重みの指標

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

今度はユーザの趣向を表現するベクトルの求め方


ユーザの趣向を表現するベクトル
ユーザの趣向を表現するベクトル
する

各ユーザは自身の趣向を表現したベクトルを持つ
・見たページの趣向を自分に足しこむ

・はてブでブクマしたページから学習
(ユーザ登録時の一回だけ)
・ユーザがKikkerに勧められたページを
閲覧するとKikkerが学習
・自身でも指定可能

学習の仕方については
後で説明します

材料が揃ったので評価値を計算


ベクトル間の角度(距離)の計算
ベクトル間

計算方法
・式に2つのベクトルをつっこんでやる
・下の式のSc
Scがすなわち評価値で、あるページがあるユーザに
Sc
どれだけお薦めかという値
・各ページについて求めたら、ソートして上位のものを推薦


全体動作

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

学習の仕組み
学習の仕組み

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


システム構成
システム構成

ページ生成、ユーザ管理
ページ生成、ユーザ管理
生成 Ruby on Rails

クローリング、
クローリング、計算処理 Java + Crossfire DB

DB MySQL

OS (CentOS
CentOSのもあった)
Windows XP (CentOSの時もあった)

Ruby部とJava部の間はXML RPCで接続

よくできました


ひとまず出来上がったけど
出来上

ベクトルの計算処理は妥当な処理時間で行えた

ただ、ページ情報のクロールが重すぎ
Yahooに異様な数のクエリを投げているのでバンされるの
ではないか・・・・・


クエリを減らす工夫
クエリをらす工夫

文章中の全てのキーワードをYahooに検索かけるのは無理
・bulkfeedsのキーワード抽出APIで間引きをする
クエリの数はかなり減らせた
重みの情報も取れればよかったけど、それはできなかった

・mecabの辞書が持っている生起コストを使う
よくわからないけどTF-IDFのIDFと置き換えてＯＫらしい by ceekz氏
クエリの数を0にできた。わーい。
(参照: http://labs.cybozu.co.jp/blog/kazuho/archives/2006/04/summarize.php)


よりよい精度を求めて
よりよい精度を
精度
推薦の精度はあまり高くない気がする
・キーワード抽出の精度が低い？
・タグやキーワードが分散し過ぎていてベクトルによる類似度計算がうまくいっていな
い

Future Work!!!!!
前者の問題を改善する方法
・少なくともタグの揺らぎはどうにかしたいところ
ウェブ？Web?はてなブックマーク？はてブ？

後者の問題を改善する方法
・潜在的意味インデキシング(Latest Semantic Indexing:LSI)という手法がある
・特徴を表現するのに最適なベクトル空間を見つけて、元の空間からその空間に写像してしまう (ベクト
ル空間の圧縮?)
・おおざっぱに言うと、必要最低限のキーワード(元のキーワードに対応しない場合もあるが)だけを使うと
いう感じ
・ベクトルの次元も小さくなるので計算量も減らせる

実は・・・

ここだけの話
・最初はKikkerのような事をHTTPプロキシを使ってやるつもりだ
った
・HTTPプロキシでユーザの通信を解析して趣向を抽出してほ
げほげ
・非集中のP2P型にしようとも考えていた

簡単なところから始める意味で
簡単なところから始める意味で今のKikkerを作った
なところから意味 Kikkerを
難しい方は途中でやる気が失せて今に至る

そんな事
そんな事はどうでもいいですよね


アジェンダ
・Kikker
・Kookle
Futue of SBM
まとめ


はてブおせっかい
はてブ

・各人のブックマーク履歴を
利用して推薦を行う
・Kikkerと異なりページの
内容の情報は使わない
・アルゴリズムは
コラボレイティブフィルタ

・ユーザ登録不要


コラボレィティブフィルタ

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 > 閾値 )


式
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では転置インデックスを作ることで全てのページに
対して計算を試行することは避けられていた
・はてブおせっかいはそれはできない
解決策
・計算処理で利用するユーザとページをどうにかして間引く
仕組みが必要か

ユーザに関してはユーザのクラスタリングで対応できない
だろうか？

アジェンダ

・Kikker
・Kookle
Future of SBM
まとめ


はてブまわりのひと
はてブ

・はてブのお気に入り、られを見てクラスタリング

・自分の周りで
クネクネしてる
のは誰？

・自分はどこらへ
んとクネクネして
るの？


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で生成してサーバ
に置いておき、アップレットは必要に応じてそれをロード

アジェンダ

・Kikker
・Kookle
Future of SBM
まとめ


Kookle

・はてブのタグ情報から生成するウェブディレクトリサービス

・要はSBMのタグから
Yahooみたいな
ディレクトリを作って
みようという試み

・ミソはタグ間の共起頻度


Kookleを作ろうと思った経緯
ろうと思った経緯

いくつかのサイトで分類法としてディレクトリによる方法とタ
グによる方法の違いが考察されていた

ディレクトリでのファイル管理をタグに置き換えることは簡単
そうだ (ディレクトリ -> タグ)
・ディレクトリ名をタグとしてファイルに付けるだけだし・・・

逆(タグ -> ディレクトリ)はできるかな？

ディレクトリは本当にできる？
ディレクトリは本当にできる？
にできる

タギング時に大分類と小分類をつけることがある気がする
・[web][ajax]
・[neta][非モテ]
・[政治][中国]

これはディレクトリでの親と子に他ならない!

できそうだ!

では実装について


やらなければいけない事
やらなければいけない事

ディレクトリを作って、それをさらにウェブディレクトリサービス
に仕立てるには以下の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 かな？

ごとのサイト

感覚的なルールに基づいて判断
・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は最大で第一パス区切りまでというルール
サイトのは最大で第一パス区切りまでという
パス区切りまでというルール
(ブログやホスティングサイトを想定すると、それなりにうまくいく)

ごとのサイト

前のスライドの説明で示したように、かなり適当

サイト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)

アジェンダ

・Kikker
・Kookle
Future of SBM
まとめ


個人による高性能データマイニングの
による高性能データマイニング

専用プロセッサによる高性能
・近年、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じゃないですか？
じゃないですか？
じゃないですか

アジェンダ

・Kikker
・Kookle
Future of SBM
まとめ


Future of SBM

正直よくわからない
ただなんとなく、人と人の関係をもっとうまく使う事が必要なの
ではないかと思う
Ex)
・はてブのお気に入り機能をもっとうまく生かすようなもの
・・・・とか？

マイニングももっと進んでいくだろう
企業がやるとした時に、必要な計算処理を提供するための
コストはペイするの？

アジェンダ
・Kikker
・Kookle
Future of SBM
まとめ


まとめ

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

みんなもSBMのデータを
いじって遊ぼう!

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Más de Hiroshi Ono

Más de Hiroshi Ono (20)

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