Gitの使い方
ローカルブランチのブランチ名の変更
git branch -m <変更したいブランチ名> <変更後のブランチ名>
checkout中のブランチ名を変更する場合
git branch -m <変更後のブランチ名>
Language Models as an Alternative Evaluator of Word Order Hypotheses: A Case Study in Japaneseを読んだ
概要
日本語の語順の評価をLanguage Model(LM)を用いた生成確率で比較する方法を提案。人間が評価する手法や、既存の頻度ベースの評価手法と同様の結果が得られることを実験で確認している。
リンク
用語
用語 | 意味 |
---|---|
NOM | nominativeの略。主格のこと |
DAT | dative caseの略。与格のこと。 |
ACC | accusative caseの略。対格のこと。 |
背景
文章の語順の評価方法としては、人間が実際に確認して評価する方法や、大規模なコーパスから頻度集計を行ったものを用いて評価する方法がある。人間が行う評価ではスケーラビリティに問題があり、頻度ベースの手法では前処理の段階でエラーが発生するといった問題がある。
Language Modelを用いた英語の語順の評価については既往研究があるが、日本語のような柔軟な語順でも成立する言語でも成り立つかどうかは検証されていない。
提案手法(LM-based method)
正しい語順の場合、Language Model(LM)の文の生成確率が最も高くなるという仮定に基づいて評価を行う。
文 の生成確率は以下を用いる
:left-to-right LMで算出した生成確率
:right-to-left LMで算出した生成確率
※ LMに用いられているTransformerは文全体の生成確率は出せない気がするので、生成確率は各単語の生成確率の累積ではないかと思われる。fairseqの論文を読んだほうが良いのかもしれないが未調査。
LMにはTransformerを用いる(auto-regressive, unidirectionalなのでBERTではない)。fairseqで実装されたものを用いた。
LMはCLMとSLMの2種類のそれぞれを評価する。
CLM:character-based LM
SLM:subword-based LM
subwordはUniDic辞書を用いたMeCabで形態素解析を行い、byte-pair-encodingで行う。
LMの学習は、3B web pageからランダム抽出した160M文を用いて行う。dev用に10K文を切り出す。adaptive softmax cutoffはSLMにのみ適用する。
ハイパーパラメータは以下のTable 5参照。
学習後のperplexityはleft-to-right CLMが11.05、right-to-left CLMが11.08、left-to-right SLMが28.51、right-to-left SLMが28.25となった。CLMとSLMのperplexityの差はボキャブラリーサイズの違いに依存している。
LM-basedを使うメリットとしては、後置詞が削除されたような場合にユーザがどちらを好むかどうかの検証用のサンプルが作りやすい点である。
※ Language Models as an Alternative Evaluator of Word Order Hypotheses: A Case Study in Japaneseより引用
検証結果
Human-based methodとLM-based methodの比較
検証用のデータ作成
3B web pagesから10K文をランダム抽出。以下の条件に該当する文のみ使用する。
- 5句以下で、1つの動詞を持つ
- dependency treeに兄弟関係を持つ節があり、助詞や副詞を持つ
- 括弧などの特殊記号を持たない
- backward dependency pathを持たない
各文に対して以下のスクランブル処理を行い、語順を変更した文を作成する
評価方法
評価はYahoo Japan! のクラウドソーシングで実施。
作業者に元の文と語順を変更した文のペアを見せ、以下のどれに該当するかを選択してもらう。
(1)文1の語順の方が良い
(2)文2の語順の方が良い
(3)文1、文2に意味的におかしい文が含まれている
文1、文2のどちらが元の文かは作業者には知らされない。
作業者はcheck questionsを用いてunmotivated workersを除外した。
各ペアに対して10人の作業者に回答してもらい、誰も「(3)文1、文2に意味的におかしい文が含まれている」を選択していない、かつ、好ましい文の選択が9人以上一致しているペアのみ評価に用いる。選択した作業者が多い方の文を、好ましい語順とする。最終的に2.6Kペアを収集した。
上記の2.6Kペアの好ましい文とLM-basedで選択された好ましい文のピアソン相関係数を算出すると、クラウドソーシングとCLMの相関係数が0.89、クラウドソーシングとSLMの相関係数が0.90だった。
なお、こうした語順の直接比較はcount-basedだとコーパスのスパース性のため難しい。
Data-driven methodsとLM-based methodの比較
目的語が2つある場合
DATとACCがどちらが先にある方が好ましいかを検証する。
例:
DAT-ACC:生徒に 本を あげた
ACC-DAT:本を 生徒に あげた
Data-driven methodsとLM-based methodの比較指標として、動詞毎にACCが前、DATが後ろである場合の確率 を用いる。
以下の図はData-driven methodsとLM-based methodの をプロットしたもの(縦軸がLM-based method)。
その他の場合
実際はその他の場合ではなく、目的語の対格が無い場合や、副詞の位置がSOVの中でどこに現れるかなどで細かく場合分けして検証を行っている。
詳細は省略するが、全て既存のData-driven手法とLM-based手法との間で一貫性のある結果が確認できている。CLMとSLMのData-driven手法とのピアソン相関係数はそれぞれ0.91と0.88で、強い相関があることが分かる。
ImageBERT: Cross-modal Pre-training with Large-scale Weak-supervised Image-Text Dataを読んだ
概要
テキストと画像のマルチモーダルBERTの提案。Transformerの入力にテキストのtokenだけでなく、Faster-RCNNで検出したRoIをTransformerに入力できる形にEncodingしたvisual tokenも入力できるようにしてEmbeddingを行えるようにしている。
また、数億パラメータを学習するためには大量のデータが必要であるとし、Pre-training用に弱学習器を用いたデータセット作成方法を提案している。
リンク
pre-training用のデータセット(LAIT)の作成
LAIT(Large-scale weAk-supervised Image-Text)はpre-trainingを行うために著者らがWebから集めた画像とキャプションのペアのデータセット。
マルチモーダルのpre-trainingに用いられるデータセットはConceptual Captions(CC)とSBU Captionsが多い。しかし、CCは3M件の画像とdescriptionの組み合わせ、SBUは1M件の画像とユーザが作成したキャプションの組み合わせで、著者らの主張としては数億パラメータのモデルを学習するためには件数が少ない。 pre-trainingにはデータのボリュームと品質が重要なため、LAITはweak-supervised approachを採用し、10M件の画像とdescriptionのペアで構成される。descriptionは平均13単語。
weak-supervisedというのは、後述するデータ収集pipeline内のImage-Text Semantic Scoringでテキストと画像が関連したものかどうかスコアリングを行う弱学習器を構築しているためにと思われる。
data collection pipeline
データ収集のパイプラインの全体像はFigure 1を参照。
各処理の内容はその後に記載しておく。
Web-page collection
Webページをクロールし、画像URLとテキストを収集する。テキストが英語でないものと、画像がWebページに対してDominantでないものは廃棄される。Figure 1では何かしらの判定器を用いているようだが詳しい記載はなし。Dominant, Non-dominantについては定義がないため不明。
Image Content Based Filtering
画像情報を用いてフィルタリングを行う。画像の縦横が両方とも300ピクセル未満のものと、エロ画像(Pornographic or Racy)、non-realisticな画像、non-learn-ableな画像は除外される。non-realistic、non-learn-ableについては定義が記載されていないが、Figure 3を参照とのこと。画像判定器についても記載がないが、恐らくMicrosoftのありものを使っていると思われる。
Sentence Detection & Cleaning
画像に対応するdescriptionを取得する。descriptionにはHTMLのAlt属性やTItle属性、もしくは画像の周辺テキストを用いる。ヒューリスティックルールを用いてノイズを除去し、適切な長さにする。詳細は記載されていない
Image-Text Semantic Scoring
少量の画像とテキストのペアの教師データを用いて、テキストと画像のペアが関連しているものかどうかの2値分類を行う弱学習モデルを作成し、スコアリングを行う。モデルに用いる特徴量はテキストのみの素性、画像のみの素性、テキストと画像のクロスモーダルな素性を数百種類用いている。モデルに用いた手法や学習用のデータ件数については記載なし。
Image-Text Aggregation
異なるdescriptionが同じ画像に紐付いていたり、異なる画像が同じdescriptionに紐付いている場合があるので、これらを解消する。
複数のdescriptionが同じ画像に紐付いている場合は、前段のImage-Text Semantic Scoringのスコアが最も高いdescriptionと画像のペアのみ残す。
複数の画像が同じdescriptionを持つ場合は、これらのペアをコーパスから除外する。
LAITのデータセットのサンプルは以下のFigure 2を参照。
Architecture
提案手法の構造をFigure 4に示す。基本的な構造はBERTと同じで、TransformerのEmbeddingの構成要素となる"Sequence Position Embedding", "Segment Embedding", "Linguistic Embedding" のうち、Linguistic Embeddingに単語の代わりに画像のEncodingしたものと画像内の位置情報を渡すものである。(画像内のPositionが定義できないのでSequence Position Embeddingには画像の場合は同じ値を入れるという制約もあるが)
Image Embedding
Faster-RCNNで抽出されたregions of interest(RoI)を単語とみなしてEmbeddingを行う。
- ObjectEmbedding :RoI内の画像をEocodingしたもの
- SegmentEmbedding :テキストの時と同じ様にSegment単位で同じ値を入れてEncodingしたもの
- ImagePositionEmbedding :画像の位置情報のEncoding。位置情報は5次元で表される。(数式の入力だったので省略しました。原論文を見てください。相対位置と、相対面積を使ってます。)
- SequencePositionEmbedding :Segment内の順序のEmbedding。RoIの順序は明確に決まらないのでダミーとして全て同じ値を入れる。
i番目のRoIの最終的なEmbeddingは以下となる。はTransformerの隠れ層と同じembedding sizeにするためのLayer Normalization。
Pre-training
Pre-training task
Pre-trainingでは以下の4タスクを行う。
- Task 1: Masked Language Modeling (MLM)
- Task 2: Masked Object Classification (MOC)
- Task 3: Masked Region Feature Regression (MRFR)
- Task 4: Image-Text Matching (ITM)
Masked Language Modeling (MLM)
BERTで行っているMLMと同じ。
Masked Object Classification (MOC)
MLMの画像版。Faster-RCNNでRoIを検出した際に一緒に返却されるラベル(face, armなど)を正解とし、マスクしたRoIに対応するトークンのクラスを予測して学習を行う。Lossにはcross-entropy lossを用いる。
15%の確率でRoIをマスクし、マスクする際は90%の確率でタスクを行う対象のトークンとし、10%の確率で単に入力を0にする。
Masked Region Feature Regression (MRFR)
このタスクではマスクしたfeature embeddingの値を回帰で予測する。そのため、Transformerの出力層に全結合層を追加し、RoIの特徴ベクトルと同じ次元に変換する。LossにはL2 lossを用いる。
マスクする確率は恐らくMOCと同じと思われる。
Image-Text Matching (ITM)
textをランダムに別のペアのものと変換し、negative sampleを作成する。sequenceの先頭の[CLS]トークンの特徴量を用いて、negative sampleかどうかの2値分類を行う。
Lossにはbinary classification lossを用いる。
Multi-stage Pre-training
著者らが提案した手法で作成したデータセットLAITと、Conceptual Captions(CC)、SBUの3つでどの様にPre-trainingを行うのかを決めておく。
著者らは冒頭で数億パラメータを学習するためにはより大規模なデータセットが必要なので、LAITデータセットを作成したと述べていた。しかし、LAITのデータの品質はCC、SBUよりも劣るために段階を分けることにしている。
Pre-trainingではまずLAITデータセットで学習を行い(stage 1)、その後、CC、SBUを結合したデータセットで学習を行う(stage k+2)。
Stage 1のPre-trainingではk+1回のpretrainを行うように書いてあるが、実験では1回しかpretrainしてない。
検証結果
画像検索のタスクを用いて提案手法の性能評価を行う。
Transformerは12層、768 hidden units、3072 intermediate units、12 attention headのものを用いる。入力の最大長は144トークンで、100トークンはFaster-RCNNで抽出したRoIが入る。
Faster-RCNNは1600カテゴリに分類されたGenomeデータセットを用いる。
Pre-trainingではドロップアウトを10%の確率でGELUを用いて行う。バッチサイズは48、学習率は1e-4、最適化にはAdamを利用、4つのV100 GPUを用いて17エポック学習を行った。 fine-tune時はITMタスクだけ学習に用い、バッチサイズが24、学習率が5e-5、4つのV100 GPUを用いて130エポック学習を行った。
画像検索のタスクでの検証
MSCOCO、Flicker30kデータセットを用いて画像検索タスクを行う。MSCOCOは1kテストセット、5kテストセットの両方で検証を行う。 Image Retrievalはテキストを入力として画像を検索するタスク、Sentence RetrievalはImage Retvievalとは逆向きのタスク。
Pre-trainingの効果を検証するためのfine-tuneなしのZero-shotでの検証と、fine-tuneありの検証の両方を行う。
Zero-shot画像検索での検証結果はTable 1を参照。他の手法ではZero-shot画像検索の検証結果がないらしくて、結果の表がスカスカ…。
Flicker30kではUNITERに劣っているが、MSCOCOでは1kテストセットで最も良い結果。
fine-tune後の比較結果はTable 2を参照。
一応どの手法よりも良い結果になっているが、Zero-shotの時に負けていたUNITERと比べると大差ないので、そこまで大きな差はないと思われる。
Ablation Studies
Pre-trainingの各条件設定が性能にどのような影響があるのかを調べている。
Pre-train dataset
Pre-trainingに使うデータセットの違いによる比較。結果はTable 3を参照。LAIT、CC、CC+SBU、LAIT+CC+SBUは各データセットを結合してPre-trainingを行った結果。LAIT→(CC+SBU)は前述のMulti-Stage Pretrainingを行った場合の結果。評価はFlicker30kでZero-shot検索で実施。
Global image features
RoIの特徴量だけでなく、画像全体の特徴量もトークンとして追加した場合の検証。結果はTable 4のPart 1を参照。性能を改善する効果は見られない。
Pre-training loss
MRFRタスクの有効性を検証する。Pre-training時のlossにMRFRのlossも追加していない場合と追加した場合を比較。結果はTable 4のPart 2を参照。
大きな改善効果があることが確認でき、より難しいタスクを追加することが良いモデリングに繋がることが示されている。
Number of Objects(RoIs) from image
画像トークンとして利用するRoIを36個の場合と100個の場合を比較検証。RoIはFaster-RCNNが予測時に出力するconfidenceでソートし、高い順に採用する。36個はViLBERTと同じ個数らしい。結果はTable 4のPart 3を参照。
結果からRoIの個数が多いほうが精度が上がっていることが確認できる。
Fine-tune loss
Fine-tune時利用するlossの比較検証。結果はTable 4のPart 4を参照。
Binary classification lossのみを利用する場合の精度が最も良い。
Dockerfile内でconda activateする
公開されているコードを試す際、セットアップにconda activate xxxx
が必要な場合がある。
以下のissueを参考にconda activateした状態でインストールを行うことができたのでメモ。
Activating environment in dockerfile - related to #81 · Issue #89 · ContinuumIO/docker-images · GitHub
解決方法
Dockerfileに以下の様に記述する。myenvが仮想環境の名前。
FROM continuumio/miniconda3 # create myenv RUN conda create -n myenv python=3.6 # activate myenv ENV CONDA_DEFAULT_ENV vilbert-mt # env setting(こちらはコンテナに入った時のため) RUN echo "conda activate myenv" >> ~/.bashrc ENV PATH /opt/conda/envs/vilbert-mt/bin:$PATH
その他の解決方法
conda run を使う方法
こちらの記事を参考にした。こちらでもactivateが適用された状態でインストールができることは確認済み。ただし、コンテナを起動した際の環境は baseのままになる。
Activating a Conda environment in your Dockerfile
Dockerfileに以下のように記述する
FROM continuumio/miniconda3 RUN conda create -n myenv python=3.6 SHELL ["conda", "run", "-n", "myenv", "/bin/bash", "-c"]
conda activateと&&で接続して行う方法
冒頭のissueに書いてあるもの。RUNは実行毎に独立しており設定が引き継がれないので、conda activateしても次のRUNではactivateされていない状態で処理が行われるらしい。
それを回避するためにスタックして書けば良いとのこと。
FROM continuumio/miniconda3 RUN conda create -n myenv python=3.6 RUN /bin/bash -c ". activate myenv" && \ pip install pandas && \ pip install ../mylocal_package/
PyTorchでout of memoryになる
推論時に徐々にメモリ使用量が増えてout of memoryになる
推論時にout of memory になった。
out of memoryになったコードのイメージ。
for batch in dataloader: inputs = {"input_ids": batch[0]} outputs = model(**inputs)
出力されたエラー。
GPUのメモリ使用量をモニタリングすると、ループする度に使用するメモリ量が増えていき、out of memoryになる。
RuntimeError: CUDA out of memory. Tried to allocate 20.00 MiB (GPU 0; 15.78 GiB total capacity; 14.43 GiB already allocated; 19.12 MiB free; 268.73 MiB cached)
解決策
with torch.no_grad():
を付ける。
(detachingでもよいが、lossが不要ならこっちのほうが簡単)
修正後のコードのイメージ。
with torch.no_grad(): for batch in dataloader: inputs = {"input_ids": batch[0]} outputs = self.model(**inputs)
以下の投稿を見ると、lossのdetachもしくはwith torch.no_grad():
でラップのどちらも行っていない場合、loss Tensorがcomputation graphを保持し続けるためにiteration毎にメモリ使用量が増加するとのこと。
Supervised Multimodal Bitransformers for Classifying Images and Textを読んだ
概要
BERTをベースにしたテキストと画像のマルチモーダルネットワークを提案。画像をResNet-152でベクトルに変換した後に、average poolingで作成したN個のベクトルをtokenとしてBERTへ入力する。単一モーダルのBaselineや、BERTとResNet-152のベクトルを単純に結合したモデルよりも若干だが高い精度がエられることを示している。
arXivによるとEMNLP 2019でrejectされている。
リンク
arXiv
pdf
facebook researchのGitHub
huggingface/transformersの実装
Architecture
著者らはMultimodal Bitransformersと呼んでいるが、画像をN個の分割された特徴ベクトルに変換したものを単語tokenとみなしてBERTの入力としていると考えれば良い。 Architectureの全体像は以下のFigure 1を参照。
token
tokenはtextはtorkenizeされたものを用いる。
Imageの方はResNet-152を利用してencodeしたものを用いるが、ResNetの出力をそのままtransformerの入力にできないので変換を行う(変換方法は下図参照)。Average Poolingは1つの画像ファイルを複数のtokenに分割するもので、Affine Layerは次元数をBERT内のembeddingの次元数に合わせるためのもの。
[CLS]や[SEP]などの特殊トークンは恐らく挿入されていない(論文中に表記が見当たらなかったため)。
huggingface/transformersの実装を確認すると、Average Poolingの出力次元数は以下の通り。
N | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
K | 1 | 2 | 3 | 2 | 5 | 3 | 7 | 4 | 3 |
M | 1 | 1 | 1 | 2 | 1 | 2 | 1 | 2 | 3 |
segment
segmentは1つ目は0、2つ目は1にする(BERTと同じ)。
V-SNLIでは入力がテキストが2つと画像1つとなるため、segmentが2を超える。pretrain済みのBERTはsegmentが2つなので、segmentが2以上の場合は以下の数式でsegment embeddingを作成する。
where
classification
クラス分類では最終層の0 token目の出力を用いる。
最終層の出力をとすると、classification layerは where となる。Dはtransformerの次元数、Cはクラス数。
multilabel分類の場合は1つ以上正しい答えがある場合はシグモイド関数を適用してbinary cross-entropy lossを各出力クラスに対して算出し学習を行う(予測の場合は閾値を0.5とする)。
multiclass分類の場合はsoftmaxを適用し、regular cross-entropy lossを算出して学習を行う。
結果
検証用データセット
MM-IMDB
映画のプロットの要約、映画のポスター、ジャンルがセットになっている。タスクではプロットの要約(text)とポスター(image)を与えて、ジャンルを予測する。
FOOD101
レシピの説明文とメイン画像、ラベルのセットになっている。レシピ説明文(text)とメイン画像(image)を与えてラベルを予測する。
V-SNLI
前提(text)、仮説(text)、画像(image)とラベルのセット。前提(text)、仮説(text)、画像(image)を与えられた時のラベルが"entailment(仮説が正しい)"、"neutral(どちらともいえない)"、"contradiction(仮説が矛盾)"のいずれになるかを予測する。
MM-IMDBとFOOD101はtext1つとimage1つが入力だが、V-SNLIのみtextを2つとimage1つを入力としてクラス分類を行う。
データセットの例はTable 2を参照。
Baseline
クラス分類は各手法でencodeしたものを素性として、1層のネットワークで行う。
Bag of Words(BoW)
textの全単語をGloveで300次元に変換し、合計したものを素性として用いる。
imageはクラス分類に利用しない。
Text-only BERT(BERT)
textを入力として、事前学習済みのbase-uncased BERTの出力を素性として用いる。
imageはクラス分類に利用しない。
Image-only(Img)
標準的な事前学習済みのResNet-152とsingle average poolingの出力を素性として用いる。各画像は2048次元のベクトルになる。
textはクラス分類に利用しない。
Concat Bow + Img(ConcatBow)
BaselineのBowとImgのベクトルを結合したものを素性として用いる。
素性は300(Bow)+2048(Img)=2348次元になる。
Concat BERT + Img(ConcatBow)
BaselineのBERTとImgのベクトルを結合したものを素性として用いる。
素性は768(BERT)+2048(Img)=2816次元になる。
検証用データセットでの精度
乱数シードを変更して5試行を実施し、平均を取った結果がTable 3。 一応提案手法が一番精度が良いが、数ポイントしか変わらない。
Hard Subsetsでの検証
マルチモーダルの検証ではテキストの素性が支配的になり、異なるマルチモーダルの手法を正しく比較したり、マルチモーダルを組み込む価値があるのか評価することが困難になる場合が多い。そのため、著者らはテキストの素性が支配的にならないサブセットを作成し、精度検証を実施している。
hard ground-truth
BowとImgのそれぞれの予測結果がground truthの結果から最も異なるデータをサブセットとする。例えば、 の上位10%をサブセットとする。は予測されたクラス、は正解のクラス、は画像情報、はテキスト情報。
disagreement
BowとImgの分類結果が異なるもののうち、最も結果が異なるものの上位10%をサンプリングしてサブセットとする。
上記のhard ground-truthは予測と正解が異なることを基準にサンプリングしており、こちらはTextとImageのそれぞれの予測結果が異なることを基準にサンプリングしている
V-SNLI(hard) (Gururangan et al. 2018)が作成した、テキスト情報のみでは分類が困難だったサブセットを用いる
hard ground truth, disagreementはMM-IMDBとFOOD101でのみサブセットを作成し、V-SNLIでは(Gururangan et al. 2018)のサブセットのみを使用。
評価結果は下記のTable 4を参照。
※ hard subsetは難しいサンプルをサブセットとしているので、データセット全体を対象に評価する場合よりも精度が下がることが予想される。しかし、データセット全体での評価(Table 3の結果)よりも精度が高い理由が不明。論文中には特に記載なし。
MM-IMDB Hard (ground truth)で実際にクラス分類した場合の差はTable 5を参照。 ムーランをImgがAnimationを予測できないのはちょっと意外。
weightのfreezing
pretrainした重みを、学習初期にfreezingしておくことがどうかの分析を行った(画像の埋め込み数は固定にしておく)。
Figure2はTextとImagそれぞれを学習の何エポックまでfreezingしておくかを軸に取ったもの。セルの数値は論文中に記載が無いが恐らくMicro-F1。
Figure2を確認すると、Imageの重みはfreezingしておくエポック数が少ない方が効果的なことが分かる(できるだけ最初からunfreezingしておいた方が良い)。textの重みのfreezingしておくエポック数はタスクに依存している。