Исследование способов генерации программного кода для REST API приложений

Содержание

1. Обзор методов
2. Использование готовой LLM через API
3. Создание собственной модели с обучением
4. Использование стандартных подходов
5. Сравнение методов
6. Гибридный метод
7. Заключение

Современная разработка программного обеспечения характеризуется растущими требованиями к скорости создания и качеству программных продуктов. REST API приложения, являющиеся основой большинства веб-сервисов и микросервисных архитектур, требуют значительного количества времени на разработку.

Автоматическая генерация программного кода по естественно-языковым описаниям представляет собой перспективное направление, способное кардинально изменить подходы к разработке программного обеспечения. Появление больших языковых моделей (LLM) и развитие технологий машинного обучения открыли новые возможности для решения задач автоматизации программирования.

В данной статье проводится анализ различных подходов к генерации программного кода по текстовому описанию пользователя. В частности, рассматриваются следующие методы:

• использование готовой LLM через API;
• создание собственной модели с обучением;
• использование стандартных алгоритмов генерации без применения нейросетевых технологий.

1. Обзор методов

1.1 Использование готовой LLM через API

Данный метод основан на использовании готовых больших языковых моделей через API провайдеров. Из перспективных вариантов можно выделить следующие решения:

• OpenAI (GPT);
• Yandex AI (YandexGPT);
• Sber AI (GigaChat).

OpenAI представляли семейство моделей GPT-4.1, специально оптимизированных для задач программирования. Модели показывают значительное улучшение в бенчмарке SWE-bench Verified с повышением производительности на 21.4% по сравнению с GPT-4o и 26.6% по сравнению с GPT-4.5, что делает их лидерами в области программирования.

Ключевые особенности:

• обновленная база знаний с кодом до июня 2024 года;
• контекстное окно до 1 миллиона токенов — самое большое среди рассматриваемых решений;
• Мультимодальные возможности (текст + изображения);
• Поддержка структурированного вывода (JSON);
• Интеграция с внешними инструментами через function calling;
• Специализированная оптимизация для задач программирования.

Yandex выпустили уже пятое поколение своих языковых моделей с двумя вариантами: YandexGPT 5 Pro для сложных задач и YandexGPT Lite для быстрых ответов. Модель 5 Pro показывает себя лучше, чем предыдущее поколение в 67% случаев, особенно в понимании сложных инструкций и работе с внешними источниками.

Ключевые особенности:

• специализированные классификаторы;
• возможность fine-tuning модели (Preview);
• работа с внешними API через вызов функций;
• поддержка потоковой генерации;
• соответствие требованиям 152-ФЗ и ISO стандартам;
• корпоративная поддержка.

У Sber есть обновленная версия GigaChat 2.0, которая, согласно бенчмарку MERA, превосходит международные модели GPT-4o, DeepSeek-V3, LLaMA 70B и Qwen2.5 по метрикам для русского языка и занимает первое место.

Ключевые особенности:

• высокая производительность на русском языке;
• доступ к данным в реальном времени из интернета;
• работа с текстом и изображениями;
• генерация музыки и вокала;
• локальное хранение данных в РФ;
• соответствие требованиям 152-ФЗ.

Использование одного из перечисленных решений устраняет потребность в разработке собственного, что, в свою очередь, экономит время и ресурсы. Этот подход может способствовать более быстрой разработке конечного программного продукта, но делает его зависимым от внешних факторов и лишает гибкости в реализации. Также нужно осознавать факт того, что использование внешнего ресурса вынуждает передавать запросы пользователей третьей стороне, а это не во всех случаях может быть приемлемо. Для сравнения решений была составлена следующая таблица:

OpenAI могут выделиться более хорошим результатом модели GPT-4o в тесте на пригодность к программированию (Human Eval). Однако их API не поддерживают работу с большим списком регионов, в который входит Российская Федерация, а это накладывает еще большие трудности для разработки и последующей работы всего проекта. Также у них отсутствует возможность развернуть модель локально.

Yandex и Sber при работе с их API соблюдают закон о персональных данных и, кроме того, они могут предложить развернуть их модели внутри вашей компании, если в этом есть необходимость. Их модели специализируются на работе с русским языком, что должно способствовать лучшему пониманию контекста запроса от русскоязычного пользователя.

Учитывая специфику работы с LLM от сторонних компаний разработчиков, можно сделать вывод, что нужно прибегать к использованию наиболее надежного варианта. В современных реалиях желательно отдать предпочтение отечественному программному обеспечению, которыми являются YandexGPT и GigaChat. Важно отметить, что производительность в задачах генерации кода может значительно варьироваться в зависимости от языка программирования, сложности задачи и качества промптов. Для принятия окончательного решения рекомендуется провести практическое тестирование.

1.2 Создание собственной модели с обучением

Разработка собственной специализированной модели для генерации программного кода приложений представляет собой комплексный процесс, требующий время и значительных ресурсов. Данный подход позволяет создать модель, точно настроенную под специфические требования проекта, однако сопряжен с высокими рисками и неопределенностью результата. Процесс создания собственной модели включает в себя следующие ключевые этапы:

    1. подготовка датасета;

    2. проектирование архитектуры;

    3. обучение и оптимизация.

Подготовка датасета сам по себе самый трудный этап в разработке, а учитывая специфику генерации программного кода, задача усложняется в разы. Датасет должен содержать парные данные состоящие из текстового запроса и соответствующего им кода. Примеры кода для обучения модели должны представлять разнообразные архитектуры паттернов, множество языков и различные типы операций. Для эффективного обучения содержимое датасета должно быть достаточно большим и может насчитывать сотни тысяч пар данных. Конкретное количество назвать сложно, так как все зависит от множества факторов, среди которых общее качество датасета, уникальность пар в датасете и производительность архитектуры обучаемой модели в области программирования.

Даже крупные технологические компании сталкиваются с серьезными вызовами на этом этапе. OpenAI для обучения CodePilot пришлось нанимать команду программистов для написания эталонного кода, что значительно увеличило стоимость проекта.

Для генерации кода наиболее эффективной архитектурой является Трансформер (Transformer-based), которая включает в себя Encoder-Decoder и Decoder-only модели.

Encoder-Decoder модели:

• encoder обрабатывает текстовый запрос;
• decoder генерирует соответствующий программный код;
• преимущества: высокое качество генерации, возможность контролировать длину выхода;
• недостатки: высокие требования к вычислительным ресурсам.

Decoder-only модели (GPT-подобные):

• объединение спецификации и кода в единую последовательность;
• использование специальных токенов для разделения контекстов;
• преимущества: простота архитектуры, возможность fine-tuning существующих моделей;
• недостатки: сложность контроля длины генерируемого кода;
• также существуют гибридные архитектуры, которые могут сочетать в себе использование уже предобученной модели для понимания естественного языка, специализированного энкодера для обработки структурированных данных и модуля валидации для проверки корректности генерируемого кода.

Наконец, модель нужно обучить на дадатсете, полученом на первом этапе. Обучение может занять несколько суток и потребует мощности нескольких производительных графических ускорителей. Мощности графических ускорителей можно арендовать на срок обучения моделей и её оптимизации. Время обучения сильно зависит от размера датасета, требований модели к вычислительным ресурсам и стратегии самого обучения.

Для обучения модели можно использовать следующую поэтапную стратегию:

    1. предобучение на общем корпусе кода (GitHub, Stack Overflow);

    2. fine-tuning на специализированном датасете (REST API);

    3. обучение с подкреплением на основе обратной связи с человеком (RLHF) для улучшения качества.

В результате вариант создания собственной модели потребует определено немалое количество времени, а также дополнительных финансовых вложений при сборе датасета и аренде производительных серверов для обучения. Самое главное, что нет четкой гарантии удовлетворительного результата и может потребоваться неоднократное повторение всех этапов до достижения требуемой точности генерации.

1.3 Использование стандартных подходов

Классические подходы к генерации программного кода подразумевают под собой заранее описанные алгоритмы, которые приводят довольно к предсказуемым результатам. В контексте генерации REST API приложений можно выделить следующие основные решения:

    1. шаблонное программирование;

    2. синтаксический анализ и DSL (Domain-Specific Language);

    3. онтологии и базы знаний.

Шаблонное программирование представляет собой методологию генерации кода на основе предварительно созданных шаблонов с переменными параметрами. Основными алгоритмами в данном подходе являются:

Алгоритм подстановки параметров:

    1. парсинг входных данных (схема API, конфигурация);

    2. извлечение параметров генерации;

    3. применение шаблонов с подстановкой значений;

    4. постобработка сгенерированного кода.

Алгоритм композиции шаблонов:

    1. декомпозиция сложных структур на базовые компоненты;

    2. применение иерархических шаблонов;

    3. сборка компонентов в целостную структуру;

    4. оптимизация результирующего кода.

DSL-подходы основаны на создании специализированных языков для описания API и последующей трансляции в исполняемый код.

Алгоритм трансляции DSL:

    1. лексический анализ DSL-спецификации;

    2. синтаксический анализ и построение абстрактного синтаксического дерева (AST);

    3. семантический анализ и валидация;

    4. генерация целевого кода на основе AST;

    5. оптимизация и форматирование результата.

Типы DSL для REST API:

• декларативные DSL - описывают "что" должно быть сгенерировано (OpenAPI, RAML);
• императивные DSL - описывают "как" сгенерировать код (Gradle DSL, Maven DSL);
• гибридные DSL - сочетают декларативные и императивные элементы;
• подход онтологий и баз знаний основан на формализации знаний о предметной области REST API в виде онтологий и применении правил вывода для генерации кода.

Алгоритм онтологической генерации:

    1. загрузка онтологии предметной области;

    2. анализ требований пользователя;

    3. применение правил вывода;

    4. формирование модели решения;

    5. генерация кода на основе модели.

Как ранее было упомянуто, данные решения имеют предсказуемые результаты на выходе, что является их плюсом и в то же время минусом. Код, полученный в результате генерации такими методами, проще всего протестировать и его работоспособность гарантирована. Также важными преимуществами являются высокая скорость генерации и низкие затраты ресурсов на нее.

Однако, здесь присутствуют проблемы в виде ограниченной гибкости, сложной поддержки и качестве результата. Все упирается в шаблоны, которые нужно создавать под все возможные случаи. Не каждый шаблон может быть оптимальным для конкретного запроса пользователя, а все потребности пользователя трудно предсказать. В результате пользователь, кроме того, что ограничен в способен задания параметров генерации, так еще имеет вероятность получить результат, не оптимизированный под его задачи и не соответствующий стандартам разработки ПО.

2. Сравнение методов

В обзоре методов генерации кода были рассмотрены их возможности применения и выявлены преимущества с недостатками. По результатам обзора можно составить следующую сравнительную таблицу:

По таблице можно сделать вывод, что применение сторонних LLM через API провайдера оптимально в сценариях, где приоритетом является скорость внедрения решения и есть достаточный бюджет на регулярные затраты. Кроме того, данный метод эффективен, когда требуется высокое качество генерируемого кода, а конфиденциальность данных имеет низкий приоритет. Такой подход желательно использовать для быстрой проверки спроектированных концептов, чтобы получить первые результаты, но при этом он пригоден и для внедрения в итоговый программный продукт.

Создание и обучение собственной модели обосновано в случаях повышенных требований к информационной безопасности. Этот метод становится экономически целесообразным, когда совокупная стоимость разработки и поддержки собственного решения оказывается ниже операционных затрат на использование внешних API. Такой подход требует долгосрочного планирования и инвестиций в развитие технологической экспертизы, но обеспечивает полный контроль над разработкой и возможность непрерывного улучшения модели.

Классические методы генерации кода остаются актуальными в условиях ограниченного бюджета, когда инвестиции в современные AI-решения не оправданы масштабом задач. Традиционный методы оптимально подходят для решения простых, повторяющихся задач с четкой логикой, где не требуется высокая адаптивность и творческий подход к генерации. Преимуществом данного подхода является максимальная предсказуемость результатов и полная детерминированность процесса генерации.

3. Гибридный метод

Анализ рассмотренных подходов показывает, что каждый метод имеет свои сильные стороны и ограничения. Гибридный подход представляет собой интеграцию различных методов генерации кода в единую систему, которая динамически выбирает оптимальный способ решения задачи в зависимости от её специфики и контекста.

Гибридная система генерации кода для REST API приложений может состоять из нескольких ключевых компонентов.

    1. Центральный координатор:
        ◦ анализирует входящие запросы пользователей;
        ◦ принимает решения о выборе метода генерации;
        ◦ координирует работу различных генераторов кода;
        ◦ обеспечивает интеграцию результатов от разных компонентов.
    2. Анализатор запросов:
        ◦ парсит естественно-языковые описания;
        ◦ извлекает ключевые параметры и требования;
        ◦ классифицирует задачи по сложности и типу;
        ◦ определяет контекстуальные зависимости.
    3. Модуль выбора стратегии:
        ◦ реализует алгоритмы выбора оптимального метода;
        ◦ учитывает метрики производительности и качества;
        ◦ адаптируется к пользовательским предпочтениям;
        ◦ поддерживает механизм обратной связи.
    4. Генераторы кода:
        ◦ LLM API Gateway: интерфейс для работы с внешними языковыми моделями;
        ◦ Local Model Engine: локальная специализированная модель;
        ◦ Template Engine: система шаблонной генерации;
        ◦ Hybrid Compositor: компонент для объединения результатов.
    5. Система валидации и оптимизации:
        ◦ статический анализ сгенерированного кода;
        ◦ проверка соответствия стандартам;
        ◦ оптимизация производительности и читаемости;
        ◦ интеграция с системами тестирования.

Гибридный подход позволяет компенсировать недостатки одного метода преимуществами другого. Например, высокая стоимость LLM API может быть снижена за счет использования шаблонной генерации для стандартных компонентов. Система автоматически распределяет задачи между методами в зависимости от их эффективности для конкретных типов операций, что приводит к оптимальному использованию вычислительных ресурсов и бюджета. Возможность отката на альтернативные методы генерации повышает общую надежность системы. Если один метод недоступен или дает неудовлетворительные результаты, система может переключиться на другой.

Гибридный метод представляет собой более продвинутое решение в области автоматической генерации кода, объединяющую лучшие аспекты различных методов. Правильная реализация такой системы может значительно повысить эффективность разработки REST API приложений, снизить затраты и улучшить качество получаемого кода.

Заключение

Каждый из рассмотренных методов генерации кода имеет свои преимущества и области применения:

• LLM API решения демонстрируют наивысшее качество генерируемого кода и максимальную гибкость, но требуют постоянных операционных затрат и создают зависимость от внешних провайдеров;
• собственные модели обеспечивают полный контроль над процессом генерации и долгосрочную экономическую эффективность, но требуют значительных первоначальных инвестиций и высокой технической экспертизы;
• традиционные методы гарантируют предсказуемость результатов и минимальные затраты, но ограничены в гибкости и адаптивности.

Ключевые факторы, влияющие на выбор подхода:

• масштаб и сложность проекта;
• бюджетные ограничения и модель финансирования;
• требования к информационной безопасности;
• доступность технической экспертизы;
• временные рамки внедрения.

Автоматическая генерация программного кода для REST API приложений находится на пороге широкого практического применения. Развитие технологий искусственного интеллекта и появление эффективных языковых моделей создают предпосылки для революционных изменений в процессах разработки программного обеспечения.

Успешное внедрение систем автоматической генерации кода требует взвешенного подхода к выбору технологий, учета специфики проекта и стратегического планирования развития технологической экспертизы организации. Гибридные решения, объединяющие преимущества различных подходов, представляют собой наиболее перспективное направление для практического применения.

Источники

    1. https://openai.com/index/gpt-4-1/
    2. https://ya.ru/ai/gpt
    3. https://sber.pro/publication/sber-predstavil-obnovlyonnuyu-neiroset-gigachat-20/
    4. https://textcortex.com/post/gpt-4o-review
    5. https://habr.com/ru/companies/bothub/articles/893128/
    6. https://habr.com/ru/companies/sberdevices/articles/890552/
    7. Nijkamp, E., Pang, B., Hayashi, H., Tu, L., Wang, H., Zhou, Y., ... & Xiong, C. (2022). CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. arXiv preprint arXiv:2203.13474.
    8. https://systems-analysis.ru/wiki/Архитектуры_LLM