Un référentiel AFNOR pour l’IA « frugale »

Le langage C, à favoriser pour concevoir des IA ? « Si cela est possible dans la limite des compétences en développement des data scientists et des choix stratégiques de la société à laquelle ils appartiennent »…

Cette recommandation figure dans l’AFNOR SPEC 2314.
Le document ne constitue pas une norme. Il vise à fournir un catalogue de méthodes et de pratiques à appliquer pour tendre vers une IA « frugale ». Une soixantaine d’organismes (47 du secteur privé, 7 du secteur public, 6 de la sphère académique/recherche) y ont contribué.

Les 31 bonnes pratiques référencées sont classées sur deux axes. D’un côté, les segments « service », « données » et « infrastructures ». De l’autre les étapes du cycle de vie d’une IA.
Celles qui procurent le plus fort gain ont trait, entre autres, à l’acculturation des parties prenantes, à l’analyse des besoins et à l’optimisation de l’équipement existant. Les plus faciles à mettre en œuvre touchent notamment à la compression de données, à la réutilisation d’algorithmes et à l’usage de datasets open source pour le prototypage.

Ces datasets étant « souvent assez propres et bien annotés », ils peuvent donner une bonne estimation de la qualité maximum qu’un algo sera capable d’atteindre, nous explique-t-on. Utiliser ces données permet par ailleurs de régler au plus juste la quantité de ressources à mettre à disposition du service avant même de réunir des données spécifiques.

Inciter les devs à la modération

Au-delà de C, on favorisera soit les langages compilés, soit les interpréteurs optimisés (exemples données : Pythran ou Numba pour Python) pour les langages plus haut niveau. Il s’agira aussi de pérenniser le code en utilisant au possible les bibliothèques courantes, en vérifiant les licences d’utilisation des langages (risque de portabilité) et en optant pour des solutions multienvironnements. L’idée étant d’obtenir un code réutilisable, y compris sous forme de modules dans d’autres projets.

Ces pratiques d’écoconception du code apportent un gain modéré, pour un effort de mise en œuvre également modéré. Même équilibre côté équipements. La SPEC invite à maximiser l’utilisation de postes de développement standards existants. Elle recommande aussi d’inciter la devs à la modération… en confinant l’espace mémoire/CPU/stockage à leur disposition.

Sur l’expression des besoins, on ira jusqu’à se demander si un mode de fonctionnement asynchrone est envisageable, quel type de mode dégradé on peut accepter ou s’il est possible d’ajouter uen fonctionnalité de détection d’obsolescence. Non sans se rappeler qu’une somme d’optimisations locales ne fait pas une optimisation globale. Attention aussi aux technos prometteuses mais non maîtrisées… et au coût – environnemental mais pas que – qu’elle peuvent engendrer.

Les impacts indirects, difficiles à saisir

Sur le plan environnemental, il peut parfois être plus intéressant de créer deux produits que de renforcer un produit existant, souligne le document. De même, découper un modèle généraliste en modèles spécialisés peut permettre de réduire l’empreinte. En particulier parce qu’elle ouvre à une mutualisation, tout en diminuant l’ampleur de l’inférence comme du réentraînement.

Pour la mesure de consommation des programmes et de l’empreinte carbone associée, l’AFNOR SPEC 2314 mentionne les outils CodeCarbon et CarbonTracker. Pour l’estimation et le suivi de la GenAI par API, EcoLogits. Elle cite aussi la plate-forme Eclipse Aidge, qui aide à concevoir des réseaux de neurones pour des environnements contraints en ressources.

Les références méthodologiques sont plus limitées pour ce qui est d’évaluer les impacts indirects associés à l’utilisation des services IA. En d’autres termes, les effets potentiels liés aux modifications comportementales, économiques ou sociétales. Des éléments beaucoup plus difficiles à quantifier que les effets dus au cycle de vie des équipements. Solution conseillée pour le moment : le niveau le plus souple de la recommandation ITU-T L.1480.

Illustration principale générée par IA