RLVR と LLM に関する混乱は、Intro AI で検索を説明する方法 (少なくとも私の説明) によっておそらく明確になるでしょう。 何かを探しているなら、少なくとも何かがあなたに襲い掛かってきたら、それを認識できなければなりません。つまり、正しい候補を推測したり、正しい解にたどり着いたりしたなら、それが本当に正しいことを*検証*できるはずです。 つまり、すべては「検証者」から始まります。 ここで、検証者はブラックボックスまたは宣言型（候補が正しい解決策である場合の論理的なステートメントを提供する）になります。 ブラックボックスの場合は、ほとんどの場合、生成テスト形式の検索、つまり最も原始的な種類の検索を実行できます。(以下で説明するように、RLVR はこの点で理解できます)。 （宣言的であれば、候補ソリューションを検証するあらゆる異なる方法に対して、その基準を反転して検索を定義できます。たとえば、計画では、進行、回帰、または因果説明を介して計画を検証できます。それぞれを反転すると、進行計画、回帰計画、計画空間計画検索が得られます。） これには検証者の複雑さに関する要件がないことに注意してください。検証者が P にある場合、検索は NP になります。そうでない場合、検索はより高い複雑さのクラスになります。 == さて、RLVR と LLM についてですが、基本的に、RLVR は、LLM による生成とテストの検索の上に移植された RL プロセスとして捉えるのが最も適切です。 LLM-Modulo 論文 (https://t.co/mREKgH8mxk) で論じているように、最も原始的な種類の検索である生成とテストが笑いものにされない理由は、LLM がランダム ジェネレーターよりもはるかに優れたジェネレーターになり得るためです。 実際、RLVR は一種の「内部 LLM-Modulo」+ RL、つまりトレーニング時に軌道と報酬/正確性信号を生成するために使用される LLM-Modulo と考えることができます。これはその後、RL の助けを借りて非常にゆっくりとジェネレーターにコンパイルされます。 通常の検索の場合と同様に、RLVRで使用される検証器がクラスPに属する必要はありません。実際、検証がクラスPに属さない問題クラスでは、LRMが「うまく機能」している例が既に存在します。例えば、単純なSTRIPS計画でさえP空間完全です。正しい計画は指数関数的に長くなり、検証に指数関数的な時間がかかる可能性があるためです。ハノイの塔を思い出してください。別の例として、AlphaProofは、Lean検証が証明の長さに比例し、クラスPを超える可能性のある証明を扱います（複雑さは入力仕様に基づいていることに留意してください）。 言い換えると、 >> 検証ツールがあれば、LLM を使用して LLM-Modulo による生成・テスト方式であらゆる問題を解決できます。 >> トレーニング フェーズ中に合成問題インスタンスに対してこの LLM-Modulo を実行し、RL を使用して検証信号を基本 LLM にコンパイルすると、RLVR が得られます。 後者は「プログラミング 2.0」として議論されているもので、検証ツールがあれば、RLVR にモデルを取得させてその問題に対するより優れたジェネレーターにすることができます。 さらに詳しい内容を知りたい場合は、次の講演をご覧ください。
