-
- いいね！0
Mamoru B Komachi
@mamoruk
コーパス開発のプロセス。付与情報の規定→ガイドラインの作成→作業の評価→議論→作業内容修正→付与情報の規定2周目→…「3周見直したらまともなものができる」#signl #ipsj
2014-09-02 10:53:52
Mamoru B Komachi
@mamoruk
応用タスクのアノテーションは多少のノイズは厭わずクラウドソーシングできるが、基礎解析技術のためのアノテーションは解析間違いがかけ算で効いてくるので、エラーが無視できず、高い作業者間一致率が必要。共有資源としての性質が強く、多様な応用技術を意識して設計する。#signl #ipsj
2014-09-02 10:56:55
Mamoru B Komachi
@mamoruk
日本語コーパスは述語項構造のアノテーションの精度が十分ではない。英語の意味役割付与は高い一致率だが、日本語は文をまたいだアノテーションが必要で難しい。システム誤りの分析をしたら、27%がアノテーションの誤りと見られた。→ガイドライン見直しにつなげたい。#signl #ipsj
2014-09-02 11:01:04
Mamoru B Komachi
@mamoruk
継続的改善が必要。一度に全ての問題を解決できない。理論的に明らかでないケースも実例にはある。少数事例もある。業界の共有財産にするためには、開発グループ以外からのフィードバックも必要。また、後方・前方互換性も取りたい。#signl #ipsj
2014-09-02 11:04:06
Mamoru B Komachi
@mamoruk
基礎解析のためのコーパスは一つのグループが長期間（数年〜十数年）かけて完成させる。改善作業も継続する。研究予算・組織体制・長期にわたる遂行能力が必要。現実的には、開発元のプロジェクトが止まると往々にして開発もストップしてしまう。#signl #ipsj
2014-09-02 11:06:01
Mamoru B Komachi
@mamoruk
よくあるコーパス作成作業の特徴。開発プロセスで残るものは、仕様書やガイドライン（どのようにつけるか）。残りにくいものは、議論の内容。なぜそのように決めたか、他の案はどのように棄却されたか。どこを厳密にして、どこを妥協しているのか。事例別の細かい判断。#signl #ipsj
2014-09-02 11:07:49
Mamoru B Komachi
@mamoruk
議論がグループ内に閉じているので、ガイドラインや研究報告から根拠が読み取れない。組織が変わると知見を保持している人物も分散し、継続的議論が困難となってしまう。→開発の過程で蓄積された知見・議論の過程・具体的事例を公開したい。オープンなコーパス開発にしたい。#signl #ipsj
2014-09-02 11:10:35
Mamoru B Komachi
@mamoruk
ここからは昨年度のNL研で発表された「日本語述語項構造アノテーションに関わる諸問題の分析」のお話。ここまでのお話も、自然言語リソースを作成した経験のある人は、みなさん体感されていることを、適切に言語化され、かつ方向性も示されていて、とても興味深かった。#signl #ipsj
2014-09-02 11:13:54
Mamoru B Komachi
@mamoruk
新しい人が来てもすぐ参加できるようなガイドラインになっていることが理想。「文書を開発グループから独り立ちさせる」#signl #ipsj
2014-09-02 11:42:12
Mamoru B Komachi
@mamoruk
述語項構造解析もいろんな基礎技術を入力とし、述語項構造の出力が他の応用タスクの入力となるため、タスク間の入出力の依存関係を整理し、リソースの統合を検討する必要がある。続きは Project Next NLP ワークショップで！！！#signl #ipsj
2014-09-02 11:53:01