自然言語処理の研究に悩む その2

前置き

あらすじ

 自分の研究的なトピックは「機械による読解 machine reading comprehension 」です。およそ雑に言うと、言語理解のモデル化のひとつの手段として「国語の文章題が解けるようなシステムを作る」のがこのトピックの目標です。ここ2,3年でそれなりな流行を見せており、大規模(問いが数万個、の単位)なデータセットが数多く出てきて、それを解くようなニューラルなシステムがたくさん提案されています。中には人間の精度に匹敵する性能を出せたものもあります。

 しかしこのような進展を見ても、システムに人間と同等の文章読解力があるとは到底思えない感じがします。システムを評価する側のデータセットが簡単そうに見える、というのが大きな理由としてあります(そして難しそうに見えるものは案の定解けません)。大規模なデータセットを作ろうとするとどうしてもクラウドワーカー等に依頼することになり、いわゆるちゃんとした国語の試験問題のような難易度になってくれないことが往々にしてあります。ではどうやったら難しそうな問題が作れるのでしょう。そもそも難しい問題とは何が難しくて、簡単な(という印象を受ける)問題は何が簡単なのでしょう。わかりません。ということで悩んでいました。

この1年くらい何をしていたか

 前の記事が2017年11月でした。2017年の末から2月末くらいまでは、 ACL2018 に何か論文を書こうと思って作業していました。ひとつの方針として、「読解の問いの難易度」を「ベースラインのシステムの正答率」だとみなして、それを予測するというタスクを考えてみました。「この特徴を使ったらシステムが正当するかどうか当てられるよ」と言えるような特徴をうまく見つけられれば、それが(少なくともシステムにとっての)難易度を決定づけるような要素だと言えそうかなと思いました。しかし色々試してみてもさほど綺麗に予測できる感じでもなく、効くような特徴がさほど面白くもなく、という感じで、弱気に short paper を書いたものの上手くまとめきれず、綺麗に不採択でした。

 上記の論文の査読が返ってきた時点でこれはダメだと思ったので、切り口を変えて EMNLP2018 に向けて何か考え直そうという気持ちになりました。その頃ちょうど NAACL2018 の論文が出始めていて、 [1803.02324] Annotation Artifacts in Natural Language Inference Data という論文が印象に残っていました。内容としては、 SNLI / MultiNLI という最近あれこれ取り組まれている含意関係認識(のことだと認識しています。詳細は省きますが、 X と Y という2つの命題が与えられて、 X が真のときに Y が真になるか(entail)・何とも言えないか(neutral)・偽になるか(contradiction)を当てる、というタスクです。例は論文の図を参照してください)のデータセットで「 X を見ずに Y の情報だけ使っても正答できる」ような問いが結構たくさんあって全然ダメよね、と指摘するような話です。同様の指摘をする論文は同時期に複数出ています。

 じゃあ同じようなことを読解のデータセットでもやれば良さそう、ということで新たな方針がおおよそ固まり、あとはその「こんな簡単に解ける」的トリックの部分を(これで大丈夫なのかと心配になりながら)考えて、調査対象のデータセットは多ければ多いほど良いだろうとなるべく増やして、結果をまとめてアノテーションで裏付けも取って(ここは査読でツッコミ対象だったのですが、急いでいてそこまで丁寧な作業ではなかったので、継続する予定です)、書いて投稿して、インターンに行きました。5月末までの話です。

 インターンについては別途記事にするかどうか迷っていますが、ひとまずここに経緯だけまとめます。2018年6-9月でカナダのモントリオールMicrosoft Research に行きました。ここは2017年の頭に Maluuba というスタートアップが買収されてできた研究所で、主要なメンバーはその時代からの人たちです。当時からの会社的なテーマは(たぶん) literate machine を作るぞという感じで、そのための主要な話題のひとつとして機械による読解云々を据えています。でそこの偉い人が昨年の ACL2017 の自分の論文を会議直前に見てくれたらしく、連絡をもらって現地で挨拶して、まあ来なよと言っていただけたので行きました(人事の方の連絡がルーズで最終的に行けたのが翌年夏になったわけですが、時期的な感覚はよくわかりませんでした)。モントリオールでの生活は特に家を探す部分が大変でした。日本食もそこまで充実していないのでちょっと食事に困ることもありました。あと思ったよりも暑かった。ただオフィスの環境がかなり良かったのでなんとか生きていけました。取り組んだテーマは自分で決めて、まだ着地しておらず、たぶんあと数ヶ月はかかりますが、きちんと形にしたいと思っています。

 話を戻します。 EMNLP2018 に出した論文の査読結果は意外とそれなりに良く、気持ち的にはあっさりと通ってしまいました。ただこれ自体が進展かと言われるとそうではない気がしています。この論文を含め、今まで自分が取り組んだ論文では既存のデータセットを批評する話しかできておらず、つまるところ何も積み上げられていない気持ちが強いです。何かをちゃんと作る側にまったく回れてないよドラえも〜んみたいな感じです。(インターンでやった内容はそのための次の一手ではあるものの、独立な取り組みかつ未完成なのでちょっと脇に置くとして、)次はどうすればいいのだろう、ということを考えたい気持ちです。

最近の業界の動向

 現状を把握するところから始めましょう。まず、読解のトピックに限らず、言語理解に関わるデータセットのうち、最近提案されたものを見てみることにします。列挙しようと試みたら数が多かったので、2018年が初出のものに限定し、新しいものが上になるようにして、特に気になることがない場合は一言だけ説明をつけるに留めました。コメントがたくさん書いてある論文はこの記事を書く際に改めて読み直した(比較的新しい)ものです。およそ箇条書きの1点目がデータセットの説明です(2点目以降は細かい話で、おそらく論文を見ながらでないとわからないです。記事の流れからは逸れるので読み飛ばしてください。長くてすみません)。図表などはコピーしていないので、興味がある場合は論文を直接参照していただけると助かります。一覧を github のレポジトリ に作りました。

  • CoQA (A Conversational Question Answering Challenge) https://stanfordnlp.github.io/coqa/ (TACL??)
    • 文章と対話形式の質問応答のデータセットクラウドワーカーのペアに何らかの記事を見せてそれについての質問応答を会話形式で連続でやってもらって集めた感じ。特徴としては、会話形式なので問いに出てくる表現がそれ以前の会話内容に依存する(照応や pragmatic な表現が入る)こと、回答の際に答えの根拠をまず抜き出させてから答えをその rewrite として自由記述させていること(正当の信頼度・一致度を上げるため)、記事の題材がいろいろあること(ドメイン7つ)。
    • 説明的な記事の内容ベースでワーカーに問いを作らせるとき、回答の候補が複数保証されるような問いがちゃんと作れない可能性がある。それをケアしようとは試みていて、 we select passages with multiple entities, events and pronominal references と書いている。どれくらい効くのかはわからないけどこういうのに気をつけているのは好印象。
    • 自由記述とは書いているけど、そのままの表現が文中に出てくるような答え(extractive と呼んでいる)は依然として 66.8% あるらしい。対して abstractive な答えである 33.2% の内訳は何かなと思って表を見てみると yes/no が全体の 20% ほどらしいのだけど、どれくらい重複があるんだろう(つまり、文中に yes/no が出てきてそれが答えになる問いの割合)。ある程度の重複があるなら abstractive のうち半分くらいは yes/no なのかも、という気もする。
    • Linguistic phenomena の分類はもうちょっと掘れた気がする。 explicit coref が記事中への coref も可能ならあまり context dependent とは言えなさそう。そうなると注目すべきは implicit coref で、割合的には 20% なので、どうやってこれを増やすかが future direction のひとつになるのだと思う。あと気になるのは、 Table 7 で question type ごとの正答率を出しているけど、 no coref (対話履歴を見ずにその問い単体で回答可能なもの)よりも implicit coref の問いの方がベースラインの精度が高い点。これだと「implitic coref がいまのモデルに解かれていなくて、これから解くべき課題だ」という主張がしづらそうな……。
    • Lexical match / paraphrasing / pragmatics という分類をすると pragmatics の問いが(人間にとってもベースラインのモデルにとっても)難しいということがわかる。これが conversation history にどれくらい関わっているのかわからないけど、問いのタイプとしては(lexical match & paraphrasing の補集合なので)知識推論みたいなところに落ちるはず。対話形式にしても implicit coref がそこまで面白くなさそう(つまるところ履歴の直前を見れば解けるような話になってしまっている?)っぽいので、こういう推論させる問いをどうやって増やすかという方針に進むのもいいのかなと思う。
    • 次に挙げている QuAC というデータセットとモチベーションはほとんど同じだけど、全体的に CoQA のほうがまとまりがよい気がする。
  • QuAC (Question Answering in Context) https://quac.ai (EMNLP2018)
    • 文章と対話形式の質問応答のデータセットクラウドワーカーのペア(甲と乙)がいて、 Wikipedia の記事の中の一項目が甲に与えられて、乙が相手に質問を投げまくる(乙は記事の内容を見られず、その項目のタイトルのみ与えられる)。甲は乙の質問に(記事の抜き出しで)答える他に、これ以上会話が続けられそうな内容かどうか、回答不可能な問いかどうか、抜き出しではなく Yes/No 、などの情報を乙に伝えることができる。甲乙の会話は連続したやりとり(最大で質問12回)で、会話の履歴に文脈的に依存することになるのでたとえば照応解析が必要になる問いが発生する。
    • 論文自体はちゃんと書いてあるけど、どうにも面白くない気がする。まず乙の応答が記事の抜き出しに制限されている(評価が難しいからというのが理由。同意するが超えなければならない点ではある)。データセット収集に使われたのが wikipedia で、かつ「人物」についての記事に限定されている。 Dialogue acts が含まれると主張しているものの本来的な意味で act なのは質問しかない気がする。評価に出てくる human equivalence score というのがどれくらい意味があるのかよくわからない。Yes/No の選択肢は正確には yes,no,neither だったらしく、 neither が majority になっていて human performance と 10% しか差がない(残念)。 gold sentence + no answer の upper bound で human performance と 8% しかない(大丈夫かな)。「もっとも近そうな sentence を予測してから範囲選択 + 回答不能判定」の組み合わせで工夫したら簡単に human performance に到達しそうな気がする。 context の参照が必要と書いているけど、必要な距離についての分析がない気がする(見落としてたらすみません)。この分析がないと、 BiDAF++ (w/ 2-ctx) が最も良い成績だったという結果を見たときに、問いの直前の 2 QA pairs だけ使うので十分な問いがほとんどなのか、本当はもっと遠くを見る必要があるけど BiDAF がそれに失敗しているのか、の区別がつかない(たぶん前者だと思うけど論文中では後者のように書いてある)。あと些細だけど論文中の図の参照の仕方がところどころ悪くて論文が読みづらい。
    • など、気になる点がちょっと多い。CoQA と共に発展の方向性としてはかなり自然で、対話にも興味がある人も見ることになると思う。重要な特徴として挙げられるのは問いが少し文脈依存になっている点と解無しの問いがある点の2つだと思うけど、それぞれ CoQA と SQuAD2.0 の方が良い気がするのでこのデータセット独自の強みが見えづらくて残念。
  • HotpotQA https://hotpotqa.github.io/ (EMNLP2018)
    • Multi-hop reasoning をテーマにした質問応答のデータセット。 multi-hop というのは例えば "When was the singer and songwriter of Radiohead born?" という問いに答えるには "the singer and songwriter of Radiohead" が "Thom Yorke" であることを見つけてから "When was Thom Yorke born?" の答えを探す、というような二段階の推論が必要とされることを指す。 Wikipedia 上でリンクがある2つの記事の1段落目同士をうまくくっつけてからクラウドワーカーに問いを作らせている。さらに comparison question というのも作らせていて、 Wikipedia 上で「〜〜のリスト」として整理されている記事を2つ持ってきてそれらを比較させるような問いも作らせている。さらに、記事中の「問いに答えるために必要な情報」を文単位でクラウドワーカーに選択させる、という作業も経て説明可能性を保証している。
    • test set は distractor と full wiki という設定に分けている。前者は正解となる two gold paragraphs に加えて問いとの bigram tf-idf が高い top eight paragraphs を含めて10個の paragraphs から答えを見つける。後者はすべての Wikipedia の記事の1段落目が与えられる(とても多くて答えがどの段落に入っているかわからない)ので information retrieval のタスクを含むことになる。
    • 単に回答を抜き出す以外に「問いに答えるために必要な情報」の選択もタスクに含めている。ただしこれは回答の選択よりは主観的なので人間の一致度がそこまで高くないと言及されている。こっちがタスクとして面白いかどうかはちょっとわからない。
    • distractor の QA のベースラインは全体で F1=0.58 くらい。対して人間の精度は(たぶん distractor なしの gold paragraphs だけで)サンプルされた1000題に対して F1=0.91 くらい(同じ1000題に対してのベースラインの精度は F1=0.69 くらい)。上限の数字も出しているけど信頼できるかどうかは微妙だと思う。人間とシステムで今のところ F1 が 0.2 くらい開いているので一応はおっけーなデータセットだと言えそう。一方の「必要な情報の選択」のタスクは gold paragraphs のみの精度が人間とほとんど同じなのでよくわからない(いずれにせよ distractor の精度を比較するなら人間の設定も揃えるべきだと思う)。
    • multi-hop のタイプを分類しているけどタイプ別の精度が見たかった。 Table 3 で出されている例はほとんど回答の候補を multi-hop なしで絞れると思うので、タイプ別で精度の差が出るかどうか怪しい気がする(そもそもアノテーションが少なくて有意な差が出ないかも)(comparison との比較は Table 6 で出ており良いと思う)。
    • なぜ hotpot なのか気になったけど脚注に "The name comes from the first three authors' arriving atthe main idea during a discussion at a hot pot restaurant." と書いてあって良さがある。 retrieval のタスクっぽく置いた方針はあまり自分の好みではないけど、問いの集め方などは面白いと思うし問いのフィルタリングや回答の候補の保証などをもうちょっと工夫できたら更に良かったかなと感じた。
  • SWAG (Situations With Adversarial Generations) https://rowanzellers.com/swag/ (EMNLP2018)
    • 動画のキャプションから取った連続した2文の、2文目の動詞句を選択肢で当てるタスク(textual な event prediction みたいな感じ。著者は situational commonsense reasoning と言っている)。選択肢の候補は、言語モデルでたくさん作ってから、(annotation artifact を避ける目的で) stylistic features を利用するモデルが間違えやすいものを選ぶようなフィルタリングをして、最後にクラウドワーカーに verification してもらっている。
    • 全体的に完成度が高い。今後はデータセットを作るときに簡単なモデルでフィルタリングするというのが増えると思う(この研究は選択肢を作るときにそれをやってる点でわりかし新しい気がする)。
    • 考えさせられたのは、「続く2文目を選ぶ」というタスク設定について。著者はイントロで here we focus on whether a (multiple-choice) ending describes a possible (future) world that can be anticipated from the situation described in the premise, even when it is not strictly entailed. と書いていて、わかっていらっしゃるという感じで文句が言えないのだけど、どうやったら今回の手法を他の種類の常識推論のためのデータセット構築に使えるかなという今後の発展がなかなか気になる。今回のデータセットを解くのに必要な知識は具体的にどのような種類の知識なんだろう、ぱっと見ではわからない。
    • 選択肢を作るのに使った book corpus や caption のコーパスで pretrain したベースラインがあってもいいのかなと思った。実はそうだったらすみません(ちゃんと読んでない)。
  • DNC (Diverse Natural Language Inference Collection) https://arxiv.org/abs/1804.08207 (EMNLP2018)
    • 自然言語処理のいろんなタスクを natural language inference のタスクに recast して統合したデータセットWhite et al. (2017) Inference is Everything の拡大版という感じ。
    • 他のデータセットで pre-training しない場合の hypothesis-only (前述した Y のみで推論する解き方)のベースラインと普通(X と Y の両方使う解き方)のベースラインでほとんど精度に差がないのが気になる(NLI のデータセットにする意義がよくわからない)。対して pre-training すると元々 hypothesis-only と普通のベースラインに差がないデータセットでも精度に差が出るということは text (上述の X )の方にバイアスが入っているということになる?
    • よくわからないけど、単一の NLI のデータセットとして見るには疑問が多い。たとえば半分近くが NER の問いなのに既に 92.5% の精度が出ているわけだし(Y のみで 91.5% だし)。どう使えばよいのかわからない。タスク同士の transferability みたいなものを見たいなら DNC というひとつのパッケージとしてまとめて pre-training する意味もないと思う。 GLUE みたいに使いたいのかと思ったけど "probe" するためにと書いてあるので違うニュアンスを与えたいみたい。そうだとしても個別のタスクそれ自体の質の保証が弱い気がする。うまく読めない。
  • OpenBookQA https://arxiv.org/abs/1809.02789 (EMNLP2018)
    • 理科の知識をもとにクラウドソーシングで選択式の問題を作ったデータセット。問いと選択肢に加えて作問に使われた知識(scientific fact)が与えられる(あるいはその知識を回答者から隠してしまえば、それ自体を外部知識として要求するデータセットと見ることができる)。論文は全体的に丁寧に書かれていて好印象(印象はあまり重要ではないですね)。
    • データセット構築の段階で「元となる理科知識に加えて何を知っていなければならないか」という常識知識をクラウドワーカーに記述させたが、あまり質の良いものではなかったと報告されている。やはり「問いを解くのに必要な常識を記述してもらうのは難しい」という感じ。
    • 分析として100問取り出したらそのうち21問は「作問に使われた知識を直接要求するような問い」ではなかったと報告されている。作問の打率が8割と考えれば聞こえはいいけど、この知識を使って訓練したベースラインの精度(4.4節)が6割前後(直前に書いた「常識知識」を使うと8割前後)あるので、「提示された知識をどう使うか」という能力を評価するデータセットとしては信頼度が少し損なわれている気がする(まあ人間の精度と3割違えば十分かもしれないけど)。
    • となると作問知識を隠して「外部知識を要求する」データセットとしての利用を考えることになる(結局 AI2 の既存のデータセットと何が違うのかという感じにはなってしまう気がするけど。知識が align されている点は大きな貢献だと思う)。著者は実際に、既存の読解のデータセットのほとんどが self-contained であるのに対して、我々のデータセットは not self-contained だと主張している。そう見るとおそらく良いデータセットになっている気がして(4.3節のベースライン)、このあたりの「自分たちのやっていることの位置づけ」に関わる議論が丁寧な論文なので好印象という感じです。
    • ただ「外部知識を要求する」としても「知識が得られてしまえばかなりの割合の問いが解ける」ようなデータセットであるから、「その知識をどうやって得るか」を中心的に要求する形に落ち着いていることになる。これはどちらかというと information retrieval のタスクなのではと思うのだけど、じゃあ(著者がそれを目指しているわけではないものの)読解タスクは information retrieval とどう違うのか、何をもって読解タスクの identity とするのかは議論の発展先としておそらく重要。自分としては narrative comprehension のような形で situation model を評価するものとしてのタスクが大事だと思うのだけど、ちょっと話が長くなりそうなのでここで切ります。
  • RecipeQA https://arxiv.org/abs/1809.00812 (EMNLP2018)
    • 読解と画像を混ぜて multi modal に問うという趣旨のデータセット。立ち位置は TextbookQAFigureQA あたりに近い。手順を説明するテキストと、その各ステップごとに対応する画像があるので、そこからタスクを作っている。問いは自動で作っている選択式(4択)みたいなのでちゃんと解けるものになっているかどうかがちょっと心配。特に cloze task の方、ベースラインが 27-29% なので。ちゃんと正当の選択肢に必然性があるのかとかが気になる。人間の精度を付けてほしかった(自動生成した問いでこれをやらないのは致命的だと思う。自動生成した問いの回答可能性を高めるのは結構大変っぽく、大変そうだなぁと過去に思ったのはたとえば Who did What とか QAngaroo とか)。
    • レシピの勉強になる論文だぁおいしそうだぁ(bacon sushi というよくわからないレシピが例示されている)と読み流そうとしていたら1段落目で自分の論文が引用されていたので真面目に読みました。
  • CLOTH https://arxiv.org/abs/1711.03225 (EMNLP2018)
    • 英語の試験問題の穴埋め(英語では fill-in-blank ないし cloze と呼ばれていると思います)のデータセット。選択式にして回答可能性を保証している。問いのタイプとして short-term か long-term の reasoning か grammar か matching かで4種類に分けている(matching を long-term に含めた主張をしているのはよくわからない)。長距離の推論と著者が呼んでいるのは multi-sentence reasoning のことで、それは全体の 18% ということらしい。そこまで多くない。ベースラインで最も良かったのは言語モデルの手法。
    • ICLR2018 の review で言われている問題はそのまま残ってると思う(けど、7-4-4 で 4 を最後に付けてる人の査読はあまりに雑でちょっとひどい。一方の 4 の人はまあそうだなぁという感じ)。ただし、 言語モデルを使ったベースラインが妥当でないという査読の主張については懐疑的。現に後続の研究で言語モデルで pre-training して finetunung したら色んなタスクで良くなったというのがあるし(Improving Language Understanding with Unsupervised Learning)、言語モデルだけで winograd schema challenge で SOTA を出した研究もある([1806.02847] A Simple Method for Commonsense Reasoning)。
    • RACE と元のコーパスが一緒っぽい。 CMU の同じチームからの論文。
  • DuoRC http://aclweb.org/anthology/P18-1156 (ACL2018)
    • NarrativeQA にアイディアが近い(初出はほとんど同時期だったはず)。ある映画を説明する二種類のプロット同士で問いを跨がせることで良い感じになってくれることを期待している。 Commonsense や multiple sentence reasnoing が多く問えるとも書いているけれどそれを裏付ける分析がない。どうでもいいですが abstract が長い。
  • SQuAD 2.0 http://aclweb.org/anthology/P18-2124 (ACL2018)
    • SQuAD に "no answer" な問いを追加したそうです。
  • CliCR (A Dataset of Clinical Case Reports) http://www.aclweb.org/anthology/N18-1140 NAACL2018
    • 医療文書の読解。穴埋め。必要な能力のアノテーションまで丁寧にやっているので個人的な好感度が高い。
  • FEVER (Fact Extraction and Verification) http://aclweb.org/anthology/N18-1074 NAACL2018
    • Fact verification というのは形式としては textual entailment の premise (前件)を長くしたもの。そのためのデータセットを大規模に作りましたという話。 EMNLP2018 でワークショップをやっていたらしい。
  • MultiRC (Multiple Sentence Reading Comprehension) https://cogcomp.org/multirc/ (NAACL2018)
    • 複数文に跨った読解。「あるひとつの文だけでその問いが解けるかどうか」の検証をデータセット構築の過程に含めている。 6K questions くらいなので少し小さい。文を跨ぐのは coreference と paraphrase で6割弱という感じ。
  • ProPara http://aclweb.org/anthology/N18-1144 (NAACL2018)
  • ARC http://data.allenai.org/arc/
    • AI2 のお家芸。小学生の理科の問題を読解形式にしたもの。ただし外部知識を要求する割合が高くて、「与えられた文章を読まないと解けない」ような問いは少ないと感じる(という分析を自分の EMNLP の論文でしました)。データセットは Challenge の方で 2-3K くらいの規模なので小さめ。
(追記)見落としていたもの:

最近のデータセットのまとめ

 長くなってしまいましたが、発展の方向性でまとめると以下のような感じでしょうか。

  • 問いの文脈的な依存(CoQA, QuAC)
  • 文間の照応や推論(HotpotQA, SWAG, MultiRC)
  • 外部知識(OpenbookQA, ARC)
  • ドメイン特化や画像入り(CliCR, RecipeQA)
  • 手続き的な文章(ProPara, RecipeQA)
  • 解答可能性の配慮(SQuAD2.0, QuAC)

 一方で、多くのデータセットに共通する課題もあります。「ある言語現象や知識に特化し、そのような能力を問うようなデータセットを目指した」と書いているものの、それについての分析が深くないように見える点です。データセットを提案する論文が査読に通る最低限の要件は「ベースラインのシステムの精度と人間の精度に乖離があり、取り組む価値がある」と主張できることなので、そこはたいていクリアされています。しかし、提案するデータセットに新規な特徴が含まれているとしても、それがそのデータセットの難易度に本当に寄与していると説明できなければ、「これを解けるシステムはその特徴を捉えることができる」という主張をすることができません。つまり「このデータセットが解けるようなシステムが作れたとき何が明らかになるのか・何が嬉しいのか」がわからないままになってしまう、ということです。

 という感じでデータセットの意義まで細かい分析を付けてくれるとありがたいなぁと思うのですが、なかなか狙い通りにならないでしょうし難しいですね。文句を言うことはできますが、実際に取り組むことで明らかになる課題もありますし、やらないより全然マシです。そもそも有名な研究室から出たデータセットなら、挑戦する人がたくさん期待できるし、他の人が勝手に分析してくれるかもしれないですしね(言い方が悪くてすみません)。ただしコストの問題があり、大きな研究室から出ているデータセットを見るとクラウドソーシングに数百万円のオーダーでお金がかかっていることがわかります。場末の学生が同じように頑張ろうとしてもちょっと難しいですね(しかし批評家は止めたいので困っている)。

データセットを作る?

 自分は次に何をするのが良さそうでしょうか。わからない。取り組み方として大きく分けると、「データセットを作る」「システムを作る」の2通りあるっぽい、ということを以前述べました(ここで「データセット」は「タスクのインスタンス」の意味で書いています)。自分としてはそろそろデータセットを作ることをやりたいなとも思っていますが、これまで見たようにあまり簡単ではない雰囲気が漂っています。

 いろいろとデータセットを見てきた中で、(難しい問いを作るのはさておき)読解のタスクで易しい問いを作らないためには次の要件が満たされているべきだと観察されます。

  1. それらしい回答の候補を複数持っている(multiple candidate answers)
  2. 回答の候補自体にバイアスが存在しない(avoiding annotation artifacts)
  3. 「問い+正答」に似た内容が文脈の文章内に直接出現しない(context-question simlarity)

 例えば上で見た SWAG というデータセットは1,2点目をわりかし綺麗にクリアしています。ただ確認したようにこれは「2連続の event の前者が与えられて後者を当てる」という event prediction 的なタスクなので、問いも文脈となる文章も持ちません。しかし文章から問いを書いてもらうと3点目が配慮されづらく、「深く考えなくても解ける」ようなものばかりになってしまう例がほとんどです。

 回答の形式についても考慮が必要です。現状で主に利用されているのは、文脈の文章からの抜き出し・多岐選択式(およそ4択)・自由記述、の三者です。まず抜き出しは上記の1点目をクリアするのが大変です。個人的には選択式のほうが多様な回答が作れるのではないかと思っていますが、同様に偽の「それらしい」回答候補を作るのが大変です。自由記述は評価が難しいので、 NG とは言わないまでも今のところは見送るべきでしょう(生成や翻訳の評価と同質の問題があります)。

 ここまで見てきて、実のところは「それらしい回答の候補を複数持たせる」ことを目指すのがもっとも重要かつ大変なのではないか、という気がしてきました(上記の1点目のクオリティを上げると2,3点目も同時に解決されそう)。個人的な経験では、国語の文章題だと「選択肢のどちらか正しいか迷う」のが難しい問いだったかなぁという思い出がないこともないです(センター試験の選択式の問題が苦手だった)。つまり「与えられた文章の内容に照らしてどちらの回答の候補がもっともらしいか」を考えさせるのがより洗練された(?)言語理解を問うことに繋がるのではないでしょうか(わからないけど)。 可能世界の多さが〜とかこの世界との近さが〜とかいう話をしてもよいのかもしれなかったのですが、いまいちピンとくる話をまとめられなかったので止めます。

 次いでもうひとつ重要になるのは、「それが解けるようになると何ができるようになったと言えるのか」を説明できるようなデータセットであるようにすべき、という点です。この手の説明可能性や解釈可能性みたいなものは機械学習が入るとより強めの問題になりますが(依然として「訓練データって何を訓練するの??」という気持ちは絶えません)、それはともかく最近のデータセットはここが弱すぎます。問いを解くという行為がどのように分解されていくかについてもうちょっと知見を深められたらいいのになあと思っています。

 という感じでもし自分がデータセットを作るなら上記の2点が大事な気がするなぁということを思いました。ではシステムを作るならどういう方向性になるのかもちょっと触れてみます。

システムを作る?

 読解のタスクでは、Bi-directional Attention Flow が出てから本質的にはその variant しか登場していない、という話を結構聞きますが、およそそれ以外は self-attention (self-attention って何?)があったり convolution があったり別のデータセットや別のタスクや augumentation で pre-training したり transfer learning したりの組み合わせだったりする場合がほとんどな気がします。なんかこう、いろんな既存手法を持ってきて組み合わせてパラメータを合わせるのが上手い・手が速い人が勝つという感じがしています(自分はそういうの下手だし手が遅いのでつらいです。修行したい)。それだけだとあまり面白くないので、解いたらこういう知見が得られるよ〜というアプローチで解きたい気持ちがあり、上記のインターンではそういうのを上手く思いつけたかなぁと一瞬期待したのですが、実際はなかなか話が立ちませんでした。そもそも SOTA の数値を出すのすら難しい場合が増えてきており(実装が公開されていないとか、GPU がたくさん必要とか)、「1GPUでそこそこ速く訓練できる」「実装が公開されている」の2点が満たされているような話はもうあまり見ません(メジャーなデータセットで SOTA を出しているのはだいたい強い企業の研究所が多かったりします)。かくいう私もインターンでは実験のために GPU をたくさん使わせてもらって、それが終わったいま自分の大学の研究室では同等の環境を用意できないので、(少なくとも自分の力だけでは)実験を続けられなくなってしまいました。頭が悪い。

 というわけで、最近の読解のタスクでは(含意関係認識のタスクでも)古き良き時代の symbolic な semantic representation の上で knowledge reasoining や logical reasoning をして解きました、みたいな話はほとんど聞かないです(ゼロではないです。たとえば AAAI2018 の Question Answering as Global Reasoning over Semantic Abstractions あたりの人たちは結構好きです。ルールが多すぎてもうちょっと何とかならないかなとは思うのですが)。自分はこっちがいいと言いたいわけではないのですが、 もうちょっと地に足の着いた感じがいいなとは思っています。じゃあどうするねん、そもそも attention ってなんやねん……。

わからない

 わかりません。データセットを作るのもシステムを作るのも大変そうです。土俵を変えたほうが良い気がする。しかし土俵を作ることにおいては知名度的に強い人たちが有利なんですよね。参った。何も解決していません。この調子だとまた分析をする論文を書いてしまいそうです。

 うーん本当は situation model をやりたかったんです。心理学における言語理解の計算論的なモデルのひとつです。著名な論文は Zwaan (1998) Situation Models in Language Comprehension and Memorypubmed のリンクを貼りましたがググれば論文は見つかります)で、最近のまとめは Zwaan (2016) Situation models, mental simulations, and abstract concepts in discourse comprehension などです。不勉強なのでここでは詳しく説明できませんが、自分としてはそれなりに面白いと思っています。しかしこれが現状の自然言語処理で必要になる話かといえばおそらくそうではないでしょう(必要になることがある、ということすら断言できません)。

 ここからは集中力が切れた文章末尾の放言です。前回の記事の最後で、「自然言語処理が何を積み上げてきたのかよくわからない」ということを書きました。かなり乱暴な言い方になってしまい反省しているのですが、気持ち的には今でもあまり変わっていません。自分としては何らかの仮説や理論の積み上げがあってほしいのですが、何もわからないままです。これには自然言語処理分野に特有の理由がいくつかあると考えています(あくまで素人の意見であることをご承知おきください。この段落を読んだら忘れてください)。まず、どんなタスクでもコーパスを評価の基軸としている以上、ぶれ・ノイズが大きくて汎用的な知見として確立するところまでいかない、というのがあると思います(伝統的なタスクほどデータセットの数が少ないと思います)。次いで、言語という様々な性質・特徴を含んだものが対象であるにもかかわらず、評価指標を精度などの一元的なものに落としているために「この手法はこのタスクに有用である」以上の知見が出てこない、というのがあります。タスクが複雑であればあるほど得られる知見がぼやける、ということになります。例えば構文解析ならまだわかりやすいですが、翻訳・対話・QA などの多段階・多種類の処理が必要になりそうなタスクで一元的な指標に落とすのは大変な気がします。いくつかあると書いたけどこの2点かなぁ。ただ、「何を積み上げているのかよくわからない」とは言っても、技術もタスク(コーパス)も積み上がっていて、それは非常に重要なことだという気がしています。言語というなんかよくわからんものに取り組む以上、持っている道具の総体として解釈していくしかないのです、たぶん……(他に手段がない)。

 あと1年と少しで博論が書き上がっていなければならないのですが、どうなるんだろう……。そろそろ就活もせねばなりません。人生。

自然言語処理の研究に悩む

背景

  • 自然言語処理分野の博士課程の学生です。何もわからないのが得意
  • 研究テーマないし進め方に悩んでいます。その考えごとを書きます
  • 何もわからん

ここに何を書きたいか

 研究が進められていない気がする。論文が書けない気がする。何も考えていないわけではないと思うが、自分の研究をどのように進めればよいのか混乱している。自分の目的・条件・研究分野の性質等を整理して、手がかりを得たい。という感じです。本当は(訓練のためにも)英語で書くべきですが、やはり日本語で考えたほうが脳内の通りがよいので(たとえばこういう表現自体を英語にできない)このまま日本語で書きます。

個人的な目的・目標

  • 自然言語処理や計算言語学(以下 NLP/CL)と呼ばれるものの定義は様々ですが、個人的には「人間がどのように言語を獲得・理解・産出(以下まとめて処理とします)するのかを計算可能な仕方でモデル化し、言語資源・知識資源・視覚や音声など利用可能な情報の分析・学習を通して検証する」という雰囲気で位置づけています。よくある「人工知能っぽい意味で言語が処理できるエージェントを作るのであれば、人間の模倣は必要条件ではない」という指摘には同意しますが、人間が扱う言語についてあれこれさせるためには何らかの形で人間に漸近するような機能が備わっているべきだとは考えています。このあたりは個人の嗜好だと思うので、「どちらかと言えば機械より人間に興味がある」くらいに考えていただければと。
  • 上記の背景のもとで、とくに言語理解に興味があります。
  • やったことを博士論文くらいの単位の成果にまとめなければなりません。その後の生存戦略を考えると、できれば目立った業績が伴うことが望ましいです(しかし意識しすぎると頭が回らなくなるのであまり考えないようにする)。

研究のスタイル

 上に書いた NLP/CL の個人的定義から、どのような研究の単位があり得るかを考えてみます。研究全体の流れを整理しましょう。研究はそこで提示された内容がどれくらい妥当か吟味される必要があります(本当か?)。したがって上記定義にしたがえば、「何らかの言語を処理するモデルを作り、そのモデルを何らかのタスクに基づいて評価して信用してもらう」のがおそらく「みんなでやっていること」になります。

 これも個人的な区別ですが、「モデル」と「タスク」の2つが NLP/CL の研究では中心的な構成要素になると考えています。モデルを作ったりタスクを作ったり、モデルの改善をしたりタスクの改善をしたり、が研究の単位になります。ということで大きく2つにスタイルを分けると次のようになりそうです。

  1. 言語を処理するモデルを作り、何らかのタスクで評価する。
  2. モデルを評価するためのタスクを定義する。

 順にどのような細分化がなされるかを書いていきます。まず 1. について。上では、獲得・理解・産出を処理と呼んでいました。もちろんこの区別は厳密ではありません。人間は言語をどのように処理するでしょうか。全体としての(認知神経科学的な)流れはよくわかりませんが、「少なくとも振る舞いとしてこういうのはできるだろう」というのがあります。これには複数のレイヤーが考えられます。もっとも基礎的なものには形態素解析構文解析、意味役割の認識などが含まれそうです。もっとも応用的なものには翻訳や対話が含まれるでしょう。以上のようにNLP/CL の研究では言語処理の部分的な振る舞いをモデル化します。たぶん。モデル化のためには「内部的にどうなっていてそのように振る舞っているか」に関する何らかの仮説を立てます。「こうすれば上手く振る舞ってくれるだろう」という仮説です。実際に上手くいったのであれば、評価に用いたデータセットの範囲内でその仮説が(その上手くいった程度に応じて)妥当なものだと見なされます。

 2. についてです。タスクの意義は、モデルの振る舞いを評価して何らかの仮説の妥当性を裏付けることにあります。しかし重要なのは、仮説の妥当性がその「評価に用いたタスク」の範囲内でしか裏付けられないという点です。あるタスクで良い振る舞いをしたからといって、別の同種のタスクでも良い振る舞いができないのであればその有用性は限定的になってしまいます。したがって、あるタスクで用いるデータやその評価方法は同種の課題に対してなるべく汎用的であるほうがよいですし、モデルの評価はなるべく多種のデータに対して行われたほうがよいでしょう(ここには「理論は広く有用であるべき」という規範が入っていますが、学術的価値や技術的価値にとっておそらく必要なことだと思います)。また、ある振る舞い(だいたいは言語的な出力)をどのように観察すれば妥当な評価が行えるのかは簡単でない場合があります。たとえば機械翻訳の結果を評価するのは難しいですね。対話システムも特に雑談の場合はしんどいという話を聞きます。タスクのデザインはモデルの設計と同等かそれ以上に難しいと個人的には思います。

 以上の両者をバランスよくやっていくのが研究分野全体として必要だと思います(参考: ベンチマークの功罪 – CTRL+x CTRL+s )。

言語理解の研究について

 自分の興味は言語理解とかそのあたりにあります。言語理解と端的に言っても定義は非常に難しいです。まずその定義には正解がなく、人によって「〜だったら言語が理解できてると言える」の「〜」に入るものが違ったりします。話を進めるために、何か暫定的なものを決めましょう。一説には「ある言語入力に対してその言語が使われている共同体の規範や慣習に沿った振る舞いができること」という定義があり、これを採用してみます(ここで規範や慣習と書いたのは人間の言語に話を限定しているからですが、他の動物がやりとりする記号や表象も含めて定義したいね、という話は案の定ですがミリカン『意味と目的の世界』などを読んでください)。さて、そこでは「言語を理解しているときの適切な振る舞い」というのをどうやって(なるべく一般的な社会規範として)決めていくかが問題となります。

 人間について考えてみます。まず言語を行使する能力がそもそもあるかどうか、という点で見ると失語症のテストが考えられます("aphasia test" あたりで検索するとそれっぽいのが出てきます)。また「言語を理解する能力」の段階的な評価として、教育的な観点からの調査が考えられます。たとえば OECD の教育部門は PISA (The Programme for International Student Assessment) と呼ばれる調査を行っており、読解力・数学的知識・科学的知識という分類を作っています。ここで言う読解力というのは単なる文章を読む能力から、文字を含んだ図表の理解まで対象にしています(詳しい解説はたとえば 平成23年度 追加分析報告書:文部科学省東北大学の成果報告書1の pp.26-32 など)。

 機械についてはどうでしょう。まず思い出されるのはチューリングテストです。しかし「対話」だと実はそれっぽい鸚鵡返しや相づち、話題転換で誤魔化せてしまうという指摘があります(ELIZA はその一例かもしれません)。このあたりは Levesque さんの On Our Best Behaviour [paper] [slide] という2013年の IJCAI の発表(と翌年の論文)で議論されており、振る舞いとして誤魔化しのきかない形式を考えるべきだと指摘しています。次いで彼は「選択式のクイズでいいのでは?」(意訳)とみたいなことを言っており、最終的に提案されているのが Winograd Schema Challenge でした。これは background knowledge を問うタスクですが、問題数も少ないのであまり流行ってはいない気がします(でも難しいです)。

 さて最近の界隈では、質問応答のひとつの延長として読解タスク(machine reading comprehension)というのが流行っている気がします。端的に言えば文章題です。これを「言語理解の能力を振る舞いから評価する」ためのひとつの枠組みだと考えて、そのためのモデルやタスクの構築について考えてみます。先に引いた人間の読解力の調査として使われている手段に近しいのと、 Levesque さんの言う「対話ではなく選択式のクイズでも十分に振る舞いが評価できる」という話に乗っかってみる感じです。

読解の研究をどうする?

 先程と同じようにモデル・タスクに分けて考えてみます。まず読解をするモデルについて。人間の読解のモデルについての研究は、たとえば心理学では Kintsch さんによる Construction and Integration Model があります(1980年代後半くらい)。これを基礎にしていくつかモデルが出ていますが、あくまで理論的な話で、あまり「実際に作る」という話には至っておらず、(そりゃそうですが)こうした理論的な仮説を心理学的な実験で検証するというのが彼らのやり方です。そのモデルにおける個々のコンポーネントやその関わりがどうなっているかを神経科学的に見ようとすると一気に難しくなり、知識(というか記憶)がどこから湧いてくるか、読んだものが逐次的にどのように処理されるか、など諸々の振る舞いに対する仮説を解剖学的な部位や時間的位置を特定したりしながら検証していきます。これを計算論的に仮説を立てて再現して処理できるかどうかやってみればよいのでは? という感じになりますが、ハードルがあまりにも多くて心の底からよくわかりません。一方で読解のタスクに対して提案されている NLP/CL の側のモデルは、たとえば [1611.01603] Bidirectional Attention Flow for Machine Comprehension[1711.04289] Natural Language Inference with External Knowledge のような(図を見てみてください)それっぽい気もするようなしないような構造をしています。人間についてのモデルとの大きな差異のひとつは読解における知識の保持・利用の仕方だと思いますが、知識がちゃんと必要になるようなタスクが少ないのでしっかりとした正答率が出せている印象です。そうです、一部のデータセットではけっこう人間に肉薄した性能が出ちゃったりしています。うーんでもじゃあこれで人間っぽい読解力が持てるようになったのか、と聞かれると全く肯定できません。どうしてでしょう。

 どうして納得できないのか。流行りのタスクが悪い気がします。上で述べた表現を使えば、「同種の課題に対する汎用性が全然なさそう」だと感じます。あるいは「問題が簡単すぎる」気もします。しかしそれをきっちり浮かび上がらせて定量的に示すのはなかなか難しいです(自分のこれまでの研究はここを何とかしようとする試みでした)。Levesque さんは同じ議論の中で、選択式のクイズが適切に振る舞いを評価するに足るための要件を挙げています。「Google-proof (検索が無効)であること」「典型的なパターンマッチでは解けないこと」「語順や文法などにバイアスが含まれていないこと」の3つです。うーん本当にそうだなあという感じです。いまデータセットとして流行っている The Stanford Question Answering Dataset (SQuAD) について Goldberg さんが「ちょっと凝ったパターンマッチじゃん」と言っていたのが記憶に新しいです(スライド)。つまり流行りのタスクは、単なるパターンマッチ+バイアスの発見で解けるような問題じゃないかな、という気がするわけです(そしてモデルはまさにそうした情報を掴むための構造になっています)。

タスクを作る?

 モデルの方は本当によくわからない・理想的なものを考えても評価する手段がないので、タスクをより改善していったほうがよいかもしれません。Levesque さんの挙げた要件を守りつつ、難易度が高そうな問いがたくさん作れるのがよさそうです。でもそれってどうするの?? というのが現在時点での悩みです(やっとここまで説明できました……長くてすみません)。質のよいクイズを作るというのはなかなかに骨の折れる作業です。人間が解く試験問題を作るのが大変なのと同じだと思います。しかもそれがなるべくたくさん欲しいわけです(最近は大規模なデータセットでないと注目してもらえないのがよくない風潮だと思います。もちろん少なければ少ないほどバイアスが発見しやすかったりするのかもしれませんが(本当か?))。どうすればいいんだろう、何を調べる・考えるべきか……。というところで詰まっています。

 もちろん既存のタスクが何もかもダメという感じでもなく、2017年のEMNLP で発表された RACE のような人間の試験問題そのままのデータセットもあったりします。これをしっかり解けるようなモデルを考えるのも面白そうです。また、 SNLIMulti NLI のような比較的大きな含意関係認識のデータセットも出てきました。ただこれらの含意関係認識のデータセットはベースラインが高く、すでに state of the art も9割近い精度が出てるので、今から取り組むべきかというと微妙な気もします。精度で勝っても有意な差にならないでしょうし、そもそも人間の精度が9割くらいだったりするとあとの1割は一体何なんだという感じになります(エラーなのか真に難しいのかがわからない)。じゃあやっぱりタスク作りをすべきでしょうか。しかしどうやって問いを立てるのでしょう。

 あとは「読解や含意関係認識のデータセットで学習する」と言ったときにモデルが一体何を学習しているのかというのが気になります。他のタスクに応用可能な知識を得ているのでしょうか。それとも、似たような問題形式でのみ使えるマッチングやバイアスの発見の仕方を学習しているのでしょうか。ここまで書くと批判したいだけに見えてしまうのですが、そもそも我々が知識と呼ぶものとそうしたヒューリスティックっぽいものに明確な境界はあるのでしょうか。

結局何ができそうか

 何もわからなくなってきました。厳しい。ここでちょっと「研究として可能そうなこと」を列挙してみます。このあたりは話がまとまってきたら後で消すかも。

  • タスク側
    • 「マッチングやバイアスの発見」を定量的に扱うための何かを考える(そもそもこれが外部知識なしのベースラインなのでは?)
    • 既存のデータセットの有用な変形。その過程で前項についての示唆を得る
    • 新しいデータセットを考える。「情報の関係(知識を含む)」を捉えることができないと解けない問題が望ましい(抽象的に書きすぎですが、要は「ちゃんと難しい」問題が作りたい気がします)
    • 問いの分析。自分がこれまで提案した能力は一体何だったのか。どのような問いにどのような能力が出てくるか。あるいはある能力を専門的に問うためにはどのような問いが必要か
    • 前項に関係して、質問ベースの翻訳評価のためのイベント粒度など
    • 読解のための能力っぽいものだけでなく、言語知識への拡張
  • モデル側(あまり考えていないので気になることだけ)

うーん、いろんなことを同時に考えすぎてどれも論文が書ける程度まで成熟していないのかもしれません(いずれにせよ何もわかっていないのですが)。論文の単位としては(自分の経験では)「何らかの仮説を立てる(モデルでなくてもよい)・何らかの定量的な評価や分析を行う・仮説の信頼度について結論を与える」という感じなわけで、その仮説の粒度は「これが言語理解のモデルだぜ!」という大きさでなくとも「いや読解の能力と文章の読みやすさってあまり関係なさそうじゃね」くらいの細かさで十分な話題になります。それが「タスクを立ててモデルを作って評価する」と一連の流れのどこか部分的にでも貢献できればよいのです。しかし……しかし、「仮説」は何かの積み重ねで成り立っているわけですが、 NLP/CL はこれまで何を積み上げてきたのでしょう。論文を読んでも「何もわからん!!!」となることが多いのはまさにこの「積み重ねのわかりづらさ」にある気がします(私が何もわかっていない・わかろうとしていない・この記事を書くにあたって認識を誇張している、などの可能性があります)。仮説検証のプロセスが暗黙のうちに為されていたり、検証のスキーム自体を数値で簡素化しているために論文の貢献が何なのか見えづらいのです(規範がばりばりに入っており、あくまで個人的な嗜好であることに留意いただければと思います)(あと論文一本が短すぎる)。

 あとはそうした思いつきを速い周期で回していくことが大事です。複数の試案を同時に考えていると各々が飽和するまでの時間が長くなってしまうので、やっぱりどれかに絞ってがっと進めたほうがよいかもしれません。自分は手を動かすのが遅いので(普段から書いているわけではないのでコードを書くのは特に時間がかかりますし、full paper の論文を書くのもまるまる1ヶ月は欲しい)、ひとつの周期をより速く回せるように意識していく必要がありそうです。

 焦っても仕方ないですし、じっくりやりましょう(って言ってると無限に時間が溶けるので、進行管理をきっちりせねば……)。たまにこんな話で雑談をしていただける方が現れると喜ぶかもしれないです。終わり。

beamer, rowcolor, columncolor, line breaks in cell, and overlay

f:id:liephia:20171102143234p:plain

\documentclass[12pt,xcolor={dvipsnames,table}]{beamer}
\usepackage{booktabs}

\makeatletter
% columncolor > rowcolor https://tex.stackexchange.com/questions/80135
\def\tmpp#1\@addtopreamble#2#3!{%
    \tmp#2!{#1}{#3}}
\def\tmp#1\CT@column@color\CT@row@color#2!#3#4{%
\def\@classz{#3\@addtopreamble{#1\CT@row@color\CT@column@color#2}#4}}
\expandafter\tmpp\@classz!
% get overlaynumber
\newcommand*{\overlaynumber}{\number\beamer@slideinframe}
\makeatother

\begin{document}

% tabular in cell for line break
\newcommand{\cellstack}[2][0]{
  \ifnum\overlaynumber=#1\newcolumntype{x}{>{\columncolor{red!20}}c}
  \else\newcolumntype{x}{c}\fi
  \def\arraystretch{0.9}\begin{tabular}[c]{@{}x@{}} #2 \end{tabular}
}
% change each column color
\newcommand{\onct}[2]{\newcolumntype{#1}{c}\only<#2>{\newcolumntype{#1}{>{\columncolor{red!20}}c}}}

\begin{frame}{Table}
  \centering
  \def\arraystretch{2.0}
  \onct{A}{2}\onct{B}{3}\onct{C}{4}\onct{D}{5}
  \rowcolors{2}{}{gray!20}
  \begin{tabular}{ABCD}
    \toprule
    Column1 & \cellstack{Column2 \\ Cat1} & \cellstack{Column3 \\ Cat2} & Column4 \\ \midrule
    \cellstack[2]{Row1 \\ Col1} & Row1 & Row1 & Row1 \\
    Row2 & \cellstack[3]{Row2 \\ Col2} & Row2 & \cellstack{Row2 \\ Col4} \\
    Row3 & Row3 & \cellstack[4]{Row3 \\ Col3} & \cellstack[5]{Row3 \\ Col4 \\ Row3inRow3} \\ \bottomrule
  \end{tabular}
\end{frame}

\end{document}

Please let me know if you know a better way...

beamer, presenter notes, pgfpages, splitshow

やること
  • beamer で作ったスライドで発表する(環境は OSX
  • 発表者ノート的なものも使いたい
手順
  • tex に仕込むコード
\usepackage{pgfpages}
\setbeamertemplate{note page}[plain] % or [default], [compress]
\setbeameroption{show notes on second screen=right} % or bottom, ...
\newcommand{\pdfnote}[1]{\note{#1}} % as you like
  • で、 \pdfnote{あれこれ} を frame と frame の間に書く(どこでもいいっぽいけど)

    • itemize が使えたり、フォントも自由にできる(便利)
  • Splitshow https://github.com/mpflanzer/splitshow で pdf を開く

    • presentation mode = split
    • main display とか helper display とか指定するとウィンドウを開いてくれる
    • 矢印キーが同期されるのでふつーに発表可能
  • 同時に note page が無い slide も出力しておきたいとき(配布用とか)

\usepackage{pgfpages}
\setbeamertemplate{note page}[plain] % or [default], [compress]
\ifdefined\ispresentation
\setbeameroption{show notes on second screen=right} % or bottom, ...
\fi
\newcommand{\pdfnote}[1]{\note{#1}} % as you like

などとしておいて(引数の入れ方はもちろん逆でもいいです(ここでは slide.pdf が note 付きになるようにしている))、

with note pages
$ lualatex "\def\ispresentation{1} \input{slide.tex}"

without note pages
$ lualatex -output-directory=org -jobname="slide_original" slide.tex

みたいな。 Makefile に適当に書いておく。最初 platex+dvipdfmx でやっていたけど table などが表示されなくて詰まったので lualatex に切り替えた。

反省
  • beamer でスライド作るのを卒業したほうがいいのではないか

Springerexemplar の grep

Springer Exemplar - Scientific Terms in Context と言えば Springer が有するコーパスから指定したフレーズの一致件数・一致例を出してくれるサイトですが、「この表現とあの表現の一致件数を比較したいな〜」というときに一発コマンドを打てると楽だなあと思っていろいろ教えてもらって書きました。なんでこんなことするのかって springerexemplar は読み込みが遅くてロードを待っている間に何を検索しようとしていたか忘れてしまうからです。

springerexemplar() {
    echo "$*"
    wget -q -O - 'http://springerexemplar.com/search.aspx?q="'"$*"'"&similar=false' | grep -o "\d* matching articles"
}
spx() {
    for i in $@; do
        springerexemplar $i
    done
}

自分は .zshrc に直に書いています。使い方は、

$ spx 'this '{is,was}' because'
this is because
122392 matching articles
this was because
128924 matching articles
$ spx 'this is because' 'this was because'
this is because
122392 matching articles
this was because
128924 matching articles

みたいな感じでどうでしょうか(自分でも使うかどうか怪しいけど)。

UBLP (EMNLP2016WS) の対話セッションのメモ

Uphill Battles in Language Processing Scaling Early Achievements to Robust Methods, Workshop held in conjunction with EMNLP 2016

  • http://www.coli.uni-saarland.de/~mroth/UphillBattles/
  • EMNLP 2016 のワークショップ
    • 「現時点までの成果をどうやって robust な技術に発展させるか」という感じの、今までを振り返ってこれからを考える趣旨の会
  • 本稿は Dialogue and Speech のセッションのメモ書き
    • 4人の研究者がそれぞれ10-15分で「これからどうするか」という話をしている
    • 他に「言語理解」「言語生成」「Grounded Language (どう訳す……?)」のセッションがあった

0. 全体のまとめ

各講演者の要点

  • Devault: 現状の音声対話システムの問題のひとつは流暢さであり、その実現のために「turn-taking における素早い応答」と「割り込み・重複を認識して認識ができること」の二点が重要だと指摘している
  • Liberman: diarization (who spoke when) すら現状の技術では満足でなく、 what について理解する前提としてまず diarization が必要。そのほか、 turn-taking物理的環境・社会的文脈への対応
  • Litman: 協調という観点から1980年代の Indirect speech actsHelpful responses の取り組みを思い出すべきなのでは
  • Stent: 概説メイン。大きな課題はふたつ: 単なる「情報を探す」対話から協調的・利益的な対話に発展させること、 AI としての対話に立ち返って必要な要素(たとえば情報の共有、照応と物理世界、文化や社会ドメイン、複雑なやりとり、自律性?)を考えること

メモ作成者のメモ

  • ページ下部へ移動

1. David Devault, University of Southern California

音声対話システムの Uphill Battles

  • Automatic speech recognition
    • 自動的な音声認識
    • (既にいいところまで行った?)
  • Broad coverage semantics
    • 幅広い語彙・知識をカバーできること
  • Multi-domain / multi-application dialogue policies
    • マルチドメインかつ様々なアプリケーションで利用可能な対話戦略を持つこと
  • Fluid conversational interaction (流暢な対話のやりとり)
    • Turn-taking / mixed-initiative (発話の順番、発話の時間的重なり)
    • Incremental (word-by-word) speech processing (逐語的な音声処理)
    • Dialogue modeling (対話をどうモデリングするか、意図や目的)

現状の音声対話システムは何が流暢ではないのか?

  • ほとんど全てのシステムが単純な turn-taking のプロトコルで成り立つ
    • 卓球のようなやりとりを仮定し、発話の重複がない
    • All user-initiative / all system-initiative
  • ユーザーは、システムがユーザーの言うことや振る舞いを理解しているかわからない
    • 応答の待ち時間がながい、相づち (backchannels; 「ああ」や頷き) がない
  • ユーザーはいつ喋ることができるのか・何を喋ることができるのかがわからない
    • Okay のような単純な発話ならすぐ使えるとはわかる
    • それ以外の発話はさっぱり何を言っていいのか見当がつかない
    • やりとりが簡単に脱線する
    • ユーザーにとっては、ひとつひとつの発話を決めるのが大変

Example 1: The Eve Agent (2014-2016)

  • ドメインを絞っており、応答が速い
  • 小さなドメインなら理解・応答が素早いシステムを作ることができる
  • しかしどのような[限定的な]ドメインでこのような素早いシステムが必要になるかは定かではない
    • [タスク指向ならいくらでもあると思うけど]

Example 2: Conflict Resolution Agent (2015-2016)

  • いろんなタイプの発話をサポートしている [たぶんシステム側]
  • Mixed-initiative を許容する
  • 速いペースのやりとりが可能

How do we make progress?

  • turn-taking や個人の turn の構造について単純な仮定を置くのを止めるべき
  • やりとりにおける時間のモデルとして良いものを用いるべき
  • より拡張的・一般的・ data-driven な対話モデルを開発するべき
  • 人間対人間の会話データを増やすべき

[まとめ]

  • DeVault さんが挙げている音声対話システムの一つの問題は流暢さ
  • 例二つは、それぞれ次を実現している
    • 幅広いドメインで素早く応答
    • 割り込み・重複を許容した振る舞い
  • We need to create fine-grained models that take seriously the timing of speech and the detailed mechanics of how human conversation unfolds through interlocutor decision-making at small timescales
  • We need to improve our ability to create intelligent agents and other dialogue systems that are not purely user-driven or system-driven, but instead have a pervasive mixed-initiative capability
  • 上の2文とも言ってること同じ

2. Mark Liberman, University of Pennsylvania

Abstract: Three Steps (Liberman 自身によるまとめ)

  • Robust diarization
    • すなわち、誰がいつ話しているか (who spoke when)
    • 大きな問題は、発話の時間的重複と背景のノイズ
    • 現状の技術では整った静かな環境の diarization も難しく、 what の理解まで行くにはまだ遠い
  • Dialogue systems with human-like turn-taking
    • 人は、例えば協調や競争の目的で相手の話に割り込む
    • 対話システムは典型的には割り込みをリセットの信号だと解釈する(実際にはそうではないのに)
    • システムは相手が喋っている間には喋らない(相づちも含めて)
    • much less to correct misunderstandings, introduce relevant information, or cut to a proposed solution.
  • Conversation systems that can participate effectively in a meeting, manage a classroom, or chat overa game of poker
    • このようなシステムは diarization 以外にも物理的な環境・社会的文脈で何が起きているのかを追跡することが必要
    • 同様に、どのようにいつ会話に貢献するか、その貢献を他者が受け取る・受け取らないことを動的な関係としてどのように調節するかを学ぶ必要がある
    • さらに、異なる会話の文化にも対応できなければならない

3. Diane Litman, University of Pittsburgh

Dialogue Systems: A Brief History

  • ELIZA (1966, chatbots)
  • SHRDLU (1971, AI, block)
  • Allen, Cohen, & Perrault (1980s, plan-based)
  • VODIS, VOYAGER (1990s, speech, "How many hotels are there in Cambridge?")
  • startups (2000s)
  • Siri (2010s)

Back to 1980: Analyzing Intention in Utterance

  • 発話の意図の分析を行って対話のプランを考えていた
  • 対話における協調的な振る舞い
    • 間接言語行為 (indirect speech acts), 助けになる返答 (helpful responses) など
  • knowledge-based なアプローチ
    • 相手にもプランの考案、実行があると考え、それを推論して障害を発見した上で自分のプランを考えて実行する

What about Siri? (example for indirect speech acts)

  • 間接言語行為が理解できない例
    • Diane: I don't know Megan's address.
    • Siri: Don't warry about it, Diane. (教えてくれない)
    • Diane: Can you tell me Megan's address?
    • Siri: Here's the address for Megan ... (教えてくれる)
  • 明示的に要求しないと伝わらない

Helpful Responses

  • 要求された以上の情報を返してくれること
    • Diane: What day of the week is election day?
    • Siri: Election Day is on Tuesday, November 8 2016
  • [ユーザーが何を必要としているのかを察して情報を増やさなければならない(増やせると便利)]

Indirect + Helpful

  • 間接言語行為を理解して、かつ強調的に情報を増やしてくれる例
    • Diane: I'm hungry
    • Siri: I don't want you feeling all peckish.
    • Siri: Here's what I found ... (15 results displayed)

Summary

  • 協調的な対話研究は大部分は諦められ、より実践的なアプローチに移った(Diane さん自身の研究も含め)
    • "There is much to be gained from recognizing not just what was said, but why; from identifying conclusions people naturally draw from both what has been said and hasn't" (Workshop CFP)
  • 1980年代の観点から見て、今のシステムがどのように協調的であり、どのように協調的であるべきかを考える必要がある

4. Amanda Stent, Yahoo! Labs, NY

In the Beginning Were Problems

Then Problem Definitions ...

  • Finite-state script
    • call transfer
  • Frame based
    • getting flight info
  • Sets of contexts
    • booking travel
  • Plan-based models
    • kitchen design consultant
  • Agent-based models
    • disaster relief management
  • 対話の問題設定は様々考えることができる
    • 上から下にいくほど複雑になる
    • 出典は Allen et al. (2001), AI Magazine

Evaluation Metrics and Parametrizable Methods, Data and Time

Challenges

  • Move beyond info-seeking dialog
    • 情報を探すだけの対話から更に発展させる
    • ユーザーのコストを削減するのではなく、ユーザーに利益を与えるような対話システム
    • 新しい評価指標
    • やりとりに関わるパラメータを増やす
  • Go back to our roots: human intelligences としての AI モデル
    • Entrainment
      • 情報共有的な意味での同期: 語彙のレベルや知識表現が良くなければユーザーと等しい情報を持つことができない
    • Anaphora resolution and grounding
      • 照応と物理的世界の参照
    • Contextually appropriate, mixed-initiative generation
      • 文化的・社会的慣習などの文脈に適合すること
      • 発話のタイミングが入り組んでも対応できること
    • Non-cooperative and semi-cooperative dialog
      • 必ずしも協調的でない対話ができること

Interesting Current Directions

  • Complex and flexible tasks, evaluation beyond efficiency
    • タスク設定と評価方法
  • Anapora and entrainment, shared language representations
    • 照応、情報の同期、共有される言語表現
  • Non-cooperative (situated) dialog
    • 協調的ではない対話
  • それぞれについての論文はスライド末尾(-1)参照

Stent さんおすすめの参考文献

以下、メモ作成者のメモ

Issues

  • understand very well and wery quickly
  • turn-taking / mixed-initiative
  • diarization (who speack when + what)
  • indirect speech acts / helpful response (cooperation / non-cooperation)
  • physical world, social context (semantics, vocabulary)

そういえば岡野原さんがIBISで言ってたこと (http://www.slideshare.net/pfi/ibis2016okanohara-69230358)

  • 知識をどのように埋め込むか、記憶と想起
  • 心理モデルや意図推定
  • コミュニケーションの目的関数と評価

やはりマーっぽい記述のモデルで整理するといいのでは(以下省略)

  • おわり

Attention-Based Convolutional Neural Network for Machine Comprehension をやる

著者の微妙に動かないコードを動かすだけです

  • paper: [1602.04341] Attention-Based Convolutional Neural Network for Machine Comprehension
  • github: GitHub - yinwenpeng/MachineComprehension
    • cis や word2embedding などのライブラリは Yin さんの別のレポジトリにあるのでコピーして持ってくる
    • train_arc1_v4.py というやつは動きます
    • 精度が高いのは train_entailment_v3.py というやつのはずで、こっちがそのままだと動かない、動かしたい
    • まず preprocess_mctest.py をいじいじして必要なファイル(vocab_DQAAAA.txt まで)を作る
    • DQAAAA とか DPNQ とか書いてあるのはデータの内容の形式です、 document, question, answer, positive, negative がどの順で書いてあるか、という感じ
    • しかしエラーが出るので露頭に迷う。 DPNQ.txt まで生成されない(Statement ファイル群がない)のでそもそもデータが足りない
  • github2: GitHub - BenjaminHess/MachineComprehension
    • ちょっとコードが整理された fork だけど、特に改善されている雰囲気ではない
    • このままでは相変わらず train_entailment_v3.py は動きません(データの読み込みで sharedvariable 宣言するところでエラー)
    • まず Statement の在り処が書いてあるので、データを引っ張ってきて Yin さんの方のにコピーするのでもよいです(DPNQ はすでにあるのでどっちでもいい)、とにかくデータはこれで揃うことになります
    • で、試行錯誤する
  • 原因は loadData.py L1342 の読み込みのとこで lower() を入れてない部分だと気付いた
    • 入れれば word の id 取ってくる部分を失敗せずに必要な theano.shared() が通ってくれます
    • でも精度が論文通りにならず困る、辛抱強く epoch 上がるのを待てばいいのだろうか……