※以下の内容は、ド素人が方々で読みかじったことを元に勝手な憶測を交えて書いているので、ところどころ間違ってるかもしれません。あるいは全面的に…。間違っても鵜呑みにしないで下さい。特に用語の使い方が変かも…。
辞書(というか品詞コード)や付属語グラフというのは "ルール" ないし "パターン"、つまり「一般的抽象的」なもの
↓
従って、個別的例外的なものには対処できない
・適切な候補の選択
・区切り位置の判定
↓
対処するためには個々の単語レベルでの情報が必要
・コーパスの大量データから連接コスト推定
→ これが十分に使えるなら、辞書や付属語グラフは不要？
↓
しかし、単語レベルでの情報を使うためにはかなりデカいデータが必要
しかも、実用的な変換速度を確保する為にはデータをメモリ上に置く必要があるらしい？
・ハード的な制約
→ 少なくとも今はローカルではムリ。64bit 環境が一般に普及すればいい？それは何年後？
→ Windows7 や Snow Leopard が出て 32bit を切り捨てにかかれば意外と早い？
→ それでも日本語入力アプリだけで数GBもメモリを使うとしたらユーザは抵抗を感じないか？
・そもそもフリーで使える大量データはどこに？
↓
Sumibi、ChaIME、SocialIME みたいな web サービスなら可能？
↓
でも、ネットに繋げなければ一切日本語が入力できないのでは困る
・サーバ or ネットワーク障害時
・接続環境がない場所
あと、入力内容を他人に知られることに抵抗を感じる人も多分少なくない
↓
ローカルのみで使えるものがやはり必要
でも、単語レベルの大量データは持てない
→ ATOK や Office IME ってどうなってるの？
↓
「基本的には辞書&付属語グラフの一般ルールで、そこに一部単語レベルの情報を付加して性能向上を図る」ハイブリッドしかない。
→ ATOK の「ハイブリッドコア」ってこういうもの？
→ anthy は既にある程度そうなってる気がする
文節区切り: 品詞コードと付属語グラフを元に例文から計算(一般ルールレベル)
候補選択 : 単語同士の共起確率みたいな情報を持っててある程度使い分けられる(単語レベル)
※あくまで anthy の挙動からの推測で、確証はないです
【現時点での結論】
・賢い変換をするためには大量データに基づく単語レベルの情報が必要だが、それはまだローカルマシンではムリ、web サービスとしてなら可能。実際いくつかある
・でも、web サービスオンリーにはなれない。なので、ローカルのみで使える変換エンジンの需要は当分なくならない
・上記のような制約を考えると、今すぐ anthy を超えるような変換エンジンが出てくるとは思えない。anthy はかなりのところまで既にやってる気がするから。G-HAL 氏パッチで学習機能を強化されたことも考えれば尚更。
【今後】
・「ローカルでは anthy 、ネットに接続できる時は web サービスのコーパスやシソーラスの情報を使って賢い変換ができる」というフロントエンドの形態が落ち着きどころのような気がする。
・web サービス自体は non-free でも一応構わない。anthy とフロントエンドさえフリーなら debian みたいにライセンスにうるさいところでも問題ない。
・でも、ユーザから集めた変換ログはフリーで使えるようにしてくれると嬉しい。プライバシーの問題とかあると思うけど。
【蛇足】
・「これ以上集めても性能は上らない」と言われて終わってしまった corpus の例文収集。が、候補選択に限ってはそうでもない気がする。
「くびをふる」が「首を降る」になっていたので「|くびを|ふる| |首を|振る|」という例文を追加してみたら、ちゃんと「首を振る」に直った。「首を軽く振る」と間に「軽く」という語が挟まっても正しく変換した。udict だと間に別の語が挟まるとダメだった気がする。でも「くびをふりつづけた」は「首を|降り|続けた」になったけど…。
文節区切りも、直らないものはどうやっても直らなかったが、直るものも結構あった。
今の 10倍くらい例文を集めてみてどうなるか見てみたい気がする。
あ、あと、今あるもので
|しぶさ|しら|ず|おーけすとら| |渋さ|知ら|ズ|オーケストラ|みたいな変なのも外して。
それから「名詞+名詞」という並びがやけに優先されてる気がするが、それは
|あくせい|しん|せいぶつ| |悪性|新|生物|みたいな、例文ではなく複合語として辞書に登録すべきものがたくさん混じってるからのような気がするので、これも辞書に移してみてどうなるか見てみたい。
|はいき|とう| |排気|塔|
|そこう|ちょうさ| |素行|調査|
あくまで「見てみたい」んであって、自分でやる気はない。つーか、ムリ。辞書だけでも手一杯だったのに depgraph にまで手を出して「オレはいつになったらお尻を拭き終わるんだろうか…？」と思ってるのに、この上さらに corpus の例文の面倒まで見れん。でも、性能に直結してるのは corpus の方な気はするけど･･･。
【関連する記事】
あとテストファーストが重要かと。
コーパスが偏るから云々という話はよく聞きますが、どのくらい問題なことなのか、いまいちピンときません。「どこから/誰からどういう文を集めるか」で変換結果が変わってくるというのは分かりますが、「標準的な文」というのはある程度あると思うので、そういうものを集めるように(あるいは妙な文体のものを入れないように)気をつければそれほど大きな問題にならない気がするんですが。
それに、udict はあの形式では登録数が増えたら管理しきれなくなると思います。
どちらにせよ、テストケース≒コーパスを増やし、どちらがより効果的かを試すしか無いですね。
>udict はあの形式では
形式変換はどうとでもなるので、問題は無いと思います。