M2 の人を中心にお疲れさま会をする。けっこうビールを飲んだ。久しぶりにこんなに飲んだかも。その割には気持ち悪くなったりしていないのだが、明日起きたら身体節々が痛くなっていそうである。
MS-IME の変換効率が悪いのは開発が中国に移動したからかと /.J で話題になっているが、どうしてそう中国とか日本とか政治的な問題に結びつけたがるのか……。根本的には(まだ準備が整っていないのに)完全に統計的な手法にスイッチしてしまったのが今回の問題の原因であると思っている。人手でパラメータいちいちチューニングするのも馬鹿らしい(最近はコーパスがあれば自動で推定できる)のだが、コーパスがちゃんとしていないのに統計的言語モデルにしてみたり、せっかく人手でカリカリにチューニングしていたパラメータを捨ててしまったり、そういうところで問題が噴出しているのであろう。
具体的には先週4万文の読みつきコーパスから統計的機械翻訳の手法を用いて統計的仮名漢字変換システムを作ってみたのだが、ちゃんと仮名と漢字の対応がつかなくて存在しない単語が生成されたり、逆にありえない読みの漢字が候補に挙がったり(いずれも古川さんのブログで取り上げられている)する。もっと制約を強烈にかければいいのかもしれないが、数十MBしか辞書領域に使えない組み込みIMEではそんなに凝った処理はできないのが現状(たぶん数GB使ってよいと言われれば別の戦略が使える)である。たぶん4万文では全然足りないほか、入力したい文体やトピックごとにコーパスを集める必要があるので、(たとえば新聞記事から頻度を計算するとどうしても「へんかん」は「返還」が「変換」より上位に来るので「返還」が第一候補に来るのが「正しい」。このあたりの背景が推測できないと、古川さんのブログに書き込んでいる人のような疑問につながるのだろうが……)コーパスが足りていないのではないかと想像している。
Google 日本語 N グラム規模のデータが使えるなら既存手法と戦えるかもしれないのだが、現実的にこの規模のデータ使おうとすると200GBほどのディスク領域が必要だったりするのだが、仮名漢字変換システムだけにこれだけのディスク領域を提供する人はほとんどいないのではないかと思う。(今のところサーバサイドで変換することを考えているのでこの制限は問題ではないのだが)
かといって個人的にはここで統計的言語モデルにしたのは時期尚早ではあるが英断だと思っていて、今後変換と確定に関するログがどんどん増えていくわけで、これが増えれば増えるほど変換精度は向上していくものだと考えられる。直接的にログが役に立つ分野もそうそうないので、ユーザの方々からは(開発者にデータを送るのは抵抗がある人多いかもしれないが)ぜひ使わせてもらいたいところだ。
