by 望月
場所，日時：ＳＯＮＹ　ＣＳＬ，１９９９年８月２０日

参加者一覧　（２０名）：
（敬称略、順不同）

ＮＥＣ　奥村
富士通　仲尾
富士ゼロックス　岡
国文学研究資料館　野本
リコー 　亀田，望主
豊橋技科大 増山
沖電気 福本
横国大  森
ＡＴＲ 山本
ＮＴＴ 稲垣
ＮＴＴデータ  平尾
通信総合研究所 　井佐原，内元，内山
ＮＹＵ／ＳＯＮＹ 関根
学情センター　影浦
通信・放送機構 福島
北陸先端大 奥村，望月

===========================
1．これまでの経緯の説明

   関根さんよりＩＲＥＸからの経緯、および今回の要約コンテストの枠組み
   についての説明があった．

   要約コンテストの組織運営は学情主導で行なわれ，
   経費に関しても学情から支出される．

   公式日程：2000年4月開始，2001年3月WS開催

2．今回の目的について，
  ・公式な日程に先立って，要約のサブタスクについて早めに手をつける．
  ・9月のIREX WSで提案する内容にしたい．

3．叩き台として用意された案についての話し合い

議案は2つに大きく分かれる

案1．「人間の被験者にテキストから要約を作成してもらう」
   という言語データの作成とそれを用いた要約システムの評価
   (言語データ作成とコンテストの開催)

案2．「タスクベースの評価」方法を用いた要約システムの評価

========================================================================
3-1. 案1について，

検討事項：
a. どのくらいの量が出来るか
b. 出力形式をどこまで要求するか(重要文抽出，重要文節抽出，自由作成など)
c. 誰に作業を頼むか(学生？，要約筆記者，．．．)
d. 要約の長さ，要約率(テキスト長との割合)，長さ(絶対長)などの選択
e. 評価方法
1) 文字列としての一致度
2) 読みやすさ，acceptabilityの主観評価
========================================================================

◯現実にどのくらいの量のデータを作成できるかという質問があった(検討事項a)
  これに対する解答は，
  ・予算の問題，どのくらいのqualityだと，どのくらい時間がかかるかによる．
	
  というものであり，これまでの参考事例も紹介された．

   *IREXでの作業を参考とすると，
	予算から考えると，アルバイト時間はだいたい1000時間

   *参考となる事例(別資料あり，望主さん提供)
	被験者100人(一般男女(学生，予備校生が多い))
	1人3記事(社説，総合，芸能)
	(1)原文から要約作成
	(2)原文から重要文抽出
	(3)(2)の重要文をできる限り使って要約作成

	期間3週間，費用(アルバイト代 1人8000円)
	データのやりとりに郵政省メールを使用し，データ入力者などの
	費用もあり，総額で200万円

◯言語データ作成について，どのようなデータが欲しいかということに
  ついていくつかの意見が出た．

  ・テキスト構造など，人手で作成したデータ作りを主にすすめる
  ・文と文の関係を木構造で表わしたデータが欲しい．
  ・単に研究者が共通に使える(著作権問題をクリアした)小説などのデータを
    用意するだけでもうれしい．
  ・要約のannotationづくりができると良い．
  
◯コンテストを開催するとしたら，言語データ作成をどのようにとらえるかという
  議論がされた．

  ・要約のテストコレクションを作成するイメージになる．
  ・(作成されるデータは)ある種の評価セットであると考える．
  ×差のつきやすい点しか扱えないのではないか？それがうれしいか？
  ×現段階で要約システムの評価をするには機が熟していない．
  ×ユーザの視点から見た要約に統一性があるのか？
  ・書き手側から見た要約なら可能なのでは？

◯評価をどのようにするか(するかどうかも含め)についての議論がなされた．

  ・要約の機械的な評価が可能かどうかは，評価方法や扱う(テキストの)分野に依
    存する．(新聞記事ならOK，物語は難しいだろう)
  ・(様々な評価を可能とするために，扱う分野に)バラエティのある言語データを
    作成すればよい．
  ・(人間による)ユレをある程度見越して，それを前提として，正解データを作成
    する．
    →評価もユレを考慮して行なうようにする

  ・最後は人間が良いと判断するべきものであるから，人間による評価を残して欲
    しい．
  ×コンテストでは，正解へのチューニング技術はつくが，独創的なシステムが
    損をするかもしれない．

◯言語データについて，どのように作成するかという議論(検討課題 c.)

  ・ある程度のクオリティを確保する必要がある．どうすればよいか？
    →あるスキルを持った人々に依頼する．
      例：国語の先生，編集者，記者など

    ×実現可能なのか？  → この場をそういう場にする(実現する機会に)

      *参考：NHKのOB記者なら大丈夫，要約筆記者も大丈夫

  ・国語の先生は個性的な要約になるかもしれない．
     → ユレの一種，次の項目参照．

  ・ユレの問題に関して，後でユレの分析ができるようなデータ作成方法を
    考える必要がある
     →データ(要約)作成の際に，(作成者が留意すべき)必要な基準を設ける

    案：要約作成者に
	・このような観点でまとめました．
	・ここを残した理由はこうです．
	というように，書き手(プロ)が要約の根拠にした点を明らかにして
	もらう

    案：上記 + このテキストから要約を作るなら
	・このポイントは必要だ
	・この文字列は必要だ
	というような，採点基準のようなものも決めて欲しい．

◯コンテンストに関して，コンテストをどのように行なうか(行なわないことも含
  めて)について議論がなされた．

  ・どのシステムが何%で何位というような方式は参加者内に抵抗がありそう．
  ・何がしかの数字を出すと，
        ◯エキサイティングで有益な議論が生まれるが，
	×数字が一人歩きするという弊害も発生しがち

  ・コンテストによるフィードバックを考えるなら，ゆるやかな
    (数字を出さないような)形でも，コンテスト形式にした方が良い．

  ・社説のような，分野によっては正解を作って機械的な評価もやってよい．
  ・物語のような，分野によっては感想を述べあう会のような形式にとどめる．
	・こういう技術でこのように実行したら，こんな要約になる．
	・正解のようなデータを色々用意して，
		Aの技術で正解1を扱える．
		Bの技術で正解2を扱える．
	というような内容の議論には持って行ける．

◯言語データ作成とコンテスト開催のどちらが主かという議論がされた．
 ・コンテストと言語データ作成のどちらが主かは決められない
	(それぞれの立場や考え方による)
 ・評価(をするということ)も含めて，今後も検討を続けていきたい．

◯評価をするには機が熟していないという意見があった．
 ・機が熟していないのは事実だが，だからコンテストしないのではなく，
   現時点でも役立つデータを作成できればうれしいはず．

 ・社説のように正解を作って機械的な評価ができる分野はやってもよく，
   物語のような分野では，感想を述べあう会のような形式にとどめると
   いう形でもよい．
 
◯今回のコンテストとはまた別に，長いスパンで言語データ作成を行なえる場
  を設けるというのは良いことなので考えたい．

■参加者が同意できそうな(orできている)事は以下のようになっている

・物語における正解要約は非常に難しい(という認識)
	・評価を行なうとしても，点数付けのような形はとりにくい

・コンテスト形式で直接採点できるようなデータだけでなく，多種のジャンル
  の言語データ作りを行なう．

・新聞記事のような分野なら直接評価可能．
	・機械的な評価，点数付けが可能

・しかし，直接評価が難しそうなジャンルもあり，そのようなジャンルでは，
  より緩い評価(人間による主観的評価)を用いる．

・読み手の視点は統一しにくいので，書き手側の立場で正解を作成する．

・人によってユレがあるということをあらかじめ念頭に置いてデータを作成．
	・ユレを考慮した評価方法も検討する必要がある．

・要約作成者はある程度のスキルを持った人に頼む

========================================================================
3-2. 案2(タスクベースの評価)について，

(タスク1) IR
(タスク2) Q & A  これには2種類のタスクが考えられる．
 ・2-i  Qを公開し，システムが要約を作成，
	人間の被験者がQに答えられるかどうかで評価
・2-ii  Qを公開し，システムが要約を作成，
	あらかじめQと共に用意しておいた Aパッセージとの一致度で評価
========================================================================

◯タスクベースの評価に関しては，言語データ作成ではなく，システムの評価に重
  点を置くという点でほぼ合意が得られた．

●(タスク1) IRに関して，原案に対し，特に反対意見はなかったが，以下の
  議論がなされた．

◯要約の形式，表示に関して
  ・表示フォントの大きさなどは自由なのか？
    →見せ方を議論しない方向にしたいので，指定し統一する．

  ・提案では，「形式を限定しない」としているが，
    情報抽出の要素は，入らない方がいいのではないか．
     → Q & A で扱うことにするのが良い．

  ・「一行にせよ」の方が良いのでは？という意見も出た．

◯評価方法について，
  ・(テキスト選択，正解の比率なども含め)コンテストに徹するなら，
    前例(SUMMACなど)と同じにするとか，ある程度実績のある方法が良い．
    → みんなが納得する評価手法を選択することが第一であろう．

◯今後は，叩き台となる案を出し，細かい内容をつめる方向で話し合っていく．

●(タスク2) Q & Aについて
タスク2では，「Qの作り方」をどうするかという問題が議論の中心となっていた．

  問題点．
  ・Qの難しさなどをどうやって決定するか？
  ・Qの作り方は非常に難しい．
  ・Qによって，要約の性質が変わる．

  問題作成に関して，
  ・日本語検定で，Q & A の Qになるような問題はないか？
  ・入試問題ではどうか？
  というような提案もされたが，タスクベースの要約評価方法自体が，間接的
  な評価をしているので，問題作成を間接的なものにすると，何を評価してい
  るのかはっきりしなくなるという点が指摘され，このような方法で問題作成
  をするのは好ましくないのではないかという反対意見も出た．

***タスク 2-i について，

◯人が答えを作成する(答える)のに，どの程度の知識を仮定するのかという
  問題が指摘された．

  ・要約の内容を読まなくても，(一般知識などで)答えられるような
    Qでは困る．という点では意見の一致が見られた．

◯被験者にテキストを読ませてから，Qを出すか，Qを見せてから，
  テキストを提示するか，どちらが良いのかという意見が出た．
  ．．．．検討課題に．

◯案1での一般的な要約に近いように思われる．

◯要約をあるタスクに役立てたいという，タスクベースの考え方にあっているか？

◯Q & A を情報抽出への前段階というように捉える．
  ・情報抽出のテンプレートが Qになっていると考えられる

◯対象をマルチドキュメントとして，答えを串刺しにするような方式はという提案
  があったが，
  ×技術水準として厳しい．という意見が大半であった．
 
◯Qの設定は非常に難しい問題であり，今回の話し合いでは具体的なことは決定
  していない．今後も検討していくことになった．

***タスク 2-ii について，

タスク2-iiに関しては，NTCIRの別のサブタスクとして，answer passage
extractionが企画される可能性があり，それとの重複を避ける等の配慮が必要
である，また，TRECのQ & A トラックに近いという指摘があり，実施するなら，
Q & Aタスクを独立させても良いのではないかという意見が出た．
  そのため，今回の話し合いでは2-iiについての議論は保留され，今後の検討
課題とされた．

=====================================================================
その他

・TRECのQ & A トラックと， SUMMACの Q & A タスクとの混乱が見られた．
	・今後名称なども混乱しないようにする必要がある？

・今回の参加者を中心としたメーリングリストの早期開設を望む．
  ・特に言語データ作成に関する議論などに有効利用していきたい．

・今回の議事録もメーリングリストに流して欲しいとの希望が出た．
=====================================================================