Zum Hauptinhalt springen
OpenAI

Fortschritte beim Programmieren in Sprachen mit wenig Trainingsmaterial

Laden …

Unsere neuesten Modellfortschritte verbessern die Fähigkeiten, Software in Programmiersprachen mit wenig Trainingsmaterial wie COBOL, Fortran und Visual Basic zu entwickeln und zu migrieren. Für diese Sprachen stehen Modellen weniger Code und Dokumentation zum Lernen zur Verfügung als etwa für Python und JavaScript. Dennoch bilden sie weltweit die Grundlage für kritische Infrastruktur und unverzichtbare Dienste. COBOL unterstützt⁠(wird in einem neuen Fenster geöffnet) mehr als 40 % der Onlinebanking-Systeme, 80 % der Kreditkartentransaktionen vor Ort und 95 % der Transaktionen an Geldautomaten. Fortran wird dagegen für Wettervorhersagen⁠(wird in einem neuen Fenster geöffnet) und Sicherheitsanalysen von Kernreaktoren⁠(wird in einem neuen Fenster geöffnet) eingesetzt. Wenn KI besser mit diesen Sprachen umgehen kann, könnte das Teams dabei helfen, die Software zu warten und zu modernisieren, auf die unverzichtbare Dienste angewiesen sind.

Diese Arbeit orientiert sich an Rückmeldungen von Entwickler:innen und unseren Unternehmenskunden: Sie berichten, dass Programmiermodelle mit diesen Sprachen oft Schwierigkeiten haben. Diese Software zu warten und zu modernisieren, kann schwierig sein: Die Dokumentation ist möglicherweise unvollständig, die ursprünglichen Entwickler:innen haben das Unternehmen vielleicht verlassen und wichtige Geschäftsregeln sind womöglich nur im Code festgehalten. Ob Teams Fehler beheben oder zu einer anderen Sprache migrieren: Sie müssen das Verhalten bewahren, auf das ihre Systeme angewiesen sind.

Um Fortschritte zu messen, haben wir zwei Evaluationen entwickelt. MultiLangBench prüft in 20 verschiedenen Programmiersprachen, ob ein Modell eine SQLite-kompatible Datenbank-Engine von Grund auf entwickeln kann. Unsere Evaluation zur COBOL-Migration prüft, ob ein Modell bestehende Programme in eine andere Sprache übertragen kann, ohne ihr Verhalten zu verändern. Zusammen prüfen sie zwei sich ergänzende Fähigkeiten: neue Software zu entwickeln und die Funktionsweise bestehender Software zu bewahren.

Unsere neuesten Modelle zeigen in beiden Evaluationen deutliche Verbesserungen und erzielen eine wesentlich höhere Genauigkeit bei geringeren Kosten.

Bei MultiLangBench erreicht GPT‑6 Astra über 20 Programmiersprachen hinweg einen durchschnittlichen Anteil bestandener Tests von 87,4 %, gegenüber 26,8 % bei GPT‑5.6 Sol. In jeder getesteten Sprache gibt es Verbesserungen. Auch GPT‑6 Luna übertrifft GPT‑5.6 Sol und erreicht 40,3 % bei geschätzt rund 78 % niedrigeren API-Kosten.

In unserer Evaluation zur COBOL-Migration erreicht GPT‑6.1 Sol bei niedrigem Reasoning-Aufwand eine Genauigkeit von 86,6 %, verglichen mit nur 5,4 % bei GPT‑5.6 Sol. Zugleich sind die Kosten um 39 % niedriger. Bei höherem Reasoning-Aufwand erreicht die Genauigkeit 97,9 %. Damit ist das maximal mögliche Ergebnis der Evaluation nahezu erreicht.

Insgesamt zeigen diese Ergebnisse, dass unsere Modelle deutlich besser mit einer Vielzahl von Programmiersprachen umgehen können und dabei kosteneffizienter werden.

1. SQLite von Grund auf entwickeln (MultiLangBench)

MultiLangBench gibt einem Modell die Aufgabe, eine SQLite-kompatible Datenbank-Engine in einer vorgegebenen Programmiersprache zu entwickeln. Das Modell muss eine Codebasis organisieren, Zustände verwalten, Fehler behandeln und neue Funktionen hinzufügen, ohne bestehende Funktionen zu beeinträchtigen.

Um Implementierungen in verschiedenen Sprachen zu vergleichen, nutzen wir Datenbankdateien als gemeinsame Schnittstelle. Das zu prüfende Programm erhält eine Ausgangsdatenbank und eine SQL-Abfrage und erzeugt daraus eine veränderte Datenbank. Mithilfe der SQLite-Referenzimplementierung prüfen wir, ob die entstandene Datenbank die erwarteten Inhalte aufweist. So können wir dieselben Tests anwenden, unabhängig davon, in welcher Sprache die Engine entwickelt wurde.

Wir haben Tests aus der bestehenden SQLite-Testsuite an dieses Format angepasst. Die Evaluation misst, wie viel funktionierende Software ein Modell während einer längeren Programmiersitzung entwickeln kann. Sie erfasst sowohl den Anteil bestandener Tests als auch die API-Kosten.

Bei maximalem Reasoning-Aufwand erreicht GPT‑6 Astra über die 20 Sprachen hinweg einen durchschnittlichen Anteil bestandener Tests von 87,4 %, gegenüber 26,8 % bei GPT‑5.6 Sol. Die Verbesserungen betreffen jede getestete Sprache, darunter COBOL (von 10,9 % auf 72,1 %), OCaml (von 25,6 % auf 85,8 %), Fortran (von 21,4 % auf 83,5 %) und Visual Basic (von 27,5 % auf 89,4 %). Astra erzielt in 19 der 20 Sprachen mehr als 83 %. COBOL bleibt mit 72 % die schwierigste Sprache.

GPT‑6 Luna bietet eine kostengünstigere Option, die GPT‑5.6 Sol ebenfalls in jeder getesteten Sprache übertrifft. Bei maximalem Reasoning-Aufwand erreicht es einen durchschnittlichen Anteil bestandener Tests von 40,3 %. Verbesserungen gibt es unter anderem bei COBOL (von 10,9 % auf 17,1 %), OCaml (von 25,6 % auf 34,1 %), Fortran (von 21,4 % auf 31,4 %) und Visual Basic (von 27,5 % auf 41,6 %). Diese Verbesserungen werden bei geschätzten durchschnittlichen API-Kosten von 0,77 USD pro Versuch erzielt, verglichen mit 3,48 USD bei GPT‑5.6 Sol. Das entspricht einer Senkung um rund 78 %.

Wir veröffentlichen den Evaluationsaufbau und die Testsuite von MultiLangBench zusammen mit den Ergebnissen für jede Sprache auf GitHub⁠(wird in einem neuen Fenster geöffnet). Entwickler:innen können einsehen, was die Evaluation prüft, die Leistung in den von ihnen genutzten Sprachen bewerten und Lücken erkennen, die für ihre eigene Arbeit relevant sind.

2. Eine COBOL-Codebasis migrieren

In unserer zweiten Evaluation sollen Modelle COBOL-Programme nach C++, Java, Kotlin, Python oder Rust migrieren, ohne die Funktionsweise der Programme zu verändern.

Eine erfolgreiche Migration erfordert ein Verständnis sowohl der Geschäftslogik des Programms als auch des spezifischen Sprachverhaltens von COBOL. COBOL-Programme verarbeiten häufig Finanztransaktionen und Geschäftsdaten. Dabei spiegeln Details wie Rundungsregeln und der Umgang mit fehlenden Datensätzen die geschäftlichen Anforderungen wider. Beispielsweise schneidet die Festkommaarithmetik von COBOL überzählige Nachkommastellen ab, sofern nicht ausdrücklich gerundet werden soll. Eine Neuimplementierung, die diese Werte stattdessen rundet, kann fehlerfrei laufen und dennoch zu anderen finanziellen Ergebnissen führen.

Um zu prüfen, ob dieses Verhalten erhalten bleibt, evaluieren wir unsere Modelle mit verborgenen Tests. Diese verlangen eine bytegenaue Übereinstimmung der beobachtbaren Ausgaben. Eine Migration gilt nur dann als erfolgreich, wenn alle Tests bestanden werden. Solche Fähigkeiten, das bestehende Verhalten zu bewahren, sind für Teams nützlich, die ältere Systeme warten und modernisieren. Bei Software im Produktivbetrieb sind jedoch weiterhin eine fachkundige Prüfung und Tests anhand der Geschäftsregeln und Abhängigkeiten des Systems erforderlich.

In dieser Evaluation erreicht GPT‑6.1 Sol bei niedrigem Reasoning-Aufwand eine Genauigkeit von 86,6 %, gegenüber 5,4 % bei GPT‑5.6 Sol mit derselben Einstellung. Dabei fallen nur 61 % der API-Kosten an. Bei höherem Reasoning-Aufwand erreicht die Genauigkeit 97,9 %. Damit ist das maximal mögliche Ergebnis der Evaluation nahezu erreicht. Diese Evaluationsergebnisse zeigen Fortschritte hin zu einer genaueren und kostengünstigeren Code-Migration für Teams, die geschäftskritische Software modernisieren.

Fähigkeiten für Unternehmenssoftware weiterentwickeln

Diese Evaluationen und direkte Rückmeldungen von Entwickler:innen sowie von unseren Unternehmenskunden helfen uns zu erkennen, wo unsere Modelle besser werden und wo sie noch Schwächen haben.

Unser Ziel ist, dass Modelle ihre Fähigkeiten in der Softwareentwicklung auf mehr Sprachen anwenden können: unbekannte Repositorys verstehen, Änderungen planen, Build-Werkzeuge nutzen, Tests ausführen und Fehler beheben.

Du kannst unsere neuesten Modelle über die API für Programmieraufgaben in den Sprachen ausprobieren, die dein Team nutzt. Dein Feedback hilft uns, das Training und die Evaluation unserer Modelle zu gestalten: Was funktioniert, wo haben die Modelle Schwierigkeiten und auf welche Sprachen oder Arbeitsabläufe sollten wir uns als Nächstes konzentrieren? So können wir die Software, auf die du angewiesen bist, besser unterstützen.