少し前、Transformer のアーキテクチャ図と Google Brain チームの論文「Attending Is All You Need」のコード間の矛盾を指摘したツイートが多くの議論を引き起こしました。
セバスチャンの発見は意図せぬ間違いだったと考える人もいますが、同時に奇妙でもあります。結局のところ、トランスフォーマー論文の人気を考えると、この矛盾については何千回も言及されるべきでした。
Sebastian Raschka 氏は、ネチズンのコメントに答えて、「最もオリジナルな」コードは確かにアーキテクチャ図と一致しているが、2017 年に提出されたコード バージョンは変更されているが、アーキテクチャは変更されていないと述べました。写真も同時に更新しました。これが議論の「齟齬」の根本原因でもある。
その後、Sebastian は、元の Transformer アーキテクチャ図がコードと一致しない理由を具体的に説明する Ahead of AI に関する記事を公開し、複数の論文を引用して Transformer の開発と変更について簡単に説明しました。
以下は記事の原文です。記事の内容を見てみましょう:
数か月前、私は「大規模言語モデルの理解: スピードアップするための最も関連性の高い文献の断面図」を共有しました。肯定的なフィードバックは非常に励みになりました。したがって、リストを最新かつ関連性のあるものに保つために、いくつかの論文を追加しました。
同時に、誰もが適切な時間内で理解できるように、リストを簡潔かつ簡潔に保つことが重要です。多くの情報が含まれているため、おそらく掲載されるべき論文もいくつかあります。
歴史的な観点から Transformer を理解するために役立つ 4 つの論文を共有したいと思います。これらを「大規模言語モデルについて」の記事に直接追加しているだけですが、以前に「大規模言語モデルについて」を読んだことのある人が簡単に見つけられるように、この記事でも個別に共有しています。
On Layer Normalization in the Transformer Architecture (2020)
下の図は Transformer の元のイメージですが、 (左) (https://arxiv.org/abs/1706.03762) は、元のエンコーダ/デコーダ アーキテクチャの有用な要約ですが、図には小さな違いがあります。たとえば、残差ブロック間のレイヤー正規化が行われますが、これは、元の Transformer 論文に含まれる公式 (更新された) コード実装と一致しません。以下に示すバリアント (中央) は、Post-LN トランスと呼ばれます。
Transformer アーキテクチャに関する論文のレイヤー正規化は、Pre-LN がより適切に機能し、以下に示すように勾配の問題を解決できることを示しています。実際には多くのアーキテクチャがこのアプローチを採用していますが、表現の破綻につながる可能性があります。
つまり、Post-LN または Pre-LN の使用についてはまだ議論がありますが、両方を一緒に適用することを提案する新しい論文もあります:「ResiDual: Transformer with Dual Residual」接続" (https://arxiv.org/abs/2304.14802) ですが、実際に役立つかどうかはまだわかりません。
#図: ソース https://arxiv.org/abs/1706.03762 (左と中央) および https://arxiv.org/abs/2002.04745 (右)
##高速重み付け記憶の制御を学ぶ: 動的リカレント ニューラル ネットワークの代替 ( 1991)この記事は、歴史的な豆知識や、基本的に現代の Transformer に似た初期の手法に興味がある人にお勧めします。
たとえば、Transformer の論文が発表される 25 年前の 1991 年に、Juergen Schmidhuber はリカレント ニューラル ネットワークの代替案を提案しました (https://www.semanticscholar.org/paper/Learning-to-Control-Fast-Weight) -思い出:-An-to-Schmidhuber/bc22e87a26d020215afe91c751e5bdaddd8e4922)、Fast Weight Programmer (FWP) と呼ばれます。高速な重み変更を実現するもう 1 つのニューラル ネットワークは、勾配降下法アルゴリズムを使用してゆっくりと学習する FWP 法に含まれるフィードフォワード ニューラル ネットワークです。
このブログ (https://people.idsia.ch//~juergen/fast-weight-programmer-1991-transformer.html#sec2) では、これを最新の Transformer と比較しています。例は次のとおりです。
今日の Transformer 用語では、FROM と TO はそれぞれキーと値と呼ばれます。高速ネットワークが適用される入力はクエリと呼ばれます。基本的に、クエリは、キーと値の外積の合計である高速重み行列によって処理されます (正規化と射影は無視します)。両方のネットワークのすべての演算が微分をサポートしているため、加法的外積または二次テンソル積を使用して、重みの急速な変化のエンドツーエンドの微分可能なアクティブ制御を実現できます。シーケンス処理中に、勾配降下法を使用して、高速ネットワークを低速ネットワークの問題に迅速に適応させることができます。これは、線形化された自己注意を備えたトランスフォーマー (または線形トランスフォーマー) として知られるようになったものと (正規化を除いて) 数学的に同等です。
上記の抜粋で述べたように、このアプローチは現在、線形トランスフォーマーまたは線形セルフアテンションを備えたトランスフォーマーとして知られています。これらは、論文「トランスフォーマーは RNN です: 線形注意を備えた高速自己回帰トランスフォーマー」(https://arxiv.org/abs/2006.16236) および「パフォーマーによる注意の再考」(https://arxiv.org/abs/2009.14794) から来ています。 。
2021 年の論文「Linear Transformers Are Secretly Fast Weight Programmers」(https://arxiv.org/abs/2102.11174) は、線形化された自己注意と 1990 年代の同等性を明確に示しています。高速ウェイトプログラマーの間で。
写真出典: https://people.idsia.ch// ~ juergen/fast-weight-programmer-1991-transformer.html#sec2
##テキスト分類のためのユニバーサル言語モデルの微調整 (2018)
これも歴史的な観点から見て非常に興味深い論文です。これは、オリジナルの「Attention Is All You Need」のリリースから 1 年後に書かれたもので、トランスフォーマーは含まれておらず、代わりにリカレント ニューラル ネットワークに焦点を当てていますが、それでも見る価値はあります。それは、事前トレーニングされた言語モデルと転移学習の下流タスクを効果的に提案するためです。転移学習はコンピューター ビジョンでは十分に確立されていますが、自然言語処理 (NLP) の分野ではまだ普及していません。 ULMFit (https://arxiv.org/abs/1801.06146) は、事前トレーニングされた言語モデルを特定のタスクで微調整すると、多くの NLP タスクで SOTA 結果を生成できることを示した最初の論文の 1 つです。ULIt が提案する言語モデルの微調整プロセスは 3 つの段階に分かれています:
ただし、ULMFiT の重要な部分であるプログレッシブ解凍は、通常、Transformer アーキテクチャがすべてのレイヤーを一度に微調整するため、実際には実行されません。
Gopher は、LLM トレーニングを理解するための広範な分析を含む、特に優れた論文 (https://arxiv.org/abs/2112.11446) です。研究者らは、3,000億個のトークンで80層、2,800億個のパラメータモデルをトレーニングしました。これには、LayerNorm (レイヤー正規化) の代わりに RMSNorm (二乗平均平方根正規化) を使用するなど、いくつかの興味深いアーキテクチャ上の変更が含まれています。 LayerNorm と RMSNorm はどちらも、バッチ サイズに制限がなく、同期を必要としないため、BatchNorm よりも優れています。これは、バッチ サイズが小さい分散設定での利点です。 RMSNorm は一般に、より深いアーキテクチャでのトレーニングを安定させると考えられています。
上記の興味深い豆知識に加えて、この記事の主な焦点は、さまざまなスケールでタスク パフォーマンス分析を分析することです。 152 の異なるタスクに関する評価では、理解、事実確認、有害な言語の特定などのタスクではモデル サイズの増加が最も有益である一方、論理的および数学的推論に関連するタスクではアーキテクチャの拡張はそれほど有益ではないことが示されています。
##図: ソース https://arxiv.org/abs/2112.11446
以上がこの「間違い」は実際には間違いではありません。Transformer アーキテクチャ図の何が「間違っている」のかを理解するには、4 つの古典的な論文から始めてください。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。