Recette OpenClaw-RL de Reef : des mises à jour de poids notées derrière une barrière de publication

Noter une tâche OpenClaw est la partie facile. La question plus difficile est ce qui arrive à la mise à jour des poids qui en résulte avant qu'elle ne soit autorisée à toucher un état de service en production. Le dépôt de Reef fournit une recette concrète d'évolution des poids OpenClaw-RL qui place cette mise à jour derrière une barrière de validation plutôt que de se fier au score seul.

La recette, concrètement

La configuration est délimitée et précise — considérez ces chiffres comme une cible de reproduction, et non comme un benchmark général :

• 72 problèmes GSM8K traités comme 72 tâches — chaque problème est sa propre unité de tâche dans la boucle.
• Qwen3-4B gère les rôles de politique et de modèle de récompense de processus.
• Qwen3-32B est l'étudiant.
• Sept GPU pour l'exécution.
• Le projet indique avoir atteint son critère de trois passes consécutives à la session 14.
• La courbe d'apprentissage versionnée couvre les 36 premières sessions.

La logique de validation est l'élément intéressant. Une mise à jour notée n'est pas promue pour remplacer la version de travail tant qu'elle n'a pas réussi un test — dans ce cas, trois passes consécutives. C'est la différence entre « le modèle de récompense l'a aimée » et « elle peut être servie en toute sécurité ».

Ce que ces chiffres sont (et ne sont pas)

Ils constituent une cible de reproduction. Ils ne benchmarkent pas toutes les charges de travail OpenClaw et n'établissent pas d'adaptateur générique de harnais OpenClaw. Si vous lisez la courbe session 14 / 36 sessions comme une affirmation universelle, vous la lisez mal. C'est une recette sur une famille de tâches (GSM8K) avec une pile de modèles.

Première action suggérée

Si vous voulez vérifier l'approche avant de l'adapter :

1. Commencez par une tâche OpenClaw qui dispose d'un vérificateur objectif — pas de notation au feeling.
2. Reproduisez la recette telle quelle.
3. Confirmez qu'un candidat de poids délibérément mauvais ne peut pas modifier l'état de service. C'est la propriété de barrière de validation qui vous importe réellement.
4. Ce n'est qu'après cela qu'il vaut la peine de se demander si l'optimisation se transfère à votre tâche réelle.

L'étape 3 est celle que les gens sautent. Si une mise à jour indésirable peut franchir la barrière, le reste du pipeline n'est que décoration.

À qui cela s'adresse

Aux développeurs qui construisent des boucles d'évolution des poids de style RL au-dessus d'OpenClaw et qui veulent une référence fonctionnelle pour valider les promotions plutôt qu'un pipeline abstrait du type « il a bien scoré, déployons-le ».