Инженерный ИИ: контекст проекта, математическое ядро, проверяемыерасчеты и ответственность

Современное инженерное программное обеспечение давно перестало быть одним расчетным инструментом.

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

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

В терминологии, близкой к действующим ГОСТ по компьютерному моделированию, компьютерная модель — это модель, разработанная в вычислительной среде и содержащая структурированные данные, программное и при необходимости методическое обеспечение, необходимое для работы с ней. Компьютерное моделирование — исследование свойств и поведения объекта моделирования с помощью такой компьютерной модели. Для задач нульмерного и одномерного инженерного анализа такие модели в инженерной практике часто называют системными моделями, а соответствующий класс задач — системным моделированием.

CAE-система Engee развивается именно как такая инженерная платформа. Она предназначена для исследования и доказательства свойств объектов моделирования и проведения виртуальных испытаний средствами численного и имитационного компьютерного моделирования: от разработки и расчета компьютерных моделей до анализа результатов, программирования и генерации исходного кода для прошивок микроконтроллеров.

Но связь между всеми этими операциями по-прежнему во многом обеспечивает человек.

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

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

Для небольшого проекта это может быть терпимо. В большом проекте такое устройство работы плохо масштабируется.

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

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

Необходимо сохранить инженерный контекст проекта и сделать его доступным непосредственно в процессе разработки.

Контекст проекта — это больше, чем набор файлов

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

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

Какие требования предъявляются к объекту? Какой показатель необходимо улучшить? Какие ограничения нельзя нарушать? Проверялся ли такой вариант раньше? Какие результаты дали расчет компьютерной модели и виртуальные или натурные испытания? Почему от предыдущего решения отказались?

Ответы обычно распределены между несколькими объектами.

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

Именно совокупность таких сведений и связей между ними мы называем инженерным контекстом проекта.

Это важно отличать от обычной «памяти чата».

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

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

Но языковая модель не должна становиться единственным местом, в котором существует знание о проекте.

Если через год команда сменит используемую LLM, инженерная история проекта не должна исчезнуть вместе со старым диалогом.

Инженерному ИИ недостаточно уметь рассуждать

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

Языковая модель способна предложить варианты изменения структуры или параметров регулятора. Она может быстро построить несколько гипотез и даже написать необходимый программный код.

Но сама правдоподобность ответа ничего не говорит о поведении конкретного объекта моделирования.

Для инженерной задачи нужен следующий шаг — расчет компьютерной модели.

Агент должен получить возможность изменить параметры или структуру модели, выполнить расчет, проанализировать результаты и проверить их по установленным критериям.

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

Такой подход уже хорошо знаком по программированию.

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

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

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

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

В Engee такие средства обеспечивают расчет компьютерных моделей численными методами. Сама программа предназначена в том числе для исследования и доказательства свойств объектов моделирования и проведения виртуальных испытаний.

При этом отдельной процедурой остается оценка адекватности компьютерной модели — подтверждение ее соответствия объекту моделирования по обоснованному перечню характеристик.

Это существенное различие.

Расчетное ядро не делает автоматически истинной любую построенную модель. Неверно сформулированная задача или неадекватная компьютерная модель могут дать вполне вычислимый результат.

Но ИИ уже не может остановиться на фразе: «предложенное решение должно обеспечить устойчивость».

Он получает возможность построить или изменить компьютерную модель, выполнить расчет, провести предусмотренные проверки и сопоставить результат с критериями.

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

ИИ быстро ищет варианты.
Инженерная среда проверяет то, что допускает формальную и расчетную проверку.
Человек определяет цель, критерии приемлемости и принимает техническое решение.

Чем больше автоматизации, тем заметнее ответственность человека

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

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

Программное обеспечение невозможно сделать субъектом ответственности за то, что человек неверно поставил задачу, выбрал недостаточный набор проверок или признал приемлемым результат, который следовало отвергнуть.

Но это никогда не мешало автоматизации.

Решатель не несет ответственности за конструкцию изделия. Компилятор не отвечает за назначение программного обеспечения. Система автоматической генерации кода не принимает решение о допуске изделия к эксплуатации.

То же относится к ИИ.

Наоборот, чем больше операций автоматизируется, тем яснее становится, за что именно отвечает инженер.

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

ИИ потенциально может сгенерировать и проверить гораздо больше вариантов, чем инженер способен рассмотреть вручную.

Но именно человек или инженерная команда определяют:

• какую задачу необходимо решить;

• какие свойства объекта существенны;

• насколько адекватна используемая компьютерная модель;

• какие требования и ограничения обязательны;

• достаточно ли выполненных проверок;

• допустим ли найденный компромисс;

• можно ли принять полученный результат и перейти к следующему этапу жизненного цикла изделия.

Поэтому развитие ИИ не устраняет человека из инженерной деятельности.

Оно сильнее разделяет выполнение операций и ответственность за интегральный результат.

Инженерный проект должен быть независим от конкретной LLM

Языковые модели меняются значительно быстрее инженерных проектов.

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

Через несколько лет набор лидеров наверняка будет другим.

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

Поэтому LLM следует рассматривать как сменный компонент.

Инженерный проект, расчетные инструменты и накопленный опыт организации — значительно более долгоживущий актив.

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

Команда «проверь устойчивость» еще не задает однозначной инженерной операции.

Необходимо определить конфигурацию компьютерной модели, метод проверки, изменяемые параметры, диапазоны, входные данные и критерии оценки результата.

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

Есть и более глубокий уровень инженерного контекста, которого вообще может не быть в исходном файле компьютерной модели. После подготовки модели к расчету — ее компиляции — в Engee формируется CMI (Compiled Model Information), то есть информация о скомпилированной модели. Она описывает уже не только то, как модель была записана разработчиком, но и представление модели, с которым работает расчетная среда после ее подготовки к выполнению.

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

Именно предоставление интеллектуальному агенту такого инженерного контекста — от объектов проекта до информации о подготовленной к расчету модели — и формализованных способов действия с ним составляет одну из задач Engee MIND — Modeling Intelligence for Nextgen Design.

Что такое Engee MIND

Engee MIND — не отдельная языковая модель и не еще один чат внутри CAE-системы.

Это модуль и слой взаимодействия между интеллектуальным агентом и инженерной платформой Engee.

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

При этом инженерный контекст сохраняется в самом проекте, а не только в истории общения с конкретной LLM.

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

Последние мы называем инженерными навыками (skills).

Skill — это формализованный и воспроизводимый способ выполнения определенной инженерной процедуры: последовательность действий, используемые инструменты, обязательные проверки и требования к результату.

Например:

• порядок проверки компьютерной модели после изменения алгоритма;

• набор виртуальных экспериментов перед передачей результата следующему разработчику;

• правила оформления компьютерных моделей;

• порядок анализа расхождения результатов;

• обязательные проверки перед фиксацией изменения;

• набор регрессионных испытаний для определенного класса моделей.

Обычная инструкция сообщает инженеру, что желательно сделать.

Skill дополнительно позволяет агенту самому выполнить формализуемую часть этой процедуры с помощью инструментов инженерной среды.

Как масштабировать практику сильных инженеров

Это позволяет сохранить еще один актив предприятия — не только результат разработки, но и способ выполнения работы.

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

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

Другой ограничится тем, что непосредственно требуется для решения сегодняшней задачи.

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

Интеллектуальный агент способен уменьшить такую вариативность.

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

Это не означает, что начинающий инженер становится равен главному конструктору.

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

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

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

Где должны находиться проект, MIND и языковая модель

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

Не менее важен вопрос: где находятся данные проекта и куда они могут передаваться.

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

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

В состав такого решения может входить модуль Engee MIND, благодаря чему в собственном контуре организации остаются:

• компьютерные модели;

• программный код и данные;

• результаты расчетов;

• инженерный контекст и история технических решений;

• проектные skills;

• сама инженерная платформа, выполняющая расчеты;

• локально развернутые и контролируемые организацией языковые модели.

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

Существует и промежуточный вариант — использование доверенной отраслевой вычислительной инфраструктуры.

Например, Росэл развивает ПАК САПР, в суперкомпьютерной среде которого доступны расчетные инструменты, включая Engee. В той же промышленной экосистеме развивается защищенная ИИ-платформа ShokinGPT, рассчитанная на работу внутри IT-среды предприятия без подключения к интернету.

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

Но не каждый инженерный проект требует такого уровня изоляции.

Для небольших, учебных, исследовательских или не содержащих чувствительной информации проектов возможна другая архитектура: облачная Engee и публично доступная LLM — например GPT, Claude, Алиса или GigaChat.

Принцип Engee MIND от этого не меняется.

Меняется лишь место выполнения отдельных компонентов.

В одном случае:
проект + Engee + MIND + LLM находятся внутри контролируемого контура предприятия.

В другом:
часть вычислительной и интеллектуальной инфраструктуры предоставляется доверенным оператором.

В третьем:
используются облачная Engee и публичная LLM.

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

Миграция существующих разработок — практический пример

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

Для многих российских предприятий переход на новый инженерный стек начинается не с чистого листа.

За годы работы накоплены компьютерные модели, программный код, алгоритмы и библиотеки, созданные в зарубежных средах.

Перенос такой разработки — это не преобразование формата файла.

Необходимо разобраться в структуре исходной модели, используемых компонентах и алгоритмах, найти соответствия в целевой среде, перенести параметры и программный код, а затем проверить, сохранилось ли требуемое поведение объекта моделирования.

Engee MIND уже используется для подобных задач при миграции моделей из Simulink в Engee.

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

Более сложный случай — модели, использующие устаревшие компоненты SimPowerSystems.

Необходимо не только заменить графические блоки, но и перейти к соответствующим электротехническим компонентам Engee.

Еще сложнее пользовательские функции и блоки, прямого аналога которых в целевой библиотеке нет.

В таком случае агент способен создать заготовку соответствующего компонента (например, Engee-function на встроенном языке, C-function, элемент на формульном языке Engee Physical Component language или маскированную подсистему, собранную из базовых сумматоров и умножителей), перенести математические зависимости или алгоритмы из пользовательского MATLAB-кода и включить полученный элемент в компьютерную модель Engee.

Но автоматический перевод — только начало.

После переноса необходимо выполнить расчет исходной и целевой реализации, сравнить результаты и определить расхождения.

Поэтому работа выполняется итеративно:
преобразование → расчет → сравнение → исправление → повторный расчет.

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

Здесь особенно хорошо видна общая архитектура инженерного ИИ.

Языковая модель помогает анализировать, строить гипотезы и выполнять преобразование.

Инженерная среда предоставляет детерминированный расчетный контур.

Человек определяет критерии соответствия и принимает решение о том, можно ли считать миграцию выполненной.

Что в результате меняется для разных участников инженерной деятельности

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

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

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

Что остается неизменным

Языковые модели будут меняться.

Будут появляться новые агенты, новые способы работы с программным кодом и документами, новые локальные и облачные модели.

Инженерный проект меняется намного медленнее.

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

Поэтому задача инженерного ПО в эпоху ИИ состоит не в том, чтобы добавить в существующую среду еще один чат.

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

Именно эту архитектуру мы развиваем в Engee.

Engee MIND — Modeling Intelligence for Nextgen Design — связывает интеллектуальных агентов с инженерной платформой, сохраняя проект и его контекст независимыми от конкретной языковой модели.

Агент получает возможность работать с инженерным контекстом и выполнять формализованные действия.

Engee предоставляет компьютерные модели, расчетное ядро и инструментальные средства для получения и анализа результатов компьютерного моделирования.

Люди ставят цели, определяют требования и принимают технические решения.

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

ИИ быстро ищет.
Инженерная среда проверяет.
Человек решает и отвечает за результат.