Transformations des programmes d'IA

Les programmes d'IA seront bientôt transformés de sorte que l’on ne pourra bientôt plus les reconnaître. Ainsi, il n’y a pas de raison de penser qu’une amélioration d’un programme d'IA particulier obtiendra l’amélioration d’un système logiciel plus global.

De nouvelles techniques de calcul apparaissent, d’autres deviennent plus accessibles lorsque les capacités matérielles augmentent, et dès lors de nouveaux programmes surviennent, qui devront être intégrés à l’existant en brouillant ses frontières. En outre, on sait que la “loi de Moore” (qui procède du constat empirique que le volume d'informations traité par les puces informatiques double tous les deux ans) met en évidence l’augmentation rapide des capacités de calcul du hardware. Il ne faut donc pas penser l’IA comme un objet, ou un artefact stable.

L’IA, c’est avant toute chose, du programme logiciel qui aura besoin de matériel informatique. Or ces dispositifs sont toujours sujet à des évolutions (mise à jour de sécurité, de compatibilité, forking à des fins commerciales, clustering, ré-architecturation en containers etc.) Ces nécessités d’évolution des fatalités techniques que l’on ne peut ignorer. 

Un autre aspect est à considérer : l’IA d’une certaine manière, change son propre code (avant tout : ses paramètres et poids des vecteurs, mais aussi ses instructions et même ses déclarations de variables.)

Ainsi il ne faut pas considérer l’IA comme un objet caractéristique (comme une chaise) ni même comme un organisme soumis à ses propres lois. C’est une forme de dispositif purement conventionnel et calculatoire, soumis à aucune régularité naturelle.

Des « effets de bord » (des reconfigurations imprévues, éventuellement invisibles mais en tout cas gênantes) apparaissent souvent en informatique déployée. Ils surgissent en particulier, s’agissant d’IA, du fait des flux de rétroaction (feedback loop) - le flux de sortie dont la fonction est de venir moduler le flux d'entrée.

Nous relevons à ce feedback au moins 3 couples {cible, fonction} usuels   :
1 - {le modèle de L'IA, entraînement}   : c'est ici que l'on retrouve les effets de bord les plus imprévisibles. Par exemple, on continue l'entraînement du modèle avec comme source les entrées utilisateurs ou des requêtes web. Ceci provoque ce que l’on peut nommer une « dérive des modèles »
2 - {l'utilisateur, médiation sociale}   : la censure des sorties selon des règles donnés (morales, législatives, fact checking, etc). Par exemple, l'utilisateur demande la recette d'explosif, la surcouche de l'IA remplace la réponse par un message prédéfini.
3 - {le système, remontée d'information}   : autrement dit du "renseignement 2.0". Par exemple, un mail est envoyé aux autorités pour informer que l'utilisateur précédant cherche absolument à créer des explosifs.

Peut-on y remédier ?

Les points 2 et 3 sont “auditables” (on peut s’en occuper si l’on a le temps) puisque advenant dans la surcouche. Il s'agit concrètement de lignes de code sur lesquelles on peut faire des tests unitaires, techniques, fonctionnels ou autres. Ainsi dans certains cas, lorsque l’on dispose concrètement des ressources adéquates, l’effet de bord est maîtrisable.

Le point 1 est plus complexe à auditer   : le test unitaire peut donner quelques indications mais n'assure en rien la conformité, puisque l’effet de dérive est continu. Il ne s'agit plus ici de questionner le traitement de la donnée flux par flux mais globalement, or les systèmes récents sont basés sur des couples d'entrée pour être performants. Il n'est pas possible d’investiguer les couples (“brutforcer”) un par un, parce qu’il y a trop entrées et résultats possibles.

L’IA n’est pas un outil : les outils ne sont pas soumis à des effets de dérive propagatrice et effets de bord (par exemple : si j’utilise mon marteau, cela n’altère pas la performance du vôtre).

Les outils sont alors optimisables unitairement, et l’amélioration globale est bien au moins égale à la somme de ces améliorations locales (si tous les marteaux fabriqués sont plus efficients, on peut espérer que tous les clous seront plus vite plantés). 

Les animaux, eux, sont également “optimisables” : on peut vouloir modifier l’ADN d’une espèce de moustiques dans une région pour la rendre moins agressive. L’amélioration globale est possible (du point de vue du confort lors des pique-nique) : si tout se passe correctement, les lois de la nature vont continuer d’opérer globalement, en propageant les “bénéfices” d’une optimisation locale. Par exemple, les prédateurs vont adapter leurs comportements au vu de la modification opérée. L’homme a dès lors appris à “surfer” sur les lois de la nature avec la planche de son travail et de ses outils - en tout cas, c’est l’impression qu’il peut en avoir-.

On ne peut pas attendre la même chose pour l’IA, dont les programmes ne sont que du code, soit des conventions écrites : il n’y a aucune magie, aucune loi naturelle qui agit spontanément pour réécrire mieux les prescriptions partout en vue d’un équilibrage global.

Ainsi, un problème majeur avec les programmes d’IA, c’est que le reparamétrage automatique et les difficultés d’intégration et de maintenance causent des transformations internes du logiciel, des effets de dérive, et des effets de bord. De la sorte, les solutions obtenues dans l’ordinateur sont toujours un peu moins bonnes qu’espérées à cause des paramétrages et calages qu’elles nécessitent.

En-dehors de l’ordinateur, il faut vraiment compter sur la chance pour imaginer que ces imprévus vont toujours s’avérer favorables. A l'inverse : à l’intérieur de l’ordinateur, si l’on dispose d’un temps illimité, rien d’imprévu ne peut se passer.