В последние годы большие языковые модели (LLM) привлекли значительное внимание в области информатики, особенно в задачах, связанных с пониманием и генерацией программного кода. Их применение охватывает широкий спектр задач — от автоматического дополнения кода и его исправления до генерации комментариев и документации. Тем не менее, большинство существующих исследований сосредоточены на современных языках программирования и относительно небольших объемах кода. Что же происходит в случае с государственными информационными системами, где часто используются устаревшие языки, такие как MUMPS или ассемблерный код (ALC), а также большие в объеме и сложные проекты, превышающие контекстные окна коммерчески доступных моделей? Этот вопрос становится особенно актуальным в эпоху цифровой трансформации государственных служб и модернизации их программного обеспечения. Особенности работы с легаси-кодом Важный аспект, который отличает код, использующийся в государственных учреждениях, — это наследие языков программирования, которые практически не применяются в современной разработке.
MUMPS, ALC и другие устаревшие языки имеют не только специфический синтаксис, но и часто уникальную структуру программ и архитектуру данных. К тому же объём таких систем зачастую очень велик, что создает дополнительную сложность для моделей искусственного интеллекта с ограниченным размером контекстного окна. Многие современные LLM были обучены на обширных корпусах с примерами кода, но преимущественно на современных языках, таких как Python, Java, C++. Их способность обрабатывать и понимать синтаксис и семантику легаси-языков не была предметом широкого изучения. Крупные языковые модели и задаче разбиения кода Разбиение кода (code chunking) — процесс логического разделения больших объемов программного кода на меньшие части, которые проще анализировать, документировать и сопровождать.
Эта операция особенно важна в легаси-системах, где модули обладают большой плотностью и сложной взаимосвязью. Традиционно эту задачу выполняли эксперты, обладающие глубоким пониманием архитектуры и особенностей проекта. Работа таких специалистов требует значительных временных и человеческих ресурсов, что замедляет процессы сопровождения и модернизации ПО. С появлением LLM возник вопрос: могут ли эти модели эффективно выполнять функции, связанные с разбиением кода? Недавние исследования подтверждают, что LLM не только способны понимать структуру программных модулей, но и могут подбирать границы для разбиения, которые очень близки к решениям экспертов. Это открывает новые возможности для автоматизации процесса подготовки к модернизации программных систем.
Как разбиение кода влияет на документирование и сопровождение В современной практике сопровождающие разработчики уделяют большое внимание автоматическому созданию документации. Комментарии к модулям и функциям крайне важны для обеспечения прозрачности кода и его последующего понимания. Недостаточное или плохо структурированное документирование осложняет поддержку и развитие ПО. Исследования, проведенные с применением различных LLM, таких как GPT-4o, Claude 3 Sonnet, Mixtral и Llama 3, показывают, что качество генерируемой документации напрямую зависит от выбранного метода разбиения кода. Более того, при использовании LLM-автоматизированных методов разбиения качество создаваемых комментариев повышается: они становятся на 20% точнее по фактам и на 10% полезнее для конечных пользователей.
Влияние технологий на модернизацию административного ПО Модернизация государственного программного обеспечения является приоритетным направлением, так как позволяет повысить эффективность работы и безопасность критически важных систем. Возможность применять LLM для автоматического разбиения больших кусков кода и сопровождающего документооборота снижает издержки, связанные с привлечением экспертов в легаси-языках. Это, в свою очередь, ускоряет процесс перехода на современные платформы и технологии, минимизируя риски ошибок и потерь данных. Будущее LLM в сопровождении кода Несмотря на обнадеживающие результаты, важно отметить, что большие языковые модели не являются универсальным решением. Они требуют тщательной настройки и интеграции в существующие рабочие процессы, а также контроля качества на каждом этапе.
