第２回 ＩＲＥＸミーティング 議事録 (Minutes of the 2nd IREX meeting) (財)計量計画研究所 言語情報研究室 この議事録は、主に(財)計量計画研究所の方々に作成していただきましたが、 最終的なチェックは関根が行ないました。間違えなどある場合の責任は 関根にあります。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 0 第2回ミーティング 1. IR 1.1 検索対象記事の範囲 1.2 検索課題の内容(Description,Narrativeの細かさ) 1.3 検索課題のレベル設定 1.4 予備試験の課題の検討 1.5 提出ファイルのフォーマット 1.6 判定プログラム、ツールのデモ 1.7 正解判定方法(判定ランク、学生5段階、最終2段階) 1.8 正解判定者 1.9 その他 2. 全体の運営 2.1 参加予定者リスト 2.2 ワークショップの形態 2.3 結果の公表の仕方 2.4 ＩＲＥＸ２ 2.5 データ公開 2.6 予備試験の日程 2.7 今後の予定 2.8 予稿集でのシステム説明 2.9 その他 3. NE 3.0 全般に関わること 3.1 NE定義 3.2 NE_TRIAL 3.3 対象記事 3.4 ツールのデモ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 0 第2回ミーティング ￣￣￣￣￣￣￣￣￣￣ 日時：平成10年9月16日10:00〜17:30 場所：計量計画研究所 5階会議室 出席者：池田、福島(ＮＥＣ)、井佐原、村田、内元(通信総研)、 江里口、木谷(ＮＴＴデータ)、荻野(ＩＢＭ)、落谷(富士通研)、 影浦、松村 (学術情報)、加藤、佐々木、中渡瀬、磯崎(ＮＴＴ)、 黒橋(京大)、剣持、宮本(横国大)、酒井(東芝)、 佐々木 (徳島大)、関根(ＮＹＵ)、徳永 (アドイン研究所)、 豊浦(三菱)、丹羽 (日立)、野口(松下)、野畑(東大)、 福本、桝井(沖電気)、藤井(図情大)、帆足(ＫＤＤ研究所)、 望月(北陸先端大)、山本 (筑波大)、若尾(ＴＡＯ)（五十音順、敬称略）、 乾、丸元、木田(計量計画研究所) 1. IR ￣￣￣ 1.1 検索対象記事の範囲 ￣￣￣￣￣￣￣￣￣￣￣ ・94、95年の毎日新聞記事の全体(報道、社説、コラム、解説、投書、スポーツなどを含んだ)を 検索対象にする。 ・重複している記事(大阪版と東京版に同じ記事がある場合など)は、除いてはどうか。 ・週間サマリーを入れると精度が上がるので除いてはどうか。 ・著作権のない短い記事は除いへはどうか。 ［意見］ ・内容の薄い短い記事は検索対象から外すべきではないか。 ・記事が要求に関係しているかどうかだけではなく、どのくらい重要性を持っているかも 問題になるのではないか。 ・問題点を洗い出すために、最初は記事全部を検索対象にしてはどうか。 ［結論］ ・今回は記事全部を検索対象とする(重複記事、週間サマリー、著作権のない記事も含む)。 1.2 検索課題の内容(Description,Narrativeの細かさ) ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ●検索要求(Description) {検索課題の簡潔な表現。主に修飾語を伴なった名詞句。} ・検索要求は3つまでの自立語群と付属語(「に関して」のような独立に意味を 持たないものも附属語とする)で表現する。 ・検索要求で使われた3つの自立語群を適切なand/orで補った検索式を作成した 場合に、その式から人間の頭に浮かぶ情報要求が検索課題と重なるように調整する。 ●検索要求説明(Narrative) {人間が見て可能な限り曖昧なく判断ができる程度に詳細な検索要求の記述。 複数の文で表現され、必要ならば、辞書記述、同義語、具体例も含む。} ・人間が見て一意に絞れる検索要求を二、三文の自然言語文で表現する。 ［意見］ ・一見簡潔なqueryでも、実際に検索してみると曖昧な場合がある。 ・検索要求(Description)と検索要求説明(Narrative)は、あらかじめ分けておく。判定の際にもよい。 ・長いqueryを使った場合と短いqueryを使った場合では、結果が違いが出る。 ・TRECでも長いqueryと短いqueryがあり、選べるようになっていた。 短いqueryと長いqueryに対して、二種類の正解を作ってはどうか。 ［結論］ ・各参加者はDescriptionのみを使用したか、Narrativeも使用したか申告してもらう。 ・判定はDescription,Narrativeの両方の情報を利用して行なう。 ・「〜を除く」というネガティブ表現は非常に難しいので、予備試験では タグを付けて出題し、その結果を見て本試験の課題にするかどうか決定する ・Descriptionで用いた言葉をNarrativeでも使用するとは限らない。 1.3 検索課題のレベル設定 ￣￣￣￣￣￣￣￣￣￣￣￣ ・意味的な分類は客観的な判断が難しいが、構文的な分類は比較的容易である。 構文的な分類を採用してはどうか。 ・構文的な分類には以下の3レベルが考えられる。 1. 単一名詞句または複数名詞句がAND/ORに翻訳容易な付属語で接続している物 2. 「AのB」「Aに関するB」「Aに対するB」のような二つの名詞句と1つの付属語 3. 二つ以上の自立語が利用され、格解析などの複雑な解析が必要な表現 ・本試験では30検索課題を予定、各レベル毎に10課題ずつとしてはどうか。 ［意見］ ・検索結果を見ないで、単語のみからレベルを類推するのは難しい。検索結果を見ながら レベル設定を行ってはどうか。 ・難易度に関係なく全課題にシステムを走らせるだろうから、レベル設定は検索結果を 出した後で行ってはどうか。 ［結論］ ・原則としてレベル設定はしない 1.4 予備試験の課題の検討 ￣￣￣￣￣￣￣￣￣￣￣￣ ［意見］ ・予備試験はなるべく易しいもので行う。 ・予備試験とは言え全部易しいのは問題があるので、ある程度は予測してやる。 ［結論］ ・BMIRの課題(今回の議題の資料で挙げたもの)から少なくとも2〜3個入れる。 ・予備試験のレベルは、難しいものから易しいものまで入れる。 1.5 提出ファイルのフォーマット ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ <ＩＲ結果提出ファイル> ・結果は1トピックにつき300件。300を越えるものは、超えた部分は評価の対象外とする。 ・今回はランクのみを使う。スコアは任意で提出(オプション扱い)。 <ＩＲスコアファイル> ・基本的には再現率・適合率。 ・正解を2種類にする場合は、二つ作成する。 1.6 判定プログラム、ツールのデモ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ・特記事項なし。 1.7 正解判定方法(判定ランク) ￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ・まず学生2人が同じ課題の判定を行う。 ・学生の判定では以下の5段階の評価をしてもらう。 5：確実に関連する (BMIRのＡに相当) 4：関連するかもしれない、なんらかの関連がある (BMIRのＢに相当) 3：わからない、 2：ほぼ関連しない 1：確実に関連しない ・二人の判定が分れたものは、学生同士で話し合う。 ・最判定は、関連する、関連しないの2段階で評価する。 ［意見］ ・典型的な query を皆にやってもらい、判定の傾向を見てみる。 ・TRECの場合は3人(メイン1，サブ2)で判定。サブの得点はメインの半分以下となる。 ・BMIRの判定 A：一致 B：一部一致 ---+---参照 +---少し触れる C：不一致 ・ＢＭＩＲでは「主題は○○だが、テキストの××の部分が一部該当」のように根拠を 　記した。 ［結論］ ・学生6段階、最終3段階で評価する。 学生 6：確実に関連する (BMIRのＡに相当) 5：6だが不安 4：一部関連する、なんらかの関連がある (BMIRのＢに相当) 3：4だが不安 2：関連しない 1：2だが不安 最終 6：確実に関連する (BMIRのＡに相当) 4：一部関連する、なんらかの関連がある (BMIRのＢに相当) 2：関連しない ・学生判定で不安を表明する場合は理由を述べる事を推奨する。 1.8 正解判定者 ￣￣￣￣￣￣￣ ・NE,IR共に参加者は審判としては加われない。大学の学生が参加した場合でも、 その先生は審判とはなれない。 ・過去に共同研究をやっていて、そのシステムまたはその改良システムを使用して 一方のみが参加する場合には、もう一方はその研究を継続していない事を条件に 審判として参加できる。 1.9 その他 ￣￣￣￣￣ ・TRECでいうautomatic query construction のみとする。TRECではmanualで検索式を 作るというのがあるが、IREXではそれはなし。 ・本試験ではシステムは一つに限るが、予備試験では複数のシステムを出してもよい。 ただし、全部評価できるかどうかは分らない(参加者数による)。 2. 全体の運営 ￣￣￣￣￣￣￣ 2.1 参加予定者リスト ￣￣￣￣￣￣￣￣￣￣ 2.2 ワークショップの形態 ￣￣￣￣￣￣￣￣￣￣￣￣ ・なるべくオープンにしたいが、順位情報の一人歩きを避けるためにコンテスト 参加者のみに限りたいという要求もある。 * 参加者のみを希望：4社(企業は上司と相談しないとわからない) * オープンでも可 ：4社以外 ・ワークショップの内容として以下のものを予定。 * 全体の話(課題の説明、スコアの説明、人間のパフォーマンス等) * 各団体からのシステムの発表(各10ー20分) * ＩＲＥＸ２での課題等、将来に向けた議論 * デモ(？) ・2日間のワークショップになる予定。 ・予稿集は発行する予定。 2.3 結果の公表の仕方 ￣￣￣￣￣￣￣￣￣￣ ・団体名を実名で公表するか、略称で公表するか。 * 団体名を明確に公表(約半数の参加者) * 略称のみを公表し、略称と団体名の対応は公表しない(約半数の参加者) ［意見］ ・略称で出しても明らかにわかるものはどうすればよいか。 (例)「計量計画研究所」の略称「IBS」 ・どんな略称をつけてもいいというわけにはいかない。 (例)「計量計画研究所」の略称を「IBM」とする、など。 ［結論］ ・公式結果の所での団体名はＩＤ番号で公表する。 ・各結果とシステムのアンケートは連結させるので、そのような技術を使って そのくらいの成績を納めたかは分るようにする。 ・ＩＤ番号はランダムに作成し、各参加団体に送る。 ・各参加者は自分の発表の中では自由に結果を公表してよい。 ・この方法でやった時に、前述の4社に問題があるか調べてもらう。 2.4 ＩＲＥＸ２ ￣￣￣￣￣￣￣ ・ＩＲＥＸ２を開催するための手段、スポンサーを考えている。 ・技術的な課題として新しい物を取り入れたい。 ［意見］ ・予算全体で1000万円以上あるのが望ましい。 (cf.)今回の予算は200万円。大部分を学生の正解作成のアルバイト代に使用。 ・国から取ってくるのがよいのではないか。 2.5 データ公開 ￣￣￣￣￣￣￣ ・NE,IR共、正解データは一般に公開する。 ・ただし、IRについては作成に手間がかかるのと、参加を促すために、以下のように 公開内容に差をつける。 * IR参加者、審判者には、各システムが出したランクの情報、各判定者の判定結果と それにかかった時間などのIRの詳細データを公開。 * それ以外の人には(IREXに無関係な人も含む)、IRのデータは関連記事かどうかの 最終判断として作られた0/1のデータのみを公開。 ［意見］ ・規定に同意しなければデータをダウンロードできないようにするなど、もう少し 制約をつけてはどうか。 2.6 予備試験の日程 ￣￣￣￣￣￣￣￣￣ <日程に関すること> ・予備試験の日程を議案にあったものより約一ヶ月遅らせる。 (変更前) 1998年10月5日 ＩＲ検索課題配布 1998年10月12日 ＩＲ検索結果提出 (日本時間23時59分まで) 1998年10月13日 ＮＥ評価対象データ配布 1998年10月16日 ＮＥ抽出結果提出 (日本時間23時59分まで) (変更後) 1998年11月9日 ＩＲ検索課題配布 1998年11月16日 ＩＲ検索結果提出 (日本時間23時59分まで) 1998年11月17日 ＮＥ評価対象データ配布 1998年11月20日 ＮＥ抽出結果提出 (日本時間23時59分まで) ・判定結果は1998年12月末を目標に作成。 <日程以外に関すること> ・予備試験では多少(1週間程度)遅れた提出も受け付けるとしていたが、本試験同様 遅れた提出は受け付けないことに変更。 ・基本的にデータの交換はメイルで行うが、問題があればFTPの使用も考える。 ・予備試験のデータ：本試験参加の予定の人には平等に同じものを配る。 ・予備試験のスコア：参加者のみに流し、外には流さない。 2.7 今後の予定 ￣￣￣￣￣￣￣ ・予備実験で大きな問題が出なければ、本試験終了までミーティングはなし。 ・連絡手段はメイルを主とする。 2.8 予稿集でのシステム説明 ￣￣￣￣￣￣￣￣￣￣￣￣￣ ・各参加団体のシステムと実験に関する論文の他に、共通のdescription form (システムに関するアンケート)を行う。 2.9 その他 ￣￣￣￣￣ ・学会の後援 人工知能学会 (ワークショップに資金を提供してもらえる予定) 言語処理学会 、 電子協 ・NACSISのコンテストとの協力 IRの出力フォーマットを統一するか、変換プログラムを提供する ワークショップは9月に共同、または連続で行う (cf.) NACSISのIRコンテストのホームページ http://www.rd.nacsis.ac.jp/projects/test-collection/ 3. NE ￣￣￣ 3.0 全般に関わること ￣￣￣￣￣￣￣￣￣￣ ・正解データの作成は、関根(ＮＹＵ)、江里口(ＮＴＴデータ)が担当する。 ・定義については、10月16日まで議論を行い、10月17日にfixする。fix版はIREXの 　ホームページに掲載する。予備試験で重要な問題が発生したら、その時点で 修正を行う可能性もある。 ・「タグの範囲」「タグの種類」が一致しているものを正解とする。 3.1 NE定義 ￣￣￣￣￣ ・改訂版NE定義(ホームページから辿れる。9月末日までに作成予定)を参照。 3.2 NE_TRIAL ￣￣￣￣￣￣￣ ・NE本試験参加予定者は、NE_TRIALをやってみることを推奨する。 3.3 対象記事 ￣￣￣￣￣￣ ・すでに94、95年の毎日新聞を使ってシステム開発を行っている団体がある。 そこで、対象記事として毎日新聞の99年のデータを使用できるよう交渉する。 ・99年の毎日新聞データを使えない場合は、一ヶ月分の記事を手入力する。 ［意見］ ・公平を期すために、システムの開発は3月末日で凍結、4月1日から16日の記事を使って本試験を行う。 ・ドメインスペスフィック、ジェネラルともに4月1日から本試験の日までのデータを使う。 ・年度末は忙しいので、3月末〆切は避けたい。 ・5月13日を本試験とするなど、ある程度期間をおいてはどうか。 ・毎日新聞に限らず、99年に発行された書類は見ない(見る＝システム開発用に使用する)。 これを紳士協定とする。 ・新聞記事などを直接見なければ、知識は使ってもよい。 ［結論］ ・システムの開発は4月13日で凍結、そこから一ヶ月分の記事を使って5月13日に本試験を行う。 ・予備試験は94、95年毎日新聞から選んだ一般的な記事を対象とする。 3.4 ツールのデモ ￣￣￣￣￣￣￣￣ ・特記事項なし。 　　 以上