СтроИИка Рогачёва

Бытовые наблюдения непрограммиста
#Бесполезные_мысли #Бесполезные_мысли@IIstroika
Объем применения ИИ: 20%

Как и все мальчики моего возраста, я частенько занимаюсь цифровым рукоблудием. Сейчас это модно называть вайбкодингом. Конечно, пока эта интеллектуальная девиация не перетекает в радикальные формы типа B2B SaaS, но иногда всё же заносит на поворотах. Поэтому решил поделиться рядом наблюдений. Интересно, как у вас? И не делайте вид, что вы все приличные и ничем таким постыдным не занимаетесь!
В основном наблюдения построены вокруг взаимодействия с OpenAI (Codex, API).

1️⃣ИИ сильно недооценивает техническую сложность реализации твоей новой идеи.
Я регулярно прихожу к ИИ с идеями что-то сделать. Обсудить, так сказать. И буквально на каждую идею он выдаёт:

Давай, братан, у тебя уже 30% бэкенда готово. Тут делов-то на 20 минут, вошли и вышли (с)...

Через 5 недель, отлаживая жуткий пайплайн и спустя миллиарды токенов, понимаешь, что довести это чудо до работоспособности будет очень сложно. Хотя 2 недели назад ИИ говорил, что проект готов на 90%.

2️⃣Оказывается, ИИ тебе писал, сколько это займёт, но ты, скорее всего, пропустил это мимо ушей.
Вот такое необычное когнитивное искажение я словил. Когда обсуждал проект с ИИ, он мне честно говорил, что понадобится не меньше месяца на реализацию. На что я говорил себе: да ладно, там нет ничего сложного. Спустя месяц, впервые запуская проект, я понял, что он не ошибался. И такое было много раз.

3️⃣ИИ маниакально зациклен на безопасности. Особенно если разрешить ему самому решить, сколько безопасности вам нужно.
Намедни собирал бэкенд с ИИ и доверил ему разработку системы безопасности без моего управления. Дык, по итогу, на готовом сервисе, чтобы войти под суперадмином, пришлось проворачивать настоящую спецоперацию уровня ядерного чемоданчика, а нормы безопасности были такими, что шагу выполнить пользователю нельзя без одобрения админа и суперадмина. Эта ситуация повсеместна. 👮
Я как-то собирал агента на VPS-сервере и решил довериться тому, что рекомендует ИИ. В итоге этот агент мог только отвечать на прямые вопросы, любые другие шаги превращались в DevOps-ад. Всё из-за маниакальной системы безопасности.👮
Если отдать ИИ проектирование безопасности без явно заданной модели угроз, допустимого риска и требований к UX, он почти неизбежно начинает перестраховываться.
Проблема в том, что модель не знает, где у тебя проходит граница между «безопасно» и «этим невозможно пользоваться», и выбирает консервативный вариант.

4️⃣Следи за тем, что делает ИИ.
Не знаю, как у других, но я не представляю, что можно поставить задачу, включить выполнение цели и типа пусть ИИ сам решает задачу как хочет. 👀
Мой опыт говорит, что он решит таким образом, что волосы зашевелятся даже там, где их нет. Нельзя отпускать ИИ надолго без контрольных точек, чтобы ловить момент, когда его потянет на блудняк. Хотя все ограничения строго прописаны везде, где только можно. Уже неоднократно ловил момент, когда ИИ начинал делать какой-то функционал, который особо не нужен, но с его точки зрения это логично.

5️⃣Не доверяй слепо его рекомендациям по проверкам. Особенно когда вместо локального теста он предлагает очередной полный аудит проекта силами LLM.
Очень частая ситуация, когда ведётся сложная сборка какой-либо информации (люблю я строить онтологические модели для разных задач) или просто какой-либо этап разработки, и он говорит, что надо сделать проверку целостности данных всего проекта. Хотя на прошлом шаге он уже это делал. Каждый такой шаг просто пожирает токены/лимиты. Но как только задаёшь вопрос, так ли необходима такая проверка, оказывается, что нет, и он просто решил перестраховаться.😡

6️⃣Если ребёнок в соседней комнате затих, жди беды. Тут то же самое.
На одном из проектов ИИ начал гонять безумное количество долгих тестов на GitHub. Вроде что-то делает, ничего не просит, проблем нет. Я решил поинтересоваться: а что это ты там делаешь? Он и говорит: у тебя на сервере нет нужного ПО, поэтому я вынужден тесты прогонять через жутко медленные пайплайны на GitHub. Дык какого хера ты не сказал, что это ПО нужно?😠
Теперь во всех инструкциях указываю проверить список доступного ПО и сообщить, если чего-то не хватает. Всегда интересуйтесь, чем же занят ваш ИИ и по какому пути он идёт. Могут быть сюрпризы.

7️⃣ИИ подвержен туннельному синдрому.
Это касается и разработки, и просто консультаций. ИИ знает всё, но в некоторых темах он сам по себе может зарыться в одно направление и копать туда «до талого». Не доверяйтесь слепо, всегда сами старайтесь смотреть шире и подкидывать идеи для ИИ. Возможно, будет что-то толковое. Только учтите, у моделей вообще есть известная склонность соглашаться с пользователем. Проще говоря, это подхалимство.❤️

8️⃣Не верь процентам готовности проекта.
Если ИИ говорит: «проект готов на 90%», это вообще ничего не значит. 90% файлов написано? 90% функциональности работает? 90% требований закрыто? 90% тестов зелёные? Я уже несколько раз видел проекты, которые были «готовы на 90%» за две недели до того, как выяснялось, что впереди ещё месяц работы.
Теперь процент готовности существует только относительно конкретного чек-листа и критериев приёмки.

9️⃣ИИ очень любит незаметно расширять задачу.
Просишь добавить кнопку. Через некоторое время выясняется, что он уже строит универсальный слой технологий на случай, если когда-нибудь появятся ещё 14 кнопок с одновременным контуром тестирования решений, которые ты не закладывал.
Особенно страшно звучит фраза: «Заодно я заметил, что архитектуру здесь можно улучшить».😫
Поэтому у меня теперь отдельно прописано: не исправлять соседние проблемы, не проводить рефакторинг и не добавлять функциональность, которую явно не просили.

Очень интересно мнение общественности. У вас такие же проблемы?🍿

Продолжение. Часть 2 из 2.

2️⃣Слой 2. Нормализация входящих данных.
Здесь начинается самое интересное. Потому что вечная истина никуда не делась:

мусор на входе = мусор на выходе.

Проектная документация вообще довольно мерзкий источник данных для машинной обработки.🤮 Рамки, штампы, колонтитулы, таблицы, сноски, перечни, схемы, картинки, графики, обозначения, номера листов, ссылки между разделами, сканы внутри PDF, таблицы внутри текста и ещё куча всего. И просто засунуть PDF на 500 страниц в LLM, далеко не лучший способ работы.
Поэтому перед моделью появляется отдельный пайплайн подготовки документации.
Он должен понять:
🟥Где структура документа
🟥Где разделы и подразделы
🟥Где основной текст
🟥Где таблицы
🟥Где изображения и схемы
🟥Где служебное оформление
🟥Где ссылки на другие части документа
🟥Что относится к конкретному листу или странице

Причём важный момент: ненужное не всегда надо просто выбрасывать.

Например, координаты объекта на странице, номер листа, номер таблицы или связь фрагмента текста с конкретным чертежом могут вообще не понадобиться LLM для ответа, но понадобятся нам потом, чтобы сказать инженеру:
«Вот здесь проблема. Лист 17, таблица 4, строка 6».

Поэтому правильнее говорить не просто о переводе PDF в Markdown, а о формировании некоторого нормализованного представления ПД, из которого уже можно отдавать модели текст, таблицы, изображения и необходимые метаданные в удобном виде.
Вот после этого качество начинает расти уже довольно заметно.
Потому что LLM получает не помойку из PDF, а подготовленные данные. И опять же, требования к пользователю уменьшаются.
Он просто загрузил документацию. Всё остальное сделал пайплайн.

3️⃣Слой 3. Формализация самой проверки.
Вот этого слоя обычно как раз не хватает в подходе «давайте сделаем хороший промт».
ПП87 это не просто текст, который надо дать почитать LLM. Это набор требований, причём часть требований применима к одному типу объектов, часть к другому, какие-то зависят от параметров проекта, какие-то требуют наличия определённых разделов, данных или обоснований.
Поэтому постепенно сам норматив тоже надо превращать в машинно-читаемую структуру.

Условно:
Из требования формируется условия применимости, далее, что необходимо найти, где это обычно находится, критерий проверки и финализируем источником требований.
И тогда LLM уже не получает абстрактную задачу: «Проверь документацию на соответствие ПП87».
Она получает сто конкретных маленьких задач. Например:
🟥Применимо ли требование
🟥Есть ли необходимая информация
🟥Где она находится
🟥Соответствует ли найденное значение требованию
🟥Достаточно ли данных для вывода
🟥Если нет, что именно отсутствует

Не забываем то, что можно проверить обычным кодом, вообще не надо отдавать LLM!
LLM оставляем там, где требуется работа со смыслом, неоднозначным текстом, классификацией, извлечением или сопоставлением. Это очень важный принцип.

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

4️⃣Слой 4. ПД превращается в базу знаний.
А вот здесь мы уже начинаем строить ядро, которое выходит далеко за пределы одного ПП87.
Потому что после того, как мы научились качественно разбирать ПД, становится довольно глупо каждый раз заново скармливать её модели целиком. Мы превращаем документацию в индексируемую базу знаний. Здесь появляются:
🟥Структурный индекс документа
🟥Полнотекстовый поиск
🟥Семантический поиск
🟥Векторный индекс
🟥Метаданные
🟥Связи с листами, разделами и таблицами
🟥Дополнительный отбор наиболее релевантных результатов
🟥Непосредственно ядро поиска и сборки контекста для LLM

И отдельно обращу внимание: одной векторной базы здесь мало, чистый RAG редко работает нормально.
В инженерной документации огромное количество точных значений:
марки оборудования, номера помещений, обозначения систем, ссылки на СП, диаметры, классы, номера листов, позиции, шифры, GUID и т. п.

Если мне надо найти условный насос Н-17, я не хочу, чтобы система нашла мне «семантически похожий насос» Мне нужен именно Н-17.
Поэтому хороший инженерный поиск почти неизбежно становится гибридным.
🟥Где-то ищем по смыслу
🟥Где-то по точному совпадению
🟥Где-то по структуре документа
🟥Где-то по типу сущности
🟥Где-то одновременно по всему этому

А уже потом отдаём найденный контекст LLM.
Теперь у LLM есть внешний механизм поиска, который сначала находит нужные данные в ПД, а уже потом передаёт их модели для анализа.

И очень важно: каждый вывод должен сохранять связь с первоисточником.
Не просто: «Требование не выполнено», а «Требование не выполнено. Основание: пункт такой-то. Проверены такие-то разделы. На странице такой-то обнаружено это. Требуемая информация не найдена».
Вот после этого системой уже можно начинать серьёзно пользоваться.

Причём созданное ядро становится пригодно не только для ПП87.
На него можно постепенно навешивать нормоконтроль, поиск противоречий, сравнение версий, проверку ТЗ, извлечение ВОР, поиск проектных решений, анализ замечаний и десятки других сценариев.
То есть мы один раз дорого и хорошо решаем проблему подготовки и понимания ПД, а потом получаем инфраструктуру сразу под множество ИИ-сервисов.
Вот это уже называется масштабирование.

5️⃣Слой 5. Онтология, граф и инженерная логика.
Если вы дошли до этого уровня, мои советы вам уже, скорее всего, не особенно нужны.😬
Предыдущие уровни я разрабатывал и проверял собственными руками. А вот этот у меня пока находится на уровне R&D.

Причём он уже вообще не про проверку ПП87. Но если хорошо реализовать предыдущий слой, то аппетит неизбежно придёт во время еды. Потому что довольно быстро захочется спросить систему не «Где в документации указан расход насоса?», а «Что произойдёт с проектом, если я заменю этот насос на другой?» Естественно здесь обычный RAG заканчивается.
Потому что система должна понимать, что насос это не просто кусок текста.
Это конкретный объект, который относится к конкретной инженерной системе и к него есть расход, напор, мощность и другие параметры. А самое главное он связан с:
🟥Трубопроводами
🟥Эектроснабжением
🟥Автоматикой
🟥Помещением
🟥Расчётами
🟥Спецификацией
🟥Планами
🟥Схемами
🟥Требованиями нормативов

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

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

В результате этого, теоретически, мы действительно можем прийти к системе, которая скажет:

«Если заменить этот насос, проверь вот эти три расчёта, две схемы, спецификацию оборудования и данный раздел пояснительной записки. Вот почему».

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

😴В итоге.
При системном применении ИИ не должно быть перечня промтов. На первых этапах должны быть ИИ-утилиты, снимающие самые трудоёмкие задачи, затем движение к ИИ-слою как базовому элементу реализации проектного процесса и поддержки принятия решений. Доступ к прямому интерфейсу ИИ нужен, но требует отдельного проекта по организации такой работы. Говорить о том, что все должны использовать прямой ИИ, пока рано. Массовое применение ИИ это не куча подписок на ИИ-сервисы, а кастомные решения под задачи компании, которые уже сейчас могут разрабатываться внутри компании или внешними специалистами.

Проверка ПД через ИИ
#СтройпрактИИкум@IIstroika
Часть 1 из 2. Процент использования ИИ: 25%
Меня часто просят выложить практические примеры, но вы забываете, что я смотрю на ИИ не как на технологию, а на то, как это внедрять с точки зрения управленца. И поэтому опишу свой подход через призму решения конкретной задачи. Например, проверку документации на соответствие ПП87. В целом эта задача под силу современным LLM топового уровня. Для этого нужно правильно сформулировать промт и загрузить данные в топовую LLM. Например, вы можете найти множество нужных промтов у коллег с канала «AI песочница инженера» (это не реклама). Сразу же скажу: Идея, что качество ответа ИИ обеспечивается волшебным промтом, давно умерла. Это не так и качество достигается другим. Но об этом буду писать в новых постах.

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

Небольшое отступление:

Классическое, что можно услышать от рядового сотрудника: этот директор совсем, что ли, не понимает, что данная проблема важна, почему он решает другие вопросы?!
Да, он будет решать именно другие, потому что, с точки зрения руководителя, потери на этом участке ничтожны по сравнению с другими, а тратить ресурсы и время на локальную неэффективность при работающем процессе нерационально. В особенности если процесс не является узким местом корпоративных процессов. Про это целые книжки написаны, и выявить такое можно только в ходе обследования😄

Что мы видим на представленном примере с ПП87? У коллег из AI песочницы вы можете найти перечень промтов и рекомендации по улучшению. В целом всё очень толково. Но вот немасштабируемо. Меня как эксперта-управленца интересует исключительно формирование подхода/решения на уровне компании, с качественным результатом, с минимальными требованиями к сотрудникам и легко повторяемым/масштабируемым результатом.
Таким же промтом могут пользоваться лишь несколько инженеров, заинтересованных в использовании современных решений, но это не сервис и, самое главное, процесс неконтролируемый, с непредсказуемым результатом.

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

Итак, мы решили, что нам жизненно необходима проверка документации на соответствие ПП87.
Как начинается работа? Как и в примере выше: нужен доступ к качественной модели, правильно поставленная задача и хорошие промты. Если всё правильно сделано будет результат.
Но нас как раз и не устраивает вот это самое «если всё правильно сделано».

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

1️⃣Слой 1. ИИ-утилита вместо прямого общения с LLM.
Делается буквально на коленке за несколько дней как первый рабочий прототип.
Берём проверенные промты под разные типы объектов и прячем их внутрь сервиса. Навайбкодим простой интерфейс: пользователь загружает ПД, выбирает тип объекта, при необходимости указывает несколько параметров и получает результат проверки.
Всё. Инженер уже не должен знать, какую модель выбрать, какой промт написать, куда вставить ПП87, в каком порядке загружать документы и какие дополнительные инструкции дать модели.
Мы убираем прямое взаимодействие инженера с LLM, тем самым получаем чуть более контролируемый результат.

Причём я бы даже на этом уровне не заставлял LLM просто отвечать: «соответствует / не соответствует». Лучше сразу делать структурированный результат: какой пункт проверяется, применим ли он к данному объекту, найдено ли соответствующее требование в ПД, где именно найдено и почему система считает его выполненным или невыполненным.

То есть даже первый прототип должен стремиться не просто выдавать ответ, а показывать доказательство, откуда этот ответ взялся. Всё это легко прописать в JSON или MD схемах, после консультации с экспертами. Но качество всё равно будет только приемлемым.

Почему?
Потому что пользователь будет грузить что попало. Один загрузит всю ПД, другой только записку, третий зачем-то приложит ещё двадцать документов, четвёртый забудет половину исходных данных. И даже если написать инструкцию на десятки страниц, её всё равно никто читать не будет.😕

Плюс сам результат работы LLM ещё надо проверять.
В этом месте появляется первый принципиально важный элемент системного применения ИИ:

Тестирование это не этап разработки. Это постоянный процесс.

Ваши эксперты должны быть готовы к тому, что систему придётся постоянно прогонять на реальных кейсах, находить ошибки, классифицировать их и проверять, что после очередного изменения мы улучшили одно и не сломали другое. Поэтому достаточно быстро должен появиться собственный набор эталонных документов и вопросов, на которых система проверяется автоматически.

Условно: было 100 контрольных требований ПП87. Вчера система правильно проверяла 92, сегодня после обновления модели 89. Значит, у нас проблема.
Здесь же кроется неприятная новость для руководителей. Эксперты предметной области будут нужны постоянно. Особенно на первых этапах. Нельзя посадить программиста, дать ему ПП87 и через месяц получить хороший инженерный сервис.

Можно снизить количество привлечения экспертов, особенно если руководитель разработки сам хорошо знает предметную область, но полностью убрать их из процесса не получится.

🎁Сквозной слой. Безопасность и контроль данных.
Я специально не называю это слоем 2, потому что безопасность должна появляться с первого обращения к внешней LLM.
ПД, а особенно сметы и внутренняя документация компании, могут содержать не только ПДн, но и целый букет проблем⚠️. Там может быть коммерческая тайна, информация по режимным объектам, внутренние технические решения, данные заказчика и много всего интересного, что совсем не хочется однажды обнаружить на серверах супостата. И я сейчас не иронизирую, бывали такие случаи.
Поэтому пользователь вообще не должен решать, что можно отправлять в LLM, а что нельзя.

Это должна решать система.
На входе документ классифицируется, проверяется на чувствительные данные, при необходимости данные удаляются, маскируются или заменяются, а после обработки возвращаются обратно.

То есть правило, в стиле закона Мерфи:

если пользователю дали возможность ошибиться, то рано или поздно он ошибётся.

🔴Даже если подписал инструкцию.
🔴Даже если прошёл обучение.
🔴Даже если вчера клялся СБ, что всё понял ))

Поэтому задача корпоративного решения не научить человека помнить правила, а технически не позволить их нарушить там, где это возможно.

Конец Части 1 из 2.

ВНИМАНИЕ! Все трюки выполнены профессионалами. Не пытайтесь повторить их в домашних условиях это опасно!

Сколько веду предпринимательскую деятельность, всё время напрягало взаимодействие с бухгалтерами. Только не обижайтесь: я вас очень люблю, понимаю и уважаю ваш адский бухгалтерский труд.
Но я не огромная компания с кучей сотрудников, где действительно сложно вести отчётность и бухгалтерию.

Вымораживало меня то, что душа автоматизатора говорила: данное действо легко автоматизируется с помощью LLM.
Ещё несколько лет назад первые попытки посчитать налоги провалились. Благо я знал, что и как должно быть, поэтому видел, что ИИ втирает мне какую-то дичь.

Но уже в прошлом году я разобрался, как работать с памятью LLM, как заставить её знать и уважать Налоговый и Уголовный кодексы РФ, как увязывать данные и работать с актуальной нормативкой.
В итоге, провёл контролируемый практический эксперимент: все налоги были посчитаны и оплачены с помощью ИИ. И, самое главное, налоговая декларация была заполнена ИИ. Естественно под моим бдительным контролем и проверкой.

Я только проверял результат и вмешался, когда с первого раза налоговая не приняла подписанный контейнер из-за некорректного ОКТМО. Проблема возникла в связи со сменой места жительства, да и в интернете была неоднозначная информация по этому коду.

Со второго раза налоговая приняла электронную декларацию.

Это был не одиночный промпт в чат. Система работала с постоянным контекстом, проверяемой нормативной базой, исходными финансовыми данными и отдельными этапами расчёта, верификации и подготовки декларации.
И вот сегодня я заглянул в личный кабинет и увидел, что декларация успешно прошла камеральную проверку. Значит, налоговая не выявила ошибок в расчётах!

К чему это я?
Заменит ли ИИ труд бухгалтера? Пока нет. Но автоматизировать простые задачи вроде моей - легко.
И с каждым днём объём задач, которые бухгалтер сможет выполнять с помощью ИИ, будет расти.

Если бы я был бухгалтером (не дай бог!) я бы уже взял на сопровождение два десятка типовых компаний и вёл их бухгалтерию через рой агентов, настроенных под особенности налогообложения и бухгалтерского учёта в организациях такого типа. Разумеется, при наличии соответствующего профессионального опыта и интеграции с основными учётными системами.
Задача непростая, риски высокие, но она вполне реализуема.

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

Ну а в каналах про ИИ ещё сверху накроет волной воды от нейронки)

Сегодня провели с Игорем Рогачёвым @IIstroika подкаст на тему «Автоматизация проектирования и стройки: где ИИ реально работает»

Игорь Рогачёв внедряет автоматизацию в проектировании и строительстве с 2007 года — и снял об этом документальный фильм «BIM — это плохо».

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

В этом видео разберём:
• Воля, ресурсы, процессы — почему автоматизация буксует не из-за технологий
• «Людочка с экселькой», календарное планирование и другие типовые неэффективности
• Где вайб-кодинг реально спасает проектировщика: 10 часов работы → 1 час
• AI-чемпионы внутри компании — рабочий подход или ловушка
• Закрытый контур и инференс: с какой суммы реально начинать (спойлер — не с 90 млн)
• Куда пойдёт автоматизация стройки в ближайшие 2-3 года

https://youtu.be/QU1D5FPz96I

⏱ Таймкоды:
00:00 — Знакомство: 18 лет в BIM и фильм «BIM — это плохо»
05:01 — Что изменилось за 2 года, а что нет: «болото» и полка автоматизации
09:30 — Почему BIM/ТИМ занимает малую долю рынка: воля, ресурсы, процессы
15:11 — Три типовые неэффективности: «Людочка с экселькой» и календарное планирование
16:15 — Компьютерное зрение и ИИ на стройке: где хайп, а где инструмент
21:20 — AI-чемпионы внутри компании: рабочий подход и его ловушки
26:30 — Вайб-кодинг: как проектировщик за 2-3 вечера закрывает годами висящую задачу
31:38 — «Как врать при помощи статистики»: ROI автоматизации и почему цифры не считают
36:51 — С чего начать без бюджета и прогноз на 2-3 года
41:06 — Инференс в закрытом контуре: точка входа и разговор с безопасниками
47:01 — Итоги: сначала наведите порядок в BIM, потом — ИИ

@IIstroika
@god_kod_agency

И снова минутка саморекламы) Снова обсуждаем BIM, ТИМ, автоматизацию в стройке, эффекты и конечно же ИИ.

ИИ по флагу
Сейчас занимаюсь написанием внутренней архитектуры ИИ-сервисов для одного из клиентов и вот о чём задумался.
Пожалуй, этот год ну, может быть, максимум следующий последний, когда в корпоративную архитектуру ещё можно относительно беспрепятственно закладывать использование сервисов OpenAI и Anthropic.
Уже сейчас доступ к этим сервисам возможен только через прокси или VPN, но всё же возможен. При этом уже была волна блокировок аккаунтов российских пользователей со стороны Anthropic.
А теперь посмотрите на ряд новостей.
1️⃣

Anthropic опубликовала открытый документ «2028: два сценария глобального лидерства в ИИ».
Один из первых случаев, когда frontier-лаборатория прямо встаёт в позицию: «Мы стратегический актив США в гонке с Китаем».
Внутри документа Anthropic открыто лоббирует закрытый фронтир для своих и продвижение «доверенного американского ИИ» на зарубежных рынках.
До этого frontier-игроки хотя бы старались выглядеть нейтральными провайдерами. Anthropic снимает маску, а OpenAI и Google уже там - через контракты с Пентагоном. ИИ-стек буквально становится оружием сверхдержавы.

2️⃣

В Claude Code обнаружили скрытый механизм идентификации пользователей, нацеленный в том числе на выявление пользователей, связанных с Китаем.
Он собирал информацию о часовом поясе, прокси и возможной связи с ИИ-лабораториями, а затем незаметно встраивал соответствующие маркеры в системные промпты, отправляемые на серверы Anthropic. Пользователи не могли этого заметить.

3️⃣

Alibaba разослала внутренний запрет на использование продуктов Anthropic, включая Sonnet, Opus, Fable и Claude Code.

4️⃣

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

Да, вы скажете, что здесь идёт борьба США🇺🇸 с Китаем🇨🇳. Но «новый дивный мир вайбкодинга», в котором каждый мог писать код с помощью самых лучших моделей, стремительно исчезает на наших глазах.😕
ИИ превращается в инструмент доминирования и контроля👨‍🏫. Как только игрушки гиков🤓 становятся мощным инструментом, серьёзные дяди берут его под контроль.🎩 Это неизбежная сущность человеческой природы.

Что это означает для частного пользователя из РФ?
Всё просто: в один прекрасный момент ваша учётная запись со всеми наработками и балансом может быть удалена независимо от того, будут это модели из США или Китая. Может быть, не в этом году, но это произойдёт.
И то, что ваш VPN-сервер находится в Нидерландах или Нью-Йорке, не спасёт.👮

Если же говорить о корпоративных решениях, то здесь такой риск просто недопустим.
Уже сейчас пройти ИБ-аудит с использованием внешних американских моделей крайне сложно, но возможно. Скоро это может стать невозможным.

Какой же выход?
Пока можно закладывать использование топовых моделей для сложных задач, после предварительной очистки данных в соответствии с требованиями ИБ. Но при этом необходимо быть готовыми к переходу на внутренние решения.
Что это может быть?

Собственный сервер
Самый дорогой вариант, конечно же покупка собственного сервера.🤑
Здесь всё очевидно: если есть лишние миллионы на развёртывание собственной ИИ-инфраструктуры, это лучший вариант.
Open-source модели не сильно уступают топовым моделям, и на их основе можно строить вполне рабочие решения. Стоимость входа в целом может начинаться от миллиона рублей, а дальше уже нужно смотреть на конкретные потребности и возможности.

Отечественные ИИ-сервисы: YandexGPT, GigaChat, решения Т-Банка и МТС
Многие воротят нос от отечественных моделей, но перечитайте написанное выше и поймите: рано или поздно с ними придётся иметь дело.
Да, технологическое отставание было, есть и будет, но его будут стараться компенсировать архитектурой, а не только вычислительной мощностью.
Поэтому рекомендую тестировать решения отечественных ИТ-гигантов уже сейчас.

Роутеры и агрегаторы для доступа к разным моделям
Пока это до конца непонятный вариант.
Как они будут работать в условиях ужесточающейся технологической, да и вполне обычной войны, которая будет охватывать всё новые и новые регионы мира, непонятно.🤯

API-доступ к моделям, развёрнутым внутри РФ
Вроде бы отличный вариант — API-подключение к уже развёрнутым моделям на специализированных серверных мощностях с необходимой системой защиты внутри РФ, а то и с аттестацией, что снимает значительную часть вопросов со стороны служб ИБ.
То есть тот же Qwen развёрнут в дата-центре на территории РФ: просто подключаешься по API и платишь копейки за токены.

Казалось бы, отличный вариант, но на практике у меня возникла сложность.
Модель с одинаковыми параметрами и квантизацией выдавала гораздо худший результат, чем та же модель на наших собственных мощностях.
Связано ли это с настройками инференса в дата-центре или с нашими кривыми ручками и насколько это распространено пока непонятно. Выясняем.
Но такой вариант, на мой взгляд, очень перспективен.

Аренда мощностей в дата-центре с собственной настройкой
Такой вариант тоже возможен, но, на мой взгляд, только как временное решение. Он достаточно сложен с точки зрения настройки и последующей поддержки.

Как итог
Если вы думаете, что ситуация с блокировкой интернета😍 и сервисов это сугубо российская дурость, то спешу вас обрадовать: скоро это будет происходить повсеместно, а блокировка доступа к ИИ по флагу окажется одной из первых мер.
Это требует особых подходов к проектированию не только корпоративной ИИ-инфраструктуры, но и вашей личной. Особенно если ИИ уже стал вашим рабочим инструментом.

P. S. За политическую агитацию, срач, софистику, оскорбления отечественных разработчиков, да и просто по настроению моей левой пятки буду безжалостно банить в комментариях к этому посту. 👀
Учтите это, прежде чем высказывать своё очень ценное мнение😬

Рубрика "СтройпрактИИкум"
Зачем нужно делать обследование?
#СтройпрактИИкум@IIstroika
В этом посте я писал, как по моему мнению может выглядеть поиск мест эффективного внедрения ИИ и особо сделал упор на необходимость в обследовании, как важнейшем факторе успеха применения ИИ. Чтобы этот процесс не превратился в поле бесконечных экспериментов, а ИИ реально решал задачи компании.

И вот пример из практики, подтверждающий эти слова.😊

Крупная проектная компания. Провожу обследование. Применение САПР вроде бы на средне-высоком уровне, организованы базовые процессы автоматизации, даже BIMщики вайбкодят плагины для проектировщиков. На первый взгляд всё нормально.👌

Можно переходить к типовым сценариям применения ИИ в проектировании, которые нужны практически всем: например, входящий\исходящий нормоконтроль или формированию ВОР из ЦИМ.
Но я настоял на обязательном обследовании всех проектных отделов. В результате в каждом отделе были выявлены нетиповые возможные сценарии применения ИИ, а их общее количество исчислялось десятками.😮

Причём сложность реализации большинства из них минимальна. Например:
Инженер берёт проектную документацию, выполненную соседним отделом на основе ЦИМ (!), и вручную (!!) ищет определённое оборудование. Затем находит в документации данные о его потреблении, переводит значения в нужные единицы измерения и вручную (!!!) вносит их в Excel-таблицу для подсчёта общего потребления.😱

Только за прошедший месяц на эту операцию было потрачено не менее двух недель! То есть автоматизация одной небольшой операции потенциально возвращает компании значительную часть рабочего времени специалиста.

Естественно, эта задача стала одной из первых, отправленных на автоматизацию. Найти эту точку неэффективности без погружения в процесс, просто нереально. 🔎

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

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

Ну и естественно была прописана архитектура ИИ-сервисов, план внедрения, ожидаемые эффекты и сценарии реализации, чтобы руководство могло принять обоснованное решение о дальнейшем применении ИИ, исходя из доступного бюджета, инфраструктуры и фазы луны.🤩

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

Это как регулярный чек-ап организма: всегда полезно и всегда обнаруживается что-то новенькое, чем стоило бы заняться, пока не поздно))🫡
То, что у вас пока нет точек применения ИИ, это не ваше достижение, а наша недоработка)
#СтройпрактИИкум@IIstroika

Я вернулся 💃

Не писал в ТГ-канале, ибо взял паузу на отдохнуть и после 60 часов в Crimson Desert решил всё-таки всплыть на поверхность и выдать полезную информацию.✍️ для данной игры 60 часов это только вступительные титры посмотреть, игра гигантская, рекомендую

Начнём с конференции НИИСФ РААСН - V Всероссийской научно-практической конференции «Машинное обучение и искусственный интеллект в управлении жизненным циклом объектов капитального строительства», которая вчера проходила, так сказать, «для своих», без громкой рекламы и освещения в СМИ.

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

1️⃣Я как-то пропустил образование комиссии Минстроя России по вопросам внедрения сервисов искусственного интеллекта и цифровизации в сфере строительства и ЖКХ, о чём было объявлено на конференции. Казалось бы, что может быть полезным обычному человеку от этого бюрократического действа? Ведь задачи комиссии - создание единой цифровой среды, ускорение внедрения ТИМ и ИИ в рамках деятельности государства. А важное в этой комиссии то, что ключевым интегратором назначен Центр инженерии данных и искусственного интеллекта (ЦДИ).

Что за ЦДИ? Вот на этой же конференции главный инициатор и исполнитель XMLизации в России, Главгосэкспертиза, объявила, что 1 июня создан Центр инженерии данных и технологий искусственного интеллекта (ЦДИ). Почему это важно? У ГГЭ есть ряд ключевых особенностей, которые делают все инициативы этой организации очень серьёзными:

✅Сильное руководство.💪

✅Наличие независимого бюджета, который может расходоваться вне рамок государственного дурдома, а значит, гибкость и возможность по-настоящему что-то делать толковое.🤑

✅Доступ ко всем основным проектным данным России. Причём немалая часть уже в машиночитаемом формате XML. А значит, уникальная возможность для работы с ИИ: даже ИТ-гиганты не имеют таких датасетов.

Исходя из этих факторов, созданный центр получил мощнейшую основу для того, чтобы «диктовать свою непреклонную волю» Минстрою и всему рынку. Соответственно, все наработки ЦДИ будут, благодаря комиссии, максимально быстро и бесшовно интегрироваться в работу не только в рамках государственных информационных систем, но и на уровне всей строительной отрасли. Поэтому рекомендую внимательно следить, что же в области ИИ придумают и реализуют ЦДИ и комиссия, если хотите идти в ногу с государством.
Большая сила - большая ответственность. Так и хочется вставить сюда нейрокартинку Игоря Евгеньевича с перчаткой бесконечности

2️⃣Дальше - больше. ФАУ ФЦС объявило, что они начинают формирование онтологической модели строительных данных на основе КСИ. Можно долго дискутировать про КСИ, но уже бессмысленно. Важно то, что я ещё 3 года назад сформулировал, что полноценное генеративное ИИ-проектирование невозможно, пока не будут преодолены 2,5 ключевых препятствия:

1. Наличие полноценных машиночитаемых норм и заданий. Здесь много кто ведёт работу, с переменным успехом.

2. Онтологическая модель строительных данных, чтобы ИИ однозначно знал и понимал, как взаимосвязаны строительные элементы.

2,5. САПР-ядро, способное полноценно работать с ИИ, машиночитаемыми данными и онтологиями. Но это уже не так критично, поэтому только 0,5.

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

3️⃣Забавно, что дальше были доклады, которые привели к дискуссии о связи философии Канта, конфликта капитализма и социализма, в основе которой лежала энциклика Magnifika Humanitas Папы Римского Льва XIV. Всё-таки научные стены давали о себе знать👨‍🔬

4️⃣Отметились коллеги из Ренга, выступив с докладом о том, что Renga - это AI Ready САПР. Смелое заявление, но проверять я, конечно, буду. Вернее, уже проверил, о чём докладывал на конференции «Белые ночи САПР». Действительно, технологические особенности Renga делают эту платформу одной из самых удобных для построения решений на основе ИИ, а разработчики всячески развивают САПР именно как интеграционную платформу.

Я также отметился уже с типовым докладом об экономически оправданном внедрении ИИ в проектировании, но впервые уже с практическими инсайтами, которые накапливаются в ходе моей консалтинговой деятельности. В ближайшее время поделюсь этим и здесь.

5️⃣Ну и last but not least: это выступление Анастасии Лесик из Яндекса 👮‍♂️. Если кто не в курсе, ИТ-гигант уже давно смотрит в сторону стройки, но прекрасно понимает, что рынок гиперсложный и влетать с двух ног сюда нельзя: слишком большие риски. В связи с этим Анастасия, как руководитель данного направления, смогла собрать ИИ-лидеров строительного рынка в независимый консорциум, в состав которого и я имею честь входить.👏

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

Если вы хотите принять участие в этом консорциуме и, главное, у вас есть данные, на основе которых можно проводить обучение моделей (не забываем про юридическую чистоту), вэлком, вас очень не хватает!🤙

Как итог: получилась непроходная конференция. Организаторам удалось собрать очень важных спикеров, которые принесли серьёзные новости отрасли, но, как всегда, никто этого не заметил. Ну а я вам эти новости подсветил.😄

Оставайтесь на связи, дальше будет больше!

⚡️Игорь Рогачев, Алексей Зотов и Игорь Пидтыканый в подкасте обсуждают, как оценивать эффект от внедрения новых технологий, преодолевать политические и бюрократические барьеры, грамотно внедрять ИИ и BIM‑решения.

💬 Ссылка на канал СтроИИка Рогачёва

Слушайте разговор про управление проектами в условиях геополитических изменений на одной из видеоплатформ:

🌐ВК🔵🔤RT 🔵🎞 YT

И финальное видео со мной, дальше только по делу)))

1️⃣ Игорь Рогачёв
И его впечатления от ЦИПР 2026

🎙️ Кстати, в ролике упоминается проект Игоря, в котором вы тоже можете поучаствовать. Целевая аудитория — ГИПы по большей части, но также и BIM-специалисты, в зависимости от вашего включения в смежные процессы. Как сказал Игорь, BIM-менеджеру важно смотреть шире семейств, коллизий и параметров. Хотели разобраться с XML — вам туда)
#LETSwatch

Какие вопросы вы бы задали на сессии Игоря?

Пока готовлюсь к Белые Ночи САПР и нет времени писать посты, будет минутка разнузданной саморекламы)

XML. Нужны люди, которые хотят сделать работу с XML чуть менее болезненной

#XML@IIstroika
Я уже давно веду проект по автоматическому преобразованию классической проектной документации в XML схемы Минстроя с использованием LLM.👨‍💻
Честно говоря, задача оказалась заметно сложнее, чем выглядела в начале. История здесь не только про «скормить ПЗ PDF нейросети и получить XML». Пришлось разбираться с логикой разделов ПД, структурой документов, качеством исходников, пайплайнами обработки и сборкой решения на относительно небольших open source LLM, чтобы не зависеть исключительно от дорогих топовых моделей. 🧠

📆Но проект постепенно выходит на финишную прямую.💃
В ближайшее время планируем запуск первого сервиса по автоматического преобразованию ПЗ в XML с дальнейшим расширением на другие разделы и сценарии работы.
Сейчас для нас особенно важна не только техническая часть, но и понимание того, как этим реально будут пользоваться инженеры.

📌Поэтому хочу собрать вокруг проекта людей, которым тема XML, автоматизации проектирования и применения ИИ в стройке действительно интересна.
Ищу не просто будущих тестировщиков.
Хочется собрать пул практиков и энтузиастов, которые смогут влиять на развитие сервиса:
✅ГИПов и ГАПов
✅BIM-специалистов
✅Специалистов работающих в экспертизе
✅Людей, которые уже работают с XML Минстроя
✅Инженеров, которым просто интересно, куда всё это движется

📍На первом этапе проведём короткие интервью и опросы, затем откроем доступ к закрытому тестированию. Не за горами уже и открытая работа сервиса!
Если хотите присоединиться к развитию ядра преобразования ПД в XML, то записывайтесь ➡️по ссылке⬅️
Попробуем вместе сделать так, чтобы XML перестал быть отдельным видом инженерного страдания.😭

P.S. Если у вас есть опыт работы с XML Минстроя или вы уже пытались решать эту задачу самостоятельно особенно жду. Возможно, именно из этой группы получится собрать сильное профессиональное ядро проекта.

#XML@IIstroika

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

Впервые было полезно общаться и с теми кто на стендах представлен. Понятное дело, что стенды крупнейших корпораций мне были не интересны, а вот там где ютились не большие стартапы уже жизнь была другая. Появилось несколько ИИ решений, которые ушли чуть дальше чем кастомная разработка и их полукоробочные ИИ сервисы уже можно пытаться внедрять в проектировании и строительстве.