自然言語処理ツールの開発を成功に導くには

CICLing 最終日は Chris Manning さんの基調講演でスタート。Manning さんといえば自然言語処理業界のバイブル的教科書である FSNLP

やIIRことの著者としても有名で (どれくらい有名かというと、今回も会議のあとに「一緒に記念写真を撮りたい」という参加者が行列するくらい有名！)、ny23 さんが基調講演の内容について言及していたので楽しみにしていたのであった。

話が始まってみると、実は基調講演の (公式ページに書かれている) 内容と、抄録に入っている論文の内容はやはり違うそうで、基調講演に入る前に論文の内容についてちょっと紹介しておきたい、ということで、15分くらいだけ触れる。

自然言語処理のコーパスから機械学習する研究でエラー分析した人なら分かると思うが、問題が本質的に曖昧で人間でも解けない場合もあるし、コーパス自体にタグづけの整合性がない (つまりタグづけが誤っている) 場合もあるし、機械学習でなんでも解決、というバラ色の生活が期待されているのかもしれないが、そろそろちゃんと言語学的な分析をしないといけないんじゃないの、というお話。

どの言語でもちゃんと人手でタグをつければ形態素解析の精度は97%程度になるのだが、たとえば英語で文末のピリオドが文末記号になる、というのも含めて97%であり、文正解率 (文中で1ヶ所でも間違っていたら間違いとカウント) にすると英語でもまだ5-6割であって、単語 (専門用語で言うとトークン) 単位で97%というのはあまり意味のある数字ではないのではないか、という指摘。

全く自分も同感で (基調講演のあと直接議論もしたが)、コーパスや辞書を作る傍ら、そこから学習したモデルをコーパスに適用し、一貫性がないところや間違っているところを地道に直していく、というサイクルを延々続けていかないと、いつまで経っても問題は解決しない。「精度が上がらないのはコーパスのせいだ」「複数人でタグづけすればよい」などと言うのは簡単だが、そんなに言うならじゃああなたが (自分自身でやるなり予算を取ってくるなりして) タグづけしてくださいよ、という話になるわけで。

述語項構造解析のタグ付与もいろいろ課題あるなと思った。OntoNotes Release 4.0 というコーパスが先日リリースされたが、これは英語・中国語・アラビア語に対し統語情報や意味情報を付与した(部分的にパラレル)コーパスなのだが、それ意外にも質の高いコーパスを作るという目標を掲げているというのが特徴的だなと思う。OntoNotes: The 90% Solution というチュートリアル資料が詳しい (印刷用には優しくないが……)。

そういうわけで基調講演の前半1/3が終わり、後半は自然言語処理における同時学習の話。ここでの同時学習は、固有表現認識と統語解析を同時に解く、という話で、先日の NL 研で松本先生が強調されていたこれからの研究テーマのことである。まあ、結果は「そうだろうな」という感じだが、ここで夕方のイベントへの伏線が張ってあって、同時学習や大域学習で少しばかり精度は上がるかもしれないが、結局使いやすいのはパイプライン処理であり、むしろ任意のレイヤーを取り替えて使うことができるパイプライン処理のほうが好ましいこともある、ということ (自分も全く同意だが)。

さて、昼食後は calvo さんの論文、

• Hiram Calvo, Kentaro Inui and Yuji Matsumoto. Co-related Verb Argument Selectional Preferences. CICLing 2011.

の発表。これが今回の会議の Best Paper Award だそうで。実際は英語の例だったが日本語で説明すると、(動詞, 格助詞, 名詞) の3つ組の共起を調べるとき、(動詞, 格助詞) と (名詞)、あるいは (動詞) と (名詞, 格助詞) の共起を調べたり、条件付き確率を調べたりなど、いろいろな選択肢があるが、それらを実際に比較してなにが一番いいのか、ということを調べました、という話。つまり「Xを調理する」と「Xを料理する」で (調理する, を) と (料理する, を) は X に似た名詞が来るので似ている、あるいは「Xに報道される」「Xが報道する」のような格交替に関しても (報道される, に) と (報道する, が) は似ている、というようなことを判定する手法、ということである。

自分自身修士のときの研究で述語と格要素の共起を使っていたが、せいぜい複数の共起尺度を試して相互情報量が一番自分たちのタスクには効果が高かったくらいしか調べていなかったし (今回の研究でもやはり事故相互情報量がいちばんよかったようだが)、地道にいろいろ調べるのも大事だなと思う。

あとの発表では去年シアトルの Microsoft Research でインターンをされていた羽鳥さんによる

• Jun Hatori and Hisami Suzuki. Predicting Word Pronunciation in Japanese. CICLing 2011.

もおもしろかった。先日 NLP 若手の会のシンポジウムで聞いた話かなと思っていたのだが、それは別の仕事で、こちらは Wikipedia の括弧表現から (単語, 読み) のペアを獲得した、という話。420万語(たぶん)を98%の高精度・高再現率で獲得でき、製品化可能な水準である、という結果。

評価も Wikipedia でやっている、というところがこの論文的には弱いところだと思うが、もう一つの仕事は文で正解を評価しているそうで、そちらがどこかの会議でアクセプトされたら2つで1つの仕事になるのだと思う (ちなみに今年の言語処理学会で話される内容は両方入っているそうだ)。

夕方のパネル討論では "Should submissions be accompanied by software?" というテーマで議論があったが、今年の ACL から論文と一緒にソフトウェアを提出する論文に加点があったそうで、CICLing も同様にソフトウェアを出すことにインセンティブを与えていたようだが、研究の再現性を保証するためにはソフトウェア(ソースコード)とデータの両方にアクセスできることが重要だ、ということには会場にいる皆が一致していて、あとはどこまでそれを求めるか、というのが問題なのである。

コードの提出には賛成だが、コードの提出を義務化してしまったら IBM や Microsoft、Google といった企業が国際会議に投稿しなくなるだろうから、義務づけるのは反対、というのは Chris Manning さんの意見。Diana McCarthy さんは「これまでもプログラムくださいと言われたら送ってきたし、いろんな人からくださいと言われたら公開しようという気持ちも強くなるし、みなさんも気軽に論文の作者にコンタクトしてほしい」という意見。

自分も企業だとコードを公開できないという事情もあるので義務づけには反対だが、評価型ワークショップのようにデータも公開データで全員条件を揃えてやるのなら、コードも(少なくとも参加者の間では、リビューのために)公開前提でやるというのはありだと思う。Google CodeJam のように「あなたの実装、ここ間違っていますよ」と指摘して撃墜することができる、とか……。

あと最後特別イベントと題して Chris Manning さんによる "Open Source Software and Academic Software: The Case of NLP" というトーク。内容は、NLP プロジェクトを成功に導くためにはどうすればいいか、という議論 (正解をここで提示する、という時間ではなく、問題提起)。Apache プロジェクトに吸収された OpenNLP や AbiWord に統合された LinkGrammar など少数の例外を除いて、基本的に研究者が片手間でやっていて、メンテナンスが馬鹿にならない、という問題。

NLTK はバザールモデルで成功しているようだが、Stanford NLP は伽藍モデル、Manning さんがアーキテクト兼プロジェクトマネージャとして学生にやってもらっているが、大学院生には洗練された API を設計したり、高速なコードを書くインセンティブがなく、基本的に自分が書きたいソフトを好き放題書いてしまうのだが、学生が書いてくるコードのうち20%はすばらしいのでそのまま採用するが、30%は書き直しを命じ、半分はリジェクトするのだとか (数字はうろおぼえ)。@overlast さんの良いものを作りたければ「最初から全部やりなおし」は禁止にもあるように、学生は (時間はあるので) 何回も「これは気に入らない」と最初から作り直したりするが、全部捨てずに再利用できるところは再利用する、というのも大事で、好き勝手にやるばかりが開発ではない、と思う。

Stanford NLP 自体はみんなに使ってもらうことが大事だと考えているので、学生には「処理時間は1分以内にすること」「パイプライン的に使えるように、API をしっかり設計すること」「Stanford NLP として統一感を持たせるので、勝手に SourceForge で公開したりしないこと」などいろいろ取り決めがあるらしい。松本研でも公開ツールこそたくさんあるが、統一感ないので、統一感を持たせるのも意味があるんだなと思った (もちろん是非はある)。

トークの最後、会場に向けても

1. README は書きましょう。コマンドラインの実行例と、サンプルのデータも用意しましょう
2. きれいなコードを書きましょう
3. 研究にはならないかもしれないけど、25%余分に努力して、使ってもらえるツールにしましょう

と3つ提言していて、なるほどな〜と感銘を受ける。これ聞けただけでも今回東京に来た甲斐があったなぁ。