unnonouno

2011年振り返りと2012年こんにちは

2012-01-01T23:59:00.007+09:00

昨年度もあっという間でした，ということは特になくて色々変化の多い一年でした．

転職しました

今年一番大きかったのはこれでした．まぁ，そうですね．実際には去年の年末にほとんど決まっていて，年初から引き継ぎとか，それまでの仕事の整理（特許と論文とソースコードとか）などでだいぶ時間を取られました．
環境は人を変えるとはよく言いますが，それを痛感した1年でした．とにかく周りの人が超人みたいな人だらけなので，盗むべきところは盗みつつ，常にディスカッションして考えを熟成させ，自分が周りにできることは何か，常に色々考えました．大変でしたが実りのあった一年だったと思いたいです．

Jubatusをリリースしました

転職後すぐにアサインされたのがJubatusでした．OSSにはあまり明るくないし，ソフトウェアのリリースも初めての経験でしたが，転職後半年でこういう機会に出会えたのは良かったと思います．リリース前後はやっぱり慌ただしくて，NTT研の人たちといろいろやりとりしたり，リリース後はいろんなセミナーで発表したりしました．

発表とかセミナーとか

今年は論文は控えめでした．会社の状態だとか，論文を書くコストを考えると，なかなかそこには注力できません．ただ前職でやっていたテーマを，前職の先輩がたくさん発表してくれたのは良かったです．
代わりにJubatus関係でたくさんセミナーで話しました．今まではどちらかと言えば研究者との対話が多かったですが，もっとエンジニアやお客さんに近い所で話して，作ったソフトウェアやそれに関する技術を世の中にちゃんと広めないとという気持ちもありました．また，会社のゴールを考えてもこれはやってよかったなと思います．

C++とか

3年間書き続けたJavaを捨てて，久しぶりのC++に戻って来ました．社内ライブラリが充実していたので，想像してたより苦労は無いです．みんな私よりも良いコードを書くので，いつも勉強させられます．テストをたくさん書いたり，モジュールの粒度を考えたり，プログラミングスタイルもずいぶん改められました．

その他

少ないと思っていましたが，写真はなんだかんだで6000枚くらい撮ってました
引っ越してジムを辞めてから運動量が激減したので，皇居ランをしました
新しい自転車を買いました！　9年ぶりの新車

さて，今年は転職2年目です．昨年蒔いた種がいろんな形で花開くといいな．蒔いた種からちゃんと収穫できるといいな，と思います．その他にもたくさん変化のある年になりそうです．

今年読んだ本5選

2011-12-31T02:39:00.000+09:00

読書記録をMediaMakerというところにつけているのですが，今年は30冊くらい読んだみたいです．実際は，ここに書いてないのもあるので，もう少しあるかな．今年読んだ本のベスト5を紹介します．

アジャイルサムライ−達人開発者への道−
Jonathan Rasmusson 西村直人

オーム社 2011-07-16
売り上げランキング : 1557

Amazonで詳しく見る by G-Tools

アジャイル開発に関するエッセンスをとてもよく凝縮し，それでいて実例や対話を交えて極めて明快に書かれています．訳本なのに非常に日本語も読みやすく，すんなり読めます．「小さなチーム」だとか「職能横断型チーム」だとか，普段自分が重要視していることも書かれていました．リソース（お金や時間）と顧客と不確定要素の関わる仕事に従事する人全員にお勧めします．例えば，締め切りがあって，査読者や審査員や指導教官がいて，実験が上手くいかないかもしれない，というような問題を抱えている人種の人達のことです！
事実を誤魔化さない，上手くいかないことは上手くいかない，それをどうマネージして最善を尽くせるか．

IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる
スティーヴン・ベイカー金山博・武田浩一（日本IBM東京基礎研究所）

早川書房 2011-08-25
売り上げランキング : 20676

Amazonで詳しく見る by G-Tools

IBMのグランドチャレンジでクイズ王にコンピュータで勝利した，プロジェクト・ワトソンの裏側のノンフィクション．クイズに答えるというタスクがいかに難しいかを人に説明しようとすると，なかなかこれが難しい．この本を読めばそれが非常に明快にわかります．自然言語処理に従事する身からすれば，無謀とも言えるチャレンジ，これがいかに始まったか，どうしてGOが出たのか，どういう覚悟でこのプロジェクトに挑んだのか．
そして何よりも，この本の書きぶりが素晴らしい．まるで小説でも読んでいるかのような書きぶりです．純粋に読み物としても面白いです．

デザイン思考の道具箱―イノベーションを生む会社のつくり方
奥出直人

早川書房 2007-02
売り上げランキング : 12237

Amazonで詳しく見る by G-Tools

製品開発をどのようにしてすすめるべきかについて書かれた本．まずプロトタイプを作り，ちゃんと作りこむ前にしっかり吟味することがすすめられています．プロト作りには何でも活用して，簡単なモックでもよい．こうした話は，今読んでいる「アントレプレナーの教科書」にある顧客開発モデルや，「アジャイルサムライ」のようなアジャイル開発手法の全てに共通して現れることがわかります．何ができるか吟味する，小さな開発サイクルを効率よく回す，顧客と対話する確認する，作り直しを恐れない．大きな失敗をいかに回避できるか，ということがいずれでも主要なテーマとなっています．
また，「技術のコモディティー化」というキーワードもとても興味を引きました．高等教育が進んで，インドや中国も高い技術を持つようになってきて，単に技術レベルだけで勝負できる時代ではないということです．試行錯誤できるかがこれからの製品開発の鍵になるのではないでしょうか．

競争と公平感―市場経済の本当のメリット (中公新書)
大竹文雄

中央公論新社 2010-03
売り上げランキング : 4457

Amazonで詳しく見る by G-Tools

日本人は，先進国の中でも突出して競争を嫌う傾向にある．公平と競争をキーワードに，様々な調査結果やデータを提示しながら，特に日本人がこれらのキーワードをどう捉えているかが非常に明快に書かれています．他の新書にはなかなか見られないくらい，とても良く既存文献を参考にし，データを的確に引用し，非常に明快な論理を展開していて，それでいて平易に書かれています．派遣切りや，格差社会，医療，教育といった現代社会でとかく争点になるテーマに関しても論理的な切り口で言及されていて，こうした問題を自分がどう捉えるかに関してよい指針になりました．

考えることの科学―推論の認知心理学への招待 (中公新書)
市川伸一

中央公論社 1997-02
売り上げランキング : 17460

Amazonで詳しく見る by G-Tools

「人間の推論」をテーマとして，推論に関わる様々な科学，すなわち記号論理や統計，認知心理学といった様々な視点から議論されています．そして，いずれの学問を持ってしても，人間の「推論」をモデル化するには不十分であることが，様々な実験データからうかがい知ることができます．「言葉」という「推論」とも密接に関わる現象を扱う立場としては，こうした人間の思考に関わる現象にももちろん興味はあります．個人的な立場としては，人間の「模倣」を必ずしもよしとは思いませんが，それをよく観察することは重要だと思っています．

第6回さくさくテキストマイニングで発表しました

2011-12-28T01:36:00.002+09:00

少し間が開いてしまいましたが、先々週末のさくテキでJubatusの紹介をしました。

Jubatusの紹介@第6回さくさくテキストマイニング

View more presentations from Yuya Unno

内容は、技術的な内容をかなり省いて、機械学習自体のチュートリアル、Jubatusが既存の機械学習ライブラリと何が違うのか、どういう応用ができそうかという点に絞りました。最近、もっと世の中の人に機械学習の恩恵を受けて欲しいと、割りと真面目に考えるようになったので、いろんな所でキャンペーンしています。機械学習だとか自然言語処理だとかは、個人的には明らかに便利な面があるのですが、まだ研究者のツールを抜け出て無い印象があって、そこのブレークスルーを作れればもっと新しいアイデアが出てくるんじゃないかと思います。

今回発表することになった発端は、前職の先輩である那須川さんの著書を、この勉強会の教科書に指定されていたので、そもそも那須川さんに話してもらったらいいんじゃないかということでボクが声をかけました。この書籍も、テキストマイニングに対する世の中のニーズや、利用シーンなどがよくまとまっていておすすめです。

テキストマイニングを使う技術/作る技術―基礎技術と適用事例から導く本質と活用法
那須川哲哉

東京電機大学出版局 2006-11
売り上げランキング : 146344

Amazonで詳しく見る by G-Tools

最近、テキストマイニングという言葉をよく聞くようになったのですが、ちゃんと利用シーンがわかって作られているのか、どういう顧客に利用してもらいたいのかというのが明確になっていない例をたまに見ます。自分の会社でもテキスト解析のご要望が増えてきていて、エンドユーザーの視点、利用シーンやイメージなどを末端のエンジニアが理解するのにもこの本は役立つと思います。

re2のxxxNの使い方

2011-11-25T23:13:00.000+09:00

re2はGoogleが公開しているC++用の正規表現ライブラリです。速度も速い（らしい）し、ちゃんと日本語一文字も"."でマッチしてくれるので、社内でも好んで使われています。

たくさん機能があるようなんですが、Web上であまり情報がなかったり、詳細はheaderファイル見てね！みたいなことが書かれていて、なかなかマスターするのが難しいライブラリです。特に、マッチ箇所（いわゆるgroup）が複数あるときにどうすればいいのかすぐにわかりません。私も以前ここではまって、色々調べてどうにか動いたことがありました。ちょうど@chezouさんが困っていたようなので、メモのつもりで晒してみましょう。

説明するより、コード読むがはやし、ということでサンプルを！

#include <re2/re2.h>
#include <string>
#include <vector>
#include <iostream>

using namespace std;

int main() {
  string pat = "(.)(.)(.)(.)";
  string text = "hoge";
                                                                                                                                                                         
  re2::RE2 re(pat);
  re2::StringPiece input(text);
  int groupSize = re.NumberOfCapturingGroups();
  vector<re2::RE2::Arg> argv(groupSize);
  vector<re2::RE2::Arg*> args(groupSize);
  vector<re2::StringPiece> ws(groupSize);
  for (int i = 0; i < groupSize; ++i) {
    args[i] = &argv[i];
    argv[i] = &ws[i];
  }
  re2::RE2::PartialMatchN(input, re, &(args[0]), groupSize);
  for (int i = 0; i < groupSize; ++i)
    cout << ws[i] << endl;
}

基本的にxxxN関数を使えばOKのようです。まず、RE2オブジェクトのgroupの数はNumberOfCaptureingGroupsで取れます。xxxN関数には、書き込み先のArgへのポインタの配列を渡す必要があります。なので、Argポインタのvector（これを関数に渡す）と、Arg実態のvectorを作ります。実態の方には、それが書き込む先のStringPieceへのポインタを代入しておくといいようです。ここは、intポインタなどを代入すれば、intに変換されて代入されるでしょう。この辺は、なんとなく書いたのでもっと良い書き方があるのかもしれません。これでマッチさせれば、最終的にStringPieceのvectorに結果が代入されました。

pficommonをちょっとだけ紹介

2011-10-29T13:44:00.001+09:00

報道機関の発表の通り、10/27日に分散オンライン機械学習基盤Jubatusを発表しました。これに関しても書きたいことは山ほどあるのですが、来週Jubatus Workshopがあるので、それまでは秘密です（ウソです、聞かれたら答えます）。

さて、同時に公開されたのがpficommonです。これは、弊社内で使われていた便利ライブラリで、あまりの便利さにこれがないと開発できないため、Jubatusでも使われています（もちろんSedueでも）。そして、Jubatus公開に伴い公開となりました。pficommonは明日からでも使うべきなライブラリなので、先にこちらを紹介します。

pficommonは様々なライブラリからなる、複合的なライブラリです。
今日は個人的にお気に入りの、

xhtml_cgi
json

の２つを紹介します。

xhtml_cgi

実験用のコードなどを書くと、たくさんログを出力したくなることがあると思います。しかし、例えば1行に収まらないとか表にしたいことはよくあります。私は昔からHTMLで出力していたのですが、いかんせんcoutで出力するのは面倒、かと言ってフロントエンドをpythonで書いてrpcまでしだすと面倒・・・。実際、私は修論のとき検索をやっていたのですが、このためだけにpython, django, rpcを使って大変面倒でした。これを一気に解決するのがxhtml_cgiです。

まず、cgiのサンプルを見てください。なんというシンプルさ。さらに、pficommonにはhttp serverが実装されているので、これを使うと単独で動くhttp serverができあがります。コンパイルして実行すればhttp serverとして動きます。インタラクティブに引数を変えて実験などをしたいとき、この仕組を使うとhttp経由で実験ができます。Apacheとかいりません。正直、実験用のコードでrpcなんてしたくないんですね。

さらに画期的なのが、このxhtml_cgiです。このサンプルを見てください。C++の黒魔術を使うことで、なんとC++のソースがテンプレートライブラリ化するのです。単なるC++のソースなので、一部を関数にして使いまわしたりも可能です。あとは適当に書くだけで、簡単なデモは出来上がり。先日のYANSの時も、こんな感じで作っていました。

おまけで、サンプルとしてhttp経由でmecabの実行結果を確認するプログラムを書いて見ました。これくらい簡単に書けます。

json

社内的にも最も使われるライブラリの一つがjsonです。上記のcgiなどを書いていると、ちょっとした事をjsonでやりとりしたくなったりします。それ以外にも、例えばtwitter APIのjsonを読みたくなったり、別プログラムの出力をjsonで吐いて取り込みたくなります。ここで便利なのが、jsonライブラリ。pficommonのjsonライブラリは、テンプレートとserialization機能で、かなり便利に使えます。

jsonの読み込み・書き込みはは、streamから取ってくるだけでおしまし。

json js;

stringstream ss;
ss<<js;

json ks;
ss>>ks; // js==ks

値の取り出しは、直感に従って書いて、最後にjson_castすればOK.

cout << json_cast<string>(js["user"]["profile"]) << endl;

最後に、jsonを何かしらの構造体にマップするのがserialize機構です。ここのソースを見てください。serialize自体は、例えばバイナリ形式でファイルに保存するのに使いますが、ここでは任意のデータ型をjsonへシリアライズ・デシリアライズできます。これは単に構造体中にserialize関数を作れば、via_jsonとto_jsonでstreamから変換ができるようになります。

以上、簡単ですが2つ紹介しました。それ以外にもスマートポインターやスレッド、msgpack_rpcなど便利なライブラリがたくさん含まれます。他の機能に関しても、せっせと @tanakh さんが紹介記事を書いていると思います。ドキュメントはありますが、ちゃんと書かれていない機能や、使い方がわからなくなったらソースや単体テストを参照すればだいたい分かる（たぶん）と思います。研究用のプログラムなどでも大変活躍すると思いますので、是非ご活用ください。

社内セミナーで形態素解析について話しました

2011-10-22T01:43:00.000+09:00

持ち回りの社内セミナーが自分の番になったので、形態素解析についてまとめてみて、発表しました。係り受け解析入門に引き続き、自然言語処理チュートリアルシリーズ第２弾になります。結構ボリュームがあって、力作になってます。

形態素解析の過去・現在・未来

View more presentations from PFI Marketing

今回の狙いは３つくらいありました。
ひとつは自分自身昔の文献などを読んだことがなかったので読んでみたこと。見ると、昔は多くの論文を企業の人が書いていて驚きます。初期の文献で引用したものはほとんどが企業系研究者の方の論文です。日本語入力の文脈で研究されていたからなのかな、という気がします。
もうひとつは現在の問題点と問題意識をまとめる。書いたとおり、アプリケーションに対して最適なことをすべき、という思いがあります。それは単にアプリケーションごとに形態素解析器を作るべき、ということではないです。そもそも形態素解析というソリューションは適切ですか？という問いかけです。実際に弊社では、普通の人が形態素解析するところで形態素解析しないで処理している所も幾つかあります。
最後は、研究者とエンジニアのマッチングです。以前より研究者は企業の問題意識を共有していない、企業は最新の研究に興味がない、という悲しい状態にあると思ってました。自分自身は研究者とのコネクションもあり、またPFIとしては様々なエンジニアの方とコネクションがあるので、ここで発表したらお互いに意識や知識を共有できるかな、と思うところもありました。結果的には、反応を見るかぎり様々な業種の方に聞いていただけたのかなと思っています。

当日、視聴していただいた皆様は、どうもありがとうございました。

NLP若手の会で発表しました

2011-10-04T00:19:00.003+09:00

会社のブログにも書いたのですが、9/21, 22にNAISTで開催されたNLP若手の会シンポジウムで発表してきました。私は幸運にも最優秀奨励賞をいただきました。投票してくださった皆様どうもありがとうございます。発表資料はこちら。

N-gram統計量からの係り受け情報の復元 (YANS2011)

View more presentations from Yuya Unno

さて、ちょっと裏話でも書きます。もともと発表する気（も時間も）はなかったのですが、プログラム委員ということでどちらにしろ奈良に行くのと（これは後に案外みんな来てないことがわかった）、最近開発＆案件続きでちょっと研究もやりたいねということで、急遽発表ネタを捻出することになりました。特に検索クオリティを上げるような面白いネタはないだろうか。以前から確率的単語分割で検索品質を上げるという話があったのですが、これを確率的構文解析に適用したら・・・。単語境界情報のみだと、スキップのある部分文字列検索に自然な適応ができません。係り受け関係というのは、ある意味こうしたスキップのある構造に対する答えの気がしてきます。長い複合語などの検索がやりやすくなるのでは。そういう風な議論から話が始まりました。

発表は、私がネタを振って、みなさんの考えを色々引き出す感じで行いました。発表する中で気になったのは、文の「構造」をどういう風に捉えているのかということでした。文が、「構造」を持っている、つまりシーケンス以上の情報を持っているということはおそらく同意が取れると思うのですが、その「情報」がなんなのか、どう表現できるのかについては十人十色の考えを持っているようです。係り受けのような表現（全域木）もあれば、句構造にように中間のノードを付与する表現方法もあります。でも、実はこれらの幾つかが同じ情報の別表現（一対一対応がとれる）だったりもするし、グラフ構造のように視覚的に表現しやすい必要もないのかもしれない・・・。こうした構造のもつ情報、また表現方法などを探ると、文に対してもう少し別の見方が見つかるんじゃないのか、というのが今回思ったことでした。また、発表の途中で松本先生がいらっしゃって、文字単位の係り受け表現についていろいろ教えていただけたことも収穫でした。たまたま、こうした研究を以前やっていらっしゃったらしく、取り扱いの面倒な現象をたくさん教えていただけました。その他にも、今回は知り合いの研究者の方がたくさんいらっしゃって、論文やらアイデアやらをたくさん教えていただき、感謝です。

ACL2011読み会で発表してきました

2011-09-03T21:53:00.001+09:00

今日は、サイボウズ・ラボさんにおじゃまして、ACL2011読み会で発表しました

今日読んだ論文はこれです。

Exploiting Web-Derived Selectional Preference to Improve Statistical Dependency Parsing.
Guangyou Zhou, Jun Zhao, Kang Liu, Li Cai.
ACL2011. [pdf]

発表スライドはこちらです。

ACL2011読み会 Exploiting Web-Derived Selectional Preference to Improve Statistical Dependency Parsing

View more presentations from Yuya Unno

内容はすごい簡単です。一言で言えば、単語の出現確率のPMIをgraph baseの係り受け解析の特徴量にいれたら精度が上がりました。これだけ。でも、これだけ主張が短くてはっきりしていて、アイデアも適用方法も明確なのは良いと思いました。一方で、いかにも誰かやってそうな方法で、既存研究ないのかという方が気になる論文です。

さて、もうちょっとちゃんと説明しましょう。係り受け解析についての詳細は割愛します。文中の単語の係り受け関係を解析するタスクです。以前TokyoNLPで発表した資料を見てください。やるとわかるのですが、品詞情報などでわかる構造はだいたい当たるようになる一方で、どうしても品詞だけだとわからない部分をちらほら間違えます。例えば、「値段の高いワイン」と「父の高いワイン」は「値段」も「父」も同じ名詞なのに構造が全く違う。
ここで、選択選好という用語の登場です。選択選好というのは、単語には係り安い単語がある、という様な意味で、例えば「・・・の高い」といったら、・・・の部分には「値段」や「背」など高さを持つ単語がきやすくて、「父」はこないというような性質です。この、係り安さというのを、コーパス中での共起しやすさで表現しようというアイデアです。共起しやすさは、PMI（自己相互情報量、Point-wise Mutual Information）で測ります。これは、2つの確率変数の同じ確率が、偶然の共起（＝独立）に比べてどれくらい共起するかの指標です。単に共起頻度さえ測れれば計算できるのでよく使われます。これを高階Eisnerのlog-linearモデルの特徴にしてしまいます。
内容はこれだけです。3単語の場合の測り方などのちょっと変化球もありますが、大きくアイデアが変わるわけではありません。
PMIを測る方法、というよりは共起頻度を測る方法として大規模なGoogle V1コーパスを使う方法と、ググった時の頻度推定値を使う2つの方法を試しています。結果的に、PMIを使わない場合より高いスコアを出す一方で、最新の半教師あり学習より低いくらいの精度でした。また、データ数が多い方が精度は良く、V1コーパスよりググった結果を使ったほうが良いようです。面白いのはコーパスを変えてもあまり精度は変わらず、単純に使う単語数のみに精度が依存していました。

さて、発表でも言ったとおり卒論のテーマにあってもおかしくないくらい簡単な方法です。ただ、一方で「単語出現のPMIを特徴に入れれば、選択選好を表現できて、精度をあげられる」という極めてシンプルで強力な主張で、適用範囲も広いし、他の研究への応用もしやすい。この論文の評価は割れると思います。手法の適用範囲の広さは重要ですが、昔からやろうとした人はいたけどデータが少なかったから効果がなかったが、最近は大規模になって〜系だとするとよくあるWeb大規模論文にしか見えてきません。データが大規模化しても省メモリで動くみたいな一捻りがあったらより良かったかなと思います。とりあえず日本語で試してみようかと思ったら、dependency parserのソースは前の職場においてきてしまった・・・

実は最初は別の論文を紹介しようと思っていました。

Language-independent compound splitting with morphological operations.
Klaus Macherey, Andrew Dai, David Talbot, Ashok Popat, Franz Och.
ACL2011. [pdf]

内容としては、複合語を分解する話です。ドイツ語などは複合語をくっつけて書くので、これを分解して機械翻訳の精度を上げようとしています。ただ、教師データがないので教師なしの設定で行います。やり方としては、分解の候補と語形変化候補をたくさん作って、最適パスを求めるという話です。と、書くと分かるとおり、それなんてコスト最小化法、あるいはSemi-Markovちゃうの、という感じです。単語分割問題に慣れ親しんだ我々日本人は、ここでガツンといいたいところです（ぉ
ということで、動的計画法面白そう！と思ったらよくある話で飽きてしまいました。途中までスライド作ってたのに・・・

しかし、2011年になって単語分割の重要性に気づくとは！　単語分割先進国の我々日本人はもっと貢献してもいいような気がしました。

さて、他の方の発表ですが、オモシロイと思ったのは @nokuno さんの単語アライメントを識別学習する話。

Unsupervised Word Alignment with Arbitrary Features.
Chris Dyer, Jonathan Clark, Alon Lavie, Noah A. Smith.
ACL2011. [pdf]

たぶんご本人がブログで解説されると思うので、他の視点で。
twitterでも書きましたが、このモデルはlinear-chain CRFの変化形として捉えることができる気がしました。普通のCRFでは、第1項が単なる特徴ベクトルになりますが、ここではaの分布の上での期待値になっています。しかし、これはアライメントaと単語tの2つ組をタグ付けるタスクにおいて、aだけ周辺化してけしていると捉える事ができます。つまり、tに対するタグだけ存在する部分的アノテーション状態です。ということで、坪井さんの部分的アノテーション論文。

日本語単語分割の分野適応のための部分的アノテーションを用いた条件付き確率場の学習.
坪井祐太, 森信介, 鹿島久嗣, 小田裕樹, 松本裕治.
情報処理学会論文誌 Vol. 50, No. 6, 2009. [link]

部分的アノテーションとは一部だけタグがふられている状態です。ラベルの振られていない部分は、全ての候補集合に対して特徴ベクトルを足しこみます。元のアライメントの問題も全てのアライメント候補を足し合わせる（周辺化する）部分が同じで、実際アライメント論文の対数尤度関数と坪井論文の(3)式、あるいはアライメント論文の(1)式と坪井論文の(5)式が同じ形をしています。
完全に両者が同じ事をしているというわけではもちろんないですが、意外な類似性が見えて私は面白かったです。

今日は途中お腹空き過ぎで、ちゃんと理解できたのが少なかったです。@niamさんは、教師なし品詞タグ付けを、パラレルコーパスを使って別言語から伝搬させる話。@shuyoさんはLDAにインタラクティブに制約を加える話。教師なし学習の結果が人間可読でない問題は昔から気になっていたので、どちらともこういうモチベーションは好き（内容は理解半分・・・）。@sleepy_yoshiさんはランキング学習を転移学習させる話。最初のランキング学習のチュートリアルがわかりやすかった。@suzuvie_reさんはcross-documentの共参照解析を、pair-wiseでなくてまとめてからやるようなモデルでやるはなし。雰囲気はわかったが、モンテカルロ法の教養がなくて基本的なところから理解できなかった。難しす。@bontyさんはスペル訂正を、コスト最小パスの問題と、top-kのリランキングで解く話。グラフと思ったら、DAGだったｗ上の複合語の話と通じるものがあります。@tsubosakaさんは識別モデルによる言語モデルを大規模化する話。普通にMEするとZの計算で頓挫するけど、上手いことサボれる。こういう話を、昔@whymくんがやろうとしていたような気がする。

今日得た素晴らしい知識は、IJCAIを「イジカイ」と読むのは日本人だけ、SIGIRを外人は「シガー」と読むということでした。

動的計画法は再帰で表せ

2011-09-02T16:55:00.000+09:00

動的計画法の説明は常に再帰関数で書き表すことにしています．いやゆるメモ化再帰です．参照透過な関数は，同じ引数に対して同じ値を返すので，保存しておけばいいという感覚です．計算量の見積もりも簡単で，引数の異なり数に関数中のループの上限をかければおしまいです．特に再帰で書くことに慣れていれば自明に書けますし，テーブルを使ったDPと違って，ループの順番を意識する必要がありません．このテクニックは学部時代に@ohkuraに教えてもらいました．関数型言語に触れた今でこそ当たり前に見えますが，当時は目から鱗だったのを覚えています．
メモ化再帰と不動点に関する@kinabaさんの日記や，プログラミングコンテスト的には@chokudaiさんの記事が参考になります．

今更ですが，ちょっと例で説明します．フィボナッチ数を計算する関数fib(x)は再帰式で，fib(x) = fib(x - 1) + fib(x - 2)とかけます．このままプログラムにかくと，

def fib(x):

if x == 0 or x == 1:

return 1

else

return fib(x - 1) + fib(x - 2)

これで参照透過な関数はかけました．後はメモ化するだけ．

def fib(x):

if x in cache:

return cache[x]

elif x == 0 or x == 1:

return 1

else:

v = fib(x - 1) + fib(x - 2)

cache[x] = v

return v

これだけです．基本，再帰が書ければそこでおしまい．パフォーマンスがシビアにならない限り，基本的に全部これでプログラム書いています．

もっとNLPよりな例を出します．たとえば，linear-chain CRFのViterbiパスのスコアを求めてみましょう．

s(x, y)は素性ベクトルと重みベクトルの内積です．やはり再帰でかけますので，同じようにメモ化するだけです．メモ化したあとに，じっとにらめっこすると，いわゆるDPテーブルを使った動的計画法に変換できます．ただ，DPテーブルを使う場合は，計算の順番を考えないといけない点で面倒です．つまり，v[t][x]の計算にはv[t-1][・]が全部終わっている必要があります．関数呼び出しコストがなくなるので，実用上は速くなります．ただし，CRFやHMMくらいならいいですが，CKYの計算順序くらいになると直感ではわからなりません．再帰で書けば，計算されてなかったら計算する，計算済みならキャッシュを返す．それだけです．まぁ，依存関係を図示すれば多くの場合すぐわかりますが．

On Efficient Viterbi Decoding for Hidden semi-Markov Models.
Ritendra Datta, Jianying Hu, Bonnie Ray, ICPR 2008.

Semi-MarkovのViterbiがDPテーブルを2つ使うと高速になるよ，という論文を以前先輩に紹介されました．最初この論文は式が全然追えなくて，なんて複雑怪奇な計算をしているんだと思ったのですが，途中にある再帰式を眺めてたら気づきました．

Bの部分は一部省略してます．これの計算量はT * N引数で，T回ループとN回ループがあるのでO(N²T²)といってます．これをちょっと変形します．

単に内側のmaxを外だしにしました．相互再帰になりました．見えましたか？　どちらの関数もT * N引数で，ηはN回，δはT回のループです．これを素直にメモ化すれば，計算量はO(NT(N + T))です．恐ろしく簡単になりました．こう書けばいいのに・・・．

思うに，この程度まで複雑になってしまうとDPテーブルを使って考えるのは難しいです．まず，再帰で表す．そしてメモ化．速くしたければDPテーブル化．再帰で表すセンスは関数型言語で磨きましょう．リストや木やDAGを見ると再帰で表したくてうずうずしたくなりますよ．

ICML2011読み会に行ってきました

2011-07-17T09:13:00.000+09:00

昨日は@nokunoさん主催のICML2011読み会に参加しました。ボクは場所貸ししただけで、発表してません（汗　本当は超簡単なsemi-supervised naive bayseを実装して発表しようかと思ったんですが、発表者いっぱいいるし、まぁいいかなと。

さて、みなさん発表上手なので話半分に分かった気になりました。一番面白かったのは松島さんが紹介した下の論文。

Parallel Coordinate Descent for L1-Regularized Loss Minimization
Joseph Bradley, Aapo Kyrola, Daniel Bickson, Carlos Guestrin

coordinate descentというのは、特徴空間の中で適当な次元の断面を考えて、その平面上で目的関数を最小化し（特に、解析的に最小点が求まることもある）、これを繰り返せば最終的にもとの特徴空間上での最小点がもとまるというもの。で、この平面の選択を分散させて、更新分を集約するとほぼリニアに速度がスケール。しかもすごいのは、並列性の理論的な限界も示せて、実験でそれも検証というもの。
これを聞いて思ったのは、検索などの文脈で出るキーワード分割とドキュメント分割の話。(parallel) SGDみたいなのはデータを分散させるのでドキュメント分割的で、この方法は特徴量で分散させるのでキーワード分割的だなぁということ。あと、平面で切ったあとの最小化はもとの関数の勾配を使うので、振る舞いとしてはバッチ的。なので目的関数はギュンギュン下がります。

あとは、@tsubosakaさんの説明したトピックを差分で表す話も面白かった。

Sparse Additive Generative Models of Text
Jacob Eisenstein, Amr Ahmed, Eric Xing

今まではトピックを多項分布（のパラメタ）みたいに表してたけど、そうではなくて全体の分布からの差分だと考えるという話。これは、例えばストップワードみたいにトピックに依存しない単語の出現確率まで推定するのは無駄なのと、そういう単語の出現確率がトピックごとに異なるみたいに推定されるのはちょっと気持ち悪い。そこで、全体の平均的な分布を考えて、トピックごとの差分をそこに足す。そして、この差分ベクトルがスパースになるような事前確率を入れるという話。差分が表現出来れば、他のトピックと比べてどの単語が多くてどの単語が少ない、というトピックごとの特徴も自然に説明できそうでよさそう。残りのベイズベイズした話は、ふーん、と思いながら聞き流してましたｗ

@niamさんの説明したSVDでディテールが潰れるところを、差分行列として取り除く話も、似たような雰囲気を感じました。全体的な平均から逸脱する部分を、疎な差分として表現して、その２つで表すという点で似ている気がします。

@nokunoさんのアンカーグラフと、@n_shuyoさんのInfinite SVMは、両方共データがどういうところに分布しているのかを考慮して学習したほうがいいよ、というような話に聞こえました。多様体とか勉強しようかな・・・。@y_benjoさんのpage rankを保存しながらグラフを圧縮する話は、なんでみんなやってなかったんだろうという気がしました。@suzuvie_reさんのベイジアーンな発表は、途中から全然追えてませんでした。キビシイ。

ベイズな話は、一度何か実装してみないと話についていけないなぁと思いました。あと、気になったのは人工データで実験しているのをたくさん見るんですが、実問題の設定からかけ離れていて意味あるのかなと思ったのが幾つかありました。どうやって手法の優位性を言うかは難しいですね。
みなさん５時間近くお疲れさまでした。

超広角を買いました

2011-07-15T23:52:00.006+09:00

忘れてましたが、ここは写真のブログでしたｗ　2月前ほど、GWにバシバシと予定を入れてしまったので、レンズを買うことにしました。買ったのは、前から欲しかったシグマの超広角、8-16mmです。

シグマ 8-16mm F4.5-5.6 DC HSM ニコン用 8-16mm F4.5-5.6 DC HSM NA

シグマ 2010-05-28
売り上げランキング : 17670

Amazonで詳しく見る by G-Tools

8mmって！　前玉なんてものすごく飛び出てるし、フィルター付けられないし、重いしでかいし。でも、たまたまアウトレット特価で４万円台という破格で売られていたので買いました。こんな焦点距離なのに、ものすごくシャープに写ってびっくり。純正の魚眼はパープルフリンジがこれでもかというくらいでるのに、全然そんなことない。空を撮ると、流れるような雲が異様な存在感を帯びて写ります。これは買ってよかった。ちなみに、上のリンクはペンタ用がamazonから消えてたのでニコンです。悲しい・・・

動的型情報で仮想関数呼び出しを速くできるか

2011-06-12T23:04:00.011+09:00

C++は抽象化と高いパフォーマンスを両立させるにはtemplateを使うのがセオリーでした。そのため、標準ライブラリはtemplateを使っています。一方のJavaは、積極的に仮想関数を使っています。しかし、Javaは動的型情報を使った実行時インライン展開ができるため、C++と違って疎結合のまま高いパフォーマンスを出すことが出来ました。しかし、よく考えれば、C++でも実装クラスが限定されるなら、Javaと同様なことをハードコードすることでC++の仮想関数を高速ができるのではと思って試してみました。

結論から言うと、一応速くなりました。でも、インライン展開を抑制しなければいけないほどの効果が出るのは、かなり限定的のようです。

さて、順を追って説明します。

まず、C++では仮想関数を使うと遅くなるというはなし。C++で仮想関数を使うと、仮想関数テーブルが作られます。そして、関数呼び出しが起こると仮想関数テーブルを参照して、そこに書かれた関数を呼ぶことになります。仮想関数テーブルというのは、要は関数ポインタです。そしてこれが遅いため敬遠されます。
何故遅いのか。これは、呼び出す関数が実行時までわからないため、コンパイル時にインライン展開できないというのが問題です。例えばvectorのoperator[]や、greaterなどのように、実質的には1命令ですむような関数を仮想関数にすると、本来数クロックで終わる処理に、レジスタの退避とジャンプ命令が付与されるため、劇的にパフォーマンスが低下する可能性があります。

例えば以下のようなプログラムを書いてみます。

class Parent {
 public:
  virtual ~Parent() {}
  virtual void fun() = 0;
};

class Child : public Parent {
 public:
  void fun() {}
};

int main() {
  Parent* c = new Child();
  for (int i = 0; i < 1000000000; ++i)
    c->fun();
}

この実行時間は1.7sec程度でした。ここで、c->fun()をdynamic_cast<child*>(c)->Child::fun()にすると実行時間が0.0secになりました。呼び出される関数が特定されたためインライン展開されて、結果的にループが消えたようです。これは、-Sでアセンブリを出力させれば、c->fun()ではあった1000000000回のループが消えることで確認できます。ちなみに、Parent* c = ... をChild* c = ...に変えても実行時間は変わりません。cがChildの子クラスである可能性を否定出来ないからだと思います。

さて、C++はこうした問題を回避しながら処理の抽象化を行うために、templateを使って対処しました。有名な例として、CのqsortよりもC++のsortの方が速いという話があります。これは、Cのqsortは比較関数を関数ポインタで渡しますがC++のstd::sortは関数オブジェクトをtemplateで渡します。関数ポインタですと、インライン展開できませんが、templateで関数オブジェクトを渡せばインライン展開されるので高速になるという寸法です。
ここまでは、C++をやっていれば必ず聞く話です。

さて、そうしたわけでパフォーマンスを気にしなければならないシーンで、templateを使うハメになるのですが、templateにするためにはソースを全部ヘッダに書いてコンパイルが遅くなったり、極端に複雑な依存関係に悩むはめになります。一方のJavaは、そもそもtemplateがないのですが、実はそもそも仮想関数がそんなに遅くならない仕組みが入っています。
例えば、Javaで以下のようなソースを書きます。

interface Parent {
  public void fun();
}

class Child implements Parent {
  public void fun() {}
}

class InlineTest {
  public static void main(String[] args) {
    Parent c = new Child();
    for (int i = 0; i < 1000000000; ++i)
      c.fun();
  }
}

このプログラムは非常に高速に実行されて、例えば自分の環境では 0.0ms でした。JavaのJIT最適化コンパイラは、ループの間でcが書き換わらないことを検知したら、下のようなプログラムに（実際はバイトコードレベルですが）に書き換えて実行するということのようです。

if (c instanceof Child) {
  Child c_ = (Child)c;
  for (int i = 0; i < 1000000000; ++i) {
    c_.fun();
  }
} else {
  for (int i = 0; i < 1000000000; ++i) {
    c.fun();
  }
}

c_.fun()がさらに実行時最適化によってインライン展開されて、最終的に大量の関数コールが消える、という寸法です。さて、そういうわけで仮想関数に関してJavaの方が優れているように感じられます。だからといって、C++でtemplate地獄に陥りたくない・・・。この問題はC++プログラマーを非常に悩ませます。そもそもC++のように面倒なことこの上ない言語を使っているのは、ギリギリのCPU性能を引き出したいからなのに、仮想関数を使ったとたんJavaよりも遅くなるとか・・・。そこで考えます。実装クラスがある程度事前に分かっていたら、手動で上記のようなif文を挿入すればいいのではないか、と。ようやく本題です。 C++で以下のようなプログラムを書いてみます。

if (typeid(*c) == typeid(Child))
    for (int i = 0; i < 1000000000; ++i)
      dynamic_cast<child*>(c)->Child::fun();
  else
    for (int i = 0; i < 1000000000; ++i)
      c->fun();

これは見事に0.0secでした。インライン展開されたのがわかります。ただし、上記のコードは若干マクロにしにくいので、以下のようにしました。

#define CALL(T, c, f, ...)                          \
  (typeid(*c) == typeid(T) ?                        \
   dynamic_cast<t*>(c)->T::f(__VA_ARGS__)           \
   : c->f(__VA_ARGS__))

...

  for (int i = 0; i < 1000000000; ++i)
    CALL(Child, c, fun);

これを実行すると、0.6secでした。実行時間がもとのおよそ1/3になりました。先程のようなパフォーマンスにならないのは、もちろん分岐命令が入るからです。簡単なマクロを書くことで、事前にある程度実行型が分かっているなら効率を上げることができることがわかります。ところで、指定した型以外のパフォーマンスはどうでしょう。別名の全く同じクラスを作ってみます。

class Child2 : public Parent {
 public:
  void fun() {}
};

int main() {
  Parent* c = new Child();
  for (int i = 0; i < 1000000000; ++i)
    CALL(Child, c, fun);
}

これが非常に遅いです。5秒以上かかってしまいました。もとの時間の3倍です。何故でしょうか。この謎を解くためには、typeinfoを覗かないといけません。 typeinfoファイルを覗くと、type_info::operator == で__buildin_strcmpという関数を使って型名の比較を行っているようです。これは残念すぎる。しかし、どうやら__GXX_MERGED_TYPEINFO_NAMESが0でなければ、単なる==演算しかしないようなので、gccに-D__GXX_MERGED_TYPEINFO_NAMES=1を指定して実行してみましょう。すると、実行時間が2.0sec程度になります。元のc->fun()のみに比べて1割増程度で抑えられました。これでようやく満足です。

ところで、実際のところここまで最適化する必要が有るのでしょうか。今回、意図的に差が出やすいように関数の中身を空にしました。実際は、数回のロード命令が挟まるだけで、インライン展開の恩恵は相対的に消えていきます。実際はサイズをいろいろ変えて、アセンブリコードを確認しながら試しましたが、載せるのがしんどくなったので割愛しますｗ　結果として、分岐やロードを数個挟むのであれば、普通に仮想関数にしてしまってもそこまで極端な性能差はでない、ということです。それから、上記の__GXX_MERGED_TYPEINFO_NAMESの問題もあるため、簡単にはパフォーマンスが上がってくれないということのようです。C++、ホントに難しい・・・。

CRFのヘシアン

2011-04-26T08:58:00.002+09:00

坪井さんの論文がAAAIに通りました。おめでとうございます。AAAI記念ということで、宣伝その２。今回はCRFのヘシアンを具体的に計算してみます。

入力文x、ラベル系列y、重みベクトルwに対して、CRFの対数尤度関数は

です。fは特徴ベクトルで、普通f(x, y)と書きますが省略します。Zは分配関数です。正則化項を無視すれば、学習データに対するこの値の総和、

が目的関数でした。この勾配はきれいな形をしていて、

という形でかけます。NLP屋さん的にはここでおしまいですが、実はもう１回微分した形、つまりヘシアンもきれいな形で求まります。では頑張って微分しましょうというのが今回の主旨。

まず、第１項のΣ_yfの項はwで微分すると消えます。考えないといけないのは第２項のE[f]の部分だけです。ベクトルの微分なのでちょっとめんどくさいです。もとの式に戻しましょう。

ではwで微分しましょう。まずは積の微分公式です。

第１項は簡単ですね。

第２項は1/Zの微分ですが、これも勾配の時と同じように落ち着いて計算すれば綺麗に消えていきます。

結果的に、全体では

になりました。なんともシンプル。ところで、勾配を求める時もものすごくキレイに期待値が出てきますよね。何回か手を動かしていると、その心がなんとなく分かってきます。イメージで言うと、expの微分がexpである（自分自身である）ということ、そしてexpの中のfwが微分されて、fが外に出てくるというのが結構ポイントのように思います。前者の特徴がP(y|x)を生み出し、後者がfを生み出し、全体でEを生み出している、そういう風に感じられます。

さて、この式から具体的な再帰式（DPの式）を導くことが出来るでしょうか。実はここまでの式変形にCRFのCRFたる特徴は使っていません。使っているのは対数線形モデルであるという特徴だけです。したがって、MEもsemi-CRFもparsingの対数線形モデルも同じ式で表せます。CRFの特徴、すなわち特徴ベクトルfがグラフィカルモデル上でのクリークに対する特徴関数の和で表せるという性質を使うのはここからです。

だとします。iはクリークにつけられたインデックスです。すると、期待値の線形性から

に分解できます。P(f_i)は各クリークが選ばれる周辺確率です。これは一般のCRFでは必ずしも効率的に計算できませんが、例えば直鎖CRF（linear-chain CRF)の場合は前向きスコアと後ろ向きスコアの積で簡単に表せることが知られています。すなわち、

です。細かいノーテーションは省略します。雰囲気で察してください（ぉ　αとβの値は動的計画法を使えば多項式時間で計算できますから、予め計算してあげれば上記のE[f]も多項式時間で計算できる、という寸法でした。lnear-chain CRFだと効率的に勾配を計算できるのは、このあたりが絡んでいます。先の@sleepy_yoshiさんの日記で省略されていたのがこの部分です。もちろん、前向き後ろ向きを内側外側にすれば構文解析ができます。

同じことを先のヘシアンに対しても適応できないか考えてみます。ところが、E[ff^T]を分解しようとしたところで詰まってしまいます。実は私は先ほど求めた式から動的計画法の式を導き出す方法をまだ編み出していません。しかし再帰式自体はもとまっていて、それが最初に紹介した坪井さんの言語処理学会の論文、及びAAAIの論文でした。個人的には、勾配の時と同じように上の式から直接きれいな形で再帰式を導き出せると思っています。実は別の導出もあるんですが、それも含めて再帰式の導出はまた今度。

Newton-CG法とは

2011-04-12T21:51:00.004+09:00

先日、@sleepy_yoshiさんがCRFの目的関数の導関数を求める記事を書いていました。ここに便乗して、@yuutatさんたちとやっていたNewton-CG法について解説を書きます。・・・、と思ってたのですが引っ越してから未だにネットにつながらなくてなかなか更新できませんでした。今、マックで書いてますｗ

まず、Newton法のおさらいから。Newton法は、目的関数を２次関数で近似して、その最小値（放物線の頂点）に更新する方法です。２次関数による近似は現在のパラメータx₀の周りでテーラー展開すればよいです。

これが最小値を取るのはxで微分した値が0になる時で、それは

に更新すればよいことがわかります。xがベクトルの場合も同様で、この場合、１階微分がベクトル（勾配）g、２階微分が行列（ヘシアン）Hになることに気をつけます。

さて、CRFの目的関数に関してこれを適用することを考えます。勾配は@sleepy_yoshiさんの日記のとおり計算できます。問題はヘシアンの逆行列です。この計算には２つの難しさがあります。ひとつは、xの次元が大きすぎるため、ヘシアン自体を陽に計算できません。もうひとつは、その逆行列は尚更計算できません。

この問題を解決するために、ヘシアンの逆行列を近似するのが擬ニュートン法でした。よく知られたL-BFGSは、反復の直近の勾配を使ってこれを近似します。しかし、実はもっと正確に計算できます。欲しいのはヘシアンでもヘシアンの逆行列でもなく、ヘシアンの逆行列を勾配に掛けた値です。つまり、欲しいのはベクトルです。ヘシアンもヘシアンの逆行列も陽に計算しないで、ヘシアンの逆行列と勾配との積を直接計算できないか、というアイデアが生まれます。実はこれが数値解析的に計算できます。すなわち、共役勾配法（CG法）を利用してこれを計算してしまう方法、これがNewton-CG法です。

ここでCG法を思い出してみましょう。CG法は連立一次方程式Ax=bを数値的に解く手法です。この解というのは、すなわちx=A^-1bを求めるということです。ところで先ほど求めたかったのは、H^-1gでした。すなわち、Hx=gという連立一次方程式をCG法でといてやれば、求めたかった更新式を計算できるという寸法です。ようやく道が開けてきました。CG法の更新式にAの逆行列は出てきません。これでヘシアンの逆行列を計算する必要がなくなりました。代わりにAとベクトルとの積が出てきます。この、ヘシアン・ベクトル積（Hessian-vector product）を計算できるか否かがポイントに成ります。そして、CRFの目的関数に対するヘシアン・ベクトル積が、動的計画法によって効率的に計算できるよ、ということを示したのが言語処理学会での@yuutatさんの論文なのでした。肝心のCRFのヘシアン・ベクトル積の計算方法ですが、これは導出が結構めんどくさい。言語処理学会の論文でもほとんど省略、発表では完全に省略（笑）しています。ところで、Newton-CG法自体は既存手法だったので、ひょっとすると機械学習やあるいは最適化の人にとってはよく知られた手法なのかもしれません。

言語処理ではベクトルの次元が巨大になるのでヘシアンを陽に計算できないよね、だから大雑把な近似しかできないよね、だからL-BFGSを使うんだよ、というのが教科書的な説明でした（だったと思う）。ちょうど、機械学習アルゴリズムを実装しようと思ってこの辺りの最適化アルゴリズムを勉強していて、ほうほうだから近似するんだね、ひとつ賢くなったよ、と思ってたときにNewton-CG法を教えてもらいました。せっかくできないことを知った直後に、実はできるよと言われたものだから結構衝撃的だったのを覚えています。ヘシアンもヘシアンの逆行列も陽に求まらないけど、それらをすっ飛ばしてヘシアン・ベクトル積なら計算できる。この辺りは全系列を列挙はできないけど、周辺確率なら計算できる、分配関数なら計算できるというのに似ていて、DPスキーとしてはニヤリとしてしまいます。
ところで時はオンライン学習大全盛の時代。L-BFGSに劇的勝利を果たしたあと、SGDの驚異的な学習の速さにあ然とするのでした。

「私は人生の岐路に立ったとき、常に困難な方の道を選んできた」

2011-04-02T13:55:00.001+09:00

twitter上で書いたとおり、３月末をもちまして日本アイ・ビー・エムを退社いたしまして、4月から株式会社Preferred Infrastructureの研究開発部門で働きます。ここに戻ってくることは無いだろうと思った本郷に、たった3年で戻ってくることになるとは思っても見ませんでした。

内外いろんな人から、なんで転職するんだという質問をいただきます。別に前職に大きな不満があるわけでもなかったし（小さな不満はどこに行ってもあると思います）、ちょうど自分がやり始めた研究、開発が成果を上げ始めて、まさにこれからという微妙なタイミングでもありました。
昨年末あたりから@hillbigさんに声をかけてもらって、悩んだ末での決断でした。これから研究開発を強化する、その過程を体験するというのは非常にチャレンジングで貴重な体験になるだろうと考えたのが主要な理由です。また、特に心に響いたのが、「変わらないこともリスクだよ」という言葉でした。自分の人生を考えたときに、どこかでチャレンジをするのなら若いウチの方がよかろうし、今のタイミングを逃したらもっと転職に対してハードルが上がるだろうということを思いました。今なら、例えば会社がうまくいかなくなったとしても、またやり直せるだろうということも考えました。いろいろな形でチャレンジをしている友人がたくさんいるのですが、彼らもやはりそうしたリスクを許容して、また失敗したとしてもそこからどんどん成長しているのを思ったりもしました。
最後に自分を奮い立たせたのが、タイトルの岡本太郎の言葉です。これからは今まで以上にチャレンジングな環境で、いろんな意味で尖った人間に囲まれることになります。短いながら３年間大企業で培った経験を活かして、常に成長していくことを目指し、腐らずに頑張っていこうと思います。

L1正則化で重みが0につぶれる理由

2011-03-14T18:08:00.002+09:00

L1正則化、つまり正則化項としてL1-normを使うとパラメタの大部分が0につぶれてモデルがコンパクトになるよという話をよく聞くと思います。初めて聞くと、何で？と思われるかと思います。先日の岡野原握手会でもこの話題がさらっとでて、@hillbigさんはよく微分した形でこれを説明しています（「押すなよ押すなよー」）。私は目的関数の形で理解した方がわかりやすいと思っているので、それを紹介。

まず、正則化項の入っていない凸な目的関数を考えます。

普通パラメタベクトルは多次元なので、多次元の山みたいな形になりますが、ここでは1次元だと思いましょう。この時点で最適値は（頂点の位置）は3です。これに正則化項を足します。L2だとこんな形をしています、というか0を中心とする放物線です。

足しましょう。

足すと0に向かってシフトすることがわかるでしょう。L2正則化の式は原点中心の山なので、元の山（頂点がどこだかわからない）に足すと、必ず頂点は0に近づきます。ここで大事なのは、頂点の”値”ではなくて”位置”です。求めたいのは最小値をとる引数です。このとききれいな山になるのですが、滑らかな曲線に滑らかな曲線を足したんだから、滑らかな曲線ができるに決まってます（目的関数が滑らかな場合）。目的関数の頂点の位置にかかわらず0に近づく、しかし0にはならないことは明白です。これが、L2でパラメタの値が小さくなる、しかし0につぶれない理由です。

では、L1だったら？ L1は下のような形をしています。尖ってます。

足したときの形というのは、0で折り曲がるのは（微分できない）確実ですが、元の目的関数の形に依存して以下の2種類が考えられます。ひとつは依然として0以外のところで最適値をとるケース。もう一方は0でぱきっと折れて、0が最適値になるケースです。

先ほど書いたとおり、本当の目的関数は多次元ですから、0になる次元とならない次元があります。この、0になる次元というのが、0につぶれる次元ということです。
ではどういう次元が0につぶれるのでしょう。正則化項を足した後の関数を微分すれば関数の傾きがわかります。0の前後で傾きの正負が変われば0につぶれることがわかります。正則化項の傾きは0の前後でそれぞれ一定ですので、結局目的関数の0の周辺での傾き（微分）の大小によって決定されると理解できそうです。

さて、この傾きが@hillbigさんのいうところの「0に向かって押す力」です。目的関数は自分の頂点（≠0）に向かってみんなで押していて、その力は頂点からの距離で変わります。一方、正則化項は一定の力で0に向かって押しています。両者の大きさの大小は場所によって違うということです。正則化項の押す力のほうが0近辺で強ければ、目的関数の押す力は負けてしまいますので0の前後で正則化項の力に負けて最適点は0になります。すると、先ほどのぱきっと折れた後者のグラフ、0で最適値をとるグラフになるわけですね。

言語処理学会年次大会2011に参加しました

2011-03-13T19:59:00.003+09:00

先週は月曜から金曜まで、豊橋技術科学大学で開催されいていた言語処理学会年次大会に参加しました。会場がホテルから遠いとか、駅から遠いとか、豊橋技科大出身の友人が何にもないよとか言ってて不安でしたが、梅村先生はじめ、技科大のスタッフの尽力のおかげでこれといった不便はありませんでした。初日に暖房が効いてなくて死ぬかと思いましたが、次の日から改善されていました。あったとすれば、「たかり事件」くらいでしょうかｗ

私の発表は、若手の会での発表の続きで、表現統一のために既存文書の頻出表現を動的に取り出して入力支援に活かす話です。予測入力とおもってもいいと思います。主に若手の会で@nokunoさんに質問された、頻出Nグラムを使う方法とどう違うのか、という回答をしたつもりです。文書のクオリティーを上げるために表現統一を実現したいというモチベーションと、他手法と比べて文字列集合を探索する定式化をしていたり、単語単位を使っていないなどの比較がメインでした。手法の概要も話しましたが、かなり長いので、ほとんど省いてなんか大変なんだねというのが伝わる程度にしました。ざっくり書くと、KWICをコンパクトに表示すれば入力支援に使えると思い立ち、文字列集合に対するスコア関数を最大化させる形に定式化して、TRIEや接尾辞木などの文字列テクを駆使して実時間で実行出来るレベルにチューンしました。ちょっと笑いもとれたので良かったです。論文はこちらのサイトにおいてあります。

Google、Microsoft、ジャストシステム、Appleと日本語入力をやっている企業から、ChaIME、Social IMEの開発者まで参加するオールスター的なセッションだったにも関わらず、不自然言語処理の裏セッションになってしまって聴衆を取られたっぽかったです。しかし、かなりクオリティーの高い議論ができた気がします。ちなみに、金曜に地震の影響で延泊したとき、さらに濃密なIME話を聞けて鼻血でそうでしたｗ

坪井さん達との共著でNewton CG法をlinear chain CRFに適応した論文も発表しています。Newton CG法はHessianの逆行列（でか過ぎて計算できない）を使う代わりにCG法を使ってNewton方向を求める方法です。この際必要となるのは、Hessianと与えられたベクトルxとの積で、これがHessian vector積と言われる計算。問題は、CRFのように複雑な構造から計算される目的関数のHessian vector積を計算できるのかという点ですが、それを示したのがこの論文でした。入社してしばらくして、ねちねちL-BFGSをつくっていたときに教えてもらった思い出深い手法です。反復ごとの収束がものすごく速くなったのを覚えています。ちょうどSGDが大流行しているときで、出すタイミングを見失っていましたｗ

発表以外では、若手の会、関根会、懇親会、岡野原握手会などの各種イベントに参加して、知り合いが増えました。私は学生時代、研究室の傾向でしょうか、あまり学会に参加しなかったのですが、いろんな知り合いを作るとアドバイスを貰えたり、相談できたり、なによりモチベーションの増加につながります。業界を俯瞰するにも役立ちます。最近は勉強会などもありますし、特にここを読んでくれている学生の方は外に出てみることをおすすめしますよ。

コンピュータがクイズチャンピオン破る

2011-02-17T21:29:00.004+09:00

今日という日は自然言語処理業界はもとより，コンピュータの歴史の中で大変重要な日になったことでしょう．IBMのProject Watsonが，アメリカの人気クイズ番組Jeopardy!で，歴代のチャンピオンに勝利したのです．

ＩＢＭスパコン、クイズ王者２人と対決し完勝　米番組
コンピュータWatson vs クイズ王の対戦 - Jeopardy!

このプロジェクトは私が入社したころからすでに始まっていて，こういうチャレンジは本当にすごいなぁ，と思っていました．本当はこの日記も対戦日が決まったときに書こうと思って忘れていたのですが．

では，何がそんなに画期的なのか．それは，クイズに答える，もう少し汎用的に言えば質問に答える，という作業はコンピュータにとってもっとも難しいタスクのひとつなのだということです．自然言語処理のタスクのひとつで，Question Answering (QA) と呼ばれます．Googleがあるだろう，難しいことはないだろう，と思われるかもしれません．検索 (Information Retrieval; IR) はQAの一段前のタスクで，QAはもう一段難しくなります．では，何が難しいのか．それは，質問文をそのまま検索しても答えはでてこない，というところです．たとえば，「1715年9月1日ルイ14世は，自身が建てた宮殿のある，この都市で死にました」という問題．答えはベルサイユです．どうでしょう，この質問文そのものをGoogleに投げて，検索結果から機械的に「ベルサイユ」という単語を抜き出せるでしょうか．たとえば，「この都市」と書いてあるから都市名に違いない，都市名のデータベースをもっておいて参照するなどが必要です．しかし，検索結果をちらりと見ると，「パリ」などの別の都市名もたくさん見られます．この中から正しく「ベルサイユ」を当てるのはそんなに簡単なことではありません．と，書いておきますが頻度が高いのでベルサイユを選ぶのは割りと簡単でしょう：）　問題がもっと複雑で，「ベルサイユ宮殿を建てた人が死んだのはいつでしょう」なんて問題になると，問題を2段階に解かないといけません．
コンピュータは決められた演算を高速に大量に処理する道具です．一方で，こうした推論を直接行うことはできず，人間は逆にこの推論をきわめて高速に正確に行います．こうした人間の推論を機械的な手順に落とすことは現代になっても難しく，言語のような曖昧でもやもやしたものの扱いはいまだに簡単なことしかできないのです．いかにコンピュータが高性能になったとしても，どうやったら推論を演算に直せるのか．こうした部分に，このチャレンジの難しさがあるのです．
ところでGoogleなどの検索エンジンのすばらしさというのは，このもっとも難しい「推論」の部分を人間に任せて，検索を行うという「演算」の部分だけに注力しているところだと思っています．そして，人間の「推論」をサポートするようなサマリーやランキングに注力することで，直接「推論」しなくても十分有用なツールに仕上げている点もすばらしいと思います．実は私はこういう，一番伸びしろのあるところをやれ的な考え方の方が好きで，QAというタスクは無駄に難しいところに注力しているようであまり好きではありませんｗ

よく，この対決をすばらしいコンピュータ性能の進歩と捉える記述が目立ちます．たとえばCPUの性能や記憶容量などの記述です．それは真実なのですが，もっとも重要な点が抜け落ちているように感じます．コンピュータがすばらしい演算性能を達成してきた，という事実は何もクイズに答えなくても，さまざまなスーパーコンピュータの出現やそれによる大規模なシミュレーションなどのアプリケーションですでに示されてきた過去があります．しかし，そうしたことが可能となった現代においても，特定のクイズ形式に答えるという形に限ったとしても，人間と同等の質問応答を達成することは過去に一度もなかったのです．今の1000倍の時間がかかってもいいから同じアプリケーションが今までにできたかというと，そんなことはなかったのです．
コンピュータの行う「演算」と，人間の行う「推論」には大きなギャップがあります．よく，人間の「推論」を模倣したわけではない，コンピュータの「演算」で無理やり解いたに過ぎない，と反論する方がいらっしゃいます．しかし，手法がどうあれ人間と同等の「結果」を出すことが，少なくともクイズに関して可能になったことがはじめて確認されたのです．鳥のように羽ばたくわけではないが，飛行機が空を飛んだようなものです．それは，今までに誰も実現できないことが可能になった瞬間なのです．それを可能にしたのは，単純にエンジンの性能（コンピュータの性能）の向上のみではなく，羽やプロペラなどの画期的な発明（自然言語処理技術，検索技術，機械学習技術）の賜物だったのです（いや，飛行機あんまり知らないけど・・・）．まぁ，あれです．ボクらもがんばってるんだよアピールですｗ

さて，最後に．チェスのときもそうですが，機械という異生物に人間が敗北したのだ，という見方をされる方をたまに見ます．しかし，こうしたものを作り上げてきたのが，技術者や研究者などのまぎれもない人間だということを忘れないで欲しいのです．この勝利は，人間の技術が人知に対して部分的に勝利した，それはまさしく人間の勝利なのです．

ズームレンズに関する誤解

2011-02-10T23:55:00.004+09:00

最近，会社の人と話していて，ズームレンズに関してすごく誤解されていることがよくわかった．しかし，思い返してみれば一眼レフを買うまで私も同じ誤解をしていたので，決して責めてはいけない．つまり，

ズームというのは，遠くのものを「大きく写す」，という意味でのズームでは決してない

ということだ．カメラの世界ではこれを「望遠」という．反対語は「広角」．「ズーム」は別の概念．なので，「遠くまで写せて，すごいズームですね」というのは，「データをいくらでも保存できて，すごいCPUですね」と同じくらい変な指摘なのだ．もちろん，同じ世代ならHDD容量とCPUの速度に正の相関があるくらいには納得できる（高倍率ズームなら超望遠である可能性が高い）．
では肝心のズームとはなにか．ズームとは，1つのレンズで異なる大きさに写せるレンズのことだ．反意語は単焦点．つまり，自分が動かなくても大きさを変えられるということだ．なので，たとえば大きく写せる単焦点も，小さく写るズームもある．

さて，次の誤解．誤解というか勘違いだが．上の説明で，大きく写せると書いたがこれは正確ではない．なぜなら，そもそも近づけばどんなレンズでも大きく写せるからだ．正確には，狭い範囲だけを写すレンズ，というのが正しい．狭い範囲だけを同じサイズに引き延ばせば，当然拡大される．そういう仕組みだ．この範囲のことを画角という，がふつうかかれていない．これは，焦点距離とセンサーのサイズで決まる．センサーサイズはふつう固定なので，焦点距離で判断する．なので，○○mmとかかれているのだ．しかし，この説明はなかなか納得してくれない．だって大きく写るじゃないか．では，何を基準にして何倍大きいというのだろう．先ほど書いたとおり，そもそも近づけば大きくなるのに何を基準にするんだろうか．昨日，これに関してよい説明を見つけた．

倍率って何なの？

（略）例えば35mm一眼レフだと焦点距離50mmレンズの倍率がおおむね肉眼と等しい１倍とされている。焦点距離が4倍の200mmレンズなら倍率も4倍、500mmだと10倍と考えることができるわけだ。（略）

これはわかりやすい．肉眼に比べて何倍くらいに見えるか，という指標を見るなら，スペック表の望遠側（○○mmとかいてあるなかの数値の大きい方）の数字を50で割ろう．これが，きっとあなたの求めている「倍率」だ．

では，光学30倍ズーム，とかいってる30倍ってなんなの？　これは先ほど書いた，「肉眼と比べた倍率」のことではない．これは，ズームレンズの広角側と望遠側の比のことだ．たとえば，25-300mmのズームレンズは，12倍ズームだ．ここで注意しよう．これは，肉眼の12倍のことではない．広角側が25mmなので，肉眼の1/2倍，そして望遠側が300mmなので肉眼の6倍．この差が12倍と言っているのだ．
意外と驚かれた実例を見てみよう．
ソニー、30倍ズームの「サイバーショットDSC-HX100V」を国内発表
ニコン、広角端22.5mmからの光学36倍ズームレンズ搭載機
タイトルの情報だけでは望遠の能力，つまり肉眼の何倍かはわからない．スペック表を見てみよう．前者は27-810mm，後者は22.5-810mm．最大で肉眼の何倍に写るか，という点で両者は同じである．繰り返す，30倍ズームと36倍ズームだが，見える大きさの最大は同じだ．どこに違いがあるかというと，広角側だ．これはどれくらい小さく写せるか，言葉を換えるとどれくらい広い範囲を写せるかだ．飲み会の会場のような狭い空間で複数人を撮るときなどに威力を発揮する．この点でニコンに軍配が上がっているということだ．

最後の誤解．光学ズームは画像の劣化がない．ウソだ．レンズはもちろん高校物理で習ったスネルの法則を利用している．しかし，あのとき習った理想的なレンズというのは世の中に存在できない．なぜか．簡単な話だ．波長によって屈折率が違うからだ（他にも理由があるかもしれないが，これが一番簡単に説明できる）．波長によって光の進み方が違うのに，どうして1点で交わるというのだ．たとえば今お使いのめがねの端の方を見てみよう．黒い物体と白い物体の境界に赤か青の線が見えないだろうか．
聞きかじった程度の知識だが，レンズ設計とはこれがいい塩梅になるように屈折率や焦点距離の異なるレンズを複数組み合わせて妥協点を見つけることだ．昔は職人芸だったらしいが，今では計算機で行う．ズームレンズはこれがさらに難しい．あらゆる焦点距離でそこそこいい感じにしないと行けないからだ．ズーム倍率が大きくなれば大きくなるほど難しくなる．なので，倍率の高いカメラを買った割に画質があがった気がしなかったとしてもお門違いというわけだ．高倍率ズームは画質ではなく便利さを買っているのだ．交換無しで（コンデジの時点でできないが・・・），あらゆる焦点距離を使えるというのはフットワークの軽さを高めてくれる．

ところで，先ほど書いたとおり50mmが標準と言われるのだが，ふつうのコンデジはこれよりも広角がデフォルトになっていることが多いと思う．なぜか．これは，私の予想だが広角の方が失敗が少ないからだ．典型的な失敗は2つ．一つは手ぶれ，もう一つはピンぼけ．広角はどちらも起こりにくい．広角というのは，画角が広い．なので，たとえば10度の望遠レンズを使って1度分手ぶれしたら，10％もぶれていることになるのだが，100度の広角なら1％くらいだ．さらに，広角の方が広い範囲から光を集めるので，シャッタースピードが速い．速いと言うことはぶれる時間も少ない．ピンぼけに関しては，望遠の方がピントの合っている領域（被写界深度）が狭い．広角の方がひろい．ということは，広角ならだいたいピントがあう．そんなわけで，巷では広角写真があふれかえっていて，中望遠くらいが好きな私としては若干うんざり気味なのである．

第200回NL研に参加しました

2011-02-01T00:21:00.003+09:00

先週，SIG-NL 200に聴講者として参加しました．NHK放送技研に潜入できる！と意気揚々と行ったのですが，どうやら建物自体には入れず，脇にある講堂のようなところが会場でした．中に入ったからといって何があるというわけでもないんですが．

さて，第200回記念ということで，歴代主査の先生も呼んでパネル討論まであったのですが，参加人数はイマイチ．少々寂しい．パネル討論でも最近盛り上がりに欠けるよね，というのが大きな一つのテーマでした．詳細は@mamorukさんのブログを参照．私の印象としては，発表者のインセンティブになるようなメリット，つまりアドバイスやコメントや議論が少ないというのが一番よくないなぁと思っています．発表すると関連研究を教えてもらえる，アドバイスをもらえる，新しい発想が得られる，これはよいまた発表しよう，新しい発表が聞ける，また聞きに行こう，というサイクルが回れば参加者も増えそうですが，今はその逆になっているように思います．これに限らず，発表準備はそれなりにコストのかかることなわけで，発表者にインセンティブが働く仕組みがなければ勉強会でも何でも続かないですよね．経験的にも・・・．
討論の中で印象的だったのは，松本先生の「何となくみんな忙しい」という言葉でした．なるべく多くの研究者が集まった方がいいとは思いますが，仕事が「何となく」忙しいと難しいですよね，何となく．めちゃくちゃ忙しいはずの（実際は知らないけど）松本先生が，毎回のようにいらしているのはすごいなぁといつも感服します．自分も忙しいとか言ってないでちゃんと時間を見つけられるようにしないと．

発表で気になったのはロンゴロンゴでした．完全にタイトルでだまされましたｗ　昨年の5月も聴講したので発表を聞くのは2回目ですが，すごい楽しそうに研究していて，いいなぁと思っていました．たまたま帰りのバスで一緒になったので，色々教えてもらいました．未解読言語の解析というのはわくわくしますね．

電子書籍はじめました

2011-01-23T21:01:00.001+09:00

@hillbigさんが絶賛していたので，昨年末Kindleを買いました．そして，最近ようやく届きました．早速使ってみたのですが，これはいい！　

良い点

軽い
ボタンなので片手で操作できる
見やすい
電池長持ち

悪い点

日本語の書籍が無い
同期周りの機能がいまいち

一番の印象は軽いということです．iPadは常に持ち歩くには重いです．私は休日などは小さめのかばんを持ち歩くのですが，iPadでは大きくて入りません．そして，実は大事なのがボタン操作という点です．古臭いという人もいるかと思いますが，ボタンのおかげで持っていてでそのまま次ページボタンが押せます．片手で読めます．手袋をしていても読めます．500ページのハードカバーの洋書が片手でサクサク読める．小さなところですが，新しい読書スタイルという感じで感動しますよ．他の2点は省略．
日本語書籍がamazonから購入できないのは周知の事実ですが，いろいろな経路で発売され始めているところを見るに，今年中にはamazonからも発売されるんじゃないでしょうか．機能面で気になるのは同期周りの機能がいまいちな点です．amazonで買った書籍は自動同期されますが，その他は自分でコピーしないといけません．しかも，カテゴリわけなどはKindle側で振り分ける必要があるみたいです．ACL2010の論文を全部入れたら全部手動で振り分ける羽目になって泣けます．それから，ファイル名での検索ができないようで，これも泣けます．いくつか改善して欲しい点もありますが，次期バージョンで改善されることを期待します．

論文読むツールとしてどうなの？という議論は以前からありましたが個人的にはこれでOKという結論に至りました．縦位置にするとさすがに文字が小さいですが，横にしてスクロールすれば普通に読めます．本当は余白部分を自動トリミングして欲しいです．最初，1/4分割するツールを使おうかと思いましたが，面倒なので辞めました．横位置で十分です．メモ書きなどは一応できますが，日本語入力できませんね・・・・．
自炊環境はちょっと迷い中です．新書や文庫もよく読むので，それをKindleにしたいのですが，そのためにうん万かけて裁断機とスキャナとか買うのはちょっとなぁと思ってます．自分の「読み」としては，今年中にKindle用の日本の書籍が出回ることを期待しています．

さて，Kindleはデバイスとしてみればまったくパッとしない時代遅れな印象すらあります．しかし，個人的にはそこにだまされてはいけないと思ってます．iPadもそうなのですが，よく「こんなデバイスは日本企業なら作れるよ」とう議論を聞きます．きっとそれは本当なんですが，そこよりもこういうデバイスがあればこういうすばらしい使い方ができるよ，ということを示したところに，iPadもKindleもすばらしいところがあるんだと思います．例えば，Whisper Syncとか．そうした周辺サービスも含めてデバイスを見ないと．Kindleをもっと高機能でもっとfancyなデバイスにすることはできたはずですが，読書ツールとして考えたときに，バッテリーのもちとシンプルな操作体系が優先されたんではないかと思います．

本年もよろしくお願いします

2011-01-06T23:31:00.002+09:00

あけましておめでとうございます。無事に新年を迎えました。
毎年恒例の今年の目標など。のまえに、昨年の目標なんだったっけ？から。

2010年の目標

見事に達成されていませんねｗ

論文は結局100本くらいでした。後半仕事が忙しくなったのが敗因。質より量でどかっと読めるようになりたい
論文紹介は1Qくらいしか続きませんでしたｗ
国内発表は3回でした。4Qで発表しようと思ってた内容が特許審査に詰まってしまったのが原因のひとつ
海外発表はことごとく落ちました（泣
特許は4つ書いて3つ社内審査に受かりました

もうちょっとがんばれると思ってましたが、仕事が忙しくなるとなかなか手が回らなくなります。もっとがんばろう。
他、

車は1回だけ運転しました。7年ぶりくらい
写真は結局7000枚くらいでした
コンテストは2回くらいしか応募してないな。もうちょっと作品を意識して撮りたい
研究会イベントは@nokunoさんイベントなどで発表させていただいた
semi-supervisedは本を読んで終わってしまった
パン焼いた、ケーキ焼いた、そば打った

今年の目標ですが、もう少し視野を広げられるようになりたいです。研究もしかり、会社とか経済とか興味の続く限り片っ端から勉強できればいいな、と思います。でも、初詣で引いたおみくじには、いろいろやりすぎるな的なことが書かれていたな・・・

自然言語処理勉強会@東京に参加しました

2010-11-07T23:37:00.003+09:00

@nokunoさん主催の自然言語処理勉強会@東京で「統計的係り受け解析入門」というタイトルで話をしてきました．資料はこちらにおいておきます．CKYアルゴリズムに関して質問が多かったので，説明を加筆しました．

内容は「入門」と銘打っておきながら，3rd order Eisnerまで紹介するアレな内容．どういう方が出席されるかわからなかったので，ちょっと最新の話題も入れてみたかったのでした．もともと社内セミナーで使った資料を半分流用しています．
Eisner法の理解の肝は，三角と台形がCFGにおける非終端記号に相当している，三角が三角と台形に分割されるというルールが，CFGにおける書き換え規則に相当している，という点が理解できれば後はCFGの知識で理解できます．この記法に慣れてくると，例えば3rd orderの論文はほとんど図を見るだけで理解できます :)
割愛しましたが，本当はこのあとスコアをどうやって学習するかという話しに行きます．log-linearにして，微分するとinside-outsideがでてきたり，周辺確率がinsideとoutsideの積で求まったりします．当然logsumexpもつかいますし，動的計画法のオンパレードです．

学会と違って，企業の方が多かったのもありますが，どうやって応用するのかという議論がいたるところでなされました．これは非常に良いことだと思います．学術的には興味を誘わない話題，特に強調した分野適応や辞書リソースの効率的な構築法などは応用上きわめて重要だと考えています．学生時代分野適応なんて，特許かWebデータに適応することだろくらいに高をくくっていましたが，実際には特定分野のお客様（例えば製造業，医療，法律，銀行）にいかに効率的に分野適応できるかが性能の鍵を握っています．こうした問題意識と研究テーマをもっと啓蒙していかないとと思っています．MeCab以来教師あり形態素解析が進んでいませんが，こうした部分でものすごく問題を抱えたまま放置されている気がします．まぁ，自分がやればいいんですけどね．

商品開発力

2010-09-29T23:20:00.000+09:00

フォトキナを睨んでか，8月あたりからデジタル一眼レフに関して自分の感覚では革命的といわれうるような大きな流れをみました．一つはソニー，もう一つはキヤノンです．日経○○をよく読むのですが，その中で将来のイメージセンサやデジタルカメラがどうなるのか，という予想，ロードマップのようなインタビュー記事を読みました．ここ数年で劇的に変わってきた，感覚的ですがそれはまさにコンピュータ屋がハードづくりからソフトづくり，そしてサービスづくりに変わっていったようなものに似ているのかなという印象を受けました．

最近，デジカメ界で話題をさらいまくっているのがソニー陣営でしょう．超小型のミラーレスなのにAPS-CのNEXは衝撃的で，しかも市場にも受け入れられているようです．しかし，先日発表されたα55とα33，これは私の中ではさらに衝撃的でした．メインストリームクラスの一眼レフに電子ビューファインダーを採用という点です．不可侵にして犯さざるべからずだったファインダーがついに，という感じです．将来的に光学ファインダーは絶滅するだろう，というような予想をされている方は過去にも見たことがあるのですが，こんなに早く，いやもうそういう上位機種でも実用段階に来ているんだと思わされました．加えて，透過光ミラー．従来のカメラ造りをする時代ではないんだよ，というような主張，気概が最近のソニーのものづくりには滲み出ているように感じます．

もう一社，衝撃的なニュースを連発したのがキヤノンでした．1億2000万画素のCMOSセンサー（従来の7.5倍）と，20cm x 20cmの巨大CMOSセンサーの開発（従来の40倍）です．どちらのニュースも目を疑いました．半導体開発に関して素人なのですごさの10％も理解できてないんでしょうが，簡単に集積度を上げられるとも思いませんし，巨大化すると歩留まりも劇的に悪くなる気がします．ただ，素人目でもはっきりと「躍進」とわかるような変化を作れるだけのパワーと度胸には感服します．

最近というわけでもないですが，他に注目株なのがパナソニックとサムスンでしょうか．こうした家電メーカーの方が斬新なアイデア，顧客のニーズ，新しい取り組みに積極的，またそれを遂行するだけの基礎体力が備わっているように感じてしまいます．ソニーはαとサイバーショットの2つの血がうまく結合したのかな，と思います．こうした点は古株の職人気質なメーカーは，折角の技術力を生かしきれずに歯がゆく感じます．我らがPentaxもK-5を発表しましたが，やはりセンサーが変わった以上のインパクトを出せていないのかなと．最近のPentaxのデザイン路線は，デザイン好きとしては好感が持てますし，そうしたニーズは確実に存在するので力を入れていって他社と違うモノづくりをして欲しいところです．

NLP若手の会シンポジウム

2010-09-18T09:18:00.004+09:00

NLP若手の会シンポジウムで発表しました．前々から何度も参加はしてたんですが，発表は初めて．タイトルは緩い感じの会議ですが，発表者も参加者も30台前後のポスドクや助教，博士課程学生が中心で，議論も活発，新規な内容が多い．特に自分の同世代，近い世代の人たちがこんなに活躍しているというのを見れて，とてもよい刺激になります．そういうのは，会議の前に書けって？　すいません．

私の発表の内容なんですが，一言で言うとKWIC (KeyWord In Context)をかっちょよくしました，という内容です（片側しか見てないからKWICじゃ無いじゃん，と突っ込まれました．実は事前に坪井さんにも突っ込まれてました）．KWICは検索結果を俯瞰するのに便利なんですが，ヒット数が多いと全体を見られなくなります．なので，うまい単位でまとめたい．これを探索問題として定式化してあげると，動的計画法に落とし込めます．さらに，最大値を求めるということは，一番最大っぽいところを探索したら，残りはそれを超えないことを確認すればOKという感じで，スコアの上限を求める関数で枝刈りをします．最後に，あらかじめ接尾辞木を頻度順に並べておくことで，TRIEの構築もサボれます．もともと，入力支援に使おうと思っていて，発表の1週間前に狙ったようにGoogle Scribeがでて困りました．デモ画面そっくり．
枝刈りのアイデアは，オセロのαβ枝刈りからインスパイアされました．αβ枝刈りは，最大値を求めるときに，超えなければいけない上限を渡して探索する方法です．学部時代にオセロプログラム大会をやったことがあって，move orderingとか色々知識を持っていました．どこでどういう知識が役にたつかなんてわからない，知れる機会があれば何でも知るべき，ということを少し体現できたかなと思います．

他の発表ですが，奨励賞の松林さんは同じセッションで聞けなかったのが残念．高村さんの語彙をつくる話は，「言語とは何ぞや」という問題に対して新しいアプローチで迫っていて面白かったです．私ももっと夢のある話をした方がよかったかなぁ．それから，内田さんがオノマトペと動詞の対応みたいな話をしてました．一応，私も言語処理学会でオノマトペネタを（共著で）発表したので気になります．当時色々アイデアを出して，ほとんどやってなかったので少しやろうかな．

いくつか聞いてて，やっぱり自分は応用よりだ，と思いました．工藤さんの講演での回帰テストの話とか，それに対する岡野原さんの質問とか，T2ミーティングでの橋本さんの話とかがやっぱり自分にはピンとくるところがあって，企業系の人（あるいはアプリ屋さん）がもってる問題意識とアカデミックの問題意識でギャップが進んでいるように思いました．もっとも，そこはちゃんと住み分けが進んでていいとも思っています．むしろ，アカデミックには短期の実用より，長期的に見て必要な基礎研究を進めて欲しい．ただ実用まで持っていくにはこれだけ必要なステップがあるよ，そしてどこも手を抜けないよ，ということが一歩引いたところから俯瞰して共有できればいいなと思います．

logsumexpとスケーリング法

2010-09-06T00:09:00.004+09:00

少し前にtwitter上でCRFSuiteはスケーリング法を使っているから速い，的なことを書いたのでその解説です．

linear-chain CRFのパラメタ推定に必要なのは対数尤度関数の微分です．これの計算に必要なのが，前向き・後ろ向きのスコアαとβです．時刻t（系列上での位置）とラベルiに対する前向きスコアαは，以下の式で計算されます．fは特徴ベクトル，wは重みベクトルです．

ところがこのままだと問題が起こります．αの値はexp個の足し算で構成されるため，最終的にかなり大きくて，簡単に倍精度の限界を超えてしまうのです．困った．そこで，logの世界に落とします．αの代わりにlog(α)を計算します．すると，expの世界の掛け算はlogの世界の足し算になります．問題は，足し算です．expの世界の足し算を，logの世界で行う２項関数がlogsumexpです．

で定義されます．expをかけてるから，結局オーバーフローしてしまうように見えますが，以下のように式変形することで，見事にオーバーフローしなくなりました．ただし，y < x とします．

これを使うとlogαの計算は以下のようになります．

ここまでがlogsumexpの話．

logsumexpを使い出すと，今までただの足し算でよかったのにlogやらexpやら，いかにも重そうな関数を使わなくてはならなくて激しく遅くなります．できる事ならexpの世界のまま計算したい．そこで使われるのがスケーリング法です．ここで大事な点を思い出します．最後に計算したかったのは周辺確率です．つまり，0から1の間に収まるような値が出力です．最後にZで割れば，彼らは器用にoverflowもunderflowもおこしません．ということは，少しずつ割っていって，最終的にZで割った値が出るように調整してあげれば，オーバーフローせずに計算が終わるはずです．

時刻 t ごとに和が 1 になるように正規化したα'を以下で定義します．

これを，普通のα同様にα'の再帰計算で計算できればlogの世界で計算する必要がなくなるという寸法です．結局α'は，毎時刻ごとに1になるように正規化しているだけなので，正規化するときに割った値を覚えておけばよいのでした．ちなみにこのテクは，PRMLのHMM（だったかな？）の章に書いてあります．って教わりました．

ところで，これで本当に速くなるんでしょうか．改めてαの式とlogαの式を見返して見ます．確かにαにはlogsumexpがありません．しかし，logαでは実は重みベクトルと特徴ベクトルの内積に対するexpが消えました．結局，logsumexpの代わりにexpになっただけ，このままではexpの実行回数で両者に差がありません．ここにもう一つトリックが存在します．一般にlinear-chain CRFではラベル遷移の特徴（遷移素性）と各時刻ごとの特徴（状態素性）は別々にあらわされます．つまり，

という2種類の特徴量に分けられています．ラベル数L，文長Tとします．これらのexpはあらかじめ計算しておくと，必要なexpの計算量はO(TL + L²)，一方でlogαではO(TL²)．結果的にαを直接計算した方が，つまりスケーリング法の方が速くなるのでした．

ところで，そんなわけで私も以前スケーリング法を実装したのですが，なんだか思わぬタイミングでoverflowやunderflowを起こしてしまいます．なので，私も完璧に理解したわけではありません．まだ実装上のテクニックがあるのかもしれません．logsumexpもスケーリング法も，たまたま何かで見たり，たまたま教えてもらったり，罠がいっぱい．

高速な復元抽出の直感的な説明

2010-07-29T22:57:00.010+09:00

先日@niamさんと@tsubosakaさんのつぶやきを見てて，確率{p_i}で復元抽出するWalker's alias methodというものを知りました．たまたま，今日，復元抽出する用事があったので，思い出して調べた次第．私も昔同じことをやろうとして，O(log n)でいけるからまぁいいやと思っていたのですが，このアルゴリズムだとO(1)でいけます．

解説はこのあたりのブログを参照．

さて，私は理解力が足りなくてこのあたりの説明を読んでもなんでこれでいいのかさっぱりわからなかったので，絵に描いて理解しました．確率{p_i}で復元抽出するためには，p_iに比例した面積の図形を壁に貼ってダーツをすればいいのです．{0.1, 0.05, 0.3, 0.1, 0.45}だったとします．するとこんなの．

まさか毎回ダーツ投げさせる訳にもいかないので，randを呼びます．でも，これでは何がうれしいのかわかりません．四角形にしてみましょう．

ちょっとうれしさがわかってきました．rand.nextDouble()の値が，たとえば0.2から0.4の間なら橙にすればよいのです．このおおざっぱな0.2ずつの区間のことをここではブロックとでも読んでおきましょう．ところが，0から0.2の間ならどうでしょう．3色もあります．もっと詰まっていたら．やっぱり2分探索が必要な気がします．そこで，一つのブロックの中に高々2種類しかないような区切り方はできないでしょうか．できます．これができれば1回比較すればよいだけです．ブロックをnこ（ここでは5個）用意すれば可能です．こんな感じ．
randが0から0.2なら，つまり5倍してintにキャスとして0だったら，もう一度0.1以上か否かチェックして，以下なら青，以上なら橙を返せばOK．このブロックを作ってるのがWalker's alias algorithmです．まず，p_iをn倍したものをq_iとします．q_i < 1のものに一つずつブロックを割り当てます．図だと，青赤緑．次に，残った q_i > 1のものはq_i < 1が消費したブロックのあまりにとりあえず詰めていき，1以下になったら新しいブロックに割り当てます．橙は青と赤のあまりに詰めたところで1以下になったので，新しいブロックをもらいました．灰は残りに割り当てて完了．割り当て数はn個，上記の方法なら各ブロックごとに新しいブロックを一つずつしか消費しないので，最大でもn個ブロックがあれば十分なことがわかります．保存すべき情報は，各ブロックごとに境界となっている位置，2種類の色です．片方の色はインデックスと一致させておけばよいので，境界ともう一方の色だけ覚えればよいのでした．

ちょっとあまりに見事な方法だったので記事にしてみました．

3D映画と視差とボケ

2010-07-26T02:03:00.000+09:00

ちょっと前に会社の人とAlice in Wonderlandを観にいきました．もちろん，ここで映画の感想うんぬんを語る気は毛頭なくて，最近妙に流行りだした3D映画といわれる技術に関してです．

2次元のスクリーン上に映し出された映像で立体物を見ているような感覚を得られる原理の基本は，両眼視差による効果です．左右の目に別々の画像を見せているわけです．立体視の方法は他にも色々あるわけですが，もう一つの代表的な方法が目の焦点によるものです．つまり，ピント．3D映画の場合，スクリーンまでの距離は一定なので，この方法で奥行きを認識できません．感じた違和感の一つはたぶんこれです．両眼視差的にはこのくらいの距離のはずなのに，ピントは別のところにあってるなぁ，という感覚．しかし，たぶんもっと感じた違和感はそこではなくて，ボケのせいだと思います．焦点の合ってない部分はボケて見えるわけですが，写真や動画でももちろん焦点の合ってない部分はボケますし，特に強調されて撮影されます．これに，3D映画の両眼視差を組み合わせると変な感覚がするのです．

そもそも写真とか動画においてボケというのは表現手法の一つなわけですよね．自分の感覚では，人間の目は典型的な写真や映画ほど被写界深度が浅くない（それほどボケてない）のですが，意識が行ってないもの，あるいは視差のあってないものの情報はほとんど入ってこないように感じます．この，情報の入ってこない感覚を2次元の写真や動画で表現するために，人間の目よりも大きなボケで表現しているんだと考えています．写真を見ると全体にフォーカスがあうので，実際の目よりもボケを強調した方が，実際の認識に近い感覚が得られるんだと思います．そのため，2次元で見せるときはボケを強調する必要があったわけですが，今の3D映画はこの強調されたボケをそのまま取り込んでいます．
現状の3D映画を見る限り，両方がごっちゃになっていて妙な違和感を感じます．具体的に言うと，画像的にボケてる部分を見たときボケてるのに視差は合っていて，そのとき画像的にボケてないところは視差が合わないということが起こります．何だろうこれは．彫刻の一部に「ボケ」といってもやもやした謎の物体が置かれてる感覚です．画像的にぼけている部分に視差をあわせられてしまうのが問題の気もします．まだ黎明期ということで，これから新しい表現方法が作られていくでしょう．そちらに期待．あるいはパンフォーカスっぽい表現が流行るのかもしれません．

NTCIR-8 Patent Mining Task

2010-07-07T23:36:00.004+09:00

ちょっと報告が遅れましたが，会議には参加してませんが，NTCIR-8のPatent Mining Taskに，チーム西山の隊員として参加しました．タスクの内容は，特許文書中からその特許が解決したい課題や効果がかかれたフレーズを抜き出すというものです．結果的に参加チーム中で結構いい順位につけたということで，論文も公開されています．実は私がポカしたせいで，本当はもう少し結果よかったです（後述）．

正解付与済みデータが与えられるということで，CRFを使った教師あり学習の枠組みに，おのおのの得意とする特徴量をこれでもかとてんこ盛りに入れ込みました．正解データを見る限り，明らかに係り関係にある単語や文節が分類に貢献していることがわかったので，私に召集令状が係った次第です．特に特許文書は一文が長く，構文解析が難しいので，NLP2010で発表したような距離期待値のテクでロバストになることを期待しました．近いものほど大きな値にするために，純粋なホップ数ではなく，0.5のホップ数乗（1ホップ遠ざかるごとに値が半分になる）の期待値の近似値を計算します．E[0.5^{(ホップ数)}]です．これも，NLP2010の方法と同種の動的計画法で効率的に計算できます．この値を特徴量の値，係り先の単語を次元とするような特徴ベクトルを作ります．他にもたくさん特徴量があるんですが，割愛します．他と比べても，この特徴量はそこそこ貢献したようです．
さて，期待値を使うのとOne-bestを使うのでどちらがよいのかという点ですが，論文でははっきりと言及してませんがかなり微差でした．一応期待値の方がよさげなんですが，微差です．有意差があるかどうか怪しい．いくつか理由はありますが，まず係り受け解析はそこそこ”簡単な”タスクだということ．8割は正解するので．それから，特徴量の値としてだけ使っているので，必ずしもすべての係り関係が正解に寄与している訳ではなさそう，という点です．このexp関数を特徴量とする設計が適切かどうかも怪しいですし．ただ，個人的には，こういう「枠組み」は必ずしも構文解析だけではなくて，たとえばもっと難しい語義曖昧性解消や照応解析などのより難しいタスクに応用できたらよいな，と思っています．

あと裏話．係り受け解析の学習には京大コーパスを使っています．すると，Juman品詞体系なので，全段の形態素解析や文節切りもJuman品詞体系に合わせる必要があります．この処理にはMeCabとCabochaを使ったのですが，デフォルトはIPA品詞体系．実験するときに品詞体系はJumanを手動で指定したくせに，モデルファイルの指定を間違えた！　orzorzorz　おかげで文節単位がめちゃくちゃになっていました．論文を書く段になって例を探しているときにこの事実に気づき，あわてて実験し直したら，数ポイントスコアが上がって順位もかわりましたとさ．

Lightroom 3

2010-06-26T21:36:00.002+09:00

昨日Lightroom 3がリリースされました．public betaが出た去年の冬に使ってたのですが，期限切れと同時に，古いバージョンで新しいファイル開けないので，え？これカタログファイルどないせいと？という悲しい状況に陥りました．βを出して，しかもファイルフォーマット変換するなら，発売までは使わせて欲しいな．

さて，使ってみた印象ですが非常に良いです．2をすっ飛ばして1.4からのバージョンアップだったので，一番印象的なのはマルチディスプレイに対応したこと．2画面目の方に画像一覧を，メインディスプレイの方で現像作業をするといい感じです．性能という点以上に使い勝手というのはこういう日常的に使うソフトにはとても大事だと思います．もっともこの昨日は2のころからあります．ということで，3での差分はやはりノイズ除去が強力になったことでしょうか．1.4との比較ですが，ぱっとみでわかるくらい除去性能が上がってます．真っ暗なスポーツバーでW杯観戦したときの，ISO1600，無発光で無理やり撮った写真もきれいになりました．すごい！　ビデオに対応を謳っていますが，単に取り込めるだけで編集はできません．Lightroomとは別に，ファイルコピーする手間が省けたくらいに思っておけばいいんですかね．

1系のユーザー，特にマルチディスプレーのユーザーは即刻かえるべきでしょう．2の人は，どうでしょうね．差分はそんなに大きくないかも．ノイズ除去はRAW現像処理の中でもメインの一つなので，ここをどうみるかでしょう．そんな感じ．

最近のミラーレス事情

2010-06-20T21:01:00.004+09:00

最近いわゆるコンパクトデジカメと，いわゆる一眼レフデジカメの間に出てきたのが，ミラーレス一眼といわれるクラスです．中に鏡が無いので一眼レフよりも小さくできて，レンズは交換できる．やっぱり一眼レフはでかい，重い，で一般受けしないことがわかったので，人に勧めるべきなカメラは何なのか，ビックカメラに行く用があったのでいじくってきました．

主にみてたのはこの3つ，とその下位機種．

まず，一番驚いたのはNEXが意外とよい！　理由は色々ありますが，背面液晶の解像度が異常に高いので，ピントの山を見分けられる．カメラ振った時のリフレッシュが非常に高速．これがちゃんとしてないと，動く物体は追えません．こういうのみてると，光学ファインダーにペンタプリズムなんて技術は，それこそ消えていくのかなぁとか思ってしまいます．そして，APS-Cはやはりコンパクトデジカメと違ってよくぼける．操作感はあまり評価してませんが，F値の調整は意外とやりやすかったです．あと，レンズがでかいのでまったくコンパクトじゃないですｗ　背面液晶なので，晴天時にどれだけみられるか気になります．
次に良かったのがLumixです．電子ビューファインダー（ファインダー内に液晶を使う）の解像度が優れていて，これも応答性能が良くて，ふつうに使えそう．背面液晶でいいジャンと思われるかもしれませんが，晴天時に液晶は見えないので，外の光を遮断して確認できるファインダーは実は重要です．AF時に自動でアップになって，ピントの山も見分けやすい．これは驚いた．
そして，残念だったのがPENでした．何がって，電子ビューファインダーの応答性能が遅すぎる・・・．動くものは追えません．どうもつかっててもしっくりきません．しかも，これつけると形がダサすぎる．デザインがいいので人には勧めてましたが，今後控えるかも．

さて，全体の感想ですが，少ない事例の中で大型家電メーカーが強いなという印象を受けました．ミラーレスというと，今までの既存のカメラ技術（シャッター，ミラー，ペンタプリズム，ファインダーなど）が省略されて，新たに電子ビューファインダーなり背面液晶なり，どちらかといえばカメラメーカーが出がけてなかった新しい技術が必要になります．こういうところの作る込みは，やはりSonyとPanasonicは一歩先を行っている感がありました．特にPanasonicはミラーレスのさきがけとしていち早く商品を出して，そして自分たちに得意とする分野をうまく生かしているように思います．今後どうなるかわかりませんが，ミラーレス市場は一眼レフ市場に比べて拡大するでしょうし，その中でこうした家電メーカー系が伸びそうな気がします．これから参入するメーカーはどうするのでしょうね．どこかと提携するなり，合併するなり，新しい動きがあっても不思議じゃなさそうです．

iPadを買いました

2010-06-13T21:33:00.001+09:00

iPadを買いました。一通り自分が想定していた範囲で使った感想では、70点くらいです。Webや写真周りの出来はとても良いですが、やはり懸念だっpdf周りはいまいちです。入力まわりは想像よりはずっといいですが、手足のようには使いこなせません。それから、safariに対応していないwebページも案外多くて、今書いているbloggerもそのひとつです。

そもそも新しいものぎらいのunnoが何で買ったのかという点から。最初から自宅での利用を想定していました。研究周りの作業は会社のノートPCでやるようになってから、自宅のデスクトップが冗長に感じてきました。うるさいし、ソファーの方がすわっててらくです。実家にいた頃はデスクチェアしか自室になかったですし。気づくと、写真以外はほとんどwebとメールにしか使っていません。朝、ニュースや天気を確認したりするには起動も遅すぎます。最初ネットブックも考えたのですが、寝ながら使いづらいとか、あとあのタッチパッドがだめなんですね。iPadは日常用途に最適。iPod touchを大きくしただけじゃんと揶揄する人もいますが、デバイスそのものよりも、こうしたデバイスがあった時のユースケースを明確に示たのが一番の貢献だと思っています。

一番素晴らしいのは写真管理です。以前より格段に解像度が増して圧倒的にきれいです。ボクの中ではネットの使えるフォトフレーム化しています。逆に、使っていて一番不便なのは入力まわりです。クリックや選択、コピペが結構絶望的。iPhoneに比べたら使いやすいという人は本質を見失ってます。iPadの対抗馬はPCやネットブックであってiPhoneではありません。とおもったが、そうじゃなくてkindleだったかw 次の不満はファイルと関連付けです。アプリケーション間の連携は最悪です。そうしたものは想定していません。そもそも、従来のPCがファイルを開く形で動いていたのが、iPadでは各アプリがファイルを管理します。そのためブラウザからpdf管理ツールを起動できません。用途を限定することで使いやすくしているので、文句は言いづらいですが、どこまで自由にするかの線引きは難しいですね。

今のところ想定している拡張は、まずdropboxを使った論文管理、bluetoothスピーカ、それからファイルサーバ上の動画閲覧などが出来そう。グリモンは使えませんがブックマークレットは使えます。具体的にはブックマークレットでaタグを探してリンクを自宅サーバに貼り直し、クリックしたらサーバー側でやりたい放題処理して、dropboxに保存します。Macも持ってないですし、当面はwebアプリで凌ごうかと。dropboxをファイル管理とみなす方法は結構使えると思います。お試しあれ。

2010年度人工知能学会全国大会

2010-06-12T00:51:00.003+09:00

人工知能学会の全国大会に参加してきました．発表はこちら．内容は，言語横断検索ってあるけど，同じことをテキストマイニングの文脈でやったらどうなるだろう，というような内容です．要約すると試してみたら案外うまくいったよ，なのでそれだと聞いてくれた人にあまりに申し訳ないので，「最終的なアウトプット（マイニング）のために中間で難しい問題（機械翻訳）を解く必要はないはずだ」というVapnikの原理的な説明を入れてみたり，訳語精度の割にうまく動いたもっともらしい説明を入れてみたりしたものの，時間足りなくて説明はしょってしまったり．なかなかうまくできないものです．ただ，前者の話というか哲学というかは最近よく感じていて，アプリケーションから見たとき本当に必要な自然言語処理って何なのか，という点は，特にいくつかの応用をはっきりともっている企業の研究者として，今までのNLPの枠組みから少しはずれる形で一石を投じてもいいんじゃないだろうかと思っています．言語処理学会で話した距離の期待値（曖昧構文解析とよんでいますが）も，「精度のよい解析は結構だが，それで検出漏れがでては困る」というような現実のニーズを反映させようとしています（まだアプリまでうまくつながってませんが）．企業研究者の方の発言やblogなんかを見ると，似たような視点を持っている方をよく見かけます．
今回の発表に先立って，広報の方がプレスリリースを出してくれたりとか，なんかひえぇぇぇだったんですが，特に何もありませんでしたｗ　それから，謝辞にも書きましたがインターンに来ていた2人の学生さんと継続して行った研究だったので，2人には感謝したいですね．

実は今回人工知能学会には初参加でした．そもそも会員でもないです．ごめんなさい．言語処理学会に比べて扱う分野の幅が広い広い．広告オークション，検索のランキング学習，オントロジー，twitter研究など聞きかじったことのある程度だったいくつかの問題に関して，チュートリアルがわりに聞けたのがよかったです．ロボットとかWeb系も，もう少し聞けばよかったかもしれません．

例のごとく，twitter上でしか認識していなかった方にたくさん声をかけていただいたり，実際にお会いできました．twitterをやっていなかったら，本当に2,3人しか知り合いがいなかったので，コミュニケーション拡大に大変役になっているのを実感します．

※上の写真は懇親会に行くとき貸し切りだった路面電車です．貸し切り満員電車でした

一眼レフデジカメのススメ

2010-05-26T22:59:00.002+09:00

最近，ちょっといいカメラ欲しいんだけど，というような相談を受けることが増えました．整理の意味も込めて，デジタル一眼レフがコンパクトデジカメに比べてよいといわれる点を思いつく限りあげてみようと思います．

撮影素子が大きいため画質がよい
レンズが優れるため画質(解像度）がよい
撮影素子が大きいため被写界深度が浅い（よくぼける）
レンズを交換できる
ファインダーがついているため明るい環境下でも見やすい
ピントの山が見やすい
位相差AFのためオートフォーカスが速い
ボタンが多くて操作感がよい
電池の持ちがよい

一番よく聞くのは1番目の理由です．これは間違いではないです．特に夜など高感度でのノイズは雲泥の差があります．2番目の理由もしかり．しかし，画質に関してどれほどの人が気にしているのか少し疑問です．むしろ，デジタル一眼レフを使ってまず一番驚くのは3番目でしょう．ぼける．とにかくぼける．これだけで全然雰囲気が変わります．特にポートレートやもの撮りが楽しくなります．これを画質と勘違いしている人はきっと多いですが，このことと画質は別です．ボケは光学的な現象ですから．それから，ホワイトバランスのことと思っている人もいるかもしれませんが，これも別です．

4番目の理由は，大きいですが実はあまりとりだたされません．理由は簡単で金がかかるからそんなに買わないよということのようです．レンズの交換は楽しいですよ．ボクは中古レンズをオススメしています．画質のためというよりは画角の違いを楽しむためという意味で．4000円で買った200mmは未だに使ってます（さすがに色々厳しいが）．今更いうまでもないですが，35mmで近づいて撮った写真と85mmで離れて撮った写真は違うものです．これは画質云々ではなくて，背景と被写体との距離の比がかわるためです．ボケのサイズや遠近感もかわります．コンパクトデジカメで一番嫌いなのはここで，画角が自分には広角過ぎに感じます．

実は重要だと思っている最後の5点，けっこう軽視されてはいる気がします．最近流行のミラーレス機がこれらのポイントを押さえているかどうか疑問です．明るい環境下で液晶はほとんど何もみえなません．いつもプレビューが見えなくて苦労します．電子ビューファインダーはこの点ありですが，その次のピントの山はどうだろう．撮影素子が大きいとピント合わせはシビアになります．ちゃんとあえば楽しいですが，どこにピントがあっているのか見えなければなりません．以前の液晶ファインダーや背面液晶ではこれが全くわかりませんでした．最近は高精細液晶が使われるようになったらしいので改善されているのかも．気にしたことないよ，という人もいるかと思いますが，コンデジは素子が小さいのでほっといてもピントがあいます．デジ一にするとすぐピンぼけします．オートフォーカスは，極端な話マニュアルでも楽しめますが（笑），ふつうの人は欲しいでしょう．一眼レフには専用のセンサーがあるので速いです．最後の操作感はかなり大事だと思います．全部お任せのコンデジと違って，デジ一は色々設定します．さすがにフルマニュアルで撮らなくても，ピントや絞り，ISO，+/-補正は常にいじりますので，1ボタンでやりたいところ．それから，搭載しているRAMの容量なんかも意外と効いているように思います．というのも，以前SDカードに書き終わるまでプレビューできなくてすごくいらいらしました．そのためにK10D買ったくらいだから・・・．常に撮影しているわけではないためだと思いますが，実は電池の持ちはよいです．

カメラの機種ごとの違いはどうなのかともよく聞かれますが，とりあえず最初は安めのでいいと思います．極端な話中古や型落ちでも．上位機種は確かにいいですが，古い上位機種より新しい下位機種の方が画質がよかったりするのもあります．高い方が基本性能（画質，ファインダー，シャッター速度，AF，連射，防水，耐久性など）がよくてでかくて重い．安い方が逆です．メーカーによってカラーがあるので，たとえばキヤノンやニコンは大きくて性能もよい，Pentaxは小型高級機，オリンパスやパナはより小さいカメラを目指しています．いいカメラ買うよりも，レンズ（画角）が違うと何がかわるのかとかを楽しんだ方がいいと思います．

そんなわけで，自分のお薦めは，キヤノンのキスデジに標準と望遠くらいのレンズ買うのがいいんじゃないでしょうか，ってめちゃくちゃベタだｗ　キヤノンはやはりレンズの利があります．友人が使っていれば借りられますし，中古市場も大きいです．レンズのレンタルもあります．ただし，キスデジはファインダーが死ぬほど小さくて泣けてきます．大きいのがいやな人には，E-PL1とかがデザイン的にもいいように思います．むしろ，そういう人はフィルム＋フィルムスキャナにしましょうｗ　なぜかフィルムの一眼の方が小さいです．なんでだろう．ポケットに入れたい人，あきらめてGRとかにしましょう．

理系的旅行計画

2010-04-29T22:15:00.004+09:00

明日からGWを利用して沖縄に旅行に行きます．私がサークルで毎月どこかに行ってたのも，もう8年くらい前のこと．沖縄に行くのもB2の春以来なので6年ぶりですね．当時と今ではインターネット界隈もずいぶん様変わりしていて，最近は旅程を組むのにそこいらのフリーのツールを活用しています．ちょっとその辺の紹介．

基本はGoogleサイトです．Wikiサービスです．タグでかけなきゃいやだー，と思ってましたが，ちょこっと書くだけならこれでもいいかな．そのまましおりになります．もともと，プロジェクトページなどを想定しているのか（サンプルがそうなっている），TODO管理とかも簡単にできます．何人かで仕事を分担すると忘れがちになるんで，まとめておきます．それから，自社サービスを埋め込めるので，たとえばMapsを埋め込んで泊まるところを書いておいたり，Picasaで写真共有とかもできます．自転車乗りとしては，ルートラボとか埋め込めるといいんですけど．

お金の管理はGoogle docsのspreadsheetを使いましょう．Excelです．足し算引き算はこれで十分．航空券や宿の予約は立て替え払いが発生しやすいので，ここに書いてもらって精算すればOK.

連絡はSkypeが便利ですね．これは，けっこう前からあったかな．

以前は大学に行けばその場でどうこうできましたが，今はこの手のツールを駆使すると大変便利です．会社のスキーや同期旅行なんかでも活躍．昔は自分でwiki置いたりしてましたが，もうそういうのも古くさく感じるようになりました．時代もかわったものです．

英文を書くときに参照したいサイト

2010-04-11T17:00:00.002+09:00

辞書サイト．

その他．

あとで追加する．

人知への挑戦

2010-04-03T01:07:00.012+09:00

去る4月2日，こんなセンセーショナルなニュースがtwitter上で，Webニュース上で飛び交いまいた．

情報処理学会が日本将棋連盟に「コンピュータ将棋」で挑戦状

ついに将棋もここまで来たか，という気分です．私が学部生のころきいたときは，アマチュアとならいけるが，まだプロとは，というくらいのことをいっていたように記憶していますから，この数年でここまで伸びたのかと思うとすごい．単にそれはマシンパワーが増大しただけではなくて，新しいアルゴリズムの開発や，それ以上に地味な工夫の繰り返しだったんではないかと推測します．いくら「解」の存在するゲームとはいえ，それは指数関数の先の遙か遠くにある解．単なる物量で近づける距離ではないはず．

人間へ挑戦の先駆者といえば，IBMのディープ・ブルーですよね．もちろん（？），IBMも黙っていません．

IBM - Research: Jeopardy!
IBM's Jeopardy-playing machine can now beat human contestants

ジョパディーというのは，アメリカで放映されているご長寿クイズ番組だそうです．IBMの研究所はこれにたいしてコンピュータで立ち向かいます．自然言語処理用語でいえば，質問応答です．この問題はチェスで人間を負かすことよりも遙かに「コンピュータにとって」難しいことです．質問応答の研究は，それこそ古くからあったわけですが，大きな成果につながったというような話はあまり聞きません．有名どころだと，Powersetでしょうか．しかし，リリースされたときの周囲の反応は案外冷ややかでした．国内だとgooラボで自然言語検索というサービスが一時ありました．いつしか公開を辞めてしまいましたね．

私は自然言語処理の究極的な目標をあげろと聞かれたら，機械翻訳とこの質問応答だと答えることにしています．質問応答は情報検索のその先にあります．それは単にデータの収集と検索にとどまらず，質問を理解し，文書を探し，推論し，答えを見つけ，適切に答える必要があります．私の知る限りこれらの一連の要求に対して有効な手法が確立されていません．そのため，この挑戦は非常にチャレンジング，というか無謀ともいえます．

私はかねてよりこうした挑戦を期待していました．自然言語処理をはじめとする応用よりの研究は，理論と現実とのギャップが大きいように感じます．私は大学院のときに検索をやっていたのですが，そのとき感じた印象は，一つのシンプルなモデルでは解けず，小さな些末な問題が山のようにあり，それを一つ一つつぶしていかないと全体の問題は解けない，ということでした．その中で自分の提案する方法がどれくらい貢献できるかというと，それは非常に小さく，こうした応用の研究は大人数の総力戦で挑まねばならないと痛感したものです．
そのため，大きな研究グループが，本気で未解決の応用に取り組んだらどうなるか？　これは非常に興味があります．こうした挑戦はそれなりの覚悟と投資が必要です．今，人間のエキスパートレベルの質問応答が実現できるかときかれたら，NOと答えるでしょう．まだ，そういう段階ではないのです．でも，本気で，それも特定のジョパディーというタスクに特化したら，ひょっとして・・・．実際のテレビ放映での対戦でコンピュータが人間に勝てるのか，非常に注目すべき挑戦だと思います．

言語処理学会年次大会2010

2010-03-15T00:17:00.001+09:00

言語処理学会年次大会，通称NLP2010に参加してきました．グループで聴講セッションの分担もあったのですが，私はなるべく普段聞かないような研究を聞きに行ったので，大変おもしろかったです．新しい問題意識ができたり，興味有る文献へのポインタもわかったり，収穫も多かったです．全体の感想としては，実に多様なアプリケーション，問題設定があるなという点で感心しました．自分は想像力が足りないのか，そういう新しい問題設定が苦手です．ただ逆に問題が多様化しすぎて，地味な基盤的研究が減った印象があります（単に聞かなかっただけかも）．学生さんには人気なさそうですが．
twitter上でしか知らなかった方にたくさんお会いしました．コミュニケーション生成に確実に役立っているようです．挨拶と同時に「アカウント知ってます」や「ブログ読んでます」といろんな方にいわれましたｗ　実力以上に知名度だけ先走りしてしまったようです．学生の内からtwitterなりブログなりで名前を売っておくと，話しかけorかけられやすくなるかもしれませんよ．

私の発表は初日の朝9:00からのセッション．時間オーバーしました．すいません．さっそく，@mamorukさんに紹介いただきました．ありがとうございます．あまり質問が飛ばなかったのは，やはりわかりにくかったのかもしれません．ここで補足させていただくと，指数個候補が存在する分布における関数の期待値を，関数に制約をかけること（係り受け木上の最短路の重み付き距離），候補に制約をかけること（後方係り受け限定），分布を近似することで（同時確率を周辺確率の積で近似）多項式時間で計算できるようにしました，というのが技術的に面白いところです．周辺確率を計算するのに動的計画法を使って，距離の期待値を計算するのにもう一度動的計画法を使います．ちなみに，直接私の成果ではありませんが構文解析技術は弊社製品にすでに使われているというのもあって，こうしたモチベーションが生まれています．応用よりの具体的な問題意識というのは，アカデミックよりも私のような企業の研究者が学会に持ち込まないといけないなぁと最近思ってます．
発表のうまい人のを聞いて思ったのは，大事な部分は3回くらい言うしつこさが大事に思いました．イントロで1回，説明に1回，まとめで1回，くらいで．「まず例を出せ」，というやり方もありますね．そのほうがよかったかも．@hillbigさんが，やはりとても発表慣れしているというのと，発表の組み立てがうまいと感じました．簡単な内容ではないはずなのに，技術のコアの説明は誰よりもわかりやすくて，それ以外は大胆にカットして大事な部分だけ印象づけさせているように感じました．参考にしたい．

10年越しの成果

2010-03-08T00:48:00.003+09:00

友人に誘われて，演奏会を聴きに行きました．演奏も素晴らしかったのですが，驚いたことにこの楽団の団長さん，10年前に今回演奏した曲を演奏したいという目標で設立し，そして10年越しでその目標を達成したとのこと．しかもそれが音大に入りたての18の頃の目標！　私，もう自然言語処理を始めて4年経ちますが，あと6年でそういう壮大な，壮大でなくても一つの筋の通った目標をやり通せるか．ここ数ヶ月は原点に返るというか，修士の時の目標意識を取り戻している気はします．ひとまずは来週の発表ですね．意識を高める，という意味でもよい週末でした．

IME戦国時代

2010-03-05T00:33:00.001+09:00

先月途中まで書いてたのが今更になってしまいました．

昨年末，Googleが日本語入力システムを出したのを皮切りに，Baiduも日本語入力を投入したニュースを聞いて久しい．

Google日本語入力
「Google日本語入力」開発者が語る、その狙い
Baidu Type - 日本語入力システム
バイドゥ、日本語入力ソフト「Baidu Type」を公開

日本語入力システムといえば，それこそ初期の自然言語処理の花形，そして自然言語処理が最も成功したアプリケーションの代表格です．しかし，それは詰まるところよい意味で枯れた技術．それがここに来て検索2社から立て続けにリリースされたというのは，なぜ今更？という意味で新鮮でした．加えてこれらがフリーで提供されていることが，すでに商品として，お金をいただいて提供するソフトウェアではないほどに成熟したことを表しているように感じられます．
もちろんお家芸のジャストシステムも黙って見ているわけではないようで，早速（？）新商品で打って出ています．加えて，社内の用語統一などの機能を盛り込んだ法人向けATOKも新登場．もう「枯れた」と思っていた分野に，こうも新しいフレーバーが盛り込まれるとは．これも競争にさらされた上での進化なんでしょうかね．

ジャストシステム、一太郎2010やATOK 2010を発表
ジャストシステム、法人向けに本気の「ATOK」を新発売--コンシューマーイメージを払拭へ

私は今まで日本語入力に関してノータッチだったのですが，実は研究として続けている方が予想以上にいることを最近知りました．@mamorukさんや@tkngさんのChaIMEや，@nokunoさんのSocialIME．あと，京都の森先生のKAGAMIとかがあるらしい．やはり，その他の自然言語処理と同じく，今までのルールベースから統計手法にシフトしているようです．私はフルチューンしたルールベースに統計手法は勝てない，なのでATOKが一番！と思っていたのですが知らない間にATOKも統計にシフトしたみたいですね．
それほど不自由に思うことも少ないこのご時世，よくもまぁこんなにたくさんあるんだと感心します．最もユーザーに近いインターフェースの部分を担うだけに，少しの不自由の改善も大きな効果が期待できるんでしょうね．それこそ，構文解析の1%を改善するより大事かもしれませんｗ　コンピュータで一番大事なのは，CPUではなくてキーボード，マウス，ディスプレイをモットーとするインターフェース最重要論者の私としても，なんかしたいなぁと思うところ．これからどういう方向に発展していくのか期待しながら見ていくことにします．

L1-SGD

2010-02-18T00:55:00.002+09:00

Stochastic Gradient Descent Training for L1-regularized Log-linear Models with Cumulative Penalty
Yoshimasa Tsuruoka, Jun’ichi Tsujii and Sophia Ananiadou, ACL2009.

論文紹介．鶴岡さんのL1正則化付き確率的勾配降下法（Stochastic Gradient Descent，SGD）．L1正則化はコンパクトなモデルパラメタになってくれるので，実用上はとてもうれしい．しかし，0の点で微分できないので面倒だった．提案手法は実装が超簡単（擬似コードで20行くらい），超高速で，収束も早いし，性能もいい，いいこと尽くめ．初めての人にもお勧めできる簡単さで，しかもそのまま実用品になります．

L1正則化は目的関数に重みベクトルのL1 normをたした，f(w)+C|w|を最小化しましょうというはなし．L2と違って，0の付近で最小になりやすいので，ほとんどのパラメタが0になって学習結果がコンパクトになりやすいため，実用上重要です．
ところが，この性質，つまり|w|は0の付近でとがっていることが最適化の上では問題．このまま計算すると，0を境にして振動するだけで，なかなか0に近づいてくれません．そこで，更新時に符号が変わるときは（0を飛び越えるときは）一度wの値を0にしてしまいます．これがclipping（で，これがFOLOS）．
しかし，ここまでやってもまだ真の最適解のスパース性に及びません．この原因はオンラインアルゴリズム特有の，最後にやってきたデータに強く引っ張られすぎるという問題のせいです．パラメタは対応する素性を含む学習データが出現すると，勾配が大きいので0から抜け出して，その後L1のペナルティだけがかさんでまた0に戻ります．この途中過程で打ち切られてしまうため，疎な解になりにくいのです（figure 1，下の追記参照）．ということは，L1のペナルティをためておいて，その素性を含む学習データがきたときに，ためておいたペナルティと，学習データによる抜け出す力（勾配）で力比べをして，ペナルティが勝ったらやっぱり0だった，学習データが勝ったら0から抜け出せばよさそう．これがcumulative．ため込んだペナルティと比較するので簡単には0から抜けません．ここで特に実用上大事なのは，L1のペナルティの絶対値はパラメタの現在の値に依存しないため，反復ごとに全体で1回足し算するだけ（これがu）．
実装は非常に簡単です．しかも，式見てわかるとおり各更新は素性の非ゼロ要素だけでよいので，ものすごく速いです．

追記（2010/2/19）
twitter上で，@tkngさんと@uchumikさんにFOLOS（@slaさんによると，最近FOBOSに改名したらしい．改名って・・・）との違いを教えていただきました．多謝！

Efficient Learning using Forward-Backward Splitting
John Duchi and Yoram Singer, NIPS2009.

5章にlazy updateについて書かれています．これは，鶴岡さんの論文でも言及されています．上の私の説明で，一度0から抜け出してから0に戻る途中で打ち切られるのが原因と書きましたが，これはちょっと間違い．lazy updateを使えばこの問題はなくなりますが，やはりcumulativeほど疎な解になりません．
一見lazy updateとcumulativeは同じに見えますが実は違います．lazy updateは前回の更新から，次の更新までの間のペナルティを一気にかけます．つまり，長いこと勾配が0で，次に立て続けに勾配が非0だと0から抜け出せます．一方で，cumulativeは最初から現在までのペナルティの総和を持っているので，勾配の総和がこれを超えてくれないと抜け出せません．なので，長いこと勾配が0だと，そのあと立て続けに勾配が非0でも，その間のペナルティがかさんでいるのでやっぱり0から抜けられません．
給料日（勾配が非0）のたびに取立て（L1ペナルティ）に来ますが，FOBOSは前回の取立て日からの日数分だけ，cumulativeは過去までさかのぼって今までのツケを要求します．人生後半で（学習の後半で）再就職すると（非0が続くと），FOBOSなら貯蓄ができますが（0から抜ける），cumulativeは今までのツケの返済に回されてやはり所持金0です．気に入ったんですが，別にわかりやすくないなw

さて，どっちがいいのかという話ですが，FOBOSは後半の出現に強く依存する点で，cumulativeの方がいいのかなという気がしました．バッチの場合は全データの勾配を足して，ペナルティも足すわけですから，出現順に依存してペナルティの総和の変わるFOBOSよりcumulativeの方が近いのかな，という直感．理論的な考察とかもありそうですね．

異分子への耐性

2010-02-10T23:25:00.003+09:00

金融工学の挑戦―テクノコマース化するビジネス (中公新書)

中央公論新社 2000-04
売り上げランキング : 114939
おすすめ平均

Amazonで詳しく見る by G-Tools

新書を久しぶりに読みました．私は金融工学はまったくの素人なんですが，初学者にも読めるように色々配慮されているように感じました．難しい数式は話半分にしか理解できませんでしたが・・・．
さて，私がこの手の専門領域の方がかかれる新書に期待することは，半分は今書いたような専門分野の入り口の記述で，もう半分がその業界の歴史といいますか，背景といいますか，ノンフィクション的な話です．著者の今野先生は，金融工学という学問が興る，まさにその瞬間を体験した方のようで，「経済学」という学問にいかにして「工学」という異分子が入り込んでいったかのドキュメンタリーが非常におもしろかったです．特に，こうした数式バリバリの手法が経験主義的な既存の経済学にいかに受け入れられなかったか，そしてにもかかわらずいかにインパクトを与えたかという話は非常に興味深い．
これを読んで思うのは，twitterで話題になったことですが，NLPに統計的手法が入り込んできたときに，既存の言語学の先生方がこぞって言語処理学会から消えていったというエピソードです．数学とか統計とか，とかく理工系の学問を新たに体得するというのはかなり大きな障壁があるのは事実ですが，たとえば共同研究するとかやり方は色々あったのではないかと思います．逆に我々も，統計や機械学習だけに固執してしまってはいけなくて，方々に知識の裾野を広げていかないとと常に思います．大学の特に大御所といわれる先生が必ずしも新しいものにnegativeという訳ではなくて，たとえば私の指導教官の先生は話を聞くだけで新しい手法の利点・欠点・特徴，あらゆるものを一瞬で理解してしまう方でした．知識は誰よりも広く，深くはないはずなのに要点は全部押さえているという．マネジメントの能力というのはこういうことを指すのかな，と漠然と思ったものです．
今の職場は，NLPはもとより，言語学から数学から物理から機械学習まで，ドンだけ幅あんねんといういろんなバックグラウンドの方のいる謎グループにいるので，こうした知識をうまく活用したいなぁと日頃から思っている次第．

TeXを書くときに便利なサイト

2010-02-06T21:54:00.005+09:00

twitterなどで見つけたTeX書くときにぜひ参照したいサイトへのリンク集

Detexify² - LaTeX symbol classifier
文字認識してTeXのシンボルを検索してくれる．すごい便利
The Comprehensive LaTeX Symbol List
TeXのコマンドがただただ大量に載ってる．4MB近いPDF
物理のかぎしっぽ
いつも見てたサイト
LaTeXコマンドシート一覧
いつも見てたサイトその2

あとで追加する．

構文解析が何に役立つのか

2010-02-06T19:32:00.004+09:00

思いがけずたくさんブックマークしていただいたので，この機会になんで構文解析なんかやるのかというお話を書こうと思います．おそらく，NLP界隈の人には何をいまさらと思われるかもしれませんが，それが本当に役立つかというとなかなか一筋縄では行きません．今回興味を持たれた方の多くはNLP分野外の方なんじゃないかな，と勝手に考えてますのでそのつもりで書きます．

構文解析というのは，文の構造を判別する処理のことで，NLP的には単語分割，品詞タグ付け（いわゆる形態素解析）のあとにくる処理です．ソフトウェアで言えばCabochaやKNPがこれにあたります．ここに大変わかり易いチュートリアルがありますｗ　例えば「値段の高いワイン」が，「値段のワイン」ではなくて，「値段の高い」「高いワイン」であることを認識する技術，と理解していただければ良いと思います．このように，文節間の係り関係を解析することを，係り受け解析（dependency parsing）といいます．これとは別に，phrase structure parsingもあるのですが，ここでは置いときます．
では，文の構造がわかると何が嬉しいのか．案外これが自明ではないです．非NLP屋さんでも，Webテキストをクロールして単語分割してBoWでTf/IDF重みのベクトルにして，やれ類似度，やれ検索というようなことをしている友人はたくさんいるのですが，なかなか構文解析まで使っている人はいないようです．私の感触では「検索」という文脈は構文解析とあまり相性がよくないようです．なぜかというと，Web検索するとき，ふつう単語を入れますよね？　クエリが単語の時点で構文情報を使いようがないのです．
じゃぁ，いらんやん・・・，とはなりません．NLPの応用は単純な単語検索，類似文書検索だけではないのですね．たとえば，「エンジン」「故障」みたいな単語間の関係を取り出したいとします．単純な単語共起で調べると，「エンジンをかけたらエアコンが故障した」のように，それエアコンですから！というのが取れてしまってげんなりします．しかし，構文木上では，「エンジン→かける」「エアコン→故障」なので，故障したのがエンジンでないことは自明です．これは情報抽出と呼ばれる処理の一種ですね．もっとも，話はそんなに単純ではなくて，「故障したエンジン」みたいに修飾関係が逆になっていたり，「エンジンの調子が悪いと思ったら，故障した」みたいに遠くの係り関係から推論しないといけない例もあったり，一筋縄ではいきません．ここが情報抽出の難しくも面白いところではあるんですが．
ここまではNLPの話で，最後に抽出された関係を集約してデータマイニング的な処理にかけて関係の出現の偏りを見ます．すると，どの製品にどんな不具合がわかったりといった応用ができます．仕事でやっているので先輩のデモを見て知っているのですが，本当にいろいろ見つかるようでなかなか面白いです．ここまでの生テキストから知見を得るまでを総じてテキストマイニングと呼ばれ，すでに商品が市場に出回っています．しかし，B2Bなので一般の人の目には触れられないようですね．実際は，これに加えてスケーラビリティが特に問題になるので，データ構造やインデクシングが重要になります．

これはあくまで一例で，自然文検索など単語間の関係に着目して検索するアプリケーションもあります．もちろん，もっと高度な機械翻訳や質問応答の前処理としても使われますが，構文情報（＋情報抽出）のみからでもいろいろ応用が考えられるよ，というはなしでした．

構文解析と情報科学

2010-02-01T01:44:00.004+09:00

そろそろ論文紹介記事を書いてみます．
NLP2010のプログラムにもあるとおり，しばらく係り受け構文解析周りをやっていました（います）．私の出身研究室では構文解析をやっている人がたくさんいたのですが，最近その面白さがなんとなくわかってきました．いや，一応私も2年間日本語係り受け解析の演習担当やってたよ！　構文解析のおもしろさというのは，言語学，機械学習，プログラミング，情報科学が非常にバランスよくミックスされた問題で，いろんな定式化の仕方や，いろんな技術が，いろいろな組み合わせで，かつわりとキレイな形で程々の難しさに仕上がっているあたりにあると思います．今日は，特に情報科学的教養が大事でしたという話を3つ．

Non-Projective Dependency Parsing using Spanning Tree Algorithms
Ryan McDonald, Fernando Pereira, Kiril Ribarov and Jan Hajic, HLT-EMNLP 2005.

Ryan McDonaldのMSTパーザーの論文．これまで，projective（非交差）のdependency parsingが主流だったところに，突如現れたグラフ理論を使った構文解析．「突如」だったかどうかは，当時の実情を知りませんが．構文解析というのは出力候補が入力長に対して指数爆発する問題であるため，全部列挙して比較することができません．そこで部分問題を順次解いて局所的な最適解をとるか，強い独立性を仮定した緩いモデルの上で大域最適解をとるかという選択があります．今まで後者の手法として動的計画法を使った，CKY風の解法（Eisnerとか）が主流でした．ところが，単語を頂点，係り関係を枝とする木を構築する問題だと思うと，これってmaximum spanning treeの構築だよね，ということに気づいたわけです．しかも，この問題はCKYのO(n^3)ではなくてO(n^2)でとけるというから，性能的にも優れます．
これを最初に聞いたとき，すげー，頭いい！と思いました．構文解析といえば動的計画法という固定観念がやはり私の中にもあったようですね．

Probabilistic Models of Nonprojective Dependency Trees
David A. Smith and Noah A. Smith, EMNLP2007.

オリジナルのMSTパーザーは学習はMIRAで行っている．つまり，ちゃんと勾配を求めずに学習します．CRF同様，この種の線形対数モデルは勾配を計算するときに分配関数が効率的に計算できる必要があります．CKYでは，この計算はinside-outsideで求めることができます．これは，HMMのforward-backwardをCRFのforward-backwardに拡張するのと同じ．
さて，肝心のMSTではこの計算が無理なんだろうと思っていました．しかし，実はこれは行列木定理（Matrix tree theorem）を使うと計算できるよ，ということに「気づいた」のがこの論文．行列木定理というのは全域木の総数を計算する手法を示した定理です．これを重み付きに拡張すると，分配関数の計算そのものになります．ここまで聞くと，行列木定理を使うのは至極当たり前な話なのですが，そもそも私これ読むまで行列木定理なんてしりませんでした．実情はしらないんですが，当時もみんな気づかなかったんじゃないでしょうか？　Ryan McDonaldがMSTパーザーを発表してから，実に2年間も誰も「気づかなかった」．そう思うと，すごくどきっとしませんか．

Concise Integer Linear Programming Formulations for Dependency Parsing
Andr´e F. T. Martins, Noah A. Smith and Eric P. Xing. ACL 2009.

かわって，今度は整数線形計画法（ILP）でdependency parsingした論文．ILPというのは，解が整数，制約式と目的関数が線形な最適化問題．各単語の係り先を変数におきます．上述したMSTパーザーでいうところのMaximum spanning treeのスコアは枝の重みの総和なので，これが目的関数．これは当然線形式でかける（書けそう）．あとは，ちゃんと木になっていることをうまいこと線形式で書き表せればよくて，これがちゃんと出来るよということが書かれています．大事なのは，この線形式の総数が文長に対して多項式サイズで済むことを示しています（今まであったILPの手法は指数サイズになった）．ILPはNP困難ですが，多項式時間で近似解を求める方法が知られているので，全体で多項式時間だぜ！というはなし．けっこうめちゃくちゃですが，筋は通ってます．うん．

いずれの方法も，既存の手法を，別の情報科学的テクニックで切り抜けた論文というくくりでした．応用分野であるNLPは，他分野のテクニックが押し寄せてくることがよくあります．こういうときに勝つのは，やっぱりいろいろな基礎体力を持っている人なんだなぁ，と思った次第．

理系のためのデジカメ講座

2010-01-27T00:49:00.004+09:00

最近こんな本を読みました．

デジタル一眼レフがわかる (Fist Book)

技術評論社 2008-07-11
売り上げランキング : 27404
おすすめ平均

Amazonで詳しく見る by G-Tools

大変面白かったです．初心者用でもしっかり抑えるところは抑えていて，というかマニアックに抑えています．例えばCCDとCMOSの違いとか，どうしてデジイチでフォーカルプレーンシャッターが必要かとか，位相差方式ってどうやっているのかとか，プリ発光がなぜ必要なのかとか，今まであやふやだった部分がかなり抑えられています．カメラのメカに詳しくなりたい人はどうぞ．

matplotlibで日本語表示～解決編

2010-01-14T22:33:00.003+09:00

先日，日本語表示できなった理由がわかった．rcParamsのfont.familyでserifを指定したのがまずかったらしい．その設定と，fontpropertiesがバッティングしたようだ．

この問題は，そもそもデフォルトフォントをserifにしておけばよい．$HOME/.matplotlib/ディレクトリ（環境変数HOMEはwindows版でもちゃんと読んでくれる）以下に，matplotlibファイルを作る．このサンプルは，Python26\Lib\site-packages\matplotlib\mpl-data\matplotlibrcにある．font.family : sans-serifという行がコメントアウトされているので，これをserifに変えて#を消せばOK．デフォルトフォントはserifになる．rcParamsはここの設定をいじくるもののようだ．ふだん使いたい設定はあらかじめ書いておくとよさそう．

matplotlibで日本語epsを生成する方法

2010-01-13T03:28:00.012+09:00

matplotlibは素晴らしく使い勝手がいいのだが，日本語を表示しようとした途端にハマってしまった．まだちゃんと調べきれてないんだが，どういうわけかうまく行ったり行かなかったりで，とりあえず自宅環境でちゃんと動いたのでメモ．手元の環境は python 2.6 + matplotlib 0.99.1．

最終的な結論としては，フォントを適切に設定すればOK．フォントファイルの指定はFontPropertiesを使う必要があるようだ．ここで埋め込むフォントで挙動が変わるらしいことが，経験的にわかった．動作を確認したのは最新のIPAフォント（現時点でver 003.01）．このフォントは，埋込PDFを作ることをライセンス上許可しているため，フォント埋込みを要求される論文投稿など（加えて，国際学会に日本語の処理の文脈で投稿する必要がある時）使うと良いだろう．こういう基盤の仕事をオープンソースという形できちんとこなしているIPAはすばらしいと思う．

フォントの指定は以下のようにすればOK.


from pylab import *
import matplotlib.font_manager as fm
prop = fm.FontProperties(fname='N:\\WINDOWS\\Fonts\\ipamp.odf')
xlabel(u'本日は晴天なり', fontproperties=prop)
show()

あとは普通にeps出力すれば良い．いくつかハマった点として，どういうわけか古いIPAフォント（ttfファイルだった）を使っていたら，”本本本本本本”と表示された．謎である．MS明朝を指定するとeps出力できなかった．
他の環境では，epsが開けなかったり，pdfなら出力できたり．今思うとこれはgs側の設定の問題かもしれない．

Pythonでグラフを描くmatplotlib

2010-01-11T17:19:00.004+09:00

今まで論文を書くとき，「漢は黙ってgnuplot」と思っていましたが，いかんせん描画できないいくつかのグラフがあります．今回，点の大きさがそれぞれ違う散布図みたいなのを描こうと思って，どうしてもよくわからずあきらめました．当初Rを使おうかと思ったのですが，なかなかいまさら文法を習得しづらい．そこでふと調べると，pythonでグラフ描画できるライブラリがあったのですね．それがmatplotlib．インストールにはnumpyが必要です．

使ってびっくり，非常に簡単，高機能，使いやすい，pythonで書ける．いいことづくめ．大雑把に言うと，x, yがfloatの配列とします．あとは，plot(x, y)を呼んでから，show()するだけ．tkで作られたウィンドウにグラフ描画されます．保存ボタンがあるので，そこからepsを選べば保存できます．eps出力はどうやるんだっけと，ぐぐる必要はもうありません．pythonのnativeなデータを使えるのがうれしい限り．それから，マニュアルが非常に充実しています．検索から何からいろいろ用意されていて，参照している関数にもちゃんとリンクはられているし（当たり前だけど）．サンプルもたくさん．

これ試すときに気づいたのですが，python付属のエディタ，IDLEって実はおおよそEmacsキーバインドにできるんですね．OptionからKeysをIDLE Classic UnixにすればOK．C-spaceは働きませんが，C-npfbが使えるので，かなり楽チン．IDLEでソースを書いてF5で描画，直してまた描画，このサイクルが非常にスムーズです．python使いの研究者の方は一度お試しあれ．

bloggerの機能を試してみる

2010-01-11T16:23:00.005+09:00

機能的な面で困ることがないかいろいろ試してみます．

まずははてぶ周り．テンプレートをいじくったらできました．これね．はてぶ数はimgでやってるのね．0はてぶのときの制御ができないけど，諦める．

次，コードスニペット．


public class HelloWorld {
 public static void main(String[] args) {
     System.out.println("Hello World!");
 }
}

ほんとに表示されてる？　＞されているようだ．

最後に，TeX．mimetexを表示させるためのgreasmonkeyなるものを見つけた．入れてみたけど，ちゃんと動かない．多分，javascriptで$を探して，該当部分をmimetexサーバーに投げて，帰ってきた画像をbloggerに登録して，それをtextareaに貼りつけてるんだろうけど，肝心のmimetexサーバーが落ちているようだ．もし，そういうことをしているんだったら，mimetexじゃなくてmediawikiにも使われているtexvcにして欲しいなぁ．アッチの方が綺麗だし，テキストでいいときはテキスト埋められるのに．

別のがあったので試してみる．

おおお，すごい．これは，texvcっぽいね！画像使うモードだけのようだ．すばらしい！

bloggerにアカウントを作ってみた

2010-01-11T15:39:00.004+09:00

はてなが重くて１年以上改善されないので，もういい加減いいかなと思い始めてbloggerにアカウントを作ってみました．はてなのよいところは，OCamlソースのシンタックスハイライトくらいで，他にはてな特有のサービスはほとんど使ってなかったりします．あまりごてごてしたブログサービスは好きじゃないのと，周りに何人かいたのでbloggerにしました．今のところの不満は，ほとんどのテンプレートが細すぎる．昔はこういう横幅をpixel指定したデザインが好きだったけど，ワイド液晶が当たり前になった昨今の液晶事情には馴染まないような気がする．と思ったが，そういう昨今の液晶事情にも関わらずブラウザを最大化している自分がいけない気もする．ちょっと使ってみて本当に移行するかどうか決めようと思う．

正式に移行を決定したました．過去の日記はコチラです．