1 подписчик
Чем опасна нейросетевая проверка (и как её приручить)
Факт из практики: эксперт-человек выдал 15 замечаний. Нейросеть — 60.
Парадокс в том, что формально ИИ не ошибался. Почти каждое из 50–70 замечаний, полученных при машинной сверке раздела ПОС, выглядело обоснованным. Но именно это и стало проблемой: разбирать их оказалось дольше, чем проверить раздел вручную.
И это — ключевой аргумент практиков против автоматической проверки. Не «ИИ ошибается», а «ИИ не умеет молчать». Он не фильтрует, он регистрирует.
Сначала научиться делать, потом — проверять
Коллеги с канала @pospprprofi (мы с ними подготовили этот материал совместно, хотя по ряду позиций расходимся) справедливо замечают: начинать надо не с контроля, а с разработки. Пока вы не научились создавать раздел с помощью нейросети, ставить её в роль экзаменатора бессмысленно.
Модель без контекста приоритетов выдаёт замечания на всё подряд. Она не отличает критическое расхождение от редакционной погрешности. А значит, говорить об отработанной методике пока рано — это экспериментальная практика, не более.
Добавьте к этому нестабильность входных данных: подрядчик работает с разными проектными организациями и каждый раз получает новый комплект — где-то полную документацию, где-то лишь схемы, таблицы и эскизы. Проверить можно только то, что передали на вход. Универсального алгоритма здесь просто не существует.
Перегруз — неизбежность, если не задать приоритет
Опытный проверяющий не фиксирует каждую неточность. Он интуитивно (и профессионально) понимает, что на конкретном объекте существенно, а что не влияет на решение.
Нейросеть же отмечает почти всё. Почему? Потому что цена ошибки в самом документе обычно не указана. И это касается не только ПОС, но и любых других разделов проектной и рабочей документации.
Отсюда жесткое правило, без которого машинная сверка не окупается:
Приоритет задаётся до запуска проверки, а не после неё.
Иначе ручной разбор 60 находок съедает именно ту экономию времени, ради которой нейросеть и привлекалась.
Три фильтра, которые превращают 60 замечаний в 5
Чтобы ИИ перестал быть «генератором шума», в запрос нужно вшить три ограничителя.
Фильтр первый — правило двух адресов.
Каждое расхождение должно содержать ссылки на два противоречащих друг другу места: например, страницу пояснительной записки и лист чертежа, абзац и строку календарного плана.
Если указано только одно место, а замечание звучит как «не обосновано», «не указано» или «отсутствует расчёт» — перед вами не подтверждённое расхождение, а мнение о полноте. Такие находки лучше собирать в отдельный перечень и разбирать пачкой. Именно они, как правило, составляют львиную долю длинного списка.
Фильтр второй — правило последствия.
Нужно проверить: влияет ли находка на объём работ, стоимость, срок, безопасность или решение экспертизы?
Если нет — это редакционное замечание. Ему место в конце списка, а не в топе приоритетов.
Фильтр третий — потолок находок.
Не более 15 замечаний, отсортированных по значимости последствий. Всё остальное — одной строкой в отдельном перечне.
Без этого ограничения модель перечисляет всё, что видит. С ограничением — начинает ранжировать. А именно ранжирования машинной проверке чаще всего и не хватает.
На условном комплекте такой подход сократил около 40 исходных замечаний до пяти приоритетных. Остальные не исчезли — они перешли в отдельный перечень для обсуждения. Решение об отклонении, уточнении или переносе принимает уже инженер. И ответственность остаётся на нём, а не на модели.
Бонусом — мини-пособие для тех, кто работает с ПОС
Мы подготовили бесплатный файл на 14 страниц — «ПОС под проверку». Внутри:
- три сверки перед выдачей раздела;
- готовый блок для вставки в запрос;
- таблица границ проверки в зависимости от входных данных;
- разбор того, как сформулировать находку так, чтобы её нельзя было отклонить как голословную.
Забирайте и перешлите тому, кто разрабатывает или принимает ПОС.disk.yandex.ru/...n4ww
3 минуты
20 августа