Reef의 OpenClaw-RL 레시피, 릴리스 게이트 뒤에 점수화된 가중치 업데이트를 둔다

OpenClaw 태스크를 채점하는 것은 쉬운 부분입니다. 더 어려운 질문은 그 결과로 나온 가중치 업데이트가 실제 서빙 상태에 적용되기 전에 어떤 일이 일어나느냐입니다. Reef의 저장소는 점수만 믿지 않고 그 업데이트를 릴리스 게이트 뒤에 두는 구체적인 OpenClaw-RL 가중치 진화 레시피를 제공합니다.

구체적인 레시피

설정은 제한적이고 구체적입니다. 이 수치들을 일반적인 벤치마크가 아니라 재현 목표로 생각하세요:

• 72개의 GSM8K 문제를 72개의 태스크로 취급 — 각 문제는 루프에서 자체적인 태스크 단위입니다.
• Qwen3-4B가 정책 및 프로세스 보상 모델 역할을 담당합니다.
• Qwen3-32B가 학생 모델입니다.
• 실행에 7개의 GPU가 사용됩니다.
• 프로젝트는 14번째 세션에서 세 번 연속 통과 기준을 충족했다고 보고합니다.
• 체크인된 학습 곡선은 처음 36개 세션을 포함합니다.

게이팅 로직이 흥미로운 부분입니다. 채점된 업데이트는 테스트를 통과하기 전까지 — 이 경우 세 번 연속 통과 — 작업 버전을 대체하도록 승격되지 않습니다. 이것이 "보상 모델이 좋아했다"와 "서빙해도 안전하다"의 차이입니다.

이 수치들이 의미하는 것 (그리고 의미하지 않는 것)

이것들은 재현 목표입니다. 모든 OpenClaw 워크로드를 벤치마킹하는 것이 아니며, 일반적인 OpenClaw 하네스 어댑터를 확립하는 것도 아닙니다. 14번째 세션 / 36세션 곡선을 보편적인 주장으로 읽는다면 잘못 읽은 것입니다. 이것은 하나의 태스크 패밀리(GSM8K)에 하나의 모델 스택을 사용한 하나의 레시피일 뿐입니다.

권장 첫 단계

접근 방식을 적용하기 전에 검증하고 싶다면:

1. 객관적 검증기가 있는 OpenClaw 태스크로 시작하세요 — 분위기 기반 채점은 안 됩니다.
2. 레시피를 그대로 재현하세요.
3. 의도적으로 잘못된 가중치 후보가 서빙 상태를 변경할 수 없음을 확인하세요. 이것이 실제로 중요한 릴리스 게이트 속성입니다.
4. 그것이 통과한 후에야 최적화가 실제 태스크로 전이되는지 물어볼 가치가 있습니다.

3단계는 사람들이 건너뛰는 단계입니다. 쓰레기 업데이트가 게이트를 통과할 수 있다면 나머지 파이프라인은 장식일 뿐입니다.

누구를 위한 것인가

OpenClaw 위에 RL 스타일 가중치 진화 루프를 구축하는 개발자로서, 추상적인 "점수가 좋으니 배포하자" 파이프라인보다는 프로모션을 게이팅하는 실제 참조를 원하는 사람들을 위한 것입니다.