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