Hatena::ブログ(Diary)

ny23の日記 このページをアンテナに追加 RSSフィード

2010-06-09 学会参加準備完了

学会の参加登録時に Workshop のプログラムが分からないのはいかがなものか

|  学会の参加登録時に Workshop のプログラムが分からないのはいかがなものかを含むブックマーク  学会の参加登録時に Workshop のプログラムが分からないのはいかがなものかのブックマークコメント

航空券が無事取れたので,11日の Early Registration の期限前に参加登録を済ますべく,Workshop のリストを見ていたのだけど,一部の Workshop で論文リストが出ていなかった.ほとんどの参加者は Early Registration すると思うのだけど,論文リストが出ていないと,面白い発表があるかどうかも分からないし,コアな研究者しか参加しない Workshop になってしまうのではないだろうか.分野外だけど興味がある,という研究者も取り込むように努力しないと,Conference にサテライトして開催する意味は無いと思う.二日目は面白そうな Workshop もあったのだけど,そういうわけで論文リストも出ていなかったし,一日目は目に付く Workshop がそもそも無かったので,結局 2-Day Conference に参加することにした.

ホテルは,学会の Web サイトから申し込めるところは,学会会場から近いところや安いところは既に無くなってしまっていたので,学会の Web サイトに載っていた(けど料金の高い)ホテルを gta 経由で申し込み.gta 経由の方が,一日当り2500円近く安かった(というか,学会の Web サイト経由で申し込んで安かった試しが今までそもそも殆どない).学会参加準備終わり.

次は,学習器の論文のカメラレディとオープンソース化の準備.

浅い文解析器と深い文解析器

|  浅い文解析器と深い文解析器を含むブックマーク  浅い文解析器と深い文解析器のブックマークコメント

某資料で速度比較があって,どちらも一番速いものが20文/秒とあったけど,これは単に深い文解析器が速いと言うより,比べている浅い文解析器が遅過ぎるのではないかと思う.係り受け解析ぐらいなら,速いものなら10000文/秒ぐらいは出るでしょう(日本語で transition-based なアルゴリズムで良ければ,三年前の計算機環境で,学部生の演習レベルの実装でも(多分係り受け解析のところだけだけど)7500文/秒とか出てた).深い文解析にも昔関与していた身からすると,ずいぶん速くなったなとは思うけど,後二桁ぐらいは速くならないと,Web スケールのテキスト処理には使えない(何でもクラウドを使えばいいと言うのはどうかと思う).前段の処理(品詞タグ付け)より処理速度が三桁も遅ければ,どう見ても明らかなボトルネックでしょう.逆に基礎的な解析アルゴリズムの高速化を研究する人は,前段の処理の2倍ぐらいまでの遅さに止めないと,「速い」という看板を掲げてもデータサイズが効くドメインでは使ってもらえないと思う.

[追記] Dynamic Programming for Linear-time Incremental Parsing を眺めていたら,英語の最速の係り受け解析器は確かに25文/秒 (on a machine with 3.2Ghz CPU) だが,実装が Python なのか.ということで,スクリプト言語で実装した浅い文解析器と,コンパイラ言語で実装した深い文解析器が同じぐらいの速度というが正解らしい.と思ったが,Efficient HPSG Parsing with Supertagging and CFG-filtering 辺りを眺めると,深い文解析器の方も,品詞タグ付けの4倍程度の時間しかかかっていないので,単に充分に最適化していないだけなのかもしれない.

[追記] 手元の係り受け解析器を,形態素解析器 (mecab) ,以前作った文節区切り判定器とパイプで繋いで解析してみた.UTF8 の2007年毎日新聞 (816,273文) を解析するのに,解析精度 89.4% のモデルで,IO その他すべて込みで 36.702秒 (22,241文/秒),91.8% のモデルで,65.40秒 (12,481文/秒) というところ.cabocha 0.60pre4 だと,863.60秒 (945文/秒; UTF8だからだろうか,こんな遅いはずはないのだが).JUMAN-6.0/KNP-2.0 だと,66文/秒ぐらい(system/main.c で,614/615 行目をコメントアウトしてタイムアウト時に exit しないようにして解析).