L2 · Методичка: внедрение ИИ в генпроекте

L2 · уровень практика

Внедрение ИИ в workflow генпроектировщика

Разворот тезисов презентации L1 в прикладную методологию: как это работает в процессе бюро, где остаётся человек, какими инструментами и с какой нормативной привязкой.

Методология внедрения ИИ — прикладная методичка

Контекст и обоснование

Российский генпроектировщик полного цикла выпускает проектную (П) и рабочую (РД) документацию по составу ПП №87 от 16.02.2008 (для ОКС — разделы 1–12, п. 10) и оформляет её по ГОСТ Р 21.101-2020 (СПДС). Ключевой «фильтр качества» — экспертиза проектной документации на стадии П.

Как устроена экспертиза (и почему это дорого)

Виды: государственная (ФАУ «Главгосэкспертиза России» и региональные госэкспертизы) и негосударственная (аккредитованные организации). Для большинства частных ОКС допустима негосударственная.
Результат: положительное либо отрицательное заключение. Отрицательное → доработка и повторная подача (повторная экспертиза по сокращённому составу — только изменённое).
Срок: до 42 рабочих дней (ПП РФ №145 от 05.03.2007), для отдельных объектов +до 30 раб. дней [S4]. Каждый цикл доработки сдвигает все последующие стадии.
Природа замечаний: значимая доля — формальные и комплектностные (отсутствие раздела/обоснования, несоответствие оформления СПДС, расхождение между разделами). Доля отрицательных заключений Главгосэкспертизы — ≈10% (снижение с 20% в 2015) [S1]; именно формальные дефекты ловит проверка полноты.

Правило цены ошибки 1–10–100

Дефект, стоящий условную «1» на стадии П, превращается в «10» после экспертизы и в «100» на стройке. ИИ-контроль смещает обнаружение максимально влево — к моменту выпуска раздела, до подачи.

Почему именно РФ-нормативность помогает ИИ

Жёсткая регламентация (ПП №87, СП, СПДС), которая «душит» творчество, для проверяющего ИИ — преимущество: есть однозначный машиночитаемый эталон. ТИМ-мандат (ПП №331 от 05.03.2021, далее №1431) обязал вести информационную модель для госзаказа с 2022 г., с поэтапным расширением — данные госстройки структурируются, появляется цифровой след.

Карта workflow генпроектировщика

Процесс — последовательные стадии и параллельные сквозные функции. Каждая стадия: вход → содержание → выход → ответственная роль.

Стадия	Вход	Содержание	Выход	Роль
0 · Тендер	ТЗ заказчика, бюджет	оценка трудозатрат, КП	договор, ТЗ	Рук-ль / ГИП
1 · ИРД + изыскания	ГПЗУ, ТУ, кадастр	сбор ИРД; инж. изыскания	отчёты по изысканиям, свод ИРД	ГИП + изыскатели
2 · Концепция/ТЭО	ИРД, ТЗ	посадка, ОПР, ТЭП, инсоляция/КЕО	эскизный проект, ТЭО	ГАП
3 · Проектная (П)	концепция, изыскания	12 разделов ПП №87 → экспертиза	комплект ПД + заключение	ГИП + разделовики
4 · Рабочая (РД)	утв. П	чертежи СПДС, спецификации, узлы	комплекты «в производство»	разделовики + BIM
5 · Авторнадзор	РД, стройка	контроль СМР vs проект	журнал АН, изменения	ГИП/ГАП

Инженерные изыскания (стадия 1) — 4 основных вида

Геодезические — топоплан, координаты, высотная основа.
Геологические — грунты, несущая способность, подземные воды (основа для КР и фундаментов).
Экологические — фоновое состояние среды (основа для ООС).
Гидрометеорологические — климат, паводки, ветер/снег (нагрузки в КР).

Узкие места, куда метим ИИ

Сбор/сверка ИРД · параллельная работа разделов без связных данных (рассинхрон АР/КР/ИОС) · текстовые разделы · нормоконтроль перед подачей · спецификации в РД.

Методология выбора точки внедрения

Чтобы не автоматизировать «всё подряд», каждая задача оценивается по формуле Приоритет = Рутина × Проверяемость × Цена ошибки. Ниже — рабочий рубрикатор: оцените каждый множитель по шкале 1–3 и перемножьте (макс. 27).

Критерий	1 балл	2 балла	3 балла
Объём рутины	эпизодически	заметная доля времени	пожирает человеко-недели
Проверяемость	ответ субъективен, трудно проверить	проверяемо экспертом за время	есть однозначный эталон (пункт нормы)
Цена ошибки	критична даже под надзором	умеренная, ловится на ревью	низкая при HITL — человек отсекает

Разбор примера: Зона 1 (нормоконтроль полноты)

Рутина = 3 (ручная вычитка сотен страниц) · Проверяемость = 3 (есть пункт ПП №87) · Цена ошибки = 3 (HITL: нормоконтролёр отклоняет ложное). Итог 27/27 — приоритет максимальный. Сравните: «принятие конструктивной схемы» — Проверяемость 1, Цена ошибки 1 → ИИ неуместен как решающий, только как справочный.

Две дисциплины-предохранителя

Human-in-the-loop (HITL): ИИ — ассистент; финальное решение и подпись за человеком. Снимает юридический вопрос ответственности за ПД.
Recall-first: при неуверенности система помечает «под вопросом» и привлекает человека, а не скрывает. Пропуск (false negative) опаснее ложного срабатывания (false positive): первый уходит в экспертизу, второй гасится на ревью за секунды.

Передаваемый навык

Дав бюро сам метод оценки, мы позволяем находить новые точки самостоятельно — методичка становится инструментом мышления, а не только каталогом наших 7 зон.

Каталог 7 зон внедрения

Зоны ранжированы по выполнимости с учётом ограничения «BIM есть, но несвязно». H1 работает на документах уже сейчас; H2 требует связной модели и СОД. Ниже — сводная таблица и подробные карточки.

#	Зона	Стадия	Сейчас?	Тип ИИ	Гор.
1	Нормоконтроль + полнота ПД	3–4	да	RAG + правила	H1
2	Извлечение ИРД/ТУ/ГПЗУ	1	да	OCR + LLM	H1
3	Генерация текстовых разделов	3	да	LLM/шаблоны	H1
4	Спецификации/ведомости из BIM	4	СОД	правила+LLM	H2
5	Приоритизация коллизий	3	модель	ML	H2
6	Генеративная концепция/посадка	2	частично	gen-design	H2
7	Авторнадзор по фото	5	as-built	CV	H2

Нормоконтроль и полнота ПД

Стадия: П и РД (3–4)
Вход → выход: комплект ПД + задание → ведомость замечаний с основаниями
Тип ИИ: OCR + RAG + движок правил
Инструменты: OCR-движок · векторная СУБД · LLM (локально) · оркестратор
Эффект: меньше замечаний экспертизы; быстрее нормоконтроль
Предпосылки: нет (работает на документах)

Извлечение данных из ИРД/ТУ/ГПЗУ

Стадия: ИРД (1)
Вход → выход: разнородные PDF/сканы ТУ, ГПЗУ → структурированная таблица параметров
Тип ИИ: OCR + LLM-структуризация
Эффект: нет «потерянных» требований ТУ → меньше замечаний
Предпосылки: нет

Генерация текстовых разделов

Стадия: П (3)
Объекты: ПЗ, ООС, ПОС, МОПБ — шаблонные тексты
Тип ИИ: LLM по шаблонам + проверка норм (RAG)
Эффект: черновик за минуты вместо дней; человек редактирует
Риск: галлюцинации → обязательная сверка с нормой

Спецификации и ведомости из BIM

Стадия: РД (4)
Вход → выход: связная модель → спецификации, ведомости объёмов
Тип ИИ: правила/скрипты + LLM-сверка наименований
Предпосылки: СОД + стандарт моделирования

Приоритизация коллизий

Стадия: П (3)
Задача: отсеять «шумовые» коллизии, выделить значимые
Тип ИИ: ML-классификация поверх clash-detection
Предпосылки: связная координационная модель

Генеративная концепция / посадка

Стадия: концепция (2)
Задача: варианты посадки/планировок по нормам (инсоляция, ТЭП)
Тип ИИ: generative design + проверка норм
Предпосылки: параметрическая среда

Авторнадзор по фото

Стадия: авторнадзор (5)
Задача: сравнение фото со стройки с проектом/моделью
Тип ИИ: computer vision
Предпосылки: as-built модель, организованная фотофиксация

Общий актив

Зоны 1 и 3 разделяют машиночитаемую базу норм (СП/ГОСТ/ПП87). Построив её один раз для нормоконтроля, бесплатно усиливаем генерацию текстов.

Зона 1 — эталонная проработка

Флагманский пример: проверка полноты комплекта ПД для ОКС (МКД) по ПП №87. Слой A — комплектность; вход — PDF (часто сканы) + DOCX; эталон — динамический; режим — recall-first + HITL.

5.0 Эталон состава: 12 разделов ПП №87 (п. 10, ОКС)

№	Раздел	Марка / примечание
1	Пояснительная записка	`ПЗ`
2	Схема планировочной организации земельного участка	`ПЗУ` (СПОЗУ)
3	Архитектурные решения	`АР`
4	Конструктивные и объёмно-планировочные решения	`КР`
5	Сведения об инженерном оборудовании, сетях ИТО (ИОС)	5.1 эл-во `ЭОМ` · 5.2 ВС · 5.3 ВО `ВК` · 5.4 `ОВ` · 5.5 связь `СС` · 5.6 газ · 5.7 технол. `ТХ`
6	Проект организации строительства	`ПОС`
7	Проект организации работ по сносу/демонтажу	`ПОД` — при наличии сноса
8	Перечень мероприятий по охране окружающей среды	`ООС`
9	Мероприятия по обеспечению пожарной безопасности	`МОПБ` (ФЗ-123)
10	Мероприятия по обеспечению доступа инвалидов	`ОДИ`
10(1)	Требования энергоэффективности и оснащённости приборами учёта	`ЭЭ`
11	Смета на строительство	`СМ` — обязательна при бюджете
12	Иная документация (в т.ч. требования к безопасной эксплуатации для МКД)	по ГрК / ФЗ

Почему эталон динамический

Не все разделы обязательны всегда: раздел 7 (ПОД) — только при сносе; смета (11) — при бюджетном финансировании. Поэтому система сначала читает задание на проектирование и формирует чек-лист под конкретный проект, а не «штрафует» за отсутствие неприменимого раздела.

5.1 Конвейер из 6 компонентов

Канон-схема конвейера · shared/diagrams/zone1-pipeline.md

Компонент 1–2 подробнее. OCR распознаёт основную надпись (штамп) по ГОСТ Р 21.101 (формы 3/4/5/6): обозначение документа, наименование, стадия (П/Р), номер листа. По коду марки в обозначении (АР, КР, ЭОМ, ВК, ОВ, ПЗ…) документ маршрутизируется к нужному разделу — так строится дерево комплекта.

5.2 Модель данных «пункт чек-листа»

Основание — пункт ПП №87 / пункт задания / пункт стандарта бюро.
Стратегия — deterministic (наличие в дереве) или semantic (RAG по тексту).
Статус — есть нет под вопросом (обязателен при неуверенности).
Доказательство — цитата + место (файл/лист) либо обоснование отсутствия.

5.3 Примеры пунктов чек-листа (МКД)

Стратегия	Пункт проверки	Основание
`deterministic`	Наличие раздела 5.1 «Система электроснабжения» отдельным томом	ПП №87 п.10
`deterministic`	Основная надпись присутствует на каждом листе графики	ГОСТ Р 21.101 ф.3
`semantic`	В ПЗ приведены реквизиты ГПЗУ и ТУ на подключение	ПП №87 п.10 (ПЗ)
`semantic`	В МОПБ есть расчёт пожарного риска либо обоснование непревышения	ФЗ-123; ПП №87
`semantic`	В ООС есть расчёт образования отходов строительства	ПП №87 (ООС)

5.4 Образец ведомости замечаний (выход)

#	Объект	Основание	Статус	Место
1	Раздел 10(1) Энергоэффективность	ПП №87 п.10	нет	раздел отсутствует
2	Реквизиты ТУ в ПЗ	ПП №87 (ПЗ)	под вопросом	ПЗ, с. 14 — формулировка неоднозначна
3	Штамп на листах АР	ГОСТ Р 21.101	есть	АР, листы 1–28

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

5.5 Роль нормоконтролёра в новом процессе

Меняется: рутинная вычитка на полноту → проверка/отклонение готовых замечаний с основаниями. Остаётся: профессиональное суждение, подпись, ответственность. ИИ снимает объём, но не полномочия.

5.6 Классы инструментов (вендоро-нейтрально)

OCR-движок

рус, таблицы, штампы

Tesseract · PaddleOCR · Yandex Vision

Векторная СУБД

для RAG по нормам

Qdrant · Milvus · pgvector

LLM (закрытый контур)

On-Premise

Qwen · Llama · GigaChat

Движок правил + HITL

оркестрация и ревью

собственная сборка

Путь роста в слой B

Содержательная проверка соответствия СП/ГОСТ добавляется как новая strategy у пунктов чек-листа — без переписывания движка. Ниже — как это устроено.

5.7 Слой B — содержательная проверка соответствия СП

Слой A отвечает на вопрос «раздел есть?». Слой B — «решение соответствует норме?». Механика та же (требование → доказательство), но добавляется извлечение числовых значений из текста, таблиц и чертежей и их сравнение с требованием нормы.

Проверка (МКД)	Норма	Что сравнивает ИИ
Продолжительность инсоляции жилых помещений	СанПиН 1.2.3685-21; СП 54.13330	расчётная инсоляция vs нормативная по зоне
Ширина путей эвакуации и выходов	СП 1.13130	фактическая ширина vs минимально требуемая
Противопожарные расстояния между зданиями	СП 4.13130	факт. расстояние vs требуемое по степени огнестойкости
Доступность для МГН (пандусы, габариты)	СП 59.13330	уклон/ширина vs предельные значения
Высота жилых помещений	СП 54.13330	факт. высота vs минимум (≥ 2,5 м)

Расширение модели данных для слоя B

Требуемое значение — извлекается из нормы (RAG по СП).
Фактическое значение — извлекается из проекта (текст / таблица / штамп / спецификация).
Вердикт — соответствует / нарушение / под вопросом + оба основания (пункт СП и место в проекте).

Почему слой B сложнее и идёт после A

Ошибка извлечения числа (например, спутать высоту этажа и высоту помещения) ведёт к ложному вердикту, поэтому: (1) обязательный HITL на каждом числовом сравнении; (2) учёт исключений и СТУ (специальные техусловия меняют требование); (3) старт только после стабильного слоя A. Расчётные проверки (инсоляция, теплотехника) ИИ не пересчитывает, а сверяет наличие и непротиворечивость результата — расчёт остаётся за профильным ПО и инженером.

Дорожная карта и предпосылки

Внедрение идёт двумя горизонтами, чтобы не ждать «идеального BIM».

Канон-схема дорожной карты · H1 финансирует H2

Что такое СОД/CDE и зачем она для H2

СОД (Среда общих данных, CDE) — единое управляемое хранилище проектных данных с регламентом статусов. Международный ориентир — ISO 19650; российская практика — ГОСТ Р серии 10.00 и требования Минстроя. Без СОД зоны 4–7 невозможны: спецификации и коллизии берут данные из связной модели, а модель должна жить в управляемой среде.

Статусы данных (CDE): в работе (WIP) → согласовано (Shared) → выпущено (Published) → архив (Archived).
Информационные требования: EIR (требования заказчика) и BEP (план реализации) задают, какие данные и в каком виде ведутся.
Стандарт моделирования бюро: правила именования, LOD/уровни проработки, атрибутивный состав — иначе ИИ нечего сверять.

Связать «несвязный BIM» — отдельный проект

Идёт параллельно H1: аудит текущих моделей → выбор СОД → стандарт моделирования → пилотная координация. Финансируется эффектом H1.

Риски и их снятие

Реестр с оценкой «вероятность × влияние» (В — высокое, С — среднее, Н — низкое) и мерой снятия.

Риск	Вер.	Влияние	Мера снятия
«Галлюцинации» модели	С	В	RAG (ответ только по документам) + доказуемость (ссылка+место) + HITL
«Мусор на входе» — плохой OCR скана	С	В	оценка уверенности OCR; страницы ниже порога → «под вопросом», не «ок»
Юр. ответственность за ПД	В	В	финальная подпись человека; ИИ — рекомендательный
Устаревание норм	В	С	версионируемая база норм с датами редакций СП/ГОСТ
Утечка данных проекта	Н	В	локальный контур (On-Premise); запрет внешних API для конфиденциального
Сопротивление команды	С	С	позиционирование «щит от рутины»; быстрые победы H1; обучение (L3)
Переусложнение / vendor lock-in	С	С	вендоро-нейтральная архитектура; начинать с минимального пилота

Протокол пилота

Пилот берёт нормоконтроль полноты ПД для МКД и измеряет эффект «до/после» на реальных архивных комплектах.

Этапы и ориентировочный срок

Этап	Содержание	Срок
0 · Подготовка	экспресс-аудит ТИМ-зрелости; сбор архива проектов с известными замечаниями экспертизы	[🏢] нед.
1 · Настройка эталона	ПП №87 + типовое задание МКД + стандарт бюро; загрузка норм в базу	[🏢] нед.
2 · Прогон	5–10 размеченных комплектов (полные и с известными пропусками)	[🏢] нед.
3 · Оценка	замер KPI, ревью нормоконтролёром, решение о масштабировании	[🏢] нед.

KPI (целевые значения ставятся с бюро от его базовой линии)

Recall пропусков требований ПП №87 — доля реальных пропусков, которые система нашла. Цель 🏢.
Время нормоконтроля «до/после». Цель 🏢.
Доля снятых замечаний экспертизы по полноте/комплектности. Цель 🏢.
Трудозатраты ГИП на сверку (чел.-ч/комплект). Цель 🏢.

Методика измерения recall

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

Принцип честности метрик

Целевые «95%» и «в 3 раза» не выдумываются заранее — KPI измеряется от базовой линии конкретного бюро.