「UNIX用かな漢字変換エンジンAnthyβリリース」記事へのコメント

辞書構造の古さ

[brake-handle (5065)]

変換エンジンを新しくするのはいいけど、辞書が単語情報しか持っていないというのは...

辞書の語彙数が10万を超えてくると、分ち書きの場合の数が爆発的に増えてきます。こうなると現行のfreeな変換エンジンで利用している単語やその頻度、品詞連接の情報だけでは変換精度が急速に悪化してきます。特に、日本語は名詞の連続により数多くの複合語を構成することができます。この場合、品詞連接の情報が全く役に立ちません。結果として、ひどい変換をしてしまうこ

Re:辞書構造の古さ

[tabatee (1637)]

残念ながらフリーでアクセスできる(フリーソフトで利用できる)高品質なコーパスが存在しないため、そのような戦略は取れません。

また、品詞の情報以外を持たせること考えていますが、その前によりシンプルかつ有効なアイデアが存在するので、そちらを実装してから検討するつもりです。

んで、語彙数が増

NL面でも手弁当でできることはある

[brake-handle (5065)]

品質をどこまで求めるのかは品詞選択などモデル設計に大きく依存するので、単に高品質のコーパスが手に入らないからあきらめるというのは最適な選択ではありません。

現状でのFreeWnnやCannaの品詞を考えると、ChaSenの品詞細分類よりはかなり粗い分類です。そこで、お金をかけずにできそうなコーパスおよび辞書作りの方法を考えてみました。

1. 辞書に含まれる単語を検索エンジンに放り込み、その単語を含むwebページを得る。
2. 得たwebページに含まれるテキストを形態素解析する。
3. 形態素解析を行ったテキストをコーパスとし、品詞を変換した上で辞書を構築する。

これだけでもそこそこ量は集まりそうな気がするのですが。名詞だけでもやってみては?

なお、語彙数の問題は、私の辞書の半分強しかないcannadicでも変な変換をする報告 [srad.jp]がすでにあります。これはanthy上で起きているので、変換エンジンよりも辞書の問題と考えるべきです。また、昔DOSで使っていたWXPは辞書を10万語に拡大した時点でいち早くこの問題を見抜き(当時のATOKは高々3万語)、単語連接のコストを最小化する戦略転換を行っています。

ところで、プロジェクトの中に自然言語処理を本職または趣味でやってる方っていらっしゃるんですか? あちこち見てもその方面の知識がありそうな人が全然見当たらないんですが...

Re:NL面でも手弁当でできることはある

[tabatee (1637)]

>> 語彙数の問題は、私の辞書の半分強しかないcannadicでも変な変換をする報告 [slashdot.jp]がすでにあります。これはanthy上で起きているので、変換エンジンよりも辞書の問題と考えるべきです。

この推論の根拠は?

Re:NL面でも手弁当でできることはある

[brake-handle (5065)]

繰り返しになるかも知れませんが、この「辞書の問題」とは、「語彙の特徴を表す情報の欠落」です。その上で、私が指摘したような誤変換というのは、品詞パタンは確かに知識に合致しているが、そのなかに入る語彙の並びが人間が書く文章ではあり得ないというものです。他の例としては、「接頭辞-名詞-接尾辞」と「名詞-名詞」です。私はかつて用語抽出に関わっていた時にこの問題にぶち当たりました。いずれの品詞パタンもいろいろな例を考えることができてしまうので、結局品詞情報のみで勝負するのは不可能という結論に達しました(穴埋めには語彙の情報を用いた)。いずれの例にしても本質的な情報を見落としているので、アルゴリズムからの改善には限界があります。

なお、全く品詞情報なしに問題を解いている例としては、音声認識があります(2年ほど手をつけていた)。ここ最近の音声認識の処理は

1. 音響信号から音素(母音および子音)を認識
2. 音素列から発話文を認識

という2段がまえが主流です。このうち2.に着目すると、音素列はかな列によく似ており、ゆえに2.の処理はかな漢字変換の問題とよく似ていることが分かります。2.に用いる知識としては品詞パタンやそれを一般化した文法規則などさまざまな試みがありましたが、精度を飛躍的に改善したのは単語のn-gramモデルでした。私もこのモデルを作ったことがありますが、品詞の情報はモデルには全くありません。それでもサンプル文などで測ると8割や9割は正しく認識できます。

異なる問題を解くに当たって同じような傾向があることが分かっているので、人間の都合だけで語彙情報を切り捨てる方向に向かうことに不安を覚えるわけです。