単語の重み付けの古典的な方法に tf-idf があります。文書中の各単語の tf-idf 値計算し、値でソートすると、その文書に特徴的な単語リストを得ることができます。 http://nais.to/~yto/clog/2005-10-12-1.html tf-idf は、単なるヒューリスティックスだと考えられていましたが、最近言語モデルに基づく情報検索手法がさかんに研究されるようになり、tf*idf の解釈が明らかになってきました。言語モデルに基づく手法は、ヒューリスティックスばりばりの手法と同性能にもかかわらず、文書のランキングに理論的で合理的な説明を与えることができます。 情報検索は、クエリ q に対し、もっとも適合する文書 d_opt を求めるタスクです。つまり、q が与えられたとき、文書 d が出現する確率 p(d|q) の最大化問題と解釈できます。 d_opt = argmax

iPhoneのSDKの条項に変更が加わり、Flashのクロスコンパイルを含む 純正開発ツール以外で作成されたバイナリの配布が禁止となるようです。 世間でも散々言われていますが、この変更は正直とても残念です。 Apple的には「製品のクオリティーが保てないから」という理由だそうですが、 Windows版iTunesが意味もなくQuickTime入れたり、Windows非標準のUIを 使いまくっていて、お世辞にもクオリティーが高いとは言えないのを棚にあげて、 クオリティー云々と言い訳できるのでしょうか。アプリなんて所詮 玉石混淆。決めるのはユーザです。 MeCabは以前GPL/LGPLでした。Appleを含む複数の方からこのライセンスでは 使いにくいと言う指摘をうけ、前職の同僚と協議をしながらBSD/LGPL/GPL のトリプルライセンスにしたという経緯があります。結果としてこの変更は うまく

プログラマ・ソフトウェアエンジニアと呼ばれる人間には、 2つのタイプがあるような気がしています。 ひとつは、もともと機械いじりやハードウェアが好きな 「ハードウェア」プログラマ、もう一つはその反対の「ソフトウェア」プログラマ。 それぞれどういう特徴があるか、独断と偏見でまとめてみました。 (私自身ハード出身なのでそちらに偏重していますw ) 「ハードウェア」プログラマ 「最適化」という言葉が好き 外的な制約(メモリ/速度/ディスク)がある方が燃えるし、真の能力を発揮できる 逆に制約がないと何していいのかわからず、平凡なアイデアしか思いつけない 開発言語は、制約から決定する O(n) の計算量でも、その定数項を気にする 専用ハード好き (地球シミュレータ, メーンフレーム) 定量評価ができないような仕事は興味ない 固定長データ バイナリデータ 再帰なんてもってのほか スピード狂 CPUがどれ

http://www.asks.jp/users/hiro/59059.html http://www.itmedia.co.jp/news/articles/0905/08/news021.html 最初読んだとき、違和感なく読めてしまったのですが、よくよく見てみると、そんなトリックがあったのですね。 さて、この「読めてしまう」がなぜよめてしまうのでしょうか？ 人間の言語モデルの単語パープレキシティは、約100ぐらいであると言われています。どういうことかというと、 人間が文章を読んでいるときに、次の単語を過去の文章から推測するのは 1/100　程度の 確率で正解するということです。 件のコピペですが、最初の文字は変わらないので、その正解率は平仮名の数(52)倍になります。 すなわち、52/100 =~ 0.5　実際には、最後の文字も変わらないし、 単語の長さが変わらないというもの、大きな

一時期オープンソースがはやった時期がありましたが、今はどうなんでしょう? 当時はオープンソースでバラ色の人生みたく過大評価されていたような記憶があります。 過大評価は言い過ぎですが、いまこうやってブログをかけるのもオープンソースの おかげであることは間違いありません。 しかし、すべてのオープンソースプロジェクトが成功したかというと、簡単に YES といえないような気がします。こういう話を某エンジニアとしたら、彼も 同じような視点(というかその方の場合は実経験かもしれませんが)を持ってて、 なんか話が盛り上がってしまいました。 その問題点とは肥大化です。オープンソースは誰でもプロジェクトに参加できるのですが、 ディベロッパーの技術もピンキリなため、時にはどーでもいい拡張がコミットされてしまう ことがあります。その最たるものが周辺技術との統合。ホニャララメタデータをMySQLに保存, ○○バッ

TinySegmenterはJavascriptだけ書かれた極めてコンパクトな日本語分かち書きソフトウェアです。 わずか25kバイトのソースコードで、日本語の新聞記事であれば文字単位で95%程度の精度で分かち書きが行えます。 Yahoo!の形態素解析のように サーバーサイドで解析するのではなく、全てクライアントサイドで解析を行うため、セキュリティの 観点から見ても安全です。分かち書きの単位はMeCab + ipadicと互換性があります。 デモ 日本語の文章を入力し、解析ボタンをクリックしてください。 ダウンロード TinySegmenterはフリーソフトウェアです. 修正BSDライセンスに従って本ソフトウェアを使用,再配布することができます. Download TinySegmenter version 0.2 使い方 <script type="text/javascript" src

CaboCha0.60pre1を sourceforge.net に置きました。 約2年ぶりの更新ですが、機能やアルゴリズムを整理し、フルスクラッチから書き直しました。 1年前から出張の移動時間などを利用してコツコツと書きためていたのですが、 この正月休みに一気に整理してみました。 変更点: - UTF8対応 (./configure --with-charset=UTF8) - 文節区切りと固有表現抽出に CRF (実装はCRF++)を使用 - ChaSenへの依存を廃止し、MeCab のみのサポートに - 固有表現を行う前に文字列の正規化を行うことで若干の精度向上 - 簡易並列処理の廃止。係り受けのみ - APIの一新、より粒度の細かい制御が可能 - PerlやMakefileに依存していた部分の排除。 - 単一バイナリ cabocha-learn による学習の簡易化 (Windows

昨日のエントリーは私の完全な勘違いでした。大学数学やりなおします。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 のおもしろいところは, B が求まってしまえば、どんな初期値でもただ1回の行列のかけ算で 最終的な答えがでてしまうところです。 B は、全パターンと全インスタンスの類似度から生成される行列で、信頼度とは無関係です。相互

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 できまるので、初期値に依存してるように思えますが、A^n がいったい どういう意味を持つのかずっと考えていました。 A_{i,j} が 0, 1 の場合、A　は無向グラフの接続行列となります。i,j がつながっている場合は A_{i,j} = 1となり

とあるIME開発者と仮名漢字変換(IME)における「文節」についてディスカッションする 機会がありました。今まであまり真剣に考えたことなかったのですが、 この「IME文節」、いろんな意味で興味深いということを改めて認識しました。 学校文法や自然言語処理におけるいわゆる「文節」とは 統語的な性質からほぼ一意に決定できる単位です。 簡単には 自立語連続＋付属語 と言えるでしょう。 たとえば、 「東京特許許可局で工藤は講演をした。」 は 東京特許許可局で｜工藤は｜講演した。 の3文節になります。小学校のときに「～ね」を挿入できる単位として 習ったかと思います。 しかし、IMEで上記の文を変換してみると。 東京|特許|許可局で|工藤は｜講演した|。 と分割されます。(WinXP) あきらかにNLP業界の文節と単位が異なるようです。 このIMEが使っている分割の単位を「IME文節」と呼ぶことにしまし

MeCabで形態素解析器を作りたい場合は以下の二つの言語リソースが必要です。 1. 辞書 (単語と品詞のペアの集合) 2. 入力文と、それに対応する正解出力ペア(正解データ) 現在公開している mecab-ipadic は、ipadicとRWCPコーパスという正解データを使っています。 ここから分かるとおり、少なくともMeCabを使う場合は、コスト値を丹念にチューニング するといった職人芸は要りません。形態素解析への入力文とそれに対応する(理想)出力 があればコスト値を機械学習的なアプローチで構築することができます。 さらに、正解データを人手で作る必要は必ずしもありません。 すなわち、Yahoo!の形態素解析器の出力結果を「擬似正解」とみなして MeCabの学習プログラムを走らせれば、Yahoo!の出力を高い精度で再現できる 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にする効果があり、モデルをコンパクトにします。 3年前のmecabに関する論文では、L2 と L1 の CRF を比較して、L2のほうが若干高性能ということを確認していました。 L1-regularized の場合

Ajax IME ブックマークレットを作ってみました．右クリックしてブックマークに登録してみてください． Ajax IME ブックマークにアクセスするだけで現在表示しているページにある textarea と inputbox が Ajax IME 経由で入力可能になるはずです．成功すれば2秒ほどで textarea の色が変わって Ajax IME 入力状態になります．Alt-O で元に戻ります． たいていはうまくいくようですが，まだまだ完璧ではなくて CSS がらみから入力のカーソル位置が激しくずれたり，javascript のイベントがフックできなくて変化なしといったことが頻発します．気長に修正していくつもりですが，みなさんのフィードバックお待ちしております． Mixi の日記投稿や Movable Type の投稿も若干癖がありますが問題なかったです．海外からの日記更新がかなり楽にな

Ajax IME の javascript 側を大幅に更新しました http://ajaxime.chasen.org/ Firefox でキャレットの位置を参照するという blog にコメントをいただきました。 Firefoxでは、textarea とまったく同じスタイルを持った見えない pre 要素を作り、その中に現在のキャレットの論理位置に pre タグで | をつっこんで、その pre tag の絶対位置から逆算する方法でキャレット位置が取得できるようです。激しく回りくどいですが、これを使って Firefox での動作がスムーズになりました。ありがとうございます。 あと、XmlHTTPRequest から JSONP にプロトコルを変えました。その結果、ime.js を読み込むだけでそのサイトのすべての textare と inputbox が AjaxIME 経由で入力できるよう