圍繞 RLVR 和 LLM 的困惑或許可以透過我們在人工智慧入門課程中對搜尋的解釋來澄清（至少我是這樣解釋的）。 如果你在尋找某個東西，至少應該能夠在它出現並給你帶來麻煩時認出它。也就是說，如果你猜對了/找到了正確的候選答案，你應該能夠*驗證*它是否真的正確。 換句話說，這一切都始於「驗證者」。 現在，驗證器可以是黑盒式的，也可以是聲明式的（因為它提供了一個關於候選答案何時是正確的解決方案的邏輯語句）。 如果它是一個黑盒，那麼你基本上可以進行生成測試式的搜尋——也就是最原始的搜尋方式。 （正如我們將在下文看到的，RLVR 可以用這種方式來理解。） （如果是聲明式的，那麼對於驗證候選解的每一種不同方法，你都可以反轉該標準來定義搜尋。例如，在規劃中，你可以透過推進、回歸或因果解釋來驗證計畫——反轉它們分別得到推進規劃、回歸規劃和規劃空間規劃搜尋。） 請注意，以上內容對驗證器的複雜性沒有任何要求——如果驗證器屬於 P 類，則搜尋將在 NP 類中進行；否則，搜尋將在更高複雜度的類中進行。 == 現在來談談 RLVR 和 LLM，基本上，RLVR 可以看作是 RL 過程嫁接到 LLM 的生成和測試搜尋之上。 正如我們在 LLM-Modulo 論文 --https://t.co/mREKgH8mxk -- 中所論述的那樣，生成和測試（最原始的搜尋方式）之所以沒有被嘲笑，是因為 LLM 可以比隨機生成器好得多。 事實上，你可以把 RLVR 看作是一種「內部 LLM 模組」+ RL——或者說，LLM 模組在訓練時用於生成軌跡和獎勵/正確性訊號，然後藉助 RL 將其非常緩慢地編譯回生成器。 與普通搜尋一樣，RLVR 中使用的驗證器並不要求屬於 P 類！事實上，我們已經有一些 LRM 演算法在驗證不屬於 P 類的問題類別上表現良好。例如，即使是簡單的 STRIPS 規劃也是 P 空間完整的，因為正確的規劃可能非常長，因此驗證時間也呈指數級增長。想想漢諾塔問題！再舉一個例子，AlphaProof 可以處理那些精簡驗證時間與證明長度成正比的證明，因此其複雜度可能超出 P 類（記住，複雜度是相對於輸入規範而言的）。 換句話說， >> 如果您有驗證器，LLM 可以以產生-測試的方式使用 LLM-Modulo 解決任何問題。 >>如果在訓練階段對合成問題實例執行此 LLM-Modulo，並使用 RL 將驗證器訊號編譯到基礎 LLM 中，則可得到 RLVR。 後者就是人們常說的「程式設計 2.0」——如果你有一個驗證器，你可以讓 RLVR 讓模型成為解決問題的更好產生器。 如果你想了解更多詳情，可以看看這篇演講：
