💬 NLP

Fine-tuned LLM-based Code Migration Framework

Ce document présente un cadre de modèle de langage à grande échelle affiné qui automatise efficacement la migration de systèmes basés sur SQL d'Oracle PL/SQL vers PostgreSQL en intégrant des techniques d'ingénierie traditionnelles, une analyse d'erreurs itérative et les retours d'experts afin de réduire considérablement les erreurs de syntaxe et d'optimiser la logique de la base de données.

Auteurs originaux : Oleg Grynets, Vasyl Lyashkevych, Dmytro Baran, Maksym Orliansky, Taras Zelenyy, Markiian Leshchyshyn

Publié 2026-02-06

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Oleg Grynets, Vasyl Lyashkevych, Dmytro Baran, Maksym Orliansky, Taras Zelenyy, Markiian Leshchyshyn

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous possédez une immense bibliothèque de manuels d'instructions écrits dans un ancien langage complexe (Oracle SQL). Votre entreprise souhaite passer à un nouveau langage, plus moderne (PostgreSQL), pour économiser de l'argent et gagner en rapidité. Le problème ? Les anciens manuels sont gigantesques, comprenant des milliers de fichiers, et les deux langages ne se contentent pas d'avoir des mots différents ; ils ont des grammaires, des logiques et des règles totalement différentes.

Ce document décrit un système automatisé intelligent conçu par des chercheurs d'EPAM Systems pour traduire ces anciens manuels vers le nouveau langage sans rien casser. Voici comment ils ont procédé, expliqué simplement :

1. Le Problème : Ce n'est pas qu'un simple « Rechercher et Remplacer »

Vous ne pouvez pas utiliser un simple dictionnaire pour traduire cela car les « phrases » de l'ancien système (Oracle) signifient souvent quelque chose de totalement différent dans le nouveau système (PostgreSQL). Les outils traditionnels (comme une application de traduction standard) tentent de suivre des règles strictes, mais ils se retrouvent souvent bloqués face à des histoires complexes, omettant de larges portions du manuel ou écrivant des absurdités.

2. La Solution : Un Robot « Super-Traducteur »

L'équipe a construit un robot d'IA personnalisé (un Grand Modèle de Langage ou LLM) et l'a formé spécifiquement pour cette tâche. Ils ne lui ont pas simplement demandé de « traduire » ; ils l'ont entraîné en utilisant une méthode spéciale en deux étapes :

Étape 1 : Apprendre les règles (La salle de classe) : D'abord, ils ont appris à l'IA à comprendre la grammaire et la structure des deux langages séparément. Ils lui ont donné des exemples de l'apparence d'une commande Oracle spécifique et de la manière dont elle devrait être décrite en langage clair. Cela a aidé l'IA à comprendre « l'ambiance » et la structure du code avant de tenter la traduction.
Étape 2 : Apprendre à traduire (La pratique) : Une fois que l'IA a compris les règles, ils lui ont donné des paires directes : « Voici une phrase Oracle, voici la phrase PostgreSQL correspondante ». C'est là qu'elle a appris la conversion réelle.

3. Le Filet de Sécurité « L'Humain dans la Boucle »

Même les robots intelligents font des erreurs. Ainsi, le système dispose d'une équipe de contrôle qualité intégrée :

Le Vérificateur Automatique : Le système scanne automatiquement le nouveau code pour détecter les erreurs de grammaire (syntaxe) et les erreurs de logique.
Les Experts Réviseurs : Lorsque le système est incertain (face à une instruction très rare ou complexe), il signale l'élément à un expert humain. L'expert corrige l'erreur, et le système apprend de cette correction pour faire mieux la prochaine fois. C'est comme un élève qui reçoit une note et un commentaire, puis étudie ce sujet spécifique avant le prochain examen.

4. La « Fiche de Révision » (RAG)

Parfois, l'IA a besoin de consulter des règles spécifiques pendant son travail. Les chercheurs ont construit deux types de « fiches de révision » (bases de connaissances) :

Stratégie A (L'Encyclopédie) : L'IA peut consulter simultanément le code original, les règles officielles du nouveau langage et les guides de traduction écrits par des experts.
Stratégie B (Le Livre d'Exemples) : L'IA consulte simplement un livre d'exemples « Avant et Après » pour deviner la meilleure traduction.
Ils ont constaté que le fait de disposer de « l'Encyclopédie » (Stratégie A) aidait l'IA à mieux comprendre le contexte, surtout pour les parties délicates.

5. Le « Compteur d'Écart » (Savoir quoi étudier)

L'une des parties les plus fascinantes de leur système est sa capacité à savoir ce qu'il doit étudier ensuite. Après chaque cycle de traduction, le système calcule un « Score d'Écart » pour différents types de code :

« Nous sommes excellents pour traduire les commandes mathématiques de base. »
« Mais nous sommes très mauvais pour traduire les scripts de sauvegarde. »
Le système utilise ce score pour dire à l'équipe humaine : « Ne perdez pas de temps à étudier les mathématiques ; allez nous trouver 50 exemples supplémentaires de scripts de sauvegarde. » Cela garantit que l'IA s'améliore précisément là où elle est la plus faible, plutôt que de simplement deviner.

6. Les Résultats : Un Gain de Temps Massif

Lorsqu'ils ont testé leur nouveau système d'IA par rapport aux anciens outils basés sur des règles :

Précision : L'IA a commis beaucoup moins d'erreurs et a traduit une plus grande partie du code correctement.
Complétude : Les anciens outils abandonnaient souvent face à des phrases complexes, les laissant vides. L'IA, elle, tente la traduction et réussit généralement.
Argent et Temps : Les chercheurs ont calculé que pour un projet de 100 000 fichiers, leur IA pouvait traduire avec succès environ 27 000 fichiers de plus que l'ancien outil.
- L'analogie : Si un expert humain peut traduire 150 fichiers par jour, l'ancien outil laisserait une pile de travail qu'un humain mettrait 9 mois à terminer manuellement. L'IA a accompli ce travail automatiquement en une fraction du temps.

Résumé

Ce document prouve qu'en combinant une IA intelligente, une méthode d'entraînement en deux étapes, des experts humains pour les cas complexes, et un système qui détermine constamment ce qu'il doit apprendre, on peut migrer de vastes et complexes systèmes informatiques d'un langage à un autre beaucoup plus rapidement, moins cher et plus précisément qu'auparavant. Cela transforme un cauchemar de réécriture manuelle en un processus automatisé et gérable.

Résumé technique : Cadre de migration de code basé sur un LLM affiné (Fine-tuned)

Problématique

La migration de systèmes de gestion de bases de données (SGBD) à grande échelle d'Oracle vers PostgreSQL est un défi interdisciplinaire complexe qui dépasse la simple conversion de syntaxe. Les auteurs identifient plusieurs barrières critiques :

Disparités sémantiques et structurelles : Des différences significatives existent entre l'Oracle PL/SQL et le PostgreSQL PL/pgSQL concernant la syntaxe, les types de données, le comportement des curseurs et les stratégies d'optimisation des requêtes.
Échelle et dépendance : Les bases de code volumineuses contiennent souvent des centaines de milliers de fichiers interdépendants, ce qui rend l'analyse et la transformation automatisées difficiles.
Limites des outils existants : Les outils traditionnels basés sur des règles (ex. : AWS Schema Conversion Tool, Ora2PG) peinent face à l'analyse contextuelle profonde, au SQL dynamique, aux déclencheurs complexes et à la gestion des exceptions, ce qui entraîne souvent des traductions incomplètes ou une dérive sémantique.
Limites des LLM : Bien que les modèles de langage de grande taille (LLM) soient prometteurs, ils souffrent fréquemment d'erreurs systématiques telles que la dérive sémantique, les correspondances d'appels d'API incorrectes et les incohérences de mapping des structures de contrôle lorsqu'ils sont appliqués directement sans adaptation spécifique au domaine.

Le problème scientifique central est l'absence d'un cadre unifié et itératif qui équilibre l'ajustement fin (fine-tuning) et l'ingénierie de prompt pour garantir l'intégrité sémantique, minimiser les risques architecturaux et atteindre une haute fidélité de migration à travers de vastes bibliothèques de code hétérogènes.

Méthodologie

La solution proposée est un cadre itératif et évolutif qui intègre l'IA générative (GAI) aux techniques traditionnelles du génie logiciel. La méthodologie est structurée autour de plusieurs composantes clés :

1. Rationalité de l'ajustement fin en deux étapes

Les auteurs rejacent un événement d'apprentissage holistique unique au profit d'un pipeline d'ajustement d'instruction en deux étapes :

Étape 1 (Alignement syntaxique) : Le modèle est entraîné sur un jeu de données associant du code à des descriptions en langage naturel (<Code> : <Description>). Cette phase se concentre sur l'apprentissage des motifs structurels, des nuances de dialecte, des signatures de types et des règles de portée, sans effectuer de conversion directe.
Étape 2 (Comportement de transformation) : Le modèle est affiné sur des paires de transformation directe (<Code Oracle> : <Code PostgreSQL>). Cette étape fait passer le modèle de la compréhension syntaxique à la conversion de la logique procédurale, assurant la préservation sémantique lors de la transformation des blocs, des curseurs et des exceptions.

2. Moteur de profilage de caractéristiques de code hybride (HCFPE)

Pour gérer l'hétérogénéité de la base de code, l'HCFPE annote le corpus avec des métadonnées de fonctionnalités SQL (marqueurs de syntaxe, structures de flux, opérateurs spécifiques au dialecte). Cela convertit le code non structuré en une représentation structurée, permettant la création de jeux de données stratifiés (petits, moyens, grands) et garantissant que les données d'entraînement reflètent fidèlement la distribution de fonctionnalités telles que RMAN, SQL*Plus et PL/SQL.

3. Architectures de base de connaissances et RAG

Le cadre emploie la génération augmentée par récupération (RAG) avec deux stratégies distinctes :

Stratégie A (Base de connaissances hybride) : Utilise trois bases de données vectorielles distinctes pour le code Oracle, la documentation PostgreSQL et les règles de transformation dérivées d'experts (SME). Cela permet au LLM de trianguler le contexte, en appliquant des règles déterministes et une documentation syntaxique faisant autorité aux côtés d'exemples de code.
Stratégie B (Base de connaissances unifiée) : Utilise une base de données vectorielle unique contenant uniquement des paires de transformation directe "Oracle-PostgreSQL". Cela teste la capacité du modèle à généraliser en se basant uniquement sur des exemples, sans application explicite de règles.

4. Humain dans la boucle et correction d'erreurs

Le cadre incorpore une logique d'itération en boucle fermée :

Évaluation : Les sorties sont évaluées à l'aide de métriques NLP (Recall, BLEU, ChrF) et de validateurs structurels (vérificateurs de syntaxe, analyseurs statiques).
Analyse d'erreurs : Les erreurs sont classées en groupes : syntaxe, sémantique, structure et fonction.
Feedback des experts (SME) : Les experts interviennent uniquement sur les échantillons ambigus ou complexes. Leur retour est utilisé pour étendre le jeu de données et affiner les annotations.
Estimation du jeu de données : Un mécanisme mathématique calcule une métrique de "Gap" ( $GAP_{Feature}$ ) pour chaque fonctionnalité SQL. Cette métrique combine la représentation du jeu de données ( $GAP_{Dict}$ ) et la qualité du modèle ( $GAP_{Quality}$ ) pour prioriser automatiquement les fonctionnalités nécessitant des échantillons d'entraînement supplémentaires pour l'itération suivante.

5. Pipelines expérimentaux

L'étude évalue quatre pipelines distincts :

Conversion directe : Conversion basée sur le prompt standard sans contexte externe.
Conversion sensible à l'historique : Incorpore les segments précédemment générés comme contexte pour maintenir la cohérence de l'état.
RAG Stratégie A : Récupère un contexte hétérogène (règles, documentation, code).
RAG Stratégie B : Récupère uniquement des exemples de transformation appariés.

Résultats clés

L'étude a évalué plusieurs modèles (Qwen32B, Qwen7B, variantes de GPT-4) par rapport à l'outil traditionnel Ora2PG sur un ensemble de plus de 1 800 fichiers stratifiés par taille.

Supériorité des LLM affinés : Le modèle Qwen32B affiné (Qwen32B-ft2) a systématiquement surpassé tous les autres candidats et l'outil Ora2PG. Dans le pipeline de conversion directe, il a atteint une efficacité de conversion de fichiers de 74,57 %, contre 49,66 % pour Ora2PG.
Réduction des erreurs : L'ajustement fin a considérablement réduit les taux d'erreur de syntaxe (SER). Le modèle Qwen32B-ft2 a produit le moins de fichiers contenant des erreurs (205) et le nombre total d'erreurs le plus bas (3 554) dans le pipeline de conversion, tandis que les modèles de base et les LLM plus petits accumulaient des volumes d'erreurs nettement plus élevés.
Couverture des fonctionnalités : Les modèles affinés ont démontré une meilleure adéquation avec les distributions de fonctionnalités attendues de PostgreSQL. Par exemple, Qwen32B-ft2 a atteint une couverture de 72,3 % pour CORE_SQL et 69,1 % pour la conversion PL/SQL vers PL/pgSQL, alors qu'Ora2PG présentait une perte d'information substantielle (ex. : 47,5 % de couverture PL/SQL) et une sous-production systématique de la logique procédurale.
Impact du RAG : Bien que le RAG apporte des bénéfices supplémentaires, le pipeline sensible à l'historique et la conversion directe avec des modèles affinés ont produit les résultats les plus stables. La Stratégie A (Hybride) offrait une robustesse pour les fonctionnalités complexes, tandis que la Stratégie B montrait de solides performances lorsque des jeux de données appariés de haute qualité étaient disponibles.
Impact économique : Les auteurs estiment qu'une seule itération d'ajustement fin a permis la migration automatique d'environ 27 690 fichiers de plus qu'Ora2PG. Cela se traduit par une réduction d'environ 9 mois-personne de travail manuel des experts pour une base de code de 100 000 fichiers.

Signification et revendications

L'article prétend fournir un fondement méthodologique pour la migration de bases de données à grande échelle qui répond à l'écart entre l'automatisation basée sur des règles et la complexité sémantique des bases de code modernes.

Contrôle qualité itératif : La principale contribution est le mécanisme d' "estimation de jeu de données basé sur le GAP", qui transforme la migration d'une tâche d'ingénierie statique en une boucle d'optimisation pilotée par les données. Cela permet une expansion ciblée des jeux de données, garantissant que les améliorations du modèle sont dictées par des déficits de performance spécifiques plutôt que par une accumulation aveugle de données.
Évolutivité : Le cadre est conçu pour gérer des bibliothèques de taille entreprise (plus de 100 000 fichiers) en décomposant la qualité de la migration en métriques de niveau fonctionnalité, évitant ainsi la croissance exponentielle de la charge de travail manuelle associée aux méthodes traditionnelles.
Approche hybride : L'étude valide qu'une combinaison d'ajustement fin en deux étapes (pour la compétence structurelle) et de RAG (pour l'ancrage contextuel) produit des résultats supérieurs à l'utilisation de l'une ou l'autre approche seule, ou des outils traditionnels basés sur des règles.
Viabilité économique : En quantifiant la réduction de l'effort manuel, l'article soutient que la migration basée sur les LLM est non seulement techniquement réalisable mais aussi économiquement avantageuse, offrant un ROI rapide même avec une préparation initiale modeste des jeux de données (30 000 échantillons d'entraînement préparés en six sprints).

Les auteurs concluent que, bien que la validation au niveau de l'exécution reste un objectif futur, le cadre proposé établit avec succès une approche scalable, précise et économiquement viable pour la modernisation des bases de données d'entreprise.