Проверка BIM данных: метод из трёх этапов для проверки ваших данных

Пятница, вторая половина дня, и в СОД поступает новая версия модели. Вы примерно знаете, что запрашивал заказчик: огнестойкость дверей, коды классификации для всех элементов, данные о материалах, которые кто-то из последующих специалистов будет использовать при оформлении заказа. Вы также знаете, что с момента стартового совещания никто не открывал документ с требованиями. Что же делать? Вы запускаете проверку на конфликты, просматриваете несколько сотен проблем, группируете их, экспортируете отчет. А что насчет данных? Прокручиваете немного. Проверяете выборочно несколько дверей. Надеетесь на лучшее. Именно так выглядит проверка данных BIM в большинстве проектов, и я видел это во многих из них.

Мы превратились в цифровых уборщиков

Вас наняли в качестве инженера. Кто-то платит вам по ставке инженера. А теперь честно вспомните прошедшую неделю: сколько часов из них ушло на работу, которую должна была выполнить машина?

Я имею в виду механическую часть. Пролистывание модели для проверки. Копирование ошибок в отчет, который никто не исправляет. Загрузка и скачивание моделей в СОД. Исправление тегов и опечаток, а затем повторение всего этого через две недели.

Работа координатора BIM задумана так, чтобы убирать за кем-то другим. В большинстве случаев вручную.

Почему никто не проверяет данные?

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

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

Почему? Потому что выявление коллизий — это просто. Не просто исправить, а просто обнаружить. Два объекта пересекаются в одном месте, а этого не должно быть. Никому не нужно определять, что такое коллизия.

Данные невидимы.

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

У данных нет естественного определения «неправильного». Кто-то должен зафиксировать, как выглядит «правильное», и этим зафиксированным документом является EIR, который никто не читал.

Поэтому отрасль проверяет то, что может понять, и называет это «контролем качества».

Во что на самом деле обходятся некачественные данные

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

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

Три причины, по которым это происходит снова и снова

Требования нечитаемы

В проекте Nye SUS — нового университетского госпиталя в Ставангере — полный набор требований BIM состоял из шести документов. 146 страниц. Более двухсот параметров, требуемых во всех дисциплинах.

Вы знаете, что происходит с таким документом. Будьте честны в отношении своего текущего проекта: кто дочитал дальше десятой страницы?

Проверка данных BIM выполняется вручную

Это ловушка «мышечного клика», и я годами попадал в неё. Скачивать модели, обновлять их, ждать, настраивать наборы правил, запускать движок, снова ждать, отделять реальные проблемы от «шума», группировать их по проектировщикам, экспортировать BCF, создавать задачи. А потом умножить всё это на несколько тысяч проблем.

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

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

Работа не накапливается

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

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

Никто не скажет: «Стать быстрее в кликах».

Так что же изменилось?

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

Ситуацию изменили две вещи, и многие координаторы и менеджеры BIM не используют ни одну из них должным образом.

Стандарт, который могут читать машины

В июне 2024 года buildingSMART выпустила Спецификацию передачи информации (IDS). Она описывает требования в формате, который может обрабатывать программное обеспечение, и большинство средств проверки IFC-моделей могут её читать.

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

Языковые модели, которые читают беспорядочный текст и возвращают структуру

Вторая новинка появилась с ChatGPT в начале 2023 года. ИИ очень хорош в двух скучных вещах: понимании прозы и структурировании данных. А это как раз и есть суть проблемы с требованиями.

Почему нельзя просто попросить ChatGPT предоставить этот файл?

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

Проблема в том, что ИИ — это «черный ящик». Вы вводите документ и запрос, модель что-то обдумывает, и в результате получается ответ. Иногда правильный, а иногда — полный бред.

В нашей отрасли мы не можем довольствоваться «довольно хорошим» результатом, потому что «незначительные» ошибки могут стоить миллионов (или даже лет тюрьмы, если что-то пойдет не так...). Нам нужно, чтобы всё, что генерирует для нас ИИ, было максимально близко к полной правильности.

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

Метод из трёх шагов: составление чернового варианта, проверка, валидация

Итак, этот рабочий процесс, основан на том, в чём силен ИИ и что позволяет сделать IDS. Вот как он работает, шаг за шагом.

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

Первый шаг уже пробуют все. Второй — почти никто.

Черновик

Этот этап состоит из двух частей.

Первая — это документ клиента в том виде, в каком он поступил. В этом примере это был файл Excel, в котором все этапы были смешаны, а пять или шесть требований были скучены в одной ячейке. Работайте с одним этапом за раз, поскольку данные меняются по мере продвижения проекта. Я выбрал LOIN 200, а остальное оставил без изменений.

Второй элемент — это контекстные файлы, и именно эту часть люди часто пропускают. Речь идет о схеме IFC4 и документации IDS, преобразованных в простой формат Markdown, который может прочитать языковая модель. Без них модель работает на основе обучающей базы данных, а эта база охватывает только такие известные свойства, как FireRating или LoadBearing. Если задать вопрос, выходящий за рамки этих свойств, модель восполняет пробелы собственными вымышленными свойствами.

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

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

Проверка

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

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

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

Затем — три прохода.

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

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

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

Проверка

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

Прежде чем приступить к работе с моделью, нужно убедиться, что файл открывается. Затем файл проходит проверку в IFC-проверке. Если ваш инструмент вообще не читает IDS, об этом стоит узнать на этой неделе, а не в тот день, когда клиент пришлёт вам такой файл.

Загрузите, запустите проверку, создайте отчёты о проблемах, экспортируйте BCF. Обычная процедура координации.

А теперь часть, которая возвращает потраченное время. Ни один из этих кликов не должен быть моим. Solibri автоматизирует процесс с помощью Autorun: XML-файла, который указывает программе, что делать, и небольшого пакетного файла, который запускает этот процесс. XML-файл следует той же семье схем, что и IDS, поэтому AI пишет и его, используя документацию Solibri Developer Platform в качестве контекстного файла.

Затем процесс запускается ночью, и утром отчёт уже лежит у меня на столе. Вот так двадцать часов каждые две недели превратились примерно в два. Инструментарий специфичен для Solibri, но сама суть процесса — нет.

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

Резюме

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

Системы автоматического обнаружения ошибок (IDS) и большие языковые модели (LLM) расширяют границы возможного, но ни одна из них не заменяет вас. Черновик местами явно содержит ошибки, поэтому проверка по-прежнему лежит на вас. Если ваше имя будет указано в отчете, вы должны самостоятельно прочитать цитаты, прежде чем файл попадет в модель.

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

В ближайшую пятницу днём в СОД поступит очередная версия. Либо вы откроете её вручную и будете надеяться на лучшее, либо проверка уже прошла, и отчёт ждёт вас.

Вы перестаёте быть тем, кто проверяет модели, и становитесь тем, кто настраивает процесс проверки.