HRPO-X v1.0.1 - Implémentation d’un framework d’optimisation du raisonnement hybride
(github.com/flamehaven01)TL;DR
- HRPO est une méthode de raisonnement basée sur l’apprentissage par renforcement qui mélange raisonnement latent + tokens de raisonnement discrets
- Les formules de l’article sont en elles-mêmes simples, mais lors de l’implémentation réelle, des instabilités, oscillations et échecs en environnement distribué apparaissent immédiatement
- HRPO-X est une implémentation indépendante centrée moins sur la fidélité stricte à l’article que sur la gestion des modes d’échec en production
Pourquoi je l’ai créé
- Les recherches existantes sur le raisonnement des LLM dépendent excessivement de la Chain-of-Thought produite en sortie
- En environnement de service réel :
- il n’est pas nécessaire d’exposer le processus de raisonnement
- dans certains cas, cette exposition constitue même un risque
- HRPO :
- conserve par défaut le latent reasoning
- n’utilise des discrete reasoning tokens qu’en cas de besoin
- Problème :
- l’implémentation de l’article ne suppose que des conditions idéales
- elle s’effondre facilement au début de l’apprentissage, en environnement distribué ou lors des changements de tâche
- une « implémentation conforme à l’article » mène immédiatement à un état inutilisable en production.
Résumé des points clés de l’article HRPO
1. Définition du problème
- Le raisonnement n’est pas redéfini comme une « génération de tokens en sortie », mais comme
- une action choisie par la politique (policy)
2. Structure de Hybrid Reasoning
- À chaque position de token :
- chemin latent (hidden state)
- chemin discret (explicit token)
- le mélange est décidé par une probabilité de gating
3. Méthode d’apprentissage
- Optimisation de politique basée sur REINFORCE
- Prévention de l’effondrement de la politique via la KL divergence
- Progressive incorporation :
- au début : actions principalement basées sur les embeddings
- ensuite : augmentation de la part du raisonnement via hidden state
Ce qui est réellement inclus dans HRPO-X
1. Stabilisation du cold start
- Suppression du planning epsilon fixe
- Application d’un epsilon adaptatif basé sur l’état de l’apprentissage
- Prévention du policy collapse en début d’entraînement
2. Atténuation des oscillations de r_min
- Réponse au problème d’oscillation des paramètres de ratio latent/discret
- Atténuation basée sur le momentum au lieu d’un simple clamp
3. Ghost-mode Validation
- Résolution du problème de fiabilité de la validation sur un petit nombre d’échantillons
- Estimation de la distribution d’échec basée sur le bootstrap
- Jugement sur la fiabilité statistique plutôt que sur une simple impression que « ça a l’air bien »
4. Gestion des partitions en environnement distribué
- partitions réseau
- incohérences de paramètres entre workers
- dérive du replay buffer
5. Adaptation aux changements de tâche
- Réponse aux problèmes de paramètres fixes lors de changements dans la distribution des tâches
- Application d’un task-aware r_min blending
Contenu du dépôt
- implémentation core minimale de HRPO
- modules de patch de stabilité
- code de test basé sur pytest
- script de démo à exécution unique
- documentation d’architecture et de conception
À qui cela peut servir
- chercheurs intéressés par le latent reasoning / raisonnement sans exposition du CoT
- ingénieurs ML qui explorent des architectures au-delà de RLHF / PPO
- développeurs souhaitant valider des idées d’article sous forme de code directement exécutable
- ingénieurs travaillant sur des environnements d’apprentissage RL distribués
- toute personne voulant voir la différence entre une « implémentation d’article » et une « implémentation exploitable en production »
Liens
-
GitHub (HRPO-X) :
https://github.com/flamehaven01/HRPO-X -
Article HRPO (arXiv) :
https://arxiv.org/abs/2505.18454 -
Implémentation des auteurs originaux :
https://github.com/Yueeeeeeee/HRPO
- Si ce travail peut servir de petite référence à quelqu’un, cela me suffit ❤️
- Le comparer à des pipelines RLHF / PPO existants peut aussi être utile
- Si vous avez des observations sur la reproduction, des cas d’échec ou des idées d’amélioration, les partager via les GitHub Issues serait d’une grande aide 💪
2 commentaires
Je suis entré en me disant « on ne sait jamais », mais comme prévu, hein mdr. Un repo de slop IA fabriqué à partir d’un gros tas d’hallucinations.
Merci pour votre retour franc.
Après vérification, il s’est avéré que, comme vous l’aviez indiqué, ce dépôt était bien un « AI Slop repo » reposant fortement sur des hallucinations de l’IA.
Il y avait des problèmes tels que des déclarations sans implémentation, un habillage excessif par la documentation et la terminologie, ainsi qu’une structure disproportionnée par rapport à l’algorithme.
À présent, la suppression de la documentation exagérée et des termes marketing, le nettoyage du code vide de substance,
et la suppression résolue des structures non fonctionnelles ont été menés à bien.
C’était un court commentaire d’une seule ligne, mais il m’a été d’une très grande aide.
En réalité, je mène actuellement des recherches et du développement sur une architecture qui transforme des articles de recherche en « code exploitable en production »,
et ce cas a été l’un des échecs révélés au cours de ce processus.
Grâce à votre remarque,
j’ai clairement pris conscience de la nécessité d’une logique permettant de définir et de valider structurellement l’AI slop,
et je travaille actuellement dans cette direction.
Plutôt que de prétendre à la perfection,
j’espère que cette tentative servira à vérifier comment éliminer et détecter les excès et l’esbroufe,
et s’il est possible d’aboutir à une mise en code de l’IA plus réaliste.
Même s’il ne s’agissait que d’une seule ligne de commentaire, je vous en remercie sincèrement,
et je vous remercie à nouveau profondément d’avoir pris de votre précieux temps.