IMEは中国開発ってホント？ 修正プログラムで賢くなった？ Office IME 2007 6の疑問という記事を発見。Q2 のところ、以前も書いたように
Q2 日本語IMEの開発は中国で行なわれているって本当？
A2 日本語IMEの開発は、日本で行なわれている。同社インプットメソッド テクノロジー シニアマネージャの佐藤良治氏によると、IME 2007以前のプロトタイプ開発の際には、日本だけでなく米国レドモントと中国北京にあるMicrosoft Researchとの共同作業が行なわれたという。それが誤解して伝わっているようだ。
日本でのIME開発は専任チームを置いて、ほかのアプリケーション開発と同じように独自に行なっているという。IME開発は日本のほかに、韓国、中国、台湾にチームがあって、各言語に依存しない要素（OSとのインターフェースなど）の開発は、これら4チームによる共同作業で行なわれている。専任チームの規模は日本が最も大きいとのことだ。
というのが事実である。上記記事は割とよく書けていて、2ページ目に今の MS-IME 2007 のアルゴリズムの概要が書いてあったり、割と読んでためになると思う(Trigram の説明のところで「Trigramでは3つの単語のつながりを見る。「品詞ではなく単語で見る」と言われても、今ひとつ素人にはピンとこない」と書いてあるが、本来これは「単語 3-gram(Trigram)」と呼ぶべきで、「品詞 3-gram」もありうるのだが、まあそれはおいといて……)。
個人的に読んでおもしろかったのは「学習方法の変更」のあたり。要は最近行った変換を重視するか、もしくは IME のシステム自体の変換を重視するかというトレードオフなのだが、前者を極端に重視すると SKK のように「最後に行った変換がトップ、以下2番目、3番目……」というようになるし、後者を極端に重視すると全く学習せず毎回同じ変換結果を返すシステムとなる。一番最近の変換結果を返すのはもちろん正しくない場合も多々あるのだが、それでもその人がよく使う単語が上位の変換候補に入ってくれるので、割とうまい候補の提示方法になっているのだ、と言える。
これも単語の変換だと、変換対象の文字列はけっこう出現するし、せいぜい候補数が両手で数えるくらいなのでこんなのでいいが、予測変換や省入力変換のようにもう少し長い単位で候補を出そうとすると、一気に組み合わせ爆発して頻度だけでは無理になる(まだ一度も変換したことがなくてもいい候補というのがいくらでもある)。
3ページ目には統計的手法に移行したことによる(アルゴリズム的な)不具合が書いてあるが、これは本当に使って不具合報告を受けた人じゃないと言えないことが載っているので、貴重な資料である。一番に上がっているのは「文末処理」だが、
そのひとつが、「単語と文末のつながる確率計算に不具合があった」（佐藤氏）という点。IME 2007の変換エンジンでは、変換確定した文字列の後ろに「文末」があると認識して、「単語」＋「文末」のつながりを元に変換候補を出す際の確率計算をするという。
例えば「そらをとぶ」と入力し、変換で「空を飛ぶ」と出て確定した場合、「空を飛ぶ＋（文末）」といった認識をエンジンが行なっている。ところが、この文末と単語のつながりの確率計算に不具合があったため、変換結果が細切れになってしまい、ユーザーが期待した変換ができないことがあった。
症状の例としては、「じょせいでしょうか」と入力・変換した場合に、「女性で消化」という変換をしてしまう（正解は女性でしょうか）例が挙げられている。こうした誤変換は、文章を細切れに変換すると発生しやすいと佐藤氏は述べている。変換のたびに入力語＋文末の組み合わせで確率計算するので、細切れに変換すればするほど、間違った計算が行なわれる可能性が高まるということだろう。
とのことで、いま ChaIME でも「一入力は一文」という仮定を措いているので、この MS-IME 2007 と同じ問題を抱えている。単純には文頭と文末を特別視しなければいいのだが、それが文頭であるか文末であるかというのはかなり大きな情報なので、使えるなら使いたい。どういう対策をして回避したのかは書かれていないが、文頭か文末か判定する処理を入れたのかもしれないし、単に文境界の情報を使わないようにした(完全に止めるのではなく、使うモデルと使わないモデルを線形補間してもよい)のかもしれないが、とにかくこれは統計的にやるとしたら考えないといけない問題の一つである。
次の不具合は「文法生成データの不具合」。例えば「かんなな」と入力した場合に、「かんな」＋「な」と細切れに認識してしまう。これはデータ側の問題で、変換エンジンの処理自体に問題があったわけではない。
これはよく分からない問題なのだが、かな入力→単語分割→文節同定→(各文節内の)変換という手順でやっているとすると、最初の2ステップのところで問題があった、ということかな? 上記の問題も実はアルゴリズムの問題というだけではなく、データ側の問題(文頭文末の情報を重視するようなデータになっていた)でもあるので、処理に問題がないと言い切れるかどうかは分からないが……
3つめが「挿入の際に後ろの語を見る」という問題。文章を一旦入力してから、その文章の途中に追加の単語を挿入するといった作業はよくある。従来は、挿入部分を変換する際に、挿入部分の後ろに来る単語も見て変換していた。素人考えでは後ろを見た方が正確に変換できそうに思えるし、実際に従来の IMEではそれでよかった。
ところが調査の結果、新しいエンジンでは挿入部分の後ろの語を参照すると、かえって変換結果がおかしくなる場合があったという。そこで今回の修正では、後ろ側を参照しなくなっている。
これは実際に実験して確かめた、というわけで、そういう知見があったのはおもしろい(どちらかというと直観に反するし)。なんでなんだろう。前を参照しないとは書かれていないので、前の情報は有用だから変換の際に参照するが、後ろは参照しない、という意味であると推測される。原因を想像するに、挿入するときは挿入するスタイルが人それぞれで違い、必ずしも完全な文になるように入れてから変換するスタイルを取る人ばかりではなく、文節文節細かく分けて入れる人もいるので、そうすると後ろの情報は参照しない方がいいのに参照して(つまり一文でないのに強引に一文であるとシステムは思ってそういう変換をする)失敗する、ということなのかなと思う。
で、最後のページになるのだが、
入力や変換のミスを減らすことが、正しい学習のために効果的。
タイプミスをしたまま変換〜確定したり、誤変換をそのまま確定してしまうと、IMEはそれを誤変換とは理解できず、正しい変換だと学習してしまう。前ページの「学習副作用の抑制」は、その例のひとつである。
佐藤氏は「タイプミスをしないようにていねいに入力し、ていねいに候補を選ぶ」ことがコツだと述べる。速く入力・変換して間違いをいちいち直すよりも、ゆっくりと正確に入力・変換した方がIMEは正しい変換を学習しやすく、結果として入力の手間も減るというわけだ。
開発者としてはそう言いたくても、やっぱりユーザを考えるとそうはしてくれないだろうなぁー。ATOK はどうもそこまで誤変換に引きずられないような仕組みがあるような気がしているのだが、単純にユーザの全入力を正しいと思って使うのは問題がある、ということなのだろう。タイプミスを減らすのは不可能なので、ミスしても変換できるような枠組みを作るのがいいと思うのだが(でもそうするとユーザは「こんなのでもいいんだ」と思って慣れてどんどん適当な変換をするようになるんだろうけど……)。
