围绕 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 使模型成为解决该问题的更好生成器。 如果你想了解更多详情，可以看看这个演讲：
