L'OSI tente toujours de définir l'« IA open source »

À qui appartiennent des paramètres entraînés par quelqu’un et affinés par quelqu’un d’autre ? Cette question est ressortie d’un atelier que l’Open Source Initiative a organisé le mois dernier à la PyCon USA.

Cet atelier visait notamment à compiler une FAQ destinée à compléter la définition de l’« IA open source ».

Voilà deux ans que l’OSI travaille officiellement sur cette définition. Aux dernières nouvelles, elle entend publier une première release candidate ce mois-ci. Et avoir une version finale pour l’All Things Open Conference, qui se tiendra en octobre. En attendant, l’organisation effectue un roadshow qui la verra passer prochainement à Paris (OW2, 11-12 juin) et à Madrid (OpenExpo Europe, 13 juin). Puis, entre autres, par Hong Kong (AI Dev, août) et Buenos Aires (Nerdearlan, septembre).

Dix-sept briques pour incarner quatre « libertés »

La première étape pour élaborer la définition fut d’identifier les libertés que doit garantir une IA open source. Le dernier brouillon en date en liste quatre :

– Utiliser le système à toutes fins et sans avoir à demander d’autorisation
– Étudier comment le système fonctionne et inspecter ses composants
– Modifier le système à toutes fins, y compris modifier ses outputs
– Partager les systèmes afin que d’autres l’utilisent avec ou sans modifications, pour toutes finalités

La deuxième étape a impliqué l’analyse de quatre systèmes (Bloom, Llama 2, OpenCV, Pythia). Objectif : déterminer les composants nécessaires pour garantir ces quatre libertés. On les retrouve inscrits, au nombre de 17, dans un document de référence : le Model Openness Framework, attribué à la Linux Foundation.

Les composants déterminés, l’OSI a examiné leurs cadres juridiques respectifs. En résulte le brouillon actuel. Il s’agit désormais d’évaluer d’autres systèmes pour voir dans quelle mesure ils s’alignent sur la définition proposée. Et donc d’élaborer, en parallèle, une FAQ. Entre autres questions que celle-ci aborde en l’état actuel : pourquoi le jeu de données d’entraînement d’origine n’est-il pas nécessaire ?

Réponse de l’OSI : dans trop de cas, partager un dataset est illégal ou techniquement impossible. Elle y préfère donc la fourniture d’« informations sur les données ». À son sens, cela englobe :

– Méthodologies et techniques d’entraînement
– Périmètre et caratéristiques des données d’entraînement
– Origine des données d’entraînement (y compris les processus d’obtention et de sélection)
– Procédures d’annotation des données d’entraînement, si applicable
– Méthodologie de nettoyage des données d’entraînement

Les datasets en eux-mêmes (entraînement, test, validation, évaluation) restent donc facultatifs. Tout comme les résultats de benchmarks.

Le flou juridique de l’IA open source

Pour revendiquer une IA open source, il faudra aussi rendre disponibles, sous des licences approuvées par l’OSI, les codes de prétraitement des données, d’entraînement/validation/test et d’inférence. Ainsi que les outils et bibliothèques sous-jacents. Le code d’évaluation est facultatif.
On y ajoutera l’architecture et les paramètres du modèle (métadonnées et échantillons d’outputs sont facultatifs).

La FAQ devra clarifier des aspects que la définition laisse pour l’heure flous. Par exemple, la notion d’information « suffisante » à propos des données*. Ou l’éventuelle possibilité, pour des projets IA qui n’incluent que du code source (pas d’informations sur les données ou de poids), d’utiliser tout de même une licence open source.

Au-delà même de savoir à qui appartiennent tels ou tels paramètres, il faut déterminer de quoi ils relèvent juridiquement. À l’instar des poids, ils ne sont ni des logiciels, ni du code source, ni des données…

* Les « informations sur les données » sont définies comme « suffisamment détaillées » pour qu’une personne « compétente » puisse recréer un système « substantiellement équivalent » en utilisant les mêmes données ou des données similaires. Autant de termes qu’il faudra probablement clarifier.

Illustration générée par IA