Why Neural Translations are the Right Length [Xing+, EMNLP'16]
概要
SMTがbrevity penaltyなどを用いて翻訳結果の長さの調整に腐心しているのに対し、 NMTは翻訳に失敗していたとしても比較的長さは入力と同じになりやすい。 その理由を分析するために a, b の2種類のトークンのみを用いて、入力と全く同じ出力を返すようなencoder-decoderモデルを訓練し、 その際のLSTMのセル(4次元)の状態を入力ごとにプロットしている。
結果、明らかに長さに反応して増減しているセルやa, b の数、文頭に連続するaの数に反応するセルなどが確認され、 decoder側での長さに反応しているセルが規定値を取るとEOSの出力確率が激増する、という仕組みになっていると述べている。
次元数1000で実験した翻訳タスクでも同様で、ある入力が与えられたときの長さに影響しうるk個のセルの値を用いて出力文長に対するlogistic回帰を行った所 top-10のセルを用いて 87%~97% の精度が達成できている。
このように、LSTMのモデルの中にはっきりと長さに反応するセルが訓練されることで出力の長さがコントロールされている、という話。
雑感
翻訳タスクかつ単語ベースだと入出力の長さの対応は結構取れている事が多いだろうけど、 他のタスク(要約とか対話とか)や文字ベースの場合そのあたりの話はどうなるのだろう? Controlling Output Length in Neural Encoder-Decoders [Kikuchi+, EMNLP'16] のように他タスクをニューラルで解く際の文長に関する研究が有ることから、結構デフォルトで出力文長に関してちゃんと学習されているかは怪しい。
対話なんかも長い発言に対する応答が必ずしも長いとは限らないし、そもそも文字ベースになると単語では一対一で意味の対応が取れていた部分が全く当てにならなくなる。文字ベース翻訳はあまり試したことないけどdecodeの結果はどうなるのだろう?
Ridge Regression, hubness, and Zero-Shot Learning [Shigeto+, ECML'15]
概要
タイトルの通り、Zero-shot learningにおけるHubness問題の原因の考察とそのシンプルな解決法。 Zero-shot Learningはある事例空間Aからラベル空間Bへの写像を学習し、テスト時には写像後に近傍探索することで画像のラベル付けなどを行う。 ラベル空間そのものに対するマップを学習しているため、訓練データの事例にラベルXに対応するものが存在しない場合でもXがラベル空間上で点を持てば対応 可能である、という利点がある。
Hubness and Pollution: Delving into Cross-Space Mapping for Zero-Shot Learning [Lazaridou+, ACL-IJCNLP '15] でも似たような話があったが、普通にL2正規化を行って対応するラベルとの二乗誤差を最小化するように学習すると、ほとんどの事例が対応するラベル(Hub) が生まれてしまう、という問題。
事例空間を写像した時ラベル空間上では原点中心の何らかの分布になると仮定すると、ラベル空間で定義された点のうち原点付近のものは 事例空間を写像した点の近傍になりやすくなる。(特に高次元ベクトルでは次元の呪いから近傍点と遠傍点との距離の差は大きくなるため、その問題が顕著になる?)
重要なのは以下の2点。
(1) Hubが出現しない、ということは写像後の点 とラベル空間の2点 ( ) との距離を考えた時に原点からの距離に関わらず2点が近傍であり得る、つまり距離の2乗の期待値の差が小さい事に相応する。また、論文の証明によるとはラベル分布の分散に比例する。
(2) L2正規化を加えて二乗誤差によって写像の最適化を行った場合、写像後の分布の分散は写像前よりも小さくなる。(shrinkage)
筆者はこれらの考えから提案手法として、事例空間をラベル空間に写像するのではなくラベル空間を事例空間に写像する、つまり写像方向を逆にするだけで ラベル空間の分散は小さくなるため、Hubの出現が抑制される、と述べている。
論文:https://arxiv.org/pdf/1507.00825v1.pdf
スライド:http://cl.naist.jp/~yutaro-s/download/Shigeto_NL222_slides.pdf
A Dynamic Oracle for Arc-Eager Dependency Parsing [Goldberg+, COLING'12]
概要
係り受け解析器の訓練をオンライン学習で行う際、訓練データとして与えられる解析結果のツリー(oracle)はある操作、ある単語からある単語への係り受け関係(arc)を付与する、という操作のシーケンスとして表現され、モデルはある状況で1つ操作を選択する試行を繰り返して最終的なツリーを構成することとなる。
その際に、既存手法では分解したツリーをどのような順序で並べるかは何らかのアルゴリズムによって決定される。 筆者はこれをstatic-oracleと呼び、あるツリーから生まれるシーケンスはアルゴリズムによって一意に決まる。
例えば、(A,B,C,D,E) からの選択問題で (A, C, E) のセットが正解だった場合、「正解を左から取っていく」というアルゴリズムでは生成されるoracleは[A, C, E] であり、 [C, A, E] や [E, A, C] などの順序にはならない。
こうしたstatic-oracleで訓練した場合、上の例だと何かの拍子に 最初に E が選ばれてしまった場合、oracleの中には E が選ばれた状況で A, Cを選ぶようなものが存在しないため、oracleの与え方によってこうしたパターンの学習が行われない、つまり正解にたどり着く複数のルートのうち学習できるのが1つのみ、という事になってしまう。
これを改善するため、オンライン学習の途中でモデルのoracleに対するテストを行い、「モデルが選びそうな正解への道」をoracleとして与えてやる、という事をしている。
(全部のシーケンスを正解として与えてやれば良いんじゃないか?と思ったけどシーケンス長が大きくなった時にサイズがとんでもないことになる、という感じだろうか。)
Curriculum Learning [Bengio, ICML'09]
概要
Bengioの有名な論文。誰か読んでまとめた記事があるんじゃないかなと探してみたらとても分かりやすいのがあった。
人間が物事を学習する時、いきなり難しい問題を与えられるよりも簡単なものから始まって徐々に難しくしていった方が効率よく学習が行える、という経験的な感覚がある。これは機械学習でも同じことが言えるんじゃないか、という事を図形分類、言語モデルというタスクで実験的に確認した論文。
徐々に難しくする、ということはここでは複雑性の高いサンプルを徐々にデータセットに加えて行く、という事を指す。 そこで問題になるのはどういう方法で難しさを順位付けするかになるが、それはやはりタスクによって異なる。
実験
やっている実験は
1. ノイズを含むxによるyの分類
2. 図形の3クラス分類
3. 言語モデルでの実験
2.は簡単なデータとして正方形や正円、等辺三角形からなるBasicShapesと難しいデータとして長方形や楕円、不等辺三角形からなる GeomShapesの2種類のデータを用意した上で、全256epochのうち初めはBasicShapes, 途中からGeomShapesに切り替えることでCurriculumを実現している。 128epochで切り替えた時が一番結果が良く、すべてごちゃまぜで訓練した場合はfig.3で言う16epochで切り替えた時くらいの性能。
3.ではW=5を窓幅としてfeed-forward NNの言語モデルを用いている。その際のCurriculumとしては頻出上位5000語, 10000語.. というように区切った上で、窓内がその上位N語のみで構成されるものを簡単なサンプルとしている。
A Diversity-Promoting Objective Function for Neural Conversation Models [Li+, NAACL'15]
概要
A Persona-Based Neural Conversation Model [Li+, ACL'16] の一つ前の論文。
実験していてもそうだったが、seq2seqベースの対話はやはり典型的な応答 (e,g, I don't know. )が頻出する事が問題になるらしく、
それをどうにかしようという話。
手法
基本的な考え方としては を最大化することで生成される文がいわゆる典型的な表現であった場合にペナルティを加える、というもの。 簡単な式変形から明らかだが、結局 、発話と応答の相互情報量を最大化していることに等しい。
これに加えて典型的な表現をペナライズする程度の調整が効くように (1)
としたものと、ベイズの定理から式変形して
(2)
としたものの2種類を検討している.前者をMMI-antiLM, 後者を MMI-bidi と呼んでいる。
また、訓練時にλを最適化するのが現実的に難しいため、この手法はdecode時にだけ用いているらしい。decode時には改めて各種係数を最適化している。
(1) MMI-antiLM
ここで問題にしているのは、 をペナルティとすることは単純な言語モデルとしての性能を下げる事につながっているため,文法的におかしい文が出力されやすくなってしまうこと。
この際、入力をエンコードした情報は出力文の初めの方に強く影響しがちで、出力の後半になるほど出力部のみでの言語モデル(decoderの途中の出力)の影響が支配的になる。事実、普通にやると出力文の後半の方が文法がおかしくなるとのこと。そのため、適当に閾値 を決めた上で
として、 を に置き換えて最適化をしている。一種のattentionモデル。 こうすると、文全体の出力確率をペナライズするのではなく文の前半部分の出力確率をペナライズする事になるため、出力文の前半部に典型的なパターンが来ることを避けた上で、性能の劣化を避けている。ちょっとアドホックな気もするが、 を連続的に変化させるやりかたでは駄目だったとのこと。
の部分、実装的にはどうしてるんだろう? decoder単体で別に訓練している?
(2) MMI-bidi
こっちでは、入力・出力を逆にしたseq2seqを学習して直接を求めている。
そこで問題になるのは、出力文の探索空間が広すぎるためありえる全ての出力文に対する の計算が現実的には不可能であること。
そのため、第一項だけを使ってbeam-searchからN-bestな応答を生成した上で、第二項を使って選択するというやり方にしている。
実験
データセット
Twitter Conversation Triple Dataset
[Sordoni, '15]のデータセットの拡張。OpenSubtitles dataset
[Tiedemann, '09] による60M~70Mほどの映画での会話集。ただ、あるセリフを誰が喋っているのかが明記されていないため、話者が同一なのか異なるのかがわからない事が問題になる。そのため、 [Vinyal, '15]と同じやり方をする、OpenSubtitles datasetの中身を知らないためここの対処法の意味がよく分からない
もしくはInternet Movie Script Database と呼ばれるものを用いて、誰が喋っているのかを特定する、というやり方を取っている。
設定
4layer, hidden:1000, learning rate:0.1, batch:256
だいたい Vinyalとかがやる設定と同じ。
評価
BLEUと、生成の多様性を見るためにdistinct-1, distinct-2と呼ばれる、応答全体に含まれる1-gram, 2-gramの種類数を同じく1-gram,2-gramの総数で割ったものでも評価している。
結果
数値的には軒並み上昇。生成された応答も面白くなっている。しかし最適化してるものは同じなのにMMI-antiLMとMMI-bidiでそこまで差が出るものか。 (1) 出力文後半についてはペナライズしない、attention的なやり方を加える のと、(2) 第一項で生成したあと第二項で選択する、というようにフェーズを分ける というのが違いであるように読めたけど・・・。
Overleafで日本語を使う
ググっても微妙に出てくる例が違う。下記は上手く行った例。
\usepackage[pass]{geometry} \usepackage{CJK,CJKspace,CJKpunct} \begin{document} \begin{CJK*}{UTF8}{min} --- 本文 --- \end{CJK*} \end{document}
メモ帳をブログに移行・投稿用チートシート
はてなブログに移行
これまでHarooPadをメモ帳として使っていたけど,読んだ論文やアイディアについてタグや検索機能が無いのが後々辛くなりそうなので更新がめんどくさくならないかぎりこっちに書くことに。研究室でのメモ書き・バイト等のネットにかくとヤバそうなことはHarooPadに書いて,論文の記録はこっち、と分けてもいいかもしれない。 ただ毎回論文しっかり読んで理解した上で感想かけるわけでもないので、流し読み程度のやつにはpaper+memoタグを付ける感じで運用する予定。
以下チートシート
文字への編集、引用、脚注
アンダーライン
打ち消し
太字
引用
脚注*1
改行はスペース2つ
箇条書きと階層化
- 一行空けないと箇条書きが適用されない?
- 段を下げたいときはスペース3つ
- 下も一行空ける
- 段を下げたいときはスペース3つ
リンク
はてな基礎文法最速マスター (はてな記法は使ってないけど)
ではないです (@letra418) | Twitter
twitter.com
ソースコードの挿入
# client.py import subprocess, sys proc = subprocess.Popen('python shell.py', shell=True, stdout=subprocess.PIPE, stdin=subprocess.PIPE, )
数式
注意点まとめ
http://cocodrips.hateblo.jp/entry/2017/04/11/032000 http://www.f-sp.com/entry/2016/08/07/182629
[], ^, _ を使うときにはエスケープ
*1:脚注