TGViewer
Денис Ермолов|Системный ПДСМ Денис Ермолов|Системный ПДСМ @demer_llc · 7.09K subscribers
Post #880 409

Forwarded from AI песочница инженера

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

Завтра НОПРИЗ проводит конференцию по применению искусственного интеллекта в инженерных изысканиях и архитектурно-строительном проектировании.

Сам по себе факт уже показательный: отрасль постепенно переходит от вопроса «можно ли использовать ИИ?» к более практичному — «где именно его имеет смысл встраивать в производственный процесс?»
И здесь есть одна проблема.

Почти любой AI-кейс можно эффектно показать на одном документе, одном проекте или одной удачной проверке.

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

1. Можно точно назвать операцию, которую выполняет ИИ
«ИИ проверяет проект» — слишком широкая формулировка.
Гораздо полезнее:
— сопоставляет ВОР со спецификацией;
— ищет расхождения между ПЗ и графической частью;
— проверяет наличие исходных данных для расчёта;
— сравнивает параметры оборудования в IFC и спецификации;
— классифицирует замечания экспертизы;
— проверяет конкретный набор требований СП.
То есть должна существовать понятная схема:
входные данные → операция → результат
Например:
IFC + спецификация XLSX → сверка оборудования → таблица расхождений
Если такую схему нельзя сформулировать, автоматизировать пока, скорее всего, нечего.

2. Понятно, какие данные считаются исходными
Для инженерной задачи это особенно важно.
Нейросеть может хорошо рассуждать и при этом анализировать:
— старую редакцию СП;
— предыдущую версию ТУ;
— неактуальный комплект РД;
— модель одной ревизии и спецификацию другой;
— документ, который вообще не относится к рассматриваемому решению.
Поэтому рабочий сценарий начинается не с промпта.
Сначала нужно определить источники:
IFC rev.07
Спецификация rev.07
ТУ №...
Задание rev.05
СП ... в редакции на дату ...
ИИ должен работать не с абстрактным «контекстом проекта», а с контролируемым набором исходных данных.

3. Результат можно быстро проверить
Для инженерной проверки недостаточно получить текст:
«Обнаружено несоответствие требованиям».

Нужна трассировка вывода.
Например:
элемент IFC → GUID
параметр → 3,2 л/с
спецификация → строка 48 → 4,1 л/с
результат → расхождение
Или для проверки нормы:
лист → объект → принятое решение → пункт нормативного документа → требование
Специалист должен понимать, откуда появился вывод, не повторяя весь поиск заново.
Если доказательство найти сложно, ИИ не столько сокращает проверку, сколько добавляет ещё один слой работы.

4. Известно, где система ошибается
Обычно при пилоте первым делом показывают успешные примеры.
Но для внедрения полезнее знать другое:
что система пропускает и что она считает ошибкой ошибочно.
Допустим, на контрольной выборке было 100 известных расхождений.
Нужно смотреть отдельно:
— сколько найдено;
— сколько пропущено;
— сколько добавлено ложных;
— какие типы ошибок повторяются.
Причём «точность 95%» сама по себе мало что значит.
Пять лишних замечаний и один пропуск критического требования — совершенно разные риски.
Для проектирования важна не только средняя точность, но и тип ошибки.

5. Определена граница между проверкой и инженерным решением
Представим простой случай.
ИИ сопоставил расчёт и схему:
в расчёте — 3,2 л/с
на схеме — 4,1 л/с
Система правильно обнаружила расхождение.
Но из этого ещё нельзя автоматически сделать вывод:
«Необходимо изменить диаметр трубопровода».

Причина может быть другой:
— схема актуальнее расчёта;
— изменилась нагрузка;
— предусмотрен резерв;
— ошибка действительно есть в принятом диаметре;
— изменилось другое связанное решение.
Поэтому полезная граница выглядит так:
ИИ нашёл → показал данные → специалист принял решение.
И эта граница должна быть определена заранее.

6. Можно измерить производственный эффект
Самая слабая метрика:
«Нейросеть дала ответ за 20 секунд».

Инженеру всё равно, сколько модель генерировала текст.
Гораздо интереснее:
раньше первичная сверка двух комплектов занимала 3 часа;
после автоматизации:
— 15 минут работает система;
— 30 минут специалист проверяет найденные расхождения.
Вот это уже можно считать.
Причём измерять желательно не только время.
Например:
время операции
число найденных расхождений
число пропусков
число ложных замечаний
время проверки результата человеком
Тогда становится понятно, действительно ли решение помогает производству.

А теперь самое практичное.
Допустим, мы хотим использовать ИИ для проверки оборудования в BIM-модели.
Не начинаем с вопроса:
«Какую LLM взять?»
Сначала описываем задачу:
Операция: сверка оборудования
Источник 1: IFC rev.07
Источник 2: спецификация XLSX rev.07
Проверяем: марку, количество, основные параметры
Результат: таблица расхождений
Доказательство: GUID + строка спецификации
Человек принимает решение: при каждом несовпадении
Метрика: время проверки + число пропущенных расхождений

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

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

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

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

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

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

AI песочница инженера в Дзене 📱|в МАХ 📲|в VK 📱|в VC|
  • 👍 3
  • 🔥 1
More from @demer_llc
  1. Sep 22, 2026База знаний, часть 3. Она не закончена, и это нормально ♾️ Начало: часть1 и часть 2 Проект…
  2. Sep 21, 2026База знаний, часть 2. Что мы сделали 🛠 Начало тут. Итак, три платформы позади, а команда…
  3. Sep 20, 2026База знаний, часть 1. Зачем она мне вообще нужна 🧠 Извините что пропал. Заканчивали проек…
  4. Sep 17, 2026Без управления рисками проект превращается в тушение пожаров В компаниях, где системной ра…
  5. Sep 13, 2026Извините что немного пропал из информационного поля - завершаем проект по работе с базой з…
  6. Sep 11, 2026Дерево 2.0: возможности, применение и экономика LVL Когда LVL становится экономически эффе…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →