Автоматизировать проектировщика или передать выпуск рабочей документации ИИ?

Почему ускорение отдельных операций не сокращает весь цикл и в каких точках по-прежнему необходим человек

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

Что такое SOPR

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

Цель технологии — передать системе формализуемую часть производства документации, оставив человеку правила, неоднозначные решения, оценку качества и ответственность за выпуск. Это не отдельная кнопка, а другая организация проектного производства.

Почему небольшая правка становится большой работой

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

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

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

Что должна определить машина

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

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

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

Локальный пересчет вместо повторного выпуска всего проекта

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

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

Такой подход сохраняет управляемость: руководитель видит причину изменения, затронутые документы и результаты проверок. Неоднозначность система должна передать человеку как конкретный вопрос, а не скрыть случайным решением.

Что эффективнее автоматизация проектировщика или выпуск документации с помощью ИИ

Здесь возникает провокационный вопрос. Что эффективнее: продолжать автоматизировать действия проектировщика или строить производство, в котором система сама выпускает и проверяет документацию, а человек подключается только к определенным операциям?

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

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

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

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

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

Место сценариев в общем контуре

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

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

Что показал кладочный пилот

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

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

Рис. 2. Исходная модель до формирования кладочного плана

Рис. 3. Результат работы ограниченного контура: кладочные решения, размеры и марки

Что должен проверить следующий эксперимент

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

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

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

Где возникает экономический эффект

Экономия появляется не за счет ускорения одной команды. Она возникает, когда сокращается весь цикл обработки изменения:

1. поиск последствий;
2. постановка заданий;
3. корректировка связанных элементов;
4. повторное оформление;
5. проверка комплекта.

Эффект усиливается при повторном применении одних и тех же правил на разных объектах, даже если архитектура каждого объекта индивидуальна.

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

Роль человека остается профессиональной

Управляемый пересчет ограничивает участие проектировщика операциями, где требуется профессиональная ответственность:

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

В разработке SOPR Codex — ИИ-инструмент OpenAI для программной разработки — используется как технический партнёр: помогает формализовать проектные знания, создавать исполнительные механизмы и повторять проверки после исправлений. Проектную логику, критерии результата и профессиональные решения задаёт автор.

Следующий результат должен быть доказательством

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

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

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