Если вы удалите из ТЗ и IOLIST названия предприятий, имена, адреса, номера договоров и грифы секретности — останутся чистые технические данные (типы датчиков, диапазоны, алгоритмы).
ТЗ зачастую это pdf файл или, что чаще, набор pdf файлов содержащий как текстовую информацию, так и схемы автоматизации, и удаление описанных вами данных звучит утопично.
Если вы считаете подход принципиально неверным — возможно, стоит направить усилия на создание полностью локального аналога?
Напротив, считаю саму идею весьма перспективной, однако для ее практического применения требуется дополнительная проработка вопросов, связанных с информационной безопасностью.
Исходя из собственного опыта, сегодня крупные заказчики нефтегазовой отрасли предъявляют исключительно высокие требования к обеспечению ИБ и рассматривают ее как один из ключевых факторов успешной реализации проектов АСУ ТП, и в этих реалиях использование Вашего продукта, в его текущем виде, может столкнуться с рядом существенных ограничений. В частности, речь идет о рисках и проблемах, которые я описал в предыдущем сообщении.
Именно поэтому хотел бы, чтобы мой комментарий воспринимался не как критика самой концепции, а как указание на нюансы, без проработки которых внедрение решения в крупных промышленных проектах может оказаться затруднительным.
Учитывая, что вы не знакомы с проектом и не тестировали его в реальных условиях, ваши замечания носят скорее теоретический характер.
С большим интересом протестировал бы Ваше решение в рамках реальных проектов после появления поддержки локальных LLM-провайдеров, таких как LM Studio или Ollama.
Безусловно, по своим возможностям локальные модели пока во многих случаях уступают облачным решениям, особенно если речь идет о сложных рассуждениях, работе с большим контекстом или специализированных знаниях. Однако для промышленного применения зачастую на первый план выходят не максимальные возможности модели, а вопросы контроля над данными.
На мой взгляд, ограниченную функциональность локальных моделей можно частично компенсировать архитектурными решениями. Например, сложные задачи можно декомпозировать на несколько более простых подзадач и распределять их между специализированными моделями. Одна модель может отвечать за анализ проектной документации, другая — за поиск релевантной информации в локальной базе знаний (практически у любого заказчика есть набор нормативной документации, который требуется учитывать при разработке проекта), третья — за формирование итогового ответа или отчета. Такой подход будет уступать единой передовой облачной модели по качеству результата, но для многих сценариев выглядит вполне оправданным.
Вы называете свой инструмент «локальным приложением», но ключевая ценность продукта — не Flask и не интерфейс на localhost, а работа внешней языковой модели DeepSeek, которая обрабатывает информацию из ТЗ и перечня сигналов. Без доступа к облачной модели основная функция фактически исчезает, поэтому громко называть такое решение "локальным" мягко говоря спорно.
Кроме того, в промышленной автоматизации технические задания, перечни сигналов, структуры объектов и алгоритмы управления зачастую относятся к конфиденциальной информации, и их передача сторонним сервисам может подпадать как под нарушение внутренних регламентов ИБ заказчика, так и регулятора в лице ФСТЭК.
Конечному пользователю важно понимать, что перед использованием подобных инструментов необходимо получить официальное согласование службы ИБ и юридического отдела заказчика, которое никто никогда не предоставит, в противном случае ответственность за передачу данных будет нести не разработчик инструмента, а сотрудник, который загрузил информацию в облако.
ТЗ зачастую это pdf файл или, что чаще, набор pdf файлов содержащий как текстовую информацию, так и схемы автоматизации, и удаление описанных вами данных звучит утопично.
Напротив, считаю саму идею весьма перспективной, однако для ее практического применения требуется дополнительная проработка вопросов, связанных с информационной безопасностью.
Исходя из собственного опыта, сегодня крупные заказчики нефтегазовой отрасли предъявляют исключительно высокие требования к обеспечению ИБ и рассматривают ее как один из ключевых факторов успешной реализации проектов АСУ ТП, и в этих реалиях использование Вашего продукта, в его текущем виде, может столкнуться с рядом существенных ограничений. В частности, речь идет о рисках и проблемах, которые я описал в предыдущем сообщении.
Именно поэтому хотел бы, чтобы мой комментарий воспринимался не как критика самой концепции, а как указание на нюансы, без проработки которых внедрение решения в крупных промышленных проектах может оказаться затруднительным.
С большим интересом протестировал бы Ваше решение в рамках реальных проектов после появления поддержки локальных LLM-провайдеров, таких как LM Studio или Ollama.
Безусловно, по своим возможностям локальные модели пока во многих случаях уступают облачным решениям, особенно если речь идет о сложных рассуждениях, работе с большим контекстом или специализированных знаниях. Однако для промышленного применения зачастую на первый план выходят не максимальные возможности модели, а вопросы контроля над данными.
На мой взгляд, ограниченную функциональность локальных моделей можно частично компенсировать архитектурными решениями. Например, сложные задачи можно декомпозировать на несколько более простых подзадач и распределять их между специализированными моделями. Одна модель может отвечать за анализ проектной документации, другая — за поиск релевантной информации в локальной базе знаний (практически у любого заказчика есть набор нормативной документации, который требуется учитывать при разработке проекта), третья — за формирование итогового ответа или отчета. Такой подход будет уступать единой передовой облачной модели по качеству результата, но для многих сценариев выглядит вполне оправданным.
Вы называете свой инструмент «локальным приложением», но ключевая ценность продукта — не Flask и не интерфейс на localhost, а работа внешней языковой модели DeepSeek, которая обрабатывает информацию из ТЗ и перечня сигналов. Без доступа к облачной модели основная функция фактически исчезает, поэтому громко называть такое решение "локальным" мягко говоря спорно.
Кроме того, в промышленной автоматизации технические задания, перечни сигналов, структуры объектов и алгоритмы управления зачастую относятся к конфиденциальной информации, и их передача сторонним сервисам может подпадать как под нарушение внутренних регламентов ИБ заказчика, так и регулятора в лице ФСТЭК.
Конечному пользователю важно понимать, что перед использованием подобных инструментов необходимо получить официальное согласование службы ИБ и юридического отдела заказчика, которое никто никогда не предоставит, в противном случае ответственность за передачу данных будет нести не разработчик инструмента, а сотрудник, который загрузил информацию в облако.