from __future__ import nowhere

Users Petition to Save Google Notebook というブログ記事で知りましたが、一部のファンによってGoogleノートブック救済嘆願のための署名が行われているようです。

不況の中、あのGoogleでさえ開発拠点の廃止、採用部門の人員削減など、縮小の動きを見せていますが、先日はいくつかのサービスの停止、開発終了などがアナウンスされました。
その中で、Googleノートブックについては、開発を停止し、新規登録を受け付けないこと、ブラウザの拡張機能は使えなくなることが説明されていました。

それを受けて、ユーザー側に署名などの動きが出ているとのことです。ノートブックはGoogleのサービスの中では比較的地味でシンプルなサービスと言っていいと思いますが、機能が豊富なGoogleドキュメントなどよりも、気軽に使えるノートブックを好む人も少数かもしれないですがいるのでしょう。実は私の妻も愛用していて、育児の記録などをメモしています。

ノートブックにも共有機能があって、例えば私が妻の育児記録を覗いたり追記したりすることはできますが、誰がどう変更したかといった履歴は管理してくれません。ノートブックはどちらかと言えばメモを貯めていくためのツールで、Wikiに代表されるような情報を整理するための場所ではないようです。その辺りで、限定的な用途での個人的なツールとして以外には展開しづらいところがあるのかもしれません。

サービス全体が止まってしまうわけではないのですが、使っている側とすれば、個人的なメモを書き込んできたサービスが見捨てられてしまうというのは悲しいことかもしれません。

11日はIIR輪講の第18回で、範囲は17章の「階層的クラスタリング」でした。場所は今回も百度さんの会議室でした。
担当の杉本さんが事前に超綺麗な和訳文書を作ってくれていました。

16章で扱われたフラットクラスタリングは構造がはっきりとしていないので、アプリケーションによっては不便な場合があります。
階層型クラスタリングは、フラットクラスタリングよりも処理コストが大きいのですが、そのような場合の選択肢になります。

どうやって階層を作るかですが、トップダウン型とボトムアップ型があります。多くボトムアップ型が使われているそうで、ここでもボトムアップ型を中心に解説されています。
ボトムアップ型は階層的凝集クラスタリング（HAC = Hierarchical agglomerative clustering）と呼ばれます。HACでは、まず個々の文書を一つのクラスタと考え、類似したクラスタ同士のマージを繰り返します。

HACのなかでは類似度の計算方法がいくつかあります。

• 単連結 - 最も近い文書同士の距離をクラスタの距離とする
• 完全連結 - 最も遠い文書同士の距離をクラスタの距離とする
• 群平均 - クラスタ間の全文書対の距離を平均し、クラスタの距離とする
• 重心 - クラスタの重心同士の距離をクラスタの距離とする

単連結や完全連結ではクラスタに偏りができる場合があり、重心クラスタリングは性質上扱いづらい部分があるということで、多くのアプリケーションにとっては群平均が最適なアルゴリズムのようです。
HACのアルゴリズムは疑似コードで詳しく紹介されていたので、実践的に使える章だと思います。

他にはフラットクラスタリングを応用しながらトップダウンでクラスタに分解する方法や、特徴語抽出によるクラスタへのラベル付けなどが軽く紹介されていました。

輪講の中では、ただビジュアル化してもつまらないよね、という話も出ました。構造をいかにエンドユーザーのニーズに合うように見せるかというのは、違う頭の使い方をしないといけないですね。

遅くなりましたが2009年一つめの投稿です。今年もよろしくお願いいたします。

昨年は色々と勉強になることがあり、中途半端にしてしまったことも多かった一年でした。今年こそは、日本中、いや世界中の人に愛されるような製品を作りだし、マリーチをブレークさせたいと思います！

今、言うまでもなく世界が劇的な変化を迎えていますが、この大変な年にマリーチという場所で勝負できることを感謝しつつ、またそのおもしろさを味わいながら、日々の仕事に取り組んでいきたいと思います。

さてさて、いきなり小さな話になりますけれども、今までのブログは使いづらいところがあったので、WordPressに入れ替えてこのブログの再スタートを切ることにしました。RSSのURLなどが変わってしまったので、RSSリーダーなどに登録していただいていた方は再登録をお願いします。恐縮です。

以前の画像などが移行しきれていないので、その辺はぼちぼちやっていきます。

今回も用賀のSun Microsystemsさんのセミナールームが会場でした。参加人数は40人弱でしょうか。

今回はこれまでの復習ということで、私も第一回にやったsetsモジュールについてスライドで説明をしました。資料はこちらに置いてあります。

持ち時間が30分だったのですが、もたもたしていて大幅に過ぎてしまい、後のお二方（柴田さん、田村さん）にご迷惑をおかけしました。

すみませんすみません。

復習のあとは二名の方のライトニングトーク（5分ぐらいの発表）で楽しませてもらいました。

標準出力をStringIOですげ替えて手軽に出力を制御するという発表と、Pythonスクリプトを使った業務改善の実例の発表がありました。

ライトニングトーク、いいですね・・・。いつか挑戦してみたいです。

先週後半から39度の熱を出して、今週前半まで寝ていました。皆様体調にはお気をつけください。

最近アメリカでは企業向けのミニブログ（マイクロブログ）がちょっとした脚光を浴びています。今年のTechCrunch50というイベントでは、Yammerというネットサービスが最優秀に選ばれました。その後、対抗馬としてPresent.lyやQikcomといったサービスも現れました。企業向けミニブログというアイデアは昨年からあちこちで言われていたようで、そのための自社製システムを使っていた会社もあるようですが、それが今年一斉に動き出したという感じです。

使い方ですが、基本的には、Twitterと同様に、その時自分がしていることをメモのように書きます。社内のメンバーが皆そのようにすれば、自分の周囲の範囲の人たちが今何をしているかという情報も次々に入ってきます。コメントしたいことがあれば返信することもできます。

企業内で使うための一番重要な機能がグループ機能です。メンバーはミニブログ内で複数のグループに所属します。重要な情報は特定の閉じたグルーブの参加者にしか読めないようなメッセージとして書くことができます。メンバーがグループに分散することで、自分の職務に関係の薄い情報が溢れることもなくなります。

弊社でもYammer、それからPresent.lyを試してみました。それぞれの使用感についてレポートします。

Present.ly

SSLでアクセスするためには有料コースを使う必要があります。ただし60日の無料試用期間があります。

画面はシンプルでとても見やすいデザインです。携帯からのアクセスにも対応しており、iPhoneでもきれいに見ることができました。

ダイレクトメッセージの送信、グループの設定、メッセージのタグづけ、ファイルの添付を行うことができます。

グループ向けメッセージの入力などはメッセージ先頭にコマンドを書くことで行います。この方法はプログラマーなどの技術者向けかもしれません。

Twitter互換のAPIを用意しているそうです。

多言語対応について少々問題があるのが残念です。まずタグは日本語が使えません。それから、一つの投稿あたり140文字まで入るはずですが、日本語では50文字を超えたあたりでエラーになります。おそらく140バイトでチェックしているのではないでしょうか。

Yammer

こちらは一部の管理機能が有料ですが、それを使わない場合は無料です。

グループの設定、タグといった機能があります。ファイルの添付はできません。コマンドを憶える必要がほとんどないので、プログラマー以外でも使いやすいと思います。

iPhoneアプリケーション、デスクトップアプリケーションが用意されています。iPhoneアプリはあまり洗練されたものではありませんが、何度かアップデートがあって使いやすくなってきています。

一つのメッセージはかなり長い文字数で投稿することができます。デフォルト設定では、日本語を入力しようとすると変換を確定した時に投稿されてしまいますが、Settting -> Appearanceに、Enterキーで投稿しない設定にチェックをすれば、日本語も問題なく使えます。タグに日本語を使うことも可能です。

しばらく使ってみて

Present.lyは日本語の扱いに問題があったので、弊社ではYammerを使い続けています。

今までメールというチャンネルからはこぼれ落ちていたような情報を拾い上げ、共有するのに役に立っていると感じています。上司に提出するための日報の代わりに、自主的に活動を記録するものとして使うこともできるでしょうね。ただ、メールの代わりになるものではなく、共存するものだと思います。

メール以外にはSkypeやIMを使ったコミュニケーションもありますが、ミニブログはそれらのような完全なリアルタイムコミュニケーションではありません。非同期に各メンバーが自分の仕事上の関心事を書き込むというスタイルで、また仕事上関心がある相手やグループの発言だけを読むことができるので、あまり個人の負荷にならないのではないかと思います。また、コミュニケーションが個人間に閉じてしまわないのも特徴だと思います。このあたりは、弊社のメンバーが数人しかいないので、規模が大きい組織で使った時にどうなるかは分かりませんが。

場所は今回も初台のDeNAさんの会議室でした。読んだのは15章の「サポートベクターマシンと文書の機械学習」という章です。15.4の前まで読みました。

実は今回ほとんど予習していない状態で行ってしまい、内容も難しくて数学が苦手な私にはよく理解できませんでした。この章は理論は解説してくれるのですが、疑似コードなど実装の話は出てきません。分かりやすいという話を聞いたオーム社の『サポートベクターマシン』を帰宅後注文しました。引き続き勉強するとして、とりあえず分かったことだけ書きます。

サポートベクターマシン（SVM）は、前回のRocchioなどと同じように、教師付き学習を用いた、ベクトル表現に基づく分類器の一種と考えていいようです。Rocchioとは違い、クラスの重心を考えるのではなくて、境界線をどこに引くかを考える方法だそうです。そのためにクラス分布の端にある文書だけを考えます。この文書一つ一つのことをサポートベクトルと呼びます。

境界線から一番近くの文書までの距離をマージンといいますが、SVMはこれが最大になるような境界を見つけようとします。この境界に基づいて、新しい入力を分類すれば、大体合っているだろうというわけです。

と書くと簡単っぽいですが、高次元でこれをやるのがSVMの偉いところなんでしょう。ナイーブベイズだと70%の精度、SVMだと80%の精度、というのが現場の感覚らしいです。とは言え、正直言って、なぜSVMが優れた性能を持ち、複雑な計算による学習を必要とするのかがちゃんと理解できていないです。

マージンを最大化する問題は、二次計画問題に還元できるそうです。ここで、サポートベクトルを決定するためにラグランジュの未定乗数法というのを使います。この辺が分からないと実装できないわけですが、さっぱりです。

というわけで、基本が分かっていないので後はキーワードだけ書きます。

ソフトマージン分類法は多少の例外を認めるという拡張。SVMにおける学習の複雑度は、文書数の3乗オーダーだが、経験的には1.7乗オーダーになる。cutting planesというものを使うと1乗になる（!?）。文書ベクトルを高次元にマップするカーネルトリックを使うことで、ノンリニアの問題に対応できる。（でもロイター21578というデータセットでの実験結果によると、リニアバージョンとほとんど変わってない。）

うーん、もうちょっと勉強します。まずちゃんと予習して行かないと。

ネットサービスのユーザー登録の時、他のユーザーと重複しない名前を入れさせられることがよくありますよね。個人を識別できる文字列が必要なのは分かるのですが、なぜメールアドレスとパスワードだけではだめなのでしょう。メールアドレスは他人と重複しないし、各個人がよく憶えているので、使いやすそうですが。

それは、いわゆるユーザー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というものの共通認識ができるのは、もう少し先になるでしょうか。このあたりの感覚は本当にサイトやユーザー層によってまちまちですね。

IIR輪講第15回は、前回やり残した13章の残りと、14章を読みました。いつも復習の資料を作ってきてくれる、はてな伊藤さんが体調を崩されてお休みだったので、復習はなしでした。

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

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は歪んだ分布にも対応することができます。

先週の金曜日に、用賀のサンマイクロシステムズ本社で行われた、Python Code Reading 05に参加しました。田村公一さんが発表されました。

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

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

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

最近ちょっと気になったWebサイトをご紹介します。

Bloombla

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

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

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

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

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

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