TL;DR
検証器が「失敗」は高信頼に判定できる一方「成功」は未確認になり得る片側検証可能性（OSV）では、成功例を正解として強化学習すると抜け道を報酬化し得る。NOPOは信頼できる負例だけを抑制し、同じrollout群の非偽陽性候補の割合で更新量を調整する。原論文はコード・論理・数学でオラクル報酬がない条件の改善を報告するが、検証器依存や未検証領域の限界も残る。
既存手法との違い
原論文は標準的なRLVRとしてGRPOを主な比較対象にし、図1ではBase・GRPO・EM-RL・w-ReinforceとNOPOを比較している。条件はunit-test、制約チェック、LLM自己検証器を用いたコード・論理・数学ベンチマークで、オラクル報酬が使えない設定。NOPOの違いは、検証器の正例を正解として強化せず、信頼できる負例の抑制と群内の非偽陽性候補数による更新量調整だけを使う点。提示本文には比較の全数値や統計的有意性の詳細はない。
使える条件
利用条件は、検証器の負例が信頼できる一方、正例が誤りを含み得るOSV。入力は問題xと候補解y、出力は検証器の二値信号。例として公開単体テスト、形式・ドメイン制約、エラー探索型LLM自己検証器。on-policy rollout groupと参照方策が必要。コード・論理・数学の評価が中心。RAG固有の手法ではなく、計算資源や実運用コストの詳細は提示本文から確認できない。
限界と未検証の範囲
原論文の評価は提示されたコード・論理・数学ベンチマークと3種の検証器に限られ、他分野への一般化は未検証。LLM自己検証器は正解を誤って拒否し得る（負例の信頼性も完全ではない）。正例の誤り率qposは非無視で、非偽陽性候補の「数」だけをサポートに使うため、候補の質は保証されない。負例だけでは確率質量の移動先を直接指定できず、全滅グループでは更新方向が弱い。理論保証や計算資源、RAGへの適用は提示本文から確認できない。
図1: 提案手法の概要（本記事による図解）
解説
え、検証器って正解かどうか判定してくれるんじゃないの？
全部は無理。今回は“失敗はかなり信頼できるけど、成功はまだ未確認”っていう片側検証可能性、OSVの話。
失敗は確定、成功はグレーってこと？
そう。負例は信頼できる反例だけど、正例はチェックを通っただけの非偽陽性候補。正解扱いすると抜け道を報酬化し得る。
それは危ない。テストを通るズルい解を褒めちゃう感じ？
その通り。だから普通のRLVRみたいに正例を強化しない。
じゃあNOPOは何をするの？
信頼できる負例だけを抑制する。参照方策に対する負例抑制損失と、同じrollout群の非偽陽性候補の割合で更新量を調整する群レベルアダプタを組み合わせる。
正例はラベルなし扱いで、負例だけ消す。でも負例だけだと、どこに確率を動かすか分からなくない？
そこが難点。だから群内に非偽陽性候補がどれくらいあるかで更新を弱めたり止めたりする。候補の数だけ使って、正解とはみなさない。
なるほど。負例抑制にブレーキと方向づけを足してる感じだ。
かなり近い。全滅グループでは更新方向の拠り所が弱い、っていう制約も残る。
評価はどうやってるの？
原論文はunit-test、制約チェック、LLM自己検証器を使って、コード・論理・数学でオラクル報酬がない条件を評価。入力は問題と候補解、出力は検証器の二値信号で、on-policyのrollout群と参照方策が前提。比較は主にGRPOで、図1ではBase、GRPO、EM-RL、w-ReinforceとNOPOを比べてる。
オラクル報酬なしで？ それでpass@kが改善したって報告？
そう。pass@kがベースラインより改善し、推論時スケーリングやクロスベンチマーク転移でも利得が続く、と報告してる。
へえ。じゃあ実務でもそのまま使える？
注意はある。評価はコード・論理・数学と3種の検証器に限られて、他分野は未検証。LLM自己検証器は正解を誤って拒否し得るから、負例の信頼性も完全じゃない。
正例の誤り率qposも無視できないし、候補の“数”だけ見るから質は保証されない、ってことだね。
あと理論保証や計算資源、RAGへの適用は提示本文からは確認できない。検証器依存の限界は残る。
じゃあ私のレポートも、提出前チェックだけ通れば“非偽陽性候補”ってことでいい感じ？
それはただの未検証。単位は保証されない。