Personnalisation des compagnons de codage pour les organisations | Services Web Amazon

Les modèles d'IA générative pour les compagnons de codage sont principalement formés sur du code source accessible au public et du texte en langage naturel. Bien que la grande taille du corpus de formation permette aux modèles de générer du code pour les fonctionnalités couramment utilisées, ces modèles ne connaissent pas le code des référentiels privés ni les styles de codage associés qui sont appliqués lors du développement avec eux. Par conséquent, les suggestions générées peuvent nécessiter une réécriture avant de pouvoir être incorporées dans un référentiel interne.

Nous pouvons combler cette lacune et minimiser les modifications manuelles supplémentaires en intégrant les connaissances du code provenant de référentiels privés au-dessus d'un modèle de langage formé sur le code public. C'est pourquoi nous avons développé une capacité de personnalisation pour Chuchoteur de code Amazon. Dans cet article, nous vous montrons deux manières possibles de personnaliser les compagnons de codage à l'aide de la génération et du réglage améliorés par récupération.

Notre objectif avec la capacité de personnalisation de CodeWhisperer est de permettre aux organisations d'adapter le modèle CodeWhisperer à l'aide de leurs référentiels et bibliothèques privés pour générer des recommandations de code spécifiques à l'organisation qui permettent de gagner du temps, de suivre le style et les conventions organisationnelles et d'éviter les bogues ou les vulnérabilités de sécurité. Cela profite au développement de logiciels d’entreprise et permet de surmonter les défis suivants :

1. Documentation ou informations éparses pour les bibliothèques internes et les API qui obligent les développeurs à passer du temps à examiner le code précédemment écrit pour en reproduire l'utilisation.
2. Manque de sensibilisation et de cohérence dans la mise en œuvre de pratiques, styles et modèles de codage spécifiques à l’entreprise.
3. Utilisation par inadvertance de code et d'API obsolètes par les développeurs.

En utilisant des référentiels de code internes pour une formation supplémentaire qui ont déjà fait l'objet de révisions de code, le modèle de langage peut faire apparaître l'utilisation d'API internes et de blocs de code qui surmontent la liste de problèmes précédente. Étant donné que le code de référence est déjà examiné et répond aux exigences élevées du client, la probabilité d'introduire des bogues ou des vulnérabilités de sécurité est également minimisée. Et, en sélectionnant soigneusement les fichiers sources utilisés pour la personnalisation, les organisations peuvent réduire l'utilisation de code obsolète.

Défis de conception

La personnalisation des suggestions de code basées sur les référentiels privés d'une organisation présente de nombreux défis de conception intéressants. Le déploiement de grands modèles de langage (LLM) pour faire apparaître des suggestions de code entraîne des coûts fixes de disponibilité et des coûts variables en raison de l'inférence basée sur le nombre de jetons générés. Par conséquent, disposer de personnalisations distinctes pour chaque client et les héberger individuellement, entraînant ainsi des coûts fixes supplémentaires, peut s'avérer extrêmement coûteux. D'un autre côté, disposer de plusieurs personnalisations simultanément sur le même système nécessite une infrastructure multi-tenant pour isoler le code propriétaire de chaque client. De plus, la capacité de personnalisation devrait faire apparaître des boutons pour permettre la sélection du sous-ensemble de formation approprié à partir du référentiel interne en utilisant différentes métriques (par exemple, des fichiers avec un historique de moins de bogues ou du code récemment validé dans le référentiel). En sélectionnant le code en fonction de ces métriques, la personnalisation peut être entraînée à l'aide d'un code de meilleure qualité, ce qui peut améliorer la qualité des suggestions de code. Enfin, même avec des référentiels de code en constante évolution, le coût associé à la personnalisation devrait être minime pour aider les entreprises à réaliser des économies grâce à une productivité accrue des développeurs.

Une approche de base pour créer une personnalisation pourrait consister à pré-entraîner le modèle sur un seul corpus de formation composé de l'ensemble de données de pré-entraînement (public) existant ainsi que du code d'entreprise (privé). Bien que cette approche fonctionne dans la pratique, elle nécessite une pré-formation individuelle (redondante) utilisant l'ensemble de données publiques pour chaque entreprise. Cela nécessite également des coûts de déploiement redondants associés à l'hébergement d'un modèle personnalisé pour chaque client qui répond uniquement aux demandes des clients provenant de ce client. En dissociant la formation du code public et privé et en déployant la personnalisation sur un système multi-tenant, ces coûts redondants peuvent être évités.

Comment personnaliser

À un niveau élevé, il existe deux types de techniques de personnalisation possibles : la génération augmentée par récupération (RAG) et le réglage fin (FT).

• Génération augmentée par récupération : RAG trouve des morceaux de code correspondants dans un référentiel qui sont similaires à un fragment de code donné (par exemple, le code qui précède immédiatement le curseur dans l'EDI) et augmente l'invite utilisée pour interroger le LLM avec ces extraits de code correspondants. Cela enrichit l'invite pour aider à pousser le modèle à générer un code plus pertinent. Il existe quelques techniques explorées dans la littérature dans ce sens. Voir Génération de récupération augmentée pour les tâches PNL à forte intensité de connaissances, DOMAINE, kNN-LM et de RETRO.

• Réglage fin: FT prend un LLM pré-entraîné et le forme davantage sur une base de code spécifique plus petite (par rapport à l'ensemble de données de pré-formation) pour l'adapter au référentiel approprié. Le réglage fin ajuste les pondérations du LLM en fonction de cette formation, le rendant ainsi plus adapté aux besoins uniques de l'organisation.

RAG et le réglage fin sont tous deux des outils puissants pour améliorer les performances de la personnalisation basée sur LLM. RAG peut s'adapter rapidement aux bibliothèques privées ou aux API avec une complexité et un coût de formation moindres. Cependant, la recherche et l’augmentation des extraits de code récupérés dans l’invite augmentent la latence au moment de l’exécution. Au lieu de cela, le réglage fin ne nécessite aucune augmentation du contexte car le modèle est déjà formé sur des bibliothèques privées et des API. Cependant, cela entraîne des coûts de formation plus élevés et des complexités dans la gestion du modèle, lorsque plusieurs modèles personnalisés doivent être pris en charge par plusieurs entreprises clientes. Comme nous le verrons plus tard, ces problèmes peuvent être résolus en optimisant davantage l’approche.

Génération augmentée de récupération

Il y a quelques étapes impliquées dans RAG :

Indexage

Étant donné un référentiel privé entré par l'administrateur, un index est créé en divisant les fichiers de code source en morceaux. En termes simples, le chunking transforme les extraits de code en éléments digestibles, susceptibles d'être les plus informatifs pour le modèle et faciles à récupérer compte tenu du contexte. La taille d'un morceau et la manière dont il est extrait d'un fichier sont des choix de conception qui affectent le résultat final. Par exemple, les morceaux peuvent être divisés en fonction de lignes de code ou en fonction de blocs syntaxiques, etc.

Flux de travail de l'administrateur

Recherche contextuelle

Recherchez un ensemble d'extraits de code indexés en fonction de quelques lignes de code au-dessus du curseur et récupérez les extraits de code pertinents. Cette récupération peut avoir lieu à l'aide de différents algorithmes. Ces choix peuvent inclure :

• Sac de mots (BM25) - Une fonction de récupération d'un sac de mots qui classe un ensemble d'extraits de code en fonction de la fréquence des termes de requête et de la longueur des extraits de code.

Récupération basée sur BM25

La figure suivante illustre le fonctionnement du BM25. Afin d'utiliser BM25, un index inversé est d'abord construit. Il s'agit d'une structure de données qui mappe différents termes aux extraits de code dans lesquels ces termes apparaissent. Au moment de la recherche, nous recherchons des extraits de code en fonction des termes présents dans la requête et les notons en fonction de la fréquence.

Récupération sémantique

BM25 se concentre sur la correspondance lexicale. Par conséquent, remplacer « ajouter » par « supprimer » ne modifiera peut-être pas le score BM25 en fonction des termes de la requête, mais la fonctionnalité récupérée peut être à l'opposé de ce qui est requis. En revanche, la récupération sémantique se concentre sur la fonctionnalité de l'extrait de code même si les noms de variables et d'API peuvent être différents. En règle générale, une combinaison de BM25 et de récupérations sémantiques peut bien fonctionner ensemble pour fournir de meilleurs résultats.

Inférence augmentée

Lorsque les développeurs écrivent du code, leur programme existant est utilisé pour formuler une requête qui est envoyée à l'index de récupération. Après avoir récupéré plusieurs extraits de code à l'aide de l'une des techniques décrites ci-dessus, nous les ajoutons à l'invite d'origine. Il existe de nombreux choix de conception ici, notamment le nombre d'extraits de code à récupérer, le placement relatif des extraits de code dans l'invite et la taille de l'extrait de code. Le choix de conception final est principalement motivé par l'observation empirique en explorant diverses approches avec le modèle de langage sous-jacent et joue un rôle clé dans la détermination de l'exactitude de l'approche. Le contenu des morceaux renvoyés et le code d'origine sont combinés et envoyés au modèle pour obtenir des suggestions de code personnalisées.

Flux de travail du développeur

Réglage fin:

Réglage fin un modèle de langage est créé pour transférer l'apprentissage dans lequel les poids d'un modèle pré-entraîné sont formés sur de nouvelles données. L'objectif est de conserver les connaissances appropriées d'un modèle déjà formé sur un grand corpus et d'affiner, remplacer ou ajouter de nouvelles connaissances du nouveau corpus - dans notre cas, une nouvelle base de code. Une simple formation sur une nouvelle base de code conduit à l'oubli catastrophique. Par exemple, le modèle de langage peut « oublier » ses connaissances en matière de sécurité ou les API qui sont peu utilisées dans la base de code de l'entreprise à ce jour. Il existe diverses techniques comme rejouer l'expérience, GEMet une PP-TF qui sont employés pour relever ce défi.

Réglage fin

Il existe deux manières de procéder à un réglage fin. Une approche consiste à utiliser les données supplémentaires sans augmenter l'invite pour affiner le modèle. Une autre approche consiste à augmenter l'invite lors du réglage fin en récupérant les suggestions de code pertinentes. Cela contribue à améliorer la capacité du modèle à fournir de meilleures suggestions en présence d'extraits de code récupérés. Le modèle est ensuite évalué sur un ensemble d'exemples retenus après sa formation. Par la suite, le modèle personnalisé est déployé et utilisé pour générer les suggestions de code.

Malgré les avantages de l'utilisation de LLM dédiés pour générer du code sur des référentiels privés, les coûts peuvent être prohibitifs pour les petites et moyennes organisations. En effet, des ressources de calcul dédiées sont nécessaires même si elles peuvent être sous-utilisées compte tenu de la taille des équipes. Une façon d'atteindre la rentabilité consiste à servir plusieurs modèles sur le même calcul (par exemple, Multilocation SageMaker). Cependant, les modèles de langage nécessitent un ou plusieurs GPU dédiés sur plusieurs zones pour gérer les contraintes de latence et de débit. Par conséquent, la multilocation de l’hébergement complet du modèle sur chaque GPU est irréalisable.

Nous pouvons surmonter ce problème en servant plusieurs clients sur le même ordinateur en utilisant de petits adaptateurs au LLM. Techniques de réglage précis des paramètres (PEFT) telles que réglage rapide, réglage du préfixe, et l'adaptation de bas rang (LoRA) sont utilisés pour réduire les coûts de formation sans aucune perte de précision. LoRA, en particulier, a connu un grand succès en atteignant une précision similaire (ou meilleure) à celle du réglage fin du modèle complet. L'idée de base est de concevoir une matrice de bas rang qui est ensuite ajoutée aux matrices avec le poids matriciel d'origine des couches ciblées du modèle. Généralement, ces adaptateurs sont ensuite fusionnés avec les poids du modèle d'origine pour le service. Cela conduit à la même taille et à la même architecture que le réseau neuronal d'origine. En gardant les adaptateurs séparés, nous pouvons servir le même modèle de base avec de nombreux adaptateurs de modèles. Cela ramène les économies d’échelle à nos clients de petite et moyenne taille.

Adaptation de bas rang (LoRA)

Mesurer l'efficacité de la personnalisation

Nous avons besoin de mesures d’évaluation pour évaluer l’efficacité de la solution personnalisée. Les mesures d'évaluation hors ligne agissent comme des garde-fous contre les personnalisations d'expédition qui sont inférieures à celles du modèle par défaut. En créant des ensembles de données à partir d'un ensemble de données conservé à partir du référentiel fourni, l'approche de personnalisation peut être appliquée à cet ensemble de données pour mesurer l'efficacité. La comparaison du code source existant avec la suggestion de code personnalisé quantifie l'utilité de la personnalisation. Les mesures courantes utilisées pour cette quantification incluent des mesures telles que modifier la similarité, correspondance exacte, et CodeBLEU.

Il est également possible de mesurer l'utilité en quantifiant la fréquence à laquelle les API internes sont invoquées par la personnalisation et en la comparant aux invocations dans la source préexistante. Bien sûr, il est important de bien maîtriser les deux aspects pour réussir. Pour notre approche de personnalisation, nous avons conçu une métrique sur mesure connue sous le nom d'indice de qualité de personnalisation (CQI), une mesure unique et conviviale comprise entre 1 et 10. La métrique CQI montre l'utilité des suggestions du modèle personnalisé par rapport au code. suggestions avec un modèle public générique.

Résumé

Nous avons construit la capacité de personnalisation d'Amazon CodeWhisperer sur la base d'un mélange des principales techniques techniques abordées dans cet article de blog et l'avons évaluée à l'aide d'études utilisateur sur la productivité des développeurs, menées par Persistent Systems. Dans ces deux études, commandées par AWS, il a été demandé aux développeurs de créer une application logicielle médicale en Java nécessitant l'utilisation de leurs bibliothèques internes. Dans la première étude, les développeurs sans accès à CodeWhisperer ont mis (en moyenne) environ 8.2 heures pour terminer la tâche, tandis que ceux qui ont utilisé CodeWhisperer (sans personnalisation) ont accompli la tâche 62 % plus rapidement en (en moyenne) environ 3.1 heures.

Dans la deuxième étude portant sur un ensemble différent de cohortes de développeurs, les développeurs utilisant CodeWhisperer qui avait été personnalisé à l'aide de leur base de code privée ont accompli la tâche en 2.5 heures en moyenne, 28 % plus rapidement que ceux qui utilisaient CodeWhisperer sans personnalisation et ont terminé la tâche en environ 3.5 heures. heures en moyenne. Nous sommes convaincus que des outils tels que CodeWhisperer, personnalisés en fonction de votre base de code, ont un rôle clé à jouer pour améliorer davantage la productivité des développeurs et vous recommandons de les essayer. Pour plus d’informations et pour commencer, visitez le Page Amazon CodeWhisperer.

---

À propos des auteurs

Soleil Qing est scientifique appliqué senior chez AWS AI Labs et travaille sur AWS CodeWhisperer, un assistant de codage génératif basé sur l'IA. Ses intérêts de recherche portent sur le traitement du langage naturel, AI4Code et l'IA générative. Dans le passé, elle avait travaillé sur plusieurs services basés sur la PNL tels que Comprehend Medical, un système de diagnostic médical chez Amazon Health AI et le système de traduction automatique chez Meta AI. Elle a obtenu son doctorat à Virginia Tech en 2017.

Arash Farahani est un scientifique appliqué chez Amazon CodeWhisperer. Ses intérêts actuels portent sur l'IA générative, la recherche et la personnalisation. Arash est passionné par la création de solutions qui résolvent les problèmes des développeurs. Il a travaillé sur plusieurs fonctionnalités de CodeWhisperer et introduit des solutions NLP dans divers flux de travail internes qui touchent tous les développeurs Amazon. Il a obtenu son doctorat de l'Université de l'Illinois à Urbana-Champaign en 2017.

Xiaofei Maman est responsable des sciences appliquées chez AWS AI Labs. Il a rejoint Amazon en 2016 en tant que scientifique appliqué au sein de l'organisation SCOT, puis plus tard AWS AI Labs en 2018 pour travailler sur Amazon Kendra. Xiaofei a été responsable scientifique de plusieurs services, notamment Kendra, Contact Lens et, plus récemment, CodeWhisperer et CodeGuru Security. Ses intérêts de recherche portent sur le domaine de l'AI4Code et du traitement du langage naturel. Il a obtenu son doctorat de l'Université du Maryland, College Park en 2010.

Murali Krishna Ramanathan est chercheur appliqué principal au sein d'AWS AI Labs et codirige AWS CodeWhisperer, un compagnon de codage génératif basé sur l'IA. Il est passionné par la création d'outils logiciels et de flux de travail qui contribuent à améliorer la productivité des développeurs. Dans le passé, il a construit Piranha, un outil de refactorisation automatisé pour supprimer le code en raison d'indicateurs de fonctionnalités obsolètes et a dirigé des initiatives de qualité de code au sein de l'ingénierie Uber. Il est récipiendaire du prix de la faculté Google (2015), du prix ACM SIGSOFT Distinguished paper (ISSTA 2016) et du prix Maurice Halstead (Purdue 2006). Il a obtenu son doctorat en informatique de l'Université Purdue en 2008.

Ramesh Nallapati est chercheur appliqué principal principal chez AWS AI Labs et codirige CodeWhisperer, un compagnon de codage génératif basé sur l'IA, et Titan Large Language Models chez AWS. Ses intérêts portent principalement sur les domaines du traitement du langage naturel et de l'IA générative. Dans le passé, Ramesh a joué un rôle de leader scientifique dans la fourniture de nombreux produits AWS basés sur la PNL, tels que Kendra, Quicksight Q et Contact Lens. Il a occupé des postes de recherche à Stanford, CMU et IBM Research, et a obtenu son doctorat. en informatique de l'Université du Massachusetts Amherst en 2006.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/customizing-coding-companions-for-organizations/