Фреймворк для міграції коду на основі донавченої LLM

Автори: Олег Гринець, CTO, Data Practice; Василь Ляшкевич, Manager, Data Analytics Consulting; Максим Орлянський, Junior Data Scientist; Тарас Зелений, Data Scientist; Маркіян Лешчишин, Machine Learning Engineer.

Міграція кодової бази великої СУБД з Oracle на PostgreSQL — це складний та багатогранний процес, що виходить далеко за межі простого перетворення синтаксису. Це комплексне міждисциплінарне завдання, яке вимагає забезпечення семантичної цілісності бізнес-процесів, мінімізації архітектурних ризиків, забезпечення безперервності бізнесу та досягнення продуктивності, порівнянної або кращої за різні архітектури цих систем керування базами даних.

Останнім часом було досягнуто значного прогресу в трансформації бібліотек коду за допомогою великих мовних моделей (LLM) та генеративного штучного інтелекту (GenAI). Моделі з відкритим кодом, такі як Code Llama та StarCoder2, продемонстрували суттєві покращення в точності синтаксичного перекладу та синтезу коду. Однак як показали численні емпіричні дослідження, LLM не завжди забезпечують ідеальну якість під час міграції бібліотек коду, допускаючи систематичні помилки, такі як семантичний дрейф та неузгоджене відображення структур керування.

Фундаментальним методологічним викликом залишається пошук оптимального балансу між донавчання та швидким проектуванням. Донавчання дозволяє адаптувати GenAI до завдання, використовуючи доменні дані, але цей підхід вимагає більше ресурсів та доступу до великих наборів даних. З іншого боку, хоча якісний prompt engineering є менш витратним, його може бути недостатньо для вирішення всіх проблем, пов’язаних із семантичними відмінностями між Oracle та PostgreSQL.

Запропоноване рішення розглядає наступний підхід до підготовки LLM (Рис. 1). Архітектура pipeline підготовки LLM відображає емпіричний висновок, що надійна міграція бази даних не може бути досягнута виключно через прямі запити. Натомість вона вимагає ітеративного циклу вдосконалення, в якому модель вивчає синтаксис SQL та спостерігає репрезентативні патерни. Це отримує ретельно відібраний зворотний зв’язок та ітеративно зменшує кількість типових шаблонів помилок у мультидіалектній кодовій базі.

Пайплайн підготовки LLM до використання у продакшені

Щоб систематично оцінити продуктивність LLM під час міграції з Oracle на PostgreSQL, ми розглянули багато різних систем-кандидатів, включаючи Qwen32B-base, Qwen32B-ft2, Qwen32B-ft1, Qwen7B-ft2, GPT-4.1-mini, GPT-4.1-nano, GPT-4o-mini, GPT-4o та традиційний інструмент міграції Ora2PG. Щоб врахувати неоднорідність реальних SQL-кодових баз, набір для оцінювання було стратифіковано за розміром файлу. Скрипти було категоризовано на:

• великі (L-size, >200 рядків; 165 файлів);
• середні (M-size, 101–200 рядків; 212 файлів);
• малі (S-size, ≤100 рядків; 1,425 файлів).

Ця стратифікація дозволяє аналізувати поведінку моделі за різної структурної та семантичної складності.

Процес починається зі збору артефактів Oracle та PostgreSQL — збережених процедур, тригерів, тіл пакетів, SQL*Plus скриптів, утиліт управління та фрагментів RMAN, які формують основу набору даних. Оскільки ці артефакти значно відрізняються за синтаксисом та семантикою, простої статичної валідації недостатньо. HCFPE аналізує та анотує код метаданими SQL-функцій, ідентифікуючи синтаксичні патерни, структури потоку керування та діалект-специфічні оператори. Це перетворює неструктурований код у структурований формат, придатний для послідовної та відтворюваної конфігурації набору даних.

Набір даних стратифікується за розміром файлу (малий, середній, великий), щоб відобразити різноманітність реальної кодової бази та оцінити, як продуктивність моделі масштабується зі зростанням структурної та семантичної складності. Анотований корпус потім обробляється конфігуратором набору даних для створення двох комплементарних наборів даних для стратегії двоетапного донавчання. Перший набір даних фокусується на синтаксичних відповідностях, використовуючи пари у форматі “: ”. Другий набір даних містить прямі пари трансформації, “: ”, що дозволяє моделі перейти від розуміння синтаксису до вивчення поведінки трансформації діалектів.

Щоб краще зрозуміти складність міграції, ми проаналізували розподіл функцій Oracle у всіх скриптах. Різні функції Oracle вносять різні синтаксичні та семантичні обмеження, що ускладнює міграцію. Використовуючи HCFPE, ми квантифікували розподіл функцій у різних сценаріях та виконали той самий аналіз для скриптів PostgreSQL. Кількість функцій було нормалізовано у відсотки, що дозволило систематично порівнювати категорії функцій Oracle та PostgreSQL у тренувальних та тестових наборах даних і підтримувати прогнозну валідацію.

Система підтримує дві альтернативні стратегії knowledge base для RAG-based міграції з Oracle на PostgreSQL.

Стратегія A використовує гібридну архітектуру з трьома окремими векторними базами даних FAISS: фрагменти коду Oracle, документація PostgreSQL та правила трансформації, визначені доменними експертами. Це налаштування дозволяє LLM отримувати різні типи контекстної інформації під час міграції — структурні патерни Oracle, офіційні правила синтаксису PostgreSQL та експертно визначену логіку трансформації.

Стратегія B використовує єдину уніфіковану векторну базу даних, побудовану лише з Dataset 2, який містить прямі пари коду “Oracle–PostgreSQL”. Ця спрощена архітектура фокусується виключно на трансформаціях на основі прикладів, зменшуючи складність системи та прискорюючи пошук. Вона розроблена для тестування того, чи може базова LLM виконувати точну міграцію SQL, використовуючи лише парні приклади, без додаткової документації або підтримки на основі правил. Однак її ефективність сильно залежить від повноти набору даних: відсутні функції Oracle не можуть бути компенсовані.

Обидві стратегії покладаються на RAG для покращення контекстної точності. Різниця полягає в тому, що саме отримується. Стратегія A повертає гетерогенні результати з трьох джерел, тоді як Стратегія B отримує лише пари трансформації з однієї уніфікованої бази даних.

Експериментальні конфігурації системи:

1. Пряме перетворення (Direct conversion)
2. History-aware перетворення
3. RAG зі Стратегією A
4. RAG зі Стратегією B

Цей дизайн ізолює вплив контекстного накопичення та пошуку.

У прямому перетворенні скрипти Oracle сегментуються на зв’язні блоки. Кожен блок доповнюється модель-специфічними запитами та перекладається незалежно, потім збирається у повний скрипт PostgreSQL. Зовнішні знання не використовуються, тому це налаштування оцінює чисту здатність LLM до перекладу.

History-aware pipeline розширює цей підхід, включаючи раніше перекладені фрагменти як контекстний вхід. Це допомагає підтримувати узгодженість між сегментами, але все ще не використовує жодної зовнішньої бази знань.

У конфігурації RAG кожен фрагмент Oracle вбудовується та зіставляється з векторною базою даних FAISS. Стратегія A отримує фрагменти Oracle, документацію PostgreSQL та правила SME з окремих сховищ, що вимагає індексації повного корпусу Oracle. Стратегія B отримує лише пари трансформації Oracle–PostgreSQL з Dataset 2.

Якість перекладу вимірювалася за допомогою Recall, BLEU та ChrF, що фіксують лексичну та структурну подібність. Коректність на рівні виконання оцінювалася за допомогою Normalized Syntax Error Rate (NSER) та Normalized Warning Rate (NSWAR). Було виконано валідацію синтаксису та часткові тести виконання, хоча повна валідація runtime була поза межами дослідження.

У прямому перетворенні модель Qwen32B Tuned перевершила всі інші моделі та базовий інструмент Ora2PG, демонструючи цінність двоетапного донавчання та feature-aware дизайну набору даних.

У history-aware налаштуванні Qwen32B Base досяг найбільш стабільної загальної продуктивності за NLP-метриками.

У RAG-експериментах різниця в продуктивності моделей була загалом невеликою. Alpha-конфігурації як для GPT-4.1-mini, так і для Qwen32B показали трохи більш стабільні результати, ніж Beta-варианти, що свідчить про покращене контекстне обґрунтування.

На таблиці 1 показано топ-5 агрегованих результатів, включаючи коректність синтаксису. Покращення продуктивності повідомляються відносно Ora2PG, використовуючи два агрегатні показники: Full Set of Metrics (FSM) та Custom Metrics (CM).

Результати демонструють, що майже всі LLM-based pipeline суттєво перевершують Ora2PG, з найбільшими покращеннями, спостережуваними для Qwen32B Tuned у Conversion та RAG pipeline. Навіть легші моделі, такі як GPT-4.1-mini та GPT-4o-mini, показують значні переваги. Лише окремі випадки, такі як Qwen7B Tuned у Conversion, показують незначні негативні покращення.

Агреговані результати експериментів

Загалом, аналіз покращень підтверджує, що LLM-driven міграція послідовно забезпечує вищу якість перекладу, ніж традиційний інструмент на основі правил.

Кількісні результати показують значне зменшення помилок у всіх pipeline. Для чіткішої інтерпретації помилки було згруповано та пов’язано з конкретними архітектурними компонентами.

Синтаксичні помилки включають неправильно сформований SQL, некоректні роздільники блоків PL/pgSQL, відсутні ключові слова та невалідні сигнатури функцій. Вони в основному є результатом діалектних відмінностей між Oracle та PostgreSQL. Покращення токенізації та діалект-aware моделювання граматики значно зменшує ці проблеми.

Семантичні помилки виникають, коли синтаксис правильний, але поведінка змінюється — наприклад, некоректна обробка NULL або неправильна інтерпретація області транзакції. Хоча вони менш часті, вони є більш критичними, оскільки впливають на коректність виконання. Донавчання та сильніші метрики якості пом’якшують їх, але глибша валідація на рівні виконання залишається необхідною.

Помилки відсутності функцій виникають, коли Oracle-специфічні конструкції (наприклад, розширені функції PL/SQL, RMAN-скрипти, команди SQL*Plus) пропускаються або спрощуються. Вони часто спричинені недостатніми контекстними знаннями. RAG-based pipeline покращує покриття, впроваджуючи feature-специфічну документацію та історичні приклади трансформації.

Структурні помилки включають порушені залежності, некоректний порядок створення об’єктів або неповні багатофайлові міграції. Вони зазвичай з’являються у великих системах. History-aware pipeline зменшує такі помилки, зберігаючи міжфайлові та темпоральні зв’язки.

У всіх pipeline ми оцінювали рівень синтаксичних помилок, помилок на рядок, неконвертованих скриптів, покриття SQL-функцій та покриття на основі розміру. Результати показують, що Conversion та History pipeline послідовно перевершують інші. В обох Qwen32B-ft2 досяг найнижчих показників помилок та мінімальної кількості неконвертованих файлів.

Інструменти на основі правил, такі як Ora2PG, демонструють системні обмеження на великих гетерогенних кодових базах. Хоча прості конструкції можуть перекладатися адекватно, глибша процедурна семантика значно погіршується. Донавчена LLM демонструють послідовні покращення в категоріях PL/SQL, відображаючи сильнішу абстракцію та передачу семантики.

Щоб підтримувати безперервне вдосконалення, ми реалізували механізм оцінки набору даних, який ідентифікує, які SQL-функції потребують додаткових тренувальних зразків. Він інтегрує чотири входи: існуючий набір даних, таксономію SQL-функцій, результати аналізу помилок та метрики якості для кожної функції. Виходом є розрив продуктивності на рівні функцій, який вказує, наскільки далеко модель від цільової точності та скільки нових зразків потрібно.

Цей етап функціонує як data-driven контролер у ітеративному циклі донавчання. Він визначає, які зразки слід додати, видалити або перебалансувати для покращення якості конверсії для конкретних функцій або системи в цілому.

Квантифікуючи розриви продуктивності та відображаючи їх на конкретні потреби вибірки, механізм забезпечує, що кожна ітерація донавчання покращує покриття функцій, повноту та зменшення помилок. Це забезпечує стійке зростання якості, навіть коли з’являються нові SQL-конструкції або патерни міграції.

Прогнозована економічна вигода від впровадження LLM-based conversion pipeline замість покладання на традиційний інструмент Ora2PG. Порівняння базується на п’яти основних групах функцій Oracle, зважених за їх оціненим покриттям у реальних промислових системах та скоригованих для типових перекриттів функцій.

Використовуючи спостережувану якість конверсії після першої ітерації донавчання (≈82% успішного перекладу в межах кожної функції), очікується, що система успішно конвертує приблизно 75,454 файли.

За ідентичних припущень очікується, що Ora2PG конвертує лише 47,764 файли. Це дає негайну позитивну різницю ≈27,690 успішно конвертованих файлів, що представляє завдання, які LLM може виконати автоматично, але Ora2PG не може.

Таким чином, навіть одна ітерація LLM донавчання ефективно усуває еквівалент майже року ручної роботи з міграції, значно зменшуючи витрати на робочу силу та терміни проєкту. Більше того, набір даних, використаний для досягнення цього покращення, 30K тренувальних зразків та 2K тестових зразків, було підготовлено лише за шість спринтів розробки одним SME, що означає, що LLM досяг економічно значущої продуктивності швидко та з помірними наглядовими зусиллями.

Ця робота представила комплексний framework для автоматизації міграції коду з Oracle на PostgreSQL за допомогою LLM. Запропоноване рішення інтегрує інженерію наборів даних, feature-aware статичний аналіз, retrieval-augmented generation, донавчання та надійну методологію оцінювання в єдиний ітеративний workflow. Було розроблено та проаналізовано три conversion pipeline: базовий Conversion pipeline, History-aware pipeline, що підтримує послідовний контекст перекладу, та два RAG pipeline (Strategy A/B), які отримують контекстну інформацію з баз знань різної структури. У всіх експериментах із сімействами моделей Qwen та GPT, LLM-based системи значно перевершили традиційний інструмент міграції Ora2PG.

Було створено масштабований evaluation framework для оцінки якості конверсії незалежно від LLM. Він включає NLP-метрики, інспекцію синтаксису, коректність фрагментів та точність пошуку. Всі результати логуються в MLflow для відтворюваності. Аналіз помилок показує, що донавчені моделі, особливо Qwen32B-ft2, досягають найнижчих показників синтаксичних помилок та найвищої ефективності конверсії файлів. Conversion та History pipeline показують найсильніші результати на гетерогенних SQL-навантаженнях.

Аналіз розподілу функцій, забезпечений HCFPE, квантифікує покриття функцій Oracle та PostgreSQL. Кореляційний аналіз демонструє, що донавчені моделі тісно узгоджуються з очікуваними розподілами функцій PostgreSQL, на відміну від інструменту на основі правил Ora2PG, який систематично недовиробляє ключові групи функцій.

Для підтримки безперервного вдосконалення було математично формалізовано GAP-based механізм оцінки набору даних, який ідентифікує недостатньо представлені або низькопродуктивні функції та визначає необхідну кількість нових зразків для наступної ітерації донавчання. Це забезпечує цільове зростання набору даних та ефективне залучення SME, включаючи безшовну інтеграцію нових SQL-функцій.

Загалом, цей framework встановлює науковий, практичний, масштабований та економічно вигідний підхід для модернізації баз даних корпоративного масштабу за допомогою LLM.