9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

TL;DR

日本語リソースで学習した DeBERTa V3 モデルを公開した。

以下のような特徴を持つ:

  • 定評のある DeBERTa V3 を用いたモデル
  • 日本語特化
  • 推論時に形態素解析器を用いない
  • 単語境界をある程度尊重する (の都合上の判定負けを喫し のような複数語のトークンを生じさせない)

はじめに

OpenAI 社から ChatGPT が登場した 2022 年以来、自然言語処理 (NLP) の、あるいは機械学習全体の、さまざまな課題に大規模言語モデル (LLM) を適用する動きが活発化している。 LLM の文脈を読む力は、タスクによっては人間にも匹敵し、有用性が高い。 Meta 社の LLaMA を皮切りに、オープンなモデルも雨後の筍のように次々と登場しており、応用可能な範囲は日進月歩で拡大している。

一方、一般的な LLM と共通する Transformer アーキテクチャを持つ BERT は、 2018 年当時の自然言語処理界隈を席巻したが、 LLM の隆盛により影が薄くなっている。しかしながら、 BERT 系のモデルは、タスク次第では LLM より数桁少ないパラメータ数で LLM と同等以上の性能を示すこともあり、現在でも一定の需要が存在すると考えられる。特に DeBERTa は、英語や多言語の性能で評価が高く、例えば、予測モデリング技術を競うプラットフォームである Kaggle においては現在でもよく採用される。公開されている日本語 DeBERTa モデルは、ある程度以上の規模で事前学習されたものに限れば、我々が学習時点で確認した範囲では DeBERTa V2 に留まり、事前学習方法がアップデートされた DeBERTa V3 のものは存在していなかった (後述の通り、現在は存在する)。

我々、グロービス経営大学院の学内シンクタンク「グロービスAI経営教育研究所」では、国内最大のビジネススクールのノウハウと、企業の人材育成や組織変革など教育現場から得られる知見と、AI(人工知能)をはじめとするデジタルテクノロジーや認知科学の発展がもたらすイノベーションを統合した次世代経営教育モデルを研究開発している。
我々は研究開発の一環として DeBERTa V3 の手法を用いて独自の日本語事前学習モデルを構築した。その成果物を Hugging Face で公開する。

モデル

BERT 系 (エンコーダベース) モデルとして DeBERTa V3 を採用した。
DeBERTa は、 “Decoding-enhanced BERT with Disentangled Attention” の略であり、一般的な Transformer がサブワードの内容 (Content) に対して注意機構を適用しているのに対し、相対位置 (Position) にも適用することで、コロケーションをより考慮することができる。
DeBERTa V2 は、 DeBERTa にアーキテクチャの小さな変更を含むいくつかの改良を施したものである。
DeBERTa V3 はさらに、アーキテクチャをそのままに、学習方法を BERT の手法 (MLM; Masked Language Modeling) から ELECTRA の手法 (RTD; Replaced Token Detection) に変更したものである。一部のトークンをマスクした系列から元のトークンを推測し穴埋めする MLM に対して、 RTD では MLM で穴埋めした系列に対してどのトークンが穴埋めによって生成されたものかを予測する。 MLM ではマスクされていたトークンのみを対象に勾配計算するが、 RTD では全てのトークンに対して勾配計算するので学習効率が高いというのが主張である。

トークナイザ

工藤氏によって示された手法で学習した。

以下のことを意識している:

  • 形態素解析器なし
  • トークンが単語の境界を跨がない
  • Hugging Face で使いやすい
  • 大きすぎない語彙数

形態素解析器なし

形態素解析器を用いる場合、BPE (byte-pair-encoding) など、語の意味や役割を考慮しない頻度ベースのサブワード分割方式と比べると、直感的には精度においてメリットがあると考えられる。一方で形態素解析器を別途インストールする必要が発生する上、厳密に運用するためには形態素解析器の辞書を学習時と推論時で合わせる必要があり、運用が難しくなる。
性能について、小規模な学習で確認した限りにおいて特に差は確認できなかったので、本モデルは SentencePiece のみによるトークン化を行なった。

トークンが単語の境界を跨がない

例えば、固有表現抽出 (NER) やシーケンスラベリングのような単語境界に意味があるタスクにおいては、トークンが境界を跨がない方が都合が良い。複合語の理解やトークン数の削減という意味では単語境界にとらわれないことのメリットが存在するが、ここでは単語境界を尊重する選択をした。単語の辞書として unidic-cwj-202302 を用いる。

Hugging Face で使いやすい

Hugging Face は機械学習モデルやデータセットを共有するプラットフォームのデファクトスタンダードとなっている。事前学習したモデルを広く公開するに当たって Hugging Face で使いやすいようにモデルやトークナイザを構成することの重要性は高い。
Hugging Face のライブラリ transformers の実装をそのまま使えるように構成することに加えて、本学習では offsets mapping 機能が使えるように注意した。 offsets mapping が使えると、各トークンが元のテキストのどの位置であったかを容易に特定できる。 BERT 系の日本語モデルでよく採用される BertJapaneseTokenizer では offsets mapping が使えない。 DeBERTa のトークナイザは Rust で実装された Fast 版では offsets mapping に対応しているが、 Fast 版は SentencePiece を再実装したものであるため、本家の SentencePiece とは挙動が異なる。特に未知語を UTF-8 のバイト列で表現する byte fallback への対応は tokenizers (Hugging Face によるトークナイザライブラリ) v0.14.0以降となっており、学習時点では対応していなかった。
本学習では byte fallback を諦め、 Fast 版のトークナイザを利用している。

大きすぎない語彙数

本家の DeBERTa V3 は大きな語彙数で学習されていることに特徴があるが、反面埋め込み層のパラメータ数が大きくなりすぎる (microsoft/deberta-v3-base モデルの場合で埋め込み層が全体の 54%) ことから、本モデルでは小さめの語彙数を採用している。

その他

語彙数などは次のとおり:

Model Vocab size algorithm
globis-university/deberta-v3-japanese-xsmall 32,000 unigram
globis-university/deberta-v3-japanese-base 32,000 unigram
globis-university/deberta-v3-japanese-large 48,000 BPE

注意点として、 xsmallbaselarge の 3 つのモデルのうち、前者二つは SentencePiece の unigram アルゴリズムで学習しているが、 large モデルのみBPEアルゴリズムで学習している。
深い理由はなく、 large モデルのみ語彙サイズを増やすために独立して学習を行ったが、なぜか unigram アルゴリズムでの学習がうまくいかなかったことが原因である。
原因の探究よりモデルの完成を優先して、 BPE アルゴリズムに切り替えた。

訓練データ

訓練データ 1 エポック分を構成するデータは表の通り:

Dataset Name Notes File Size (with metadata) Factor
Wikipedia 2023/07; WikiExtractor 3.5GB x2
Wikipedia 2023/07; cl-tohoku の手法 4.8GB x2
WikiBooks 2023/07; cl-tohoku の手法 43MB x2
青空文庫 2023/07; globis-university/aozorabunko-clean 496MB x4
CC-100 ja 90GB x1
mC4 ja; DSIR で Wikipedia 類似データを 10% 抽出 91GB x1
OSCAR 2023 ja; DSIR で Wikipedia 類似データを 20% 抽出 26GB x1

Wikipedia / WikiBooks

Wikipedia は NLP において一般に品質の高いデータソースとして扱われる。ゆえに、本学習では 4 倍量の Wikipedia データを用いている。 Wikipedia は MediaWiki の書式で記載されていることに加え、メタ情報を含むことから、事前処理によって不要な文字列を削除する必要がある。
テキスト抽出の手法としてよく使われているものとして WikiExtractor があるが、特に日本語のテンプレート展開に弱いので、発音記号など一部のデータが破損する (例: コミンフォルム(, )、正式名称は共産党・労働者党情報局()は、)。一方、東北大学が公開している日本語 BERT では CirrusSearch のダンプデータを元にヒューリスティクスを適用することでテキストデータを得ているが、箇条書きやメニューなど、一部消しきれていない文字列が散見される (例: 世界遺産 文化遺産 (世界遺産) 自然遺産 (世界遺産) 複合遺産 (世界遺産) 危機にさらされている世界遺産)。
本学習ではどちらも 2 回ずつデータセットに加えて、 4 倍量を利用した。

青空文庫

globis-university/aozorabunko-clean として、我々が Hugging Face で公開しているデータを4倍量用いた。ただし、文字遣い種別新字新仮名 のものに限って用いている。

CC-100

Common Crawl のデータから構成された多言語データセットで、日本語部分を用いた。 Common Crawl ベースのものとしては日本語の品質が比較的高い。

mC4

CC-100 と同様、 Common Crawl のデータから構成された多言語データセットだが、手法が異なる。日本語の質は低く、一瞥しただけで大量のアダルト・広告コンテンツや、 Web ページ内のナビゲーションメニューなどが確認できる。
原因の一つとして、 mC4 は LDNOOBW による NG ワード処理をしているが、中国語およびタイ語をスペース区切りではない言語として例外処理をしている一方で、日本語ではされていないことが考えられる。

本学習では、 DSIR (Data Selection with Importance Resampling) という手法で Wikipedia に類似するデータを日本語パートから 10% サンプリングした。

ここで、 DSIR は unigram と bigram の bag-of-ngrams モデルで、各文書 i に対して p / q (ここで、p は目標コーパスでの生成確率、q はフィルタリング対象コーパスでの生成確率) を計算し、 Gumbel top-k サンプリングによってフィルタリングを行う手法である。単純な bag-of-ngrams では ngram の数が多く次元数が大きくなりすぎるが、適当なハッシュ関数で 10000 次元程度に減らす工夫がなされている (本学習では 16384 次元とした)。

なお、 DSIR の論文では 128 語までのチャンクにして p / q を計算しているが、系列 (文書) の長さを制限しない場合、短くて目標コーパスによく似ている文書よりも、長くて少ししか似ていない文書の方が p / q が高くなってしまい、都合が悪い。そこでヒューリスティックとして log(p / q) を文書中の ngram 数で割って正規化し、サンプリングの際に Gumbel 分布のスケールを 0.01 に設定して調整した。(サンプリングをしなくても目標コーパスに似た文書を集めるという目的は達成できるため、本学習ではスケール値を重要視しておらず、故にハイパーパラメータチューニングはしていない。)

OSCAR 2023

このデータセットも Common Crawl ベースだが、 2023 年のクロールデータを用いておりやや新しい。また、 mC4 と比べるとややフィルタリングの精度が高い。
mC4 と同様に DSIR を適用し、日本語パートから20%をサンプリングした。

使い方

from transformers import AutoTokenizer, AutoModelForTokenClassification

model_name = 'globis-university/deberta-v3-japanese-base'
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForTokenClassification.from_pretrained(model_name)

訓練

本学習では、 Microsoft から Hugging Face で公開されている xsmall、base、large の 3 つのモデルをランダムに初期化して事前学習を行った。学習パラメータ等の詳細を表にまとめる。

Parameter xsmall base large
Batch size 48×8 24×8 8×8
Learning rate 3.84e-4 1.92e-4 6.4e-5
Number of steps 1M 1M 2M
(Number of Epochs) 3.86 1.93 1.29
Training days >5 days >5 days >12 days
Parameter Value
Number of devices 8
Maximum sequence length 512
Optimizer AdamW
Learning rate scheduler Linear schedule with warmup
Warmup steps 100,000
Precision Mixed (fp16)

評価

JGLUE による評価結果を表に示す。評価には JGLUE の GitHub で紹介されている方法を用い、グリッドサーチも行った。 test セットは公開されていないので、 dev セットでの成績の最大値をそのまま報告している。
なお、 JGLUE の JSQuAD 評価コードにおいて、 BertJapaneseTokenizer 以外は事前に分かち書きをしたデータを与える前提になっていたので、 BertJapaneseTokenizer と同じ処理をするように書き換えた。ここで実行されるコードの違いはスコアに影響を与えている可能性もある。本学習において作成した事前学習モデル以外のスコアは、全てモデルの作成者による報告の通りである。グリッドサーチの結果、採用したファインチューニングのハイパーパラメータを付録に示した。

総じて、既存のモデルと比べても十分に高性能なモデルを学習することができた。 xsmall ではサイズの違う東北大学の BERT base モデルに迫る性能になった。 base は他の DeBERTa モデルと同等の性能になった。 large はどのモデルも JSQuAD 以外はあまり性能の差が出なかった。本モデルが JSQuAD で伸び悩む原因は分かっていないが、本家の DeBERTa V3 が SQuAD を苦手としていないことから、モデル自体の性能ではなく、前述した評価用コードのトークン化時の処理の違いによって発生している可能性も排除できない。

Model #param JSTS JNLI JSQuAD JCQA
≤ small
和泉研 DeBERTa V2 17.8M 0.890/0.846 0.880 - 0.737
GLOBIS DeBERTa V3 33.7M 0.916/0.880 0.913 0.869/0.938 0.821
base
東北大 BERT (v3) 111M 0.919/0.881 0.907 0.880/0.946 0.848
河原研 RoBERTa 111M 0.913/0.873 0.895 0.864/0.927 0.840
和泉研 DeBERTa V2 110M 0.919/0.882 0.912 - 0.859
京大 DeBERTa V2 112M 0.922/0.886 0.922 0.899/0.951 -
京大 DeBERTa V3 160M 0.927/0.891 0.927 0.896/- -
GLOBIS DeBERTa V3 110M 0.925/0.895 0.921 0.890/0.950 0.886
large
東北大 BERT (v2) 337M 0.926/0.893 0.929 0.893/0.956 0.893
河原研 RoBERTa 337M 0.930/0.896 0.924 0.884/0.940 0.907
河原研 RoBERTa seq512 337M 0.926/0.892 0.926 0.918/0.963 0.891
京大 DeBERTa V2 339M 0.925/0.892 0.924 0.912/0.959 -
GLOBIS DeBERTa V3 352M 0.928/0.896 0.924 0.896/0.956 0.900

License

CC BY SA 4.0

Acknowledgement

計算リソースに ABCI を利用させていただきました。ありがとうございます。

9
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?