representationと呼ばれるものを作り,そこから2つの出力層を使って回答スパンの開始と終了位置を求めるのだとか。こねこねする部分が微妙に複雑でなんでこんな計算にしてるのか元論文読まないといまいち意図が把握できない。最近のQAこんなんばっかりだ。devセットの評価では未知語について文字ベースでスペル情報を入れると大きく改善、肝心の辞書情報の方の寄与はやや低め。~78%)には及ばない。そもそもベースラインがしょぼい。QAでSOTAを取ることが目標というわけではないのだろうけど。これらを全部同時にやった時の場合は実験しなかったのだろうか?まあまだarXiv版だからこれから色々追加実験するのかもしれない。他のタスクについても性能向上への寄与は同じような感じ。前者については同様の処理を繰り返す(つまり定義文中の未知語についてもその定義文を用いる)ことが自然だと考えられるが、計算量やメモリの観点からそれを素直にやるのは辛そうだとのこと。この2つは上手いこと解決できたら面白いと思う。定義文らしいものが早期に記述されるであろうWikipediaのデータを用いた疑似定義文でも有効だよ、ということを実験したほうが良かったのでは。synsetは複数あるためそこのWSDが必須になると思うのだがそこの処理についての詳しい記述が見当たらなかった気がする・・・?どうしているんだろう。ついて読んだやつまとめ。公開されたデータセット。この処理によってエンティティに関する事前知識を持っていた場合に記事を読まずに質問に答えることを不可能にしている。Mailが879K記事前後。modelといったベースラインとNNベースのモデルを比較。文書とクエリから構築したベクトルと回答候補aのベクトルの内積になっている。計算し直すなどをやっている。アテンションを掛けてもう5%向上といった感じ。NAACL'16]以前言語処理学会で見て面白いなあと思っていた研究。文書・クエリのベクトル表現の話が中心で回答候補のベクトルについては特に何もしていなかったが(というよりそれがこのタスクの重要なところじゃないの?という気がするけど)、それに対して文書から動的に対象となるエンティティのベクトル表現を構築することがメインテーマ。提案手法の工夫は大きく分けて3つ。表現する事で文脈を伴うエンティティの表現ができる。