jackee777のブログ

情報系学生のつぶやき

NTCIR 14 QA poliinfo Segmentation

自然言語処理 segmentation NLP NTCIR

NTCIR 14 の論文含め終わったようなのでまとめます．

当方は，インターンで segmentation に関わった程度です． 論文までは関わってないのでカンファレンスには参加していませんが，どれに関わっていたかは読めばわかってしまうかも．半分は2018/08のインターン参加報告ですね．

とりあえず，segmentation について書いて，summarization と classification は興味があればという感じです．

NTCIR について

NII Testbeds and Community for Information access Research の略だそうです． NII の project の1つということみたいですね．

こういった試みとしては， SemEval - Wikipedia は知っていましたが，NTCIR は正直知りませんでした．

今週行われた NTCIR-14 の QA のタスクに関する詳細はこちらにあります． https://poliinfo.github.io/NTCIR-14-QALab-PoliInfo-4thRoundTableMTG.pdf また，論文形式でも自然言語処理学会で発表されたようです． https://www.anlp.jp/proceedings/annual_meeting/2019/pdf_dir/C2-2.pdf

これらについては，github でも公開されており，議論には応じたいとどこかで見た気がします． github.com

segmentation task について

スライドに基づいて説明していきます．

このタスクでは 入力を議会会議録に含まれる「発言」と要約の「制限字数」と「議会会議録」として，引用を理解するために読むべき発言の範囲（「開始行」「終了行」）を予測します．

発言と要約についてはこのようになっています．

f:id:jackee777:20190613013405p:plain
Segmentation Task

先ほどの発言者，要約，日付等の譲歩が json 形式で配られ，それらが書かれている行数を当てようという感じです．

f:id:jackee777:20190613013904p:plain
予測

また，今回の場合は東京都議会を対象としているため，こちらのページで閲覧可能です． www.gikai.metro.tokyo.jp こんな感じで取れます．time sleep については robots.txt には記述なし？？？怒られたくないので，10で書いてます． https://github.com/jackee777/some_codes/blob/master/crawling/tokyo_meeting/scrape_tokyo_info.ipynb

スライドの例ですと， 平成二十三年東京都議会会議録第八号がそれに当たります．

どうやら，村上英子氏の発言の前半部分というのが正解のようです．

まとめると

  1. 「Date」と「Meeting」の情報から会議録を「平成二十三年東京都議会会議録第八号」に限定
  2. 「*Speaker」から発言の候補の抜出
  3. 「*Summary」等から，該当する発言箇所について導出

みたいな感じです．

例としては

  1. 「23-6-23」と「平成23年_第２回定例会」の情報から会議録を「平成二十三年東京都議会会議録第八号」に限定
  2. 「村上英子（自民党）」から「村上英子」氏の発言の抜出
  3. 「国難のもとにおける東京の役割について～」等から，該当する発言箇所「初めに、東日本大震災～二つの課題に、（中略）知事の所見をお伺いいたします。」について導出

このタスクを解く利点については，膨大な議事録から該当箇所を容易に得られることだと思います． 確かに，議事録すべてを読むのは心が折れます．「〇月〇日に知事が～～って言ってた」などと言われても，はあ・・・調べんの嫌だなあって感じです．

このタスクの難しい点としては

  • 東京都議会側の回答者は複数回登壇する点
  • 一つの質問，一つの回答がひじょーーーーに長い点
  • 該当箇所の1文は比較的容易にわかるが，「引用を理解するために読むべき発言の範囲」は容易ではない点（precision の方が簡単で，recall の方が難しい）

です．

今後の発展としては，１．２．で与えられている情報を使わないことが考えられます． 正直言ってしまうと，回答者は難しいですが，質問者については現在与えられている情報があれば 該当箇所を見つけることはそこまで難しくないというのが理由です．

実際問題，「〇月〇日に知事が～～って言ってた」とまで明確に言うのは学術系の人間くらいでは？と思います． 一般の人は「なんかチラッとTV見てたら※※って言ってたような・・・」みたいな情報としても微妙だし，喜怒哀楽も取れない文が全然ある気がします．

逆に，そういったちょっとした情報から，都議会議員の発言と都民の感情を結びつけることができれば，非常に意味のあるタスクになるなと感じています（これはこのタスクが現状意味がないという意味ではなく，より良いタスクへの方向性がいくつか考えられるという意味です）．

データについて

github を見るのが早いですが，先ほどの json と行ごとに区切った都議会の文章が渡されます． 行ごとに区切ったものを配布するのは公平性のためだと思います．

training 用の json は合計で298個あり，訓練データは298個しかないことになります．8月のインターン時にはもっと少なくて，機械学習なんて無理ぽよって思いました．

test 用の json は合計で82個あり，これらは非公開でした．多分

加えてですが，会議録では同じフレーズが使いまわされることが多いようです． 例としてはこんなです．

  • 文頭には，「まず」や「次に」といった接続詞
  • 質問時には，「を伺います」などのフレーズ
  • 回答時には，「検討してまいります」や「対応してまいります」などのフレーズ

件数を見るとすぐわかるのですが，質問に比べると回答の方が多岐にわたることが分かります． この点においても，回答の方が抽出が難しいことがわかります．

一応，見れるようにしておきました． https://github.com/jackee777/some_codes/blob/master/crawling/tokyo_meeting/check_NTCIR14/check_NTCIR.ipynb

評価指標について

Precision, Recall, F値です．※F値は github 上にはなく，Formal Run ではある感じです．

github では次のようにあります．

  • Precision列: [一致] / [解答範囲が表す個数]（Question と Answerを合わせたもの）
  • Recall列: [一致] / [正解範囲が表す個数]（Question と Answerを合わせたもの）

※一致というのは解答（予測）行数が80~89であり，正解行数が85~90であれば，85~89が一致となります． この時

  • Precision = (89-85+1) / (89-80+1)
  • Recall = (89-85+1) / (90-85+1)

となります．

Formal Run の結果

f:id:jackee777:20190613044321p:plain
NTCIR_Formal_RUN_結果

https://poliinfo.github.io/NTCIR-14-QALab-PoliInfo-5thRoundTableMTG.pdf

NAMI の結果が分かりやすいですが，解答行数が少ないほど Precision は出しやすいので，解答範囲によって Precision と Recall が trade off します

論文について

RICT，NAMI と KSU について見ることにしました（F値 0.8 越えしてたもの）． 後ろ2つの解説はちょっとサボったのもありますが，図が見やすかったので，それで十分というのが強いです．

各論文はこちらからhttp://research.nii.ac.jp/ntcir/workshop/OnlineProceedings14/NTCIR/toc_ntcir.html

RICT

http://research.nii.ac.jp/ntcir/workshop/OnlineProceedings14/pdf/ntcir/02-NTCIR14-QALAB-YongJ.pdf by リコー

Introduction 要約と文章を対応させることは必須ではないが，一部の文章だけを抜粋してしまうと誤解を招く恐れがある．そこで，segmentation step と search step という2段階で解くことで考えることにした．

  • segmentation step: 会議録をトピック毎に分割
  • search step: 要約に相応しい segment を分割した segment の中から探索

概要 * データの用意

与えられたデータは，segment 用にはできてなかったため，自分たちでラベル付けして training と test 用に分割

  • segmentaion step について

dry run （formal run の前にあったテスト）では，segmentation には nltk の TextTilling *1を使っていたけれども，従来の segmentation では要約にある手掛かりとなるフレーズが分割に使われていなかった．そこで formal run では手掛かりとなるフレーズが使われる手法をいくつか試した．

segmentation を解くにあたって，分割するかしないかの2クラス分類として問題を解いた． 手法はいくつかあって

  1. ルールベース

    f:id:jackee777:20190613075700p:plain
    RICT_segmentation_rule

  2. 分割候補の前後10単語（計20単語）を入力とする SVM．入力ベクトルは BoW を Latent Semantic Indexing で100次元に圧縮したもの

  3. semi supervised ここだけはかなり厄介なことをしている．次のようなことを繰り返す． （１）すでに分割されている箇所に基づき，分類器を学習（２）分類器によって分割（３）分割数に基づき，negative を適切にサンプリング これを繰り返すことで，最終的に分割することができる．分類器には Logistic 回帰と SVM を用いた模様． すなわち，正解を作り出しながら，再帰処理的なことをしているぽい．賢い． ※一番最初の分割は「話者」．議事録上で分割されている

  4. なんもしない

  5. LSTM 前後の文の「前10単語後10単語」の計20単語を入力とする LSTM．入力ベクトルは100次元の word2vec

  6. HAN https://www.cs.cmu.edu/~./hovy/papers/16HLT-hierarchical-attention-networks.pdf formal run の後に走らせたらしい．入力は LSTM と同じだが，embedding 層，attention 機構，双方向の GRU を使った NN．

f:id:jackee777:20190613081057p:plain
HAN

  • search step について

dry run では，e Amazon Elasticsearch Service を使っていたが，要約の中には”[1]〇〇について[2]××について”という複数の segment からなるものがあったため，必要以上に segment が連なってしまっていた．閾値の設定が難しかったため，自ら実装したものを使用．

実装はシンプルな確率モデルでなされ，summary 中の単語が文章に連続して現れる確率を計算して導出． （ちょっと疲れたので略）

結果 * segmentation の結果 rule base が最も良いが，SVM と HAN も強い

f:id:jackee777:20190613083316p:plain
RICT_segmentation_result

  • formal run に対する結果（平均） segmentation の結果とほぼ相関があり，HAN が強い segmenta
    f:id:jackee777:20190613083513p:plain
    RICT_formal_result

まとめ semi-supervised のところも検証されてたりする．気になる方は見てください．

  • segmentation task に手掛かりとなるフレーズを導入することに成功
  • rule base が最も良かったが，機械学習による手法も同じくらいの精度を達成
  • semi-supervised の手法を使えば，ラベルを振らなくても済むかもしれない
  • こういった手法の benchmark になるのでは

感想 個人的には，試したものが多かった．考え方はほとんど同じで，自分も2段階だなと思ったし，classification task として解こうということも同じだった． （参加したのはここではないが，自分は前後の文を入力にした LSTM を組む直前でインターンが終わってしまったので，仕方なく Random Forest を組んだが．あと，GRU は？データ少ないし，パラメータの少ない GRU の方が強かったのでは？という疑問も試してくれていて良かった．）

著者としても，semi-supervised が推しなのかな？とは思ったのと，semi-supervised が一番面白いと思った．

NAMI

http://research.nii.ac.jp/ntcir/workshop/OnlineProceedings14/pdf/ntcir/15-NTCIR14-QALAB-YokoteK.pdf by 日立

概要

  1. 役職の検知（会議録の冒頭等に情報がある）
  2. 発話者の対応付けによる segment の絞り込み（誰に対しての会話かを検知）
  3. クエリの再構築

  4. オントロジーに基づくクエリの拡張

    f:id:jackee777:20190613084849p:plain
    NAMI_概要

  5. クエリに基づいて全組み合わせを探索 カバレッジ（cov），出現頻度（occ），チャンクサイズ（chu）の長さの3つの評価軸を用意し，文章を評価している（効果的には，簡易的なアンサンブル？）．

    f:id:jackee777:20190613090924p:plain
    NAMI_Q_数式

結果 一番，F値が上がった場合だが，query の拡張が効果を示していることがわかる．

f:id:jackee777:20190613090512p:plain
NAMI_result

感想 クエリを拡張することで recall が改善していることから，単語の置き換えを検出することで，summary の情報の網羅性が上がると考えられる．よくよく考えると，この手法だけ segment の境界についてはあまり触れていないので，recall と segment の正確さの関係性が気になると思いました．

＜追記＞ この手法ですが，オントロジーを使わなくてもクエリの拡張というのは可能という点で，最も他のサービスには使いやすいのでは？と思います．実際，私は学部4年生に対して「難しいことをやる前に，今のあなたにもできる単語ベースなところからやってみては」と提案しました．最近の多くの手法では，文単位の similarity を取る例は多いですが，容易な technique である doc2vec などでは目的の意味での文章の類似度を取れないことがあるかと思います．そういった場合には簡易的な用法として，単語ベースな手法は十分に聞くかと思います．例えば，tf-idf の重みと word2vec のベクトルを組み合わせて文章ベクトルを得る手法が論文としても出ていたと思います（気になる方は How to get vector for a sentence from the word2vec of tokens in sentence - Stack Overflow や 文書ベクトルをお手軽に高い精度で作れるSCDVって実際どうなのか日本語コーパスで実験した(EMNLP2017) - Qiita を参考にしてください）．

KSU

http://research.nii.ac.jp/ntcir/workshop/OnlineProceedings14/pdf/ntcir/12-NTCIR14-QALAB-KimuraT.pdf by 京都産業大学

概要

  1. 質問と回答の分割
  2. 日付と Speech Type (ST) によるフィルタリング（質問，回答，報告，まとめ，etc）
  3. SD から抜き出す際に Speaker Filtering を適用（話者の限定．例外あり）
  4. 単語頻度（WF）によるテキストの大まかな分割*2
  5. ルールベース（RB）による segmentation 範囲の決定
    f:id:jackee777:20190613092537p:plain
    KSU_概要

上でいう4がstage1，5がstage2です．

f:id:jackee777:20190613092630p:plain
KSU_イメージ

結果 * スピーカーのフィルタリング（SF）は非常に有効 * 単語頻度による境界の決定（WF）とルールベースによる境界の決定（RB）はどちらも効果を示したが，RB の方が

f:id:jackee777:20190613091541p:plain
KSU_result

感想 一文を当てる制度は非常に高かったことが見て取れますが，質問者側の精度がよろしくなかったみたいですね．単語頻度による分割は読みながら，RICT にもあったように上手くいかなそうだなと思ったので，そんな感じでした．ただ，単語頻度による分割をしたときは precision が異様に高いので，segment が大きいと starting point が間違いやすかったのかなあなんて思いました（わからぬ）．

Discussion（個人的な感想）

先に，こうでも良いなあと思ったことを書きます．

  • NTCIR についてのところで書きましたが，「日付」，「議会名」，「発言者」の情報がない場合についても検証
  • データ数の増加（データが少ないので，機械学習とルールベースのどちらが良いのか議論の余地が残るのではと感じました）
  • 参加者の増加
  • 正解に関する一貫性の担保（引用を理解するために読むべき発言の範囲が人によって違う）

最後のところだけ補足すると，「引用を理解するために読むべき発言の範囲」というのは曖昧で，わざと曖昧にしているのかなとも思いました．

若輩者が言うのは申し訳ないですが，この曖昧性は予測モデルの設計の上では非常に重要なのではないか？と思いました． 具体的には，「それでは、都議会公明党を代表して質問いたします。」は「日本観測史上最大のマグニチュード九を～」と続くのですが，この「日本観測史上最大のマグニチュード九を～」から切り取っている箇所もあるのではと思いました．

おそらく，タスク全体に影響を及ぼすほどではないとは思いますが．それも含めて，結構難しいなあと思いました．

まとめ

そもそも，このページを書こうと思ったのが，RICT で LSTM のフレーズを見たからなので，RICT の論文はとても面白かったです． ルールベースが一番いいのはわかっているから，それをどうするかというのは正しいように思います．

（一方で，ルールベースでできるものをわざわざ機械学習でやる意味というのも考える必要はあるんだと思いますが，ちゃんと時間をかけて作ったルールベースに勝てるのかな？というのは疑問です）

なんというか山本さんの

を見た後だと色々考えてしまいます．

RICT に釣られて読みましたが，応用タスクも面白いですよね． こうして，ブログも書けるしインターンが無駄な時間でなくてよかったと思います（インターン先には落ちたので笑笑）．

属性的には，質問と回答で分けているものはありましたけど，モデル全体として質問と回答で分けた例はなかったのかな？とふと思いました．

*1:http://kesin.hatenablog.com/entry/2013/07/23/%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%BB%E3%82%B0%E3%83%A1%E3%83%B3%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E7%A0%94%E7%A9%B6%E7%B4%B9%E4%BB%8B

*2:https://pdfs.semanticscholar.org/4b5a/3e77fa3ca6b2cf91cda4e602bdf2ad3e9969.pdf