それは、いわゆるユーザーIDが、ユーザーページのURLに含まれたり、お互いを呼び合うための名前というソーシャルな使われ方をするからだと思います。メールアドレスが誰でも見られるURLの一部に入るのはさすがにまずいです。また、英数字だけというよくある制限も、URLに含めるのに都合がいいという面があるのでしょう。

ユーザーIDには、アイデンティティーという心理的な意味もあります。IDをユーザー本人が設定し、システム上それを変更できない場合、ユーザーにはその名前に対する強い責任が生まれます。匿名の是非論争というのはネット上でしばしば起こりますが、是非はともあれ、建設的な言論を求めるユーザーは、IDの考え方がしっかりしたサイトを好む傾向があるように思います。（例えばはてな。）

しかし、アイデンティティーは置いておいて、個人の利便性だけを考えたとき、サービス全体で重複のないIDをユーザー本人が登録しなければいけないというのは、面倒なものです。ちょっと気の利いたサイトでは、入力した文字が使用可能なIDかどうか簡単にチェックできるボタンなどが用意されていますが、使いたかったIDがもう他の人に取られていることもよくあります。そうすると別のIDを考える必要があります。あまり色々なIDをつけていると、どのサービスでどのIDを使っていたか忘れてしまいます。

他方、URLなどに含まれる文字列は、ユーザー登録とは関係なく設定できるというサイトもあります。これは利便性と社会性を切り分けた設計だと思います。そうした設計の有名サイトの中では、例えばFlickrは一度URLを決めてしまうと変更できませんが、Tumblrは何度でも変更できます。そういう細かい違いもあります。

データベース上のIDとしては、ただの連番を振るのが基本ですから、連番IDをURLに使うこともできます。mixiではそうなっています。ライトユーザーが意識することはあまりありませんが、プロフィールページなどのURLに現れている数字が連番IDです。ログインの時は、メールアドレスとパスワードを使いますね。ユーザー同士で呼び合う時は、ニックネームや本名を使っていると思います。

mixiは招待制のSNSなので、外部サイトから直にプロフィールページを参照するということをあまり想定しないのでしょうし、URLの意味をあまり考えないライトなユーザーが多いようですから、IDをユーザー本人につけてもらうよりは連番のほうが確かに合っている気がします。

結局のところ、運営者側がサイトの性格をどう考えているか、ユーザーにどのように行動して欲しいかによって、ユーザーIDの扱いは変わってくるのだと思います。当たり前の話ばかりかもしれませんが、ちょっと自分の頭を整理してみました。

最後に、利便性だけを言うなら、そもそもIDやバスワードを使ってログインするのが面倒だと感じる人も多いようです。それもある意味まっとうな感覚だと思います。セキュリティ上のリスクは増しますが、多くのサイトがログイン状態を長く保つオプションを用意しています。複数のサイトで共通に使えるOpenIDの採用も進んでいます。しかし、安全で便利なWebというものの共通認識ができるのは、もう少し先になるでしょうか。このあたりの感覚は本当にサイトやユーザー層によってまちまちですね。

前回と同じように、式ではなく文章で振り返ります。はさみマークの部分は飛ばしています。

13章の残り

テキスト分類の評価方法について。テキストのそれぞれを、ゼロ個以上複数のクラスに分類する場合、「A or not A」、「B or not B」・・・という分類器をたくさん用意して、クラスごとに調べていくのが標準的なアプローチになります。これらの分類器の性能テストをまとめて評価したい場合、MicroaveragingとMacroaveragingという集計方法があります。

まずテストした個々の事例について考えると、クラスに該当する場合の正解、クラスに該当しない場合の正解、それぞれの不正解という四つのケースがあります。Microaveragingは、テスト全体からこれらの各事例の数を足してしまって、正答の割合を評価するという、ざっくりとした評価方法です。

これだと事例の多いクラスの結果が大勢を占めてしまうので、Macroaveragingでは、クラスごとに割合を評価し、それらを平均します。

たつをさんも仰っていたのですが、ざっくりとしたのがMicroで、分けて見るのがMacroという、直感と反対の憶えにくい名前です。Microは一つ一つの事例が等しい重さになるのでMicro、と考えればいいみたいです。

14章

この章では、テキスト分類の別の手法として、文書をベクトルとして表現し、文書間の類似度を距離として計算する分類方法が解説されています。文書をベクトルとして表現するところは、以前の章で出てきたベクトル空間モデルによる検索と同じです。

ベクトル表現

文書のベクトル表現について簡単に振り返っておくと、まず文書は単語の集まりと考えます。ある単語がその文書に入っていた数（TF）を、単語の種類分並べると、文書を表すベクトル＝文書ベクトルになります。全体の中での特徴を数値に反映するために、全文書の数を、単語が入っていた文書数で割った数字（IDF）を、TFと掛けたりします。IDFは対数にしたりして調整しますが、これをTF-IDFという名前でよく使います。

さて、ベクトルを使った分類には、Contiguity hypothesisという基本前提があるそうです。これは、同じクラスの文書はN次元のグラフのなかで連続した領域にあり、また、異なるクラスの領域は重ならない、という仮説です。これを使う場合は、例えば飛び飛びになっているような分布は対象にしないということになります。 

ベクトルを使った分類方法として、Rocchio分類法とkNNが紹介されています。

Rocchio分類法

言葉で書くとすごく簡単です。まず学習の時に、クラスごとに、そのクラスに含まれる文書ベクトルの重心を計算します。単純に平均をとるということでOKです。

新しい文書を分類する時は、その文書のベクトルと、各クラスの重心ベクトルとの距離を計算します。そしてもっとも近いクラスを採用します。

Rocchioの欠点は歪んだ分布に対応できないことです。 Rocchioの場合、各クラスは大体同じくらいのばらつきで文書が分布していることになりますので、文書が広く分布したクラスというものに対応できません。

kNN（K近傍法）

kNNは、新しい文書を分類する時に、距離的に近くにあるトレーニング文書を探して、それらの文書のクラスを採用するという方法です。

近くにある文書は仲間だろう、という、直感的なアプローチな気がします。さすがに一つだけ調べるのは不安なので、K個の近い文書を見つけて、多数決で決めたりします。 考え方は単純ですが、結構うまく行くケースが多いみたいです。

Rocchioはリニアな分類器ですが、kNNはノンリニアな分類器です。二次元でいうと、一本の直線で図面を二分割するのがリニアな分類器です。kNNは歪んだ分布にも対応することができます。

今回はinspectモジュールのソースコードを読みました。inspectは、Pythonのオブジェクトからソースコードを調べたり、関数の引数を取り出したりできるモジュールです。普段使うことはあまりないですが、開発環境の整備などに使えるのではないかと思っています。例えばチームのコーディング規約に違反していないかを自動的にチェックするようなことができるのではないでしょうか。

ソースコードには、目立ったコーディングテクニックはないのですが、Pythonオブジェクトの内部構造にアクセスするコードが延々と出てくる感じで、それを一つ一つ例を交えながら解説された田村さんは大変だったと思います。勉強になりました。

 その後は、参加した半数以上の人が、近くのちゃんこ料理屋さんで親交を深めました。

Bloombla

Twitterライクなミニブログサービスです。

“What have you done?”という質問に答えて、”I’ve — – –”という定型文を入力します。

他の人の書き込みを見ていて、これは自分もやった！という書き込みがあれば、Done it!というボタンをクリックします。

同じことをした人たちはまとめて表示されます。一字一句同じになるので、日本語で同じことをすると堅い表現になってしまいそうですが、英語だと成り立つのでしょう。

それから、やったことに対してストーリーを書くことができます。同じ行動でもいろんな背景があることが見えるという狙いですね。

見た感じストーリー機能はあまり活用されていないようなので残念ですが、「それってどういうこと？」と聞きたくなるような短いひとことから、世界を広げていこうというアイデアは面白いと思います。

thesixtyone

thesixtyoneは、ミュージシャン、リスナー双方向のコミュニティサイトです。ミュージシャンが各ジャンルに曲を登録します。各画面にプレイリストがあり、再生を始めると、サイト内の他のページに移動しても、プレイリストを聴き続けられるようになっています。リスナーは、他のことをしながら次々に音楽を聴けるので便利です。

ポイントとレベル

このサイトでは、ログインして音楽を聴いたりすると、リスナーにポイントがたまっていくようになっています。ユーザのアクション履歴をポイントとして可視化しているのです。ポイントがたまるとレベルが上がり、レベルが上がるとサイトで色々なことができるようになります。

このようにしてリピータを増やす手法はアメリカなどのサイトではよく目にします。ポイントのことをカルマと呼んでいる場合もあります。日本のサイトでも裏側では同じようなことをしているケースもあるのでしょうけれど、こういったポイントを明示しているサイトはあまりないと思います。文化の違いでしょうか。

アクションの種類によっては、ポイントがたまるだけでなく、ユーザに”disk jockey”や”groupie”といったマークがつきます。それを見れば、その人がそのサイトでどのようなことをしてきたかが分かるようになっています。

ミュージシャンは、自分の曲が多く聴かれることでポイントがたまっていき、レベルが上がるとアップロードできる曲が多くなります。

ミュージシャンへの評価

ポイントがたまるとリスナーは色々なことができます。このサイトで一番大きな役割を持っているのはbumpという操作です。これは自分が気に入った曲に投票をすることで、それによって曲をランキング上位に押し出すことができます。

その曲をbumpした人がまだ少ない時は、bumpするのにたくさんのポイントが必要です。しかし、bumpした曲が、その後で他のユーザにたくさんbumpされれば、先にbumpした人はポイントを獲得することができます。

これは現実に即したうまい仕組みだと思います。というのは、新しい良い曲を発掘したリスナーが評価されると同時に、情報の固定化を防げるからです。

Webサイトにランキングはつきものですが、どうしてもたくさんの人の目に触れる上位が固定化しがちです。そのため多くのサイトでは、古い情報は消えていくようにしています。これをユーザの行動によって回避できるというのは面白いです。ミュージシャン側でも新規参入のモチベーションになりますね。

リスナー同士の評判

リスナーは気に入った曲を集めてプレイリストにすることができますが、他のリスナーがこれを再生すると、プレイリスト作者にポイントが入ります。ユーザが他のリスナーにあえて点数をつける必要がないのがうまいと思います。

リスナーは気に入ったリスナーがいれば購読することができます。自分のホーム画面では、購読したリスナーが何を聴いているかを一覧表示できます。

レベルの高いリスナーは、Leaderというページにランキング表示されますので、この辺りから探すと良いのでしょう。

自分の趣味に合うリスナーを探す仕組みがもう少しあればもっと楽しくなると思うのですが。

まとめ

まとまりなく要素を挙げてきましたが、ミュージシャンへの評価とリスナーの評価が結びついているところがうまいと思いました。