ИИ ищет в модели то, чего не находят правила

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

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

Проблема в другом. Самые дорогие ошибки обычно не входят в список правил, потому что никто не догадался их туда внести. Стена толщиной 380 вместо 400 в одном месте из четырёхсот. Оборудование с массой 1200 кг там, где у соседних позиций 120. Дверь, которая по параметрам открывается в сторону лестничной клетки.

Правило на такое не напишешь: заранее не знаешь, что именно пойдёт не так. Зато можно искать не нарушения, а странности.

В чём разница

Правило говорит: «параметр Марка не должен быть пустым». Оно проверяет соответствие условию.

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

Такой подход не заменяет правила, а дополняет их. Правила отсекают известные ошибки. Аномалии подсвечивают неизвестные.

Что реально ищется

Числовые выбросы. Берём все элементы одного типа и смотрим на распределение параметров: толщина, высота, объём, масса, площадь. Значения, выпадающие из общей картины, попадают в отчёт.

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

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

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

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

Геометрические странности. Элементы нулевого или почти нулевого объёма, дубли в одной точке, элементы, торчащие далеко за габариты здания. Такое появляется от неудачного копирования и не ловится ни одним правилом качества.

Нужны ли для этого нейросети

Честно: чаще всего нет.

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

Языковая модель полезна на другом шаге: когда нужно объяснить находку человеку. «Элемент 5482: толщина 380 при том, что у остальных 412 стен этого типа она 400; вероятно, ручное изменение экземпляра» читается лучше, чем строка с числами. На больших отчётах это экономит время того, кто разбирает.

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

Что делать с результатом

Главная опасность такого отчёта в том, что он превращается в шум. Если система выдаёт четыреста «странностей» на модель, их никто не будет смотреть.

Поэтому три правила.

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

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

Третье: помечать проверенное. Если проектировщик посмотрел и сказал «так и должно быть», элемент не должен всплывать в следующем отчёте. Без этого механизма люди перестают открывать отчёт через неделю.

Пример с цифрами

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

Поиск аномалий дал 63 замечания после фильтрации. Из них:

• 8 оказались реальными ошибками (толщины, отметки, один элемент с массой в тоннах вместо килограммов);
• 21 штука оказалась осознанными исключениями, их пометили и больше не показывали;
• 34 были шумом от особенностей моделирования, после чего правило подсветки подкрутили.

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

С чего начать

Не с закупки платформы. Начните с выгрузки: возьмите спецификацию по одной категории и посмотрите на распределение числовых параметров в обычной таблице. Выбросы видны глазами.

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

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