~自分自身を~ 繰り返さない

自己繰り返しを避ける

🤗 Transformersのデザイン哲学

「Don’t repeat yourself（同じことを繰り返さない）」、またはDRY（Don’t Repeat Yourself）は、ソフトウェア開発のよく知られた原則です。この原則は、「The pragmatic programmer」というコードデザインに関する最も読まれた本の1つから生まれました。この原則のシンプルなメッセージは明らかな意味を持っています。既に他の場所で存在するロジックを再書きする必要はありません。これにより、コードは同期され、メンテナンスが容易になり、より堅牢になります。この論理パターンへの変更は、依存関係のすべてに一様に影響を与えます。

Hugging FaceのTransformersライブラリの設計は、DRY原則とはまったく逆のものに見えるかもしれません。注意機構のコードは、異なるモデルファイルに50回以上もコピーされています。時にはBERTモデル全体のコードが他のモデルファイルにコピーされています。既存のモデルとほぼ同じ新しいモデルの貢献を強制的に行うことがよくありますが、それにはわずかな論理的な調整以外にも、すべての既存のコードをコピーする必要があります。なぜこれをやるのでしょうか？私たちは単に怠惰であるか、あるいは中心化された場所にすべての論理的な要素を集めることに圧倒されているのでしょうか？

いいえ、私たちは怠惰ではありません。TransformersライブラリにDRYデザイン原則を適用しないというのは、非常に意識的な決定です。その代わりに、私たちは「シングルモデルファイル」ポリシーと呼ぶ別のデザイン原則を採用することにしました。シングルモデルファイルポリシーは、モデルの順方向パスに必要なすべてのコードが1つのファイル、つまりモデルファイルに含まれているというものです。推論でBERTがどのように機能するかを理解するためには、BERTのmodeling_bert.pyファイルを見ればよいだけです。異なるモデルの同一のサブコンポーネントを新しい中央集権化された場所に抽象化しようとする試みを通常は拒否します。すべての可能な注意メカニズムが含まれたattention_layer.pyを持つことはしたくありません。再び、なぜこれをやるのでしょうか？

短く言えば、その理由は次のとおりです：

• Habana LabsとHugging Faceが提携し、Transformerモデルのトレーニングを加速化する
• CO2排出量と🤗ハブ：リーディング・ザ・チャージ
• 教育のためのHugging Faceをご紹介します 🤗

• 1. Transformersはオープンソースコミュニティによって作られました。
• 2. 私たちの製品はモデルであり、顧客はモデルコードを読んだり調整したりするユーザーです。
• 3. 機械学習の世界は非常に速く進化しています。
• 4. 機械学習モデルは静的です。

1. オープンソースコミュニティによって作られました

Transformersは、外部の貢献を積極的に促進するために作られています。貢献は通常、バグ修正または新しいモデルの貢献です。モデルファイルの1つでバグが見つかった場合、見つけた人が修正するのができるだけ簡単にすることを望んでいます。他のモデルの100のエラーを引き起こすことを見るのは、非常にやる気を削ぐことです。

モデルコードが他のすべてのモデルから独立しているため、特定のモデルに精通している人が修正するのはかなり簡単です。同様に、1つの新しいモデルファイルのみが追加される場合、新しいモデリングコードを追加し、対応するPRをレビューするのも簡単です。寄稿者は、既存のモデルを壊さずに中央集権化された注意メカニズムに新しい機能を追加する方法を考える必要はありません。レビュワーは、既存のモデルが壊れていないことを簡単に確認できます。

2. モデリングコードは私たちの製品です

私たちは、Transformersライブラリのユーザーの中にはドキュメントを読むだけでなく、実際のモデリングコードを見たり変更したりする人々が多いと仮定しています。この仮説は、Transformersライブラリが10,000回以上フォークされ、Transformers論文が1,000回以上引用されたことによって裏付けられています。したがって、初めてTransformersのモデリングコードを読む人が簡単に理解し、必要に応じて適応できることは非常に重要です。必要なすべての論理的なコンポーネントを1つのモデリングファイルに順番に提供することは、可読性と適応性の向上に非常に役立ちます。さらに、私たちは意味のある変数/メソッドの命名に非常に注意を払い、文字の効率的なコードよりも表現力のある/読みやすいコードを好みます。

3. 機械学習は驚異的な速さで進化しています

機械学習、特にニューラルネットワークの分野の研究は、非常に速く進化しています。1年前に最先端だったモデルは、今では時代遅れかもしれません。1年後に最も優れた注意メカニズム、位置埋め込み、またはアーキテクチャがどれであるかはわかりません。したがって、すべてのモデルに適用される標準的な論理パターンを定義することはできません。

例えば、2年前には、BERTのセルフアテンションレイヤーを、すべてのTransformersモデルで使用される標準的なアテンションレイヤーと定義するかもしれませんでした。論理的には、「標準的な」アテンション関数を中央のattention.pyファイルに移動できたでしょう。しかし、その後、各アテンションレイヤーに相対的な位置埋め込みを追加するアテンションレイヤーや（T5）、複数の異なる形式のチャンク化されたアテンション（Reformer、Longformer、BigBird）、位置と単語の埋め込みのための別個のアテンションメカニズム（DeBERTa）などが登場しました… 毎回、私たちは「標準的な」アテンション関数を適応すべきか、それをattention.pyに新しいアテンション関数を追加する方が良いかを考えなければなりませんでした。しかし、その場合、それをどのように名前付けるのでしょうか？attention_with_positional_embd、reformer_attention、deberta_attention？

機械学習モデルの論理的な要素に一般的な名前を付けることは危険です。なぜなら、この要素がどのモデルの要素であるかは非常に速く変わったり時代遅れになるかもしれないからです。例えば、チャンク化されたアテンションはGPTNeoやReformer、BigBirdのどのチャンク化されたアテンションに対応しているのでしょうか？アテンション層はセルフアテンション層なのか、クロスアテンション層なのか、それとも両方を含んでいるのでしょうか？しかし、モデルの名前でアテンション層を命名する場合、対応するモデリングファイルに直接アテンション関数を配置するべきです。

4. 機械学習モデルは静的です

Transformersライブラリは、さまざまな研究チームが作成した機械学習モデルの一貫性のあるコレクションです。通常、各機械学習モデルには論文と公式のGitHubリポジトリが付属しています。機械学習モデルが公開されると、それ以降はほとんど変更や改訂が行われません。

その代わりに、研究チームは通常、以前のモデルを基に新しいモデルを公開しますが、既に公開されたコードには大きな変更はほとんど加えません。これはTransformersライブラリの設計原則を決定する際に重要な認識です。モデルのアーキテクチャがTransformersに追加されると、モデルの基本コンポーネントはもはや変更されません。バグは頻繁に見つかり修正されるかもしれませんし、メソッドや変数の名前が変更されることもありますし、モデルの出力や入力形式がわずかに変更されるかもしれませんが、モデルの核となるコンポーネントはもはや変更されません。そのため、Transformersのすべてのモデルに対してグローバルな変更を適用する必要性は大幅に低下し、論理的なパターンが一度しか存在しないことはそれほど重要ではありません。

二つ目の認識は、モデルは双方向に依存しないということです。最近の公開されたモデルは既存のモデルに依存することがありますが、既存のモデルが論理的に後継モデルに依存することは明らかです。例えば、T5はBERTに基づいて一部が構築されているため、T5のモデリングコードは論理的にはBERTのモデリングコードに依存するかもしれませんが、BERTはT5に論理的に依存することはありません。したがって、BERTのアテンション関数をT5のアテンション関数でも動作するようにリファクタリングすることは論理的に正当ではありません。BERTのアテンション層を読んでいる人はT5について何も知る必要はありません。これは、アテンション層などのコンポーネントをすべてのモデルがアクセスできるモジュールに集中させることに反対するものです。

一方、後継モデルのモデリングコードは、論理的には前任モデルに依存することができます。例えば、DeBERTa-v2のモデリングコードはDeBERTaのモデリングコードに一部依存していると言えます。DeBERTaのモデリングコードとDeBERTa-v2のモデリングコードが同期していることで、保守性が大幅に向上します。DeBERTaのバグを修正すると、理想的にはDeBERTa-v2の同じバグも修正されるべきです。後継モデルが前任モデルの関数を参照している場合、前任モデルの関数を自動的に修正するツールが用意されています。

欠点

明らかに、単一ファイルポリシーには欠点もあります。ここで2つの主な欠点について簡単に触れたいと思います。

Transformersの主な目標の一つは、ユーザーが簡単に異なるモデル間を切り替えることができるように、推論とトレーニングの両方に統一されたAPIを提供することです。ただし、モデリングファイルが抽象化された論理パターンを使用することが許されない場合、モデル間で統一されたAPIを確保することははるかに困難です。私たちは、一貫したAPIに従うモデルを確保するために、多くのテスト（このブログ投稿時点で約20,000テストが毎日実行されています）を実行することでこの問題を解決しています。この場合、単一ファイルポリシーにより、モデルおよびテストの追加をレビューする際に非常に厳格にする必要があります。

第二に、Machine Learning モデルの単一のコンポーネントに関する研究がたくさんあります。例えば、Rethinking Attention with Performers で行われたように、新しいアテンションメカニズムの形式を既存のすべての学習済みモデルに適用するための研究チームがあります。このような研究を Transformers ライブラリにどのように組み込むべきでしょうか？これは確かに問題があります。既存のすべてのモデルを変更すべきでしょうか？これは上記の3番目と4番目のポイントに反することになります。100以上の新しいモデリングファイルを追加して、それぞれが Performer... で始まるようにすべきでしょうか？これはばかげたことのように思えます。このような場合、残念ながら良い解決策はありませんので、この論文を Transformers に統合しないことにします。もし論文がもっと注目され、強力な学習済みチェックポイントが含まれている場合、modeling_performer_bert.py のような最も重要なモデルの新しいモデリングファイルを追加していたかもしれません。

結論

全体として、🤗 Hugging Face では、単一のファイルポリシーが Transformers の正しいコーディング哲学であると確信しています。

あなたの意見はどうですか？ここまで読んでいただけたなら、あなたの意見に非常に興味があります！コメントを残したい場合は、こちらの対応するフォーラム投稿をご覧ください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!