WO2025256865A1

WO2025256865A1 - Verfahren zum trainieren eines large language models bezüglich der erzeugung von programmcode

Info

Publication number: WO2025256865A1
Application number: PCT/EP2025/063576
Authority: WO
Inventors: Aaron Haag; Oliver Lohse
Original assignee: Siemens AG; Siemens Corp
Current assignee: Siemens AG; Siemens Corp
Priority date: 2024-06-14
Filing date: 2025-05-16
Publication date: 2025-12-18
Anticipated expiration: 2026-12-14

Abstract

Es wird ein Verfahren zum Trainieren eines Large Language Models bezüglich der Erzeugung von Programmcode zu einer Programmiersprache, bei dem wenigstens eine Programmieraufgabe erzeugt wird, die Programmieraufgabe n-mal an das Large Language Model übermittelt wird und eine Anzahl von n Lösungen von dem Large Language Model empfangen wird, wobei n > 1, eine Qualitätsreihenfolge für die Lösungen ermittelt wird, ein Compiler für die Programmiersprache verwendet wird, um die Qualitätsreihenfolge zu bestimmen, mit den Programmieraufgaben, den Lösungen und der zugeordneten Qualitätsreihenfolge eine Feinabstimmung des Large Language Model mit einem Verfahren gemäß der Direct Preference Optimization durchgeführt wird.

Description

Beschreibung

Verfahren zum Trainieren eines Large Language Models bezüglich der Erzeugung von Programmcode

Die Erfindung betrifft ein Verfahren zum Trainieren eines großen Sprachmodells (engl. Large Language Model) bezüglich der Erzeugung von Programmcode zu einer Programmiersprache sowie ein solches Sprachmodell.

Ein großes Sprachmodell, englisch Large Language Model, LLM, ist ein sehr umfangreiches neuronales Netzwerk, das sich durch seine Fähigkeit auszeichnet, Sprache für allgemeine Zwecke zu verstehen und zu generieren. LLMs erwerben diese Fähigkeiten durch das Erlernen statistischer Beziehungen aus sehr großen Mengen von Textdokumenten während eines rechenintensiven selbstüberwachten und halbüberwachten Trainingsprozesses. LLMs sind sogenannte neuronale Netze, die einer Transformatorarchitektur folgen.

Als autoregressive Sprachmodelle arbeiten sie, indem sie einen Eingabetext verwenden, und wiederholt das nächste Token oder Wort Vorhersagen. Bis 2020 war ein sogenannter Fine- Tuning-Prozess die einzige Möglichkeit, ein Modell so anzupassen, dass es bestimmte Aufgaben erfüllen konnte. Größere Modelle, können mit Hilfe von sogenanntem Prompt- Engineering ähnliche Ergebnisse erzielen. Man geht davon aus, dass sie sich Wissen über Syntax, Semantik und Ontologie aneignen, dass in menschlichen Sprachkorpora enthalten ist, aber auch Ungenauigkeiten und Verzerrungen, die in den Korpora vorhanden sind.

Bemerkenswerte Beispiele sind die GPT-Modelle von OpenAI (GPT, Generative Pretrained Transformer) z. B. GPT-3.5 und GPT-4, die in ChatGPT verwendet werden), PaLM von Google (verwendet in Bard) und LLaMA von Meta sowie BLOOM, Ernie 3.0 Titan und Claude 2 von Anthropic.

Die jüngsten Entwicklungen bei Large Language Models führen dazu, dass sie nicht nur in der Analyse von natürlicher Sprache verwendet werden, sondern weitere Einsatzbereiche erschlossen werden sollen. Beispielsweise gibt es ein großes Interesse an der Erforschung ihres potenziellen Einsatzes im industriellen Bereich.

Ein möglicher Einsatzbereich ist die Erzeugung von Programmcode aus einer Anfrage in natürlicher Sprache. Es ist bekannt, dass LLMs auf Basis von Texteingaben in un strukturierter Form oder natürlicher Sprache funktionierenden Programmcode (Codeartefakte) in vielerlei Programmiersprachen erzeugen können, beispielsweise Python oder Java, aber auch beispielsweise github „Actions“ (Generierung von Programmcode auf Basis von textueller Code- Intention).

Die Grundlage dafür stellt wie bei anderen Fähigkeiten der LLMs das Training dar. LLMs sind in der Regel auf großen Datensätzen aus frei verfügbaren Ressourcen (z.B. Websites) trainiert und sind in der Lage, die darin vorhandenen Informationen wiederzugeben und zu kombinieren, unter Berücksichtigung der textuellen Programmieraufgabe (Code-Intention). Je besser eine Programmiersprache in den verfügbaren und genutzten Ressourcen abgebildet ist, beispielsweise in Form von Programmen und Dokumentation, desto besser passt der generierte Programmcode zu der Intention der Texteingabe, also der Programmieraufgabe (hohe Generierungsqualität).

Es gibt Programmiersprachen, für die die Trainingsdaten aus dem Internet nur geringen Umfang haben. Dazu gehören beispielsweise die im industriellen Umfeld der SPS (Speicherprogrammierbare Steuerung) Programmierung genutzten Sprachen aus EN 61131-3 zu (z.B. „strukturierter Text“). Noch mehr trifft das auf proprietäre Dialekte (z.B. SCL - structured control language, Siemens) zu. Für diese Programmiersprachen ist die Generierungsqualität daher schlecht, was sich in Kompilierungsfehlern (falsche Syntax) und/oder fehlerhafter Funktion (keine funktionale Richtigkeit/Semantik) aufzeigt.

Das manuelle Erzeugen von Trainingsressourcen, also Paaren aus textueller Programmieraufgabe und dazugehörigem Programmcode) ist zeitaufwändig, und häufig nur in sehr geringem Umfang möglich. Manuell erzeugte Trainingsressourcen sind daher oft nicht ausreichend, um ein LLM zu trainieren.

Selbst wenn Trainingsressourcen vorliegen (z.B. Kundendaten), das heißt, Paare aus textuellen Code -Intentionen und dazugehörigem Programmcode, kann Letzteres nicht zum Trainieren von LLMs genutzt werden, da er häufig kundenspezifische Besonderheiten enthält, und Charakteristika aufweist, die in der späteren Nutzung Rückschlüsse auf den Kunden zulassen würden. Ohne den entsprechenden Programmcode kann ein Netz allerdings durch gängige Supervised-Methoden nicht angelernt werden.

Die Verwendung von nicht-öffentlichen Daten (Programmcode und Intention) für das Training ist nicht unter allen Umständen überhaupt möglich. Selbst wenn sie verwendet werden könnten, besteht die Gefahr, dass Charakteristika dieser nicht-öffentlichen Daten in der späteren Nutzung Rückschlüsse auf die Herkunft zulassen würden.

Es ist Aufgabe der Erfindung, ein Verfahren zum Trainieren eines Large Language Models bezüglich der Erzeugung von Programmcode zu einer Programmiersprache anzugeben, mit dem speziell für Programmiersprachen mit geringem Umfang von verfügbaren Trainingsdaten eine Verbesserung der Generierungsqualität erreichbar wird. Eine weitere Aufgabe besteht darin, ein entsprechend trainiertes LLM anzugeben.

Diese Aufgabe wird durch ein Verfahren mit den in Anspruch 1 angegebenen Merkmalen gelöst. Hinsichtlich des LLM besteht eine Lösung in einem LLM mit den Merkmalen von Anspruch 11.

Bei dem erfindungsgemäßen Verfahren zum Trainieren eines Large Language Models bezüglich der Erzeugung von Programmcode zu einer Programmiersprache wird wenigstens eine Programmieraufgabe erzeugt. Diese wird n-mal an das Large Language Model übermittelt. Eine entsprechende Anzahl von n Lösungen werden von dem Large Language Model empfangen. Das Übermitteln und Empfangen passiert mehrfach, also n > 1.

Für die Lösungen wird eine Qualitätsreihenfolge für die Lösungen ermittelt. Dabei wird ein Compiler für die Programmiersprache verwendet, um die Qualitätsreihenfolge zu bestimmen. Die Qualitätsreihenfolge besteht beispielsweise in einer Sortierung der Lösungen oder erlaubt eine solche Sortierung.

Schließlich wird mit den Programmieraufgaben, den Lösungen und der Qualitätsreihenfolge eine Feinabstimmung des Large Language Model mit einem Verfahren gemäß der Direct Preference Optimization durchgeführt.

Das erfindungsgemäße Large Language Model umfasst ein neuronales Netzwerk mit wenigstens 100 Millionen Parametern, trainiert mit dem erfindungsgemäßen Verfahren.

Es versteht sich, dass das LLM, das die Programmieraufgaben übermittelt bekommt, mittels seines neuronalen Netzwerks und seines bis dahin vorliegenden Trainings eine Lösung erzeugt und diese zurück übermittelt. Da das LLM möglicherweise eine externe Ressource im Internet darstellt, ist das Ermitteln der Lösung aber nicht zwingend Teil des erfindungsgemäßen Verfahrens. Vorteilhaft ermöglicht es die Erfindung, ein Training eines LLMs für eine Programmiersprache vorzunehmen, für die keine oder nur wenige Trainingsdaten verfügbar sind. Dabei müssen keine Trainingsdaten manuell erstellt werden oder gar nicht-öffentliche Trainingsdaten verwendet werden. Vielmehr wird jede der Programmieraufgaben mehrfach an das LLM übermittelt und jeweils eine Lösung vom LLM empfangen. Bekanntermaßen unterscheiden sich die so erstellten Lösungen voneinander, auch wenn der Prompt, also die Programmieraufgabe dieselbe bleibt.

Die so erhaltene Liste von Lösungen wird von einem Compiler für die Programmiersprache bewertet. Anhand der Rückmeldung des Compilers wird die Qualitätsreihenfolge bestimmt, anhand derer die Lösungen relativ zueinander sortiert sind oder werden können. Die Methode der DPO (Direct Preference Optimization) erlaubt es dann, das LLM basierend auf diesen Lösungen und ihrer Qualitätsreihenfolge zu trainieren. Es handelt sich bei diesem Training um eine Feinabstimmung (fine tuning), da ein Basistraining des LLM bereits vorliegen muss.

Vorteilhaft an dem erfindungsgemäßen Vorgehen ist weiterhin, dass es wenig oder gar keine menschlichen Eingriffe erfordert. Das Verfahren ist skalierbar, ohne dabei gleichzeitig den Einsatz menschlicher Ressourcen mit zu skalieren. Beispielsweise kann die Anzahl der Lösungen für eine Programmieraufgabe (= n) gesteigert werden, ohne dass sich der Anteil menschlicher Arbeit verändert.

Die Methode der DPO ist aus https://doi.org/10.48550/arXiv.2305.18290 bekannt.

Es versteht sich, dass die Programmieraufgabe (Code intention, Zweck) eine Anfrage in natürlicher Sprache ist, wie sie üblicherweise als Prompt für LLMs verwendet wird.

Vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens und des erfindungsgemäßen LLMs gehen aus den abhängigen Ansprüchen hervor. Dabei kann die Ausführungsform der unabhängigen Ansprüche mit den Merkmalen eines der Unteransprüche oder vorzugsweise auch mit denen aus mehreren Unteransprüchen kombiniert werden. Demgemäß können noch zusätzlich folgende Merkmale vorgesehen werden:

Bevorzugt wird ein n >= 10 verwendet. Es wird also jede Programmieraufgabe 10 oder mehr mal an das LLM übermittelt und eine entsprechende Anzahl von Lösungen empfangen. In anderen Ausgestaltungen kann auch eine höhere Anzahl von n >= 20 oder n >= 50 verwendet werden. Eine höhere Anzahl von Lösungen verbreitert die erreichte Qualitätsspanne und erhöht die Chance, kompilierbare Lösungen zu erzeugen. Dadurch wird die erreichte Feinabstimmung durch DPO verbessert.

In einer bevorzugten Ausgestaltung der Erfindung werden zur Ermittlung der Qualitätsreihenfolge für eine Lösung ein oder mehrere der folgenden Ergebnisse eines Kompiliervorgangs durch den Compiler verwendet:

- Kompilierbarkeit,

- Anzahl der Kompilier-Fehler, die eine erfolgreiche Kompilierung verhindern,

- Anzahl von Kompilier-Warnungen, die eine erfolgreiche Kompilierung nicht verhindern, aber ein Defizit des Programmcodes anzeigen,

- Schwere von Kompilier-Fehlern und/oder Kompilier-Warnungen.

Durch die Verwendung dieser Kriterien wird erreicht, dass die Qualitätsreihenfolge nicht nur auf einem binären Wert basiert im Sinne von kompiliert/nicht kompiliert, sondern ein größeres Wertespektrum bereitsteht, sowohl bei kompilierbaren als auch bei nicht kompilierbaren Lösungen. Bei der Kompilierbarkeit selbst handelt es sich um ein binäres Ergebnis. Die Anzahl der Kompilierfehler und die Anzahl der Kompilierwarnungen sind natürliche Zahlen, die für die Ermittlung der Qualitätsreihenfolge kombiniert werden können.

Besonders vorteilhaft ist es, die Schwere von Fehlern und Warnungen zu berücksichtigen. Beispielsweise kann einem fehlenden Import ein geringer Qualitätsmalus zugeordnet werden, da dieser in einer realen Umgebung von einer Entwicklungsumgebung automatisch korrigiert werden könnte. Einer falschen Syntax dagegen kann ein höherer Qualitätsmalus gegeben werden.

In einer vorteilhaften Ausgestaltung und Weiterbildung der Erfindung wird für eine Programmieraufgabe eine zweite Lösung in einer zweiten Programmiersprache erzeugt und die Qualitätsreihenfolge unter Verwendung eines Vergleichs einer Funktionalität der Lösung mit derselben Funktionalität der zweiten Lösung bestimmt.

Die zweite Lösung kann dabei durch dasselbe LLM erzeugt werden, das für die (erste) Programmiersprache trainiert wird. Alternativ kann auch ein anderes LLM verwendet werden. Dabei wird die Programmieraufgabe an das dafür vorgesehene LLM übermittelt und die Lösung empfangen. Als zweite Programmiersprache beispielsweise Python, Java, C# oder eine andere bekannte Programmiersprache verwendet werden, für die das jeweilige LLM wohltrainiert ist, wofür also eine große Menge an Trainingsdaten vorhanden ist. Alternativ kann auch eine zweite Programmiersprache verwendet werden, die der zu trainierenden Programmiersprache ähnelt oder im Zweck nahekommt. Ist die Programmiersprache aus dem Bereich der SPS, dann könnte also als zweite Programmiersprache eine andere Programmiersprache aus dem Bereich der SPS verwendet werden.

Es ist zweckmäßig, eine entsprechende Angabe in der Programmieraufgabe an die zweite Programmiersprache anzupassen, um die richtige Lösung zu bekommen, beispielsweise „Erzeuge ein Programm für (...) in der Programmiersprache Python“.

Die Funktionalität kann eine Ausgabe des Programms, also der Lösung, sein oder eine andere Reaktion auf einen Eingabeparameter, beispielsweise ein Fehler (Exception). Der Vergleich der Funktionalität kann mit einem einfachen Test erfolgen, bei dem eine Ausgabe oder anderes Ergebnis auf die jeweils nötigen Eingabeparameter verglichen wird.

Vorteilhaft wird dadurch erreicht, dass die Qualitätsreihenfolge nicht nur das Kompilationsergebnis, sondern auch die Funktion des Programms abbildet. Während die Qualitätsreihenfolge bezüglich nicht kompilierbarer Programme vor allem durch den Compiler bestimmt werden kann, liefert dieser wenige Informationen bezüglich fehlerfrei kompilierbarer Programme. Genau dort liefert ein Vergleich mit dem Programm in der zweiten Programmiersprache deutlich bessere Informationen, erlaubt also eine bessere Gestaltung der Qualitätsreihenfolge.

Vorteilhaft erfolgt der Vergleich mittels eines Programms nach Art eines Unit Tests. Der Unit Test kann ebenfalls durch das für die zweite Programmiersprache verwendete LLM erzeugt werden. Ein Unit Test kann ausgestaltet sein, mehrere Funktionalitäten zu prüfen. Dazu kann der Unit Test beispielsweise automatisiert eine Mehrzahl verschiedener Eingabeparameter verwenden und sowohl den korrekten Ablauf als auch Fehlerszenarien simulieren.

Insgesamt wird so erreicht, dass alle Lösungen für die Programmiersprache von einem völlig korrekten Programm bis hin zu einem völlig unpassenden und nicht kompilierbaren Programm in eine passende Qualitätsreihenfolge gebracht werden können, obwohl das LLM zumindest anfänglich schlecht oder gar nicht für die Programmiersprache trainiert ist. In einer weiteren vorteilhaften Ausgestaltung und Weiterbildung der Erfindung wird eine Lösung in der Programmiersprache dem LLM oder einem zweiten LLM zusammen mit einer Anfrage zur Bewertung der Lösung. Weiterhin wird ein Ergebnis von dem jeweiligen LLM empfangen. Die Qualitätsreihenfolge wird unter Verwendung des Ergebnisses bestimmt. Die Anfrage enthält zweckmäßig eine Instruktion in natürlicher Sprache zur Bewertung der Lösung, beispielsweise hinsichtlich semantischer Richtigkeit und Qualität. Hierbei wird vorteilhaft genutzt, dass ein LLM in der Lage ist, eine Lösung auch dann zu bewerten, wenn es die Programmiersprache an sich nicht „beherrscht“, also selbst nur eine geringe Generierungsqualität bezüglich der Programmiersprache hätte. Das Ergebnis der Anfrage fließt dann in die Qualitätsreihenfolge ein. Anstelle der einzelnen Lösung kann auch ein Lösungsvektor mit allen Lösungen zu einer Programmieraufgabe an das LLM übermittelt werden mit einer Anfrage zur Rückgabe einer Qualitätssortierung. Diese Rückgabe kann dann zur Bestimmung der endgültigen Qualitätsreihenfolge verwendet werden.

Hierzu kann die Anfrage so formuliert sein, dass das Ergebnis leicht in einen numerischen Wert umzusetzen ist. Alternativ kann eine Auswertung des Ergebnisses beispielsweise durch eine Suche nach Schlüssel-Worten vorgenommen werden. Auch ein Verfahren des NLP (Natural Language Processing) mit einer Kl (künstlichen Intelligenz), die gegenüber einem LLM klein ist, kann hierzu verwendet werden.

Es ist zweckmäßig, eine Mehrzahl m von voneinander verschiedenen Programmieraufgaben zu verwenden. Dadurch wird zusammen mit der n-fachen Umsetzung der Programmieraufgabe ein Datensatz der Größe G = n ■ m erzeugt, der für die Feinabstimmung mittels DPO bereitsteht.

Es können beispielsweise wenigstens 10, insbesondere wenigstens 20 voneinander verschiedene Programmieraufgaben verwendet werden.

In einer Weiterbildung der Erfindung wird das Verfahren mehrfach wiederholt. Speziell die Schritte: Übermitteln der Programmieraufgabe an das Large Language Model und Empfang der Lösung, Ermittlung einer Qualitätsreihenfolge für die Lösungen, Feinabstimmung des Large Language Model mit einem Verfahren gemäß der Direct Preference Optimization werden mehrfach wiederholt. Die Programmieraufgaben können in jeder Iteration erneut verwendet werden und müssen nur einmalig bereitgestellt werden. Dadurch wird das Training des LLM deutlich verbessert und es ergibt sich ein deutlich besseres Ergebnis der Feinabstimmung, als es mit nur einem Durchlauf des Verfahrens möglich wäre. Vorteilhaft ist es, wenn die Programmieraufgaben automatisiert erzeugt werden. Beispielsweise können mittels eines LLM (das trainierte LLM oder ein anderes LLM) aus einer einzelnen Basis- Programmieraufgabe durch einen Prompt weitere Programmieraufgaben erzeugt werden. Dadurch kann mit nur geringem Aufwand eine große Menge an Trainingsdaten für das DPO- Verfahren erzeugt werden.

Im Folgenden wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläutert. Es zeigen:

Figur 1 ein Verfahren zur Erzeugung von Programmieraufgaben,

Figur 2 ein Verfahren zur Erzeugung und Sortierung einer Matrix von Lösungen zu den

Programmieraufgaben, die von einem LLM generiert werden,

Figur 3 ein Verfahren zur Ermittlung der Sortierreihenfolge für die Lösungen,

Figur 4 ein Verfahren zur Feinabstimmung des LLM anhand der Lösungen und der

Sortierreihenfolge.

Die im Folgenden beschriebenen Verfahren bilden ein Ausführungsbeispiel für die Erfindung. Sie dienen insgesamt dazu, eine Feinabstimmung eines LLM 100 vorzunehmen. Die Feinabstimmung soll das LLM 100 befähigen, Programme oder Programmteile für eine Programmiersprache zu erzeugen, die es aus dem Training mit verfügbaren Inhalten nicht oder nicht ausreichend beherrscht.

Mit dem schematisch dargestellten Verfahren gemäß Figur 1 wird aus einer Vorgabemenge von ersten Programmieraufgaben 10, auch als Code Intents oder Intentions bezeichnet eine Ergebnismenge von zweiten Programmieraufgaben P erzeugt. Die Vorgabemenge 10 ist beispielsweise menschlich erzeugt oder liegt aus frei verfügbaren Trainingsdaten für andere Programmiersprachen vor. Die Vorgabemenge wird einem geeigneten Prompt einem LLM, beispielsweise dem zu trainierenden LLM 100 oder einem zweiten LLM 200 übermittelt. Als Ergebnis wird von dem jeweiligen LLM 100, 200 die Menge von m zweiten Programmieraufgaben P empfangen.

Mit den zweiten Programmieraufgaben P wird das Verfahren gemäß Figur 2 durchgeführt. In einem ersten Schritt wird anfänglich die erste Programmieraufgabe Pi der Programmieraufgaben P, bei weiteren Iterationen die nächstfolgende Programmieraufgabe Pj der Programmieraufgaben P ausgewählt mit i = 1 ... m.

In einem zweiten Schritt wird diese Programmieraufgabe Pj an das LLM 100 übermittelt. In einem Schritt wird eine Lösung Lik für die Programmieraufgabe Pj als Antwort von dem LLM 100 empfangen. Der zweite Schritt und der dritte Schritt werden zusammen n mal wiederholt, so dass k = 1 ... n.

Nach der Aufnahme der Lösungen Lik für die gegenwärtige Programmieraufgabe Pi wird zum ersten Schritt zurückgekehrt, solange noch weitere Programmieraufgaben Pi vorhanden sind. Es entsteht somit eine Matrix von n ■ m Lösungen Lik.

In einem vierten Schritt 24 werden die Lösungen Lik separat für jedes i sortiert und dadurch in eine Reihenfolge gebracht. Es ergibt sich also für die Lösungen Lik der ersten Programmieraufgabe Pi ein sortierter Lösungsvektor Li. Für die Lösungen L2k der zweiten Programmieraufgabe P2 ergibt sich ein sortierter Lösungsvektor L2 usw. Es findet also ein Vergleich der Lösungen zu einer jeweiligen Programmieraufgabe Pi statt, ein Vergleich zwischen Lösungen Lik zu unterschiedlichen Programmieraufgabe Pi / Pj dagegen ist unnötig.

Die Reihenfolge im jeweiligen Lösungsvektor Li gibt dabei die Qualität der Lösungen Lik an. Es versteht sich, dass diese Sortierung in der tatsächlichen computerimplementierten Umsetzung verschiedenartig realisiert werden kann. Sie kann beispielsweise durch eine tatsächliche Sortierung im Speicher eines ausführenden PCs umgesetzt sein oder aber durch Zuordnung einer Qualitätszahl zu den Lösungen Lik, die die Reihenfolge festlegt oder eines Index, der die Reihenfolge festlegt. Mit „sortiert“ ist daher nicht notwendigerweise eine tatsächliche Sortierung gemeint, sondern es ist auch die Möglichkeit der Sortierung zu einem späteren Zeitpunkt umfasst.

Figur 3 zeigt genauer, wie die Reihenfolge ermittelt wird. Dabei wird von einer Programmieraufgabe Pi und den zugehörigen Lösungen Li = Lu, L2 ... Lj_n ausgegangen, für die noch keine Reihenfolge ermittelt ist.

Der gesamte Lösungsvektor wird in einem ersten Schritt einem LLM 100, 200 zugeführt mit einer Anfrage, eine Reihenfolge der Lösungen festzulegen nach Qualität der Lösung und semantischer Richtigkeit. In einem zweiten Schritt wird ein Ergebnis 32 von dem LLM 100, 200 empfangen. Hier kann das zu trainierende LLM 100 oder ein anderes LLM 200 eingebunden werden.

Weiterhin wird jede Lösung Lik in einem weiteren Schritt einem Compiler 300 für die zu trainierende Programmiersprache zugeführt. Das Ergebnis der Arbeit des Compilers 300 ist einerseits eine Liste 33 von Fehlern und/oder Warnungen.

Andererseits erzeugt der Compiler 300, sofern möglich, einen lauffähigen Code Cik, der für eine weitere Prüfung verwendet wird. Hierzu wird die Programmieraufgabe Pj einem LLM 100, 200 zugeführt, wobei hier die Aufgabe dahingehend umformuliert oder ergänzt wird, dass die Lösung die Programmiersprache Python verwenden soll. Als Ergebnis wird von dem LLM 100, 200 ein Python-Programm Py empfangen, das die Programmieraufgabe Pj löst.

Zwischen den Lösungen Py und Cik wird ein Funktionsvergleich 31 durchgeführt. Der Funktionsvergleich kann in einfachen Ausführungen nur den Aufruf des Programmfragments mit einem Satz von Eingangsparametern und ein Vergleich des Ergebnisses sein. In komplexeren Ausführungen kann auch ein Test mit verschiedenen Sätzen von Eingangsparametern durchgeführt werden.

Die Ergebnisse des Funktionsvergleichs 31, die Resultate 33 des Kompiliervorgangs und das Ergebnis 32 zur Einschätzung der Qualität werden zusammen verwendet, um die endgültige Reihenfolge 35 der Lösungen Lik festzulegen.

Insgesamt wird für die Feinabstimmung des LLM 100 ein Verfahren durchgeführt, das in Figur 4 schematisch dargestellt ist. Dabei werden die Programmieraufgaben Pi..._m bereitgestellt, die Lösungen Lik empfangen und eine Reihenfolge ermittelt, wie bereits im Zusammenhang mit den Figuren 1 bis 3 beschrieben. In der Folge wird unter Verwendung der m sortierten Lösungsvektoren Li eine Feinabstimmung gemäß der Direct Preference Optimization 40 für das LLM 100 durchgeführt.

Danach wird das Verfahren ein oder mehrmals wiederholt. Dabei werden dieselben Programmieraufgaben Pi..._m wiederum verwendet und an das nun bereits durch die erste Feinabstimmung besser trainierte LLM 100 übermittelt. Es werden dann neue Lösungen Lik2 empfangen und für diese wiederum eine Reihenfolge ermittelt, um dann schließlich damit wiederum eine Direct Preference Optimization 40 für das LLM 100 durchgeführt. Auf diese Weise wird das LLM 100 iterativ verbessert. Bezugszeichen

10 Vorgabemenge von Programmieraufgaben

24 vierter Schritt 31 Funktionsvergleich zwischen Lösung und Lösung in Python

32 Qualitätsbewertung durch LLM

33 Fehler und Warnungen des Compilers

100 zu trainierendes LLM

200 weiteres LLM 300 Compiler für die zu trainierende Programmiersprache

Pi...m Programmieraufgaben

Lik Lösungen zu den Programmieraufgaben

Cik Kompilierter Code für die Lösung Lik

Py Lösung für eine Programmieraufgabe in Python

Claims

Patentansprüche

1. Verfahren zum Trainieren eines Large Language Models bezüglich der Erzeugung von Programmcode zu einer Programmiersprache, bei dem

- wenigstens eine Programmieraufgabe erzeugt wird,

- die Programmieraufgabe n-mal an das Large Language Model übermittelt wird und eine Anzahl von n Lösungen von dem Large Language Model empfangen wird, wobei n > 1,

- eine Qualitätsreihenfolge für die Lösungen ermittelt wird,

- ein Compiler für die Programmiersprache verwendet wird, um die Qualitätsreihenfolge zu bestimmen,

- mit den Programmieraufgaben, den Lösungen und der zugeordneten Qualitätsreihenfolge eine Feinabstimmung des Large Language Model mit einem Verfahren gemäß der Direct Preference Optimization durchgeführt wird.

2. Verfahren nach Anspruch 1, bei dem ein n >= 10 verwendet wird.

3. Verfahren nach Anspruch 1 oder 2, bei dem zur Ermittlung der Qualitätsreihenfolge ein oder mehrere der folgenden Ergebnisse eines Kompiliervorgangs durch den Compiler verwendet werden:

- Kompilierbarkeit,

- Anzahl der Kompilier-Fehler, die eine erfolgreiche Kompilierung verhindern,

- Schwere von Kompilier-Fehlern und/oder Kompilier-Warnungen.

4. Verfahren nach einem der vorangehenden Ansprüche, bei dem

- für eine Programmieraufgabe eine zweite Lösung in einer zweiten Programmiersprache erzeugt wird,

- die Qualitätsreihenfolge unter Verwendung eines Vergleichs einer Funktionalität der Lösung mit derselben Funktionalität der zweiten Lösung bestimmt wird.

5. Verfahren nach Anspruch 4, bei dem als zweite Programmiersprache Python verwendet wird.

6. Verfahren nach einem der vorangehenden Ansprüche, bei dem

- eine Lösung dem Large Language Model oder einem zweiten Large Language Model übermittelt wird zusammen mit einer Anfrage zur Bewertung der Lösung, - ein Ergebnis empfangen wird, und

- die Qualitätsreihenfolge unter Verwendung des Ergebnisses bestimmt wird.

7. Verfahren nach einem der Ansprüche 1 bis 5, bei dem

- ein Lösungsvektor aus den Lösungen zu einer Programmieraufgabe dem Large Language Model oder einem zweiten Large Language Model übermittelt wird zusammen mit einer Anfrage zur Bereitstellung einer Qualitätssortierung der Lösungen,

- ein Ergebnis empfangen wird, und

- die Qualitätsreihenfolge unter Verwendung des Ergebnisses bestimmt wird.

8. Verfahren nach einem der vorangehenden Ansprüche, bei dem eine Mehrzahl von voneinander verschiedenen Programmieraufgaben verwendet wird.

9. Verfahren nach Anspruch 8, bei dem wenigstens 10, insbesondere wenigstens 20 voneinander verschiedene Programmieraufgaben verwendet wird.

10. Verfahren nach einem der vorangehenden Ansprüche, bei dem die Schritte

- Übermitteln der Programmieraufgabe an das Large Language Model und Empfang der Lösung,

- Ermittlung einer Qualitätsreihenfolge für die Lösungen,

- Feinabstimmung des Large Language Model mit einem Verfahren gemäß der Direct Preference Optimization mehrfach wiederholt werden.

11. Large Language Model mit einem neuronalen Netzwerk mit wenigstens 100 Millionen Parametern, trainiert mit einem Verfahren nach einem der vorangehenden Ansprüche.