ReefのOpenClaw-RLレシピ、スコア付き重み更新をリリースゲートの背後に配置

OpenClawタスクの採点は簡単な部分です。より難しい問題は、結果として得られる重み更新が、稼働中の配信状態に触れる前にどうなるかです。Reefのリポジトリには、スコアだけを信頼するのではなく、その更新をリリースゲートの背後に置く、具体的なOpenClaw-RL重み進化レシピが含まれています。

レシピの具体的内容

構成は限定されており具体的です。これらの数値は再現目標として扱い、一般的なベンチマークとは考えないでください：

• 72のGSM8K問題を72のタスクとして扱う — 各問題はループ内で独自のタスク単位です。
• Qwen3-4Bがポリシーとプロセス報酬モデルの役割を担当します。
• Qwen3-32Bが生徒役です。
• 実行には7つのGPUを使用します。
• プロジェクトはセッション14で3回連続合格の基準を満たしたと報告しています。
• チェックインされた学習曲線は最初の36セッションをカバーしています。

興味深いのはゲーティングのロジックです。採点された更新は、テスト（この場合は3回連続合格）をクリアするまで、稼働中のバージョンを置き換えるために昇格されません。これが「報酬モデルが気に入った」と「配信しても安全だ」の違いです。

これらの数値が意味するもの（そして意味しないもの）

これらは再現目標です。すべてのOpenClawワークロードをベンチマークするものではなく、汎用的なOpenClawハーネスアダプタを確立するものでもありません。セッション14 / 36セッションの曲線を普遍的な主張として読むなら、それは誤読です。これは1つのタスクファミリー（GSM8K）に対する1つのモデルスタックでの1つのレシピです。

推奨される最初のステップ

アプローチを適応させる前に健全性を確認したい場合：

1. 客観的な検証器を持つOpenClawタスクから始めます — 感覚に基づく採点は避けます。
2. レシピをそのまま再現します。
3. 意図的に悪い重み候補が配信状態を移動できないことを確認します。 これが実際に重要なリリースゲートの特性です。
4. それが合格した後に初めて、最適化が実際のタスクに転送できるかどうかを問う価値があります。

ステップ3は人々が飛ばしがちなものです。ゴミのような更新がゲートをすり抜けられるなら、残りのパイプラインは飾りです。

対象読者

OpenClaw上でRLスタイルの重み進化ループを構築している開発者で、抽象的な「スコアが良かったから出荷」パイプラインではなく、昇格をゲートするための実用的なリファレンスを求めている人向けです。