オンライン手書き文字認識エンジンZinniaを公開しました。
少し前の話ですが、Yahooがかな漢字変換Webサービスを出したようです。拙作のAjaximeみたいなサービスを簡単に作れるインフラが整ってきたようです。早速 Ajaxime のバックエンドをこれになーんてハックもいいのですが、やってて手応えがないので、Linux上で動く変換エンジンをYahooかな漢字変換サービスを使ってできないかと思って libanthy のラッパーライブラリを書いてみました。
一時期オープンソースがはやった時期がありましたが、今はどうなんでしょう?
当時はオープンソースでバラ色の人生みたく過大評価されていたような記憶があります。
過大評価は言い過ぎですが、いまこうやってブログをかけるのもオープンソースの
おかげであることは間違いありません。
しかし、すべてのオープンソースプロジェクトが成功したかというと、簡単に
YES といえないような気がします。こういう話を某エンジニアとしたら、彼も
同じような視点(というかその方の場合は実経験かもしれませんが)を持ってて、
なんか話が盛り上がってしまいました。
その問題点とは肥大化です。オープンソースは誰でもプロジェクト
最近新幹線に乗る機会が多々あったので、暇つぶしに Javascriptだけで(Ajax等は使わずに)
分かち書きが出来るソフトウェアを作ってみました。実用性は謎です。
CaboCha0.60pre1を sourceforge.net に置きました。
約2年ぶりの更新ですが、機能やアルゴリズムを整理し、フルスクラッチから書き直しました。
1年前から出張の移動時間などを利用してコツコツと書きためていたのですが、
この正月休みに一気に整理してみました。
変更点:
- UTF8対応 (./configure --with-charset=UTF8)
- 文節区切りと固有表現抽出に CRF (実装はCRF++)を使用
- ChaSenへの依存を廃止し、MeCab のみのサポートに
- 固有表現を行う前に文字列の正規化を行うことで若干の精度向上
- 簡易並列処
Espresso を飲みながらさらに Espresso を考えていました。
r_instance = A^n * r_instance_0
となるのは間違いないと思います。A は P * P^{T}、さらに P = 1/|I||P| * pmi(i, p)/ maxpmi です。
A は、インスタンスどうしの類似度を表現した正方対称行列です。A_{i,j} はインスタンス i, j の類似度です。
類似度は、パターン個数次元からなるベクトルの内積で、各次元は pmi となります。
この形だと、r_instanc は r_instance_0 できまるので、初期値に依存してるように思えま
昨日のエントリーは私の完全な勘違いでした。大学数学やりなおします。orz
行列表現にはまちがいはないのですが、あの形はマルコフ連鎖そのものなので、
x_instance = A * x_instance の解は、x_instance = A^{n} * x_instance0 なので、x_instance0 の初期値
に依存します。A^{n} が収束し B になるとすれば、x_instance = B * x_instance0 となります。
A^{n} が収束することが条件ですが、相互情報量の最大値で正規化されているので、たぶん収束するでしょう。
しかし、Espresso のおもし
Espresso という情報抽出アルゴリズムを使った研究が散見されるようになったので、
ちょっと深追いしてみました。基本的に Bootstrapping をベースにしているようです。
Bootstrapping のアイデアはわかりやすいのですが、実際動かすには設定すべき
パラメータがいくつもあります(各Iteration でどういう基準で何個パターンを
見つけたらいいのかなど)。 Espresso は、この設定すべきパラーメータが
アルゴリズムとして明示的に記述されており、わりと再現・実装がしやすい
アルゴリズムだと感じました。
しかし、式を追ってみると、最終的な結果は Seed に依存しな
とあるIME開発者と仮名漢字変換(IME)における「文節」についてディスカッションする
機会がありました。今まであまり真剣に考えたことなかったのですが、
この「IME文節」、いろんな意味で興味深いということを改めて認識しました。
学校文法や自然言語処理におけるいわゆる「文節」とは
統語的な性質からほぼ一意に決定できる単位です。
簡単には 自立語連続＋付属語 と言えるでしょう。
たとえば、
「東京特許許可局で工藤は講演をした。」 は
東京特許許可局で｜工藤は｜講演した。
の3文節になります。小学校のときに「〜ね」を挿入できる単位として
習ったかと思います。
しかし、IMEで上記の文を
C++と Pthreads でミニマルなHTTPサーバを書く
にて、ネットワークサーバのさまざまな設計・実装方針がまとめられています。
1. クライアントごとに fork
2. 事前に fork - 各プロセスで accept
3. 事前に fork - ファイルロックで accept を保護
4. 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PROCESS_SHARED)
5. 事前に fork - ソケットディスクリプタパッシング
6. クライアントごとにスレッド生成
7. 事前にスレッド生成 - Mut
MeCabで形態素解析器を作りたい場合は以下の二つの言語リソースが必要です。
1. 辞書 (単語と品詞のペアの集合)
2. 入力文と、それに対応する正解出力ペア(正解データ)
現在公開している mecab-ipadic は、ipadicとRWCPコーパスという正解データを使っています。
ここから分かるとおり、少なくともMeCabを使う場合は、コスト値を丹念にチューニング
するといった職人芸は要りません。形態素解析への入力文とそれに対応する(理想)出力
があればコスト値を機械学習的なアプローチで構築することができます。
さらに、正解データを人手で作る必要は必ずしもありません。
すなわ
hillbigさんのブログで
紹介されていた "Scalable Training of L1-regularized Log-linear Models", G. Andrew and J. Gao., ICML 2007.
をCRF++上に実装してみました。
現在の CRF++ の実装、そしてオリジナルも含めた多くの実装は L2-regularized log-linear model
です。hillbig さんのプレゼンにもありますが、L2は若干高性能だけど、全パラメータが非0になって、最終的なモデルがデカく
なってしまうのですが、L1だと不必要･冗長なパラメータを完全に0にする効果が
