等々いろいろあるようだ。全域探索が目的なので、shift-reduceは除外。他のを見てると、どうも探索の計算量がO(**)だ、とかいうあたりがいろいろ皆さん気にしてるようだ。...うーん、でもどうなんだろう。人間が読んで理解できるような文章なら、そんな計算量が必要なはずないと思うのだが(でないと人間にわからないはず)。計算量気にせずとにかく作ってみて、計算量かかって遅いようならまた考えよう、といういいかげんな気分で設計を始める。論文を見てるとすべての文節の組み合わせをトライしてるようだが、少なくとも日本語書き言葉ならさすがにそこまでしなくてもいいんじゃないかと思う。連体詞なら必ず名詞にかかると思ってよいし、格補語なら必ず述語にかかるだろう。いう「絶対こうなる」的ルールと、「大体こうなることが多いんだけど、例外もある」ようなルールとは分けられるだろう。前者をハードルール、後者をソフトルール、と仮に呼ぼう。ハードルールが適用できるなら、係り先が「(自分より右の)全ての文節」よりもかなり小さいサブセットに限定される。これプラスいくつか枝刈りの技術を組み合わせれば、探索空間は十分小さく抑えられるのではないかな、というのがまあ楽観的かもしれないが当方の予想。探索のやり方もいろいろ工夫が考えられるが、まずは単純な木探索で、文末側から機械的に(ハードルールで選んだ)可能な係り先をしらみつぶしに辿っていく、という方式で行ってみる。文頭まで行ったら(つまり、木の末端では)係り受けの評価(スコア計算)を行う。ここでソフトルールが出てきて、「は」は文末にかかりやすいとか、同じ格の補語は2つ以上あれば減点とか、点数づけをしていく。入出力もいるのだが、これはcabochaを流用することにしよう。まではcabochaをそのまま使う。中のfindHead()の結果も使う。たいした処理ではないが。)cabochaのデータ構造から文節や形態素の情報をひっぱってきて解析する、とするのがいちばん楽そうだ。出力も、やろうと思えばcabochaのデータ構造に書き込んでcabochaの出力ルーチンを使うこともできるが、とりあえずはcabochaの結果と比較してどこが違うかを見たいので、テキストで文節ごとの係り先をcabochaと独自ルーチンの方と両方出す、くらいで当面はいいことにする。以上のようなプログラムならそんなに難しくないだろう、ということで、作ってみる。いうか実はもう作っていてだいぶ動いている。公開してみようか、と思うが、ちょっと現状ソースが汚いのでもうちょっと整えてからにしようか。前記事で書いた「係り受け・WSD・照応・述語項を同時に処理する...2012-11-06徐々に改良中KNBコーパスで正答率が出るようになると、やはり良い数字を出し...2012-10-20KNBコーパスで正答率を測るせっかく係り受け解析器を作ったので、やはり精度がどうなって...2012-10-15【作ってみた】全域探索を行う日本語係り受け解析器「係ろっと」できた。係り受けの次のステップ月別アーカイブはてなブログをはじめよう!yu_hatvaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。