アカウント名:
パスワード:
「みれるとおもったが」→「見れるとおもっ|他が」
「ないこともないが」→「ないこともな|意が」
など、付属語が連接しすぎのケースが目に付くように思います。この辺はさじ加減だと思いますが、もう少し連接を絞ってもいいので は?
「貴社の|貴社が|貴社で|期しゃした」とかも同様です。
「見れる」はまさにら抜き言葉だと思うのですが..?
まあそれはおいといて、もう少し調べてみたところ、「思ったが」が一文節として扱われず「思った|画」になるのがもう一つの原因のようです。こっちは付属語連接が短すぎたとうわけですね。
「無いこともな|意が」に関しては、難しいとのことですが「無いことも」までの連接にとどめておくべきでは? 「無いこともな」の「な」は終助詞だと思うんですが、文末以外での連接を許すと誤変換の温床になると思います。 「そのなまえで」→「祖のな|前で」になったりしますよ。
ちなみに、MS-IMEやATOKでは「無いこともな」は一文節扱いにはならず、「無いことも|な」になります。まねすればいいというわけではないですが、参考にはなりますよね。
これは、文節区切りの誤変換の学習のことですね?
「このはな」変換→「此のはな」→「この|花」確定。とかしてみましたが、2回目はちゃんと「この|花」に一発変換しました。また、「この|花」を「此のはな」に戻してみると、それも学習します。いい感じだと思いました。
ただ、ちょっと融通が利かない面もありますね。「この|花」学習後に「このはなが」を変換すると「この|花が」ではなく「此花が」となります。もう少し学習を効かしてほしい気もしますが、微妙なところかもしれません。
逆に、「このはなしを」を変換すると「この|花|氏を」になるのは学習による誤変換ですね。こちらのほうは学習が効きすぎて弊害になっており、このままではまずいように思います。
付属語の方もそうですが、いろんなところにさじ加減がありますよね。対応するのは大変だと思いますが...
学習のやり方が相当ad hocなようです(「さじ加減」という言葉が出てくるあたり、学習アルゴリズムに限らない問題と考えるべきだが)。そのために、表向きは「学習した」ように見えているのですが、実は学習による変換モデルの更新がコントロール不能な状態に陥っている(評価基準が数学的な裏付けを持っていない)のではないでしょうか。
そこへいくと、確率モデルでは評価基準が意味のわかりやすい形式で出てくれるので、他の人にとっても楽なんですけどねぇ。でもコーパスを使うことをあきらめた段階でこの事実に気付けなかったとすれば、仕方ないです。
考えを広げていくうちに、ある大きな疑問が出てきました。
おそらくプロジェクトの方針としては、できるだけ人間の直観をモデルに反映させることを狙って、ad hocな改良を加え続けていくことになるのでしょう。ところが、先に挙がっている文節区切りの学習などは、よくよく考えるとコーパスに基づく自然言語処理の一部分です。より一般化すれば事例に基づくモデル構築の部分問題になっています。モデルが先にありきとする前者の立場とは真っ向から対立してしまいます。
同じ問題に対し、両者が同じ解を導くことは一般にはありません。すなわち、人手で作成したモデルが事例によって否定されてしまう可能性があります。もし最初にモデルをおくことから出発した場合、この問題は動作原理の一貫性を損なってしまう恐れがあります(全てを学習に帰着させる場合は、学習手法をfixしておけば再学習が可能)。
というわけで、ad hocな改良と事例ベースの学習をそんなに単純に混ぜてしまう方針には大きな不安を覚えるのですが...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
付属語の連接、長すぎませんか? (スコア:1)
「みれるとおもったが」→「見れるとおもっ|他が」
「ないこともないが」→「ないこともな|意が」
など、付属語が連接しすぎのケースが目に付くように思います。この辺はさじ加減だと思いますが、もう少し連接を絞ってもいいので は?
「貴社の|貴社が|貴社で|期しゃした」とかも同様です。
Re:付属語の連接、長すぎませんか? (スコア:1)
学習アルゴリズムも工夫しているので、一度間違えた入力を訂正したあともう一度入力してみてください。この学習機構の効きについても意見をいただけるとありがたいです。
「期しゃした」が先頭に出てくるのはバグで、cvs版では修正しました。
「見れる」は「ら抜き言葉」の扱いになってましたが修正する方向です。
「無いこともないが」は付属語グラフの評価のせいで、多分その「さじ加減」の問題になるので難しいです。
多くの誤変換は確率の問題ででてくると思われがちですが、Anthyはまだそのレベルには達していないので、この手の報告も助かります。
Re:付属語の連接、長すぎませんか? (スコア:1)
「見れる」はまさにら抜き言葉だと思うのですが..?
まあそれはおいといて、もう少し調べてみたところ、「思ったが」が一文節として扱われず「思った|画」になるのがもう一つの原因のようです。こっちは付属語連接が短すぎたとうわけですね。
「無いこともな|意が」に関しては、難しいとのことですが「無いことも」までの連接にとどめておくべきでは? 「無いこともな」の「な」は終助詞だと思うんですが、文末以外での連接を許すと誤変換の温床になると思います。
「そのなまえで」→「祖のな|前で」になったりしますよ。
ちなみに、MS-IMEやATOKでは「無いこともな」は一文節扱いにはならず、「無いことも|な」になります。まねすればいいというわけではないですが、参考にはなりますよね。
Re:付属語の連接、長すぎませんか? (スコア:1)
ソース中のmkanthydic/*.depwordに付属語のグラフが書いてあって、誤変換の多くはここに遷移を追加するだけで解決するんですが、グラフにご指摘のあった終助詞などをふくめてもうちょっと情報を持たすことを検討しています。
Re:付属語の連接、長すぎませんか? (スコア:1)
> もう一度入力してみてください。この学習機構の効きについても意見をいただけるとありがたいです。
これは、文節区切りの誤変換の学習のことですね?
「このはな」変換→「此のはな」→「この|花」確定。とかしてみましたが、2回目はちゃんと「この|花」に一発変換しました。また、「この|花」を「此のはな」に戻してみると、それも学習します。いい感じだと思いました。
ただ、ちょっと融通が利かない面もありますね。「この|花」学習後に「このはなが」を変換すると「この|花が」ではなく「此花が」となります。もう少し学習を効かしてほしい気もしますが、微妙なところかもしれません。
逆に、「このはなしを」を変換すると「この|花|氏を」になるのは学習による誤変換ですね。こちらのほうは学習が効きすぎて弊害になっており、このままではまずいように思います。
付属語の方もそうですが、いろんなところにさじ加減がありますよね。対応するのは大変だと思いますが...
Re:付属語の連接、長すぎませんか? (スコア:2)
学習のやり方が相当ad hocなようです(「さじ加減」という言葉が出てくるあたり、学習アルゴリズムに限らない問題と考えるべきだが)。そのために、表向きは「学習した」ように見えているのですが、実は学習による変換モデルの更新がコントロール不能な状態に陥っている(評価基準が数学的な裏付けを持っていない)のではないでしょうか。
そこへいくと、確率モデルでは評価基準が意味のわかりやすい形式で出てくれるので、他の人にとっても楽なんですけどねぇ。でもコーパスを使うことをあきらめた段階でこの事実に気付けなかったとすれば、仕方ないです。
ad hocな改良中心の戦略に学習を加えることは正しいの (スコア:2)
考えを広げていくうちに、ある大きな疑問が出てきました。
おそらくプロジェクトの方針としては、できるだけ人間の直観をモデルに反映させることを狙って、ad hocな改良を加え続けていくことになるのでしょう。ところが、先に挙がっている文節区切りの学習などは、よくよく考えるとコーパスに基づく自然言語処理の一部分です。より一般化すれば事例に基づくモデル構築の部分問題になっています。モデルが先にありきとする前者の立場とは真っ向から対立してしまいます。
同じ問題に対し、両者が同じ解を導くことは一般にはありません。すなわち、人手で作成したモデルが事例によって否定されてしまう可能性があります。もし最初にモデルをおくことから出発した場合、この問題は動作原理の一貫性を損なってしまう恐れがあります(全てを学習に帰着させる場合は、学習手法をfixしておけば再学習が可能)。
というわけで、ad hocな改良と事例ベースの学習をそんなに単純に混ぜてしまう方針には大きな不安を覚えるのですが...