Может ли ИИ действительно проверять проектную документацию? Результаты эксперимента SIGNAL
Один комплект несколько раз проверялся разными моделями и разными сценариями работы с искусственным интеллектом.
Может ли искусственный интеллект не просто прочитать проектную документацию и сформировать несколько правдоподобных комментариев, а действительно выполнить инженерную проверку: пройти десятки листов, сопоставить данные между ними, найти противоречия, проверить числа и ссылки — и при этом не завалить специалиста ложными замечаниями?
Чтобы ответить на этот вопрос, в SIGNAL провели серию экспериментов на одном и том же комплекте проектной документации. SIGNAL — это ИТ-компания, созданная на базе строительного девелопера SEVERIN DEVELOPMENT, которая превратила собственный опыт цифровой трансформации в готовые программные продукты для отрасли. Команда SIGNAL предлагает рынку решения, проверенные на реальных стройплощадках: от внедрения BIM до автоматизации процессов управления проектами.
Один комплект несколько раз проверялся разными моделями и разными сценариями работы с AI. Всего было выполнено семь прогонов — от сложного многоступенчатого анализа, занимавшего несколько часов, до практически автоматических проверок современными мультимодальными моделями.
Было важно не то, сколько замечаний способна сгенерировать нейросеть, а насколько полезен результат для инженера:
сколько найденных замечаний действительно подтверждается;
сколько существенных проблем АІ пропускает;
способен ли он связывать информацию между разными листами;
умеет ли проверять арифметику, спецификации и перекрёстные ссылки;
различает ли явную ошибку и неоднозначность;
насколько сокращается объём ручной проверки.
Результаты показали: качество проверки определяется не только моделью. Не менее важен сам процесс анализа документации.
Первый эксперимент: глубокая многоступенчатая проверка
Первая проверка проводилась практически в исследовательском режиме.
Комплект примерно из 40 PDF-страниц обрабатывался несколькими способами: документ разбивался на страницы, отдельно анализировались текст, структура и изображения, выполнялось несколько последовательных проходов, после чего результаты объединялись в единый отчёт. Весь процесс занимал несколько часов.
АІ сформировал 42 замечания. После ручной проверки инженером:
31 замечание подтвердилось;
5 были отнесены к спорным;
6 оказались ложными.
Подтверждаемость составила около 74%.
При этом AI находил не только локальные ошибки на отдельных листах, но и пытался анализировать связи между документами, исходные данные, характеристики конструкций и полноту представленной информации. Здесь проявилось важное ограничение.
Если каких-либо сведений нет в переданном комплекте, это ещё не означает, что проектировщик их не разработал. Они могут находиться в другом разделе, расчётной записке или отдельном томе. Поэтому недостаточно просто передать большой языковой модели комплект и сказать: «Проверь проект по всем нормам». Система должна понимать границы проверки: какие документы ей переданы и какие сведения действительно должны присутствовать именно в них.
Контрольный набор из 14 дефектов
Для дальнейшего сравнения выделили 14 конкретных и проверяемых проблем,
присутствовавших в документации. Это не означало, что во всём комплекте было ровно 14 ошибок. Контрольный набор нужен был
для того, чтобы одинаково оценивать разные подходы.
В него вошли типичные ситуации:
одна позиция используется для разных элементов;
одинаково обозначенные детали имеют разные характеристики;
данные на чертеже расходятся со спецификацией;
остаются незаполненные шаблонные значения;
часть размеров не завершена;
ссылка ведёт не на тот лист или узел;
арифметическое выражение содержит ошибку;
масса детали не соответствует её геометрии или спецификации;
количество элементов расходится между таблицами;
значение на одном листе противоречит сводной ведомости.
Первая многоступенчатая проверка обнаружила примерно 10,5 из 14 контрольных дефектов.
То есть даже глубокий анализ, сформировавший десятки замечаний, не обеспечил полного покрытия заранее известных проблем.
Одна модель — разные результаты
Затем один и тот же комплект четыре раза проверялся SIGNAL AI Checker с использованием одной и той же модели gpt-5.6-sol.
В разных прогонах АІ сформировал:
6 замечаний;
7 замечаний;
5 замечаний;
12 замечаний.
Причём первые три проверки выполнялись с практически одинаковой постановкой задачи.
Часть замечаний повторялась стабильно: модель регулярно находила незаполненные значения, неопределенные размеры и некоторые расхождения между чертежами и спецификациями.
Другие проблемы появлялись только в отдельных запусках. В одном случае AI находил несогласованность параметра, в другом — ошибку массы, в третьем — неправильную межлистовую ссылку.
Для обычного чат-бота такая вариативность не критична. Для инженерной проверки — принципиальна. Если система должна обнаруживать максимально возможное количество потенциальных дефектов до передачи документации эксперту, одного общего запроса к модели недостаточно.
Проверку необходимо строить как системный сценарий: отдельно искать разные классы ошибок, сопоставлять результаты между проходами и перепроверять потенциальные замечания.
Постановка задачи сильно влияет на результат
Особенно показателен оказался четвёртый прогон. Вместо задачи, ориентированной преимущественно на существенные нормативные нарушения, модель получила более широкую формулировку: найти все замечания к документу.
Количество результатов выросло до 12 замечаний, и после ручной проверки подтвердились все 12.
AI начал находить более глубокие внутренние противоречия:
одинаковые позиции у разных элементов;
различные детали с одним обозначением;
ошибочные ссылки между листами;
аномальные размеры;
несогласованные массы;
неправильные ссылки на текстовые пункты.
По контрольному набору этот прогон обнаружил 8 из 14 дефектов, тогда как один из предыдущих
— только 5 из 14.
Эксперимент не является академическим benchmark: между сериями менялись сценарии проверки и позднее использовались другие модели. Поэтому нельзя объяснять всю разницу только качеством конкретной нейросети.
Но для разработки продукта вывод очевиден: хороший AI Checker — это не кнопка «Отправить документы в нейросеть». Необходимо проектировать сам процесс проверки.
Почему количество замечаний почти ничего не говорит о качестве
Отдельно протестировали локальную мультимодальную модель Qwen3-VL 8B. Формально результат выглядел впечатляюще: 47 замечаний. Но после ручной проверки подтвердилось примерно одно. Покрытие контрольного набора составило около 0,5 из 14. Этот тест хорошо показывает, почему нельзя оценивать AI Checker по количеству сгенерированных пунктов.
Если инженер получает 47 замечаний и вынужден отклонить 46 из них, нейросеть не экономит время, а создаёт дополнительную работу. Каждый ложный результат необходимо прочитать, найти соответствующее место в документации, проверить контекст и принять решение. Поэтому одна из ключевых характеристик такой системы — доля действительно подтверждаемых замечаний.
Более сильная модель дала принципиально другой результат
В финальной серии тот же комплект был проверен моделью GPT-6 Astra.
Она сформировала 23 замечания:
21 подтвердилось;
одно оказалось ложным;
одно было отнесено к спорным.
Подтверждаемость составила около 91%. При этом модель обнаружила 13 из 14 контрольных дефектов и нашла ряд проблем, которых не было в предыдущих отчётах.
Наиболее показательные результаты выглядели так:
Подход
Замечаний
Подтверждаемость
Покрытие контрольных дефектов
Глубокий многоступенчатый анализ
42
около 74%
10,5 / 14
Один из прогонов GPT-5.6
5
100%
5/14
Лучший прогон GPT-5.6
12
100%
8/14
Локальная Qwen3-VL 8B
47
около 2%
0,5/14
GPT-6 Astra
23
91%
13/14
Главный результат здесь — именно сочетание высокой полноты и высокой подтверждаемости.
AI начинает выполнять не отдельные проверки, а цепочки рассуждений
С развитием моделей менялось не только количество найденных проблем, но и характер проверки.
Сопоставление данных между листами
AI мог заметить, что масса одного изделия на нескольких листах отличается от значения в сводной спецификации, а затем проследить, как это расхождение влияет на итоговую массу сборной конструкции. Это уже не чтение отдельной надписи, а сопоставление связанных данных из нескольких частей
Проверка ведомостей и спецификаций
Модель сравнивала локальные спецификации со сводными ведомостями и находила случаи,
когда сумма элементов не соответствовала итоговому значению. По сути, AI выполнял последовательность действий, которую обычно выполняет инженер:
Находит исходные значения.
Понимает связь между ними.
Выполняет расчёт.
Находит итог в другой таблице.
Сравнивает результаты.
Показывает место расхождения.
При этом простую арифметику не обязательно оставлять на усмотрение языковой модели. Там, где существует точная формула, расчёт лучше выполнять программно, используя AI для поиска исходных данных и объяснения результата.
Поиск аномалий
Ещё один полезный сценарий — поиск значений, резко отличающихся от соседних.
Например, если у большинства аналогичных узлов используется одно значение, а в одном месте стоит существенно другое; если почти везде предусмотрен одинаковый зазор, а в одном случае указан ноль; если среди целых размеров появляется одно необычное дробное значение.
Человеку сложно систематически отслеживать такие отклонения в десятках похожих листов. Для системы, способной собрать значения по всему комплекту, это естественная задача.
Межлистовые ссылки — один из наиболее перспективных сценариев
Проектная документация — это не набор независимых страниц.
На одном листе находится общий план, на другом — узел, на третьем — спецификация, на четвёртом — ведомость. Одни и те же элементы и ссылки повторяются в разных частях комплекта. В тестовой документации были случаи, когда ссылки вели на неправильный лист, узел или текстовый пункт. В одном месте присутствовала некорректная самоссылка. Ранние проверки находили подобные проблемы эпизодически. Более сильная модель смогла рассматривать их уже как системную задачу. В перспективе AI должен переходить от восприятия проекта как последовательности картинок к построению графа связей документации: элемент → лист → узел → спецификация → ведомость → ссылка → итоговое значение.
Тогда проверять можно не отдельные страницы, а целостность документации в целом.
Не каждое расхождение является ошибкой
Ещё одно важное изменение — способность более сильных моделей отделять ошибку от неоднозначности. Например, рассчитанный геометрически объём конструкции может не совпадать с числом в таблице. Но при дополнительной проверке оказывается, что одно значение приведено для одного элемента, а другое — для группы элементов. Формально расчёт может быть правильным. Проблема в другом: база расчёта явно не обозначена.
Хорошая AI-проверка должна в таких случаях не утверждать:
«Объём рассчитан неправильно».
А указывать:
«В одной спецификации используются разные базы расчёта, но это явно не обозначено, что создаёт риск неправильной интерпретации».
Иногда задача AI — не объявить нарушение, а показать инженеру место, которое требует
внимания.
Нормативная проверка остаётся сложной задачей
Практически во всех экспериментах риск ложных замечаний увеличивался, когда модель переходила от поиска внутренних противоречий к утверждениям вида: «Это нарушает такой-то пункт такого-то СП».
Большая языковая модель не должна быть единственным источником истины по нормативной базе.
Более надёжный подход заключается в том, чтобы AI сначала обнаруживал потенциальную проблему, а затем система проверяла нормативное основание по контролируемой базе актуальных СП, ГОСТ, технических регламентов, корпоративных стандартов и требований заказчика.
Если однозначного основания найти не удалось, система должна прямо об этом сообщить и передать вопрос специалисту.
Качество входных данных не менее важно, чем качество модели
В одном из прогонов модель сама указала, что часть изображений была обрезана, а некоторые фрагменты текста повреждены. Если система неправильно подготовила чертёж и не передала модели часть информации, никакая мощность AI не позволит проверить то, чего он не получил. Поэтому подготовка документов — полноценная часть AI Checker. Необходимо контролировать корректность обработки PDF, качество изображений и текста, порядок страниц, полноту контекста и возможность связать найденную проблему с конкретным местом исходного документа.
Что в итоге показал эксперимент
Главный вывод исследования: проверка проектной документации — это не задача одной нейросети. Это задача системы.
Современные мультимодальные модели уже способны находить сложные инженерные несоответствия. Но устойчивый результат возникает, когда вокруг модели выстроен правильный процесс:
весь комплект последовательно анализируется;
данные с разных листов связываются между собой;
числовые значения извлекаются и сопоставляются;
точные расчёты выполняются программно там, где это возможно;
перекрёстные ссылки проверяются системно;
АІ ищет не только типовые ошибки, но и аномалии;
потенциальные замечания перепроверяются;
нормативные основания подтверждаются по контролируемым источникам;
каждое замечание можно связать с конкретным местом документации.
Эксперимент также показал, насколько опасно ориентироваться на объём AI-отчёта.Можно получить 47 замечаний с практически нулевой полезностью. А можно получить 23 замечания, 21 из которых подтверждается, при обнаружении 13 из 14 контрольных дефектов.
Поэтому для важны четыре метрики:
Сколько реальных проблем найдено, сколько пропущено, сколько создано ложных замечаний и сколько времени инженера удалось сэкономить.
Как это будет работать в SIGNAL
Сегодня AI Checker уже существует в виде отдельного desktop-приложения и доступен компаниям для тестирования на собственной документации. Получить текущую версию и инструкцию можно через техническую поддержку SIGNAL или по адресу info@sgnl.pro.
Следующий этап — встроить проверку непосредственно в SIGNAL DOCS и существующий процесс согласования документации. Для пользователя сценарий должен выглядеть естественно: в SIGNAL DOCS загружается документация → формируется комплект → комплект отправляется на согласование → первым этапом его проверяет AI → на следующем этапе эксперт получает документацию вместе с результатами AI-проверки.
Эксперт проходит по найденным AI местам и принимает решение по каждому из них. Те результаты, с которыми он согласен, он может эскалировать в обычные замечания SIGNAL на своём этапе проверки и затем передать их проектировщику в рамках стандартного процесса согласования.
Таким образом, AI не создаёт параллельный процесс. Он становится первым уровнем проверки внутри уже существующего процесса SIGNAL.
Замечание должно сразу приводить к месту на чертеже
В текущей desktop-версии AI Checker формирует текстовый отчёт. В SIGNAL результат должен быть связан с конкретным местом в документации. Если AI обнаружил потенциальную проблему, эксперт сможет открыть соответствующий лист и сразу перейти к нужному фрагменту чертежа.
Если вывод подтверждается, из АI-пометки можно сформировать обычное замечание SIGNAL.
Система сможет предварительно заполнить известные ей данные: описание, тип замечания, местоположение, привязку к документу и, если основание надёжно установлено, ссылку на нормативное требование.
Эксперт проверяет результат и принимает окончательное решение.
Конфиденциальность и доступ к AI
Для корпоративных клиентов важно, какие данные передаются внешней модели.
Поэтому перед AI-проверкой SIGNAL предусматривает анонимизацию документации: сведения, которые не нужны для инженерного анализа — например, персональные данные, названия участников проекта и другие чувствительные реквизиты, — могут быть удалены или скрыты до передачи материала модели. Сейчас отдельные этапы этого процесса реализованы отдельными сервисами. В дальнейшем они должны работать автоматически внутри SIGNAL. Там же планируется централизовать доступ к используемым AI-моделям, чтобы пользователю не требовалось самостоятельно настраивать VPN или хранить ключи доступа к внешним сервисам.
Может ли AI заменить инженера-проверяющего?
Сегодня — полностью нет. AI по-прежнему может пропускать ошибки, неверно интерпретировать контекст и ошибаться в нормативных основаниях. Окончательное решение должен принимать квалифицированный специалист.
Но результаты экспериментов позволяют поставить вопрос иначе: насколько больше документации сможет проверить один инженер, если значительную часть предварительной работы возьмёт на себя AI?
Сегодня значительная часть проверки состоит из повторяющихся операций:
просмотреть десятки листов;
сопоставить спецификации;
проверить ссылки;
сравнить повторяющиеся значения;
проверить количества и суммы;
найти аномалии;
убедиться, что изменение в одном месте учтено во всех связанных документах.
Именно эту работу AI способен постепенно брать на себя. Человек при этом концентрируется на сложных, спорных и ответственных решениях. Пока рано говорить, во сколько именно раз это позволит увеличить производительность инженера. Для этого технологию необходимо проверить на значительно большем количестве проектов, разделов и реальных процессов. Но когда система обнаруживает 13 из 14 контрольных дефектов, а более 90% её замечаний подтверждаются специалистом, вопрос о практической эффективности AI-проверки уже перестаёт быть теоретическим.
От эксперимента — к новому уровню инженерного контроля
Сегодня вопрос уже не в том, способен ли АІ увидеть ошибку на проектном чертеже. Способен. Следующий вопрос гораздо важнее: «можно ли построить вокруг современных моделей достаточно надёжную систему, которая будет методично проверять документацию, не создавать лишнего информационного шума и значительно увеличивать производительность инженера?».
Эксперименты показывают, что в SIGNAL постепенно приближаемся именно к этому. Конечная цель SIGNAL — не отдельный AI-сервис и не ещё одно окно с чат-ботом. Это автоматический первый уровень инженерного контроля внутри привычного процесса согласования документации: проектировщик → АІ-проверка → эксперт → подтвержденные замечания → проектировщик.
AI выполняет массовую предварительную проверку, а человек принимает окончательные инженерные решения. И именно в таком разделении работы мы видим основной практический потенциал технологии.
Испания остается одной из самых привлекательных стран Европы для релокации: сюда переезжают удаленщики, предприниматели, семьи и люди с пассивным доходом.
Межрайонная ИФНС №4 по Башкортостану подала в Арбитражный суд Петербурга и Ленобласти заявление о банкротстве ООО «Л1Строй Север» — структуры девелопера «Л1».
11-09-2026 18:00
13 
