Re: 日本語入力 News(2004-10-24)
フォローしようと思って忘れてました...。
fj.comp.input-methodの記事<koabe-C7A501.22004826102004@news01.sakura.ne.jp>で
koabe@ps.sakura.ne.jpさんは書きました。
> この日記の筆者tabateeさんがいう「二元論」に、「日本語入力プログラム
> について考える」内の「文節をどう区切るか」も含まれるのかなあと
> 思い、コメントしてみました。
tabateeさんの日記、読みました。この人は全般に旧来
の日本語入力プログラム業界やその取り巻き連中(?)に
対して批判的で、どうやら私もその矛先に上がっている
ようです。最長一致法や最小コスト法、さらにはAI変換
といった用語についても、tabateeさんとしてはそれら
が絶対的なことばとして一人歩きするのを許せないので
しょうね。
私としてはそのような表現をしても根本を見誤るもので
はないと思うのですが、まあ宣伝用の表現という見かた
にも一理あります。Anthyをかつぐtabateeさんとしては
旧来の考えかたを破壊したところから出発したいわけな
ので、そういう立場から発言せざるを得ないのはないか
と思います。私としては責めるつもりはないです。
> tabateeさんの「古い資料」の範囲がどの辺りの時期を指しているのかが
> はっきりしていませんが、連文節変換が出始めた時期にどの程度、複数の
> 手法を併用できたものなのか、実用的な性能を得るためにどんな工夫を
> していたのかなど、私にははっきりと分からず、興味を持ちました。
tabateeさんのおっしゃる最長一致法と最小コスト法が
必ずしも相反するものではないという意見は正しいです。
たとえば最長一致法でも特定の文節の中で接頭語や接尾
語がどうつながるか、また自立語にどういう付属語がつ
ながるかについては、可能な候補に対して「つながりや
すさ」というコストを勘案しています。最小コスト法に
ついても、入力全体のコストを計算するのは高価につく
ので、先頭からコストを計算していき、短いうちに限界
コストに達してしまった候補を切り捨てていくなどのよ
うに、長さを利用する可能性もあります。極端なことを
いえば、最長一致法と最小コスト法を組み合わせて、両
者が一致して最善の候補と見なしたものを提示する方法
だってあるわけです。
ただ、DOSの時代からWindows 3.1の時代にかけてはPCの
計算能力が不足していたため、その限られた能力をどの
方面に振り向けるかのほうが重要でした。いずれか一方
の方式を選んだとしても、その方式について考えられる
すべての要素技術を実装できるわけではなく、また、そ
れぞれの方式が不得意な変換例について落穂拾いのよう
に対策を施す必要もあったわけです。このあたりは日本
語入力プログラムごとの匙加減というべきものですが、
tabateeさんにとってはそのへんの不透明さも気に入ら
ない点なのでしょう。
匙加減のうちきわめて重要なのが、付属語として何を用
意するか、それらを自立語にどう接続させるかというあ
たりです。この問題については、たとえばCannaの付属
語テーブルに対して狩野宏樹さんが行った改善過程が参
考になるかと思います。Canna MLのログにあったと思う
のですが、確認はしてません。
ただ、この匙加減をどうやっても不得意な変換例という
のは出てくるものです。たとえば最長一致法では経験的
に、文節長の合計が同じならうしろの文節が長いほうが
正しい候補であることが多いことがわかっていて、どの
日本語入力プログラムもそれをアルゴリズムの一部とし
て利用しているはずです。しかし、いまちょっと例を思
いつきませんが、逆に先頭の文節を長くとるべき変換例
というのも存在するわけで、付属語の優先度をいじった
りして対策するわけですが、それでも最長一致法に基づ
くかぎりその種の変換例では失敗する傾向が避けられま
せん。
また、最小コスト法では人間の目で見てかけ離れた文節
区切りの候補が似たようなコストになることがあり、語
尾のちょっとした違いで文節の区切りかたががらりと変
わったりすることがあります。日本語入力プログラムで
標準的な操作インタフェースでは、いったん文節区切り
が決められると文節の区切り直しは人間に任されること
になるので、コストの小さいほうから2番めの文節区切
り候補があっても、それは日本語入力プログラムからの
変換候補としては決して出てこないことになります。
匙加減に属するもうひとつの例として、うまく変換でき
なかったときにどう取り繕うか、結果として何を提示す
るかという問題もあります。アルゴリズムとしてはあま
り表に出てこない部分なので、製品ごとにどうなってい
るのかは私にもよくわかりません。たとえば変換結果の
大部分は評価値が良好なのに一部だけ極端に悪いような
ときに、頬かむりをしてその結果をそのまま出すか、あ
るいは全体の評価値を下げても平均化を試みるかという
違いはあるでしょう。最小コスト法のほうが原理的に破
綻が変換結果全体に波及する可能性が高そうですが、最
長一致法、最小コスト法ともに、たとえばできるだけ先
頭付近に正しい候補を出そうと努力する手はあります。
ベースの部分として最長一致法を選ぶか最小コスト法を
選ぶかというのは、そういう意味で「最善の候補を提示
できるか」というより、「うまくいかないときにどうい
う対策をとれるか」という選択の幅を選ぶことに相当し
ます。それらはその製品の変換の傾向を左右することに
なり、ユーザからみたときの製品の“味付け”として好
き嫌いに影響することになります。
こういったもろもろの点を考えて、私としてはその製品
がどんな方式をベースにしているかに興味がありますし、
その興味に基づいたレビューを書くことにも読むことに
も違和感はないわけです。
どうもうまくまとまりませんが、書けたらまたそのうち
書きます。
--
Junn Ohta
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735