GPT-2を読む⑥入力表現

前回に引き続き、OpenAIが2019年に発表した論文「Language Models are Unsupervised Multitask Learners」（GPTのバージョン２）の「アプローチ」を読み進めます。

前回に読んだ部分では、タスクに依存しない方法でより品質の高い訓練データセットを集める方法が解説されていました。

ただ単にWebから莫大なテキストを収集するだけではなく、良質なデータを収集することがGPT-2の学習において重要であり、そのための工夫が語られていました。

今回は「アプローチ」の残りの部分を読みます。主に、モデルへのテキストの入力表現について理解します。

入力表現における課題

伝統的なトークン化の課題

セクション２.２「入力表現」は次のように始まります。

ここでの「文字列」（ストリング）は、トークンのシーケンスと読み替えても同じ意味です。

これまで何度も登場した言語モデリングを行うことで言語モデルは言語の統計的な構造を習得します。よって、様々なシーケンスに対する確率を計算することができるようになります。

一般的な言語モデルであれば、そうあるべきです。

このため、訓練データセットにおける解説で強調されていたように、一般的な言語モデルの学習ではタスク固有の訓練データ選択は行われるべきではありません。

その一方で、伝統的なコーパスのトークン化ではいくつかの問題がありました。

まず、以前のトークン化の問題点として言語に特有であることが挙げられます。

例えば、アルファベットだけを考慮した処理として代表的なものに以下があります。

• 小文字化（Aからaへなど、大文字を全て小文字にする）

• 単語レベルでのトークン化（スペースやカンマなどで区切る）

なお、英語ベースのトークン化処理についてはこちらでも解説しています。

未知語への対応の問題

さらに伝統的なトークン化では未知語を扱えません。これは、コーパスのトークン化が行われる時点で知られていない単語を扱えないという問題です。

例えば、トークン化された単語などに整数値（インデックス）を与えて語彙をを管理する場合にこの問題が生じます。それぞれのトークンにインデックスがあり、その値に対応する（マッピングされた）埋め込みベクトルを取り出すのですが、そもそもそのようなインデックスが存在しない場合は未知語となり扱い不能となってしまいます。

わかりやすい例としてこんなのはどうでしょうか。

私が見つけたのは手のひらに乗るほど小さいゼットンだった。

「ゼットン」はウルトラマンに登場した宇宙恐竜ですが、語彙の中に含まれていなければトークン化がなされていないわけで未知語となります。

未知語をモデルが予測することも考えられますが、「ゼットン」の身長は本来６０メートルぐらいなので「手のひらに乗る」といった文脈では予測するのは困難でしょう。

つまり、以前に主流だったトークン化手法では未知語が発生するため、対応する埋め込みベクトルが取得できず、モデルでの処理が困難になります。この制約により、モデリング可能な文字列の範囲が制限されてしまうという問題があります。

多言語への対応

言語特有のトークン化を避けるには多言語対応した文字列が必須となります。そこで、ちょっと話がそれますが、Unicode（ユニコード）について簡単に紹介します。

Unicodeは世界中のほぼすべての文字や記号を一つの統一された体系で表現するための規格です。これには、アルファベット、数字、漢字、ひらがな、カタカナ、絵文字、特殊記号など、さまざまな言語や文化の文字が含まれています。

たとえば、英字の「A」はUnicodeでU+0041、漢字の「漢」はU+6F22が割り当てられています。

また、このように各文字に割り当てられた一意の番号をコードポイント（Code Point）と呼びます。コードポイントによって、各文字に対して整数値（インデックス）を対応させています。つまり、異なる文字に固有の番号が付けられています。

以上より、Unicodeを使うことで異なるシステムやプラットフォーム間で文字を正確にやり取りできるようになっています。

Unicodeで定義された文字をコンピュータで扱えるバイト列に変換するエンコーディング方式の一つとしてUTF-8があります。

UTF-8では、文字ごとに異なるビット数を使ってエンコードする可変長のエンコーディングを採用しています。よって、1バイトから4バイトの範囲でエンコードが可能となっています。

例えば、ASCII文字（英数字や記号）は1バイトで表現されるので、伝統的なASCII文字と互換性があります。それ以外の文字（日本語の漢字など）は2バイト以上で表現されます。

このようにして世界中の文字を効率的に扱えるため、現在ではUTF-8はほぼ標準として広く使用されています。

Byte Pair Encoding

UTF-8のシーケンス

では、単語レベルでのトークン化における未知語の問題の解決策を考えてみましょう。単語レベルでのトークン化ではなく、文字ごとにデータ処理するのはどうでしょうか。UTF-8の文字列を扱うならば多言語にも対応できます。

論文はこう続けます。

つまり、Unicodeのシーケンスを使えば、言語特有のトークン化に陥ることなく未知語の問題を解決するための条件を満たしてはいます。

しかし、バイトレベルの言語モデル（文章をUTF-8のシーケンスとして学習する）と単語レベルの言語モデル（単語のトークン化を行い学習する）より性能が悪くなりました。これは、One Billion Word Benchmarkという大規模データセットで確認されています。

また、OpenAIでも彼らが収集したWebTextを使って同様の実験をし、バイトレベルの言語モデルの性能が比較的に悪いことが確認されました。

この問題を解決するために、バイト対符号化が登場します。

バイト対符号化

論文は、バイト対符号化（Byte Pair Encoding、BPE）についてこう語ります。

BPEの手法では、頻出ひんしゅつする文字列のペアを繰り返し結合（マージ）して、新しい単語やトークンを作り出します。といっても抽象的すぎてわかりにくいので、単純な例を使って要点を解説します。

まず、あるコーパス（テキストを集めたデータセット）の中で４つの単語のみが存在するとします。以下に各単語の頻度を表示します。

頻度 = {
  bell: 3,
  big: 4,
  small: 5,
  tall: 2,
}

この例のコーパスでは、'bell'という単語は３回出現しています。

さて、このコーパスに登場する４つ単語から文字レベルの語彙を抽出すると以下になります。

語彙 = [ a, b, e, g, i, l, m, s, t ]

この状態での語彙は、文字レベルのトークンだけです。

では、文字レベルのトークンを使って各単語を表現します。

頻度 = {
  (b, e, l, l): 3,
  (b, i, g): 4,
  (s, m, a, l, l): 5,
  (t, a, l, l): 2,
}

次に、隣接するトークンの中で頻出するものを結合します。

'l'と'l'が隣接したケースが全部で10回あります（'bell'が3回、'small'が5回、'tall'が2回）。これが最も多く出現するので結合して'll'というトークンにします。

よって、語彙に'll'が追加されて、次のようになります。

語彙 = [ a, b, e, g, i, l, m, s, t, ll ]

これを使って各単語を表現すると以下になります。

頻度 = {
  (b, e, ll): 3,
  (b, i, g): 4,
  (s, m, a, ll): 5,
  (t, a, ll): 2,
}

次に、'a'と'll'が最も多く隣接して出現しています（'small'が5回、'tall'が2回）。よって、これを結合して'all'とします。

語彙 = [ a, b, e, g, i, l, m, s, t, ll, all ]

頻度 = {
  (b, e, ll): 3,
  (b, i, g): 4,
  (s, m, all): 5,
  (t, all): 2,
}

これで、'all'という単語は単語レベルのトークンとして扱われるようになりました。'll'という部分単語（サブワード）のトークンも登場しています。それ以外は文字レベルで扱われます。

以上からわかるように、各ステップでの結合処理で、ペアの頻度が変わってきます。よって、更新されたペアの頻度によって、次に結合するペアが選ばれます。より大きなコーパスでも同様のプロセスを繰り返すことでトークン化が行われます。

これはざっくりとした例ですが、BPEによって文字レベルから単語レベルまで頻度によってトークン化が行われる様子が見えます。

頻度が多いものは連結してまとめるので、文字レベルだけの処理より効率が良くテキストを扱うことができます。つまり、頻繁に使われる単語をより短く表現でき、まれな単語も細かく分割して扱えるようになります。

よって、未知語には文字レベルや部分単語で対処することができます。

以上はアルファベットのみのケースですが、他言語でも考え方は同じです。

例えば、日本語の場合、「こんにちは」という単語を文字レベルで分割すると「こ」「ん」「に」「ち」「は」となります。このようにして文字レベルから出発してBPEの処理を繰り返し適用していきます。

なお、バイト対符号化という名前に「バイト」（byte）と付いていますが、実際にはバイト列ではなく、Unicodeコードポイントを単位として実装されることが多いです。

UTF-8は、文字を1〜4バイトでエンコードする可変長エンコーディング方式です。よって、ある文字がUTF-8では2バイトで表現されることが（特に日本語などでは頻繁に）ありますが、Unicodeコードポイントでは1つの文字として扱われます。これにより、BPEはいわゆる文字をトークン化の出発点とするので、他言語の複雑な文字エンコーディングにも対応します。

語彙サイズの問題

なお、実際の実装ではいくつかのハイパーパラメータや設定が必要となります。

例えば、最終的な語彙サイズ（vocab_size）を指定します。語彙サイズを1000と指定すると、トークンの結合（マージ操作）が自動的に繰り返され、語彙サイズが1000に達するまで行われます。

マージ操作が多いほど、より大きなトークンが生成され、長い単語に対応することになります。一方で、操作回数が少ないと、トークンが細かく分割され、文字レベルに近いトークン化が行われます。

さらに、語彙サイズが大きいほど、言語モデルが予測するトークンの種類が増えるので、その分だけモデルのパラメータ数も増加し、必要なメモリや計算コストが高くなります。

しかし、Unicodeのコードポイントを全て含めるとなると語彙が膨大になってしまいます。

この点に関して論文は次にのように述べています。

Unicodeコードポイントを扱う場合、すべてのUnicodeシンボルを表現する必要があるため、基本語彙が非常に大きくなります（13万以上）。

しかし、BPEの手法が使われる場合、32,000から64,000トークンぐらいの語彙サイズが通常です。

BPEをコードポイントではなく、バイトレベルで適用する場合、複数バイトの文字は分割されたバイトとして扱われるので、語彙サイズは256に収まります（１バイトで表現できる整数は256個のみ）。

文字カテゴリの区別

しかし…、と論文は続けます。

「バイト列に直接BPEを適用する」と言っているのは、単純にバイト列から頻度の高いペアを取り出して結合していくことを指します。つまり、文字の種類などを考慮せずに結合を行うと問題が生じるというわけです。

問題の具体例として、同じ「dog」という単語でも、末尾の記号が異なるだけで、"dog."、 "dog!"、 "dog?"などの別々のトークンとして扱われるため、語彙が無駄に増えてしまいます。

ただし、前述のUnicodeコードポイントを使う例では、コーパスを単語に分けた状態からスタートしたのでそのような問題はありません。

よって、バイト単位での処理を行う場合でも、何らかの手段によって不要な連結が起こらないようにする必要があります。

論文はこう続けます。

文字のカテゴリとは、以下のようなものです。

• 通常の文字：英字のアルファベットや、他の言語の文字。

• 数字：0〜9の数字や、漢数字など。

• 句読点：ピリオド（.）、カンマ（,）、感嘆符（!）、疑問符（?）

• 特殊文字：$、&、@ などのシンボル

例えば、「100点」という文字列が頻繁に登場したとしても、「100」と「点」を連結することはしないということです。

ただし、スペースに関しては連結を許します。

例えば、次のようなテキストはスペースを含めて分割されます。

I have a book.

このテキストは、以下のように分割されます。

[ "I", " have", " a", " book", "." ]

このように分割された各々のトークン内でバイト単位のBPEを実行します。

もう少し複雑なテキストを、HuggingfaceからのGPT-2のトークナイザーを使ってトークン化してみます。

from transformers import GPT2Tokenizer

# GPT-2トークナイザーのロード
tokenizer = GPT2Tokenizer.from_pretrained("gpt2")

# テキストの定義
text = "I have a book about AXGC99."

# トークン化
tokens = tokenizer.tokenize(text)
token_ids = tokenizer.convert_tokens_to_ids(tokens)

# 各トークンとその対応するID、逆トークン化されたテキストを表示
print(f"Token \t\t Token ID")
print(f"{'-'*30}")
for token, token_id in zip(tokens, token_ids):
    print(f"{token:15} {token_id}")

このコードでの入力テキストは以下になっています。

I have a book about AXGC99.

この出力は次のようになります。

Token 		 Token ID
------------------------------
I               40
Ġhave           423
Ġa              257
Ġbook           1492
Ġabout          546
ĠAX             43051
GC              15916
99              2079
.               13

ここで、「Ġ」という記号はスペースを意味します。

また、「AXGC99」という適当な本のタイトルが「AX」、「GC」、「99」と分割されています。

このトークナイザーでは、「AX」や「GC」は連結されたトークンとして語彙に含まれているということです。トークナイザーを訓練したデータセットでそのようなパターンの頻度が高かったということでしょう。

なお、文字と数字が分割されているのも確認できます。

以上により、スペース以外は文字のカテゴリを超えて連結することなく、またUnicodeコードポイントではなくバイト単位でBPEを適用することで、少ない語彙数で多くのトークンを表現することが可能となりました。

GPT-2の入力表現

GPT-2の入力表現について、論文はこう結んでいます。

これまでの経緯から分かるように、単語レベルのトークン化では経験的に良い性能が出ることがわかっていたが、多言語や未知語の問題を解決するために文字レベルのトークン化が必要だった。さらに、バイト単位の処理を行うことで語彙数を最小限に抑えることが可能になりました。

そのため論文は、この入力表現を使うことで、単語単位での言語モデルが持つ実用的なメリットと、バイト単位の手法による柔軟性を両立させる、と結論づけています。

Unicode文字列にも対応している上、事前にテキストを特定の形式に変換する必要もありません。例えば、テキストをすべて小文字にしたり、特定の単語に分割したりする前処理を必要としません。また、バイト単位の処理のおかげで語彙サイズが大きくなっても柔軟に対応できます。

どのようなデータセットでも、こうしてトークン化された入力表現のシーケンスに対して言語モデリングを行えば、どんな文字列に対しても確率を予測できるようになります。

モデルのアーキテクチャ

トランスフォーマーへの修正

セクション２.３「モデル」は次のように始まります。

GPTシリーズは、トランスフォーマー（Vaswaniら、2017）からのデコーダをベースにしています。GPT-2は、GPT-1（Radfordら、2018）に幾つかの修正を加えたモデルです。両方ともIlya Sutskever（最近、OpenAIを去りました）が関わっています。

修正の概要について論文は以下のように説明しています。

レイヤー正規化

レイヤー正規化はバッチ正規化と似た目的を持ち、訓練中にデータの平均や標準偏差が大きく変わることを防ぎ訓練を安定させるためのものです。

オリジナルのトランスフォーマーやGPT-1ではレイヤー正規化は、自己アテンションや位置ごとのフィードフォワードの後に置かれていました。

オリジナルのトランスフォーマーの後の論文で、レイヤー正規化を自己アテンションや位置ごとのフィード・フォワードの前に行う手法の方がより訓練が安定することがわかりました。これを事前レイヤー正規化（Pre-LN）と呼びます。これがGPT-2では採用されています。

なお、残差接続は、勾配消失の問題を低減するための手法です。こちらで解説しています。

「最後の自己アテンション・ブロックの後に追加のレイヤー正規化が加えられました」とは、最後の自己アテンションの直後ではなく、最後のブロックの後にレイヤー正規化を付け加えたという意味です。さもないと、最後のブロックからの出力に正規化が施されない状態になってしまうからです。

残差接続

深いニューラルネットワークでは、モデルが深くなるほど、各層での出力が積み重なって、残差接続を通して伝達される数値が大きくなりすぎることがあります。これを防ぐために、各層の重み（パラメータ）を初期化する際に工夫をしています。

ここで残差層（Residual Layers）と呼ばれているのは、残差接続が行われている層のことです。つまり、自己アテンションと位置ごとのフィードフォワードのことです。

例えば、自己アテンションへの入力と自己アテンションからの出力が結合されたものが、次のフィードフォワードへの入力となり、それがフィードフォワードからの出力へと残差接続されます。

モデルの深さ（ブロックの数）が増えるほど値が継続される回数が増えるので最終的な出力が大きくなり過ぎてしまうリスクがあります。

そこで、自己アテンションや位置ごとのフィードフォワードの重みを設定する際に、モデルの深さ（残差層の数）に応じて、初期値を小さくスケーリングします。

このスケーリングの方法として、重みを初期化する際に$${\frac{1}{\sqrt{N}}}$$ の値でスケールしています。$${N}$$は層の数なので、層の数が増えるほど重みの初期値は小さくなります。

文脈のサイズ

語彙のサイズが約５万トークンということなのでvocab_size=50,000でBPEを実行したのでしょう。

ここでの文脈は、入力文に与えられる条件となるシーケンスのことです。そのサイズが以前の512トークンから2倍の1024トークンへと増加されました。

GPT-1の事前学習のバッチサイズは64したが、GPT-2では512へと大きく変更されました。

なお、GPT-1のモデル構造はこちらで解説しています。

次回予告

次回も、この論文を読む方針に従って読み進みます。

これまで読んできた「アプローチ」が、どれだけ成功したのかを確認するために「実験」のセクションに目を通していきます。

言語モデルでは様々なタスクを実行するので、対象によっては「アプローチ」が生む効果が異なるでしょう。さて、結果からどんな結論が見えてくるでしょうか。

お楽しみに！