Va parcourir Hugging Face maintenant et tu trouveras des milliers de mod\u00e8les qui n’ont pas \u00e9t\u00e9 mis \u00e0 jour depuis plus d’un an. Beaucoup \u00e9taient \u00e0 la pointe de l’art lors de leur sortie. Certains re\u00e7oivent encore des centaines de t\u00e9l\u00e9chargements par jour. Presque aucun n’a un plan clair pour ce qui se passe quand leurs mainteneurs passent \u00e0 autre chose, que leurs donn\u00e9es d’entra\u00eenement deviennent probl\u00e9matiques, ou qu’une vuln\u00e9rabilit\u00e9 critique est d\u00e9couverte. Bienvenue au cimeti\u00e8re des mod\u00e8les ouverts, o\u00f9 les poids abandonn\u00e9s vivent \u00e9ternellement et personne n’est responsable des cons\u00e9quences.<\/p>\n
Dans le logiciel traditionnel, l’obsolescence est un concept bien compris. Les biblioth\u00e8ques ont des politiques de cycle de vie. Les APIs obtiennent des dates de suppression. Les correctifs de s\u00e9curit\u00e9 ont des fen\u00eatres de support d\u00e9finies. L’\u00e9cosyst\u00e8me des mod\u00e8les ouverts n’a aucune de ces infrastructures. Un mod\u00e8le est publi\u00e9 avec un billet de blog et une fiche mod\u00e8le, les t\u00e9l\u00e9chargements s’accumulent, des applications sont construites dessus, et puis… rien. Le mainteneur publie un nouveau mod\u00e8le et oublie l’ancien. Ou il quitte le domaine enti\u00e8rement. Ou l’organisation se dissout. Le mod\u00e8le reste, gel\u00e9 dans le temps, accumulant une dette technique que personne n’entretient.<\/p>\n
Tu pourrais soutenir que les mod\u00e8les abandonn\u00e9s s’auto-corrigent \u2014 les gens vont naturellement migrer vers de meilleures alternatives. C’est vrai \u00e0 long terme mais dangereusement faux \u00e0 moyen terme. Les d\u00e9ploiements en entreprise se font lentement. Un mod\u00e8le int\u00e9gr\u00e9 dans un pipeline de production en 2024 pourrait toujours fonctionner en 2027 parce que personne ne veut toucher \u00e0 un syst\u00e8me qui marche. La startup de sant\u00e9 qui a construit son outil de diagnostic sur une version de mod\u00e8le sp\u00e9cifique ne va pas l’\u00e9changer \u00e0 la l\u00e9g\u00e8re \u2014 cela n\u00e9cessite une nouvelle validation, de nouvelles soumissions r\u00e9glementaires, et des mois de test.<\/p>\n
Les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 sont la pr\u00e9occupation la plus aigu\u00eb. Quand les chercheurs d\u00e9couvrent qu’un mod\u00e8le est vuln\u00e9rable \u00e0 une attaque adversariale particuli\u00e8re, ou que ses donn\u00e9es d’entra\u00eenement contenaient des informations personnelles sensibles, ou qu’il pr\u00e9sente un biais dangereux dans un contexte sp\u00e9cifique, il n’y a aucun m\u00e9canisme pour notifier les utilisateurs. Pas de base de donn\u00e9es CVE pour les mod\u00e8les. Pas de syst\u00e8me de correction automatique. Pas de processus de divulgation coordonn\u00e9e. Le mod\u00e8le reste juste l\u00e0, \u00eatre t\u00e9l\u00e9charg\u00e9 et d\u00e9ploy\u00e9, avec des probl\u00e8mes connus que les nouveaux utilisateurs n’ont aucun moyen de conna\u00eetre.<\/p>\n
Il y a aussi l’angle de la reproductibilit\u00e9. Les mod\u00e8les publi\u00e9s sans \u00e9pinglage de version, sp\u00e9cifications de d\u00e9pendances, ou documentation d’environnement deviennent de plus en plus difficiles \u00e0 ex\u00e9cuter \u00e0 mesure que l’\u00e9cosyst\u00e8me \u00e9volue. Les versions de PyTorch changent. Les versions de CUDA changent. Les biblioth\u00e8ques de tokeniseur sont mises \u00e0 jour. Un mod\u00e8le qui fonctionnait parfaitement avec transformers 4.30 pourrait produire des donn\u00e9es inutiles avec transformers 4.40, et sans une documentation claire de l’environnement requis, les utilisateurs sont laiss\u00e9s \u00e0 deviner.<\/p>\n
Un plan d’obsolescence de mod\u00e8le appropri\u00e9 n’a pas besoin d’\u00eatre compliqu\u00e9, mais il doit exister. Au minimum, il devrait aborder trois questions : Pendant combien de temps ce mod\u00e8le sera-t-il activement support\u00e9 ? Qu’est-ce qui constitue une raison de l’obsol\u00e9ter ? Et que se passe-t-il pour les utilisateurs quand l’obsolescence se produit ?<\/p>\n
Le support actif signifie que quelqu’un surveille les probl\u00e8mes, r\u00e9pond aux rapports de bugs, et met \u00e0 jour la fiche mod\u00e8le quand de nouvelles informations \u00e9mergent. Cela n’a pas besoin d’\u00eatre \u00e9ternel \u2014 m\u00eame un engagement du type \u00ab 12 mois de support actif, suivi d’un statut maintenu par la communaut\u00e9 \u00bb est infiniment mieux que le silence. Les utilisateurs peuvent planifier autour de calendriers connus. Ils ne peuvent pas planifier autour de l’abandon.<\/p>\n
Les d\u00e9clencheurs d’obsolescence doivent \u00eatre explicites. La contamination des donn\u00e9es d’entra\u00eenement, la d\u00e9couverte de biais nuisibles, les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9, ou une r\u00e9gression significative de performance par rapport aux alternatives plus r\u00e9centes \u2014 n’importe lequel de ces \u00e9l\u00e9ments pourrait justifier l’obsolescence. La fiche mod\u00e8le devrait indiquer ce que les mainteneurs consid\u00e8rent comme une cause suffisante, afin que les utilisateurs comprennent le profil de risque qu’ils acceptent.<\/p>\n
Le processus d’obsolescence lui-m\u00eame devrait inclure une notification utilisateur claire, un chemin de migration recommand\u00e9 vers des mod\u00e8les alternatifs, une p\u00e9riode de transition o\u00f9 les anciens et nouveaux mod\u00e8les sont disponibles, et finalement, un marquage clair du mod\u00e8le obsol\u00e8te. Pas de suppression \u2014 la suppression brise la reproductibilit\u00e9 \u2014 mais du marquage. Une grande banni\u00e8re visible qui dit \u00ab ce mod\u00e8le est obsol\u00e8te, voici pourquoi, voici ce qu’il faut utiliser \u00e0 la place. \u00bb<\/p>\n
Les fiches mod\u00e8les \u00e9taient une innovation brillante. Introduites par Margaret Mitchell et ses coll\u00e8gues, elles ont apport\u00e9 une documentation structur\u00e9e aux mod\u00e8les de ML : cas d’usage pr\u00e9vus, limitations, r\u00e9sultats d’\u00e9valuation, consid\u00e9rations \u00e9thiques. La plupart des versions s\u00e9rieuses de mod\u00e8les incluent d\u00e9sormais une forme de fiche mod\u00e8le. Mais les conventions actuelles de fiche mod\u00e8le ont un point aveugle flagrant : elles d\u00e9crivent le mod\u00e8le tel qu’il existe \u00e0 la sortie et ne sont presque jamais mises \u00e0 jour.<\/p>\n
Une fiche mod\u00e8le vivante inclurait un journal des modifications, les probl\u00e8mes connus d\u00e9couverts apr\u00e8s la sortie, les notes de compatibilit\u00e9 pour diff\u00e9rentes versions de framework, et un champ de statut d’obsolescence. Certaines organisations commencent \u00e0 le faire \u2014 Hugging Face a ajout\u00e9 certains champs de m\u00e9tadonn\u00e9es qui supportent ce type d’information \u2014 mais c’est loin d’\u00eatre une pratique standard. La plupart des fiches mod\u00e8les sont des documents \u00e0 \u00e9criture unique qui deviennent de plus en plus inexacts \u00e0 mesure que le temps passe.<\/p>\n
La communaut\u00e9 a besoin de conventions pour les mises \u00e0 jour de fiche mod\u00e8le. Quand un probl\u00e8me de donn\u00e9es d’entra\u00eenement est d\u00e9couvert, mets \u00e0 jour la fiche. Quand une vuln\u00e9rabilit\u00e9 est signal\u00e9e, mets \u00e0 jour la fiche. Quand une nouvelle version de framework casse la compatibilit\u00e9, mets \u00e0 jour la fiche. Cette maintenance continue est moins glamour que de publier de nouveaux mod\u00e8les, mais c’est une infrastructure essentielle pour un \u00e9cosyst\u00e8me mature.<\/p>\n
Le monde du logiciel a pass\u00e9 des d\u00e9cennies \u00e0 construire une infrastructure pour g\u00e9rer les d\u00e9pendances et leurs cycles de vie. Les gestionnaires de paquets comme npm, pip, et cargo g\u00e8rent le versioning, la r\u00e9solution des d\u00e9pendances, et les avis de s\u00e9curit\u00e9. L’IA peut emprunter lourdement \u00e0 ces mod\u00e8les.<\/p>\n
Le versioning s\u00e9mantique pour les mod\u00e8les permettrait aux utilisateurs de sp\u00e9cifier les exigences de compatibilit\u00e9. Un mod\u00e8le \u00e0 la version 2.3.1 communique que c’est la deuxi\u00e8me version majeure, troisi\u00e8me mise \u00e0 jour mineure, et premier correctif. Les changements de rupture incr\u00e9mentent la version majeure. Les nouvelles capacit\u00e9s incr\u00e9mentent la version mineure. Les corrections de bugs incr\u00e9mentent la version de correctif. C’est une pratique standard en logiciel mais pratiquement inou\u00efe dans les versions de mod\u00e8les.<\/p>\n
Les avis de s\u00e9curit\u00e9 pour les mod\u00e8les cr\u00e9eraient une base de donn\u00e9es centralis\u00e9e des probl\u00e8mes connus. Quand un chercheur d\u00e9couvre que le Mod\u00e8le X est vuln\u00e9rable \u00e0 un jailbreak sp\u00e9cifique, ou que ses donn\u00e9es d’entra\u00eenement incluaient du contenu prot\u00e9g\u00e9 par le droit d’auteur de la Source Y, ou qu’il pr\u00e9sente un comportement dangereux dans le Contexte Z, cette information serait enregistr\u00e9e dans un format structur\u00e9 et consultable. Les utilisateurs en aval pourraient \u00eatre automatiquement notifi\u00e9s, tout comme npm audit t’avertit des d\u00e9pendances vuln\u00e9rables.<\/p>\n
Les fichiers de verrouillage pour les d\u00e9ploiements de mod\u00e8les \u00e9pingleraient la version exacte du mod\u00e8le, la version du tokeniseur, la version du framework, et la configuration utilis\u00e9e dans un d\u00e9ploiement. Cela assure la reproductibilit\u00e9 et rend possible la mise \u00e0 jour syst\u00e9matique quand l’obsolescence se produit. Sans cela, les mises \u00e0 niveau de mod\u00e8les sont des aventures risqu\u00e9es o\u00f9 n’importe quoi pourrait se casser.<\/p>\n
La question la plus difficile en mati\u00e8re d’obsolescence de mod\u00e8le est la propri\u00e9t\u00e9. Le logiciel open-source fait face \u00e0 des d\u00e9fis similaires, mais les mod\u00e8les ajoutent des complications uniques. Un mod\u00e8le adapt\u00e9 \u00e0 partir de Llama par un chercheur ind\u00e9pendant, h\u00e9berg\u00e9 sur Hugging Face, d\u00e9ploy\u00e9 par une startup \u2014 qui est responsable de son cycle de vie ? Le cr\u00e9ateur du mod\u00e8le original ? L’adaptateur ? La plateforme d’h\u00e9bergement ? Le d\u00e9ployeur ?<\/p>\n
La r\u00e9ponse pratique est une responsabilit\u00e9 en couches. Les cr\u00e9ateurs de mod\u00e8les originaux devraient documenter les limitations connues et fournir des avis d’obsolescence pour les mod\u00e8les de base. Les adaptateurs h\u00e9ritent de la responsabilit\u00e9 de leurs d\u00e9riv\u00e9s et devraient suivre l’obsolescence en amont. Les plateformes d’h\u00e9bergement devraient fournir une infrastructure pour les m\u00e9tadonn\u00e9es d’obsolescence, les notifications, et la visibilit\u00e9. Les d\u00e9ployeurs sont finalement responsables des mod\u00e8les qu’ils mettent devant les utilisateurs, y compris la surveillance des avis d’obsolescence en amont.<\/p>\n
Ce mod\u00e8le en couches n’est pas parfait, mais il refl\u00e8te la fa\u00e7on dont la gestion des d\u00e9pendances logicielles fonctionne en pratique. Le mainteneur d’un paquet npm n’est pas responsable de chaque application qui l’utilise, mais il est cens\u00e9 communiquer les changements de rupture et les probl\u00e8mes de s\u00e9curit\u00e9. La m\u00eame attente devrait s’appliquer aux mainteneurs de mod\u00e8les.<\/p>\n
Plusieurs projets \u00e9mergents visent \u00e0 construire cette infrastructure. Les registres de mod\u00e8les avec gestion du cycle de vie, les tests de compatibilit\u00e9 automatis\u00e9s entre les versions de framework, et les formats de m\u00e9tadonn\u00e9es standardis\u00e9s pour le statut d’obsolescence sont tous en d\u00e9veloppement actif. La communaut\u00e9 MLOps reconna\u00eet lentement que la gestion des mod\u00e8les ne se termine pas au d\u00e9ploiement \u2014 elle inclut tout le cycle de vie de la publication \u00e0 la retraite.<\/p>\n
Le changement culturel compte autant que les outils. Publier un mod\u00e8le devrait venir avec la compr\u00e9hension que tu acceptes une certaine responsabilit\u00e9 continue, m\u00eame si cette responsabilit\u00e9 est explicitement limit\u00e9e dans le temps. \u00ab Je maintiendrai cette fiche mod\u00e8le pendant 6 mois \u00bb est un engagement parfaitement raisonnable. \u00ab Je vais publier ce mod\u00e8le et ne jamais le regarder \u00e0 nouveau \u00bb ne devrait pas \u00eatre normalis\u00e9, surtout pour les mod\u00e8les qui connaissent une adoption significative.<\/p>\n
L’\u00e9cosyst\u00e8me des mod\u00e8les ouverts m\u00fbrit rapidement. Il dispose de pipelines d’entra\u00eenement de classe mondiale, de cadres d’\u00e9valuation et d’outils de d\u00e9ploiement. Ce qui lui manque, c’est la gestion du cycle de vie \u2014 l’infrastructure ennuyeuse et essentielle qui transforme une collection d’artefacts publi\u00e9s en un \u00e9cosyst\u00e8me fiable sur lequel les entreprises et les individus peuvent construire avec confiance. Les plans d’obsolescence ne sont pas glamours. Mais c’est la diff\u00e9rence entre un \u00e9cosyst\u00e8me qui \u00e9volue durablement et un qui s’effondre sous le poids de ses propres artefacts abandonn\u00e9s.<\/p>\n","protected":false},"excerpt":{"rendered":"
Le probl\u00e8me du mod\u00e8le abandonn\u00e9 Va parcourir Hugging Face maintenant et tu trouveras des milliers de mod\u00e8les qui n’ont pas \u00e9t\u00e9 mis \u00e0 jour depuis plus d’un an. Beaucoup \u00e9taient \u00e0 la pointe de…<\/p>\n","protected":false},"author":1,"featured_media":306,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[272],"tags":[],"class_list":["post-558","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ia-open-source"],"_links":{"self":[{"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/posts\/558","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/comments?post=558"}],"version-history":[{"count":0,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/posts\/558\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/media\/306"}],"wp:attachment":[{"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/media?parent=558"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/categories?post=558"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/laeka.org\/publications\/wp-json\/wp\/v2\/tags?post=558"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}