Comment Google utilise l'IA pour les migrations de code interne
Google utilise les LLM pour rationaliser les migrations de code interne, réalisant des gains de temps significatifs allant jusqu'à 89% : Comment Google utilise l'IA pour les migrations de code interne
Google a publié un rapport d'expérience sur l'utilisation des LLM pour les migrations de code. Les informaticiens de Google ont constaté que l'utilisation des LLM peut réduire de manière significative le temps nécessaire aux migrations, ainsi que les obstacles au démarrage et à l'achèvement des programmes de migration. En outre, ils ont partagé leurs impressions et les enseignements qu'ils ont tirés de l'utilisation de l'IA pour la migration de code.
Les informaticiens de Google ont utilisé les LLM pour rationaliser les migrations de code internes, réalisant des gains de temps significatifs allant jusqu'à 89 % dans certains cas. Les résultats ont été publiés dans un document intitulé "How is Google using AI for internal code migrations ?" (Comment Google utilise l'IA pour les migrations de code interne ?).
Pour rappel, un grand modèle de langage (LLM) est un type de modèle d'apprentissage automatique conçu pour les tâches de traitement du langage naturel telles que la génération de langage. Les LLM sont des modèles de langage comportant de nombreux paramètres et sont formés par apprentissage auto-supervisé sur une grande quantité de texte. Les modèles modernes peuvent être affinés pour des tâches spécifiques ou guidés par l'ingénierie d'aide.
Selon le rapport de Google, l'accent est mis sur les outils d'IA sur mesure développés pour des domaines de produits spécifiques, tels que les annonces, la recherche, l'espace de travail et YouTube, plutôt que sur les outils d'IA génériques qui fournissent des services largement applicables tels que l'achèvement du code, l'examen du code et la réponse aux questions.
Les migrations de code de Google ont consisté à remplacer les ID 32 bits de la base de code de plus de 500 millions de lignes pour Google Ads par des ID 64 bits, à convertir son ancienne bibliothèque de test JUnit3 en JUnit4 et à remplacer la bibliothèque Joda time par le package standard java.time de Java. La migration de int32 à int64 n'était pas triviale car les identifiants étaient souvent définis de manière générique (int32_t en C++ ou Integer en Java) et n'étaient pas facilement consultables.
Ils existaient dans des dizaines de milliers d'emplacements de code dans des milliers de fichiers. Les modifications devaient être suivies par plusieurs équipes et les changements apportés aux interfaces des classes devaient être pris en compte dans plusieurs fichiers. "L'ensemble de l'effort, s'il était réalisé manuellement, devait nécessiter des centaines d'années d'ingénierie logicielle et une coordination transversale complexe", expliquent les auteurs.
Processus de migration
Pour leur flux de travail basé sur le LLM, les ingénieurs logiciels de Google ont mis en œuvre le processus suivant. Un ingénieur d'Ads identifiait un identifiant nécessitant une migration en utilisant une combinaison de recherche de code, de Kythe et de scripts personnalisés. Ensuite, une boîte à outils de migration basée sur LLM, déclenchée par une personne compétente en la matière, était exécutée pour générer des modifications vérifiées contenant du code qui passait les tests unitaires. Ces modifications sont vérifiées manuellement par le même ingénieur et éventuellement corrigées.
Ensuite, les modifications de code sont envoyées à plusieurs réviseurs responsables de la partie de la base de code affectée par les modifications. Il en est ressorti que 80 % des modifications de code figurant dans les listes de modifications (CL) étaient purement le fruit de l'IA, le reste étant constitué de suggestions d'IA rédigées ou modifiées par l'homme.
"Nous avons découvert que dans la plupart des cas, l'homme devait revenir sur au moins quelques modifications apportées par le modèle qui étaient soit incorrectes, soit inutiles", observent les auteurs. "Compte tenu de la complexité et de la nature sensible du code modifié, des efforts doivent être déployés pour que chaque modification soit appliquée avec soin aux utilisateurs."
Sur la base de ce constat, Google a entrepris des travaux supplémentaires sur la vérification pilotée par LLM afin de réduire la nécessité d'un examen détaillé. Même s'il est nécessaire de revérifier le travail du LLM, les auteurs estiment que le temps nécessaire pour achever la migration a été réduit de 50 %. Avec l'aide du LLM, il n'a fallu que trois mois pour migrer 5 359 fichiers et modifier 149 000 lignes de code pour achever la transition JUnit3-JUnit4. Environ 87 % du code généré par l'IA a fini par être validé sans aucun changement. En ce qui concerne le changement de cadre temporel Joda-Java, les auteurs estiment que le gain de temps est de 89 % par rapport au temps de changement manuel prévu, bien qu'aucune spécification n'ait été fournie pour étayer cette affirmation.
Résultats de migration lors des 3 premiers trimestres 2024
Ces résultats permettent de mieux comprendre les déclarations du PDG de Google, Sundar Pichai. Lors de l'annonce des résultats financiers du troisième trimestre 2024, il a dévoilé que plus de 25 % du nouveau code produit par Google est désormais généré par l'intelligence artificielle (IA). Il a déclaré que l'utilisation de l'IA pour le codage permettait de "stimuler la productivité et l'efficacité" au sein de Google.
"Une fois le code généré, il est ensuite vérifié et revu par les employés... Cela permet à nos ingénieurs d'en faire plus et d'aller plus vite... Je suis enthousiasmé par nos progrès et les opportunités qui s'offrent à nous, et nous continuons à nous concentrer sur la création de produits de qualité." a-t-il ajouté.
Ces résultats permettent également d'estimer les performances de l'assistant de codage doté d'IA de Google. Dévoilé le 11 novembre 2024, l'assistant de codage doté d'IA "Jules" serait capable de corriger de manière autonome les bogues des logiciels et de préparer les modifications de code pendant que les développeurs se concentrent sur ce qu'ils veulent réellement construire.
L'agent de codage expérimental alimenté par l'IA est construit sur la plateforme de modèles d'IA Gemini 2.0. Il s'intègre directement au système de flux de travail de GitHub et peut analyser des bases de code complexes, mettre en œuvre des correctifs sur plusieurs fichiers et préparer des demandes d'extraction détaillées sans supervision humaine constante. Google affirmait que "Jules" constitue une avancée significative dans le cadre des efforts déployés par l'entreprise pour automatiser les tâches de programmation essentielles.
Amélioration des outils de codage par IA
Comment Google utilise l'IA pour les migrations de code interne ?
Voici les principales conclusions de l'équipe de Google :Présentation du rapport
Ces dernières années, l'utilisation de l'IA générative, et en particulier des grands modèles de langage (LLM), dans l'ingénierie logicielle a suscité un intérêt considérable. En effet, plusieurs outils sont désormais disponibles dans le commerce et de nombreuses grandes entreprises ont également créé des outils propriétaires basés sur les ML pour leurs propres ingénieurs en logiciel. Alors que l'utilisation des ML pour des tâches courantes telles que l'achèvement du code est disponible dans les outils de base, l'application des LLM à des fins plus spécifiques suscite un intérêt croissant. L'un de ces objectifs est la migration de code.
Cet article est un rapport d'expérience sur l'utilisation des LLM pour les migrations de code chez Google. Il ne s'agit pas d'une étude de recherche, en ce sens que nous n'effectuons pas de comparaisons avec d'autres approches et que nous n'évaluons pas les questions/hypothèses de recherche. Nous partageons plutôt nos expériences dans l'application de la migration de code basée sur les LLM dans un contexte d'entreprise à travers une gamme de cas de migration, dans l'espoir que d'autres praticiens de l'industrie trouveront nos idées utiles. Nombre de ces enseignements s'appliquent à toute application de ML dans le génie logiciel. Nous constatons que l'utilisation des LLM peut réduire de manière significative le temps nécessaire aux migrations et peut réduire les obstacles au démarrage et à l'achèvement des programmes de migration.
Les LLM pour la modernisation du code
Les LLM offrent une opportunité significative d'aider à la modernisation et à la mise à jour de grandes bases de code. Ils sont très flexibles et, par conséquent, une variété de tâches de transformation de code peuvent être encadrées dans un flux de travail similaire et être couronnées de succès. Cette approche a le potentiel de changer radicalement la façon dont le code est maintenu dans les grandes entreprises.
Elle peut non seulement accélérer le travail des ingénieurs, mais aussi rendre possibles des efforts qui étaient auparavant irréalisables en raison de l'investissement considérable qu'ils nécessitaient. Les migrations inachevées ont tendance à ralentir continuellement les équipes, même si elles ne travaillent pas directement dessus, elles déroutent les nouveaux développeurs avec des modèles obsolètes et nécessitent une charge cognitive supplémentaire. L'accélération des migrations a des effets bénéfiques qui vont bien au-delà du changement de code technique proprement dit.
LLM+AST, mieux ensemble
Beaucoup de migrations de code peuvent être divisées en étapes discrètes et chaque étape peut être soit la génération LLM, soit l'introspection LLM, mais aussi l'utilisation de méthodes traditionnelles comme les techniques basées sur l'AST (abstract syntax trees) et même les recherches de type grep. Ils ont découvert que les capacités de planification LLM ne sont souvent pas nécessaires et qu'elles ajoutent une couche de complexité qui devrait être évitée dans la mesure du possible.
L'outil basé sur l'AST a l'avantage d'être "toujours correct" et de ne pas souffrir des changements de version du modèle ou des fluctuations des changements rapides. Par exemple, de simples erreurs du modèle, comme l'ajout de commentaires inutiles ou la modification de méthodes qui ne devraient pas l'être, peuvent être facilement vérifiées par un analyseur AST qui différencie les nœuds AST avant/après du fichier. Travailler avec des prompts plus petits et mieux définis, alimentés par LLM, augmente la fiabilité des résultats tout en réduisant les efforts de débogage et le besoin d'ajuster les prompts.
Un autre avantage est que les étapes qui ne reposent pas sur les LLM ont tendance à être beaucoup moins coûteuses en termes de calcul. Bien que le coût par jeton pour les prédictions ait régulièrement diminué, les migrations nécessitent souvent de toucher des milliers de fichiers et les coûts peuvent rapidement s'accumuler.
Diviser pour mieux régner
Des sous-tâches plus simples permettent au développeur qui construit le flux de migration d'itérer plus rapidement et de "diviser et conquérir" le problème. Dans la boîte à outils décrite dans le document, différents ingénieurs sont chargés de régler et d'optimiser une étape spécifique qui est ensuite utilisée pour plusieurs migrations. Par exemple, l'étape de fixation de la construction est omniprésente et son amélioration permet de réaliser des économies d'échelle.
Lorsque la sortie du modèle n'est pas parfaite, le fait de s'appuyer sur la validation et la vérification par le biais de plusieurs étapes permet de "récupérer" le changement et de mener à un flux de travail fructueux. D'après les observations de l'équipe de Google, les LLM sont très doués pour résoudre un problème bien défini qui complète leur première tentative de changement.
Exemple de sous-tâches
Déploiements des changements : un processus humain
Bien que les LLM puissent permettre un gain de temps significatif pour la génération de changements elle-même, des outils supplémentaires seront nécessaires pour réduire ou accélérer l'implication humaine. Les revues de code et les déploiements de changements nécessitent toujours un opérateur humain et peuvent rapidement devenir des goulots d'étranglement dans le processus plus large de migration du code.
Ils ont dû ralentir une partie du travail de migration pour éviter de submerger les équipes chargées des révisions et pour veiller à ce que les déploiements se fassent de manière progressive et responsable. Ils étudiraient activement la possibilité d'aider les développeurs humains dans les tâches adjacentes aux modifications du code dans le cadre d'une migration.
Mesures et évaluation
De nombreux travaux dans les communautés de ML et de ML appliquée se concentrent sur les évaluations, généralement dans le cadre desquelles les performances du modèle sont mesurées sur des tâches isolées et hermétiques telles que "générer un code Python pour ..." . Bien que cela permette de mesurer certains aspects de la qualité du modèle, ce qui importe en fin de compte, c'est la manière dont les performances au niveau du modèle se traduisent par des résultats au niveau de l'entreprise.
De mauvaises performances au niveau du modèle peuvent compromettre les résultats au niveau de l'entreprise, mais de bonnes performances au niveau du modèle ne garantissent pas de bons résultats au niveau de l'entreprise, puisque le modèle ML n'est qu'une partie d'une tâche de transformation complexe. L'équipe de Google se mesure constamment au niveau des résultats commerciaux.
Formation et adoption
L'utilisation généralisée de l'IA générative, avec des techniques sur mesure, s'accompagne d'un coût caché : celui de devoir former un certain nombre d'ingénieurs à l'utilisation de ces techniques. La construction d'un outillage élaboré pour dissimuler complètement l'utilisation de l'IA derrière des outils est coûteuse et crée une obligation technique de maintenir cet outillage, qui est utilisé par un nombre relativement restreint d'ingénieurs. (En comparaison, les technologies génériques telles que l'autocomplétion de code sont faciles à amortir sur une population beaucoup plus large).
Modèles personnalisés ou génériques
Dans le même ordre d'idées que le point précédent, si les modèles affinés peuvent être utiles, ils ont aussi un coût, et une entreprise doit constamment évaluer la "surface sous la courbe" d'un investissement dans des modèles personnalisés pour obtenir de meilleurs résultats, par rapport à l'utilisation de modèles prêts à l'emploi. Nous avons actuellement utilisé des modèles affinés pour générer des modifications et réparer les échecs de construction.
Source : "How is Google using AI for internal code migrations?"
Et vous ?
Pensez-vous que ce rapport est crédible ou pertinente ?
Voir aussi :
Répondre avec citation
Partager