Hugging Face optimise ses publications avec l'IA et l'open source

Une nouvelle ère pour les publications de Hugging Face

Hugging Face, un acteur majeur dans le domaine de l'intelligence artificielle, a récemment transformé son processus de publication de logiciels. Le cœur de cette transformation réside dans l'utilisation du client Python huggingface_hub, qui sert de fondation à l'écosystème de la société. Ce client est essentiel pour de nombreuses bibliothèques telles que transformers, datasets, diffusers, et sentence-transformers. Ces bibliothèques s'appuient sur le Hub pour communiquer efficacement. Jusqu'à récemment, Hugging Face publiait de nouvelles versions toutes les quatre à six semaines. Désormais, grâce à un flux de travail automatisé via GitHub Actions, les publications sont hebdomadaires. Chaque semaine sans nouvelle version est une semaine de corrections et de fonctionnalités bloquées sur la branche principale. Ce changement a été rendu possible grâce à l'utilisation d'outils open source et de modèles à poids ouverts, tout en maintenant une intervention humaine là où le jugement est crucial. L'objectif était de créer un système que d'autres développeurs pourraient facilement adopter et adapter sans nécessiter de contrats avec des fournisseurs ou d'infrastructures complexes.

Un processus initialement manuel

Le processus de publication précédent de Hugging Face était en grande partie manuel, bien qu'il ait intégré certains éléments automatisés. Lorsqu'un tag était poussé, une publication sur PyPI était déclenchée. Cependant, de nombreuses étapes restaient manuelles. Cela incluait la création de branches de version, l'augmentation de la version dans le fichier init.py, l'engagement, le tag et la poussée. De plus, il fallait surveiller les exécutions CI en aval et trier les échecs, lire chaque PR fusionnée depuis la dernière version, et rédiger des notes de version à la main. Ces notes devaient être organisées par thème, avec un contexte approprié, et ne pas ressembler à un simple journal de git. Après la période de RC, la version stable était publiée, suivie d'une annonce interne sur Slack et de publications sur les réseaux sociaux. Enfin, une PR post-publication était ouverte pour augmenter la branche principale à la prochaine dev0. La rédaction de notes de version était particulièrement chronophage, nécessitant de compiler des dizaines de PR sur divers sujets, ce qui représentait une demi-journée de travail étalée sur plusieurs jours.

Automatisation et intervention humaine

Pour rationaliser ce processus, Hugging Face a identifié deux types de tâches. Certaines étapes, purement mécaniques, pouvaient être automatisées : augmentation de la version, engagement, tag, poussée, ouverture de branches de test en aval, et ouverture de la PR post-publication. Ces tâches ne nécessitent pas de réflexion et doivent simplement être exécutées dans le bon ordre, ce qui est l'un des avantages d'un flux de travail CI. D'autres tâches, comme la rédaction des notes de version et la formulation d'annonces, nécessitent un jugement humain. C'est ici que l'IA intervient, transformant une page blanche en un premier brouillon solide en quelques secondes. Cependant, il est crucial de rester vigilant, car un brouillon incorrect peut être plus problématique qu'aucun brouillon.

Un design ouvert et réutilisable

Lors de la refonte du processus, Hugging Face a établi une contrainte claire : chaque partie du système devait être accessible et réutilisable par n'importe quel mainteneur. Pas de modèles fermés ni de plateformes propriétaires. La pile technologique comprend l'orchestration de la publication, l'exécution de l'agent qui pilote le modèle, un modèle à poids ouverts (actuellement GLM-5.2 de Z.ai), la rédaction des notes de version et de l'annonce Slack, les fournisseurs d'inférence HF, et la publication du package sur PyPI. Un principe clé est que le modèle rédige, mais un humain décide. Les modèles de langage sont efficaces pour transformer des titres de PR en notes lisibles, mais ils ne doivent pas être utilisés aveuglément. Le flux de travail est donc supervisé par un humain : le modèle produit un premier jet, un script vérifie son travail, et un humain révise avant toute publication.

Vue d'ensemble du pipeline

Le flux de travail complet est encapsulé dans un fichier unique, .github/workflows/release.yml, déclenché manuellement depuis l'interface Actions. Il nécessite une seule entrée :

workflow_dispatch:
- minor-prerelease

Les tâches s'enchaînent ensuite dans l'ordre suivant :

• Préparation : Calcul de la prochaine version, création ou réutilisation de la branche de publication, augmentation de version, engagement, tag, et poussée.
• Publication sur PyPI : Construction et téléchargement de huggingface_hub. En parallèle, construction et téléchargement du CLI hf en tant que package PyPI distinct.
• Notes de version : Diffusion de la plage de commits depuis le dernier tag, extraction des métadonnées des PR depuis l'API GitHub, et rédaction d'un changelog structuré par le modèle. Ce brouillon est enregistré en tant que publication GitHub.
• Branches de test en aval : Pour les RC, ouverture de branches dans transformers, datasets, diffusers, sentence-transformers avec le RC bloqué, pour vérifier rapidement si quelque chose a été cassé.
• Annonce Slack : Lecture des notes et production d'une annonce interne dans le ton de l'équipe.
• Archivage des notes : Téléchargement du brouillon brut de l'IA et de la version éditée par un humain dans un Bucket Hugging Face.
• Augmentation post-publication : Après une publication stable, ouverture d'une PR sur la branche principale pour augmenter à la prochaine dev0.
• Commentaire sur les PR expédiées : Laisser un commentaire "cela a été expédié dans vX.Y.Z" sur chaque PR dans la publication.
• Synchronisation de la documentation CLI : Ouverture d'une PR sur le dépôt de compétences avec la documentation des compétences CLI hf régénérées.
• Rapport à Slack : Chaque étape publie son statut en tant que réponse de fil ; une tâche finale met à jour le message racine avec ✅ ou ❌.

Les étapes manuelles restantes consistent à réviser et publier les brouillons de notes de version, et à réviser et publier un message interne sur Slack. Ces deux étapes nécessitent une intervention humaine.

La vérification humaine : un élément essentiel

Un problème majeur avec les notes de version générées par l'IA est le risque d'omission ou d'invention de PR. Un changelog presque correct est pire qu'aucun changelog, car il n'est pas vérifié. Hugging Face ne fait pas confiance aux notes générées pour être complètes dès le premier essai. Un script Python récupère toutes les PR pertinentes et les stocke comme référence. Le modèle rédige ensuite les notes à partir de ces PR. Une fois terminé, la sortie est vérifiée par rapport à la liste initiale des PR. Si des éléments manquent ou sont en trop, le processus ne publie pas un fichier incorrect. La divergence est renvoyée à l'agent pour correction.

Ancrer le modèle pour éviter les erreurs

L'exhaustivité et l'exactitude sont essentielles. Un modèle qui résume une PR uniquement à partir de son titre peut inventer des exemples de code incorrects. Pour éviter cela, les métadonnées des PR incluent également les différences de documentation. Ce diff est intégré dans le contexte du modèle pour garantir que les exemples cités correspondent à la documentation réelle. Les invites sont stockées sous forme de compétences, vérifiées dans le dépôt, et expliquent comment structurer les notes de version.

Le rôle crucial de l'humain

Après la publication du RC, le brouillon de publication GitHub reste disponible avec le premier passage de l'IA. Un réviseur lit et édite le brouillon pour le ton et l'emphase, corrigeant les erreurs du modèle. Ce n'est qu'après cette révision que la publication mineure est déclenchée, promouvant le RC en version finale. Le temps du réviseur est ainsi optimisé, transformant une demi-journée d'écriture en une session d'édition de quinze minutes. Deux fichiers sont archivés chaque semaine : le brouillon brut de l'IA et la version éditée par un humain, permettant une amélioration continue.

Sécurité et transparence

La refonte du processus a également renforcé la sécurité, notamment contre les attaques de la chaîne d'approvisionnement. La publication utilise Trusted Publishing, éliminant le besoin de jetons PyPI. PyPI vérifie un jeton OIDC à courte durée de vie émis par GitHub pour ce flux de travail exact, et émet des attestations PEP 740 / provenance Sigstore pour chaque artefact. L'exécution de l'agent est verrouillée et vérifiée, garantissant l'intégrité du processus. Hugging Face a démontré qu'il est possible de combiner efficacité, sécurité et transparence dans un processus de publication automatisé.

Un impact minimal sur les ressources

Le coût de cette transformation est négligeable. Une publication complète, incluant les notes et l'annonce Slack, à travers 20 à 40 PR, nécessite moins d'une heure de travail humain. Cette efficacité accrue permet à Hugging Face de se concentrer sur l'innovation et l'amélioration continue de ses produits.