Nos dernières avancées de modèles apportent des capacités renforcées pour construire et migrer des logiciels dans des langages de programmation à faibles ressources tels que COBOL, Fortran et Visual Basic. Ces langages disposent de moins de code et de documentation sur lesquels les modèles peuvent apprendre que des langages comme Python et JavaScript, mais ils prennent en charge des infrastructures critiques et des services essentiels dans le monde entier. COBOL prend en charge(ouvre dans une nouvelle fenêtre) plus de 40% des systèmes bancaires en ligne, 80% des transactions de cartes de crédit en personne et 95% des transactions aux guichets automatiques, tandis que Fortran est utilisé dans les prévisions météorologiques(ouvre dans une nouvelle fenêtre) et l'analyse de la sûreté des réacteurs nucléaires(ouvre dans une nouvelle fenêtre). Améliorer la capacité de l'IA à travailler dans ces langages pourrait aider les équipes à maintenir et à moderniser les logiciels dont dépendent les services essentiels.
Ce travail est guidé par les retours de développeurs et de clients entreprises qui nous ont dit que les modèles de programmation peinent souvent avec ces langages. Maintenir et moderniser ces logiciels peut être difficile : la documentation peut être incomplète, les développeurs d'origine peuvent avoir quitté l'entreprise, et des règles commerciales importantes peuvent n'exister que dans le code. Qu'il s'agisse de corriger des bugs ou de migrer vers un autre langage, les équipes doivent préserver le comportement dont leurs systèmes dépendent.
Pour mesurer les progrès, nous avons développé deux évaluations. MultiLangBench teste si un modèle peut construire un moteur de base de données compatible SQLite à partir de zéro dans 20 langages de programmation différents. Notre évaluation de migration COBOL teste si un modèle peut migrer des programmes existants vers un autre langage tout en préservant leur comportement. Ensemble, elles testent deux compétences complémentaires : construire de nouveaux logiciels et préserver ce que font les logiciels existants.
Nos derniers modèles montrent des améliorations substantielles dans les deux évaluations, offrant une précision bien plus élevée à moindre coût.
Sur MultiLangBench, GPT‑6 Astra atteint un taux de réussite moyen aux tests de 87.4% sur 20 langages de programmation, contre 26.8% pour GPT‑5.6 Sol, avec des améliorations dans chaque langage testé. GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40.3% avec un coût API estimé environ 78% inférieur.
Sur notre évaluation de migration COBOL, GPT‑6.1 Sol atteint une précision de 86.6% à faible effort de raisonnement, contre seulement 5.4% pour GPT‑5.6 Sol, tout en coûtant 39% moins cher. À effort de raisonnement plus élevé, la précision atteint 97.9%, saturant presque l'évaluation.
Ensemble, ces résultats montrent que nos modèles deviennent nettement meilleurs pour travailler avec un large éventail de langages de programmation, tout en devenant plus rentables.
1. Construire SQLite à partir de zéro (MultiLangBench)
MultiLangBench demande à un modèle de construire un moteur de base de données compatible SQLite dans un langage de programmation spécifié. Le modèle doit organiser une base de code, gérer l'état, gérer les erreurs et ajouter de nouvelles fonctionnalités tout en préservant les fonctionnalités existantes.
Pour comparer les implémentations entre langages, nous utilisons des fichiers de base de données comme interface commune. Le programme candidat reçoit une base de données initiale et une requête SQL, puis produit une base de données modifiée. Nous utilisons l'implémentation de référence SQLite pour vérifier si la base de données résultante contient le contenu attendu. Cela nous permet d'appliquer les mêmes tests quel que soit le langage utilisé pour construire le moteur.
Nous avons adapté les tests de la suite de tests existante de SQLite à ce format. L'évaluation mesure la quantité de fonctionnalités opérationnelles qu'un modèle peut construire au cours d'une session de programmation prolongée, en rapportant à la fois le taux de réussite aux tests et le coût API.
À effort de raisonnement maximal, GPT‑6 Astra atteint un taux de réussite moyen aux tests de 87.4% sur les 20 langages, contre 26.8% pour GPT‑5.6 Sol. Les améliorations s'étendent à chaque langage testé, notamment COBOL (10.9% à 72.1%), OCaml (25.6% à 85.8%), Fortran (21.4% à 83.5%) et Visual Basic (27.5% à 89.4%). Astra obtient plus de 83% dans 19 des 20 langages, COBOL restant le plus difficile à 72%.
GPT‑6 Luna offre une option à moindre coût qui améliore également GPT‑5.6 Sol dans chaque langage testé. À effort de raisonnement maximal, il atteint un taux de réussite moyen aux tests de 40.3%. Les gains incluent COBOL (10.9% à 17.1%), OCaml (25.6% à 34.1%), Fortran (21.4% à 31.4%) et Visual Basic (27.5% à 41.6%). Ces améliorations s'accompagnent d'un coût API moyen estimé de 0,77 $ par échantillon, contre 3,48 $ pour GPT‑5.6 Sol, soit environ 78% inférieur.
Nous publions la configuration d'évaluation MultiLangBench et la suite de tests sur GitHub(ouvre dans une nouvelle fenêtre), ainsi que les résultats pour chaque langage. Les développeurs peuvent examiner ce que l'évaluation teste, consulter les performances dans les langages qu'ils utilisent et identifier les lacunes importantes pour leur propre travail.
2. Migrer une base de code COBOL
Notre deuxième évaluation demande aux modèles de migrer des programmes COBOL vers C++, Java, Kotlin, Python ou Rust tout en préservant ce que fait chaque programme.
Une migration réussie nécessite de comprendre à la fois la logique commerciale du programme et le comportement spécifique du langage COBOL. Les programmes COBOL traitent souvent des transactions financières et des enregistrements commerciaux, où des détails tels que les règles d'arrondi et la gestion des enregistrements manquants reflètent des exigences commerciales. Par exemple, l'arithmétique à virgule fixe de COBOL rejette les chiffres décimaux excédentaires sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s'exécuter sans erreur tout en produisant des résultats financiers différents.
Pour vérifier si ces comportements sont préservés, nous évaluons nos modèles sur des tests cachés qui exigent une parité octet par octet sur les sorties observables. Une migration est considérée comme réussie uniquement si tous les tests passent. Des capacités de préservation du comportement comme celles-ci sont utiles pour les équipes qui maintiennent et modernisent des systèmes plus anciens, bien que leur application à des logiciels en production nécessite toujours une revue par des experts et des tests par rapport aux règles métier et aux dépendances du système.
Sur cette évaluation, GPT‑6.1 Sol atteint une précision de 86.6% à un faible effort de raisonnement, contre 5.4% pour GPT‑5.6 Sol au même réglage, et ce pour seulement 61% du coût de l'API. À un effort de raisonnement plus élevé, la précision atteint 97.9%, rapprochant l'évaluation de la saturation. Ces résultats d'évaluation démontrent des progrès vers une migration de code plus précise et plus abordable pour les équipes qui modernisent les logiciels dont dépendent leurs entreprises.
Faire progresser les capacités pour les logiciels d'entreprise
Ces évaluations, ainsi que les retours directs des développeurs et des clients entreprise, nous aident à voir où nos modèles s'améliorent et où ils restent encore en deçà.
Notre objectif est d'aider les modèles à appliquer leurs compétences en ingénierie logicielle à davantage de langages : comprendre des dépôts inconnus, planifier des modifications, utiliser des outils de build, exécuter des tests et déboguer les échecs.
Vous pouvez essayer nos derniers modèles via l'API sur des tâches de codage dans les langages utilisés par votre équipe. Vos retours sur ce qui fonctionne, sur les points où les modèles rencontrent des difficultés et sur les langages ou les flux de travail sur lesquels nous devrions nous concentrer ensuite nous aident à façonner la manière dont nous entraînons et évaluons les modèles pour mieux soutenir les logiciels dont vous dépendez.