空気のようなソフトウェアのつくりかたに迫る

Word + IME 2000に迫るを読んでいろいろと考える。taku さんのファンに支えられるプロダクトとユーザにdisられるプロダクトを読んで、「ポジティブなファンの応援は確かに励みになりますが、改善点を正直にぶつけてdisってくれるユーザ(not ファン)を大事にしていきたいと思います。良くも悪くも言われないんだけど、誰もが空気のように使っているというのが私の理想のプロダクトです」とあって、そうだなぁ、と思ったり。

安達:そうなんです。ユーザビリティ・ラボのテストでも,初心者の人はどうしても変換中の文字列に対してマウスを使ってしまって,変換中の文字列が全部消えてビックリ,となる。そこで,変換中の文字列に対しても,確定後の文字列に対してと変わらないマウス操作を可能にしよう,と。
藤本:その一環として,見た目的にも,変換中の注目文節が反転する表示をやめました。代わりに太い下線が引かれます。
安達:反転表示も,どうしても文字列が選択されていると見えるらしいんですね。で,Deleteキーで一発削除しようとして,できないので,戸惑ったりする。
──でも,こういう空気のような部分の改定にこそ,私は感動します。人間洞察の賜というか。ユーザビリティ・ラボで初心者が自然に新機能を使ってくれたときは,「やった,やった! 人の心を見切ったゾ!」みたいな喜びがあるんじゃないですか?
安達:そうなんです。「入力カーソルがあれば文字挿入,反転していたら選択」というので,確定前後の操作性に統一感を出したわけですが,ユーザビリティ・ラボでは,初心者の方は「それが当たり前」という顔で使いますよ。それこそが開発側として一番うれしいことなんです。この辺の楽しさは,ユーザビリティ・ラボを作って初めてわかりました。
──技術者は,その時点その時点でできる最新の機能をつい盛り込みたくなるんでしょうが,ユーザーそっちのけでそっちに走ると……。
安達:「とりあえず,こんなのできました」で終わるんです。ラボを作ってから,「地道な,細かい部分を直すのが楽しいんだ」というのがわかる開発者が増えてきましたね。
──そういう空気のような部分の改善に喜びを見いだす,というのは大切でしょうね。そういう目に見えない部分の差こそが,日常作業のストレスの差を大きく左右しますから。
安達:そうなんです。ただ,広告の宣伝文句としては,アピールしないんですよ,そういう部分は。そこが悩みの種で(笑)。

MS いろいろ方向性としては正しいことをしていると思うのだが、「Word/PowerPoint/etc の校正機能はうざいからオフにする」とか言う人も多く、個人的には残念。いろいろおせっかいな機能は確かにあるのだが、おせっかいが使いやすければ(空気のようなおせっかいをしてくれれば)たぶんみんな喜んで使うんじゃないかな? Google はそのあたり神業的にやっているので、裏の人はどんだけ苦労しているんだろう、と思ったりする。親切をするなら本気でとても親切にしないと、かえって仇になったり。でもそういうのを言う人がしっかりいるので MS の製品は着実によくなっていると思う。

それで、増井なにがしを追いつめるというスレッドを偶然見つけたので読み耽る。うーん、まあ、なんというか……。

去年 ChaIME を作ったとき感じたのは、思ったより簡単に作れるものだな、という印象だが、いまになって思うのは、思ったよりメンテナンスは大変なんだな、という感想……。アルゴリズムは枯れているので、データさえあれば最初の叩き台を作るのはそこまで難しくはないのだが、それからのチューニングが一苦労。(結局 ChaIME はまだチューニングしていないのだが……) アルゴリズムが決まる前にチューニングを始めると、チューンした結果が無駄になる可能性があるので、アルゴリズムが固まるまではそんなに「最適化」しないほうがいいと思うし、かな漢字変換ならまだいいけど、予測入力に関してはなにが正解かは分からないので、いろいろ試してみてもいいような気はするのだが……。

安達:基本となる変換アルゴリズムは,今回,いじってません。変換カーネルは相変わらず,スコア手法の上に,N-Best手法で最適な形態素解析候補を生成し,格フレームとの一致度を加味した選択基準で変換結果を出力する,という仕掛けです(注1)。この辺は毎回いじるような部分でもないですし(笑)。
──ATOK開発者の方も,「日本語IMEは生き物だから,アルゴリズムを変えると,それに応じた膨大な辞書のチューニングが必要になるので,辞書が育つまでは,変換精度は落ちる」と言っていました。「変換アルゴリズムは,おいそれとはいじれない」,と。
安達:それは同感です。うちはたまたま,その変換アルゴリズムの一新をIME 98で思い切ってやった。IME 2000では,その次の当然のステップとして,徹底的な辞書のチューニングを行なったわけです。

こういうふうに、アルゴリズムが変わるときは非連続で大規模な変化があるので、最初のリリースはだいぶ混乱があると思うけど、すぐ落ち着くんじゃないかな? (徹底的にチューニングする必要はあるのだが) と思ってしまうのはやっぱり開発者目線なんだろう(汗)

──具体的には,どんな方法で?
安達:IME 98では,コーパス(資料となる文書データ群)を元に辞書をチューニングしやすい構造を採用しました。最初ですから,膨大なコーパスを読み込ませて辞書をチューニングするスタティスティクス(統計的手法)がメインで,最後に誤変換を目で見て,手でなおすヒューリスティクな作業をした。
 IME 2000開発では,それを発展させ,最初のコーパス作成時にIME 98の「再変換」機能を利用するブートストラップ手法(注2)を採用しました。つまり,コーパスは通常,漢字仮名交じり文なわけで,従来は人間がそれに読み方を付けてコーパスを作成していた。しかし,それではどうしても作成できるコーパスの数に限りが出てくる。そこで今度は,元のコーパスに対してIME 98の「再変換」で自動的に「読み方」を付け,それを元データとして辞書をチューニングしたわけです。今回はこの手法で膨大な読み付きコーパスを入手でき,より精度の高い辞書チューニングができた。これが大きいですね。
 今時の各社IMEの変換精度はどれも95%前後ですが,漢字仮名交じり文から読み方を生成する「再変換」の精度は98〜99%にもなる。これだけの精度があれば,開発ツールとして,IME 98を十分活用できるわけです。

ここで「ブートストラップ手法」という名前が出てくるのは意外だったが(笑)、こういうふうにしていたのか、と参考になった。ちなみにここで言う「再変換」機能というのは普通は形態素解析と呼ぶと思うのだが、形態素解析で擬似的に読みをつけたコーパスから学習するのは ChaIME もそのようにしている。実は読みに曖昧性がある単語も少なからずあるのだが、ほとんどの場合読みは一つしかない(9割以上の単語は読みは一つしかない)ので、このようにしてもそれなりに学習できるのである。

形態素解析器を使って自動的に読みをつけるなら、コーパスはウェブからクロールしてきた数百 GB のテキストでも問題なく読みをさくっとつけられるのだが、これを人手でやるとするとえらい手間である。大体この日記は1日平均10文書くのだが、このペースで4万文(京都テキストコーパスと同じ分量)集めるとすると10年以上日記を書かないといけない。途方もない時間がかかるのだと思う。(さすがに実際やるなら最初に自動で形態素解析して単語区切りと読みをつけておいて、間違っているところだけ直し、さらに読みに曖昧性がある単語だけつけるだろうから、そこまで大変ではないと思うが……)

あと、機械学習的な手法でもいろいろパラメータチューニングが必要というのもよく分かる。研究と応用の違いというか、正解があるわけではないので、なかなか難しい。

安達:IME 97ではあえて,元々の辞書が持っている係り受け用例に反するものは,なるべく学習しない仕様にしていました。果たして,「IME 97は学習しない」というユーザーからの批判が多く聞かれた。そこで,「それでは」と,IME 98では学習の効きを強くしたら,今度は「学習しすぎて元々の変換精度を損なう」という副作用が大きくなった。それらの経験を踏まえて,今回ついに学習の効き方がうまくバランスしたということです。

なんか涙ぐましい……。

長いが後半部分も自然言語処理的にはおもしろい話がいろいろある。

南條:エンジン開発の際に集めた膨大なエラーコーパスを分析すると,エラーの68%は入力ミスなんです。もちろん,それ以外にも同音語/表記揺れ/表現のミスなどはありますが,大半は入力ミス。そこで,Word98でも誤字脱字のチェックは可能でしたが,今回,その精度向上に注力し,その結果,初めてフォアグラウンドではなく,バックグラウンドで処理を行なう仕様に格上げした。
(中略)
──エラーコーパスの元データは?
森本:電子百科事典「Microsoft Encarta」です。膨大なテキストを含んでいますからね。
安達:あれがよかったのは,校正の過程がすべてデータとして残ってたんですね。最初の原稿と,プロの校正屋さんの目で校正を済ませた完成原稿とを比較すれば,どういうエラーを人間が行ないがちか,かなり明らかになります。

誤用コーパス第二言語学習でも有用な情報として注目されているが、確かに辞書編纂のときのデータがあったら活用しない手はないなぁ、と思った。世の中に出ている文章というものは、編集の手を経てきれいな状態になった文章か、もしくはブログや掲示板のように編集の手が入らないので間違いが大量に入った文章かのどちらかがほとんどであり、どれをどう直せばいいのか分からないので、文章作成支援や言語教育には使えないという問題がある。誤用コーパスは、どこが間違いで、それをどう直せばいいのか分かるので、非常に有用なコーパスなのである。やっぱりこういう人手をかけたデータを二度も三度も使う、使えるというのはいいことだと思う。他の組織でもこういうデータないのかな?

ともあれ、かな漢字変換自然言語処理に興味ある人には、いろいろおもしろいトピックが入っているので、冒頭の ASCII の記事は一度読んでみることをお勧めする。

あと、先日の N-Best 手法に関する話もここで出ていたのか……註はこれ↓

N-Best手法:スコアを付けられたN個の候補から最適な変換候補を選別する手法。現在,各社IMEに多く採用されている最小コスト法の発展形。最小コスト法では,単語Aの後に単語Bが来る確率を,前から順に接続コストとして計算し,最長の範囲でこのコストの統計が最小になる(接続確率の和が大きくなる)変換候補を優先提示する。N-Bestでは,この接続コストの計算を,前からと同時に,その逆方向からも行なう。その結果,提示されるN個の候補から,接続コストの和が最小になるものを選ぶわけだ。

前からと逆から計算するのは前向き確率と後ろ向き確率を計算する forward-backward のことだと思うが、これと N ベストは関係ないし、提示される N 個の候補から最小のものを選んでいるわけでもないと思うのだけど……。(ビームサーチしながら仮説を枝刈りしているなら確かに N 個の候補から選んでいるのだろうが)