Subbarao Kambhampati (కంభంపాటి సుబ్బారావు)(@rao2z)의 스레드

RLVR과 LLM을 둘러싼 혼란은 아마도 Intro AI에서 검색을 설명하는 방식을 통해 해소될 수 있을 것입니다(적어도 제가 설명하는 방식은 그렇습니다). 무언가를 찾고 있다면, 적어도 그것이 나타나서 당신을 물어뜯을 때 그것을 알아볼 수 있어야 합니다. 즉, 정답을 맞히거나 정답에 도달했다면, 그것이 실제로 정답인지 *확인*할 수 있어야 합니다. 다시 말해, 모든 것은 "검증자"로부터 시작됩니다. 이제 검증자는 블랙박스이거나 선언적일 수 있습니다(후보가 올바른 솔루션인 경우에 대한 논리적 진술을 제공함). 블랙박스라면 대부분 생성-테스트 스타일 검색, 즉 가장 원시적인 검색을 수행할 수 있습니다. (아래에서 살펴보겠지만, RLVR은 이러한 관점에서 이해할 수 있습니다.) (선언적이라면 후보 솔루션을 검증하는 모든 방법에 대해 해당 기준을 반전하여 검색을 정의할 수 있습니다. 예를 들어 계획에서 진행, 회귀 또는 인과 설명을 통해 계획을 검증할 수 있습니다. 각 기준을 반전하면 진행 계획, 회귀 계획 및 계획 공간 계획 검색이 제공됩니다.) 이 중 어느 것도 검증자의 복잡도에 대한 요구 사항이 없다는 점에 유의하세요. 검증자가 P에 있으면 검색은 NP에서 수행되고, 그렇지 않으면 검색은 더 높은 복잡도 클래스에서 수행됩니다. == 이제 RLVR과 LLM에 대해 이야기해 보겠습니다. 기본적으로 RLVR은 LLM이 생성하고 테스트하는 검색에 접목한 RL 프로세스로 보는 것이 가장 좋습니다. LLM-Modulo 논문에서 주장했듯이(https://t.co/mREKgH8mxk), 가장 원시적인 종류의 검색인 생성 및 테스트를 비웃지 않는 이유는 LLM이 난수 생성기보다 훨씬 더 나은 생성기가 될 수 있기 때문입니다. 사실, RLVR은 일종의 "내부 LLM-모듈로" + RL -- 또는 LLM-모듈로로 생각할 수 있는데, 이는 학습 시간에 궤적과 보상/정확성 신호를 생성하는 데 사용된 후 RL의 도움을 받아 매우 천천히 생성기로 다시 컴파일됩니다. 일반 탐색의 경우와 마찬가지로, 이 모든 것이 RLVR에 사용되는 검증기가 클래스 P에 있을 필요는 없습니다! 사실, 검증이 클래스 P에 속하지 않는 문제 클래스에서 "잘 작동하는" LRM이 이미 존재합니다. 예를 들어, 간단한 STRIPS 계획조차도 P-공간 완전성을 갖습니다. 올바른 계획은 기하급수적으로 길어질 수 있고, 따라서 검증에 지수적인 시간이 걸릴 수 있기 때문입니다. 하노이의 탑을 생각해 보세요! 또 다른 예로, AlphaProof는 Lean 검증이 증명 길이에 비례하여 클래스 P를 초과할 수 있는 증명을 처리합니다(복잡도는 입력 사양의 관점에서 계산된다는 점을 기억하세요). 다시 말해서, >> 검증자가 있다면 LLM-Modulo를 사용하여 Generate-Test 방식으로 모든 문제를 해결할 수 있습니다. >>합성 문제 인스턴스에 대한 훈련 단계에서 이 LLM-Modulo를 수행하고 RL을 사용하여 검증 신호를 기본 LLM으로 컴파일하면 RLVR이 됩니다. 후자는 "프로그래밍 2.0"으로 떠돌고 있는데, 검증자가 있다면 RLVR이 해당 문제에 대한 더 나은 생성기를 만들 수 있습니다. 더 자세히 알고 싶으시다면 이 강연을 확인해 보세요: https://t.co/oiCQQ73KvV