ИИ, которому нельзя верить на слово

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

ИИ-помощники уже вышли за пределы текстовых задач и постепенно входят в инструменты разработки промышленных систем, в том числе SCADA. Но в АСУ ТП мало получить быстрый и убедительный ответ. Нужно понимать, на какой источник и версию он опирается и как проверить результат. Мы решили проверить этот подход на практике и собрали пилот на реальных задачах разработки и технической поддержки проектов, реализованных на ПО «Альфа платформа» компании «Атомик Софт».

Граница, которую необходимо учитывать

С офисным ИИ можно позволить себе риск. Модель не так пересказала письмо или не так поняла таблицу, досадно, но поправимо.

В АСУ ТП цена ошибки другая, ответ почти всегда привязан к версии платформы, конфигурации объекта, правам доступа и ответственности конкретного человека.

Поэтому разговор о промышленном ИИ нельзя начинать с вопроса «какую модель подключить». Первый вопрос куда более консервативный. Как модель будет доказывать свой ответ?

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

Как обстоят дела сейчас

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

Флагманские большие языковые модели вроде Fable 5, GPT-5.6 Sol, Kimi K3 и Qwen 3.8-Max лучше справляются с длинными задачами и вызовом инструментов. Но в промышленной среде важны не только возможности модели, но и место её запуска. Проектные данные не должны покидать закрытый периметр.

Поэтому тут интересны модели с открытыми весами, их можно развернуть на собственной инфраструктуре и зафиксировать нужную версию. Четырёхбитное сжатие снижает требования к памяти. Например, веса Qwen 3.8-27B занимают около 14 ГБ; с памятью для контекста модель уже можно запустить на мощной локальной рабочей станции.

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

«Нельзя верить на слово»

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

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

Архитектура проверяемого приватного агента

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

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

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

MCP полезен и опасен

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

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

Что мы собрали в СкадаСистемы

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

Это программная платформа для создания SCADA и многоуровневых систем диспетчеризации. Для внутреннего эксперимента мы собрали собственную систему под рабочим названием Alpha Copilot. Подчеркнём, решение не является продуктом семейства «Альфа платформа».

Проектные файлы «Альфа платформы» сочетают бинарные данные и XML-структуры. В отсутствие полной спецификации структуру и внутреннее устройство файлов мы восстанавливали на основе реальных проектов. Дополнительную сложность создавали сотни компонентов с набором свойств, зависящим от версии, а также собственный язык Alpha.OM.

Для пилота мы собрали 133 руководства, 466 обезличенных обращений и реальные проекты, а модели дали проверенный доступ к этой базе без дообучения.

Как это устроено

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

Те же данные используются при генерации. Агент берёт проверенный каркас и примеры реальных компонентов. После каждой правки линтер сверяет XML и скрипты с реестрами, а затем проект проверяет официальный alpha.hmi.cli или devstudio.cli в подходящем окружении. Линтер ловит известные ошибки, компилятор сверяет проект с правилами платформы, стенд подтверждает работу логики.

Чему нас научили сломанные проекты

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

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

Что уже работает

92 независимо сгенерированных проекта открылись в Alpha.HMI и DevStudio на виртуальной машине и выполнили заложенную логику. В небольшой проверке из восьми теоретических вопросов около 90 процентов ответов совпали с эталоном, неподкреплённых ответов не было. Такой набор даёт только предварительную оценку надёжности.

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

Демонстрация

По текстовому описанию система собрала АРМ оператора для установки подготовки нефти: обзорный экран, формы и экран тревог. Проект открыли и запустили в Alpha.HMI на виртуальной машине.

От текстового запроса до результата прошли минуты. Формы прошли статический линтер и официальный компилятор Alpha.HMI, после чего проект открыли на виртуальной машине.

Проект DevStudio

В отдельном тесте Alpha Copilot по техническому заданию собрал проект насосной станции на четыре насоса: серверную часть DevStudio, карты Modbus и OPC UA.

Всё скомпилировалось без ошибок и предупреждений, карта адресов прошла проверку без расхождений. Проект DevStudio в том запуске проверили статически.

Итоги

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

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

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

И агент должен уметь останавливаться, если данных мало или версия не определена, правильный ответ короткий — «нужны дополнительные данные».

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