MAS4SysML: Многоагентный фреймворк для генерации моделей SysML v2 с естественного языка

Summary

Этот протокол представляет собой MAS4SysML — многоагентный подход, который автоматически генерирует код SysML v2 через скоординированное разделение задач, требующий минимальных итераций ремонта и значительно сокращая время ручного моделирования, одновременно повышая эффективность моделирования системы.

Abstract

Автоматическая генерация точных моделей SysML на основе требований естественного языка может значительно ускорить внедрение инженерии систем на основе моделей (MBSE) в разработке сложных систем. Однако использование крупных языковых моделей (LLM) для генерации кода часто не соответствует строгим синтаксическим ограничениям формальных языков моделирования, и стабильное обеспечение семантического согласования между сгенерированными моделями и требованиями остаётся сложным. Для решения этих проблем в статье представлен MAS4SysML — многоагентный коллаборативный фреймворк для генерации кода SysML v2, который улучшает синтаксическую корректность и семантическую согласованность при ограниченном бюджете на ремонт. Фреймворк разбивает задачу моделирования на иерархические подзадачи, формализует их в виде структурированных карт задач и генерирует код модели снизу вверх. Во время генерации используется официальная среда валидации для диагностики синтаксиса; После завершения фреймворк проверяет семантическую согласованность между кодом и карточками задач. Если синтаксисная или семантическая проверка не удаётся, фреймворк итеративно ремонтирует и повторно валидирует код в рамках заранее определённого бюджета ремонта, руководствуясь диагностической обратной связью, пока критерии валидации не будут выполнены или бюджет не исчерпается. Для оценки предлагаемого метода мы создаём набор данных SysML v2, охватывающий пять основных типов задач — требования, сценарии использования, структуру, параметры и автоматы состояний — и проводим сравнительные эксперименты. Результаты показывают, что MAS4SysML снижает средний уровень синтаксической ошибки до 2,63, увеличивает семантическое сходство до 0,91 и превосходит существующие методы генерации кода в целом.

Introduction

MBSE стал ключевой методологией для анализа требований, проектирования архитектуры системы и планирования верификации при разработке сложного оборудования в таких областях, как авиация и аэрокосмическая^{отрасль 1}. Используя унифицированные языки моделирования, такие как SysML, в качестве основы моделирования, информация — включая требования, структуру, поведение и ограничения — может быть организована в целостную модельную структуру, что улучшает структуру процессов и эффективность междисциплинарного сотрудничества². Однако по мере роста масштаба системы количество моделей, которые необходимо разработать, соответственно увеличивается, что приводит к устойчивому росту нагрузки по ручному моделированию SysML. Кроме того, моделисты должны работать в условиях строгих синтаксических и методологических ограничений, требующих значительных знаний и навыков абстракции. Эти факторы стали серьёзным узким местом для инженерного внедрения^{MBSE 3}.

В последние годы LLM продемонстрировали сильные возможности в понимании естественного языка, структурированном представлении информации и генерации кода, открывая новые возможности для автоматизации моделирования MBSE от естественного языка к коду^{модели 4}. Предыдущие исследования изучали прямую генерацию кода модели SysML с использованием^{LLMs 5}. Тем не менее, серьёзные трудности остаются. С синтаксической точки зрения система типов, механизмы охвата и семантика ссылок в SysML регулируются строгими формальными ограничениями и часто более сложны, чем у универсальных языков^{программирования 6}. Семантически LLM могут не полностью отражать поведенческую логику, структурные связи и межслойные ограничения, что приводит к отсутствующим отношениям, логическим несоответствиям или неполным^{моделям 7}. Эти ограничения препятствуют надёжности, управляемости и интерпретации подходов прямой генерации.

Для решения этих проблем в этой статье представлен MAS4SysML — фреймворк генерации кода SysML v2, включающий четыре роли агентов. Вместо прямого нацеливания на создание полной модели системы с перекрёстным видом в один раз, это исследование сосредоточено на генерации и итеративном восстановлении нескольких репрезентативных задач моделирования SysML v2. Основанный на декомпозиции задач и структурированных карточках задач, а также интеграции генерации кода, синтаксической диагностики на уровне инструментов и проверки семантической согласованности, MAS4SysML создаёт замкнутый рабочий процесс генерации, проверки и ремонта. Эта конструкция улучшает синтаксическую корректность, семантическую согласованность и структурную полноту сгенерированного кода при ограниченном бюджете на ремонт.

Основные вклады обобщены следующим образом: (1) Фреймворк MAS4SysML. Мы предлагаем MAS4SysML — многоагентный фреймворк, управляемый LLM, который позволяет генерировать сквозную генерацию от требований на естественном языке до исполняемого кода модели SysML v2, предоставляя практический путь для снижения стоимости моделирования и повышения эффективности моделирования. (2) Парсинг задач и двойная валидация. Мы вводим механизм разбора дерева задачи-структура и двойственную схему валидации (синтаксис и семантику). В парсинге задач цели моделирования иерархически разлагаются и формализуются в структурированные карточки задач. Для валидации синтаксическая диагностика использует официальную валидационную^{среду 8} для проверки сгенерированного кода и возвращения диагностики, ориентированной на исправление, в то время как семантическая валидация использует ключевые поля в карточках задач в качестве ссылок для оценки общей согласованности между сгенерированной моделью и целями моделирования. (3) Экспериментальная оценка. Мы проводим сравнительные эксперименты с использованием уровня синтаксических ошибок и оценки семантической согласованности в качестве основных метрик. Результаты показывают, что MAS4SysML снижает средний уровень синтаксической ошибки до 2,63 и увеличивает семантическое сходство до 0,91, превосходя базовые методы по точности генерации и автоматизации.

Protocol

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

Фаза I: Анализ задач
Рабочий процесс начинается с разбора задач. Система предоставляет намерение моделирования на естественном языке для агента генерации структуры задач, который выводит набор карт задач. Чтобы следующие поколения были исполняемыми и воспроизводимыми, каждая карта задачи должна содержать, как минимум, (i) идентификатор задачи, (ii) зависимости и (iii) ключевую информацию о моделировании для валидации, такую как цель моделирования, ограничения/граничные условия, слоты параметров и значения инстанцирований, а также ожидаемые выходы. Этот этап выводит task_card_set, который служит единой основой для последующего генерации кода модели.

Фаза II: Итеративная генерация кода
При итеративной генерации система инициализирует контекст кода prev_code в пустое состояние и последовательно генерирует код для каждой карты задачи в порядке, определяемом полями зависимостей. Для каждой карты задачи агент генерации кода принимает текущую карту задачи и контекстный код в качестве входа для получения candidate_code и сразу вызывает модуль проверки синтаксиса. Модуль проверяет код с использованием официальной среды проверки SysML v2 и возвращает результаты диагностики. Если валидация проходит успешно, candidate_code используется для обновления prev_code и поддерживает последующее поколение. Если проверка не удаётся, активируется агент восстановления кода, который выполняет минимальные, целенаправленные правки, руководствуясь возвращённой диагностикой, после чего восстановленный код повторно отправляется на повторную валидацию. Этот цикл повторной валидации ремонта ограничен максимальным бюджетом ремонта_{K max}. Если валидация проходит в рамках бюджета, проходящая версия обновляет prev_code; в противном случае, после попыток K_max система фиксирует сбой и продолжает последующий процесс с использованием последней отремонтированной версии в качестве prev_code , чтобы избежать блокировки рабочего процесса при сохранении контекстной непрерывности.

Фаза III: Семантическая валидация
После генерации кода для всех карт задач рабочий процесс переходит к семантической валидации. Агент семантической валидации оценивает согласованность между конечным кодом и намерением моделирования, используя ключевые поля в task_card_set в качестве ссылок и выводит результаты семантической валидации. Если валидация проходит успешно, prev_code принимается как окончательный код модели SysML v2. В противном случае система генерирует отчёт о семантическом отклонении, который выявляет невыполненные поля карты задач и необходимую область ревизии. Затем агент по восстановлению кода корректирует код и выводит пересмотренный код модели в итоге.

Архитектура и методология модели
Архитектура модели
Фреймворк MAS4SysML, иллюстрированный на рисунке 1, состоит из четырёх совместных агентов: агента генерации структуры задач, агента генерации кода, агента восстановления кода и агента семантической валидации. Соответствующие шаблоны запросов показаны на рисунке 2.

Агент генерации структуры задач выполняет семантический анализ намерения входного моделирования и генерирует исполняемые структурированные карты задач. Сначала применяется механизм иерархической декомпозиции задач (см. иерархический механизм декомпозиции) для разложения общей цели моделирования на узлы задачи с чётко определёнными семантическими границами, а затем строит структурированную карту задач для каждого узла. Далее карты задач упорядочены по полям зависимостей моделирования, чтобы обеспечить соответствие последовательности выполнения с конечной структурой кода, тем самым закладывая основу для генерации кода снизу вверх, основанной на глобальной цели моделирования.

Агент генерации кода постепенно генерирует код, совместимый с SysML v2, в соответствии с зависимостями моделирования. Опираясь на артефакты кода, созданные родительскими задачами, агент выполняет соответствующие операции генерации кода на основе требований, указанных в каждой карте задач, что позволяет поэтапно строить процесс — от локальных компонентов до полной модели.

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

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

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

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

TC = {id,O,N,K,P,V,C,D} (1)

Если id — это уникальный идентификатор узла задачи, O — цель задачи, N — описание задачи на естественном языке, то K обозначает основные семантические элементы SysML v2, которые могут быть вовлечены в задачу, главным образом требования def/требование, part def/part, port def/port, item def, attribute def/attribute и state/transition. Взаимосвязи между этими элементами в первую очередь выражаются через соединение (структурные соединения), входные/выходные элементы на портах (информационные/материальные потоки) и условия триггеров/защиты переходов в машине состояний (например, команды, состояние здоровья и пороговые ограничения), C как семантические правила или граничные условия, P как параметризуемые слоты внутри задачи, такие как имена атрибутов, типы данных или составные типы, V — это инстанцированные значения для каждого слота, а D — моделирование зависимостей между задачами, где depend_on указывает необходимые выходы от других задач до генерации текущего кода, предоставляет — обозначает выходы, полученные после завершения задачи, а потребляет — представляет внешние входы, необходимые задаче.

Модуль валидации синтаксиса
Модуль проверки синтаксиса создан на основе пилотной реализации SysML v2. Используя парсер и валидатор, модуль анализирует и проверяет синтаксическую корректность сгенерированного кода модели SysML v2. Критерии валидации модуля в основном основаны на спецификации языка SysML v2, а также из грамматических правил, правил разрешения области и связанных механизмов проверки ограничений, реализованных в инструменте Pilot. В частности, валидация проверяет, являются ли объявления элементов корректными, полны ли блочные структуры, валидны ли аннотации типов, можно ли успешно разрешить имена и ссылки, а также соответствуют ли моделирующие конструкции, такие как порты, соединения, состояния и переходы, требованиям языка.

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

e₁ = (тип_i, pos_i, msg_i) (2)

Где e_i обозначает список обнаруженных проблем для текущей задачи моделирования, каждая запись содержит тип _{ошибки i}, место ошибки pos_i и диагностическое сообщение_msg i .

Например, если сгенерированный код содержит синтаксическую ошибку, например «атрибут не отображён определением атрибута», модуль валидации возвращает следующее диагностическое сообщение:

'type' : 'error'
'message': 'ОШИБКА: Атрибут должен быть введён по определению атрибута.' (3)
'Позиция' : 'Строка 7 Колонка: 3'

Когда результат валидации e i ≠ 0, собранная информация об ошибке e_i пересылается агенту по восстановлению кода для дальнейшей корректировки. Таким образом, процесс исправления кода не является неограниченной процедурой модификации, а целенаправленной редакцией, управляемой явной диагностической информацией, возвращаемой парсером и валидатором.

Механизм семантической валидации
Механизм семантической валидации использует ключевые поля карт задач, которые явно и прослеживаются в соответствии с кодом модели, в качестве семантических якорей. Он оценивает семантическую согласованность на уровне модели, тем самым предоставляя явные, применимые критерии для последующего ремонта модели. В частности, для каждой карты задачи_{TC i} в качестве ключевых семантических ссылок используются следующие поля: (i) цель моделирования O_i, (ii) семантические ограничения и граничные условия C_i, (iii) инстанцированные значения слотов параметров V i и (iv) ожидаемые выходы после выполнения задачи D_i['предоставить']. Эти поля накладывают дополняющие семантические ограничения на сгенерированную модель с разных точек зрения: реализация намерения моделирования, удовлетворение ограничений, согласованность инстанции параметров и полнота результатов модели — что позволяет принимать принципиальное решение о том, удовлетворяет ли код модели требованиям моделирования без необходимости дополнительных предположений.

Основываясь на этих ключевых полях, мы определяем многополовую семантическую функцию принятия решений по несогласованности:

(4)

где I(·) обозначает индикаторную функцию, равную 1, если все функции подрешения внутри скобок выполняются, и 0 в противном случае. Это бинарное решение явно различает состояния удовлетворения требований моделирования и необходимости дальнейшего ремонта, обеспечивая детерминированное условие триггера для последующего процесса семантического ремонта. Общее решение совместно определяется следующими четырьмя функциями подрешения:

(1) Моделирование объективной согласованности:

Φ₀ (TC_{i,c f}) = I(состав(c _{f,0 i})) (5)

где Consist(_{c f,0 i}) указывает, является ли код модели c f семантически согласованным с целью моделирования_{0 i}, указанной в карточке задач.

(2) Удовлетворение семантических ограничений:

Φ_c (TC_{i,c f}) = I(Удовлетворительно(c_{f,C i})) (6)

где Satisfy(_{c f,C i}) указывает, удовлетворяет ли код модели c f семантическим ограничениям и граничным условиям C_i, указанным в карточке задач.

(3) Согласованность параметров:

Φ_c (TC_{i,c f}) = I(Мгновенно(_{c f,V i})) (7)

где Instant(_{c f,V i}) указывает, отражаются ли инстанцированные значения параметров V i в карте задачи в коде модели.

(4) Согласованность выхода:

(8)

где Artifacts(_{c j}) указывает, присутствуют ли выходы, ожидаемые картой задачи, в конечном коде модели, служа мерой полноты сгенерированного результата.

Эти суждения о согласованности реализуются агентом семантической валидации с помощью семантических возможностей понимания LLM; Внутренний процесс рассуждения агента не изменяет формальное определение или использование функции согласованности.

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

Экспериментальные данные и оценка
Экспериментальные данные
Код модели SysML v2 — это не обычный программный код; Её созданные артефакты обладают характерными чертами формального моделирования. Различные взгляды обычно включают отдельные категории элементов основного моделирования, такие как требования, части, порты, атрибуты, состояния и переходы, которые существенно различаются стилями объявлений, организационными формами и структурой композиции. Кроме того, код модели должен удовлетворять множеству ограничений, включая ссылки на типы, иерархическое вложение, ограничения связей и семантическое повторное использование между элементами.

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

Каждый тип представления модели содержит 15 экземпляров моделей, созданных вручную, в результате чего получается набор данных N = 75 моделей SysML v2. Набор данных охватывает несколько инженерных областей, включая аэрокосмические, автомобильные, медицинские и системы умного дома, и все модели успешно прошли официальную валидационную среду SysML v2, обеспечив строгое синтаксическое соответствие.

Впоследствии мы сгенерировали соответствующее описание намерений моделирования на естественном языке для каждой модели. Для повышения эффективности строительства мы использовали шаблон запросов, показанный в дополнительном файле 2 , и применили GPT-4o для создания начальных описаний. GPT-4o был выбран за сильное понимание семантики и возможности по извлечению информации, что позволяет точно фиксировать элементы основной модели без галлюцинаций и генерировать описания намерений моделирования, похожие на человека.⁹. Для обеспечения точности и устранения неоднозначности все сгенерированные описания вручную проверялись и уточнялись исследователями с опытом в системной инженерии. Репрезентативные примеры для различных типов моделей приведены в Таблице 1.

Метрики оценки
Мы используем следующие три ключевых метрики для оценки качества сгенерированного кода модели SysML v2:

Средний уровень синтаксической ошибки (SER)
Эта метрика количественно определяет долю синтаксических ошибок, обнаруженных при проверке сгенерированного кода модели по официальным правилам синтаксиса SysML v2. Он вычисляется следующим образом:

(9)

где E_i обозначает количество синтаксических ошибок, выявленных в i-й генерируемой модели. Эта метрика отражает степень соответствия сгенерированного кода модели формальной спецификации синтаксиса SysML v2.

Оценка семантической согласованности (SCS)
Эта метрика оценивает, насколько точно и всесторонне сгенерированный код модели отражает семантический смысл, выраженный в спецификациях моделирования на естественном языке. В частности, мы извлекаем семантические единицы из намерения моделирования — такие как системные сущности, участвующие компоненты, основные функции или поведенческие сценарии, а также ключевые условия или ограничения — и сравниваем их с семантическими единицами, присутствующими в сгенерированном коде модели. Семантическая согласованность вычисляется следующим образом:

(10)

где U — множество семантических единиц, извлеченных из намерения моделирования, а — множество семантических единиц, идентифицированных в сгенерированном коде. указывает количество единиц, правильно зафиксированных сгенерированным кодом модели. Более высокое значение SCS указывает на более сильное семантическое покрытие и согласованность.

Оценка качества человека
Традиционные автоматизированные метрики, такие как BLEU и CodeBEU, в первую очередь оценивают поверхностное сходство или исполняемость кода, но не фиксируют, действительно ли модель понимает или правильно выражает предполагаемую семантику моделирования. Эти метрики ограничены в оценке семантической согласованности, полноты ключевых элементов и согласованности с намерением^{моделирования 10}. В отличие от этого, человеческая оценка может более точно выявлять такие проблемы, как отсутствие семантических элементов, логические несоответствия, структурная избыточность или необоснованные галлюцинации, обеспечивая более надёжную^{оценку 11}. Вдохновлённые этими ограничениями, мы разрабатываем человеческую оценочную рамку для сгенерированных моделей SysML v2, состоящую из трёх критериев: (1) Корректность: сгенерированная модель должна точно отражать намерение моделирования, сохранять структурную и логическую согласованность с целями задачи и не содержать семантической неоднозначности, отсутствующих элементов или ошибочных расширений. (2) Читаемость: код модели должен быть понятным и лёгким для понимания, с последовательным именованием, согласованной структурой и хорошо организованной иерархией, поддерживающей инспекцию и последующее обслуживание. (3) Целостность: модель должна обладать полной структурной логикой, согласованными межэлементными ссылками и отсутствием неопределённых типов или сломанных цепочек зависимостей, что обеспечивает её использование для анализа и интеграции в дальнейшем потоке. Мы пригласили исследователей с опытом моделирования SysML оценивать каждую сгенерированную модель по трёхбалльной шкале, где 1 означает самое низкое качество, а 3 — самое высокое. Во время оценки оценщикам разрешалось сравнивать сгенерированный код модели с моделью на основе истинности, чтобы обеспечить более точную и всестороннюю оценку.

Базовая линия
Мы выбрали несколько базовых уровней оценки для сравнительного тестирования по предлагаемому методу, включая:
CodeCoT¹²: Сочетает цепочки мысли с механизмом самопроверки, позволяя модели явно рассуждать во время генерации и самокорректировать синтаксические ошибки, тем самым повышая качество кода и семантическую согласованность.

^{Самопланирование 13}: Вводит двухэтапный конвейер генерации кода, при котором модель сначала планирует шаги решения, а затем генерирует код в соответствии с планом, эффективно повышая логическую согласованность и интерпретируемость для сложных задач.

^{Саморедактирование 14}: Принимает итеративную парадигму генерации и редактирования, которая выполняет сгенерированный код и автоматически исправляет ошибки на основе обратной связи во время выполнения, постоянно уточняя результат.
^{CodeChain 15}: Использует модульную генерацию и итеративную ревизию, разбивая сложные задачи на независимые функциональные модули и улучшая прочность конструкции и общее качество через несколько этапов оптимизации.

Self-debuging¹⁶: Наделяет модель автономной отладкой и возможностями объяснения. Благодаря замкнутому циклу генерации, выполнения и отладки он значительно повышает корректность сложных задач программирования без участия человека.

^{MapCoder 17}: Создает многоступенчатую совместную структуру, состоящую из четырёх агентов — поиска, планирования, кодирования и отладки — тщательно имитируя рабочий процесс программирования человека и обеспечивающую замкнутую генерацию от понимания задач до проверки результатов.

^{Self-Collaboration 18}: Организует систему как виртуальную команду программирования с ролями, такими как аналитик, программист и тестировщик, повышая общую производительность при генерации сложного кода за счёт ролевой коллаборации и итеративной обратной связи.

Экспериментальная установка
Для обеспечения справедливости и сопоставимости между экспериментами мы сначала оценили несколько основных LLM с использованием подхода прямой генерации кода для установления базовой производительности. На основе этих первоначальных результатов была выбрана наилучшая LLM в качестве единой основной модели для всех последующих экспериментов. Впоследствии мы сравнили предложенную структуру MAS4SysML с несколькими методами генерации репрезентативного кода. Все взаимодействия LLM проводились с фиксированной температурой (T = 0,2) для минимизации случайности при генерации. Для каждой задачи моделирования максимальное количество итераций восстановления в MAS4SysML было установлено как _{K max} = 3. Все базовые методы выполнялись в той же экспериментальной конфигурации, что и MAS4SysML, чтобы обеспечить согласованность результатов и справедливость экспериментов. Python-скрипт метода MAS4SysML предоставлен в виде дополнительного файла 3.

Results

Оценка базовой модели
Сначала мы выбрали несколько основных LLM и провели предварительные тесты производительности с использованием прямой генерации модели в код, включая CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)²², Incoder(6.7B)²³ и code-davinci-002(175B)²⁴. Как показано в таблице 2

Discussion

Мы предлагаем MAS4SysML — многоагентную совместную структуру для полуавтоматизированной генерации кода модели SysML v2. Фреймворк состоит из четырёх функционально взаимодополняющих агентов. Во время генерации он (i) иерархически разбивает требования к моделированию на естественном языке с помощью структуры на основе дерева задач и формализует их в структурированные карты задач, и (ii) генерирует код модели SysML v2 снизу вверх, руководствуясь ограничениями и зависимостей, указанными в эт...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (проект с открытым исходным кодом)	v1.0.8; https://github.com/langchain-ai/langchain	Фреймворк для взаимодействия LLM и оркестрации агентов
LangGraph	LangChain (проект с открытым исходным кодом)	v1.0.3; https://github.com/langchain-ai/langgraph	Фреймворк для выполнения многоагентных рабочих процессов
Python	Фонд программного обеспечения Python	3.10.x; https://www.python.org/downloads/release/python-3100/	Основной язык программирования для реализации MAS4SysML
Пилотная реализация SysML v2	Группа управления объектами (OMG)	(предоставить версию релиза/тег); https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Используется для проверки синтаксиса и разбора моделей