g-hal****@fenix*****
g-hal****@fenix*****
2010年 6月 24日 (木) 23:21:04 JST
fenix.ne.jp の G-HAL です。
ちょびっとだけ誤解があった模様でして。
前後２文節まで判定を行うのは、「用例機能」です。
MBRビタビの確率計算は、「注目文節とその１つ前の文節」から計算します。
MBRビタビの確率計算の、概略のイメージ例を挙げますと、
|新しい|朝が|来た|
|あたらしい|あさが|きた|
の変換候補を評価する場合、
第１文節の特徴データベース：形容詞：終端：hash(い)：POS_A,COS_NONE,SCOS_A0,CC_A_SIKU,CT_HEAD,WF_INDEP
第２文節の特徴データベース：名詞+格助詞：格助：hash(が)：POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP
第３文節の特徴データベース：動詞+終端：終端：hash(た)：POS_V,COS_NONE,SCOS_NONE,CC_KV,CT_RENYOU,WF_INDEP
を持ってきて、そこから
｛文頭 ＆ 第１文節の特徴データベース｝
｛形容詞 ＆ 第２文節の特徴データベース｝
｛名詞+格助詞 ＆ 第３文節の特徴データベース｝
｛動詞+終端 ＆ 文末｝
の４つの確率を proccorpus & calctrans で得たデータベースから引いてきて
その総積を、「|新しい|朝が|来た|」の候補全体の評価としています。
短い文節を入力した際に効果が有るかもしれない、と言う点に関しましては、
私も未確認です。
|新しい|朝が|
をコーパスに入れると、
｛名詞+格助詞 ＆ 文末｝
も高確率だと覚えてしまう気がします。
文節細切れに入力する人にとっては良いかもしれませんが。
================================================================
(Now Printing)
================================================================
<AANLk****@mail*****>の記事において
vagus****@gmail*****さんは書きました。
>大泉です。
>
>見て頂き、ありがとうございます。
>
>2010/6/22 NIIBE Yutaka :
>> この変更によって、コーパスから1文節ごとのものと2文節ごとのものを作って、
>> これまでの生のコーパスに加えて proccorpus の入力となる、という理解で正
>> しいでしょうか。
>
>はい。
>
>> これまでのコーパスでの加点に加えて、一文節でも加点され、二つの文節の結
>> びつきでも加点される。... ということだと思うのですが、ここでやりたい処
>> 理は、コーパスとして加点(だけ)ではないのでしょうか。
>
>ええと、まず、
>
>> |新しい|朝が|来た|
>
>は、proccorpus 処理時(でいいのかな?)には
>
> <文頭>|新しい|朝が|来た|<文末>
>
>として処理され、各文節に対して、前後2文節との情報(共起確率?)が計算されるそうです
>(G-HAL 氏の解説を読んだ自分の理解では(^^; )。
>つまり、この例では、「朝(が)」は、「<文頭>」「新し(い)」「来(た)」「<文末>」の4つに対する
>情報を得ている(らしい)。
>
>それで、divide.sh はこのうちの
>
> ・普通の語だけでなく、<文頭>、<文末> という特殊文節(?) に対しても計算される
>
>という点に着目して行ってみている実験です。
>
>おおまかに説明すると、
>
> ・「しんぱいでしょうね」「かんどうでしょうね」が「心肺でしょうね」「完動でしょうね」
> とかになった(辞書では「心配」「感動」が先頭)
> ↓
> ・現在の anhty はコーパスから計算した値に従って、辞書での並び順をバンバン
> ひっくり返す(それ自体は別に間違ったことではないと思うが、不適切にひっくり返す
> のは頂けない)
> ↓
> ・ 「心配でしょうね」「感動でしょうね」が例文にないために正しく候補選択できて
> いないのではないか?
> 正しい変換が何か分からないから、単純に「最もありそうな品詞コードのもの」を
> 先頭に出してるだけではないか
> ↓
> ・試しに、「心配でしょうね」「感動でしょうね」を例文に登録してみたら、正しく出せる
> ようになった。
> ↓
> ・恐らく、既存の例文に1~2文節のものが少なくて、
> <文頭>|文節|<文末>
> <文頭>|文節|文節|<文末>
> みたいな場合に、候補をどう並べていいか分からないからだろう
> ↓
> ・手っ取り早く試してみるために、既存の例文を分割してやろう
>
>というのが思考の流れです。
>
>ただ、そもそも前提となっている理解(「普通の語だけでなく、<文頭>、<文末> という
>特殊文節(?) に対しても計算される」)が合ってるいるか自信がないですし、合っていたと
>しても、「手っ取り早く試す」ための手抜き実験なので、こんなことをしなくても正しく変換
>できるようになるなら、ない方がいいと思います。
>
>「何をやりたかったのか」をご理解頂ければ、私としてはそれで十分です。
>
>Ubuntu PPA 版に入っている 18-anthy-dimension-tweak-orig.dpatch は
>
>http://blog.goo.ne.jp/ikunya/e/6425242f371b3b8dec50683d56b592d9
>> ・候補の選択をいじるパッチ（だったかな？）
>
>だそうですので、もしこれを当てれば候補選択がまともになるのなら、divide.sh は
>不要だと思っているのですが、現在 compound.t のマージ作業で手一杯で時間が
>取れず、試せてません…