PPO (Proximal Policy Optimization)
Pourquoi PPO existe
Les algorithmes de policy gradient classiques (comme REINFORCE) souffrent d’un probleme fondamental : la taille des mises a jour de la politique est difficile a controler. Une mise a jour trop grande peut detruire les performances acquises, entrainant un effondrement de l’entrainement. Une mise a jour trop petite ralentit l’apprentissage considerablement.
TRPO (Trust Region Policy Optimization), le predecesseur de PPO, resolvait ce probleme en imposant une contrainte KL-divergence sur les mises a jour de politique. Mais TRPO est complexe a implementer (il necessite un calcul de la matrice hessienne et une ligne search par contrainte conjuguee). PPO atteint une stabilite comparable avec une approche beaucoup plus simple : le clipping.
Fonctionnement de PPO
L’objectif clippe
Le coeur de PPO est sa fonction objectif clippee. Au lieu de contraindre explicitement la divergence KL entre l’ancienne et la nouvelle politique (comme TRPO), PPO limite le ratio de probabilite entre les deux politiques dans un intervalle [1-epsilon, 1+epsilon], ou epsilon est typiquement 0.2.
Concretement, pour chaque action echantillonnee, on calcule le ratio r(t) = pi_new(a|s) / pi_old(a|s). Si la recompense de cette action est positive (l’action etait bonne), PPO augmente sa probabilite mais la coupe a (1+epsilon). Si la recompense est negative, PPO diminue la probabilite mais la coupe a (1-epsilon). Ce mecanisme de clipping empeche les mises a jour trop agressives dans les deux directions.
L’objectif final est le minimum entre l’objectif non clippe et l’objectif clippe : L = min(r(t) * A(t), clip(r(t), 1-epsilon, 1+epsilon) * A(t)), ou A(t) est l’avantage estime (advantage function). Cette formulation pessimiste garantit que PPO ne surestimera jamais le benefice d’une mise a jour.
Fonction d’avantage (GAE)
PPO utilise le Generalized Advantage Estimation (GAE) pour calculer l’avantage A(t). Le GAE combine les estimations a differents horizons temporels via un parametre lambda (typiquement 0.95). Un lambda proche de 1 reduit le biais mais augmente la variance ; un lambda proche de 0 fait l’inverse. Le GAE offre un compromis reglable entre biais et variance.
Architecture actor-critic
PPO fonctionne en mode actor-critic. Le reseau actor produit la politique (distribution sur les actions). Le reseau critic estime la fonction de valeur V(s) utilisee pour calculer l’avantage. En pratique, les deux reseaux partagent souvent les memes couches inferieures, avec des tetes separees pour la politique et la valeur. La perte totale combine la perte politique (clippee), la perte de valeur et un terme d’entropie qui encourage l’exploration.
Implementation pratique
Boucle d’entrainement
L’entrainement PPO suit un cycle collecte-optimisation. L’agent interagit avec l’environnement pendant N pas de temps (phase de collecte), stockant les etats, actions, recompenses et probabilites dans un buffer. Puis, les donnees du buffer sont utilisees pour plusieurs epoques d’optimisation (typiquement 3 a 10) avec des mini-batchs. Apres l’optimisation, le buffer est vide et le cycle recommence.
Cette approche par batchs est naturellement parallelisable : plusieurs instances de l’environnement collectent des donnees simultanement, accelerant l’entrainement. C’est un avantage majeur de PPO pour les applications a grande echelle.
Hyperparametres cles
| Parametre | Valeur typique | Role |
|---|---|---|
| Epsilon (clip) | 0.2 | Limite la taille des mises a jour |
| Learning rate | 3e-4 (jeux) / 1e-5 (LLM) | Vitesse d’apprentissage |
| Lambda (GAE) | 0.95 | Compromis biais-variance |
| Gamma (discount) | 0.99 | Horizon temporel |
| Epoques PPO | 3-10 | Nombre de passes sur le buffer |
| Mini-batch size | 64-256 | Taille des sous-ensembles |
| Coeff. entropie | 0.01 | Force d’exploration |
PPO dans le RLHF
Le role le plus impactant de PPO en 2026 est dans le RLHF pour l’alignement des LLM. Dans ce contexte, l’agent est le LLM, l’environnement est le prompt, l’action est la generation d’une reponse complete, et la recompense est le score attribue par le reward model.
Le pipeline RLHF avec PPO necesssite quatre modeles en memoire : le modele actif (policy), le modele de reference (pour la penalite KL), le reward model et le critic. Pour chaque batch de prompts, le modele actif genere des reponses, le reward model les score, et PPO met a jour le modele actif pour maximiser les scores tout en restant proche du modele de reference.
La penalite KL est cruciale : sans elle, le modele pourrait degenerer vers des reponses qui exploitent les failles du reward model (reward hacking). La contrainte KL maintient le modele dans une zone ou le reward model est fiable.
PPO vs autres algorithmes
| Algorithme | Famille | Avantage vs PPO | Inconvenient vs PPO |
|---|---|---|---|
| TRPO | Policy gradient | Garanties theoriques | Plus complexe, plus lent |
| SAC | Actor-Critic | Meilleure exploration continue | Moins adapte au discret/LLM |
| A2C | Actor-Critic | Plus simple | Moins stable |
| REINFORCE | Policy gradient | Tres simple | Haute variance, instable |
| GRPO | Policy gradient | Pas de critic, plus leger | Moins eprouve |
PPO vs GRPO
DeepSeek a introduit le GRPO (Group Relative Policy Optimization) pour entrainer DeepSeek-R1. Le GRPO elimine le reseau critic en utilisant les recompenses relatives au sein d’un groupe de reponses generees pour le meme prompt. Au lieu d’estimer V(s) avec un critic, GRPO calcule l’avantage comme l’ecart de recompense par rapport a la moyenne du groupe. Cela reduit la memoire GPU et simplifie le pipeline. Les premiers resultats de DeepSeek-R1 sont tres prometteurs, suggerant que le critic n’est pas toujours necessaire.
Applications au-dela des LLM
PPO reste dominant en robotique simulee (locomotion, manipulation), dans les jeux video (OpenAI Five pour Dota 2, agents Minecraft), en controle industriel et en optimisation combinatoire. Sa versatilite lui permet de traiter aussi bien des espaces d’actions discrets (jeux, LLM) que continus (robotique). Les implementations de reference sont disponibles dans Stable Baselines3 (Python), CleanRL (implementation minimale), et TRL (pour le RLHF).
Limites de PPO
Malgre sa popularite, PPO a des limites connues. L’efficacite en donnees est faible : les donnees du buffer sont utilisees pour quelques epoques puis jetees (on-policy). Les methodes off-policy comme SAC reutilisent les donnees plus efficacement. Le clipping est une heuristique, pas une contrainte formelle : il n’y a pas de garantie theorique forte sur la taille des mises a jour. La sensibilite aux details d’implementation (normalisation des recompenses, initialisation des poids, scheduling du learning rate) est bien documentee : de petites variations peuvent produire de grandes differences de performances.
FAQ – PPO
Pourquoi PPO est-il prefere a TRPO ?
PPO offre une stabilite comparable a TRPO avec une implementation beaucoup plus simple. TRPO necessite le calcul de la matrice hessienne et une optimisation sous contrainte complexe. PPO remplace tout cela par un simple clipping de la fonction objectif, ce qui le rend plus rapide et plus facile a debugger.
Que signifie le epsilon dans PPO ?
Epsilon (typiquement 0.2) definit l’intervalle dans lequel le ratio de probabilite est autorise. Le ratio pi_new/pi_old est clippe entre 1-epsilon et 1+epsilon. Un epsilon plus petit limite davantage les mises a jour (plus stable, plus lent). Un epsilon plus grand autorise des changements plus agressifs (plus rapide, potentiellement instable).
PPO est-il adapte a tous les problemes RL ?
PPO est tres versatile mais n’est pas optimal partout. Pour les espaces d’actions continus avec des environnements complexes, SAC peut etre superieur. Pour les problemes avec replay buffer et donnees couteuses, les methodes off-policy sont preferables. PPO excelle dans les cas ou la stabilite et la parallelisation sont prioritaires.
Combien de GPU faut-il pour le RLHF avec PPO ?
Pour un modele 7B, comptez 4 a 8 GPU A100/H100 (il faut charger 4 modeles). Pour un modele 70B, 32 a 64 GPU sont necessaires. Le GRPO ou le DPO reduisent ces exigences en eliminant certains modeles du pipeline. C’est une des raisons pour lesquelles le DPO gagne en popularite dans la communaute open source.
PPO sera-t-il remplace par GRPO ou DPO ?
Pas entierement. Le DPO elimine le RL mais ne le remplace pas dans tous les cas (il est offline par defaut). Le GRPO simplifie PPO mais reste dans le cadre RL. PPO continue d’etre utilise par OpenAI, Google et d’autres pour les modeles de pointe. La tendance est plutot a la coexistence : DPO pour les cas simples, PPO/GRPO pour les cas complexes et a grande echelle.