フレームワーク、ライブラリ、RL、そしてなぜ私があなたのお気に入りのRLコードベースが好きではないのかについて話しましょう。はい、それも含めて。 RLの珍しい点は、アルゴリズムが簡単な部分であることです。GRPOは、いくつかのlogprobの単線方程式です。データがあれば、損失の計算は簡単で、おそらく選択したバックプロップライブラリで使用しているでしょう。 しかし、それが問題です -- データの取得です。それはお尻の痛いことです。通常のRLでは、ロールアウトを行い、おそらくいくつかのエピソードを切り捨て、それに応じて終了を処理する必要があります。カタツムリになりたくない場合は、環境をベクトル化し、それに合わせてアルゴリズムを適応させる必要があります。LLMを行いたい場合は、LLMをメモリに収めるためのナンセンスをすべて行う必要があります。プロンプトに注意し、損失の適切な部分をマスクする必要があります。適切な生成エンジン (vLLM) が必要であるため、重みを更新するのが面倒になります。マルチエージェントマルチターンLLM RLを行いたい場合は、数独をコミットしたほうがいいかもしれません。 RL に関連するほぼすべてのことについて多くの意見の相違がありますが、@jsuarez5341 の Pufferlib はこの点を見事に例示していると思います。シミュレートされた環境でRLアルゴを非常に迅速にトレーニングするという、その機能は間違いなく信じられないほどです。 しかし、その目新しさのほとんどは純粋なインフラです。コアアルゴリズムは長年とほぼ同じであり、エンジニアリング作業全体の10%未満にすぎないと私は言います。 当然のことながら、これは、組み込みの例を実行する以外のことを行うために記述する必要があるコードに影響します。私が何度も何度も見つけているのは、多くの十分に自明ではない(読み:興味深い)研究問題の場合、(a)ゼロから/単純なプリミティブから物事を書くか、(b)クレイジーなアイデアに対応するために既存のフレームワークを適応させるのに、同じような時間がかかるということです。 前者では、実際のロジックを書くことに重点を置きます。後者では、ロジックを追加できるようにフレームワークをラングリングします。私は自分が何が好きかをよりよく知っています。 これはすべて、アルゴリズムが簡単な部分だからです。 インフラはお尻の痛みです。したがって、選択できる立場にあるときはいつでも、インフラストラクチャを簡素化するツールを使用し、トレーニング ループを自分で作成してください。フレームワークを構築するのではなく、ライブラリを構築してください。後で自分に感謝するでしょう。 当時の修士課程の指導教官に、rllibをやめて自分でPyTorchでPPOを書くように言ってくれた最初の人でした。そして、ついにこの暴言を書くきっかけを与えてくれた@halleriteに感謝します。人々がそれを要求すれば、将来のある時点で例を挙げて適切な努力の投稿を書くかもしれません。