MedicalGPT : une chaîne d'entraînement médicale du pré-entraînement au DPO

Le pipeline ChatGPT transposé au domaine médical

Le problème visé est précis : un modèle généraliste ne connaît ni le vocabulaire clinique, ni les tournures des comptes rendus, ni la manière dont un patient formule une question. Le README présente MedicalGPT comme une implémentation de la chaîne d'entraînement de ChatGPT appliquée à la médecine, avec un pré-entraînement incrémental (PT), une mise au point supervisée (SFT), puis des méthodes de préférence : RLHF avec modèle de récompense, DPO, ORPO, GRPO et, depuis la version 2.7, OPD (On-Policy Distillation). Le public visé n'est pas le clinicien : c'est l'ingénieur ou l'équipe de recherche qui possède un corpus médical et veut y adapter un modèle open source. Le README rattache explicitement la partie RLHF à un exposé d'Andrej Karpathy, la partie DPO à l'article Direct Preference Optimization, et ORPO à l'article Monolithic Preference Optimization without Reference Model. La filiation méthodologique est donc documentée, ce qui facilite la vérification des choix d'implémentation. Notez que le PT est marqué comme optionnel dans la liste des fonctionnalités : beaucoup d'équipes commenceront directement au SFT sur un modèle déjà instruct.

Ce que le dépôt ne fait pas pour vous

Le dépôt fournit du code d'entraînement, pas un modèle médical validé. Le README décrit des étapes et des scripts, il ne publie ni protocole d'évaluation clinique, ni jeu de test annoté par des médecins. Un modèle obtenu après DPO sur des préférences médicales peut produire des réponses plus fluides et mieux alignées sur les attentes des annotateurs sans devenir fiable sur le fond. La licence Apache-2.0 couvre le code du dépôt ; elle ne dit rien des licences des modèles de base que vous téléchargez, ni de celles de vos données d'entraînement. Si votre corpus contient des dossiers patients, la question du cadre réglementaire se pose avant la question technique, et le dépôt ne l'aborde pas. Autre limite pratique : la documentation disponible ici est un README et un wiki externe. Les détails de chaque hyperparamètre, la gestion des échecs de convergence ou le comportement en cas de données déséquilibrées ne sont pas visibles dans le matériel fourni. Prévoyez de lire le code avant de lancer une campagne coûteuse.

Les étapes d'entraînement et leur enchaînement

La séquence décrite dans le README suit quatre temps. Le PT réentraîne le modèle sur des documents de domaine pour déplacer la distribution des données. Le SFT construit un jeu d'instructions et ajuste le modèle préentraîné pour aligner l'intention et injecter les connaissances métier. Vient ensuite le choix entre deux familles. D'un côté le RLHF, en deux mouvements : un modèle de récompense entraîné sur un classement de préférences humaines selon les principes « helpful, honest, harmless », puis une phase de renforcement où ce modèle de récompense guide la mise à jour de la politique du modèle SFT. De l'autre, DPO, qui optimise directement le modèle de langage sur les préférences sans passer par un modèle de récompense séparé. Le README affirme que DPO est plus simple à mettre en œuvre et à entraîner que le RLHF. ORPO va plus loin dans cette direction en supprimant le modèle de référence. GRPO, ajouté en version 2.4, propose une voie purement RL, en LoRA comme en paramètres complets. OPD, en 2.7, ajoute une distillation on-policy avec son propre point d'entrée. Le choix entre ces méthodes est un arbitrage entre coût d'infrastructure et contrôle du comportement final.

Scripts, points d'entrée et formats de données

L'usage passe par des scripts shell : le README cite scripts/run_orpo.sh pour ORPO et scripts/run_opd.sh pour la distillation introduite en 2.7. Les points d'entrée Python sont nommés de façon cohérente, avec par exemple training/opd_training.py pour la version 2.7. La version 2.6 a ajouté la prise en charge du Function Call et des outils d'agent, avec du code de conversion et d'analyse pour les différents formats d'outils selon les modèles, accompagné d'exemples de données dans le dossier data, sous toolcall. La version 2.5 a étendu le support à la série Qwen3.5, y compris les variantes Base, Instruct et MoE, sur l'ensemble PT/SFT/DPO/ORPO/GRPO, avec de nouveaux gabarits de conversation nommés qwen3, qwen3_5, qwen3_nothink et qwen3_5_nothink, et la prise en charge de l'entraînement MoE sous DeepSpeed ZeRO-3. Ce dernier point compte : les variantes MoE ne se contentent pas d'un script de lancement standard, et le README indique explicitement que ZeRO-3 est la configuration prévue. Sur les versions antérieures, on trouve aussi la génération de données SFT de dialogue médecin-patient via le dossier role_play_data, avec plusieurs fournisseurs LLM cités (OpenAI, Doubao, MiniMax). La version 1.7 a introduit un démonstrateur de questions-réponses sur fichiers, demo/chatpdf.py, qui combine le modèle ajusté et une base de connaissances.

Ce que la documentation laisse dans l'ombre

Le README est un journal de versions autant qu'un guide. Les entrées de changelog s'accumulent depuis la version 0.2 en juin 2023, et chaque nouvelle méthode arrive avec un script et quelques paramètres, sans section dédiée aux cas d'échec. Rien dans le matériel fourni n'indique comment détecter un effondrement de la politique en RL, ni quel volume de préférences est nécessaire pour que le DPO produise un effet mesurable. Le wiki est référencé mais son contenu n'est pas inclus ici, donc les détails de configuration par méthode restent hors de portée de cette analyse. Autre point de vigilance : la multiplication des méthodes dans un même dépôt signifie que les scripts partagent probablement des utilitaires de chargement de données et de tokenisation. Une modification du format d'entrée pour un cas d'usage peut donc se répercuter sur d'autres scripts. Sans exécution, je ne peux pas confirmer ce couplage, mais la structure du dépôt (un dossier training, un dossier scripts, un dossier data) le rend plausible. Testez chaque script isolément avant de les enchaîner en production.

Alternatives : entraîner soi-même ou déléguer

Deux voies se dessinent. La première consiste à utiliser une bibliothèque d'ajustement généraliste, comme les outils de la famille PEFT ou les implémentations DPO publiées par les auteurs de l'article, et à écrire soi-même l'enchaînement des étapes. L'avantage est un contrôle total sur chaque phase et une surface de code plus petite à auditer. L'inconvénient est qu'il faut recâbler la préparation des données, les gabarits de conversation et le lancement distribué. MedicalGPT prend le parti inverse : l'enchaînement est déjà écrit, les gabarits de plusieurs familles de modèles sont fournis, et les scripts se ressemblent d'une méthode à l'autre. La contrepartie est une dépendance à la structure du dépôt et à ses conventions de données. La deuxième voie consiste à ne pas entraîner du tout et à utiliser une API de modèle avec des documents médicaux en contexte. C'est plus rapide à mettre en place, mais cela exclut l'ajustement sur des préférences locales et pose la question de l'envoi de données de santé à un tiers. Le choix dépend donc moins de la qualité du code que de la sensibilité de vos données et de votre besoin de contrôle sur les poids.

Coût de maintenance et implications de licence

Le rythme de publication est soutenu : les versions 2.5, 2.6 et 2.7 sont datées d'avril 2026, à quelques jours d'intervalle, et la dernière poussée sur la branche principale est datée du 3 juin 2026. Cela signifie que les interfaces de script et les paramètres peuvent bouger entre deux versions mineures. Si vous épinglez une version, prévoyez de relire les notes de publication avant toute mise à jour, en particulier autour des gabarits de conversation et des formats de données d'outils introduits en 2.6. La licence Apache-2.0 s'applique au code du dépôt : usage commercial permis, avec conservation des mentions de copyright et du fichier de licence. Elle ne s'étend ni aux poids des modèles de base que vous téléchargez, ni à vos données. Vérifiez séparément la licence de chaque modèle de base, car certaines familles imposent des conditions d'usage. Sur le plan matériel, le README mentionne DeepSpeed ZeRO-3 pour les modèles MoE, ce qui suppose un environnement multi-GPU correctement configuré ; l'entraînement en paramètres complets sur un modèle de taille moyenne n'est pas réalisable sur une seule carte grand public.

Conclusion éditoriale

Adoptez MedicalGPT si vous disposez déjà de données médicales annotées et d'un ingénieur capable de lire des scripts shell et des fichiers de configuration Python : les entrées training/sft_training.py, training/dpo_training.py et scripts/run_orpo.sh sont le bon point de départ. Passez votre chemin si vous attendez un modèle cliniquement validé ou un service hébergé. Avant tout entraînement, ouvrez scripts/run_sft.sh et vérifiez que les chemins de modèle de base et de jeu de données correspondent à votre environnement, puis contrôlez le format de votre corpus médical contre les exemples du dossier data, car une seule colonne mal nommée fait échouer le chargement.

Sources officielles

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. shibing624/MedicalGPT on GitHub