g-hal****@fenix*****
g-hal****@fenix*****
2010年 6月 24日 (木) 23:21:04 JST
fenix.ne.jp の G-HAL です。 ちょびっとだけ誤解があった模様でして。 前後2文節まで判定を行うのは、「用例機能」です。 MBRビタビの確率計算は、「注目文節とその1つ前の文節」から計算します。 MBRビタビの確率計算の、概略のイメージ例を挙げますと、 |新しい|朝が|来た| |あたらしい|あさが|きた| の変換候補を評価する場合、 第1文節の特徴データベース:形容詞:終端:hash(い):POS_A,COS_NONE,SCOS_A0,CC_A_SIKU,CT_HEAD,WF_INDEP 第2文節の特徴データベース:名詞+格助詞:格助:hash(が):POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP 第3文節の特徴データベース:動詞+終端:終端:hash(た):POS_V,COS_NONE,SCOS_NONE,CC_KV,CT_RENYOU,WF_INDEP を持ってきて、そこから {文頭 & 第1文節の特徴データベース} {形容詞 & 第2文節の特徴データベース} {名詞+格助詞 & 第3文節の特徴データベース} {動詞+終端 & 文末} の4つの確率を 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 のマージ作業で手一杯で時間が >取れず、試せてません…