Устаревшие научные кодовые базы накапливаются десятилетиями, и когда первоначальные авторы уходят, заложенные в коде знания становится трудно восстановить. Более того, использование языков без активной экосистемы разработчиков означает упущенную возможность опираться на чужие наработки. Mistral помогла европейскому оператору энергетического сектора перенести 40 000 строк кода на Fortran 77 в C++ — это интенсивно использующий физические расчеты симулятор пласта без набора тестов и централизованной документации.
Выход за рамки простого перевода кода при модернизации устаревших систем.
Перевод синтаксиса с одного языка на другой — в значительной степени решенная задача. Если попросить любую современную модель перевести фрагмент с не совсем малоизвестного языка на другой, скорее всего, за несколько итераций удастся прийти к приемлемому результату. Однако миграция полноценной системы с процедурного языка на объектно-ориентированный C++ порождает потребность в архитектурном рефакторинге, что делает эту задачу нетривиальной.
Fortran 77 был стандартизирован в 1977 году, как можно догадаться по названию, и написанный на нем код напрямую отражает эти ограничения: никаких модулей, пространств имен и структурированных типов. Состояние хранится в блоках COMMON — глобальной памяти, разделяемой всей программой. Типы переменных неявно определяются по их первой букве, поэтому из-за опечатки в имени молча создается новая переменная, а не генерируется ошибка компилятора.
В качестве простого, но наглядного примера возьмем следующую реализацию разложения Тейлора первого порядка. Входные и выходные данные являются глобальными переменными в блоке COMMON, а переменная IC является целым числом только потому, что ее имя начинается с буквы в диапазоне от I до N. Имена переменных довольно загадочны, так как их длина ограничена 6 символами.
SUBROUTINE GASDEN
INCLUDE 'common.h'
DO 10 IC = 1, NCELL
10 RHOG(IC) = ROG(IV) + DROG(IV)*(P(IC)-PTAB(IV))
END
В C++ можно будет использовать явные типы, писать объектно-ориентированный код и возвращать значение через return вместо глобальной записи:
double gasDensity(const GasProperties& gas, double pressure) {
size_t i = lookup(gas.pressure, pressure);
return gas.density[i] + gas.slope[i] * (pressure - gas.pressure[i]);
Рассеянные массивы COMMON превращаются в единый параметр GasProperties, а цикл по сетке вынесен на уровень вызывающего кода, поэтому здесь нет поэлементного соответствия для проверки, что и усложняет верификацию миграции.
Эти структурные различия, а также необходимость интеграции современных фреймворков для научных вычислений (таких как PetSc), породили несколько важных вопросов еще до начала миграции:
- Как доказать, что мигрировавшая кодовая база совпадает с исходной в числовом выражении
Как доказать, что мигрировавшая кодовая база совпадает с исходной в числовом выражении
- Как разделить миграцию на управляемые части
Как разделить миграцию на управляемые части
- Как наилучшим образом использовать автономных агентов для ускорения процесса
Как наилучшим образом использовать автономных агентов для ускорения процесса
Создание инструментария паритета перед миграцией устаревшего кода.
Прежде чем задействовать агентов, нам нужен был способ доказать, что обе кодовые базы дают одинаковые результаты. Под «одинаковостью» здесь понималось числовое равенство выходных данных — как конечных результатов, так и набора критических промежуточных точек, указанных инженерами заказчика по разработке пластов.
Мы добавили:
- подпрограммы, позволяющие выгружать состояние кодовой базы на Fortran
подпрограммы, позволяющие выгружать состояние кодовой базы на Fortran
- тестовый фреймворк для загрузки контрольных точек в C++
тестовый фреймворк для загрузки контрольных точек в C++
файлы для направления агентов к их правильному использовании
В ходе рабочих процессов миграции агенты успешно внедрили в кодовую базу Fortran инструменты для дампов снимков состояния и использовали тестовый фреймворк C++ для проверки корректности перенесенных модулей.
Создание этой части инструментария на начальном этапе оказалось крайне выгодной инвестицией для проекта: оно сделало длительные запуски агентов более безопасными, а числовой паритет — это легко проверяемый и убедительный аргумент того, что фрагмент кода был успешно перенесен. Мы считаем, что это должно быть одним из первых шагов в любом проекте по модернизации кода.
Приведенный ниже пример иллюстрирует это. Сначала мы вставили в код Fortran строку для вывода значения переменной RHOG (в данном запуске оно составляло 42.71834), а затем использовали это же значение в качестве эталонной контрольной точки при тестировании перенесенного модуля C++.
Использование ИИ-агентов для понимания и документирования устаревших кодовых баз.
Документация проекта была разбросана по старым PDF-файлам и комментариям, спрятанным прямо в коде Fortran, и одним из главных побочных успехов всей работы стало приведение этой документации в порядок и размещение ее рядом с кодом.
К счастью, процедурный код вроде Fortran обладает удобным свойством: всю программу можно представить в виде единого дерева вызовов («вызывающий — вызываемый»). Мы сгенерировали это дерево, проанализировав кодовую базу с помощью пользовательского парсера, а затем использовали Vibe CLI, чтобы запустить более сотни агентов для его документирования. Каждый агент мог подтягивать соответствующие PDF-файлы через библиотеки документов и Mistral OCR.
Начав с листьев дерева и двигаясь вверх, каждый узел порождал субагента для своего документирования и создания PR (пулл-реквеста) в исходный репозиторий. Агент-ревьюер, работающий в цикле по расписанию cron, отслеживал появление новых PR, проводил их ревью и при необходимости планировал задачи по исправлению.
Использование ИИ-агентов для модернизации кода.
При первой попытке мы предоставили агентам полную автономность: по одному агенту на каждую подпрограмму на Fortran, и каждый независимо переводил свою функцию на C++ в течение недели. Результат оказался рабочим, но модернизацией кода это назвать было нельзя. Блоки COMMON превратились в глобальные структуры один к одному. Управляющие конструкции с оператором GOTO остались без изменений вместо того, чтобы быть переписанными в циклы или ранние возвраты. Это выглядело как Fortran, переписанный в синтаксисе C++, а не как модернизированный код.
Во второй попытке мы решили эту проблему, наделив агентов не просто автономностью, а структурой: планировщик, разработчик, тестировщик и ревьюер качества кода работали над каждым модулем совместно. Качество кода значительно выросло по сравнению с первой попыткой. Но сложность исходного кода в конце концов настигла агентов. Они сталкивались с багом, пытались внести несколько исправлений и останавливались, не имея возможности обратиться к кому-либо за вмешательством.
Мы пришли к золотой середине: человек управляет рабочим процессом, состоящим из агентов-разработчиков, тестировщиков и ревьюеров, выполняя миграцию кодовой базы модуль за модулем. Это позволило сохранить качество кода второй попытки и добавить этап проверки человеком, чтобы разблокировать агентов, когда они застревают. В следующем разделе этот рабочий процесс описан подробно.
Запуск структурированных рабочих процессов с ИИ-агентами для миграции сложного кода.
Когда кодовая база была задокументирована, а инструментарий паритета создан, осталась самая интересная часть — настройка степени автономности агентов с одновременным получением кода, готового к слиянию. Мы попробовали обе крайности: от полностью автономных запусков до жестко контролируемых ручных сессий. Структурированный рабочий процесс, описанный ниже, стал тем решением, к которому мы пришли для данного сценария использования.
Работая совместно с инженерами заказчика, мы использовали дерево вызовов для идентификации независимых модулей — самодостаточных поддеревьев управляемого размера (эмпирически — менее ~10 000 строк кода на Fortran). Каждый модуль проходил через один и тот же рабочий процесс:
- Сгенерируйте целевую архитектуру C++.
Сгенерируйте целевую архитектуру на C++.
- Согласуйте ее с инженером по разработке нефтяных и газовых месторождений.
Согласуйте ее с инженером по разработке нефтяных и газовых месторождений.
- После одобрения разбейте ее на очередь задач.
После одобрения разбейте ее на очередь задач.
- Запускайте подпроцесс реализации для каждой задачи: планирование → реализация → тестирование → повтор.
Запускайте подпроцесс реализации для каждой задачи: планирование → реализация → тестирование → повтор.
- Человек проверяет получившиеся PR и запрашивает изменения до тех пор, пока они не будут приняты.
Человек проверяет получившиеся PR и запрашивает изменения до тех пор, пока они не будут приняты.
Осознание пределов возможностей модернизации устаревшего кода с помощью ИИ.
Первый спринт охватил основной функционал: 40 000 строк из 300 000. Кодовая база на Fortran была самодостаточной и рабочей, что является благоприятным исходным условием. Миграции, зависящие от внешних систем, не имеющие рабочей базы для сравнения или кодирующие физические процессы, которые нигде не задокументированы, привнесут дополнительные сложности, не рассматриваемые в этой статье.
Применение трех принципов модернизации сложных устаревших систем.
Три урока из этого проекта применимы к любой миграции крупных устаревших систем.
- Создайте тестовый стенд для проверки эквивалентности до того, как писать код миграции — числовое совпадение является самым дешевым и убедительным доказательством того, что модуль готов.
Создайте тестовый стенд для проверки эквивалентности до того, как писать код миграции — числовое совпадение является самым дешевым и убедительным доказательством того, что модуль готов.
- Приведите документацию в порядок, прежде чем полагаться на агентов, так как нельзя мигрировать код, который никто не может прочитать.
Приведите документацию в порядок, прежде чем полагаться на агентов, так как нельзя мигрировать код, который никто не может прочитать.
- И в масштабах такого проекта структурированные рабочие процессы с этапами проверки человеком превосходят как полную автономность, так и ручные сессии под управлением человека.
И в масштабах такого проекта структурированные рабочие процессы с этапами проверки человеком превосходят как полную автономность, так и ручные сессии под управлением человека.
Мы нанимаем сотрудников!
Команда прикладного ИИ в Mistral — это группа инженеров, создающих полностековые решения на базе моделей Mistral и корпоративной платформы. Мы поставляем критически важные, специализированные решения для решения самых сложных проблем в мире.
Если вы хотите заниматься именно такой работой, подайте заявку на присоединение к нашей команде.
