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


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

         筑波大学大学院システム情報工学研究科M1
         神林 亮
まずは自己紹介から




2008年7月12日 SBM研究会      2
自己紹介(1)

      筑波大の
      筑波大のM1の学生
      専門は
      専門はHPC
   ・クラスタコンピューティング
   ・スーパーコンピュータ
   ・グリッドコンピューティング
      テーマの例
...
自己紹介(2)

      物作りが大好き
      物作りが大好き
        りが大好
   ・いろいろ作った
    いろいろ作
    最近だとひらめいった
       だとひらめいったー
   ・最近だとひらめいったーとか
...
自己紹介(3) with はてブ
                はてブ

      主に使うSBMははてブ

      ブログのブクマ数 = 794
      サービスの置いてあるアドレスのブクマ数 = 736
      合計 = 1...
2008年7月12日 SBM研究会   6
2008年7月12日 SBM研究会   7
やっと自己紹介が終わりまして
                    やっと自己紹介が
                       自己紹介
                    方針の説明を
                    方針の...
発表の方針
   発表の


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



      ...
アジェンダ

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




2008年7月12日 SBM研究会     11
開発に至った経緯
   開発に った経緯

    Ceekz氏がはてブニュースとい
    うサービスを作った
    ベイズ推定によってはてブの
    ホッテントリを自動分類
    これはすばらしいものだ!
    しかし、並びかえただ...
2008年7月12日 SBM研究会   13
アジェンダ

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

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




2008年7月12日 SBM研究会   15
全体動作

  0. Kikkerがはてブをクロールして各ページの情報を集める(常に)
  1.ユーザ登録
    1.1 はてなのアカウントを設定
    1.2 自身の興味のあるキーワードを重みとともに登録
  2.ユーザがKikkerにア...
評価値の計算方法
   評価値の

      アルゴリズム
   ・ベクトル計算
   ・ページ内容のベクトルとユーザの趣向のベクトルの角度(距離)を計算
   ・得られた値はすなわち評価値.対象のページが対象の
    得られた値はすなわち...
まずはページの内容を表現するベクトルの求め方
         (ユーザの趣向についてのベクトルはその後で)




2008年7月12日 SBM研究会   18
ページの内容を表現するベクトル
   ページの内容を表現するベクトル
            する

     ページ内の各単語ごとの重み
    ・意味は見ていない
    Ex)[SBM,web,ajax]=[10,10,40]
     ...
形態素解析

      対象言語の文法の知識(文法のルールの集まり)や辞書
      (品詞等の情報付きの単語リスト)を情報源として用い、
      自然言語で書かれた文を形態素(Morpheme, おおまか
      にいえば、言語で...
TF-IDF

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

    ある単語iのドキュメントjの中での重みを求めたい
   計算するために必要な情報
  ・TF:対象ドキュメント中の対象単語の出現数
  (文書長で割って正規化する場合もある)
  ・...
今度はユーザの趣向を表現するベクトルの求め方




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

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

 ・はてブでブクマしたページから学習
  (ユーザ...
材料が揃ったので評価値を計算




2008年7月12日 SBM研究会   24
ベクトル間の角度(距離)の計算
   ベクトル間

     計算方法
   ・式に2つのベクトルをつっこんでやる
   ・下の式のSc
         Scがすなわち評価値で、あるページがあるユーザに
         Sc
     どれ...
全体動作

  0. Kikkerがはてブをクロールして各ページの情報を集める(常に)
  1.ユーザ登録
    1.1 はてなのアカウントを設定
    1.2 自身の興味のあるキーワードを重みとともに登録
  2.ユーザがKikkerにア...
学習の仕組み
   学習の仕組み

     ユーザが推薦されたページを見るたびに学習
    ・ユーザが見たページのベクトルをそのユーザの趣向ベクトル
     に足しこむ
     ユーザがお勧めされたページのうちのどれを実際に見たか
  ...
システム構成
システム構成


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

 クローリング、
 クローリング、計算処理       Java + Crossfire...
よくできました




2008年7月12日 SBM研究会     29
2008年7月12日 SBM研究会   30
ひとまず出来上がったけど
   ひとまず出来上がったけど
       出来上



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

      ただ、ページ情報のクロールが重すぎ
      Yahooに異様な数のクエリを投げている...
クエリを減らす工夫
   クエリを らす工夫

   文章中の全てのキーワードをYahooに検索かけるのは無理
  ・bulkfeedsのキーワード抽出APIで間引きをする
          クエリの数はかなり減らせた
  重みの情報も取れれ...
よりよい精度を求めて
よりよい精度を
    精度
 推薦の精度はあまり高くない気がする
・キーワード抽出の精度が低い?
・タグやキーワードが分散し過ぎていてベクトルによる類似度計算がうまくいっていな
 い


         Future ...
実は・・・

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


 簡単なところから始...
そんな事
       そんな事はどうでもいいですよね




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

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

   ・ユーザ登録不...
コラボレィティブフィルタ

                p1         p2        p3         p4         p5        p6         p7

     Bob                ...
式
 Mixがドキュメントxがユーザiにどれだけお薦めかの値
 Mixが0.5以上なら推薦、0.5以下なら推薦しない
 (はてブおせっかいでは閾値をいじったけど)
 MiはMixのXに関する平均
 Cijはユーザiとユーザjの相関係数。一つ前の...
システム構成
システム構成




     Kikkerと同様
余談: 労力のお話
    労力のお
      のお話

  システムの大部分はKikkerと共通であったため、新たに実
  装したのは計算アルゴリズムのところだけ

  そんなわけで実装は一日で終了



実装で大変なのはクローリングやらD...
ひとまず出来上がったけど
   ひとまず出来上がったけど
       出来上

      計算処理が重すぎてユーザがイライラ
     ・Kikkerでは転置インデックスを作ることで全てのページに
      対して計算を試行することは避け...
アジェンダ

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

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

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

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



2008年7月...
http://www.coins.tsukuba.ac.jp/~i041184/distribute/
hatebu_mawarinohito/hatebu_mawarinohito.html

で遊べます。
  べます。
クラスタリング

・ソーシャルブックマークサービスを利用した情報リコメンデーション
 [白土ら ’06]
を参考に実装。ただ、この論文だけだとクラスタリングの処理を実装で
きなかったのでリファーされていた論文も読んだ。


・Finding l...
クラスタリングアルゴリズム
前提:ユーザ間の接続関係を表現したグラフがある

下準備1: 空の集合Aと全ユーザを含む集合Uを用意する
下準備2: 集合Aに起点となるユーザ(まわりのひとを発見したい人)を追加

・以下の繰り返しステップを集合A内...
システム構成
システム構成



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

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

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

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

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




2008年7月12日 SBM研...
Kookleを作ろうと思った経緯
        ろうと思った経緯

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

 ディレクトリでのファイル管理をタグに置き換えることは簡単
 そうだ (デ...
ディレクトリは本当にできる?
ディレクトリは本当にできる?
         にできる

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

これはディレクトリでの親...
では実装について




2008年7月12日 SBM研究会      53
やらなければいけない事
やらなければいけない事

 ディレクトリを作って、それをさらにウェブディレクトリサービス
 に仕立てるには以下の2つのことをしなければならない



1: タグの共起頻度からディレクトリ構造を構成
2: 各タグについて、...
共起頻度
  あるタグとあるタグがどれだけ同時に利用されたか
  全タグ x 全タグのテーブルを作ればよい
 ・ほとんどの箇所に値がない疎なテーブル
 ・ハッシュを使えば空間効率がよい

  クローリング時に集計
Ex)[web][ajax][...
1: タグの共起頻度からディレクトリ構造を構成
アルゴリズムを考える
 アルゴリズムを

 仮定1
 大分類のタグは中・小分類のタグよりたくさん使われている




タグ数



      大分類   中分類   小分類
アルゴリズムを考える
アルゴリズムを

 仮定2
                                  ○共起頻度の関数
関連するタグの共起頻度は高い
                                   co-o...
これらの仮定を
これらの仮定を踏まえまして
    仮定
ヒューリスティクスによる簡易なディレクトリ構成アルゴリズム


WIDTH: ひとつの階層に含まれるタグの数を表現する定数

ステップ1
ステップ1
 タグを総出現数に従ってソートして一列に並べる
ステップ2
ステップ2
 ステップ1のタグ列を...
アルゴリズムの図示1
  アルゴリズムの

      ステップ1:ソート
      ステップ ソート          ステップ2:分割
                        ステップ 分割


      WIDTH   WID...
アルゴリズムの図示2
アルゴリズムの
ステップ4:ツリーの
ステップ ツリーの出力
      ツリー                 ※小分類以降は図示省略



            Root


     Blog   SNS    A...
2: 各タグについて、それが多く使われているサイトを集計
タグごとのサイト集計1
タグごとのサイト集計
  ごとのサイト

 各タグのページにはそのタグが多くつけられたサイト
                      サイトを列挙したい
                      サイト

    ...
タグごとのサイト集計2
タグごとのサイト集計
  ごとのサイト

 感覚的なルールに基づいて判断
・http:/XXXX/YYYY/ZZZZ/SS?QQ=Q
       サイトはhttp:/XXXX/YYYY と判断
・http:/XXXX/...
タグごとのサイト集計
タグごとのサイト集計3
  ごとのサイト

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

 サイトURLの判断を誤った場合のためにリカバー用リンク(抽出し
 たサイトURLとタグ名を用いてGoogleとはてブで検索) ...
システム構成
システム構成



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



      サイトURLの抽出
       に失敗してる


        こんな時のための
        リカバー用リンク
リカバー用
リカバー用リンク(はてブ)の結果
         はてブ
リカバー用
リカバー用リンク(Google) の結果
Kookleの展望
 4つのサービスの中では一番有望(だと思っている)

 が、ディレクトリ構造の構成がかなりヘッポコ
・トップに[社会]や[教育]があるのはいいが、[はてな]や[これはひどい]
 もあるのはおかしい

 ディレクトリを構成する...
アジェンダ

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

 専用プロセッサによる高性能
・近年、PS3に搭載されたCellプロセッサや、グラフィックカード(GPU:Graphic
Proc...
CellやGPUの性能
CellやGPUの

数万円で手に入るのに速い
 PS3のCellプロセッサで218GFlops (Core2 2.8GHzの約15倍)
 GPUで数百~千数百 GFlops (数十倍~百倍)
        の性能が理...
“このサービスはPS3で動いています
 このサービスは
 このサービス    で いています”
とか書いてあったら
とか書いてあったらCoolじゃないですか?
             じゃないですか?
             じゃないですか
アジェンダ

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

     正直よくわからない
     ただなんとなく、人と人の関係をもっとうまく使う事が必要なの
     ではないかと思う
   Ex)
    ・ はてブのお気に入り機能をもっとうまく生かすようなもの
   ...
アジェンダ
     各SBM関連のサービス開発記
   ・開発を始めた経緯
   ・Kikker
   ・はてブおせっかい
   ・はてブまわりのひと
   ・Kookle
     個人による高性能データマイニングの可能性
     Fut...
まとめ

      4つのサービスの開発について説明した
     ・Kikker、はてブおせっかい、はてブまわりのひと、Kookle
     ・概要や工夫した点、展望について述べた
     ・同じようなものを作るための情報は網羅したつも...
Upcoming SlideShare
Loading in …5
×

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

4,976 views

Published on

Published in: Technology, News & Politics
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,976
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
20
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

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

  1. 1. 私がチャレンジしたSBMデータマイニング 7月12日 SBM研究会@東工大 筑波大学大学院システム情報工学研究科M1 神林 亮
  2. 2. まずは自己紹介から 2008年7月12日 SBM研究会 2
  3. 3. 自己紹介(1) 筑波大の 筑波大のM1の学生 専門は 専門はHPC ・クラスタコンピューティング ・スーパーコンピュータ ・グリッドコンピューティング テーマの例 ・簡便にボランティアコンピューティングを実現するためのフレームワーク ・仮想マシンを用いた分散システムの耐故障性評価環境 etc…… 2008年7月12日 SBM研究会 3
  4. 4. 自己紹介(2) 物作りが大好き 物作りが大好き りが大好 ・いろいろ作った いろいろ作 最近だとひらめいった だとひらめいったー ・最近だとひらめいったーとか 学部3 (2年前 年前) ・学部3年(2年前)の時に SBMにハマる SBMにハマる 今回の 今回の話 2008年7月12日 SBM研究会 4
  5. 5. 自己紹介(3) with はてブ はてブ 主に使うSBMははてブ ブログのブクマ数 = 794 サービスの置いてあるアドレスのブクマ数 = 736 合計 = 1530 余談: みなさんはどれぐらいブクマされてます? 2008年7月12日 SBM研究会 5
  6. 6. 2008年7月12日 SBM研究会 6
  7. 7. 2008年7月12日 SBM研究会 7
  8. 8. やっと自己紹介が終わりまして やっと自己紹介が 自己紹介 方針の説明を 方針の説明をば 2008年7月12日 SBM研究会 8
  9. 9. 発表の方針 発表の SBMデータマイニングサービス開発体験記 ・別に、深い洞察があるわけではないです^^; ・泥臭い話をしようかと思います ・誰でもできると伝えたい 俺の屍を越えて行け!! 2008年7月12日 SBM研究会 9
  10. 10. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 10
  11. 11. やっと肝心の やっと肝心の話が始まります 肝心 2008年7月12日 SBM研究会 11
  12. 12. 開発に至った経緯 開発に った経緯 Ceekz氏がはてブニュースとい うサービスを作った ベイズ推定によってはてブの ホッテントリを自動分類 これはすばらしいものだ! しかし、並びかえただけでフィル タリングとかをしているわけじゃ ない 情報収集の手間はそれほど 変わらない http://labs.ceek.jp/hbnews/ 自分専用のフィルタリングがいい 2008年7月12日 SBM研究会 12
  13. 13. 2008年7月12日 SBM研究会 13
  14. 14. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 14
  15. 15. Kikker 学習するユーザーカスタマイズドなニュースサイト ・ユーザ(はてブの)ごとにページを推薦 ・学習機能付き 2008年7月12日 SBM研究会 15
  16. 16. 全体動作 0. Kikkerがはてブをクロールして各ページの情報を集める(常に) 1.ユーザ登録 1.1 はてなのアカウントを設定 1.2 自身の興味のあるキーワードを重みとともに登録 2.ユーザがKikkerにアクセス 3.Kikkerが各ページについて評価値を計算.評価の高かったN ページをユーザに推薦 4.ユーザが推薦されたページを閲覧すると、Kikkerがそのページ を対象ユーザの趣向であると学習 5. ステップ2に戻る 2008年7月12日 SBM研究会 16
  17. 17. 評価値の計算方法 評価値の アルゴリズム ・ベクトル計算 ・ページ内容のベクトルとユーザの趣向のベクトルの角度(距離)を計算 ・得られた値はすなわち評価値.対象のページが対象の 得られた値はすなわち評価値 対象のページが対象の 評価値. ユーザにどれだけお めかを意味 にどれだけお薦 意味する ユーザにどれだけお薦めかを意味する ユーザの趣向ベクトル ユーザの趣向ベクトル ? ページの内容ベクトル ページの内容ベクトル 2008年7月12日 SBM研究会 17
  18. 18. まずはページの内容を表現するベクトルの求め方 (ユーザの趣向についてのベクトルはその後で) 2008年7月12日 SBM研究会 18
  19. 19. ページの内容を表現するベクトル ページの内容を表現するベクトル する ページ内の各単語ごとの重み ・意味は見ていない Ex)[SBM,web,ajax]=[10,10,40] ベクトルの抽出 1.はてブのキーワードを集める 2.ページの内容を形態素解析して 単語に分解(1のも含む) 3.名詞だけ選択 3.各単語の重みとTF・IDFで決定 4.重みの上位N個と手順1のキーワードで ベクトルを構成 2008年7月12日 SBM研究会 19
  20. 20. 形態素解析 対象言語の文法の知識(文法のルールの集まり)や辞書 (品詞等の情報付きの単語リスト)を情報源として用い、 自然言語で書かれた文を形態素(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
  21. 21. TF-IDF 単語の文章中での重みの指標 ある単語iのドキュメントjの中での重みを求めたい 計算するために必要な情報 ・TF:対象ドキュメント中の対象単語の出現数 (文書長で割って正規化する場合もある) ・N:世界中に存在するテキストの数 ・DF:対象単語を含むドキュメントの数 検索エンジンを使えばオケ ・Yahoo APIを叩く ・ http://nais.to/~yto/clog/2005-10-12-1.htmlを参照 2008年7月12日 SBM研究会 21
  22. 22. 今度はユーザの趣向を表現するベクトルの求め方 2008年7月12日 SBM研究会 22
  23. 23. ユーザの趣向を表現するベクトル ユーザの趣向を表現するベクトル する 各ユーザは自身の趣向を表現したベクトルを持つ ・見たページの趣向を自分に足しこむ ・はてブでブクマしたページから学習 (ユーザ登録時の一回だけ) ・ユーザがKikkerに勧められたページを 閲覧するとKikkerが学習 ・自身でも指定可能 学習の仕方については 後で説明します 2008年7月12日 SBM研究会 23
  24. 24. 材料が揃ったので評価値を計算 2008年7月12日 SBM研究会 24
  25. 25. ベクトル間の角度(距離)の計算 ベクトル間 計算方法 ・式に2つのベクトルをつっこんでやる ・下の式のSc Scがすなわち評価値で、あるページがあるユーザに Sc どれだけお薦めかという値 ・各ページについて求めたら、ソートして上位のものを推薦 2008年7月12日 SBM研究会 25
  26. 26. 全体動作 0. Kikkerがはてブをクロールして各ページの情報を集める(常に) 1.ユーザ登録 1.1 はてなのアカウントを設定 1.2 自身の興味のあるキーワードを重みとともに登録 2.ユーザがKikkerにアクセス 3.Kikkerが各ページについて評価値を計算.評価の高かったN ページをユーザに推薦 4.ユーザが推薦されたページを閲覧すると、Kikkerがそのページ を対象ユーザの趣向であると学習 5. ステップ2に戻る 2008年7月12日 SBM研究会 26
  27. 27. 学習の仕組み 学習の仕組み ユーザが推薦されたページを見るたびに学習 ・ユーザが見たページのベクトルをそのユーザの趣向ベクトル に足しこむ ユーザがお勧めされたページのうちのどれを実際に見たか 知る必要がある ・推薦ページのリストのURLはKikkerのサイトのものにしてお き、ユーザには一回転送することでアクセスさせる 2008年7月12日 SBM研究会 27
  28. 28. システム構成 システム構成 ページ生成、ユーザ管理 ページ生成、ユーザ管理 生成 Ruby on Rails クローリング、 クローリング、計算処理 Java + Crossfire DB DB MySQL OS (CentOS CentOSの もあった) Windows XP (CentOSの時もあった) Ruby部とJava部の間はXML RPCで接続
  29. 29. よくできました 2008年7月12日 SBM研究会 29
  30. 30. 2008年7月12日 SBM研究会 30
  31. 31. ひとまず出来上がったけど ひとまず出来上がったけど 出来上 ベクトルの計算処理は妥当な処理時間で行えた ただ、ページ情報のクロールが重すぎ Yahooに異様な数のクエリを投げているのでバンされるの ではないか・・・・・ 2008年7月12日 SBM研究会 31
  32. 32. クエリを減らす工夫 クエリを らす工夫 文章中の全てのキーワードをYahooに検索かけるのは無理 ・bulkfeedsのキーワード抽出APIで間引きをする クエリの数はかなり減らせた 重みの情報も取れればよかったけど、それはできなかった ・mecabの辞書が持っている生起コストを使う よくわからないけどTF-IDFのIDFと置き換えてOKらしい by ceekz氏 クエリの数を0にできた。わーい。 (参照: http://labs.cybozu.co.jp/blog/kazuho/archives/2006/04/summarize.php) 2008年7月12日 SBM研究会 32
  33. 33. よりよい精度を求めて よりよい精度を 精度 推薦の精度はあまり高くない気がする ・キーワード抽出の精度が低い? ・タグやキーワードが分散し過ぎていてベクトルによる類似度計算がうまくいっていな い Future Work!!!!! 前者の問題を改善する方法 ・少なくともタグの揺らぎはどうにかしたいところ ウェブ?Web?はてなブックマーク?はてブ? 後者の問題を改善する方法 ・潜在的意味インデキシング(Latest Semantic Indexing:LSI)という手法がある ・特徴を表現するのに最適なベクトル空間を見つけて、元の空間からその空間に写像してしまう (ベクト ル空間の圧縮?) ・おおざっぱに言うと、必要最低限のキーワード(元のキーワードに対応しない場合もあるが)だけを使うと いう感じ ・ベクトルの次元も小さくなるので計算量も減らせる
  34. 34. 実は・・・ ここだけの話 ・最初はKikkerのような事をHTTPプロキシを使ってやるつもりだ った ・HTTPプロキシでユーザの通信を解析して趣向を抽出してほ げほげ ・非集中のP2P型にしようとも考えていた 簡単なところから始める意味で 簡単なところから始める意味で今のKikkerを作った なところから 意味 Kikkerを 難しい方は途中でやる気が失せて今に至る
  35. 35. そんな事 そんな事はどうでもいいですよね 2008年7月12日 SBM研究会 35
  36. 36. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Futue of SBM まとめ 2008年7月12日 SBM研究会 36
  37. 37. はてブおせっかい はてブ ・各人のブックマーク履歴を 利用して推薦を行う ・Kikkerと異なりページの 内容の情報は使わない ・アルゴリズムは コラボレイティブフィルタ ・ユーザ登録不要 2008年7月12日 SBM研究会 37
  38. 38. コラボレィティブフィルタ 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
  39. 39. 式 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)
  40. 40. システム構成 システム構成 Kikkerと同様
  41. 41. 余談: 労力のお話 労力のお のお話 システムの大部分はKikkerと共通であったため、新たに実 装したのは計算アルゴリズムのところだけ そんなわけで実装は一日で終了 実装で大変なのはクローリングやらDB周りの処理であって、 推薦のための計算処理自体は大した労力は必要ない (ということはクローリング周りをみんなで共通化できるとうれしいかも)
  42. 42. ひとまず出来上がったけど ひとまず出来上がったけど 出来上 計算処理が重すぎてユーザがイライラ ・Kikkerでは転置インデックスを作ることで全てのページに 対して計算を試行することは避けられていた ・はてブおせっかいはそれはできない 解決策 ・計算処理で利用するユーザとページをどうにかして間引く 仕組みが必要か ユーザに関してはユーザのクラスタリングで対応できない だろうか? 2008年7月12日 SBM研究会 42
  43. 43. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 43
  44. 44. はてブまわりのひと はてブ ・はてブのお気に入り、られを見てクラスタリング ・自分の周りで クネクネしてる のは誰? ・自分はどこらへ んとクネクネして るの? 2008年7月12日 SBM研究会 44
  45. 45. http://www.coins.tsukuba.ac.jp/~i041184/distribute/ hatebu_mawarinohito/hatebu_mawarinohito.html で遊べます。 べます。
  46. 46. クラスタリング ・ソーシャルブックマークサービスを利用した情報リコメンデーション [白土ら ’06] を参考に実装。ただ、この論文だけだとクラスタリングの処理を実装で きなかったのでリファーされていた論文も読んだ。 ・Finding local community structure in networks [Aaron Cluset ‘05] で、実装したのだがクラスタリングの結果がしっくりこなかったので、論 文で説明されていたアルゴリズムのフィーリングの基にオレオレなアル ゴリズムを考えてそれを使用。
  47. 47. クラスタリングアルゴリズム 前提:ユーザ間の接続関係を表現したグラフがある 下準備1: 空の集合Aと全ユーザを含む集合Uを用意する 下準備2: 集合Aに起点となるユーザ(まわりのひとを発見したい人)を追加 ・以下の繰り返しステップを集合A内のユーザ数が一定数を越えるまで行う ステップ: 繰り返しステップ 集合U内で集合A内のユーザからの総被リンク数が大きいものを選択し集合Aに追加 ・結果出力 集合Aを発見したユーザ群として出力 ※全ユーザからの被お気に入り数も考慮しなければ、被お気に入りの多い人間がどうしても 選択されてしまうことになってしまうが、このアルゴリズムはその問題をあえて考慮していない
  48. 48. システム構成 システム構成 Javaアップレット製 クラスタリングの計算処理はアップレットで行う 計算に必要となるデータは事前にRubyで生成してサーバ に置いておき、アップレットは必要に応じてそれをロード
  49. 49. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 49
  50. 50. Kookle ・はてブのタグ情報から生成するウェブディレクトリサービス ・要はSBMのタグから Yahooみたいな ディレクトリを作って みようという試み ・ミソはタグ間の共起頻度 2008年7月12日 SBM研究会 50
  51. 51. Kookleを作ろうと思った経緯 ろうと思った経緯 いくつかのサイトで分類法としてディレクトリによる方法とタ グによる方法の違いが考察されていた ディレクトリでのファイル管理をタグに置き換えることは簡単 そうだ (ディレクトリ -> タグ) ・ディレクトリ名をタグとしてファイルに付けるだけだし・・・ 逆(タグ -> ディレクトリ)はできるかな?
  52. 52. ディレクトリは本当にできる? ディレクトリは本当にできる? にできる タギング時に大分類と小分類をつけることがある気がする ・[web][ajax] ・[neta][非モテ] ・[政治][中国] これはディレクトリでの親と子に他ならない! できそうだ!
  53. 53. では実装について 2008年7月12日 SBM研究会 53
  54. 54. やらなければいけない事 やらなければいけない事 ディレクトリを作って、それをさらにウェブディレクトリサービス に仕立てるには以下の2つのことをしなければならない 1: タグの共起頻度からディレクトリ構造を構成 2: 各タグについて、それが多く使われているサイトを集計
  55. 55. 共起頻度 あるタグとあるタグがどれだけ同時に利用されたか 全タグ x 全タグのテーブルを作ればよい ・ほとんどの箇所に値がない疎なテーブル ・ハッシュを使えば空間効率がよい クローリング時に集計 Ex)[web][ajax][mixi]とタグ付けされたブクマがあったとする table[“web”][“ajax”]++; table[“web”][“mixi”]++; table[“ajax”][“web”]++; table[“ajax”][“mixi”]++; table[“mixi”][“web”]++; table[“mixi”][“ajax”]++;
  56. 56. 1: タグの共起頻度からディレクトリ構造を構成
  57. 57. アルゴリズムを考える アルゴリズムを 仮定1 大分類のタグは中・小分類のタグよりたくさん使われている タグ数 大分類 中分類 小分類
  58. 58. アルゴリズムを考える アルゴリズムを 仮定2 ○共起頻度の関数 関連するタグの共起頻度は高い co-occur (tag1,tag2) Co-occur(web,sns) Web 政治 is high. SNS Blog スキャンダル 外交 Co-occur(政治,外交) is high. 上のような構造があるとすれ のような構造があるとすれ 構造 Co-occur(web,外交) is low. のように観測 観測されるはず ば右のように観測されるはず
  59. 59. これらの仮定を これらの仮定を踏まえまして 仮定
  60. 60. ヒューリスティクスによる簡易なディレクトリ構成アルゴリズム WIDTH: ひとつの階層に含まれるタグの数を表現する定数 ステップ1 ステップ1 タグを総出現数に従ってソートして一列に並べる ステップ2 ステップ2 ステップ1のタグ列を出現数の高い方からWIDTH, WIDTH ^2, WIDTH ^3・・・・ という間隔で区切り、それぞれ階層1,2,・・・・とする ステップ3 ステップ3 階層nに含まれる各タグについて,階層(n-1)に含まれるタグの中から最も 共起頻度の高いものを選びそれに所属させる ステップ4 ステップ4 ステップ3で作成した関係をツリーとして出力する
  61. 61. アルゴリズムの図示1 アルゴリズムの ステップ1:ソート ステップ ソート ステップ2:分割 ステップ 分割 WIDTH WIDTH^2 WIDTH^3 タグ数 ステップ3:親 ステップ 親の決定 ※図では一部の接続のみ表示 では一部 接続のみ 一部の のみ表示
  62. 62. アルゴリズムの図示2 アルゴリズムの ステップ4:ツリーの ステップ ツリーの出力 ツリー ※小分類以降は図示省略 Root Blog SNS Ajax 大分類 中分類 小分類
  63. 63. 2: 各タグについて、それが多く使われているサイトを集計
  64. 64. タグごとのサイト集計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 かな?
  65. 65. タグごとのサイト集計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は最大で第一パス区切りまでというルール サイトの は最大で第一パス区切りまでという パス区切りまでというルール (ブログやホスティングサイトを想定すると、それなりにうまくいく)
  66. 66. タグごとのサイト集計 タグごとのサイト集計3 ごとのサイト 前のスライドの説明で示したように、かなり適当 サイトURLの判断を誤った場合のためにリカバー用リンク(抽出し たサイトURLとタグ名を用いてGoogleとはてブで検索) を設置 最悪、ユーザがサイトの 最悪、ユーザがサイトのURLを見つけられる を でも、やっぱりもっとちゃんとした手法で対応するのがベスト ・ソーシャルな枠組みでページURLとサイトURLの対応付けをして、そ の結果をウェブAPIで提供してくれる人とかいないかな・・・
  67. 67. システム構成 システム構成 クローリング、集計、ページ生成の全てをRubyスクリプトで 行う ≠ CGI ページ自体はRubyスクリプトで生成した静的なもの (動的にディレクトリをアップデートしていければベストだけど)
  68. 68. よくできました
  69. 69. [はてな]タグのページ タグの サイトURLの抽出 に失敗してる こんな時のための リカバー用リンク
  70. 70. リカバー用 リカバー用リンク(はてブ)の結果 はてブ
  71. 71. リカバー用 リカバー用リンク(Google) の結果
  72. 72. Kookleの展望 4つのサービスの中では一番有望(だと思っている) が、ディレクトリ構造の構成がかなりヘッポコ ・トップに[社会]や[教育]があるのはいいが、[はてな]や[これはひどい] もあるのはおかしい ディレクトリを構成する手法の ディレクトリを構成する手法の改善 する手法 ・シソーラス(語彙分類表)を手に入れて、それとマッチするように構成 ? ・Yahooのディレクトリ構造をベースに構成する? ・階層的クラスタリング? ・Intersection rateを使うとうまくいくらしい (http://d.hatena.ne.jp/Makots/20080118#tagHierarchy)
  73. 73. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 73
  74. 74. 個人による高性能データマイニングの可能性 個人による高性能データマイニングの による高性能データマイニング 専用プロセッサによる高性能 ・近年、PS3に搭載されたCellプロセッサや、グラフィックカード(GPU:Graphic Processor Unit)などの非汎用プロセッサを用いて高性能計算を行う試みがなさ れている ・CellプロセッサやGPUでは汎用的な処理は難しいが、ベクトル化(複数のデー タを同時に処理)できるような処理であれば極めて高い性能を発揮できる データマイニングはばっちり(のはず)
  75. 75. CellやGPUの性能 CellやGPUの 数万円で手に入るのに速い PS3のCellプロセッサで218GFlops (Core2 2.8GHzの約15倍) GPUで数百~千数百 GFlops (数十倍~百倍) の性能が理論的には 理論的にはある 理論的には 実アプリケーションにおいて理論的な性能に比例する効用が 得られるとは限らないが、それでもうまくすれば普通のPC10台 ~2-30台ぐらいの性能は達成できそう (ただし特殊なプログラミングが必要になるのでコーディングは大変) 個人でも頑張れば結構な規模のデータ マイニングができるのでは?
  76. 76. “このサービスはPS3で動いています このサービスは このサービス で いています” とか書いてあったら とか書いてあったらCoolじゃないですか? じゃないですか? じゃないですか
  77. 77. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 77
  78. 78. Future of SBM 正直よくわからない ただなんとなく、人と人の関係をもっとうまく使う事が必要なの ではないかと思う Ex) ・ はてブのお気に入り機能をもっとうまく生かすようなもの ・・・・とか? マイニングももっと進んでいくだろう 企業がやるとした時に、必要な計算処理を提供するための コストはペイするの? 2008年7月12日 SBM研究会 78
  79. 79. アジェンダ 各SBM関連のサービス開発記 ・開発を始めた経緯 ・Kikker ・はてブおせっかい ・はてブまわりのひと ・Kookle 個人による高性能データマイニングの可能性 Future of SBM まとめ 2008年7月12日 SBM研究会 79
  80. 80. まとめ 4つのサービスの開発について説明した ・Kikker、はてブおせっかい、はてブまわりのひと、Kookle ・概要や工夫した点、展望について述べた ・同じようなものを作るための情報は網羅したつもり ・SBMのデータマイニングは楽しい 個人によるデータマイニングとSBMについての展望を述べた みんなもSBMのデータを いじって遊ぼう! 2008年7月12日 SBM研究会 80

×