Hatena::ブログ(Diary)

自然言語処理 on Mac

2012-09-22

驚異的な解析速度を誇る日本語係り受け解析器J.DepP

日本語の係り受け解析器といえば、KNPCaboChaが有名ですが、J.DepPは線形分類器を用いて大規模な対象を非常に高速に、また高精度に解析できることが特長です。2009年末に公開されてから着実にバージョンアップされていますが、ビルドの方法が簡単になって、モデルの学習機能が追加されたことで大変使いやすくなっています。また、J.DepPは線形分類器のpeccoopalを利用していますが、ベースの分類器が高速化されたことが、そのまま解析器の性能向上につながっているようです:
ソフトウェアの更新も一人旅になってきた - ny23の日記

このJ.DepPをMacPortsとして登録しました。デフォルトの状態でjdeppインストールすると、jumandicを参照するMeCabを組み込んだ解析器と、解析済みのブログコーパスであるKNBコーパスを対象とした学習モデルが利用できるようになります:

$ sudo port selfupdate
$ sudo port install jdepp


MeCabの辞書としてはjumandicの他に、IPAdicやNAIST-jdicも利用可能で、それぞれ+ipadicまたは+naistjdicをインストール時に指定すると組み込まれます。また、学習モデルの対象に京都コーパスを指定することもできます。毎日新聞データが使える方であれば、/tmp/KyotoCorpus4.0にコーパスデータを参照できるようにしておいて、+kyotoを指定してインストールできます。例えば、ホームディレクトリに置いてある京都コーパスを学習データとして、IPAdicを利用する場合は、次のコマンドを実行します:

$ ln -s ~/KyotoCorpus4.0 /tmp
$ sudo port install +kyoto +ipadic


なお、CaboChaでの話ですが、京都コーパスKNBコーパスを使った場合の性能評価が次のブログに書かれていて参考になります:
CaboChaでKNBコーパスを使う | 関口宏司のLuceneブログ

ざっくりと動作の様子をみるために、KNBコーパスのテキスト(約252KB)を対象として係り受け解析を実行してみます(※コメントに、解析速度に関して作者の方からの説明がありますのでご覧ください):

$ sudo port install nkf KNBC
$ nkf -w /opt/local/share/KNBC/corpus2/Kyoto.tsv > Kyoto.tsv
$ time jdepp -v -1 < Kyoto.tsv > kyoto.jdepp
(input: STDIN [-I 0])
J.DepP profiler:
io : 0.0196 ms./trial (58.69402665/2997)
dict : 10.3510 ms.
preproc : 3.8375 ms./sent. (5748.59597486/1498)
chunk : 0.0594 ms./sent. (88.98891755/1498)
depnd : 0.0452 ms./sent. (67.65351785/1498)


real 0m8.720s
user 0m0.345s
sys 0m0.219s
$ time jdepp -v -1 < Kyoto.tsv > kyoto.jdepp
(input: STDIN [-I 0])
J.DepP profiler:
io : 0.0162 ms./trial (48.47844897/2997)
dict : 0.5021 ms.
preproc : 0.0969 ms./sent. (145.11098944/1498)
chunk : 0.0428 ms./sent. (64.17484213/1498)
depnd : 0.0436 ms./sent. (65.25766264/1498)


real 0m0.413s
user 0m0.298s
sys 0m0.106s


参考までにCaboChaで同じことをさせてみます:

$ sudo port install cabocha
$ time cabocha -f 1 < Kyoto.tsv > kyoto.cabocha

real 0m14.948s
user 0m4.235s
sys 0m0.314s
$ time cabocha -f 1 < Kyoto.tsv > kyoto.cabocha

real 0m4.484s
user 0m4.227s
sys 0m0.184s


どちらも係り受け解析の前にMeCabによる形態素解析を行っていますが、J.DepPの係り受け解析の速度はMeCab形態素解析とそれほど大きく変わらず、桁違いに遅いということはないようです:
J.DepP - C++ implementation of Japanese Dependency Parsers

CaboChaも相当速いと思っていましたが、こうなると前処理であったり、後処理の意味的な解析や索引化の処理が全体のボトルネックになってきそうです。

ny23ny23 2012/09/22 16:33 分類器, 学習器に引き続き,J.DepP も MacPorts に登録して頂きありがとうございました.

ベースの分類器 (pecco) に施した高速化は,分類時の計算を(ラベルが確定した段階で)打ち切る,というもので,実は -v -1(スコアを出力するオプション)をつけた場合には有効となりません.このオプションはデバッグ用のオプションで,デフォルト設定 [-I 0] では,スコアが出力されず単に解析が遅くなるだけになります(次の版でこのオプションをつけた場合はスコアを出力するように変更します).

あと,pecco はそもそも,タスクデータに頻出する基本分類問題を利用した高速分類手法 (EMNLP 2009 で発表したもの) を実装したもので,J.DepP もモデル構築の際に学習データをタスクデータとして用いてこの分類器の高速化を行なっています.そのため,KNB コーパスで学習して KNB コーパス (Kyoto.tsv) をテストに用いると,コーパスの内容に重複があることから J.DepP で速度が出やすい状況になっていると思われます.

なかなか公平な比較は難しいのですが,構文解析単体(文節区切り+係り受け)で評価する場合,他の実装より一桁以上高速なのは確かなので,大規模な解析を行う際にはぜひ試していただければ,と思います.

hjym_uhjym_u 2012/09/23 14:15 素晴らしい研究成果を実際に利用できる形で公開していただいてありがとうございます!また高速化や出力についての詳細なコメントも大変参考になります。京都コーパスで学習したモデルでKNBコーパスを解析してみてもほぼ同様の速度という感触でした。構文解析も、結果をどのように使うのかは難しいところもありますが、形態素解析のように今後ますます一般的に利用されていきそうですね。

ny23ny23 2012/11/12 18:42 11月8日のバージョンですが,中途半端に更新した分類器のソースコードが混ざっていたため,一部の環境でコンパイルできない状態になっていました(パッチで対応して頂いたように,SSE4.2 用のインクルードガードが抜けていました).
たびたびで恐縮ですが,対応頂けると助かります.

hjym_uhjym_u 2012/11/12 23:45 ソースコードの更新ありがとうございます。portも対応させました。ただし、このバージョンは手元のMountain LionやLion OSでは問題なくビルドができますが、どうもSnow Leopardではうまくいかないことがあるようです。buildbotに文句を言われてしまいました:https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/12332

ny23ny23 2012/11/13 02:26 古い MacBook (Snow Leopard) を引っ張りだして確認してみました.
コンパイル時に実行されるスクリプトに python 2.7 依存のコードが入っていたため,学習用のコーパスを生成するところでコケていたようです.Leopard Server で問題なくコンパイルできたので油断していました(この環境には python 2.7 が入っており,見逃していました).
python 2.4 以降で動作するよう更新したものを再度アップロードしておきました.

hjym_uhjym_u 2012/11/14 00:41 早速の対応ありがとうございます! portを更新したところ、無事Snow Leopardでもビルドできたようです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/hjym_u/20120922/1348278329