Я вернулся 💃

Не писал в ТГ-канале, ибо взял паузу на отдохнуть и после 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, ориентированной под задачи стройки, что даст невероятный буст для резкого роста автоматизации благодаря наличию готового ядра для целого спектра программных решений автоматизации строительства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИИ по флагу
Сейчас занимаюсь написанием внутренней архитектуры ИИ-сервисов для одного из клиентов и вот о чём задумался.
Пожалуй, этот год ну, может быть, максимум следующий последний, когда в корпоративную архитектуру ещё можно относительно беспрепятственно закладывать использование сервисов 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
Часть 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.

Продолжение. Часть 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 красиво это придумала, а потому, что в модели проекта существуют реальные связи, на основании которых этот вывод был сделан.
Вот к такому уровню я бы в итоге и стремился. Потому что здесь ИИ уже перестаёт быть отдельной игрушкой рядом с проектированием. Он становится одним из слоёв самого проектного процесса и поддержки принятия решений.

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

Как начать использовать ИИ
Объем применения ИИ: 30%
#СтройпрактИИкум #СтройпрактИИкум@IIstroika

Тут в одном из чатов спросили, как начать применять ИИ в проектировании. Я написал ответ, посмотрел на него и понял, что это уже почти готовый пост, поэтому чуть дописал и вот, что получилось.
Как начать применять ИИ в проектирования для отдельно взятого инженера?
Всё очень просто:

Шаг 💕
Все ответы на вопросы уже есть в ИИ. Не нужно спрашивать в чате ТГ: «А что мне изучать?», «С чего начать?», «Как это сделать?». Напиши это в чат с ИИ, расскажи, чем занимаешься, попроси позадавать тебе вопросы, чтобы точно выявить твои задачи, текущий уровень знаний и построить по шагам, что именно нужно делать.

1️⃣Поднимаешь собственный КВН-сервер (для таких задач покупка чужого КВН, харам) и делаешь иностранную карту. Желательно, чтобы локация сервера совпадала с платёжным адресом карты. Как это сделать - полно информации в интернете + консультации с ИИ.

2️⃣Покупаешь подписку начального уровня у OpenAI или Anthropic. С бесплатным тарифом просто теряешь время и возможности. Модели надо использовать много. Очень много. Пока ты задаёшь ИИ три вопроса в неделю, ты его не изучаешь.

3️⃣Параллельно разбираешься хотя бы на базовом уровне, как вообще работают современные LLM: что такое контекст, токены, системный промпт, structured output, вызов утилит, эмбединги, температура, галлюцинации (недавно узнал что правильно их называть конфабуляция). Не надо становиться ML-инженером и изучать устройство трансформера до последнего тензора. Но понимать, где заканчивается магия и начинается обычная программная система, обязательно. Нужно понимать как мыслят нейронки, хотя бы примерно.

4️⃣Вайбкодинг наше всё!
Изучаешь всё, что сможешь найти: что это и как этим пользоваться. Полно доступных гайдов на YouTube. Без понимания вайбкодинга сейчас никуда нормально не продвинешься. Я, например, написал огромный отчёт с помощью вайбкодинга за неделю, который делать руками пришлось бы пару месяцев. Хотя казалось причем тут программирование и написание отчета.

Но есть нюанс: вайбкодинг не отменяет необходимость хотя бы примерно понимать, что тебе накодили и как это запускать.
Поэтому постепенно осваиваешь Git, API, JSON, SQL, Docker, что такое базы данных. Не на уровне разработчика с десятью годами опыта. На уровне «понимаю архитектуру и как оно работает, запустить проект, посмотреть логи и объяснить ИИ, где он опять всё сломал». ИИ тебе в помощь, объяснит даже очень далеком от IT человеку, только правильно попроси.

5️⃣Скачиваешь Codex или Claude Code. Хотя, это лучше как можно раньше сделать. Смотришь гайды на YouTube, как с ними работать, что такое агенты, субагенты, MCP, скиллы, tools, хуки, правила, контекстное окно. Хотя с контекстным окном ты должен был разобраться ещё на п.3. Но тут уже нужно понимать почему после 70% заполнения окна мышление деградирует, как правильно создать handoff.

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

6️⃣Дальше, а вернее совместно с п.5, выполняешь с ИИ планирование своих задач: какие задачи и в какой последовательности будешь решать. От простого к сложному. К этому моменту уже с помощью скиллов типа Superpowers и нормального процесса: исследование, архитектура, план, реализация, тестирование, ревью. Я прежде чем приступаю к написанию плана прохожу 3-4 диалога исследований, включая глубокое исследование и эксперименты.

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

7️⃣Память. Научись создавать память для ИИ. Ещё на п.2 надо освоить, например, функции Work и Проекты в ChatGPT. Так чтобы с новым чатом ИИ не забывал о чем вы общаетесь в этом проекте, какие данные есть, как действовать и т.п. В конечном счете вы должны идеально понимать что тако AGENTS.md или CLAUDE.md и как этим все пользоваться. На текущий момент это самое главное направление в серьезном применении ИИ.

Переходим применительно к проектированию и строительству.

8️⃣САПР и вайбкодинг. Для меня, как и для многих кто много работал в САПР и страдал из-за того что нет нужных функций, вайбкодинг стал настоящим откровением. Я вздохнул полной грудью в этот момент. Просто спросите ИИ как реализовать нужную функцию в САПР и дальше перед вами откроется новый дивный мир. Не без пердолинга конечно, но оно того стоит! Тем более если вы прошли все предыдущие пункты, то тогда работа пойдет как по маслу.

9️⃣Для серьёзной работы с проектной документацией чистый RAG по пачке сырых PDF почти бесполезен. Но развернуть, потрогать и понять, как он работает, обязательно надо. Но потом быстро выясняется, что просто порезать документацию на кусочки, засунуть их в векторную БД и прикрутить чат этого недостаточно.
Начинаешь разбираться в обработке документов:
✅PDF/DOCX/XLSX/OCR и распознавание структуры
✅Нормализация
✅Выделение сущностей
✅Метаданные
✅Классификация
✅Индексация
✅Полнотекстовый и векторный поиск
✅Переранжирование результатов
✅Связи между сущностями
✅Графы
✅Онтологии
✅Проверки

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

9️⃣Отдельно разобраться с мультимодальными моделями.
Проектирование это не только текст. Это чертежи, планы, схемы, таблицы, фотографии, BIM-модели, сканы, генпланы.
Поэтому пробуешь задачи:
🟪Распознавания чертежей и схем
🟪Извлечения таблиц
🟪Сопоставления текста и графической части
🟪Анализа фотографий стройплощадки
🟪Поиска изменений между версиями документации
🟪Классификации замечаний
🟪Проверки комплектности
🟪Извлечения данных из штампов
🟪Анализа коллизий и результатов проверок моделей.

Вот это уже применение ИИ.

А «я загрузил PDF в ChatGPT и спросил, что там написано» пока ещё просто использование ChatGPT.

1️⃣0️⃣Дальше обязательно изучаешь оценку качества ИИ-систем.
Уровень конечно для настоящих джедаев, но метрики реально необходимы для любой системы.
Тестовые выборки, эталонные ответы, precision/recall, false positive/false negative, трассировка источников, воспроизводимость результатов, проверки после изменения промптов или моделей.
Если система должна делать нормоконтроль 500 комплектов документации, аргумент «я десять раз попробовал, вроде работает» не очень подходит.
Потом безопасность: что можно отправлять во внешнюю модель, что нельзя, локальные модели, обезличивание данных, разграничение доступа, журналирование действий агентов.

1️⃣1️⃣Стоимость.
Понимаешь, что подписки начального уровня давно не хватает, переходишь на подписку за 100–200 и больше долларов и осознаёшь, что так ИИ тебя разорит)
Начинаешь разбираться, что такое API, агентский харнесс, роутинг моделей, кэширование, локальные модели и почему далеко не каждую задачу надо решать самой дорогой моделью.

И только после этого постепенно приходит главное понимание:

ИИ это вообще не ChatGPT

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

Дальше сами)