💬 NLP

Fine-tuned LLM-based Code Migration Framework

Dieses Paper präsentiert ein Framework auf Basis eines feinabgestimmten Large Language Models, das die Migration von SQL-basierten Systemen von Oracle PL/SQL zu PostgreSQL durch die Integration traditioneller Engineering-Techniken, iterativer Fehleranalyse und Expertenfeedback effektiv automatisiert, um Syntaxfehler signifikant zu reduzieren und die Datenbanklogik zu optimieren.

Ursprüngliche Autoren: Oleg Grynets, Vasyl Lyashkevych, Dmytro Baran, Maksym Orliansky, Taras Zelenyy, Markiian Leshchyshyn

Veröffentlicht 2026-02-06

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Oleg Grynets, Vasyl Lyashkevych, Dmytro Baran, Maksym Orliansky, Taras Zelenyy, Markiian Leshchyshyn

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie besitzen eine riesige Bibliothek von Bedienungsanleitungen, die in einer alten, komplexen Sprache (Oracle SQL) verfasst sind. Ihr Unternehmen möchte zu einer neuen, modernen Sprache (PostgreSQL) wechseln, um Geld zu sparen und schneller zu arbeiten. Das Problem? Die alten Anleitungen sind gewaltig, bestehen aus tausenden von Dateien, und die beiden Sprachen unterscheiden sich nicht nur durch ihre Wörter, sondern auch grundlegend in Grammatik, Logik und Regeln.

Dieses Papier beschreibt ein intelligentes, automatisiertes System, das von Forschern bei EPAM Systems entwickelt wurde, um diese alten Anleitungen in die neue Sprache zu übersetzen, ohne dabei etwas zu beschädigen. Hier ist die Erklärung, wie sie es gemacht haben, vereinfacht dargestellt:

1. Das Problem: Es ist nicht nur ein „Suchen und Ersetzen“

Man kann nicht einfach ein einfaches Wörterbuch verwenden, um dies zu übersetzen, da die „Sätze“ im alten System (Oracle) im neuen System (PostgreSQL) oft etwas völlig anderes bedeuten. Traditionelle Werkzeuge (wie eine Standard-Übersetzungs-App) versuchen, strengen Regeln zu folgen, bleiben aber bei komplexen Geschichten oft stecken, lassen riesige Teile der Anleitung aus oder schreiben Unsinn.

2. Die Lösung: Ein „Super-Übersetzer“-Roboter

Das Team baute einen maßgeschneiderten KI-Roboter (ein Large Language Model) und trainierte ihn spezifisch für diese Aufgabe. Sie haben ihn nicht einfach nur gebeten zu „übersetzen“; sie haben ihn mit einer speziellen Zwei-Schritte-Methode trainiert:

Schritt 1: Die Regeln lernen (Das Klassenzimmer): Zuerst brachten sie der KI bei, die Grammatik und Struktur beider Sprachen separat zu verstehen. Sie gaben ihr Beispiele dafür, wie ein spezifischer Oracle-Befehl aussieht und wie dieser in klarem Englisch beschrieben werden sollte. Dies half der KI, den „Vibe“ und die Struktur des Codes zu verstehen, bevor sie versuchte, ihn zu übersetzen.
Schritt 2: Das Übersetzen lernen (Die Praxis): Sobald die KI die Regeln verstanden hatte, gab man ihr direkte Paare: „Hier ist ein Oracle-Satz, hier ist der korrekte PostgreSQL-Satz.“ Hier lernte sie die eigentliche Konvertierung.

3. Das Sicherheitsnetz „Mensch im Prozess“ (Human-in-the-Loop)

Selbst schlaue Roboter machen Fehler. Deshalb verfügt das System über ein eingebautes Qualitätskontroll-Team:

Der Auto-Checker: Das System scannt den neuen Code automatisch auf Grammatikfehler (Syntax) und Logikfehler.
Die Experten-Prüfer: Wenn das System sich bei etwas unsicher ist (wie einer sehr seltenen oder komplexen Anweisung), markiert es dies für einen menschlichen Experten. Der Experte korrigiert es, und das System lernt aus dieser Korrektur, um beim nächsten Mal besser zu werden. Es ist wie ein Schüler, der eine Note und einen Kommentar erhält und dann genau dieses Thema lernt, bevor er die nächste Prüfung schreibt.

4. Das „Spickzettel“-Prinzip (RAG)

Manchmal muss die KI während der Arbeit nach spezifischen Regeln nachschlagen. Die Forscher bauten zwei Arten von „Spickzetteln“ (Wissensdatenbanken):

Strategie A (Die Enzyklopädie): Die KI kann den ursprünglichen Code, die offiziellen Regeln der neuen Sprache und Experten-geschriebene Übersetzungsleitfäden gleichzeitig nachschlagen.
Strategie B (Das Beispielbuch): Die KI schaut sich einfach ein Buch mit „Vorher-Nachher“-Beispielen an, um die beste Übersetzung zu erraten.
Sie fanden heraus, dass das Vorhandensein der „Enzyklopädie“ (Strategie A) der KI half, den Kontext besser zu verstehen, insbesondere bei schwierigen Teilen.

5. Das „Lücken-Messgerät“ (Wissen, was zu lernen ist)

Einer der coolsten Teile ihres Systems ist, wie es weiß, was es als Nächstes lernen muss. Nach jeder Runde der Übersetzung berechnet das System einen „Gap Score“ (Lücken-Score) für verschiedene Arten von Code:

„Wir sind sehr gut darin, grundlegende mathematische Befehle zu übersetzen.“
„Aber wir sind schrecklich darin, Backup-Skripte zu übersetzen.“
Das System nutzt diesen Score, um dem menschlichen Team zu sagen: „Verschwendet keine Zeit mit Mathe; sucht uns stattdessen 50 weitere Beispiele für Backup-Skripte.“ Dies stellt sicher, dass die KI genau dort besser wird, wo sie am schwächsten ist, anstatt nur zu raten.

6. Die Ergebnisse: Eine massive Zeitersparnis

Als sie ihr neues KI-System gegen die alten, regelbasierten Werkzeuge testeten, zeigten sich folgende Ergebnisse:

Genauigkeit: Die KI machte weit weniger Fehler und übersetzte viel mehr des Codes korrekt.
Vollständigkeit: Die alten Werkzeuge gaben bei komplexen Sätzen oft auf und ließen diese leer. Die KI versuchte sie zu übersetzen und war meist erfolgreich.
Geld & Zeit: Die Forscher berechneten, dass ihre KI-System bei einem Projekt mit 100.000 Dateien etwa 27.000 Dateien mehr erfolgreich übersetzen konnte als das alte Werkzeug.
- Die Analogie: Wenn ein menschlicher Experte 150 Dateien pro Tag übersetzen kann, würde das alte Werkzeug einen Stapel Arbeit hinterlassen, für dessen manuelle Fertigstellung ein Mensch 9 Monate bräuchte. Die KI erledigte diese Arbeit automatisch in einem Bruchteil der Zeit.

Zusammenfassung

Das Papier beweist, dass man durch die Kombination einer intelligenten KI, einer Zwei-Schritte-Trainingsmethode, menschlicher Experten für schwierige Fälle und einem System, das ständig erkennt, was es als Nächstes lernen muss, riesige, komplexe Computersysteme viel schneller, günstiger und genauer von einer Sprache in eine andere migrieren kann. Es verwandelt einen Albtraum des manuellen Umschreibens in einen handhabbaren, automatisierten Prozess.

Technisches Resümee: Fine-getuntes LLM-basiertes Code-Migrations-Framework

Problemstellung

Die Migration von groß angelegten Datenbankmanagementsystemen (DBMS) von Oracle zu PostgreSQL ist eine komplexe, interdisziplinäre Herausforderung, die weit über eine einfache Syntaxkonvertierung hinausgeht. Die Autoren identifizieren mehrere kritische Barrieren:

Semantische und strukturelle Disparitäten: Es bestehen signifikante Unterschiede zwischen Oracle PL/SQL und PostgreSQL PL/pgSQL hinsichtlich Syntax, Datentypen, Cursor-Verhalten und Abfrageoptimierungsstrategien.
Skalierung und Abhängigkeit: Große Codebasen enthalten oft Hunderttausende interdependenter Dateien, was die automatisierte Analyse und Transformation erschwert.
Limitierungen bestehender Werkzeuge: Traditionelle regelbasierte Tools (z. B. AWS Schema Conversion Tool, Ora2PG) haben Schwierigkeiten mit tiefer kontextueller Analyse, dynamischem SQL, komplexen Triggern und der Ausnahmebehandlung, was häufig zu unvollständigen Translationen oder semantischer Drift führt.
LLM-Limitierungen: Während Large Language Models (LLMs) vielversprechend sind, leiden sie bei direkter Anwendung ohne domänenspezifische Anpassung häufig unter systematischen Fehlern wie semantischer Drift, API-Aufruf-Fehlpaarungen und inkonsistenten Abbildungen von Kontrollstrukturen.

Das Kernproblem der Wissenschaft besteht im Fehlen eines einheitlichen, iterativen Frameworks, das Fine-Tuning mit Prompt Engineering kombiniert, um die semantische Integrität zu gewährleisten, architektonische Risiken zu minimieren und eine hochgradig getreue Migration über massive, heterogene Code-Bibliotheken hinweg zu erreichen.

Methodik

Die vorgeschlagene Lösung ist ein iteratives, skalierbares Framework, das Generative KI (GAI) mit traditionellen Software-Engineering-Techniken integriert. Die Methodik gliedert sich in mehrere Schlüsselkomponenten:

1. Rationale des zweistufigen Fine-Tunings

Die Autoren lehnen ein einzelnes ganzheitliches Lernereignis zugunsten einer zweistufigen Instruction-Tuning-Pipeline ab:

Stufe 1 (Syntaktische Ausrichtung): Das Modell wird auf einem Datensatz trainiert, der Code mit natürlichen Sprachbeschreibungen paart (<Code> : <Beschreibung>). Diese Phase konzentriert sich darauf, strukturelle Muster, Dialektnuancen, Typ-Signaturen und Scope-Regeln sowohl von Oracle als auch von PostgreSQL zu erlernen, ohne eine direkte Konvertierung durchzuführen.
Stufe 2 (Transformationsverhalten): Das Modell wird auf direkten Transformationspaaren feinabgestimmt (<Oracle Code> : <PostgreSQL Code>). In dieser Stufe wechselt das Modell von der syntaktischen zum prozeduralen Logik-Verständnis, um die semantische Integrität bei der Transformation von Blöcken, Cursorn und Exceptions zu gewährleisten.

2. Hybrid Code Feature Profiling Engine (HCFPE)

Um die Heterogenität der Codebasis zu bewältigen, annotiert die HCFPE den Korpus mit SQL-Feature-Metadaten (Syntax-Marker, Flussstrukturen, dialektspezifische Operatoren). Dies überführt unstrukturierten Code in eine strukturierte Repräsentation und ermöglicht die Erstellung stratifizierter Datensätze (klein, mittel, groß), wodurch sichergestellt wird, dass die Trainingsdaten die Verteilung von Features wie RMAN, SQL*Plus und PL/SQL korrekt widerspiegeln.

3. Wissensdatenbank-Architekturen und RAG

Das Framework verwendet Retrieval Augmented Generation (RAG) mit zwei unterschiedlichen Strategien:

Strategie A (Hybride Wissensdatenbank): Nutzt drei separate Vektordatenbanken für Oracle-Code, PostgreSQL-Dokumentation und von Fachexperten (SME) abgeleitete Transformationsregeln. Dies ermöglicht es dem LLM, den Kontext zu triangulieren, indem deterministische Regeln und autoritative Syntax-Dokumentationen zusammen mit Code-Beispielen angewendet werden.
Strategie B (Vereinheitlichte Wissensdatenbank): Verwendet eine einzige Vektordatenbank, die nur direkte "Oracle-PostgreSQL"-Transformationspaare enthält. Dies testet die Fähigkeit des Modells, allein auf Basis von Beispielen zu generalisieren, ohne explizite Regelanwendung.

4. Human-in-the-Loop und Fehlerkorrektur

Das Framework beinhaltet eine geschlossene Feedback-Schleife:

Evaluierung: Die Outputs werden mittels NLP-Metriken (Recall, BLEU, ChrF) und strukturellen Validatoren (Syntax-Checker, statische Analysatoren) bewertet.
Fehleranalyse: Fehler werden in die Gruppen Syntax, Semantik, Struktur und Funktionalität kategorisiert.
SME-Feedback: Fachexperten intervenieren nur bei ambivalenten oder komplexen Stichproben. Ihr Feedback wird genutzt, um den Datensatz zu erweitieren und die Annotationen zu verfeinern.
Datensatz-Schätzung: Ein mathematischer Mechanismus berechnet eine "Gap"-Metrik ( $GAP_{Feature}$ ) für jedes SQL-Feature. Diese Metrik kombiniert die Datensatzrepräsentation ( $GAP_{Dict}$ ) und die Modellqualität ( $GAP_{Quality}$ ), um automatisch zu priorisieren, welche Features in der nächsten Iteration zusätzliche Trainingsbeispiele benötigen.

5. Experimentelle Pipelines

Die Studie evaluiert vier verschiedene Pipelines:

Direkte Konvertierung: Standardmäßige promptbasierte Konvertierung ohne externen Kontext.
Historienbewusste Konvertierung: Bezieht zuvor generierte Chunks als Kontext ein, um die Konsistenz des Zustands aufrechtzuerhalten.
RAG Strategie A: Ruft heterogenen Kontext (Regeln, Dokumentation, Code) ab.
RAG Strategie B: Ruft nur gepaarte Transformationsbeispiele ab.

Kernergebnisse

Die Studie evaluierte mehrere Modelle (Qwen32B, Qwen7B, GPT-4 Varianten) gegen das traditionelle Tool Ora2PG anhand eines Datensatzes von über 1.800 Dateien, die nach Größe stratifiziert wurden.

Überlegenheit von fine-getunten LLMs: Das fine-getunte Qwen32B-Modell (Qwen32B-ft2) übertraf konsistent alle anderen Kandidaten sowie das Ora2PG-Tool. In der Direct Conversion Pipeline erreichte es eine Datei-Konvertierungseffizienz von 74,57 %, verglichen mit 49,66 % bei Ora2PG.
Fehlerreduktion: Das Fine-Tuning reduzierte die Syntax-Fehlerrate (SER) signifikant. Das Qwen32B-ft2 Modell produzierte die wenigsten fehlerbehafteten Dateien (205) und die niedrigste Gesamtzahl an Fehlern (3.554) in der Konvertierungs-Pipeline, während Basismodelle und kleinere LLMs deutlich höhere Fehlervolumina akkumulierten.
Feature-Abdeckung: Fine-getunte Modelle zeigten eine überlegene Übereinstimmung mit den erwarteten PostgreSQL-Feature-Verteilungen. Beispielsweise erreichte Qwen32B-ft2 eine Abdeckung von 72,3 % für CORE_SQL und 69,1 % für die PL/SQL zu PL/pgSQL Konvertierung, während Ora2PG erheblichen Informationsverlust zeigte (z. B. 47,5 % PL/SQL-Abdeckung) und prozedurale Logik systematisch unterproduzierte.
RAG-Auswirkung: Während RAG zusätzliche Vorteile bot, lieferten die historienbewusste Pipeline und die direkte Konvertierung mit fine-getunten Modellen die stabilsten Ergebnisse. Strategie A (Hybrid) bot Robustheit für komplexe Features, während Strategie B eine starke Leistung zeigte, sofern hochwertige gepaarte Datensätze verfügbar waren.
Ökonomische Auswirkungen: Die Autoren schätzen, dass eine einzige Fine-Tuning-Iteration die automatische Migration von etwa 27.690 Dateien mehr ermöglichte, als Ora2PG bewältigen könnte. Dies entspricht einer Reduktion von etwa 9 Personenmonaten manueller SME-Arbeit für eine 100.000-Dateien-Codebasis.

Bedeutung und Ansprüche

Die Arbeit beansprucht, eine methodische Grundlage für die groß angelegte Datenbankmigration zu liefern, die die Lücke zwischen regelbasierter Automatisierung und der semantischen Komplexität moderner Codebasen schließt.

Iterative Qualitätskontrolle: Der primäre Beitrag ist der "GAP-basierte Datensatz-Schätzungsmechanismus", der die Migration von einer statischen Engineering-Aufgabe in einen datengesteuerten Optimierungsprozess verwandelt. Dies ermöglicht eine gezielte Erweiterung des Datensatzes und stellt sicher, dass Modellverbesserungen durch spezifische Leistungsdefizite statt durch bloße Datenakkumulation vorangetrieben werden.
Skalierbarkeit: Das Framework ist darauf ausgelegt, Enterprise-Scale-Bibliotheken (100.000+ Dateien) zu handhaben, indem es die Migrationsqualität in Feature-Level-Metriken zerlegt und so das exponentielle Wachstum des manuellen Arbeitsaufwands verhindert, das mit traditionellen Methoden verbunden ist.
Hybrider Ansatz: Die Studie validiert, dass eine Kombination aus zweistufigem Fine-Tuning (für strukturelle Kompetenz) und RAG (für kontextuelle Fundierung) überlegene Ergebnisse liefert als entweder einer dieser Ansätze allein oder herkömmliche regelbasierte Tools.
Wirtschaftliche Tragfähigkeit: Durch die Quantifizierung der Reduktion des manuellen Aufwands argumentiert das Paper, dass LLM-basierte Migration nicht nur technisch machbar, sondern ökonomisch vorteilhaft ist und einen schnellen ROI bietet, selbst bei moderater initialer Datensatzvorbereitung (30k Trainingssamples vorbereitet in sechs Sprints).

Die Autoren kommen zu dem Schluss, dass das vorgeschlagene Framework – während die Validierung auf Ausführungsebene weiterhin ein zukünftiges Ziel bleibt – erfolgreich einen skalierbaren, präzisen und wirtschaftlich tragfähigen Ansatz für die Modernisierung von Enterprise-Datenbanken etabliert.