Les confusions autour de RLVR et LLM peuvent probablement être éclaircies par la façon dont nous expliquons la recherche dans l'introduction à l'IA (du moins, c'est ainsi que je le fais). Si vous cherchez quelque chose, vous devriez au moins être capable de le reconnaître si cela vous pose problème. Autrement dit, si vous avez deviné/trouvé la bonne solution, vous devriez pouvoir *vérifier* qu'elle est bien correcte. Autrement dit, tout commence avec le « vérificateur ». Le vérificateur peut être une boîte noire ou déclaratif (en ce sens qu'il fournit une affirmation logique sur les cas où un candidat est une solution correcte). S'il s'agit d'une boîte noire, vous pouvez généralement effectuer une recherche de type génération-test, c'est-à-dire la forme la plus primitive de recherche. (Comme nous le verrons plus loin, RLVR peut être compris en ces termes). (S'il s'agit d'une recherche déclarative, alors pour chaque méthode de vérification de la solution candidate, vous pouvez inverser ce critère afin de définir la recherche. Par exemple, en planification, vous pouvez vérifier un plan par progression, régression ou explication causale ; inverser chacune de ces méthodes vous donne respectivement la planification par progression, la planification par régression et la recherche dans l'espace des plans.) Notez que rien de tout cela n'impose de contrainte quant à la complexité du vérificateur : si le vérificateur appartient à la classe P, alors la recherche appartiendra à la classe NP ; sinon, la recherche appartiendra à une classe de complexité supérieure. == Pour en venir à RLVR et aux LLM, RLVR peut être considéré comme un processus RL greffé sur une recherche de génération et de test par LLM. Comme nous le soutenons dans l'article LLM-Modulo --https://t.co/mREKgH8mxk -- la raison pour laquelle la génération et le test, qui est le type de recherche le plus primitif, ne sont pas rejetés d'emblée est que les LLM peuvent être des générateurs bien meilleurs que les générateurs aléatoires. En fait, on peut considérer RLVR comme une sorte de « LLM-Modulo interne » + RL -- ou LLM-Modulo utilisé au moment de l'entraînement pour générer des trajectoires et un signal de récompense/correction, qui est ensuite très lentement recompilé dans le générateur à l'aide de RL. Tout comme pour la recherche classique, rien de tout cela n'exige que le vérificateur utilisé dans RLVR appartienne à la classe P ! En réalité, nous disposons déjà de LRM performants sur des classes de problèmes dont la vérification n'est pas de classe P. Par exemple, même la planification STRIPS simple est P-Space-complet car le plan correct peut être exponentiellement long, et donc nécessiter un temps de vérification exponentiel. Pensez aux Tours de Hanoï ! Autre exemple : AlphaProof traitera des preuves dont la vérification Lean serait proportionnelle à la longueur de la preuve et peut donc être hors de la classe P (rappelons que la complexité est exprimée en termes de spécification d'entrée). Autrement dit, >> Les LLM peuvent être utilisés pour résoudre n'importe quel problème selon le modèle Générer-Tester avec LLM-Modulo si vous disposez de vérificateurs. >>Si vous effectuez ce LLM-Modulo pendant la phase d'entraînement sur des instances de problèmes synthétiques, et que vous utilisez RL pour compiler le signal du vérificateur dans le LLM de base, vous obtenez RLVR. C’est cette dernière approche que l’on présente comme la « Programmation 2.0 », où, si vous disposez d’un vérificateur, vous pouvez laisser RLVR obtenir le modèle pour qu’il devienne un meilleur générateur pour ce problème. Si vous souhaitez obtenir plus de détails, vous pouvez consulter cette conférence :
