ИИ уже создаёт цифровые модели. Почему рабочую документацию всё ещё выпускает человек?

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

Евгений Дмитриев — директор по проектированию ГК ПИК, инициатор и руководитель разработки SOPR. Codex — ИИ-партнёр в разработке SOPR и подготовке статьи.

Рабочая документация — это комплект чертежей и спецификаций, по которому строится реальный дом. Его ценность определяется согласованностью решений. Геометрия, материалы, размеры, проёмы, задания смежным разделам и ведомости зависят друг от друга. Одно изменение может затронуть модель и несколько документов. Пока инструменты ускоряют операции по отдельности, связи между ними удерживает человек. Поэтому локальная экономия времени не даёт сопоставимого эффекта на уровне всего проекта.

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

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

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

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

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

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

Исходная модель: фрагмент плана без оформления

Результат работы SOPR: сформированный кладочный план

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

Первый лист не дал мгновенной экономии. На поиск подхода, разработку правил и исправление ошибок мы потратили больше времени, чем занял бы обычный ручной выпуск. Но сравнивать стоимость разработки технологии со стоимостью одного листа неправильно. Экономика появляется при повторном применении: на следующем этаже, другой секции, новом объекте и при изменении исходных данных. Рабочая гипотеза проекта — сократить активные трудозатраты человека минимум на 60 процентов. Подтвердить или опровергнуть её должен измеримый эксперимент, а не впечатление от демонстрации.

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

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

Этап анализа перед генерацией: SOPR определил необходимые операции, проверил исходные данные и выделил вопрос, требующий решения специалиста.

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

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

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

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

Материал выражает личную позицию автора и не является публикацией ГК ПИК.