PLC Smart Splitter: как ИИ помогает инженеру АСУ ТП не утонуть в технических заданиях

[ura-ch]

В текущей версии PLC Smart Splitter действительно не полностью локальный. Ключевая генерация структурированного ТЗ выполняется через API DeepSeek (облачная модель). Локальными остаются:

• парсинг и профилирование IOLIST,

• нарезка ТЗ на блоки,

• группировка сигналов по подсистемам,

• формирование промптов,

• экспорт и интерфейс.

Но сама генерация — облачная. Называть продукт просто «локальным» без оговорок — некорректно. Я поправлю формулировки в README и на сайте, добавив чёткое разделение:

«Данные не покидают ваш ПК до момента отправки промпта в DeepSeek API. Сама генерация ТЗ выполняется в облаке модели. Если требуется полная локальность — генерация отключается, остаётся режим «Промпт чата» (вы сами вставляете промпт в веб-чат) или подготовка данных для ручной доработки.»

Если вы удалите из ТЗ и IOLIST названия предприятий, имена, адреса, номера договоров и грифы секретности — останутся чистые технические данные (типы датчиков, диапазоны, алгоритмы). Такой набор практически невозможно обратно привязать к конкретному заказчику или объекту. С ним можно работать через облачный API без нарушения большинства внутренних регламентов ИБ.

Риск утечки именно вашего промпта из DeepSeek близок к нулю — массовых взломов истории запросов у крупных LLM-провайдеров не было. Основная угроза — утечка вашего API-ключа или загрузка исходного неанонимизированного документа.

Учитывая, что вы не знакомы с проектом и не тестировали его в реальных условиях, ваши замечания носят скорее теоретический характер. Если вы считаете подход принципиально неверным — возможно, стоит направить усилия на создание полностью локального аналога? Рынок АСУ ТП действительно ждёт такого решения, и конструктивная конкуренция здесь только поможет.

[ara32]

Если вы удалите из ТЗ и IOLIST названия предприятий, имена, адреса, номера договоров и грифы секретности — останутся чистые технические данные (типы датчиков, диапазоны, алгоритмы).

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

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

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

Исходя из собственного опыта, сегодня крупные заказчики нефтегазовой отрасли предъявляют исключительно высокие требования к обеспечению ИБ и рассматривают ее как один из ключевых факторов успешной реализации проектов АСУ ТП, и в этих реалиях использование Вашего продукта, в его текущем виде, может столкнуться с рядом существенных ограничений. В частности, речь идет о рисках и проблемах, которые я описал в предыдущем сообщении.

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

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

С большим интересом протестировал бы Ваше решение в рамках реальных проектов после появления поддержки локальных LLM-провайдеров, таких как LM Studio или Ollama.

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

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

[ura-ch]

Вы предлагаете компенсировать слабость локальных моделей архитектурными ухищрениями, но на практике декомпозиция сложной инженерной задачи на примитивы не спасает от главного: локальные LLM систематически ошибаются в логике, работе с большим контекстом и скрытых взаимосвязях в ТЗ. Именно поэтому ни один крупный заказчик не примет решение, построенное исключительно на Ollama или LM Studio, это гарантия некачественного результата. Сценарии, где такой подход “оправдан”, сводятся к примитивному извлечению полей или поиску по ГОСТам, но это не автоматизация разработки АСУ ТП. Пока локальные модели не сравняются даже с GPT-4 по глубине рассуждений, говорить о промышленном применении вашей схемы преждевременно.

[ara32]

Вы называете свой инструмент «локальным приложением», но ключевая ценность продукта — не Flask и не интерфейс на localhost, а работа внешней языковой модели DeepSeek, которая обрабатывает информацию из ТЗ и перечня сигналов. Без доступа к облачной модели основная функция фактически исчезает, поэтому громко называть такое решение "локальным" мягко говоря спорно.

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

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