Le 10 août, l’organisme de recherche spécialisé en IA a dévoilé la bêta privée d’OpenAI Codex, un système capable de convertir du langage naturel en code informatique. La fonctionnalité suscite à la fois enthousiasme et méfiance.
Codex est dérivé du réseau de neurones GPT-3 développé par OpenAI et publié il y a un an. Il s’agit de la technologie sous-jacente de GitHub Copilot, un outil d’autocomplétion et de génération de code en préversion technique, présenté il y a un peu plus d’un mois.
Déployé sous forme d’API, le rôle d’OpenAI Codex est de retranscrire des commandes simples écrites en anglais en code, dans une « douzaine » de langages de programmation. Il a majoritairement été entraîné sur Python, puis sur JavaScript, TypeScript, Ruby et Go. Il supporte aussi Perl, PHP, Swift ou encore Shell. Selon les ingénieurs responsables du projet, l’intérêt de l’API réside dans la possibilité d’incorporer le code généré dans une application existante.
Lors d’une démonstration « live » rediffusée sur YouTube, les dirigeants d’OpenAI ont présenté plusieurs cas d’usage.
« Tout ce que nous faisons, c’est formater l’instruction envoyée au modèle un peu comme une docstring Python, de sorte qu’elle ressemble à un commentaire. Le modèle génère du code que nous exécutons par la suite », explique en préambule Greg Brockman, cofondateur et CTO d’OpenAI. Le code engendré est affiché depuis la même interface utilisateur à des fins d’interprétabilité, selon lui.
En quelques minutes, le CTO a exposé un exemple d’Hello World déployé sur un serveur Python, expédié des mails, développé un jeu vidéo basique, et formaté un texte à la voix (via l’outil d’assistance de Word). Sur son site Web, OpenAI propose des cas d’usage beaucoup plus utiles pour les développeurs et les analystes. L’un vise à convertir un programme Python en Ruby. L’autre consiste en l’exécution d’opérations analytiques simples. Ici, il s’agit de visualiser un graphe représentant les pics de températures à San Francisco entre les mois de juin et juillet 2021. Tout cela sans écrire une seule ligne de code.
OpenIA a « effleuré la surface »
« Nous n’avons qu’effleuré la surface de ce qui peut être fait. Codex est très bon pour résoudre un petit problème à la fois. Si vous lui en demandez trop d’un coup, il échouera. »
Greg BrockmanCofondateur et CTO, OpenAI
Bien qu’intéressant, le projet émerge à peine. De plus, certaines instructions textuelles sont plus rapides à exécuter manuellement, à l’aide de la fonction glisser-déposer d’un outil de programmation visuelle.
« Nous n’avons qu’effleuré la surface de ce qui peut être fait. Codex est très bon pour résoudre un petit problème à la fois. Si vous lui en demandez trop d’un coup, il échouera », reconnaît Greg Brockman. Il s’agit donc d’enchaîner de multiples petites commandes.
À l’avenir, Codex pourrait enrichir un kit d’outils low-code/no-code et dans certains cas une chaîne d’outils d’un développeur. C’est la prétention d’OpenAI et de GitHub avec CoPilot. Cette extension à VS Code complète le code, « convertit » les commentaires en code, peut lancer des tests, mais peut également suggérer une méthode alternative pour composer une fonction.
Pour ce faire, OpenAI explique que Codex dispose d’une capacité de mémoire afin de comprendre le contexte des commandes, de sorte qu’il est possible de rectifier une instruction censée générer du code. Par exemple, pour Python, Codex dispose d’un cache de 14 Ko, contre 4 Ko pour GPT-3, lui permettant de « prendre en compte trois fois plus d’information contextuelle ».
Pour rappel, GPT-3 est un modèle de Deep Learning généraliste consacré au traitement du langage naturel, et à la génération automatique de textes. C’est la puissance de calcul et le nombre de paramètres pris en compte, ainsi que l’effort d’optimisation, qui expliquent ses performances. Codex et Copilot sont des variantes dédiées à la programmation.
« Il est fondamentalement impossible de bâtir un tel système sauf en formant un gros réseau de neurones pour obtenir une très bonne autocomplétion du code. C’est la méthode la plus simple pour ce faire », déclare Ilya Sutskever, cofondateur et Chief Scientist chez OpenAI.
« Si GPT-3 dispose de capacités rudimentaires de programmation, il a atteint une précision de 0 % sur notre benchmark », indique Wojciech Zaremba, cofondateur et PDG d’OpenAI. « Aujourd’hui, nous présentons un modèle [Codex] capable de résoudre 37 % des problèmes ». Précision importante, les résultats formulés par le PDG valent uniquement pour des programmes Python.
De son côté, la « version distincte de Codex » spécifique à Copilot serait plus performante. « Nous avons récemment effectué une comparaison avec des fonctions Python qui ont une bonne couverture de test dans les dépôts open source. Nous avons supprimé le corps des fonctions et demandé à GitHub Copilot de les remplir. Le modèle a trouvé la bonne réponse dans 43 % des cas au premier essai, et dans 57 % des cas après 10 essais », peut-on lire dans la FAQ de GitHub.
Bien que certains confèrent à GPT-3 des propriétés quasi magiques, il s’agit d’une nouvelle preuve qu’un modèle entraîné, « fine tuné » pour des tâches spécifiques est plus performant dans son domaine que son parent généraliste. Reste à savoir comment OpenAI obtient ces résultats. Les chercheurs travaillant pour l’entreprise ont publié le 14 juillet 2021 un article documentant leur approche.
Tout d’abord, Codex ne s’appuie pas sur les 175 milliards de paramètres souvent mis en avant par l’entreprise au moment d’évoquer GPT-3, mais sur un peu plus de 12 milliards de ces éléments. Ensuite, en sus du « fine tuning supervisé », les ingénieurs ont dû créer leur propre benchmark nommé HumanEval. En effet, le score BLEU (BiLingual Evaluation Understudy), utilisé pour évaluer la qualité d’une traduction automatique par rapport à des traductions de références rédigées par des humains, est difficilement adaptable à la problématique de génération de code. Par ailleurs, en l’état, le modèle est à mettre dans les mains de développeurs confirmés ou avancés. Les chercheurs soulignent des risques de confiance excessive de la part des usagers qui ne sauraient rectifier le code, et de potentiels « défauts d’alignements » du modèle entre ce qui lui est demandé et ce qu’il génère.
CoPilot « inacceptable et injuste », selon la Free Software Foundation
Puis, vient la question épineuse de la provenance des données d’entraînement.
« GPT-3 a été entraîné sur des textes disponibles publiquement, Codex a été entraîné sur un large corpus de texte et de code disponible librement. »
Ilya SutskeverCofondateur et Chief Scientist, OpenAI
« GPT-3 a été entraîné sur des textes disponibles publiquement, Codex a été entraîné sur un large corpus de texte et de code disponible librement », rappelle Ilya Sutskever. Il en va de même pour Copilot.
Dans le cadre de leur recherche, les auteurs de l’article ont récolté 179 Go de fichiers Python uniques de moins de 1 Mo chacun, à partir de 54 millions de dépôts publics hébergés sur GitHub. Filtré des fichiers les plus lourds et des lignes de code générées automatiquement, le data set extrait en mai 2020 pèse 159 Go. Cela donne une petite idée du volume de lignes de code nécessaires pour entraîner Codex à tous ces langages de programmation.
En ce sens, la disponibilité de GitHub CoPilot a provoqué une vive réaction de la part des responsables de la Free Software Foundation (FSF) qui juge l’extension « inacceptable et injuste ». Bien qu’entraînée sur des lignes de code open source, elle « nécessite l’exécution d’un logiciel qui n’est pas libre (Visual Studio, ou des parties de Visual Studio Code), et Copilot est un service agissant comme un substitut de logiciel ».
La FSF se pose autant la question de la présence éventuelle de code propriétaire dans ces dépôts GitHub, au vu de la problématique à suivre les licences dans les dépendances, que celle de la possible violation du fair use de GPL et AGPL, ou encore du copyright soutenant le modèle d’IA de Copilot. Pour y répondre, l’organisation a lancé un appel à l’écriture d’un livre blanc pouvant être soumis à la fondation jusqu’au 23 août 2021.
OpenAI est bien conscient de ces points d’attention. Dans leur article, les chercheurs se protègent en mentionnant l’avis rendu le 3 mars 2020 par le United States Patent and Trademark Office (USPTO) rattaché au Département du Commerce étatsunien, à la demande d’OpenAI. En résumé, l’USPTO reconnaît qu’en vertu du « droit actuel, l’entraînement de systèmes d’IA constitue un usage loyal », respectant les considérations politiques qui sous-tendent la notion de fair-use. Reste une « incertitude juridique sur les implications en matière de droits d’auteur » associés aux données utilisées pour entraîner les modèles qui « devrait donc être résolue de manière officielle ».
Si ce point varie suivant les cas spécifiques, l’autorité évalue que l’usage « raisonnable » d’éléments propriétaires dans l’entraînement d’un système IA est un « fair-use » à condition de ne pas rendre accessibles publiquement ces actifs. Quand les données sont déjà publiques, peu importe la licence ou le copyright appliqué, elle estime encore une fois que l’usage est loyal au vu de l’aspect « transformateur » des algorithmes en développement.
Il ne s’agit ici que d’un avis d’une autorité et non du verdict d’un juge, et ceux au regard du droit américain.
Codex et la question ouverte de la cybersécurité
Concernant la propriété du code générée, GitHub mentionne expressément qu’elle appartient à l’utilisateur. D’ailleurs, c’est à lui de le tester, de le vérifier et de le sécuriser. De son côté, OpenAI n’apporte pas encore cette précision.
Les chercheurs d’OpenAI expliquent toutefois qu’ils sont alertes aux questions de cybersécurité. Ils ont eux-mêmes testé des paquets non vérifiés dans un environnement sandbox hébergé sur Kubernetes reposant sur le runtime de container dit sécurisé gVisor, imaginé par les ingénieurs de Google. « Les hôtes et services adjacents au réseau sont protégés par des règles de pare-feu basées sur eBPF qui empêchent les connexions entrantes et sortantes, à l’exception de celles requises pour le contrôle de l’expérience », écrivent les chercheurs. D’ailleurs, ils ont considéré le code sélectionné comme potentiellement compromis à chaque étape du développement, ce qui pourrait représenter un problème si Codex rencontre un large succès.
L’utilisation de Copilot, elle, nécessite l’extraction de données de télémétries pour « améliorer les futures versions du système d’IA ». Si GitHub assure que l’accès aux informations est sécurisé, ce transfert implique nécessairement un élargissement de la surface d’attaque.
« Nous pensons qu’au niveau actuel de leurs capacités, les modèles Codex ne réduisent pas de manière significative la barrière à l’entrée pour le développement de logiciels malveillants. »
Chercheurs d'OpenAI
Quant aux possibles usages de Codex par des cyberattaquants, les spécialistes d’OpenAI se veulent confiants. « Même si cela est préoccupant, sur la base de nos tests, nous pensons qu'au niveau actuel de leurs capacités, les modèles Codex ne réduisent pas de manière significative la barrière à l’entrée pour le développement de logiciels malveillants ». Un modèle du même type plus avancé aurait la capacité d’enfanter de malwares polymorphiques.
En l’état, Codex pourrait tout de même servir à accélérer la mise en œuvre de certaines attaques. « Bien que nous ayons constaté que Codex n’est pas capable de générer un code malveillant autonome, il est cependant encore capable de générer du code qui peut être incorporé en tant que composants de systèmes plus complexes. Par exemple, nous avons constaté que le modèle avait du mal à engendrer des charges utiles d’injection SQL et shell. En revanche, il n’a eu aucun problème à produire du code pour chiffrer récursivement des fichiers dans un répertoire ».
Pour l’instant, OpenAI Codex et GitHub CoPilot demeurent à l’état de bêta privée et de préversion technique, mais les deux acteurs ne sont pas les seuls à avoir ouvert cette boîte qui ne semble pas prête à se refermer.
Pour approfondir sur Intelligence Artificielle et Data Science
