Игорь Рогачёв в серии постов «СтроИИка» предложил не очередную подборку промтов, а системный взгляд на внедрение ИИ в корпоративную среду. С позиции управленца, а не инженера-энтузиаста.
🔴Волшебного промта не существует
Качество работы LLM определяется не формулировкой запроса, а подготовкой данных и архитектурой. Хорошие промты из открытых каналов решают задачу локально, но немасштабируемы. Ими воспользуются единицы. Остальные сотрудники не станут осваивать промт-инжиниринг — их нужно натаскивать, и без личной мотивации результат непредсказуем.
🔴От проблемы сотрудника к проблеме компании
Локальная неэффективность отдельного участка не всегда требует оптимизации — руководитель видит картину целиком и знает, где потери действительно критичны. Внедрение ИИ начинается не с «давайте автоматизируем», а с комплексного обследования, выявляющего реальные узкие места.
🔴Архитектура системного ИИ: 5 слоёв
На примере проверки ПД по ПП87 Рогачёв показывает, как выстроить решение, дающее предсказуемый результат независимо от того, кто нажал кнопку.
Слой 1. ИИ-утилита вместо прямого общения с LLM
Проверенные промты прячутся в сервис с интерфейсом: загрузил ПД, выбрал тип объекта — получил структурированный ответ с доказательством. Инженер не думает о моделях и промтах. Качество пока приемлемое — пользователи загружают что попало, эксперты нужны постоянно для непрерывного тестирования.
Сквозной слой. Безопасность
С первого обращения к внешней LLM. Система, а не пользователь, решает, что отправлять: классифицирует, маскирует чувствительные данные. Никакие инструкции не гарантируют, что сотрудник не ошибётся — задача технически не дать ему такой возможности.
Слой 2. Нормализация входящих данных
ПД — сложный источник: рамки, штампы, таблицы, схемы, сканы. Нужен пайплайн, который понимает структуру, выделяет текст, таблицы, изображения, сохраняет метаданные — номера листов, таблиц, координаты. Не просто PDF → Markdown, а нормализованное представление, позволяющее указать инженеру точное место проблемы.
Слой 3. Формализация проверки
ПП87 — набор требований с разной применимостью. Норматив превращается в машинно-читаемую структуру: условия, что искать, где, критерий, источник. LLM получает сотню конкретных задач вместо абстрактной «Проверь документацию». Всё, что проверяется кодом, модели не отдаётся. Переход от утилиты к корпоративному сервису.
Слой 4. ПД как база знаний
Вместо того чтобы каждый раз скармливать модельке всю документацию, строится индексируемая база с гибридным поиском: по смыслу, по точному совпадению, по структуре, по типу сущности. Только после этого контекст передаётся LLM. Каждый вывод — с привязкой к первоисточнику. Ядро пригодно для нормоконтроля, сравнения версий, проверки ТЗ, извлечения ВОР. Один раз решается проблема подготовки ПД — инфраструктура для множества сценариев.
Слой 5. Онтология и граф
R&D-уровень. Документация становится моделью проекта. Насос — не текст, а объект с параметрами и связями с трубопроводами, электрикой, автоматикой, расчётами. Онтологическая модель и граф конкретного проекта. Система отвечает не «Где это?», а «Что будет, если заменить насос?» — проверяя цепочку зависимостей на основе реальных связей, а не генерации LLM. ИИ становится слоем проектного процесса и поддержки решений.
🔴В итоге
При системном подходе — не перечень промтов, а ИИ-утилиты для снятия трудоёмких задач, затем ИИ-слой как элемент процесса. Прямой доступ к LLM — отдельный проект для продвинутых. Массовое применение — не куча подписок, а кастомные решения под задачи компании.
ИИ в строительстве — не про магию и эксперименты. Про системную архитектуру, где каждый слой решает конкретную проблему: убирает человеческий фактор, нормализует данные, формализует нормативы, строит базу знаний и в перспективе создаёт модель проекта.
#ИИ #ИИ_ИНП #TechNews #ИНП
📲MАХимально на связи🔴
🤖 подписывайтесь:
@NextGenInfrastructure