D'accord, parlons des frameworks, des bibliothèques, du RL, et pourquoi je n'aime probablement pas votre code de base RL préféré. Oui, y compris celui-là. La chose inhabituelle avec le RL, c'est que l'algorithme est la partie facile. GRPO est une équation d'une seule ligne sur quelques logprobs. Si vous avez les données, le calcul de la perte est trivial, et ensuite, vous l'utilisez probablement avec une bibliothèque de rétropropagation de votre choix. Mais c'est le problème : obtenir les données. C'est un vrai casse-tête. Dans le RL classique, vous devez faire des rollouts, peut-être tronquer certains épisodes, et gérer les fins en conséquence. Si vous ne voulez pas être un escargot, vous voudrez vectoriser l'environnement et adapter l'algorithme pour cela. Si vous voulez faire un LLM, vous devez faire toutes les absurdités qui permettent aux LLM de tenir en mémoire. Vous devez faire attention à vos invites, masquer les bonnes parties pour la perte. Vous avez besoin d'un moteur de génération décent (vLLM), ce qui rend ensuite difficile la mise à jour des poids. Si vous voulez faire du RL LLM multi-agents multi-tours, autant faire un sudoku de commit. Bien que nous ayons de nombreux désaccords sur presque tout ce qui concerne le RL, je pense que la Pufferlib de @jsuarez5341 illustre ce point de manière magnifique. C'est sans aucun doute incroyable dans ce qu'elle fait - entraîner des algos RL sur des environnements simulés très très rapidement. Mais la plupart de sa nouveauté est pure infra. Les algorithmes de base sont largement les mêmes qu'ils l'ont été depuis des années, et je parie qu'ils représentent moins de 10 % de l'effort d'ingénierie global. Naturellement, cela a des implications sur le code que vous devez écrire pour faire quoi que ce soit au-delà de l'exécution des exemples intégrés. Ce que je trouve encore et encore, c'est que pour de nombreux problèmes de recherche suffisamment non triviaux (lisez : intéressants), il faut un temps similaire pour (a) écrire la chose depuis zéro / depuis des primitives simples, ou (b) adapter un framework existant pour accueillir des idées folles. Dans le premier cas, vous vous concentrez sur l'écriture de la logique réelle. Dans le second, vous vous débattez avec le framework pour vous permettre d'ajouter la logique. Je sais ce que je préfère. Tout cela est parce que l'algorithme est la partie facile. L'infrastructure est le casse-tête. Donc, chaque fois que vous êtes en position de choisir - utilisez les outils qui simplifient l'infrastructure, et écrivez la boucle d'entraînement vous-même. Ne construisez pas des frameworks, construisez des bibliothèques. Vous vous remercierez plus tard. Un grand merci à mon superviseur de Master d'autrefois, qui a été le premier à me dire de laisser tomber rllib et de simplement écrire PPO moi-même dans PyTorch. Et à @hallerite pour m'avoir inspiré à enfin écrire ce coup de gueule. Je pourrais écrire un véritable effortpost avec des exemples à un moment donné dans le futur si les gens le demandent.