佐々木 祥さん, 上村 理さんの講演

SBM研究会

情報爆発の時代においてはユーザのニーズに合わせた情報発見のためのシステムとして，リコメンデーションの必要性は高まっている。しかしながら参加ユーザ数の増加，嗜好の多様化により，リコメンデーションに必要となる計算量は莫大となっている。
この問題に対し，計算処理の分散方法が各種提案されているが，これらの方法は複数の計算機を使い処理を行うため経済的側面や環境的側面から見ても「エコ」ではない。そこで，推薦の精度を保ちつつ，計算量削減を実現する方法を検討する。


以下は私のメモです。

  • 佐々木さんの講演
    • １サイトにBMするだけではなく、２つのサイト間の関係としてBMするのも良い。
      • graphのlink構造を明示的に取ることはより効果的ということでしょうね。
    • CF(Collaborative Filtering)のお話
      • scaleしない
      • 分散処理もいいがアルゴリズム的な解決を考える
      • user to uesrやitem to itemの関係を出す元データを代表的、典型的なユーザだけに絞るなど簡単に取って、多少精度は落としてもreasonableな算出をする。よくありがちな方法
        • 典型的user/itemはサービスに依存する。つまり要チューニング
      • もっともprimitiveな方法。逃げの方法。非ゼロ考慮など、大規模系の力技はエコではないし、PFIさんにお任せということかな？
  • 上村（かみむら）さんの講演
    • 3R（本講演の焦点はRecycle?）
      • Reduce
        • 計算量の削減
        • 次元圧縮のようなことみたい
      • Reuse
        • cacheのこと
        • 計算結果の再利用
      • Recycle
        • profileの構造化
        • 解析を入れるということかな？
    • 提案Algorithm
      • まずNormalized Cut
        • リンクの弱いものから落としていって、componentに分割されるとそれをtreeの分岐とする。最小スパニングツリーのKruskal Algorithmの逆みたいな話
        • greedy algorithm過ぎるのでは？
      • 汎用性を出すためにprofile選択木の登場のようだが、とりあえずの方法かも？他の方法ではなくこの方法にする必然性は不明。
      • その後に何ホップ以内など近いもののプロファイルから
      • まあ結果はでるでしょうと思ったが予想外に、それほど良い結果は出ていないみたい
    • Anti-Folksonomy
  • Q&A
    • はてなのデータセット使ったのはなぜ（チームラボの高須さん）
      • すぐ使えたから
    • 解析データ数が少ないのが、結果が良くなかった原因かと予想されているが、数が増えれば計算量や精度の面では良いのか？
      • 精度は今のアルゴリズムでは確信はない
      • 計算量はそうなると思う。
    • f-measureを詳しくない人に説明して
      • かなり分かりにくい回答している、、、
      • 具体例を出した方が分かりやすいと思う。
        • 火事と火災警報器でいえば、火事が起こった時に火災警報器が鳴る確率と、火災警報器が鳴った時に火事が起こっていないエラー率が、ともにかなえるようにした(max-min)評価値。
    • SBMがはやるには
      • SBM listにすると広まるのではないかと思っている