Эксперт-человек даёт к разделу 15 замечаний. Нейросеть — 60.

Это не гипотеза, а случай из практики.
ПОС разработали с помощью нейросети. Принимающая сторона проверила готовый раздел тоже с помощью ИИ и получила от 50 до 70 замечаний. Почти все выглядели обоснованными.

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

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

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

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

Проверить можно только то, что передали на вход.

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

Ручной разбор 60 находок — это именно та работа, ради экономии которой и применяли нейросеть.

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

2. Правило последствия
Нужно проверить, влияет ли находка на:
— объём работ;
— стоимость;
— срок;
— безопасность;
— решение экспертизы.
Если не влияет, это редакционное замечание. Его место — в конце списка.

3. Потолок находок
Не более 15 замечаний, отсортированных по значимости последствий. Всё остальное — одной строкой в отдельном перечне.
Без ограничения модель перечисляет всё, что обнаружила. Ограничение заставляет её ранжировать находки — а именно ранжирования машинной проверке чаще всего и не хватает.
На условном комплекте такой подход сократил около 40 исходных замечаний до пяти приоритетных.

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

📘 «ПОС под проверку» — бесплатное мини-пособие на 14 страниц.

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

Забирайте и перешлите тому, кто разрабатывает или принимает ПОС.

А тем, кто ближе к разработке, чем к проверке, будет полезен канал ПОС ППР Профи

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

#ПОС #организация_строительства #экспертиза #входной_контроль #ГИП #ПТО #ИИ_для_инженера #нейросети_в_стройке #AIпесочница