Проверку проектной документации и информационной модели стоит делить на две части. Соответствие правилам проверяет программа: результат повторяется при каждом запуске. Нейросеть полезна вокруг проверки: она переводит требования из текста в правила и формулирует замечания для авторов модели и разделов.
Что проверяют в модели
Набор проверок у каждой организации свой, но почти везде встречаются шесть групп:
- заполнение обязательных параметров у элементов;
- допустимые значения: список, формат, единицы измерения;
- именование типов, видов, листов и файлов по внутреннему стандарту;
- уровни, оси и привязка к общей системе координат;
- связанные файлы и актуальность их версий;
- пересечения элементов между разделами.
Правило как данные
Каждое правило записывают структурой: к каким элементам оно относится, какой параметр проверяется, какое условие должно выполняться. Правила хранятся таблицей или файлом, а не в голове BIM-координатора. Движок проверки применяет их к модели и выдаёт список нарушений. Одна и та же модель при каждом запуске даёт один и тот же список.
| Категория | Параметр | Условие | Серьёзность |
|---|---|---|---|
| Стены | Огнестойкость | Заполнен, значение из утверждённого списка | Ошибка |
| Двери | Марка | Не повторяется в пределах уровня | Ошибка |
| Помещения | Номер | Не пустой, без повторов | Предупреждение |
Таблица показывает структуру. Параметры и значения определяются требованиями заказчика и стандартом организации.
Где помогает нейросеть
- Разбор требований. Из технического задания на информационное моделирование модель готовит черновик таблицы правил. Человек проверяет каждую строку.
- Формулировка замечаний. Строка отчёта «Стена 4523, параметр пуст» превращается в замечание для автора: где элемент, что нужно заполнить, по какому требованию.
- Группировка. Сотни однотипных нарушений собираются в несколько замечаний с перечнем элементов.
- Пояснения. Новому сотруднику объясняют, почему правило существует и как его выполнить.
Решение о соответствии модели нейросети не поручают. Языковая модель может дать разные ответы на один и тот же вход, а результат проверки должен быть воспроизводимым и объяснимым.
Текстовая часть и ведомости
Та же схема применима к проверке проектной документации с помощью ИИ. Формальные признаки проверяет код: состав разделов, нумерацию, совпадение обозначений и значений в тексте и таблицах, ссылки на тома. Нейросеть сопоставляет требования задания с текстом раздела и формулирует замечание со ссылкой на страницу. Решение о замечании принимает ГИП или нормоконтролёр.
Как выглядит хорошее замечание
Из строки отчёта «Стена 4523, параметр пуст» нейросеть формирует текст, по которому автор может действовать без уточнений. Пример для иллюстрации:
Раздел АР, уровень 2, оси А-Г/3-5: у 14 стен типа «Наружная, 380» не заполнен параметр «Огнестойкость». Требование: таблица требований к параметрам, строка 12. Заполните значение из утверждённого списка. Перечень элементов и вид с подсветкой приложены.
В замечании есть место, количество, требование, действие и вложение. Все числа и номера берутся из результатов проверки, а не придумываются моделью. Это можно проверить автоматически: число элементов в тексте замечания сверяется с числом строк отчёта, и расхождение отправляет замечание на ручную правку.
Состав отчёта проверки
- сводка: число проверенных элементов и число нарушений по серьёзности;
- нарушения, сгруппированные по правилам;
- перечень элементов с идентификаторами;
- ссылки на виды или файл BCF;
- версии набора правил и модели, чтобы результат можно было воспроизвести.
Форматы обмена
Проверку можно запускать на экспорте IFC (открытый формат обмена моделями, ISO 16739) и передавать замечания в формате BCF, который создан для обмена замечаниями между программами. Такой подход не зависит от САПР и не затрагивает рабочую модель. Ограничение: в экспорт попадают не все параметры, поэтому до внедрения проверьте, что нужные данные выгружаются.
Проверка внутри САПР через API видит больше данных и точнее привязывает замечание к элементу, но требует доработки под каждую программу. Подходы к API описаны в статьях про Revit и про Renga, nanoCAD, Archicad и AutoCAD.
Нормативный контекст
Правила формирования информационной модели на разных стадиях жизненного цикла объекта изложены в своде правил СП 333.1325800.2020 (утверждён приказом Минстроя России от 31.12.2020 № 928/пр, действует с 1 июля 2021 года). Для объектов, которые финансируются с привлечением бюджетных средств, формирование и ведение информационной модели с 2022 года стало обязательным условием договора на подготовку проектной документации (постановление правительства от 5 марта 2021 года № 331, есть исключения). Актуальные редакции и перечень исключений проверяйте в официальных источниках.
С чего начать
- Выписать правила, которые нарушаются чаще всего. Типичный источник - возвраты моделей на доработку за последние месяцы.
- Оформить их таблицей: категория, параметр, условие, серьёзность.
- Реализовать проверку на экспорте IFC или через API программы и получить повторяемый отчёт.
- Добавить нейросеть для замечаний и группировки, оставив решение о соответствии за правилами.
- Замерить время от выгрузки модели до готового списка замечаний и долю моделей, возвращённых повторно.
Вывод
Разделение ролей даёт воспроизводимую проверку и экономит время на текстах замечаний. Нейросеть не принимает решений о соответствии, она готовит материал для BIM-координатора, который принимает решение сам.