2021-08-15

論文メモ：COLING2016, Automatic Extraction of Learner Errors in ESL Sentences Using Linguistically Enhanced Alignments

論文メモ

@inproceedings{felice-etal-2016-automatic,
    title = "Automatic Extraction of Learner Errors in {ESL} Sentences Using Linguistically Enhanced Alignments",
    author = "Felice, Mariano  and
      Bryant, Christopher  and
      Briscoe, Ted",
    booktitle = "Proceedings of {COLING} 2016, the 26th International Conference on Computational Linguistics: Technical Papers",
    month = dec,
    year = "2016",
    address = "Osaka, Japan",
    publisher = "The COLING 2016 Organizing Committee",
    url = "https://aclanthology.org/C16-1079",
    pages = "825--835",
}

概要

文法誤り訂正（GEC）のための自動アライメント手法を提案しました．特に，Damerauの編集距離をベースとし，言語情報を考慮することでコストの計算部分を拡張します．また，2トークン以上の編集にも対応させるために，アライメントをマージする手法も提案します．人手のアライメントと比較する実験の結果，提案したアライメント手法は人と80%以上一致することを示唆しました．さらに，ルールベースに基づく手法であるため，編集情報の抽出を一貫性をもって行えるとしています．

自動アライメントの重要性

今までは，アライメントは手動で行われることが一般的でした．しかし，手動のアライメント手法には次の2点の問題点があると主張しています．また，自動のアライメント手法ではこれらを解決できるとしています．

アライメント作業は面倒
直感的にも，手動アライメントは面倒な作業です．edit-basedな評価を行うことを考えると，原文とモデルの出力文に対してのアライメントを毎回取る必要があります．これを毎回人手で行うわけにはいかないため，自動アライメント手法を確立することは重要です．
一貫したアライメントが取れない
手動のアライメントは一貫性がないことがあります．人手で行われたアライメントを分析すると，[has → was] というアライメントもあれば，[has eating → was eating]というアライメントもあったようです．後者の例ではeatingという単語は変化していないため，[has → was]のみにした方が良さそうに見えます．自動アライメントではこのような違いは発生せず，一貫性のあるアライメントが取得できます．

アライメント手法

まず，大きな枠組みとしてDamerauの編集距離のコストからアライメントを取ります．Damerauの編集距離は，置換，挿入，削除，隣同士の単語の入れ替えを許す編集距離です．今まではノーマルなLevelshtein Distanceが用いられてきましたが，語順誤りにはうまく対応できませんでした．例えば，[A B → B A]のような訂正の場合，[A → $\phi$ ]，[B → B]，[ $\phi$ → A]のように3つのアライメントに分かれてしまいます．そこで，入れ替えの操作も許すDamerauの編集距離を採用することで，語順入れ替えも「語順入れ替え」として処理できるようになりました．さらに，[A B C → B C A]のような3トークン以上の語順入れ替えに対応するために，コスト行列を対角線的に遡って探索するように拡張しています（Listing 1）．

f:id:gotutiyan:20210810005636p:plain

次に，Damerauの編集距離の置換コストを，言語情報を考慮したものに置き換えます（Listing 2）．考慮する言語情報は次の4つです．

小文字化したときに一致するか
一致すればコストは $0$ とします．そうでなければ，次の2. 3. 4. の3つのコストを足した値とします．
lemma cost
metとmeetingのように，置換前後の単語が同じlemmaを持つ，もしくは派生形（derivationally related form）であれば $0$ ，そうでなければ $0.499$ とします．
part-of-speech cost
置換前後の単語が同じ品詞なら $0$ ，ともに内容語（形容詞，副詞，名詞，動詞）なら $0.25$ ，いずれでもないなら $0.5$ とします．
character cost
置換前後の単語の文字レベルのDamerau-Levenshtein distanceを，アライメントの長さで割った値とします（ $0$ 〜 $1$ ）．

lemma costでは派生形（derivationally related form）という概念があります．ここで派生形は，置換前後のトークンのlemma集合が交差していることを指します．例えば，metとmeetingが派生形かどうか調べたいとして，各単語のlemma集合を考えます．metは動詞のみなのでlemmaはmeet，meetingは名詞と捉える場合と動詞と捉える場合でlemmaが異なり，それぞれmeeting，meetです．よって，lemma集合はそれぞれmeetとmeeting, meetであるので交差し，2つの単語は派生形とみなされます．

f:id:gotutiyan:20210810000125p:plain

実験

自動アライメントと手動アライメントを比較し， $F _ 1$ スコアを見る実験を行っています（Table 4）．まず，Levenshtein Distanceによるアライメントと，人手で作成したGoldアライメントは50%程度の $F _ 1$ スコアでした（Table 4，LevとGoldの列）．

次に，人手アノテーションを最小限の訂正になるように修正したアライメントも作成しました．具体的には，両端から同じトークンを再帰的に削除します．この処理により，[has eating → was eating]のような訂正も[has → was]のみになります．このように修正を加えたGoldをGold-Minと呼んでいます．このデータを用いると，Levenshtein Distanceでは60%程度の $F _ 1$ スコア，Damerauの編集距離だと70%程度の $F _ 1$ スコアでした．この結果から，アライメントの最小化を行う処理はアライメントをより正しく評価することができ，かつ，言語情報を取り入れたDamerau編集距離が人との一致率の向上に貢献することがわかります．

f:id:gotutiyan:20210810003127p:plain

アライメントのマージ

これまでに説明されたアライメントの手法では，2トークン以上の編集が分割されることがあります．人手のアノテーションを見ると，ほとんどの編集は0:1（1トークンを挿入），1:1（1トークンを別の1トークンに置換），1:0（1トークンを削除）のいずれかですが，0-2:0-2のような訂正もやはり存在します（Table 6）．よって，得られたアライメントを適切にマージする必要があります．例えば，[wide spread → widespread]のように結合するような編集は，現状のアルゴリズムでは[wide → widespread]，[spread → $\phi$ ]のように，1:1と1:0の2つの編集に分割されます（Table 5）．このようなものはマージして[wide spread → widespread]とし，2:1の編集として扱う方が望ましいです．

f:id:gotutiyan:20210810152834p:plain

アライメントのマージは10個のルールに基づいて行います．（このルールに関しては，論文の記述を直接読んだ方が分かりやすいと思います．以下は参考程度で．）

挿入アライメント（M）で分割する．例：アライメント列がMSDSTDSSMなら，M, SDSTDSS, M
句読点を含む編集で，その次にケース変更の編集があればマージする．
例：[, → .]，[we → We]があれば，[, we → . We]
入れ替えの編集があれば，それを独立にする．
所有格の接尾辞に関する編集は，その前の編集とマージする．
例：[friends → friend]，[ $\phi$ → 's]があれば，[friends → friend 's]
トークンの間に空白を挿入もしくは削除する編集をマージする．
文字が70%より多く一致している単語で，かつ，その前のトークンと品詞が一致していなければ独立にする．
ある置換の編集の前に置換の編集があるとき，独立にする．
少なくとも一つの内容語が含まれる編集の組み合わせを全てマージする．
同じ品詞に関する連続した編集をマージする．
連続した編集の最後にある決定詞に関する編集は独立にする．

これらのルールは1>2>...>10の優先度で適用されます．また，あるルールを適用してマージ・分割が起これば，残りの未確定の部分列に対して再帰的に適用されます．Figure 1はその一例です．

f:id:gotutiyan:20210810161230p:plain

アライメントのマージに関する実験

アライメントをマージすることで，さらに人との一致率が向上することが示唆されました．ベースラインとして，All-split（マッチしないアライメントは全て独立にする），All-merge（マッチしない連続したアライメントは全てマージする），All-equal（同じ操作であって，マッチしない連続したアライメントはマージする）の3つと比較しています．

結果はTable 7の通りです．提案手法が最も高い一致率を示しました．ただし，ベースラインの手法にはそれぞれ良いところがあるとしています．例えば，All-splitはTPは高くFNは低いが，FPも高くなります．これは2トークン以上に関わる訂正を無視するような設定になっているからです．一方で，All-mergeはFPの値が低くなる一方でTPは低く，FNは高くなります．提案手法はルールベースな手法によりアライメントを適切に分割・マージするので，All-splitとAll-mergeの良いところを利用できるため，一致率が高くなると分析しました．

それから，エラータイプの分類も考慮した一致率でも，提案手法は最も高い値を示しました．編集情報へのエラータイプの付与は，MaxEnt error type classifierを利用したとしています．

f:id:gotutiyan:20210810162830p:plain

考察

ここまでに行ってきたアライメントの性能評価は，どうしても過小評価されています．例えば，同じ編集でも，人によって[has eaten → was eating]，もしくは[has → was] + [eaten → eating]のようにバラつくことがあります．このようなばらつきは最小化（Gold-Minを作ること＝端から一致したトークンを消すこと）を実施しても解消されないため，自動アライメントはいずれか一方にしか正解の判定を得られません．

他のデメリットとして，複数の誤りを扱う編集や，編集の途中に未編集のトークンが存在する訂正はうまくマッチしないことがあります．（Gold-Minは両端からのみ未編集のトークンを消すので，途中に存在する未編集トークンは最小化できない．）

一方でメリットは，出力に説明性があること，一貫性があることです．ある編集がマージ・分割された理由を知りたいときは，その操作を実施したルールから説明できます．また，ルールベースに基づいているので，編集の抽出に一貫性があります．

最後に，自動アライメントの先行研究と比較し，提案手法がF1スコアを大きく上回っていることを示しました（Table 8, 9，本記事では割愛）．

2021-07-30

論文メモ：EMNLP2020, Improving the Efficiency of Grammatical Error Correction with Erroneous Span Detection and Correction

論文メモ

EMNLP2020，Improving the Efficiency of Grammatical Error Correction with Erroneous Span Detection and Correctionの論文メモです．

@inproceedings{chen-etal-2020-improving,
    title = "Improving the Efficiency of Grammatical Error Correction with Erroneous Span Detection and Correction",
    author = "Chen, Mengyun  and
      Ge, Tao  and
      Zhang, Xingxing  and
      Wei, Furu  and
      Zhou, Ming",
    booktitle = "Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP)",
    month = nov,
    year = "2020",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://aclanthology.org/2020.emnlp-main.581",
    doi = "10.18653/v1/2020.emnlp-main.581",
    pages = "7162--7169",
}

ACL Anthology:
https://aclanthology.org/2020.emnlp-main.581/

概要

文法誤り訂正タスク（GEC）は，誤りを含む文から正解文への翻訳としてみなされ，EncoderDecoderのアーキテクチャが使われてきました．しかし，GECでは誤りのないトークンについては入力から出力へコピーすることが多く，コピーの処理までEncDecのアーキテクチャに任せるのは非効率です．そこで，誤りスパンの検出器と，スパンの訂正器のパイプライン型のモデルを提案しています．結果，seq2seqに劣らない性能を維持したまま推論速度を50%程度削減することに成功しました．また，検出器の閾値を調整することで柔軟な推論が可能だとしています．

提案モデルのアーキテクチャ

アーキテクチャは，誤り検出器であるerroneous span detection（ESD），erroneous span correction (ESC)の2つをパイプライン的につなげたものです（Figure1）．ESDは系列タギングに基づくモデルで，入力文の各トークンに対して正解か誤りかの2値をタグ付けします（Figure1 (a)）．この結果をもとに，入力文に<s1></s1>のような誤りスパンを示す目印をつけます．

ESCはEncoder-Decoderなモデルです．Encdoerには誤りスパンの目印も含めた入力文を全て入れて，Decoderは目印をつけたスパン内のみ出力します（Figure1 (b)）． f:id:gotutiyan:20210730005039p:plain

ESDを訓練する上では，あるトークンが誤りかどうかの正解情報が必要です．そこで，アノテーションツールであるERRANTと同じ方法でsourceとtarget間のアライメントを取ります．また，ESCの訓練時には，誤りのスパン以外にもランダムに選択したスパンも加えて学習させます．これはESDの検出エラーがESCに及ぼす影響を緩和するためです（ESDが誤って検出したスパンはESCが訂正しないことも大事）．ランダムなスパンの選択は，SpanBERTの論文の3.1節に書かれている方法と同じです．これは，スパンの長さをGeometric distribution（小さい値に偏った分布）からサンプリングし，スパンの開始点を一様分布からサンプリングして作ったスパンを追加することを，文に占めるスパンの割合が閾値を超えるまで続けるものです．

データ

学習データとして，英語ではBEA-2019 Shared Taskの訓練データを使っています．さらに，事前学習として260M文の擬似データを用いています．この擬似データは，誤りでないトークンをランダムで選択し，そのトークンをConfusion-setで対応する誤りトークンに置換して作成します．

中国語のデータには，NLPCC-2018 Chinese GEC shared taskの公式データを使用します．

結果

英語（CoNLL-2014テストデータ，BEA-2019テストデータ）と中国語（NLPCC-2018テストデータ）で評価しています．

英語のデータセットでは，提案手法は先行研究のトップの性能には及ばないものの高速に動作するため，実応用に向いているとしています（Table 1）．Table 1は3つのグループで比較が行われています．上のグループが擬似データによる事前学習なしのグループ，中央のグループが擬似データを用いた事前学習ありのグループ，下のグループがアンサンブルやリランキングなどのヒューリスティックな手法も加えたグループです．

f:id:gotutiyan:20210730123156p:plain

速度の比較では，全てを自己回帰で生成するseq2seqな手法の半分で推論可能だとしています（Table 2）．Table 2は上のグループがpytorch実装，下のグループがtensolflow実装です．LanserTaggerやPIEは系列タギングに基づくモデルで，高速に動作することで知られています．また，英語と中国語の両方でseq2seqと遜色ない性能を達成しており，言語非依存で適用できることも示唆されます．

f:id:gotutiyan:20210730124658p:plain

また，ESDやESCが処理した実数値も分析しています（Table 3）．Table 3において，ESD+ESCは誤りスパンを検出→スパン内のみデコードする提案手法，ESD+seq2seqは誤りスパンが検出された文を（スパン関係なしに）全てデコードする手法を示しています．つまり，ESD+seq2seqとseq2seqを比較するとESDの貢献がわかり，ESD+seq2seqとESD+ESCを比較するとESCの貢献がわかります．結果，ESDはseq2seqよりもデコードする文を400文程度減らしており，ESCは時間を半分程度に削減することに成功しています．また，ESCはデコードするトークン数を1/3程度減らす効果があるようです（21,065 → 7,647）．

f:id:gotutiyan:20210730125906p:plain

それから，ESDの閾値を調整することで，モデルの振る舞いをPrecision重視にするかRecall重視にするかを決められることも利点だとしています．ESDの閾値を高くするとPrecisionが向上してRecallが低下し，閾値を低くするとその逆になります．これは直感的にも正しいですし，実験でも示されています（Table 4）．

f:id:gotutiyan:20210730130133p:plain

2021-07-30

論文メモ：ACl2021, Instantaneous Grammatical Error Correction with Shallow Aggressive Decoding

論文メモ

ACL 2021 long paper, Instantaneous Grammatical Error Correction with Shallow Aggressive Decodingの論文メモです．

@inproceedings{sun-etal-2021-instantaneous,
    title = "Instantaneous Grammatical Error Correction with Shallow Aggressive Decoding",
    author = "Sun, Xin  and
      Ge, Tao  and
      Wei, Furu  and
      Wang, Houfeng",
    booktitle = "Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers)",
    month = aug,
    year = "2021",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://aclanthology.org/2021.acl-long.462",
    doi = "10.18653/v1/2021.acl-long.462",
    pages = "5937--5947",
}

概要

文法誤り訂正のためのモデルとして，Shallow Aggressive Decoding (SAD)を提案しています．SADは，seq2seqのモデルにおいてデコーダを工夫することで高速な生成を可能にします．具体的には，Aggressive Decodingと呼ばれるteacher forcing的な生成手法と，Re-decodingと呼ばれる自己回帰的な生成方法を切り替えながら生成します．さらに，seq2seqのアーキテクチャとしてエンコーダの層を増やしてデコーダの層は減らすことで高速化します．結果，完全な自己回帰型のseq2seqモデルよりも10倍程度高速で，かつ高性能になりました．

推論方法

推論は，Aggressive DecodingとRe-decodingの2つを交互に切り替えることで行います．

Aggressive Decodingは，一つ前の系列をteacherとしてTeacher-Focing的に生成する手法です．特に，初回のAggressive Decodingではソース文をteacherとして系列を生成します．形式的には（2）式に従います．ここで $\mathbf{o}$ がモデルの出力， $\hat{\mathbf{o}}$ が一つ前の系列， $\mathbf{x}$ がソース文の系列を表しています．初回に限り， $\hat{\mathbf{o}}=\mathbf{x}$ です． $\mathbf{x}$ は当然givenなので，並列計算が可能です．後で議論がありますが，Aggressive Decodingでは系列の長さに制限を設けずに生成します． f:id:gotutiyan:20210726173305p:plain

次に，生成した系列 $\mathbf{o}$ と $\hat{\mathbf{o}}$ を先頭から比べて，完全に一致していれば $\hat{\mathbf{o}}$ には誤りが無いとみなし，終了します．もし一致しない場合，先頭から比べて初めてトークンが異なるインデックス $k$ を求めます．形式的には， $\mathbf{o} _ {1\dots k-1} = \hat{\mathbf{o}} _ {1\dots k-1}$ であり， $\mathbf{o} _ {k} \neq \hat{\mathbf{o}} _ {k}$ であるような $k$ です．この時点で， $\mathbf{o} _ {1\dots k}$ は生成結果として確定します．また， $\mathbf{o} _ {k}$ より後ろの系列は破棄します．

インデックス $k$ が見つかれば，Re-decodingに切り替えます．Re-decodingでは， $\mathbf{o} _ {k+1}$ から1単語ずつ自己回帰的に生成します．具体的には， $j (j\geq k)$ について式（4）に従って生成します． f:id:gotutiyan:20210726181433p:plain

Re-decodingは，入力系列と一致する $q$ トークンのsuffix（末尾からの部分列）が見つかるまで行います．形式的には， $j \; (j> k)$ について $\mathbf{o} _ {j}$ を推定したときに $\mathbf{o} _ {j-q\dots j} = \mathbf{x} _ {i-q\dots i}$ となるような $i, j$ が見つかれば良いです．もしこのsuffixが見つかれば，再度Aggressive Decodingに切り替えます．この時点で， $\mathbf{o} _ {1\dots j}$ までが生成結果として確定します．

再度Aggressive Decodingに戻ってきたときには，Teacher-Focingに用いる系列として式（6）のようにconcatしたものを用います．つまり，過去にAggressive DecodingやRe-decodingによって得られた系列と，それ以降に対応するソース文の系列をconcatします．Re-decodingのときにソース文の系列とのsuffixの比較をしているので，「それ以降に対応するソース文の系列」は一意に決まります．

f:id:gotutiyan:20210726183412p:plain

このように，Aggressive DecodingとRe-decodingを切り替えることで系列が生成できます．切り替えは条件を満たせば何度でも行われます．Aggressive Decodingは並列計算可能で高速であり，Re-decodingは自己回帰なので低速です．しかし，全てを自己回帰で生成するよりは明らかに高速に動作します．

また，Aggressive Decodingにおいてさらに低コストに計算するため，デコーダを浅くするshallow decoderを採用しています．

これらをより一般化したアルゴリズムはAlgorithm1に示されています．

f:id:gotutiyan:20210726184835p:plain

Aggressive Decodingの評価

評価データで性能を見る前に，開発データとしてCoNLL-2013を使って性能を分析しています．

まず，提案手法の速度と性能を調査するために，全てを自己回帰で生成するseq2seqモデルをベースラインとして比較します．結果，提案手法は明らかに高速に動作し，Recallは上昇するがPrecisionは低下する傾向にあるとしています（Table 1）．

f:id:gotutiyan:20210726185953p:plain

また，編集率が高いほど速度が低下します（Figure 2）．この理由として，編集率が高いと低速なRe-decodingが頻繁に実行されるからだと分析しています．これはTable2に具体例があります（本記事では割愛）．

f:id:gotutiyan:20210726190302p:plain

次に，Aggressive Decodingでデコードするトークンの長さは制限しなくて良いとしています（Table 3）．Aggressive Decodingで長々と出力しても，入力系列と異なるトークンがあればそのトークン以降は破棄されてRe-decodingに移ってしまいます．よって長々と出力するのはリスクが大きそうですが，むしろ制限しないほうが高速でした．この理由として，GECの入力となる文にそこまで長いものは無いからだと分析しています．

f:id:gotutiyan:20210726191542p:plain

最後に，エンコーダは深く，デコーダを浅くするのが良いとしています（Table 4）．Table 4中の3+6と9+6のブロックからはエンコーダを深くすると速度を維持したまま性能が向上することが分かり，6+3と6+9のブロックからはデコーダを深くすると速度が落ちるのに性能はほぼ変わらないことが分かります．11+1のように極端に深さを変えると性能が落ちることから，論文中では9+3を使っています．

f:id:gotutiyan:20210726191814p:plain

結果

英語（CoNLL-14データセット，Table 5）と中国語（NLPCC-18データセット，Table 6）で評価しています．

英語のデータセットについて，Multi-stage Fine-tuningなしの部門では，9+3のモデルが最高性能，かつベースラインを10倍高速化しています．また，先行研究のGECToRではBERTなどの事前学習モデルを用いていることに倣って，12+2のモデルをBARTで初期化しています．その結果 $F _ {0.5}$ で66.4を達成しました．

f:id:gotutiyan:20210726194928p:plain

中国語のデータセットでも，性能は完全自己回帰であるようなTransformerと同等の性能で，12倍もの高速化を達成しています．また，ここでは英語や中国語のように言語非依存なGECが行えることも貢献としています．例えば，GECを系列タギングとして解いたGECToRでは，英文法の事前知識をもとにg-transformationと呼ばれるタグを用いて訂正を行っていますが，このタグを用いると英語のデータにしか適用できません．一方提案手法はタグを使わないモデルですし，文法に関する事前知識は必要ないため，言語によらず適用できます．

f:id:gotutiyan:20210726194939p:plain

2021-07-26

論文メモ：BEA2021, Document-level grammatical error correction

論文メモ

@inproceedings{yuan-bryant-2021-document,
    title = "Document-level grammatical error correction",
    author = "Yuan, Zheng  and
      Bryant, Christopher",
    booktitle = "Proceedings of the 16th Workshop on Innovative Use of NLP for Building Educational Applications",
    month = apr,
    year = "2021",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://aclanthology.org/2021.bea-1.8",
    pages = "75--84",
    abstract = "Document-level context can provide valuable information in grammatical error correction (GEC), which is crucial for correcting certain errors and resolving inconsistencies. In this paper, we investigate context-aware approaches and propose document-level GEC systems. Additionally, we employ a three-step training strategy to benefit from both sentence-level and document-level data. Our system outperforms previous document-level and all other NMT-based single-model systems, achieving state of the art on a common test set.",
}

概要

文法誤り訂正（GEC，Grammatical Error Correction）は文単位で処理を行うことが一般的でした．しかし，周囲の文脈も考慮することでより正確な訂正が期待できます．例えば，動詞の時制は周囲の文脈に出現する他の動詞などから推測できる可能性があります．そこで，文書単位のGECモデルを提案しました．結果としては，訂正対象の文と周囲の文脈を別々にエンコードし，デコーダ側で足すようなアーキテクチャが最も良いとしています．また，評価データとして従来の文単位の評価データではなく，文書単位の評価データを使って評価しています．

モデル

Baseline，SingleEnc，MultiEnc-enc，MultiEnc-decの4種類を比較しています．まず，BaselineはTransformerベースのseq2seqモデルです（Figure1 (a)）．このモデルでは文脈を考慮せず，訂正対象の文のみを見て誤りを訂正します．SingleEncもアーキテクチャはTransformerベースのseq2seqですが，入力に周囲の文も合わせた一つの長い系列を用います．MultiEnc-encは，訂正対象の文と周囲の文を別々にエンコードし，それらの重みつき和をデコーダに送ります（Figure1 (b)）．MultiEnc-decも訂正対象の文とその周囲の文を別々にエンコードしますが，デコーダ側には足さずに送り，2種類のアテンションを計算してから足します（Figure1 (c)）．2種類のアテンションとは， $c _ {current}$ のmasked multi-head self-attensionと， $c _ {current}$ から $c _ {context}$ への直接的なアテンションです． $c _ {current}$ は訂正対象の文のエンコード表現， $c _ {context}$ は文脈のエンコード表現です．

f:id:gotutiyan:20210724135803p:plain

MultiEnc-encにおける重み付き和は，式(1)のように計算されます．ここで重み $\lambda$ は式(2)のように計算されます．エンコードしたそれぞれのベクトルをconcatし，1層通すイメージです．

f:id:gotutiyan:20210724135903p:plain

文書レベルGECの評価

これまでGECで使われてきた評価用データは，正解が文単位で用意されているため，文書レベルGECの性能を正しく評価できません．そこで，文書単位の評価データを作成しています．作成するといっても，既存の評価データの分割単位を文単位にするか文書単位にするかというだけです．CoNLL-2014やBEA-2019は，元々はエッセイをアノテーションしたデータセットで，これまではそれを文単位で分割して使ってきました．今回の文書レベルGECの評価では，文書単位に分割したデータを使います．M2形式で考えると，Sから始まる行には1文書が対応します．

ただし，この評価方法は複数のアノテーションが付与された評価データにおいて，少し厳しい評価となります．理由は，従来は文ごとに最適なアノテーションを選んで採点できていたのに対して，今回は文書ごとにしか最適なアノテーションを選べないからです．

訓練

MultiEnc-encとMultiEnc-decのモデルは3段階で訓練します．1段階目は文単位のデータを用いた事前学習です．この段階では文脈のデータがないので，文脈をエンコードする部分は無視します．データセットはCLC + FCE-train + W&I-train + NUCLEを使います．2段階目はCLCデータセットを用いた文書単位のデータで訓練し，3段階目はFCE-train + W&I-train + NUCLEの文書単位のデータでfine-tuningします．

BaselineとSingleEncのモデルもCLCで訓練し，FCE-train + W&I-train + NUCLEでfine-tuningします．BaselineとSingleEncは，訓練時に文単位のデータと文書単位のデータを混ぜることはしません．

結果

結果は，MultiEnc-Decが全ての評価データで最高の $F _ {0.5}$ を示しました．BEA-devではMultiEnc-encと違いはほぼありませんが，FCE-testとCoNLL-2014では性能が向上しているため，デコーダがより文脈を捉えられていそうだということでした（Table 1）． f:id:gotutiyan:20210724135723p:plain

また，3段階の訓練におけるAblation studyの結果，pre-traningもfine-tuningも性能向上に寄与しているため，どちらも必要だということでした（Table 2）． f:id:gotutiyan:20210724140930p:plain

それから，入力する文脈は前後1~2文程度で良いそうです（Figure 2）．BEA-devとFCE-testでは前後1文を考慮するのが最も性能がよく，CoNLL-2014では前後2文を考慮することが最も良いそうです．CoNLL-2014は他のデータセットに比べて1文書あたりの文数が2倍くらいあるので，より広い文脈の考慮が効いたのではと分析しています．また，使う文脈は長ければ良いというものではないこともわかります． f:id:gotutiyan:20210724143745p:plain

エラータイプ別の分析では，主語動詞の一致，動詞の時制，代名詞のエラータイプが顕著に解けるようになっていました．他にも，トピックに依存した語彙選択もうまくできた例があったようです．例えば，motorcycleに乗る人を指す単語としてはcyclistsよりもriderのほうが適切ですが，提案手法はriderを選択できています（Table3のExmaple (b)）． f:id:gotutiyan:20210724142117p:plain

最後に，従来のNMT-basedなモデルとの比較を行っています．評価データとして文単位のCoNLL2014，尺度をM $^ 2$ スコアラとして比較すると，提案手法は高いPrecisionを達成しており，FCE-testでは最高性能を達成しました．提案手法は擬似データを用いていませんが，擬似データを用いている先行研究と匹敵する性能を達成しています． f:id:gotutiyan:20210724143900p:plain

実装

文書単位の評価データを作るツールが公開されています． github.com

モジュールとしてerrantが必要です．

pip install errant

もしspacyの英語データが無いよ的なエラーが出たら

python -m spacy download en

として英語データを取ってこれば動きました．

2021-07-08

論文メモ：NAACL2021, Comparison of Grammatical Error Correction Using Back-Translation Models

論文メモ

NAACL2021，Comparison of Grammatical Error Correction Using Back-Translation Modelsの論文メモです．

@inproceedings{koyama-etal-2021-comparison,
    title = "Comparison of Grammatical Error Correction Using Back-Translation Models",
    author = "Koyama, Aomi  and
      Hotate, Kengo  and
      Kaneko, Masahiro  and
      Komachi, Mamoru",
    booktitle = "Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Student Research Workshop",
    month = jun,
    year = "2021",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://aclanthology.org/2021.naacl-srw.16",
    doi = "10.18653/v1/2021.naacl-srw.16",
    pages = "126--135",
}

ACL Anthology:
https://aclanthology.org/2021.naacl-srw.16/

概要

文法誤り訂正（GEC）では，データ不足を補うために擬似データ生成が行われています．擬似データの生成手法は逆翻訳の手法が主流であり，アーキテクチャは誤り訂正モデルと逆翻訳モデルで同じものが使われてきました．しかし，逆翻訳モデルには様々なアーキテクチャが適用可能であり，アーキテクチャによる訂正の傾向の違いは分析されていません．そこで，逆翻訳モデルとしてTransformer，CNN，LSTMの3つのモデルを用いて，性能の違いや訂正の傾向を調べています．結果，逆翻訳モデルとして単一のアーキテクチャを使うよりも，複数を組み合わせたほうが性能が上がるということを確認しました．

GECにおける逆翻訳を用いた擬似データ生成

GECでは文法誤りを含む文から正しい文へ変換することを目的とするタスクです．近年ではこの変換を翻訳するとみなして，seq2seqなモデルで解くことが主流です．しかし，seq2seqなモデルの学習には大量のデータが必要なのにも関わらず，GECの学習データは十分にありません．そこで，データの擬似生成をします．逆翻訳はデータ擬似生成手法の一つで，正解文を入力として誤り文を出力するように訓練します（GECの逆方向）．こうして訓練した逆翻訳モデルの入力は正解文（誤りのない文）ですので，Wikipediaなどの単言語コーパスを入力すれば誤り文を擬似的に作ることができます．単言語コーパスは山ほどあるので，擬似データも大量に作れます．

実験

実験では，GECモデルは一種類に固定して，擬似データ生成のための逆翻訳モデルのアーキテクチャを変化させます．逆翻訳モデルはBEA-2019のtrainで訓練し，訓練後にWikipeadia（2020-07-06 dump file）から抽出した900万文を入力して擬似誤り文を生成します．アーキテクチャはTransformer，CNN，LSTMの3種類で実験します．また，異なるモデルの出力を合わせて1800万文とした擬似データや，seed値を変えた同じモデルの出力を合わせて1800万文とした擬似データでも実験します．評価はCoNLL-2014test，JFLEG，BEA-2019testの3つのデータセットで行います．

GECモデルはTransformerベースのEncoderDecoderモデルで，逆翻訳の手法で生成した擬似データ900万文（or 1800万文）で事前学習し，BEA-trainでfine-tuningします．また，ベースラインとして事前学習せず，単にBEA-trainのみで学習したモデルも訓練します．

結果

定量的な結果では，異なるモデルの出力を組み合わせた場合に最も性能が良いという結果になっています（Table2）．Table2の上のブロックは単一モデルから生成した擬似データで訓練したとき，下のブロックは複数のモデルが生成した擬似データを組み合わせて訓練したときです．

上のブロックではデータセットによって異なる逆翻訳モデルが高い性能を示しています． $F _ {0.5}$ やGLEUを見ると，CoNLL-2014ではTransformerが勝っていて，JFLEGとBEAではCNNが勝っています．近年ではTransformerが他のモデルよりも高い性能を出すことが多いですが，逆翻訳モデルに適用する場合には，必ずしもTransformerが良いとは限らないと主張しています．

下のブロックでは， $F _ {0.5}$ やGLEUで見るとCNN&CNNがJFLEGで1位，Transformer&CNNが他2つのデータセットで1位です．CNN&CNNやTransformer&Transformerはシード値を変えて生成した擬似データを混ぜたものですが，上のブロックで示されている単一のモデルに負けることがあります．例えば，CoNLL-2014のTransformerに注目すると，単一なら $F _ {0.5}$ が59.0ですが，シードが異なるものを混ぜると $F _ {0.5}$ が58.9と劣ります．例外的にJFLEGではCNN同士で混ぜたものが僅差で勝っていますが，全体としては異なるモデルが生成した擬似データを組み合わせたほうがロバストなGECモデルになるとの結論です． f:id:gotutiyan:20210708000032p:plain

BEAのtestにおけるエラータイプ別の性能も分析しています（Table3）．左のブロックは単一モデルでの性能です．逆翻訳モデルのアーキテクチャによって異なるエラータイプの性能が向上しています．しかし，PUNCTの誤り（Punctuation，カンマやピリオドなどの誤り）は他のエラータイプに比べてベースラインからの伸びが小さく，逆翻訳で生成した擬似データで解くのは難しいことを示唆しています．右側のブロックはモデルを組み合わせた場合の性能です．Table3に掲載されている14のエラータイプのうち，11のエラータイプに関しては，Transformer&CNNがCNN&CNNとTransformer&Transformerのどちらかには勝っている（=最下位ではない）ため，やはり異なるモデルが生成した擬似データを混ぜることでロバストなGECモデルになると主張しています．また，OTHERのエラータイプに注目すると，Transformer&CNNが突出して解けているので，多様な誤りの訂正に寄与するような擬似データが生成できていそうだという主張をしています．（ただ，同じモデルでもシードを変えることで性能にばらつきがあるエラータイプは，同一モデルを混ぜると性能が高くなるみたいな話も4節の終わりに書いてあります．） f:id:gotutiyan:20210708000114p:plain

考察

直感的にはたくさん生成されたエラータイプは性能が上がりそうですが，そうではなかったようです（Table4）．擬似生成されたトークン数と誤りの数がともに1位の逆翻訳モデルと，GECモデルの性能が1位であるような逆翻訳モデルが一致するエラータイプは14種類中6種類にとどまりました．

また，事前学習の時点で逆翻訳モデルによって性能の優劣があっても，fine-tuningすればそれが逆転する可能性があることも主張しています（Table5）．Table5ではBEA-testにおいてfine-tuningしたもの（w/FT）としなかったもの（w/oFT）の性能を比較しています．w/oFTにおいてLSTMはTransformerに $F _ {0.5}$ で7ポイント程度負けていますが，w/FTでは逆に0.1ポイント勝っています． f:id:gotutiyan:20210708000217p:plain

2021-07-04

論文メモ：EACL2021, How Good (really) are Grammatical Error Correction Systems?

論文メモ

EACL2021，How Good (really) are Grammatical Error Correction Systems? の論文を紹介してみます．

@inproceedings{rozovskaya-roth-2021-good,
    title = "How Good (really) are Grammatical Error Correction Systems?",
    author = "Rozovskaya, Alla  and
      Roth, Dan",
    booktitle = "Proceedings of the 16th Conference of the European Chapter of the Association for Computational Linguistics: Main Volume",
    month = apr,
    year = "2021",
    address = "Online",
    publisher = "Association for Computational Linguistics",
    url = "https://www.aclweb.org/anthology/2021.eacl-main.231",
    pages = "2686--2698",
}

ACL Anthology: aclanthology.org

概要

文法誤り訂正（GEC, Grammatical Error Correction）の参照あり評価（事前に用意した正解文を使って行う評価）では，用意された正解文が正解の集合を網羅できない問題がある．そこで，システム出力文をできるだけ変えないように人手で修正を加えて，それを正解文とみなして評価した．英語とロシア語のデータセットで評価した結果，GECシステムは従来報告されているよりも高品質な訂正が行えることを示唆した．また，10-bestの出力文の分析からは，下位のランクほど多様な訂正が行えていることを示唆した．

導入

現状の参照あり評価は，GECシステムの性能を過小評価していると主張しています．GECは入力文の誤りを発見して自動で訂正するタスクですが，訂正の候補は山ほどあります．現在使われているM² ScorerやGLEU，ERRANTのような評価指標はいずれも参照あり評価で，事前に用意された正解文をもとに評価しています．正解文は人手でアノテーションしており，データセットによっては一つの入力文に対して正解文が複数付与されることがありますが，前述したように正解の候補は大量にあるため全てを網羅できません．よって，現状の参照あり評価は，GECシステムが持つ本当の性能を評価できていないとしています．また，こうなる主な原因は，正解文がシステム出力とは独立に作成されているから，とも主張しています．

手法

前述した問題は，システム出力から正解文を作ることで解決します．こうして作られた正解文もまた入力文に対応する正解の集合に属するため，本来は評価されるべき部分が評価されると言えます．論文中では，このように作成した正解文をClosest Golds (CGs)と呼んでいます．これと対応して，元からアノテーションされている正解文はReference Gold (RG) と呼んでいます．また，システム出力の10-bastに対して検証します（本当は1,2,5,10番目ですが）．

CGsは，入力文とシステム出力文を見ながら，入力文の意味を損なわず，かつ，システム出力文との編集距離ができるだけ小さくなるように作ります．形式的には，入力文を $S$ ，10-bestの出力文を順に $H_1, H_2\dots H_{10}$ とすると， $(S,H_i)$ の組みを見ながら，対応する $CG_i$ を作ることになります．結局，全体的としては， $S,H_i,RG,CG_i$ のセットが得られる感じです．

実験

実験は英語のデータセットとロシア語のデータセットで行っています．英語データセットはCoNLL-2014とBEA test，ロシア語のデータセットはRULEC-GECとlang-8 コーパスのロシア語の文です．GECモデルは，英語にはBERTベースのモデル，ロシア語にはTransformerベースのSoTAモデルを使います．

$CG_i$ は， $i=1,2,5,10$ について作ります．つまり，ある入力文に対してGECシステムが1,2,5,10番目だと推定した4つの出力文について，それぞれを人手で編集して $CG_i$ を作ります．入力文は，各データセットから100文ずつランダムに取ります． $CGs$ のアノテーションは，英語ではネイティブと非ネイティブの2人，ロシア語は1人のネイティブが行います．3人とも修士号を有しており，過去にアノテーションの経験があるそうです．

結果

モデルの出力は $RG$ に対して最適化されていることを主張しています（Figure2）．まず， $RG$ に（赤色）に注目すると $H_1$ から $H_{10}$ にかけてスコアが減少していて．かつ， $H_1$ と $H_2$ の差が特に大きく開いています．一方で， $CG$ （青色）に注目すると， $RG$ ほどその傾向は表れていません．つまり，モデルの出力文でランクが高いものでも低いものでもやっている訂正は高品質だということです．

f:id:gotutiyan:20210704140051p:plain

また，訂正が行われる数に注目すると，ランクが低い出力文ほど多くの訂正を行っており，かつ，RGに対する性能値とCGに対する性能値の差が大きくなることを示しています（Table2）．つまり，ランクが高い出力文ほどRGに近いような訂正をするようにフィットしていることが言えます．（まあtrainもtestも人が正解文をつけているので，trainにフィットさせたモデルが自信を持って出力する文はtestの正解（RG）にもフィットするだろうというのは自然な気はします．）

f:id:gotutiyan:20210704140142p:plain

次に，編集率（Edit Rate）に注目した結果も分析しています（Table3）．ここでは主にpost-editと呼ばれる，正解文であるCGとシステム出力文の間の編集距離として定義された値を計算しています．結果として，英語のデータセットではランクによるpost-editに大きな違いはなく，ロシア語のデータセットでは $H_5$ や[tex:H{10}]はわずかにpost-editが大きくなっているが， $H_1$ と $H_2$ の差は特にないという結果になっています．ロシア語のデータセットでは $H_5$ や[tex:H{10}]でpost-editの値が大きくなりますが，大幅に劣化しているわけではないので，やはり下位のランクの出力文も高品質ですねという結論です．

f:id:gotutiyan:20210704140202p:plain

最後に，英語のデータセットで出力文のランクにおける訂正傾向の違いについて調べた結果は，低いランクの出力文ほどLexical（語彙的）な訂正を行っていることを示唆しています．Table5では上のブロックがスペル誤り/文法誤りでグルーピングした誤りタイプを，下のブロックがLexicalな誤りでグルーピングした誤りタイプを示しています．Table5最下部のパーセンテージを見ると， $H_1$ よりも $H_{10}$ のほうがLexicalな誤りを多く含んでいることがわかります．つまり，実は低いランクの出力文のほうが多様な誤りを訂正できているのではないかということです．

f:id:gotutiyan:20210704140214p:plain

考察など

DiscussionはConclusionみたいになっていますね．3つくらいの主張にまとめています．1つ目は，やはり現状の GECシステムってみんなが思ってるより高性能だよ，ということ．2つ目は，10-bestで1番になっている訂正はRGに寄っているので数値上は最も高品質に見えるが，下位の出力も高品質で，場合によってはトップの出力が負けることもあるということ．3つ目は，10-bestで下位の出力文は，多様な訂正をしているということです．

2021-01-30

【Pytorch】 EarlyStoppingを実装する

pytorch 機械学習・深層学習

はじめに

本記事ではpytorchでEarlyStoppingを実装する方法を紹介します．EarlyStoppingはいくつか実装方法がありますので，そのうちの一つを扱います．

おさらい: EarlyStoppingとは

深層学習における教師あり学習では，訓練データを用いて学習を行いますが，やりすぎると過学習してしまいます．過学習を起こしているときは，訓練データのlossは減少する一方で，汎化性能が下がるため開発データのlossは増加することが予想されます．よって，開発データのlossを眺めつつ，増加傾向にあれば学習を打ち切るような工夫をします．このような工夫をEarlyStoppingと呼びます．

使用するリポジトリ

今回は以下のリポジトリの実装を使います．

github.com

上記リポジトリをcloneするか，cloneが面倒であれば pytorchtools.py だけコピーし，手元に準備します．これ以降，from pytorchtools import EarlyStoppingのようにインポートすることになります．pytorchtools はpipにも存在しますが中身が異なるため，必ず上記リポジトリのpytorchtools.py を手元に置き，インポートする形にしてください．

この実装では，開発データの最小lossに注目し，最小lossが更新されているかということを打ち切る基準にします．最小lossが順調に更新されていれば学習を続けますし，一定のエポック数が経過しても更新できなければ打ち切ります．

実装

最小限構成

まずは，最小限の構成として以下のようなコードを書いてみます．

from torch import nn
from pytorchtools import EarlyStopping

# 適当なモデル
class Model(nn.Module):
    def __init__(self):
        super(Model, self).__init__()
        self.Linear = nn.Linear(1, 1)
    
    def forward(self, x):
        pass

# インスタンス作成
model = Model()
early_stopping = EarlyStopping(patience=3)
# loss（だと思っている値）のループ
for val_loss in [5, 4, 3, 2, 1, 2, 3, 4, 5, 6]:
    print('val_loss:', val_loss)
    early_stopping(val_loss, model)
    if early_stopping.early_stop:
        print("Early Stopping")
        break # 打ち切り

まずはモデルのインスタンスと，EarlyStoppingのインスタンスを作ります．今回は3回連続で最小lossを更新できなかった場合に打ち切ることにするので，patience=3とします．モデルは何らかのパラメータを持つ必要があるので，適当にLinear()を持たせています．

続くfor文では，開発データのlossのつもりで値をループしています．序盤は5,4,3,2,1とlossが減少しますが，途中で過学習が起こって2,3,4,5とlossが増加する状況を想定します．lossが得られるたびに，early_stopping(val_loss, model)として，lossとモデルのインスタンスを渡します．

EarlyStopping はメンバ変数に .early_stop を持っており，打ち切るべきだと判断すれば True になります．if文でこれを確認し，True であればbreakしてエポックのループを打ち切ります．

実行すると以下のようになります．

val_loss: 5
val_loss: 4
val_loss: 3
val_loss: 2
val_loss: 1
val_loss: 2
EarlyStopping counter: 1 out of 3
val_loss: 3
EarlyStopping counter: 2 out of 3
val_loss: 4
EarlyStopping counter: 3 out of 3
Early Stopping

3回連続で最小lossを更新できなかったので，打ち切られたことが確認できます．

これと同時に，最小lossを達成するようなモデルがcheckpoint.ptというファイル名で保存されています．ファイル名は後述するオプションで変更可能です．

実践的な例

実践的な例に関しては，同リポジトリのMNIST_Early_Stopping_example.ipynbが非常に参考になります．このノートブックでは，ざっくり以下のような形でEarlyStoppingが使われています．

early_stopping = EarlyStopping(patience=20)
for エポック数:
    for 訓練データのミニバッチ:
        モデルの訓練
    
    for 開発データのミニバッチ:
        開発データのミニバッチlossを計算，リストに保存
    early_stopping(開発データのミニバッチlossの平均値, モデル)
  if early_stopping.early.stop:
    break # 打ち切り

訓練データのミニバッチを一周するたびに開発データのlossを計算します．開発データのlossはミニバッチ単位で複数得られるため，それらの平均値で打ち切るかどうかを判断します．

オプション

early_stopping = EarlyStopping()でインスタンスを作る際には，オプションで以下のような設定ができます．

patience= （デフォルト: 7）

開発データのlossが何回連続で最小lossを更新できなければ打ち切るか指定します．例えば，patience=3 であれば，最小lossを3回連続更新できなければ打ち切ります．

verbose= （デフォルト: False）

普通，特別な出力があるのは開発データの最小lossを更新できなかったとき（悪くなったとき）の

EarlyStopping counter: 1 out of 3

みたいな表示だけですが，verbose=Trueのもとでは，最小lossを更新したとき（良くなったとき）にも以下のようなメッセージを出力します．

Validation loss decreased (5.000000 --> 4.000000).  Saving model ...

delta= （デフォルト: 0）

lossが前回からいくつ減少すれば良くなったと判断するか設定します．デフォルトは 0 なので，最小lossから少しでも値が減少していれば良くなったと判断します．一方で，仮に delta=0.1 に設定した場合，最小lossから 0.1以上減らないと，最小lossを更新したとみなされません． deltaを大きくすればするほど，打ち切られやすいと解釈できます．

path= （デフォルト: 'checkpoint.pt'）

最小lossが更新された際にモデルが保存されるパスを指定します．

おわりに

今回はPytorchでEarly Stoppingを実装する方法を紹介しました．今回紹介したライブラリは一例に過ぎません．他にもpytorchのigniteというライブラリ群にEarly Stoppingの実装があったりします．お好みのものを探して使ってみてください．