NLTK 日本語モジュールに付属するコーパスサンプルの検討

502 views
Skip to first unread message

Masato Hagiwara

unread,
May 14, 2010, 11:44:58 AM5/14/10
to nltk-j...@googlegroups.com
Please forgive me for writing this in Japanese, since this is
Japanese-specific topic.

みなさま

萩原です。

一点ご相談があり、皆さまの知恵をお借りしたいと思っています。ご存じかもしれませんが、「NLP with
Python」の翻訳に際して、我々は現在、日本語自然言語処理に特化した内容を「第12章 日本語自然言語処理」として書き進めています。

そこで、NLP with Python の原著と同様に、

from nltk.jbook import *

などとして日本語コーパスやサンプル(=「NLTK 日本語モジュール」とでも呼びましょうか)を一式ロードして、例えば

ja_morph_analyze(jtext1.sents()[0])

などとして形態素解析を簡単に試せるようにしようとしています。

ここで提供する日本語コーパスのサンプルとして、フリーのものとして青空文庫や Wikipedia からの抜粋のほかに、京大コーパスや IREX
コーパスなどの元となる「平文データ」として使われる毎日新聞データ集を(CDを日外アソシエーツから購入することなく)含められないかということで毎日新聞側との交渉を進めていますが、「インターネットの特性上、記事を不特定多数がダウンロードする可能性のある状態にすることは原則としてできない」という返事を頂いており、「引用」の範囲として可能な数記事、数文の提供であっても難しいという状態ということです。

他には、EDR概念体系辞書・EDRコーパスの提供についても交渉中で、こちらは返事待ちの状況です。また、形態素解析済のコーパスについては、JEITAがプロジェクト杉田玄白、青空文庫の形態素解析済み(ただし人手によるチェックは無し)のコーパス

http://www-lab25.kuee.kyoto-u.ac.jp/NLP_Portal/jeita_corpus/index.html

を公開していて、こちらを TaggedCorpusReader で読める形にして再配布させて頂こうと考えています。

ただし、京大コーパスや NAIST
テキストコーパスのような形態素や係り受け解析済みであるデータを、気軽にダウンロードして自然言語処理の各種テクニックを試せる利点は大きいと考えていて、少なくとも形態素解析済のコーパスを少し(理想的には、コンコーダンスや分布類似度を十分に計算できるだけの量)、構文(係り受け)解析済みのコーパスを少しでも提供したいという心境です。

そこで、NLTK 日本語モジュールに含めるコーパスのサンプルとして配布できるデータで、どのような物を使ったらよいかということについて、良いアイデアをお持ちの方はいらっしゃいませんでしょうか。

たとえ毎日新聞データの配布許可が得られたとしても、例えば1995年版全てを含められるということは到底無く、2,3記事では、データ形式を確認する上でのサンプルとしての意味はあっても、実用的な自然言語処理は言うに及ばず、その「実習」という観点からも遠く及びません。

もし、既存のコーパスの提供が(一部分でも)難しいようであれば、例えば極端な話、Wikipedia
や青空文庫の一部を有志でタグ付け(といっても、おそらくMeCab や CaboCha、Juman や
KNPでも良いですが、自動解析結果の人手修正)をして、「フリーのタグ付きコーパス」として少量でも作ってしまうという方法すら考えているのですが、そのような試みはもうあるのでしょうか?

NLTK は 有志によってオープン・コミュニティによる成果物として開発・メンテナンスされており、それと同じ「ノリ」で日本語タグ付きコーパスも作ってしまう、というのは、実は十分あり得る話なのかな、と個人的には思っています。

以上、長々と失礼いたしました。フィードバック、ご意見等お待ちしています。

萩原


--
Masato HAGIWARA
Product Planning & Development Department
Baidu Japan Inc.
http://www.baidu.jp/

Mamoru Komachi

unread,
May 15, 2010, 8:40:03 AM5/15/10
to nltk-j...@googlegroups.com
Steven, I'm sorry I write this mail in English.
I have written what kinds of Japanese corpora are available (i.e. can
be included in NLTK distribution) at the moment.

小町です。

2010/5/15 Masato Hagiwara <hag...@gmail.com>:


> 一点ご相談があり、皆さまの知恵をお借りしたいと思っています。ご存じかもしれませんが、「NLP with
> Python」の翻訳に際して、我々は現在、日本語自然言語処理に特化した内容を「第12章 日本語自然言語処理」として書き進めています。

お疲れさまです。書き下ろしの部分も、それ以外の部分も、楽しみにしています。

> ここで提供する日本語コーパスのサンプルとして、フリーのものとして青空文庫や Wikipedia からの抜粋のほかに、京大コーパスや IREX
> コーパスなどの元となる「平文データ」として使われる毎日新聞データ集を(CDを日外アソシエーツから購入することなく)含められないかということで毎日新聞側との交渉を進めていますが、「インターネットの特性上、記事を不特定多数がダウンロードする可能性のある状態にすることは原則としてできない」という返事を頂いており、「引用」の範囲として可能な数記事、数文の提供であっても難しいという状態ということです。

それはそうでしょうね……。提供できればありがたいですが、なかなか難しいとは思います。

> ただし、京大コーパスや NAIST
> テキストコーパスのような形態素や係り受け解析済みであるデータを、気軽にダウンロードして自然言語処理の各種テクニックを試せる利点は大きいと考えていて、少なくとも形態素解析済のコーパスを少し(理想的には、コンコーダンスや分布類似度を十分に計算できるだけの量)、構文(係り受け)解析済みのコーパスを少しでも提供したいという心境です。

基本的には数が多い方がいいのではと思うのですが、ターゲットが

(1) 自然言語処理を志す学生 (今後京大コーパスのようなアカデミックなデータを使える)
(2) 自然言語処理に興味があるエンジニアなど研究者以外のプログラム書ける人
(3) 文系の人など、自然言語処理には興味があるがプログラムを書きたいわけではない人

のいずれかで少しずつ状況が違い、たぶん教師ありのデータがあってうれしいのは(1)-(2)の人たちではないでしょうか。

(1)の人はデータ的には研究室のデータを使えばいいので、(1)の人たちが対象であれば、大量のデータがあるかどうかが重要ではなく、研究で使える京大コーパスなどのフォーマットが解析できるサンプルがあったほうがよいでしょうね。

(2)の人たちが対象であれば、タグつきデータがあればいいのは山々ですが、やり方さえ示せばタグつきデータがなくても自分たちでクロールして
MeCab なりなんなりをかけて自動的に生成したデータを使えるのでしょうから、前処理スクリプトなどを含めた上でいくつかのダウンロードしたデータに自動処理をかけたデータをする、というあたりが落し所かなと思います。

そういえば、4000文程度ではありますが、こちらのコーパスは再配布可能なので、使えるとは思います。

http://nlp.kuee.kyoto-u.ac.jp/kuntt/#ga739fe2

> もし、既存のコーパスの提供が(一部分でも)難しいようであれば、例えば極端な話、Wikipedia
> や青空文庫の一部を有志でタグ付け(といっても、おそらくMeCab や CaboCha、Juman や
> KNPでも良いですが、自動解析結果の人手修正)をして、「フリーのタグ付きコーパス」として少量でも作ってしまうという方法すら考えているのですが、そのような試みはもうあるのでしょうか?

日本語入力の Anthy が自分たちで(分かち書きや文節の)タグを収集・公開していましたし、古くからは SKK
の辞書はフリーで有志によってメンテナンスされ続けているので、タスクによっては可能なんだろうとは思います。ただ、タグづけは根気と継続性が必要なので、インターネットを用いて大々的に貢献者を募ってやる、ということには自分は否定的です。

Anthy のコーパス収集も、結局送られてくるコーパスも偏っていれば、タグづけ基準も一貫しておらず、まともに使えるものではなく、せっかく送ってもらったデータでもかなり捨てないと使えないだろう、と思っています。(単語や文節の認定基準が人によって違うが、ばらばらだとちゃんと学習できない)

単語分割程度のタスクであれば、数千文であれば経験ある人なら2週間フルタイムでやれば作成できるそうです。係り受けもアノテーションしようと思えばできますが、言語学に興味がない人には、かなり難しいようです(妻が松本研で係り受けのアルバイトをしていましたが「こんな作業は時給1,000円でやるような仕事ではない」と言って辞めさせてもらいました)。

いずれにせよ、気軽に参加してください、と言って他人に参加してもらえるようなタスクではないと思います。場合によっては作業してもらったものほとんどやり直しになってしまうので……。本当はそうやって経験のある人に直してもらって「ここが違う」というのを何度も何度も繰り返し、正しくつけられるようになるので、やり直しが出るのは本質的なのですが、こういうやり方は
OSS 的な開発にはなじまないと感じています。

Mamoru Komachi

Masato Hagiwara

unread,
May 18, 2010, 7:22:47 AM5/18/10
to nltk-j...@googlegroups.com
萩原です。早速のフィードバックありがとうございます。

> (1) 自然言語処理を志す学生 (今後京大コーパスのようなアカデミックなデータを使える)
> (2) 自然言語処理に興味があるエンジニアなど研究者以外のプログラム書ける人
> (3) 文系の人など、自然言語処理には興味があるがプログラムを書きたいわけではない人
>
> のいずれかで少しずつ状況が違い、たぶん教師ありのデータがあってうれしいのは(1)-(2)の人たちではないでしょうか。
>
> (1)の人はデータ的には研究室のデータを使えばいいので、(1)の人たちが対象であれば、大量のデータがあるかどうかが重要ではなく、研究で使える京大コーパスなどのフォーマットが解析できるサンプルがあったほうがよいでしょうね。
>
> (2)の人たちが対象であれば、タグつきデータがあればいいのは山々ですが、やり方さえ示せばタグつきデータがなくても自分たちでクロールして
> MeCab なりなんなりをかけて自動的に生成したデータを使えるのでしょうから、前処理スクリプトなどを含めた上でいくつかのダウンロードしたデータに自動処理をかけたデータをする、というあたりが落し所かなと思います。

おっしゃる通りだと思います。ちょっと補足させてもらうと、(1)~(3)のどのグループが対象であろうが、NLP
の解説本、実践本である以上、原書にあるような、例えば類義語を求めるサンプル

text1.similar("hogehoge")

などが、「ある程度それっぽく」動かないと意味が無いと思ってて、今回の毎日新聞側との交渉では、「「引用」の範囲として可能な数記事、数文の提供であっても難しい」というレベルなので、やはり「ある程度の量」のコーパスを付属させるのは必須なのではと思っています。

その上で、(1)~(3)のそれぞれのクラスタの人々が、研究室のデータを使ったり、自分たちでクロールしてくる、という解決法に進む、というシナリオだと思います。

> そういえば、4000文程度ではありますが、こちらのコーパスは再配布可能なので、使えるとは思います。
>
> http://nlp.kuee.kyoto-u.ac.jp/kuntt/#ga739fe2

紹介いただきありがとうございます。再配布可能ですし、今回の目的から見て十分だと思います。形式も京大コーパス互換のようなので、とりあえずこのコーパスを
CorpusReader で読み取って実習を進める、というような形式にしようかと考えています。


> いずれにせよ、気軽に参加してください、と言って他人に参加してもらえるようなタスクではないと思います。場合によっては作業してもらったものほとんどやり直しになってしまうので……。本当はそうやって経験のある人に直してもらって「ここが違う」というのを何度も何度も繰り返し、正しくつけられるようになるので、やり直しが出るのは本質的なのですが、こういうやり方は
> OSS 的な開発にはなじまないと感じています。

なるほど、経験者のお言葉として参考になります。検索エンジン開発においても、色々なデータを人手によってタグ付けする必要性が生じるのですが、そこでもやはり一定のトレーニングや手直しが必要で、なかなかOSS的にはいかないのは理解できます。

一方で、NLTK 付属のコーパス群などを比べてしまうと、やはり英語圏と比べて再配布可能なライセンスで使える日本語コーパスが少ない現状で、特に上記
(2) のクラスターの人々にはなかなか自然言語処理に手が出ないのも歯がゆいと感じています。

適切な例えではないかもしれませんが、Wikipedia が出る前は、百科事典なんか CGM
的に作れるわけがないと誰もが思っていたと思いますし、最近では Amazon Mechanical Turk
を使いながらいかに信頼性を上げるか、という話もありますから、色々な可能性を探ってみる価値はあるかもしれません。

NLTK の話からは少し脱線しました・・・。色々とフィードバックありがとうございました。

萩原

2010年5月15日20:40 Mamoru Komachi <mamoru....@gmail.com>:

--

Mamoru Komachi

unread,
May 18, 2010, 9:08:36 AM5/18/10
to nltk-j...@googlegroups.com
小町です。

2010/5/18 Masato Hagiwara <hag...@gmail.com>:
> NLPの解説本、実践本である以上、原書にあるような、例えば類義語を求めるサンプル


>
> text1.similar("hogehoge")
>
> などが、「ある程度それっぽく」動かないと意味が無いと思ってて、今回の毎日新聞側との交渉では、「「引用」の範囲として可能な数記事、数文の提供であっても難しい」というレベルなので、やはり「ある程度の量」のコーパスを付属させるのは必須なのではと思っています。

はい、確かにその通りですね。可能であれば、NLTK本が印刷される前にNLTK本体にコードが入り、
確実に日本語でも動くバージョンがあることを明記できるといいんですが……。

>> そういえば、4000文程度ではありますが、こちらのコーパスは再配布可能なので、使えるとは思います。
>>
>> http://nlp.kuee.kyoto-u.ac.jp/kuntt/#ga739fe2
>
> 紹介いただきありがとうございます。再配布可能ですし、今回の目的から見て十分だと思います。形式も京大コーパス互換のようなので、とりあえずこのコーパスを
> CorpusReader で読み取って実習を進める、というような形式にしようかと考えています。

そうですね、研究で使いたい人はその上で京大コーパスを使ってください、という感じでいいんじゃないでしょうか。

> 一方で、NLTK 付属のコーパス群などを比べてしまうと、やはり英語圏と比べて再配布可能なライセンスで使える日本語コーパスが少ない現状で、特に上記
> (2) のクラスターの人々にはなかなか自然言語処理に手が出ないのも歯がゆいと感じています。
>
> 適切な例えではないかもしれませんが、Wikipedia が出る前は、百科事典なんか CGM
> 的に作れるわけがないと誰もが思っていたと思いますし、最近では Amazon Mechanical Turk
> を使いながらいかに信頼性を上げるか、という話もありますから、色々な可能性を探ってみる価値はあるかもしれません。

いやー、それもおっしゃる通りです。結局はどのように人を集めるかが大事なのかなぁ、と思います。

Wikipedia も成功しているのは英語版だけで、日本語版は玉石混淆、やはり書き手の質が重要で、
英語版は英語を書ける人がたくさんいるので、数集めることで質が上がった、というところではないでしょうか。

Amazon Mechanical Turk でも、あれがうまく行くのはかなりタスクを選びますよね。
係り受け程度に複雑になってしまうと厳しいのではないかと思います。
基本的には2値分類の連続でタグづけできるので楽かもしれませんが、
実際係り受けをトレーニングしていない人にやらせると機械的にやらせるのと同程度の性能だそうで、
それなら自動解析の結果でいいんじゃないかなとも。
(自動解析した結果を直させてもほとんど機械の結果を信じてスルーしてしまうので精度的には向上しない)

方向性としてすぐ思いつくのは

(1) うまく初心者でもタグづけできる問題まで落とし込んでつける(UI を工夫するなども含む)
(2) うまく経験者を取り込む方法を考える(初心者が離れていかず留まる方策を考えることも含む)


の2方向でしょうか。前者が Amazon Mechanical Turk の取った方法で、後者が Wikipedia の取った方法、と。
(オープンなタグ付けは諦めてクローズドなエクスパートでタグ付けして、あとは自動解析、という手も入れると3つ)

可能性を探るとすると、結局自然言語処理関係のタグづけは経験者がやるしかないので、
後者の筋なのかなーと思いますが、日本語を使う人の母数は相当あるので、
それなりのインセンティブがあればうまくいくのかもとは思います。
逆に言うと、スタートに失敗したら参加するはずの人も参加しなくなる可能性があるので、
スタートを慎重にやる必要があるのでしょうが……。

複数人でつける場合、一人一人につけさせるとモチベーションの維持が大変で、
たとえば5人でつけたら文とか単語ごとの一致率を匿名で出したりすると(間違えた人には自分が間違えたと分かるので)
全体のタグの一致率が上がるみたいですね。
OSS的にやるならこんなふうに「スーパーアノテーター」を表彰するみたいなシステムがあればいいのかもしれません。

雑駁な話になりましたが、どのようにタグ付けすればいいのかは悩ましい問題なので
(NAIST 松本研でも今年は学生に100万語係り受けをつけてもらうことになりました)
自分も試行錯誤しているところです。
ノウハウ的なものがたまればいいのですが、なかなか共有されないですよね……。

Mamoru Komachi

Masato Hagiwara

unread,
May 19, 2010, 12:18:24 PM5/19/10
to nltk-j...@googlegroups.com
萩原です

少し話がそれましたが、面白いですね。タグ付けの話は、研究室などにノウハウとして溜まっていると思うのですが、なかなか論文等の形で世の中に出てくることがないので、とても参考になります。

仰る通り、(1) 初心者でもうまくタグ付けできる状況を作る and/or (2)
適切なインセンティブを用意するなど、経験者を取り込む、の組み合わせで可能性は探れそうな気がしますね。

「スーパーアノテーター」的なモチベーション維持のシステムはとても面白いと思います。個人的には、タグ付けの履歴(誰がいつ何をどうタグ付けしたか)まで含めて全て公開して、「OSS的に開発された」ということを断って配布するのなら、それはそれで使い道があるのかなとも妄想しています。

もう少し一般化すると、信頼性の高いアノテータによって付けられたタグは信頼性が高く、かつ、信頼性の高いタグと一致率の高いアノテータは信頼性が高い、みたいな再帰的なモデルを使うと、各タグに信頼度みたいなスコアが出せて、信頼度の高いものだけ取り出してコーパスとして使う、なんてできるかなーとも思ったりしましたが、なんだかどこかで聞いたような話に似てきましたね。

さてそういえば、紹介いただいた KNB コーパスの CorpusReader
を軽く書いてみましたので、ドキュメント(といっても簡単な使い方)とテスト兼サンプルコードが完成し次第公開して、もしよければ皆さまに使っていただき、バグ出し等でご協力いただくかもしれません。その際はまた別途アナウンスいたします。

よろしくお願いいたします。

萩原

2010年5月18日21:08 Mamoru Komachi <mamoru....@gmail.com>:

--

Mamoru Komachi

unread,
May 20, 2010, 1:48:22 AM5/20/10
to nltk-j...@googlegroups.com
小町です。

2010/5/20 Masato Hagiwara <hag...@gmail.com>:


> 「スーパーアノテーター」的なモチベーション維持のシステムはとても面白いと思います。個人的には、タグ付けの履歴(誰がいつ何をどうタグ付けしたか)まで含めて全て公開して、「OSS的に開発された」ということを断って配布するのなら、それはそれで使い道があるのかなとも妄想しています。

汎用的なアノテーションツールの開発で研究室の先輩と組んで以前未踏にプロポーザルを書いたことがあるのですが、それは落ちてしまいました。理由は「自然言語処理以外であまり使われる発展性がなさそう」というもので、まぁそれはそれでごもっともな指摘なんですが……。

結局自分も学振に通って未踏に出せなくなったのでその後このテーマで研究したりはしていませんが、ユーザを巻き込んでデータを作る、というのは自分の最近の関心事(検索クリックスルーのように受動的に生成されるデータも含む)なので、どこかでもう一度リバイバルしたいと考えています(笑)

> もう少し一般化すると、信頼性の高いアノテータによって付けられたタグは信頼性が高く、かつ、信頼性の高いタグと一致率の高いアノテータは信頼性が高い、みたいな再帰的なモデルを使うと、各タグに信頼度みたいなスコアが出せて、信頼度の高いものだけ取り出してコーパスとして使う、なんてできるかなーとも思ったりしましたが、なんだかどこかで聞いたような話に似てきましたね。

さすが萩原さん、うまいですね(笑) まあ、実際そうすると(アノテーター間での)最頻出タグに収束するのではないかと思います。Rion Snow
の Amazon Mechanical Turk の論文では、素人のタグ付けの voting
でも高い精度が出せる、という話だったので、意外とタスクによってはそれが正しいのかもしれません。特に意味に関するタスクでは、個々人の見方の違いがノイズになりうるので、多数決はそれなりに有効な戦略ではないかと考えています。

機械が得意な処理と人間が得意な処理とそれぞれあって、機械が得意で人間が不得意な処理(たとえば形態素解析とか係り受け解析とか)は少数の経験者が小さなデータにタグ付けするほうが、逆に機械が不得手で人間が得意な意味解析系の処理であれば多数の初心者が大規模なデータにタグづけするほうが相性いいのかも、と思います。

> さてそういえば、紹介いただいた KNB コーパスの CorpusReader
> を軽く書いてみましたので、ドキュメント(といっても簡単な使い方)とテスト兼サンプルコードが完成し次第公開して、もしよければ皆さまに使っていただき、バグ出し等でご協力いただくかもしれません。その際はまた別途アナウンスいたします。

仕事速くてすばらしい。公開していただければこちらでもテストします。どうぞよろしくお願いします。

Mamoru Komachi

Reply all
Reply to author
Forward
0 new messages