TRL v1.0：分野の前提が崩れても機能するポストトレーニングライブラリ

記事に戻る TRL v1.0: 分野が自らの前提を無効化するときにも機能するポストトレーニングライブラリ Upvote - ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1677431596830-631ce4b244503b72277fc89f.jpeg) Quentin Gallouédec qgallouedec フォロー ![](https://cdn-avatars.huggingface.co/v1/production/uploads/5f5006390bcb0e71543cec17/rIygtvzvx-z0AlYcFIME-.png) Steven Liu stevhliu フォロー ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1617264212503-603d25b75f9d390ab190b777.jpeg) Pedro Cuenca pcuenq フォロー ![](https://cdn-avatars.huggingface.co/v1/production/uploads/61929226ded356549e20c5da/ONUjP2S5fUWd07BiFXm0i.jpeg) Sergio Paniego sergiopaniego フォロー TRL v1.0をリリースします。これはTRLの真の転換点を示すものです。研究用のコードベースとして始まったものが、安定性に関する明確な期待とともに、人々が構築する信頼できるライブラリへと進化しました。これは単なるバージョン番号の更新ではありません。TRLが現在本番システムを支え、その責任を受け入れているという現実を反映しています。 TRLは現在75以上のポストトレーニング手法を実装しています。しかし、網羅性自体が目標ではありません。重要なのは、これらの手法を実際に試し、比較し、実践で使用することを容易にすることです。このライブラリの設計は最初から決まっていたわけではありません。6年以上前の最初のコミットに遡る、何年にもわたる反復の結果であり、新しいアルゴリズム、新しいモデル、移り変わるパラダイムなど、この分野が投げかけたあらゆるものによって形作られてきました。時が経つにつれ、この圧力はコードベースを非常に独自の設計へと導きました。その一部は一見すると風変わりに見えるかもしれませんが、多くの進化的なコードベースと同様に、そこには存在理由があります。 TRLは、停滞しない分野のために構築されています。したがって、問題は完璧な抽象化をいかに設計するかではありません。自らの前提を無効化し続ける領域で、いかに安定したソフトウェアを作るかです。これがTRL v1.0で解決しようとした課題であり、この記事ではその方法を説明します。 1. 動く標的：変化し続ける分野としてのポストトレーニング ポストトレーニングは、単一のレシピを滑らかに洗練させる形では進化してきませんでした。それは連続する重心移動を経ており、それぞれが目的だけでなく、技術スタックの構造そのものを変えてきました。 PPO [Schulman et al., (2017); Ziegler et al., (2019)]は、あるアーキテクチャを規範的なものに見せました：ポリシー、参照モデル、学習済み報酬モデル、サンプリングされたロールアウト、そしてRL（強化学習）ループです。 その後、オリジナルのDPO [Rafailov et al., (2023)]、ORPO [Hong et al., (2024)]、KTO [Ethayarajh et al., (2024)]といったDPOスタイルの手法が、そのスタックを切り崩しました。選好最適化は、別個の報酬モデルや価値モデル、あるいはオンラインRLを必要とせずに機能し得るのです。基本的と思われていたコンポーネントが、突然オプショナルなものに見えるようになりました。 GRPO [Shao et al., (2024)]などのRLVRスタイルの手法は、再び重心を移動させました。数学、コード、ツール使用といったタスクでは、報酬は学習済み報酬モデルからではなく、検証器や決定論的チェックから得られることが多くなりました。サンプリングとロールアウトが再び重要になりますが、ループ内で扱われる対象は、もはやPPOライブラリが当初想定していたものとは同じではありません。 ここでの教訓は、単に手法が変わるということだけではありません。コアの定義自体がそれらと共に変化し続けているのです。ここでの強い前提は半減期が短い。これがおそらく、どのポストトレーニングライブラリもまだ真に安定していない理由です。 2. プロジェクトからライブラリへ：TRLは「混沌適応型」設計を持つ では、停滞しない分野のためのライブラリを構築するとはどういう意味でしょうか？答えは直感に反します：今日安定しているものの本質を捉えようとしてはなりません。代わりに、変化し得るものの周りを設計するのです。報酬モデルがその理由をよく表しています：PPOでは不可欠に見え、DPOではオプショナルになり、RLVR手法では検証器として戻ってきました——学習済みモデルではなく決定論的関数であり得る構造です。それらの元の形態を中心に構築された抽象化は、今となっては二度も時代遅れになっていたでしょう。このライブラリが生き残るのは、強い前提は寿命が短いことを認識し、その変化可能性をコードベースの構成方法の中心に据えるからです。 これが、TRLが月間300万回ダウンロードされ、主要な下流プロジェクトがそれを安定したインフラとして扱う環境です。分野は基盤を変え続け、同時に、ユーザーはものが壊れないことを必要としています。 性質の転換：コードから契約へ TRLは意図的にライブラリになろうと決めたわけではありません。すでにライブラリであったことに気づいたのです。UnslothやAxolotlのようなプロジェクト——両者で数千人のユーザーを持つ——は、TRLのトレーナーとAPIの上に直接構築していました。TRLの破壊的変更は、即座にそれらのスタックに伝播しました。引数の名前変更、デフォルト値の移動、出力形式の再構築——これらはいずれも他者にとってのインシデントになり得ました。転換はすでに起きていたのです。v1.0は、TRLがそれを明示的に認めた瞬間です。 安定版と実験版、同じ屋根の下で TRLの安定性モデルの特異な点は、それが保証するものではなく、その保証と並行して許容するものにあります。安定版と実験版は、明示的に異なる契約のもと、同じパッケージ内で共存します。安定版コアはセマンティックバージョニングに従います。実験版レイヤーはそのような約束をしません——これは新しい手法が評価中に置かれる場所であり、APIが分野に追いつくために素早く変更できる場所です。 これは妥協ではありません。これは特定の制約への対応です：この分野は、いかなる手法が安定性を獲得するよりも速く、新しい手法を生み出します。未成熟な手法の追加を拒めば、TRLは数ヶ月で無関係なものになるでしょう。それらすべてを安定版に追加すれば、アルゴリズムが期待通りに機能しないことが判明するたびに、すべての下流プロジェクトが壊れてしまいます。 from trl import SFTTrainer # ⚖️ 安定版 from trl.experimental.orpo import ORPOTrainer # 🧪 実験版 実験版から安定版への昇格は自動的ではありません。重要なのは、保守コストと実際の使用量の比率です。コミュニティが広く利用するため、一部の手法は居場所を獲得します。他の手法は、保守コストを十分に低く抑えられることで実用的になります——そしてコードベースの設計がそれを可能にしています。 実際には、安定版のインターフェースには、SFT、DPO、報酬モデリング、RLOO、GRPOのトレーナーとその近縁バリアントが含まれます。実験版のインターフェースはより広く、より速く変化します。最新の状況については、TRLドキュメントが最良の参照先です。 v1.0に到達するために必要な破壊的変更は、意図的に0.xリリース全体に分散されました。最後の0.xバージョンからの移行は最小限です——移行ガイドを参照してください。 意図的に抽象化を制限する パターンが変化し続ける領域では、何でも収容できる柔軟な抽象化を構築したいという誘惑に駆られます。私たちの答えは逆でした：抽象化を厳密な最小限に制限する——ただし、この「最小限」はほぼ常に過大評価されていることを認識しながら。 実際には、これはコードに対する非常に局所的なアプローチに変換されます： * 一般的なクラス階層を避ける * 明示的な実装を好む * 重複を受け入れ、むしろ奨励する 目標は構造を完全に排除することではありません——共通ユーティリティは依然として存在します——しかし、ドメイン自体がまだ安定していない場所に抽象化を押し付けることを避けることです。例えば、オフライントレーナーの共通基底クラスを定義するのではなく、それらの将来の進化が不確実な場合は独立した実装を好みます。 ```python # ❌ 望ましくない例 class OfflineTrainer(Trainer): def some_common_method(self): ... class DPOTrainer(OfflineTrainer): ... class KTOTrainer(OfflineTrainer): ... # ✅ 良い例 class DPOTrainer(Trainer): def some_common_method(self): ... class KTOTrainer(Trainer): def some_common_method(self): ... ``` 別の例： ```python # ❌ 望ましくない例 # collator.py class TRLCollator: ... # dpo_trainer.py class DPOTrainer: def __init__(self, ...): self.collator = TRLCollator(...) # kto_trainer.py class KTOTrainer: def __init__(self, ...): self.collator = TRLCollator(...) # ✅ 良い例 # dpo_trainer.py class DataCollatorForPreference: ... class DPOTrainer: def __init__(self, ...): self.collator = DataCollatorForPreference(...) # kto_trainer.py class DataCollatorForUnpairedPreference: ... class KTOTrainer: def __init__(self, ...): self.collator = DataCollatorForUnpairedPreference(...) ``` Judge（審判）は、この原則に従わなかった場合に何が起こるかの良い例です。初期にJudgeを導入したとき... より明示的だが、より適応可能 このアプローチは、硬直したフレームワークよりも、明示的で変更可能な使用法を好みます：魔法のような挙動は少ないが、制御は多い。これには明らかな代償が伴います：コードの重複です。これはしばしばアンチパターンと見なされますが、この文脈では、許容できるだけでなく効果的であることが証明されています。直感に反して、実際には小さくとも一貫した規律——実装間の差分を最小限に保ち、不必要な分岐を避ける——によって管理可能なままです。Transformersの設計哲学と同様に、私たちは意図的に重複と局所的な明示性を受け入れます。動機は、焦点に多少のニュアンスはあるものの、大部分が一致しています。 これは説明するよりも見た方が簡単です。RLOOとGRPOを比較してください：それらの実装の大部分はほぼ行ごとに重複しています。それは偶然ではなく、無駄な負荷でもありません。これらの手法は十分に近いため、それらのコードパスを揃えておくことで、読みやすく、進化させやすく、保守コストを低く抑えることができます。 3. TRLの位置付け この比較の目的は、TRLがあらゆる軸で最高だと主張することではありません。そうあるべきでもありません。一部のシステムは最大スループットのために構築され（PipelineRLなど）、一部は問題のより狭い範囲に最適化され（LLaMA-Factoryなど）、一部は特定の環境でより意見の強い開発体験を提供します（Tinkerなど）。TRLはエコシステム内で異なる位置を占めています：それは汎用のポストトレーニングライブラリとして、広範な手法のカバレッジ、深いHugging Face統合、比較的低いインフラ負担、明示的な安定性契約を、ドメインが許す限りAPIとコードをシンプルに保ちながら組み合わせようとします。 UnslothやAxolotlのようなライブラリは、比較において隣に位置するのではなく、TRLの上に構築されるため、ここには含まれていません。その意味で、それらのユーザーの多くは間接的にTRLユーザーでもあります。

TRL v1.0：分野の前提が崩れても機能するポストトレーニングライブラリ

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト