Les grands modèles ne peuvent pas être des agriculteurs de code ! La découverte surprenante de Princeton : GPT-4 a un taux de réussite de 0 dans la résolution des problèmes de programmation GitHub

Source de l’article : Shin Ji Yuan

outils de codage d’IA comme ChatGPT sont menaçants, et Stack Overflow licencie à nouveau ! Cependant, Princeton et Chicago ont constaté que GPT-4 avait un taux de résolution de 0 % pour les problèmes GitHub du monde réel.

Stack Overflow, déjà créé par ChatGPT !

Parce que les codeurs ont afflué vers ChatGPT et Github Copilot, Stack Overflow a dû annoncer aujourd’hui le licenciement de plus de 100 employés, soit près d’un tiers du nombre d’employés.

Donc, les outils de codage d’IA comme ChatGPT vont-ils vraiment subvertir l’ensemble de l’industrie ?

Mais une étude récente de Princeton et de Chicago a révélé que le LLM n’est pas si facile à faire en tant qu’agriculteur de code.

Adresse papier :

Face à 2294 problèmes GitHub réels, le taux de réussite de GPT-4 résolvant des problèmes GitHub aléatoires s’est avéré être de 0% !

Même le meilleur modèle, le Claude 2, ne résout que 1,96% d’entre eux.

Les codeurs peuvent-ils perdre leur emploi à cause de ChatGPT ? La réponse est : absolument pas pour le moment.

S’adapter ou périr

En tant que site assisté par code préféré de tous les développeurs dans le monde, Stack Overflow s’est bien débrouillé auparavant, déclenchant une frénésie d’embauche l’année dernière, doublant les effectifs de l’entreprise à 540.

Cependant, tout a changé depuis qu’OpenAI a publié ChatGPT en novembre dernier.

L’aide fournie par les chatbots IA est plus spécifique que le message du forum il y a 5 ans. Avec LLM, les développeurs peuvent corriger instantanément le code exact, des suggestions d’optimisation et une description de ce que fait chaque ligne de code.

Bien que LLM ne fournisse pas de réponses fiables à 100 %, la capacité unique de valider le code immédiatement en le testant simplement dans l’environnement de développement intégré de l’IDE fait de l’écriture de code un cas d’utilisation idéal pour ChatGPT.

En conséquence, le trafic de Stack Overflow a été considérablement réduit, et les outils de programmation d’IA tels que ChatGPT et Github Copilot alimenté par GPT-4 sont devenus de nouveaux endroits pour les agriculteurs de code.

Aujourd’hui, le PDG Prashanth Chandrasekar a annoncé que Stack Overflow avait licencié plus d’une centaine d’employés, soit 28 % de ses effectifs.

L’explication du PDG pour les licenciements est que Stack Overflow essaie de se mettre sur la voie de la rentabilité sous la pression macroéconomique et continue d’introduire des innovations de produits.

** Traverser la rivière et abattre le pont ? **

La plus grande ironie de l’impact de ChatGPT sur Stack Overflow est que la puissance du grand modèle de langage provient en grande partie du grattage de sites comme Stack Overflow.

Que se passe-t-il si les grands modèles de langage vident ces données sans rien rendre en retour, et si toutes les sources de données sont forcées de quitter l’entreprise ?

Aujourd’hui, de nombreuses entreprises technologiques ont déjà un problème imminent : s’il y a moins de programmeurs, il y aura moins de données artificielles.

Comment entraîner de nouveaux modèles d’IA sans données à jour ?

Vous souhaitez utiliser nos données ? Prenez l’argent**

Stack Overflow, bien sûr, ne peut pas rester immobile, il a choisi deux façons de se sauver -

L’une consiste à développer son propre outil de codage d’IA, OverflowAI, et l’autre consiste à rechercher des partenariats directement avec des entreprises technologiques comme OpenAI, qui utilisent les données de Stack Overflow pour construire des modèles d’IA.

OpenAI développe des contrôles de robot d’indexation Web pour ChatGPT afin que les données de sites comme Stack Overflow ne puissent pas être explorées.

Le PDG a déclaré que Stack Overflow avait pris position : quiconque veut utiliser nos données pour former le LLM paie.

Les PDG pensent que des sites comme Stack Overflow sont essentiels au développement de grands modèles de langage, et que pour progresser, ils doivent être formés à de nouvelles connaissances.

Prashanth Chandrasekar, PDG de Stack Overflow

LLM veut obtenir le code farmer, il est encore tôt

Alors, les grands modèles de langage peuvent-ils vraiment prendre des agriculteurs de code ?

Les équipes de Princeton et de Chicago ont constaté que ce n’était pas si facile !

Dans le dernier article, les chercheurs proposent un nouveau cadre, SWE-bench, pour évaluer la capacité des grands modèles à résoudre 2294 problèmes du monde réel sur GitHub.

Il a été constaté que les grands modèles de premier plan comme GPT-4 et Claude 2 avaient moins de 5% de capacité à résoudre des problèmes réels.

Pour être plus précis, GPT-4 peut résoudre des problèmes GitHub aléatoires avec un taux de réussite de 0 %, alors que le meilleur modèle, Claude 2, ne peut résoudre que 1,96 % d’entre eux.

De plus, lors de l’utilisation du BM-25 pour récupérer les fichiers de code pertinents pour chaque problème, seulement 23% des correctifs écrits par Claude 2 étaient valides (prêts pour le dépôt), et seulement ~1% ont réellement résolu le problème.

En outre, les performances des différents modèles dans la résolution de problèmes avec 12 bibliothèques Python populaires varient également.

Le modèle GPT-4 a atteint un tel résultat, ce qui est vraiment surprenant, après tout, beaucoup de gens l’ont longtemps considéré comme une « arme de programmation ».

Mais pour y voir clair, la vraie force de l’IA, ne vous laissez pas noter et ne vous inquiétez pas.

Certains internautes ont déclaré que c’était la meilleure réponse à la question de savoir « si les agriculteurs du code sont au chômage en raison de la programmation ».

Finalement, quelqu’un a créé un véritable jeu de données pour le modèle de code, et Hum n’était que l’interview de LLM pour leetcode. Nous savons tous que ce n’est pas la bonne mesure pour les ingénieurs humains. Moins de 4 %, c’est bien, car les grands modèles sont encore loin d’être totalement autonomes.

Alors, est-ce vraiment le cas avec les résultats de SWE-bench dans l’évaluation des capacités des grands modèles ?

SWE-bench : Conçu pour le codage des modèles

Dans cette étude, les auteurs ont constaté que de nombreux points de référence actuels pour mesurer la capacité de codage des grands modèles sont saturés et ne peuvent pas mesurer la véritable force des grands modèles.

Par exemple, dans Human, le problème du défi est trop simple, et le LLM n’a besoin que de quelques lignes de code pour résoudre un problème autonome.

Cependant, le génie logiciel n’est pas si simple en réalité.

La correction d’un bogue peut nécessiter de parcourir une énorme bibliothèque de ressources, de comprendre les relations entre les fonctions dans différents fichiers ou de trouver un petit bogue dans le code complexe.

Inspirés par cela, des chercheurs de Princeton et de Chicago ont introduit SWE-bench.

SWE-bench récupère les instances de tâches à partir d’un véritable référentiel Python en connectant les problèmes GitHub et les solutions de demande de fusion pour résoudre les tests associés.

Comme le montre l’image, la tâche du modèle, généralement un rapport de bogue ou une demande de fonctionnalité, consiste à résoudre un problème validé dans le référentiel GitHub.

Chaque tâche nécessite la génération d’un correctif et la description des modifications à appliquer à la base de code existante.

Utilisez ensuite l’infrastructure de test SWE-bench du référentiel pour évaluer la base de code modifiée.

Pour trouver des exemples de haute qualité de tâches à grande échelle, les chercheurs sont passés par trois étapes de criblage :

**Étape 1 : Sélection de l’entrepôt et recherche de données. **

Les demandes de tirage (PR) ont d’abord été collectées à partir de 12 dépôts Python open source populaires sur GitHub, générant un total d’environ 90 000 demandes de tirage.

Les chercheurs se sont concentrés sur les référentiels populaires parce qu’ils ont tendance à être mieux entretenus, à avoir des directives claires pour les contributeurs et à avoir une meilleure couverture de test. Chaque PR a une base de code associée, c’est-à-dire l’état du référentiel avant la fusion de la PR.

**Phase 2 : Filtrage basé sur les attributs. **

La tâche candidate est créée en sélectionnant une demande de tirage fusionnée qui répond aux critères suivants : (1) résout le problème GitHub ; (2) Modification du fichier de test du référentiel, ce qui indique que l’utilisateur a très probablement contribué à des tests pour vérifier si le problème est résolu.

**Phase 3 : Filtrage basé sur l’exécution. **

Pour chaque tâche candidate, le contenu de test de la demande de tirage est appliqué, et les résultats de test pertinents avant et après l’application de l’autre contenu de la demande de tirage.

Le chercheur filtre les cas de tâches qui n’ont pas au moins un test, et le statut de ces tests passe de échec à la réussite (ci-après dénommé « échec à la réussite du test »). De plus, les instances qui provoquent des erreurs d’installation ou de fonctionnement sont filtrées.

Au cours de ces étapes de sélection, les 90 000 RP d’origine sont examinés en 2 294 instances de tâches, qui constituent le banc SWE.

La classification finale de ces instances de tâches dans différents référentiels est illustrée dans la figure 3 ci-dessous, le tableau étant la principale caractéristique des instances de tâches SWE-bench.

Les chercheurs soulignent que ces bases de code sont volumineuses, contenant des milliers de fichiers, et que les demandes de tirage de référence modifient souvent plusieurs fichiers en même temps.

SWE-bench offre plusieurs avantages par rapport aux benchmarks de programmation LM existants.

Il s’agit notamment de paramètres réels avec des problèmes et des solutions soumis par les utilisateurs, d’entrées diverses comprenant des questions de code uniques provenant de 12 référentiels, d’un cadre d’évaluation robuste basé sur l’exécution et de la possibilité de mettre à jour en permanence les benchmarks avec de nouvelles instances avec une intervention humaine minimale.

Tâche LLM : Modifier la base de code, résoudre les problèmes

Le chercheur donnera au grand modèle une description textuelle du problème, ainsi qu’une base de code complète.

La tâche du grand modèle est de modifier la base de code pour résoudre le problème.

En pratique, les chercheurs représentent les modifications sous forme de fichiers de correctifs, qui spécifient les lignes de la base de code à modifier pour résoudre le problème.

Comment évaluer si la solution donnée par LLM est bonne ou non ?

Les chercheurs utilisent des correctifs Unix, appliquent les correctifs générés à la base de code, puis effectuent des tests unitaires et système liés aux instances de tâche.

Si le correctif est appliqué avec succès et que tous ces tests sont réussis, le schéma recommandé par LLM peut être considéré comme ayant résolu le problème avec succès.

Mesure de la ligne de base, qui correspond au pourcentage d’instances de tâche résolues.

Création d’un jeu de données unique pour SWE-bench

Les benchmarks NLP traditionnels n’impliquent généralement que de courtes séquences d’entrée et de sortie et considèrent certains problèmes « artificiels » créés spécifiquement pour les benchmarks.

En revanche, pour construire le banc SWE, les chercheurs ont injecté des propriétés uniques dans l’ensemble de données.

Par exemple, des tâches réelles d’ingénierie logicielle sont utilisées.

Étant donné que chaque instance de tâche dans SWE-bench contient une base de code volumineuse et complexe et une description du problème associé, la résolution de SWE-bench nécessite les compétences et les connaissances complexes d’ingénieurs logiciels expérimentés, qui ne sont souvent pas évaluées dans les benchmarks de génération de code traditionnels.

De plus, le processus de collecte peut être facilement appliqué à n’importe quel dépôt Python sur GitHub avec peu ou pas d’intervention humaine.

Par conséquent, les chercheurs peuvent étendre le SWE-bench en fournissant de nouvelles instances de tâches et évaluer le modèle de langage pour les problèmes créés après la date de formation, en s’assurant que le corpus d’apprentissage ne contient pas de solution.

De plus, les chercheurs garantissent différentes entrées longues dans le benchmark, une évaluation robuste, une édition de code inter-contexte, une large gamme de solutions, etc.

Mise au point de SWE-Llama

Ensuite, il est temps d’évaluer l’efficacité des modèles ouverts et propriétaires dans le cadre SWE-bench.

Cependant, les chercheurs ont constaté que les modèles de réglage fin CodeLlama prêts à l’emploi ne pouvaient pas suivre d’instructions détaillées pour générer des modifications de code à l’échelle de la bibliothèque, produisant souvent des réponses d’espace réservé ou du code non pertinent.

Pour évaluer les capacités de ces modèles, les chercheurs ont effectué un réglage fin supervisé (SFT) sur le modèle CodeLlama-Python à 7 milliards de paramètres et le modèle CodeLlama-Python à 13 milliards de paramètres.

Le modèle qui en résulte est un éditeur de référentiel spécialisé qui s’exécute sur du matériel grand public et résout les problèmes GitHub.

### Les gros modèles échouent

Ensuite, les chercheurs ont évalué GPT-3.5, GPT-4, Cluade 2 et des modèles affinés.

Il s’est avéré que tous les modèles ont échoué - aucun d’entre eux n’a résolu tous les problèmes, sauf les plus simples.

Par exemple, Claude 2 et GPT-4 ne peuvent résoudre que 4,8 % et 1,7 % des tâches, respectivement.

Après l’utilisation du retriever BM25, les performances de Claude 2 ont encore chuté à 1,96 %.

**Les différentes bibliothèques ont différents niveaux de difficulté. **

Si vous décomposez les performances par référentiel, vous verrez que tous les modèles présentent des tendances similaires dans toutes les bibliothèques.

Néanmoins, les problèmes abordés par chaque modèle ne se recoupent pas nécessairement de manière importante. Par exemple, dans une configuration oracle, Claude 2 et SWE-Llama 13b ont des performances comparables, résolvant respectivement 110 et 91 instances par modèle.

**La difficulté dépend de la longueur du contexte. **

Les modèles peuvent être pré-entraînés sur de longues séquences de code, mais nécessitent généralement qu’une seule fonction soit générée à la fois et fournissent un cadre avec un contexte limité pour déterminer le problème.

Comme indiqué, vous pouvez voir que les performances de Claude 2 se dégradent considérablement à mesure que la longueur totale du contexte augmente, ce qui peut également être observé dans d’autres modèles.

Même si l’augmentation de la taille maximale du contexte du BM25 améliorait le rappel par rapport aux fichiers Oracle, les performances se dégraderaient tout de même, car le modèle ne pouvait tout simplement pas localiser le code problématique dans le vaste thésaurus.

**La difficulté est indépendante de la date de résolution du problème. **

Le tableau 7 présente les résultats du modèle par date pour les demandes de tirage créées avant ou après 2023 dans les paramètres de recherche « oracle ».

Pour la plupart des modèles, à l’exception de GPT-4, il y a peu de différence de performance avant ou après cette date.

En outre, l’étude a révélé que l’ajustement fin du modèle est sensible aux changements dans la distribution contextuelle, et qu’il est plus facile de générer un correctif que de générer un fichier entier. Et les grands modèles ont tendance à produire des montages plus courts et plus simples.

Le LLM ne remplace pas les programmeurs, mais il peut accélérer les flux de travail

Certains internautes ont des espoirs et des espoirs pour l’avenir du « modèle généraliste ».

C’est vrai, c’est ce que je dis. Le modèle généraliste n’est pas assez bon pour avoir une longueur de contexte suffisamment large pour coder seul, à l’exception d’extraits de code relativement courts.

Mais je pense que ce n’est qu’une question de temps. Je peux prévoir que dans un avenir proche, le LLM généraliste avec une formation spécifique deviendra un modèle très professionnel.

Bien que les grands modèles ne remplacent pas les programmeurs, ils peuvent accélérer leurs flux de travail. Ce qui nécessitait auparavant une équipe de 10 personnes n’a plus besoin que de 4 personnes. Cela libère des ressources pour d’autres objectifs préparés par l’entreprise.

Au lieu de licencier des employés pour économiser de l’argent, laissez les développeurs accomplir de grandes choses à une vitesse vertigineuse !

Ressources: