On pensait attendre une "fraise", mais c'est un "chou kale" qui est arrivé
Bien que le monde entier ait les yeux rivés sur le "projet fraise", il semble que l'OpenAI rebelle ne soit pas toujours à la hauteur des attentes. Vous voulez une "fraise", ils vous donnent plutôt un "chou kale".
À 2 heures du matin, heure de Pékin, le 14, OpenAI a publié sur son site officiel qu'il publiait un sous-ensemble vérifié manuellement de SWE-bench, qui peut évaluer plus fiablement la capacité des modèles d'IA à résoudre des problèmes logiciels du monde réel.
Adresse Hugging Face de SWE-bench :
https://huggingface.co/datasets/princeton-nlp/SWE-bench_Verified
Dans le cadre de son cadre de préparation (un ensemble de méthodes établies par OpenAI pour développer et déployer en toute sécurité ses modèles de pointe), OpenAI a développé une série de métriques pour suivre, évaluer et prédire les capacités d'action autonome des modèles.
La capacité à accomplir de manière autonome des tâches d'ingénierie logicielle a toujours été un élément clé du niveau de risque moyen dans la catégorie des risques autonomes des modèles de pointe. En raison de la complexité des tâches d'ingénierie logicielle, de la difficulté d'évaluer avec précision le code généré et des défis de simulation des scénarios de développement du monde réel, l'évaluation de ces capacités est difficile. Par conséquent, l'approche de préparation d'OpenAI doit également examiner attentivement l'évaluation elle-même, minimisant la possibilité de surestimer ou de sous-estimer les facteurs de risque.
L'une des suites d'évaluation d'ingénierie logicielle les plus populaires dans cette méthode est SWE-bench. Elle peut être utilisée pour évaluer si les grands modèles de langage peuvent réellement résoudre des problèmes logiciels réels de GitHub, et dans quelle mesure ils peuvent les résoudre. Le benchmark consiste à fournir aux agents un référentiel de code et une description du problème, et à leur demander de générer un correctif qui résout le problème décrit.
Selon le classement SWE-bench, au 5 août 2024, les agents de codage ont fait des progrès remarquables sur SWE-bench, avec l'agent le mieux performant obtenant un score de 20% sur SWE-bench et 43% sur SWE-bench Lite.
Après des tests, il a été constaté que certaines tâches sur SWE-bench peuvent être difficiles ou impossibles à résoudre, ce qui conduit SWE-bench à sous-estimer systématiquement les capacités d'ingénierie logicielle autonome des modèles. OpenAI a donc collaboré avec les auteurs de SWE-bench pour résoudre ces problèmes dans une nouvelle version du benchmark, qui devrait fournir une évaluation plus précise.
Alors, quel est le contexte de SWE-bench ?
Chaque exemple dans l'ensemble de tests SWE-bench est créé à partir d'un problème GitHub résolu dans l'un des 12 référentiels Python open source sur GitHub. Chaque exemple a une demande de tirage (PR) associée qui inclut le code de la solution et des tests unitaires utilisés pour vérifier l'exactitude du code. Ces tests unitaires échouent avant l'ajout du code de solution dans la PR, mais réussissent ensuite, donc appelés tests FAIL_TO_PASS. Chaque exemple a également des tests PASS_TO_PASS associés, qui passent avant et après la fusion de la PR, utilisés pour vérifier que les fonctionnalités existantes non liées dans la base de code n'ont pas été cassées par la PR.
Pour chaque échantillon dans SWE-bench, l'agent reçoit le texte original de la question GitHub (appelé énoncé du problème) et se voit accorder l'accès au référentiel de code. Avec cela, l'agent doit éditer les fichiers dans le référentiel de code pour résoudre le problème. Les tests ne sont pas montrés à l'agent.
FAIL_TO_PASS évalue les modifications proposées en exécutant et en testant PASS_TO_PASS. Si les tests passent, cela signifie que le problème a été résolu. Si les tests passent, les modifications n'ont pas accidentellement cassé des parties non liées de la base de code. Les modifications doivent passer ces deux ensembles de tests pour résoudre complètement le problème GitHub original.
Adoption de SWE-bench comme évaluation de l'état de préparation
Étant donné la pertinence potentielle de SWE-bench pour le cadre de préparation, les chercheurs visaient à trouver des moyens d'améliorer la robustesse et la fiabilité du benchmark. Trois principaux domaines d'amélioration ont donc été identifiés :
Les tests unitaires utilisés pour évaluer l'exactitude des solutions sont souvent trop spécifiques et parfois même sans rapport avec le problème. Cela peut conduire au rejet de solutions correctes.
Les descriptions de problèmes pour de nombreux exemples sont ambiguës, rendant difficile de comprendre clairement quel est le problème et comment le résoudre.
Il est parfois difficile pour les agents de configurer de manière fiable l'environnement de développement SWE-bench, ce qui peut conduire involontairement à l'échec des tests unitaires quelle que soit la solution adoptée. Dans ce cas, des solutions parfaitement valides peuvent être jugées incorrectes.
Voici un exemple illustrant le premier problème.
La tâche SWE-bench scikit-learn__scikit-learn-14520 consiste à faire résoudre par l'agent un problème dans le référentiel scikit-learn. Cet énoncé de problème signale que le paramètre copy d'une fonction peut être spécifié par l'utilisateur mais est ignoré par la bibliothèque (le comportement est plutôt codé en dur dans la fonction) :
Pour résoudre ce problème, l'agent doit d'abord déterminer si le comportement de la fonction est intentionnel ou une erreur, puis apporter des modifications à la base de code pour résoudre le problème. Selon la configuration de SWE-bench, toute solution proposée par l'agent doit passer le test suivant, extrait de la PR qui a initialement résolu le problème :
Ce test vérifie spécifiquement si la solution doit lever un DeprecationWarning lorsque le paramètre copy est utilisé, bien que l'énoncé du problème original dans le texte ci-dessus ne communique pas cette exigence. De plus, même si l'agent réalise qu'un DeprecationWarning doit être levé, le test exige que l'agent corresponde exactement au message de dépréciation, qui a été déterminé après quelques discussions dans la PR à laquelle l'agent n'a pas accès.
Notez que l'agent ne reçoit la description du problème que du texte principal du problème et ne peut pas voir les tests qu'il doit passer. Dans cette configuration, il est presque impossible pour l'agent de résoudre cet exemple dans SWE-bench.
SWE-bench vérifié
Pour résoudre ces problèmes, OpenAI a lancé une campagne d'annotation manuelle avec des développeurs logiciels professionnels pour examiner chaque échantillon de l'ensemble de tests SWE-bench afin d'obtenir des tests unitaires de portée appropriée et des descriptions de problèmes clairement spécifiées.
OpenAI a publié, en collaboration avec les auteurs de SWE-bench, SWE-bench Verified : un sous-ensemble du jeu de tests original de SWE-bench contenant 500 échantillons vérifiés sans problème par des annotateurs humains. Cette version remplace les ensembles de tests SWE-bench et SWE-bench Lite originaux. De plus, OpenAI a publié des annotations manuelles pour tous les échantillons de test SWE-bench.
En même temps, OpenAI a collaboré avec les auteurs de SWE-bench pour développer de nouveaux outils d'évaluation pour SWE-bench. Il utilise un environnement Docker conteneurisé pour rendre l'évaluation sur SWE-bench plus facile et plus fiable.
Sur SWE-bench Verified, GPT-4o a résolu 33,2% des échantillons, soit le double du score précédent de 16% obtenu par le meilleur agent open source Agentless sur SWE-bench.
N'ayant pas reçu l'annonce officielle du "projet fraise", cet ensemble de tests peut tout au plus être considéré comme un amuse-bouche. Alors, un tel ensemble de tests vaut-il la peine qu'OpenAI en fasse la promotion ?
Il y a une semaine, le PDG d'OpenAI, Sam Altman, a publié un tweet avec une image de fraises, accompagné du texte "J'aime l'été dans le jardin". Les quatre fraises de l'image suggéraient peut-être qu'une nouvelle version de GPT-4 pourrait être spécialement conçue pour le raisonnement, fonctionnant aux côtés de GPT-4o, conçu pour la création et l'interaction. Cela a suscité toutes sortes de spéculations sur le lancement d'un nouveau modèle Strawberry par OpenAI.
Ces deux derniers jours, le leaker @iruletheworldmo sur X a fréquemment publié des messages liés à la sortie de Strawberry, indiquant qu'OpenAI lancerait son nouveau modèle - un projet d'IA axé sur le raisonnement "Strawberry" - le 13 août à 10h, heure du Pacifique. Toute la communauté était pleine d'attentes.
Qu'est-ce que le mystérieux "projet fraise" ?
Le nouveau "projet fraise" d'OpenAI permettrait à ChatGPT de rechercher plus librement sur le web et de résoudre des problèmes complexes.
Le "projet fraise" a été révélé pour la première fois par les médias étrangers le 12 juillet. Selon des initiés et des documents internes examinés par Reuters, OpenAI, le fabricant de ChatGPT, étudie de nouvelles approches pour ses modèles d'IA dans un projet nommé "Strawberry".
Mais les détails du projet n'avaient jamais été rapportés auparavant, alors que la startup soutenue par Microsoft s'efforce de prouver que les types de modèles qu'elle propose peuvent offrir des capacités de raisonnement avancées.
Selon une copie d'un document interne d'OpenAI vue par Reuters en mai, une équipe interne d'OpenAI développe Strawberry. Reuters n'a pas pu déterminer la date exacte de publication du document, qui détaillait les plans d'OpenAI pour utiliser Strawberry dans la recherche. Les sources ont décrit le plan à Reuters comme un travail en cours. L'agence de presse n'a pas pu déterminer à quel point Strawberry était proche d'une sortie publique.
La source a déclaré que même au sein d'OpenAI, le fonctionnement de Strawberry est un secret bien gardé.
Le document décrit un projet utilisant le modèle Strawberry dans le but de permettre à l'IA de l'entreprise non seulement de générer des réponses aux requêtes, mais aussi de planifier à l'avance et de naviguer de manière autonome et fiable sur Internet pour effectuer ce qu'OpenAI appelle une "recherche approfondie", selon la source.
Selon des entretiens avec plus d'une douzaine de chercheurs en IA, c'est un problème que les modèles d'IA n'ont pas encore résolu à ce jour.
À l'époque, interrogé sur Strawberry et les détails rapportés dans cet article, un porte-parole d'OpenAI a déclaré dans un communiqué : "Nous espérons que nos modèles d'IA pourront voir et comprendre le monde comme nous le faisons. La recherche continue de nouvelles capacités d'IA est une pratique courante dans l'industrie, avec la croyance commune que les capacités de raisonnement de ces systèmes s'amélioreront avec le temps."
Le porte-parole n'a pas directement répondu aux questions sur Strawberry.
Google lance le défi
Strawberry a toujours été "à moitié caché derrière un luth", et cette fois, OpenAI a soudainement annoncé une campagne de promotion, ### il est difficile de dire que ce n'est pas pour rattraper l'événement matériel "Made by Google 2024" de Google qui se déroule presque simultanément.
Lors de cet événement, Google a présenté ses derniers produits matériels, notamment la prochaine génération de téléphones Pixel tant attendue : Pixel 9, Pixel 9 Pro et le nouveau Pixel 9 Fold, ainsi que de nouveaux produits matériels tels que la Pixel Watch et les Pixel Buds. Bien qu'il s'agisse d'un lancement matériel, le thème de l'IA a imprégné l'ensemble de la présentation. Notamment, le chatbot IA de Google, Gemini, est l'assistant par défaut des téléphones Pixel 9.