en
Feedback
Свердловская область: цифровизуем строительство сообща и невзирая на! 📈

Свердловская область: цифровизуем строительство сообща и невзирая на! 📈

Open in Telegram

Любо-дорого видеть вас подписчиком нашей ленты знаний и новостей о цифровой трансформации строительной отрасли Свердловской области!

Show more
1 095
Subscribers
No data24 hours
+87 days
+1130 days
Attracting Subscribers
September '26
September '26
+10
in 0 channels
August '26
+11
in 6 channels
Get PRO
July '26
+13
in 8 channels
Get PRO
June '26
+6
in 1 channels
Get PRO
May '26
+11
in 7 channels
Get PRO
April '26
+15
in 10 channels
Get PRO
March '26
+22
in 6 channels
Get PRO
February '26
+45
in 4 channels
Get PRO
January '26
+26
in 5 channels
Get PRO
December '25
+52
in 2 channels
Get PRO
November '25
+17
in 4 channels
Get PRO
October '25
+27
in 3 channels
Get PRO
September '25
+12
in 1 channels
Get PRO
August '25
+15
in 10 channels
Get PRO
July '25
+24
in 1 channels
Get PRO
June '25
+18
in 2 channels
Get PRO
May '25
+46
in 4 channels
Get PRO
April '25
+39
in 7 channels
Get PRO
March '25
+70
in 5 channels
Get PRO
February '25
+89
in 6 channels
Get PRO
January '25
+52
in 4 channels
Get PRO
December '24
+48
in 13 channels
Get PRO
November '24
+101
in 5 channels
Get PRO
October '24
+76
in 6 channels
Get PRO
September '24
+20
in 7 channels
Get PRO
August '24
+20
in 2 channels
Get PRO
July '24
+15
in 3 channels
Get PRO
June '24
+36
in 5 channels
Get PRO
May '24
+53
in 7 channels
Get PRO
April '24
+34
in 6 channels
Get PRO
March '24
+40
in 7 channels
Get PRO
February '24
+39
in 8 channels
Get PRO
January '24
+31
in 4 channels
Get PRO
December '23
+47
in 13 channels
Get PRO
November '23
+87
in 7 channels
Get PRO
October '23
+27
in 0 channels
Get PRO
September '23
+25
in 0 channels
Get PRO
August '23
+40
in 0 channels
Get PRO
July '23
+87
in 0 channels
Get PRO
June '23
+24
in 0 channels
Get PRO
May '23
+83
in 0 channels
Get PRO
April '23
+53
in 0 channels
Get PRO
March '23
+338
in 0 channels
Date
Subscriber Growth
Mentions
Channels
08 September0
07 September0
06 September+1
05 September+2
04 September+7
03 September0
02 September0
01 September0
Channel Posts
В первой части мы рассказывали, как подготовили базу знаний из инструкций по ИСУП и задали 31 одинаковый вопрос трём моделям – ChatGPT, Qwen и DeepSeek. Теперь – о результатах. Ответы каждой модели заносили в таблицу и оценивали по трём критериям: точность, полнота информации и отказ от выдумки. Оценка, конечно, в определённой степени субъективная – проверяет ответы человек. Но в нашем случае это скорее плюс. Все вопросы и оценки заполняла Ирина Дзюба – наш новый сотрудник, которая сравнительно недавно работает с системой. То есть проверку проводил именно тот пользователь, для которого мы и хотим сделать будущего ассистента: человек уже работает с ИСУП, сталкивается с реальными задачами, но ещё не знает наизусть, где искать нужный ответ. Поэтому оценивали практично: – понятно ли, что делать? – хватает ли ответа для выполнения задачи? – не придётся ли после него всё равно перелопачивать инструкции? --- В целом, все три модели справились достаточно хорошо. На многих вопросах они получили максимальные оценки – например, по согласованию КСГ, изменению уже утверждённого графика, отправке заявки в техподдержку и заполнению проектных сроков. Хорошо сработали и вопросы, где ответа в документации вообще не было. В таких случаях модель должна была честно сказать:
В инструкциях нет данных по этому вопросу
Для нас это один из самых важных критериев. ИИ-ассистент должен уметь не только находить ответ, но и вовремя останавливаться. Убедительно написанный неправильный ответ всегда хуже, чем отсутствие какого-либо ответа. Ошибки тоже были показательными. Например, по вопросу об интеграции ИСУП с 1С ответа в контексте не было. ChatGPT и Qwen это распознали, а DeepSeek начал достраивать ответ самостоятельно. В другом случае DeepSeek использовал сведения с других сайтов, хотя условие теста было жёстким: отвечать только из переданного контекста. А по вопросу про атрибут «Подрядные работы» произошло обратное – DeepSeek решил, что ответа нет, хотя ChatGPT и Qwen нужную информацию нашли.
Наши сводные оценки: ChatGPT – 97,3 % Qwen – 88,7 % DeepSeek – 83,9 %.
Все три модели показали вполне рабочий результат, но ChatGPT в нашем эксперименте оказался лучшим. В целом это коррелируется и со стоимостью токенов: более качественная модель обходится чуть дороже, хотя разница в цене заметно меньше разницы в качестве ответов. Если совсем просто, токен – это небольшой фрагмент текста, который ИИ читает или генерирует. При работе через API стоимость зависит от количества переданных и полученных токенов. Поэтому для будущего сервиса важно учитывать одновременно два аспекта: качество ответа и стоимость использования. --- Следующий шаг – превратить эксперимент в рабочий инструмент. Запускать собственную большую языковую модель на мощном сервере мы пока не планируем. Такое оборудование обходится значительно дороже, как и аренда серверов с GPU. Поэтому схема в общем виде видится так: RAG и логика ассистента работают на нашем сервере, а к языковой модели он обращается через API. Сервер принимает вопрос, ищет в базе знаний подходящие фрагменты инструкций, передаёт их вместе с вопросом ИИ-модели и возвращает готовый ответ. Для нашей задачи такой вариант проще и дешевле – не нужна собственная мощная видеокарта, а оплачиваются фактические обращения к модели. --- Ну и последний слой – интерфейс. По нашему замыслу, пользователю не должно быть важно, что внутри работают RAG, API, токены и языковая модель. Он просто задаёт вопрос боту в MAX:
Как загрузить КСГ? Где указать номер договора? Как назначить заказчика? Куда загрузить фотографию объекта?
А в ответ получает либо пошаговую инструкцию, собранную из нескольких документов, либо подсказку, где именно искать нужную информацию. Первоначально такую базу знаний хотим построить для ИСУП и региональной ГИСОГД. Если всё получится так, как задумано, то вместо поиска нужного абзаца среди множества инструкций у пользователя останется одно действие – нормально сформулировать вопрос. А это, как мы уже выясняли раньше, тоже отдельный навык.

2
Инструкции по работе с информационными системами читают далеко не все. Думаем, здесь мы никого особенно не удивили 🙂 И да, это проблема. Но есть и вторая проблема. Даже если человек готов разобраться в работе системы самостоятельно, то ответ на какой-нибудь вполне конкретный вопрос иногда приходится собирать сразу из нескольких документов (а третья проблема – инструкции часто написаны настолько анти-пользовательски, что их нельзя правильно понять, да и в целом пользоваться ими тоже не с руки). Например, порядок выполнения нужного действия может быть описан в одной инструкции, а требования к регистрации пользователя и его правам в системе – совсем в другой. В результате человек вроде бы всё делает правильно, но нужная кнопка у него просто недоступна. И начинается отдельное исследование: что не так с системой, инструкцией или самим пользователем? Отсюда появилась идея попробовать собрать ИИ-ассистента по работе с ИСУП, которому можно задать обычный «человеческий» вопрос типа: «Как мне выполнить такую-то операцию?» – и получить в ответ последовательность действий, собранную из нескольких инструкций. --- Для первого эксперимента мы соорудили базу знаний для RAG на основе инструкций по работе с ИСУП. Если очень упрощённо, то RAG (букв. «генерация с дополненной выборкой») – это подход, при котором искусственный интеллект отвечает не просто «из того, что знает», а сначала ищет подходящие фрагменты в переданных ему документах и уже на их основе формирует ответ. Для нас здесь принципиально важна именно вторая часть. Ассистент по информационной системе не должен быть самым разговорчивым или самым эрудированным. Он должен правильно найти ответ в документации и не придумывать того, чего там нет. Для проверки мы взяли три разные ИИ-модели и поставили их в одинаковые условия: каждой передавали один и тот же контекст и задавали одно и то же правило: Отвечай строго на основании приведённого КОНТЕКСТА. Если в контексте нет ответа – прямо напиши: «В инструкциях нет данных по этому вопросу» и не придумывай. Так мы могли сравнивать уже не качество промпта или исходных данных, а то, как каждая модель работает с одной и той же базой знаний: находит нужный фрагмент, связывает информацию из нескольких инструкций и удерживается от выдумывания ответа там, где его в документации действительно нет. --- Дальше началась проверка. Мы подготовили 31 вопрос – от совсем прямых до намеренно неудобных. Спрашивали, например, какие статусы может принимать КСГ (календарно-сетевой график), как пошагово загрузить его в систему, как изменить уже утверждённый график, куда внести номер договора, как загрузить фото объекта или заполнить проектные сроки. Были и вопросы, ответ на которые нужно было собирать из нескольких инструкций: например, «Как связаны КСГ и загрузка исполнительной документации?» или «Какие действия выполняют заказчик и подрядчик при согласовании графика?» Отдельно добавили вопросы-ловушки: о стоимости лицензии ИСУП, интеграции с 1С, требованиях к серверному оборудованию и разработчике системы. Ответов на них в подготовленном контексте намеренно не было. И вот здесь для нас хороший ИИ – это не тот, который обязательно что-нибудь ответит. Хороший ИИ в такой ситуации должен уметь сказать: «В инструкциях нет данных по этому вопросу». Каждый ответ мы оценивали по трём параметрам: точность, полнота информации и отказ от выдумки. То есть нас интересовало не общее качество текста, а гораздо более прикладная вещь: сможет ли человек после такого ответа действительно выполнить нужное действие в системе – и не уйдёт ли он по ложному пути из-за убедительно написанной фантазии нейросети? А вот что получилось у ChatGPT с подпиской плюс, Qwen и DeepSeek, а также о том, как мы планируем собрать самого ИИ-агента, расскажем во второй части.
131
3
Дорогие друзья и уважаемые подписчики! Первый день осени – это не только начало сезона золотых листьев, затяжных дождей, и вн
Дорогие друзья и уважаемые подписчики! Первый день осени – это не только начало сезона золотых листьев, затяжных дождей, и внезапного желания завернуться в мягкий уютный плед. 1 сентября мы отмечаем День знаний – праздник школьников, студентов, педагогов и вообще всех, для кого учёба не заканчивается вместе с получением аттестата или диплома. Всем, кто учит, учится или просто стремится каждый день разобраться в чём-то новом, желаем терпения, настойчивости, любопытства и побольше тех приятных моментов, когда сложная и запутанная тема складывается в понятную картину. А мы продолжим утолять нашу общую жажду знаний в непростом, постоянно меняющемся, а временами и совершенно загадочном мире информационного моделирования. Разумеется, под чутким присмотром наших неизменных обаяшек-пушистиков – Тима и Бима. С Днём знаний!
155
4
No text...
204
5
Есть одна тема, которая вроде бы не про BIM/ТИМ, ИСУП и цифровые сервисы напрямую, но на практике сильно влияет на то, как бы+1
Есть одна тема, которая вроде бы не про BIM/ТИМ, ИСУП и цифровые сервисы напрямую, но на практике сильно влияет на то, как быстро решаются вопросы в цифровой среде. Это культура постановки вопросов и общения в рабочих чатах. Да, да о таких вещах тоже надо, оказывается, договариваться и проговаривать правила взаимодействия. Мы видим это сразу в нескольких местах: при первой линии техподдержки ИСУП, при отладке наших контрольных таблиц УКС, а также в многочисленных рабочих чатах с коллегами. И закономерности, увы, похожи. --- Заявка в техподдержку может выглядеть примерно так: «Не работает». Что именно не работает, на каком объекте, что делал пользователь, что увидел на экране – неизвестно🤷‍♀️ В результате вместо решения проблемы специалист сначала звонит заявителю и выясняет, в чём, собственно, беда. При этом уточнение обстоятельств может занять времени кратно больше, чем само решение проблемы. С этим мы попробовали бороться довольно прямолинейно: подготовили инструкцию, как правильно оставлять заявку, и официальным письмом довели её до участников процесса. Вместе с инструкцией тем же письмом рассказали пользователям о Telegram-боте, куда при необходимости можно прислать видео с экрана телефона. Это позволяет показать проблему и дать устный комментарий в случаях, когда по разным причинам описать всё текстом не получается. --- С рабочими чатами история сложнее. Пользователи техподдержки в большинстве своём люди постоянные, поэтому их планомерное обучение вполне целесообразно. А с некоторыми участниками рабочих чатов мы можем пересечься всего один раз. В чатах проблема в том, что сообщение может не иметь ни конкретного адресата, ни явного вопроса, ни понятной просьбы что-либо сделать. Но отправитель при этом считает, что информацию передал и дальше ответственность уже находится «на чужой половине поля». Не исключено, что автор сообщения мысленно ставит своеобразную галочку в списке своих задач: сообщение в чат отправлено – значит, «я сообщил». А адресат в это время может вообще не понимать, что обращение было к нему и от него ждут каких-то действий. В итоге вопросы, которые можно было бы решить достаточно быстро, начинают жить в переписке своей отдельной жизнью. В отличие от инструкций для пользователей, опыта по наведению порядка в чатах, доведённого до состояния готового «продукта», у нас пока нет. Из перспективных идей видится одна из самых простых – фиксировать правила взаимодействия прямо в начале рабочего чата: - кому адресуем вопрос; - что требуется сделать; - к какому результату хотим прийти; -в какой срок, если это необходимо. То есть вместо:  «Коллеги, опять проблема с документом»   писать примерно так:  «@Имя, при передаче документа возникает ошибка № __. Просим проверить причину и сообщить результат».  По количеству символов разница небольшая, но вероятность получить желаемый результат - существенно выше. --- Уважаемые подписчики, здесь нам особенно интересен ваш практический опыт. Удалось ли вам выстроить удобную схему подачи заявок в техподдержку? Вводили ли вы правила общения в рабочих чатах? Может быть, используете шаблоны сообщений, ботов, регламенты или какие-то другие простые инструменты, которые действительно навели порядок? Поделитесь рабочими решениями. Есть ощущение, что хорошая цифровая культура начинается не с очередной информационной системы, а с довольно простого умения понятно сообщить другому человеку: что произошло и что именно от него требуется.
212
6
Мы участвуем в пилотном проекте Минстроя России по подготовке цифровых ведомостей объёмов работ (ЦВОР) на основе ЦИМ. И по ходу работы столкнулись с вопросом, который, кажется, возникает почти в любом пилоте: как сделать так, чтобы накопленные знания не остались только в головах его участников?   Сначала задача выглядела вполне прикладной. Чтобы не пытаться автоматизировать всё и сразу, решили двигаться от тех работ, которые сильнее всего влияют на стоимость объекта: 1. определить наиболее капиталоёмкие позиции по разделам АР, КР и ОВИК; 2. понять, какие ГЭСН за ними стоят; 3. определить, какие данные нужны для выбора конкретной нормы и расчёта объёма; 4. разобраться, как связать элемент ЦИМ с ГЭСН – напрямую либо через код нашего классификатора; 5. на основании этого определить, какие материалы, единицы измерения и другие характеристики должны быть стандартизированы в параметрах ЦИМ. Логика вроде бы понятная: от стоимости – к норме, от нормы – к необходимым данным, от данных – к требованиям к модели. Но довольно быстро возник ещё один вопрос. Допустим, мы всё это прошли. Сметчик объяснил, почему для конкретной конструкции выбрана именно эта норма. ТИМ-специалист понял, из какого параметра модели брать объём. Вместе определили, когда элемент можно связать с ГЭСН по наименованию материала, а когда нужен классификатор. А что останется после завершения пилота? Настройки в программе? Человек, который «помнит, почему мы тогда сделали именно так»? Формальный отчёт? Так появилась идея Карточки ГЭСН☝️ --- Карточка нужна не столько для фиксации самой нормы, сколько для фиксации логики принятого решения. В ней отдельно записывается: - что это за ГЭСН и к какому разделу он относится; - какие качественные характеристики элемента нужны, чтобы выбрать именно эту норму; - откуда в ЦИМ брать объём и как переводить его в единицу измерения ГЭСН; - как связать норму с элементом модели – напрямую или через классификатор; - что делать с многослойными элементами; - чем проверить правильность полученной связи и какой у неё статус. То есть карточка отвечает не только на вопрос «что настроили?», но и на гораздо более полезный вопрос – «почему настроили именно так?» Причём она специально разделяет две вещи, которые легко смешать: данные, необходимые для выбора нормы, и данные, необходимые для расчёта объёма. ❗️Это важно, потому что наличие в модели материала и геометрии ещё не означает, что этих данных достаточно для автоматического выбора нужной расценки. --- И вот здесь, на наш взгляд, появляется ценность, которая выходит уже за рамки одного пилота. Если такую карточку заполнить по каждой отработанной норме, другой специалист сможет не просто получить готовый результат, а проследить ход рассуждений, согласиться с ним или указать на ошибку. Другая организация сможет взять наши наработанные связи «элемент ЦИМ → вид работ → ГЭСН», заменить наши коды классификатора и наименования материалов своими и адаптировать правила под собственную информационную среду. А настройки сметного ПО перестают быть чем-то, что можно передать только вместе со специалистом, который их создавал. В материалах пилота эта идея развивается дальше: карточки становятся основой для связанных справочников и формализованных правил мэппинга. По сути, мы постепенно приходим к довольно простой мысли: результатом пилотного проекта должен быть не только работающий сценарий, но и передаваемое знание о том, как этот сценарий был получен. Иначе следующая команда будет проходить тот же путь заново. А если логика решений сохранена, проверяема и пригодна для повторного использования – тогда осязаемые результаты пилота действительно начнут масштабироваться.
306
7
Мы участвуем в пилотном проекте Минстроя России по подготовке цифровых ведомостей объёмов работ (ЦВОР) на основе цифровой информационной модели (ЦИМ). По ходу работы столкнулись с вопросом, который, кажется, возникает почти в любом «пилоте»: как сделать так, чтобы накопленные знания не остались только в головах его участников? Поначалу задача подготовки ЦВОРов выглядела вполне прикладной. Чтобы не пытаться автоматизировать всё и сразу, мы решили начать с тех работ, которые сильнее всего влияют на стоимость объекта: 1. Определить наиболее капиталоёмкие позиции по разделам АР, КР и ОВиК. 2. Понять, какие ГЭСН за ними стоят. 3. Определить, какие данные нужны для выбора конкретной нормы и расчёта объёма. 4. Разобраться, как связать элемент ЦИМ с ГЭСН – напрямую или через код нашего классификатора? 5. На основании этого определить, какие материалы, единицы измерения и другие характеристики должны быть стандартизованы в параметрах ЦИМ. Логика вроде бы понятная: от стоимости – к норме, от нормы – к необходимым данным, от данных – к требованиям к модели. Но довольно быстро возник ещё один вопрос. Допустим, мы всё это прошли. Сметчик объяснил, почему для конкретной конструкции выбрана именно эта норма. ТИМ-специалист понял, из какого параметра модели брать объём. Вместе определили, когда элемент можно связать с ГЭСН по наименованию материала, а когда нужен классификатор. А что останется после завершения пилотного проекта – настройки в программе? Человек, который «помнит, почему мы тогда сделали именно так»? Некий формальный отчёт? Так появилась идея Карточки ГЭСН. --- Карточка нужна не столько для фиксации самой нормы, сколько для фиксации логики принятого решения. В ней отдельно записывается: – что это за ГЭСН и к какому разделу он относится; – какие качественные характеристики элемента ЦИМ нужны, чтобы выбрать именно эту норму; – откуда именно в ЦИМ нужно брать объём и как перевести его в единицу измерения ГЭСН; – как связать норму с элементом модели – напрямую или через классификатор; – что делать с многослойными элементами; – чем проверить правильность полученной связи и какой у неё статус. То есть карточка отвечает не только на вопрос «Что настроили?», но и на гораздо более интересный и важный вопрос «Почему настроили именно так?» Причём она специально разделяет данные, необходимые для выбора нормы, и данные, необходимые для расчёта объёма – две сущности, которые легко спутать. Это тем более важно☝🏻что наличие в ЦИМ сведений о материале и геометрии ещё не означает, что этих данных достаточно для автоматического выбора нужной расценки. --- И вот здесь, на наш взгляд, появляется ценность, которая выходит уже за рамки одного пилотного проекта. Если такую карточку заполнить по каждой отработанной норме, то другой специалист сможет не просто получить готовый результат, а проследить ход рассуждений, согласиться с ним или указать на ошибку. Другая организация сможет взять наши наработанные связи «Элемент ЦИМ → Вид работ → ГЭСН», заменить наши коды классификатора и наименования материалов своими и адаптировать правила под собственную информационную среду. А настройки сметного ПО перестают быть чем-то, что можно передать только вместе со специалистом, который их создавал. В материалах «пилота» эта идея развивается ещё дальше – карточки становятся основой для связанных справочников и формализованных правил мэппинга. По сути, мы постепенно приходим к довольно простой мысли: результатом пилотного проекта должен быть не только работающий сценарий, но и передаваемое знание о том, как этот сценарий был написан – иначе следующая команда будет проходить тот же путь заново 😬 А если логика решений сохранена, проверяема и пригодна для повторного использования, то тогда предметные результаты пилотного проекта действительно можно будет масштабировать.
2
8
Цифровизация строительства: договорились сотрудничать до 2030 года 🤝 Минстрой России и Правительство Свердловской области по+1
Цифровизация строительства: договорились сотрудничать до 2030 года 🤝 Минстрой России и Правительство Свердловской области подписали Меморандум о сотрудничестве в сфере цифровизации строительства. Со стороны Минстроя документ подписал заместитель Министра строительства и ЖКХ РФ Константин Михайлик, со стороны Свердловской области – заместитель Губернатора Сергей Швиндт. Но главное здесь – не ещё один документ с подписями хотя это тоже, бесспорно, важно. Главное – договорились, куда движемся дальше. Задача – перейти от отдельных цифровых решений к системной цифровизации строительства: связать цифровыми процессами участников и этапы инвестиционно-строительного цикла так, чтобы технологии действительно помогали делать его эффективнее, прозрачнее и качественнее. И речь уже не только о привычных нам ТИМ и государственных информационных системах. В планах: – обмениваться лучшими практиками и аналитикой; – получать методическую и консультационную поддержку Минстроя России; – участвовать в пилотных проектах по апробации перспективных цифровых решений; – применять ТИМ на всех этапах жизненного цикла объекта; – создавать условия для применения решений на основе искусственного интеллекта; – подключать к цифровой трансформации муниципалитеты и организации строительного комплекса. По сути, меняется сам подход. Цифровизация – это уже не про «давайте внедрим ещё одну систему», а про обмен опытом: применять в регионе проверенные федеральные решения и передавать наверх собственные успешные практики. --- Меморандум действует до 31 декабря 2030 года, конкретные мероприятия будут появляться в протоколах, планах и дорожных картах. Меморандум – не финал, а скорее старт. И самое интересное – увидеть, во что эти договорённости превратятся на практике в Свердловской области 👀
261
9
No text...
1 185
10
Пожинаем плоды объединения разрозненных таблиц заказчиков Свердловской области Помните, как некоторое время назад мы объединили разрозненные таблицы УКС Свердловской области в единую систему? Идея была простой: иметь оперативный доступ к актуальной информации, а не собирать её по десяткам сотрудников и сотням файлов. И, как это часто бывает с цифровизацией, бонусы обнаружились по ходу дела 😎 Теперь мы можем посмотреть сразу на все сметы контракта и получить общую картину, а не открывать каждый файл по отдельности. И вот что увидели, проанализировав 19 смет и ~3000 захваток. Напомним: захватка – это единица приёмки работ, то есть технологически законченный объём работ на объекте. Захватки формируют заказчик и подрядчик согласно Методике, утверждённой приказом Минстроя РФ 841/пр и с оглядкой на нашу Методику, которая расшифровывает подходы, установленные федеральной методикой. ☝🏻 Все проанализированные захватки условно разделились на 3 группы: 1. Сделано строго по Методике – 647 захваток Это позиции, оформленные ровно так, как показано в примерах Методики: – разработка грунта экскаватором в траншее по осям 1, 3, 5; – монолитная ж/б плита в осях 1-20/А-Ж – захватка №1; – огрунтовка основания под кровельный ковёр… в осях 1-20/А-Ж. 2. Разделение есть (и оно шире, чем описано в Методике) – 2 157 захваток Это самая интересная группа. Подрядчики самостоятельно выделили дополнительные элементы там, где это оказалось логичным и удобным для работы: – Лестница Лв-1 (КР1 л.26); – Стропильные конструкции (КР1 л.35-37); – Кладка наружных стен из газобетонных блоков, 1 этаж; – Перегородки в санузлах (АР л.7); – Шахта лифта. И знаете что? Это не ошибки. Это готовый материал для следующего шага. 3. Требует дополнительного анализа – 381 захватка Формально захватка есть, но по названию не очень понятно, что именно включено в предмет приёмки. Вместо конкретного вида работ в названии просто указан раздел проектной документации с добавлением слова «этап»: – конструктивные решения; – архитектурные решения; – сети связи; – сети связи и кабельные трассы; – наружные сети. ✅ Что со всем этим делать и почему это вообще хорошо? 1. Дополнить нашу Методику. Группа №2 показывает, какие элементы подрядчики регулярно выделяют на практике. Лестницы, крыльца, шахты и лифты, проёмы, кладка по этажам, фасады, полы, потолки – для них в Методике пока нет отдельных правил. Значит, будем брать реальные формулировки из практики и дополнять ими Методику. Получается, что подрядчики уже частично написали её за нас. Спасибо 🤝 2. Настроить ПО. Виды работ, которые подрядчики стабильно выделяют на разных объектах, можно превратить в готовые пресеты для программ, формирующих захватки. То есть не заставлять пользователя каждый раз начинать с чистого листа, а предложить проверенные шаблоны. 3. Видеть историю изменений. Здесь особенно пригодилось то самое объединение таблиц и их ежедневное автоматическое сохранение. Теперь мы можем увидеть, как захватка выглядела изначально: например, была одним большим монолитным блоком, а потом постепенно была разделена на несколько частей. А если однажды мы уже поняли, что такую захватку нужно разукрупнять, то логично требовать от подрядчика сразу формировать ее в нужном виде, а не исправлять всё «по ходу дела». Вот так обычное объединение таблиц превращается в инструмент управления и анализа. Умеем, любим, практикуем🙂 И цифровизируем 💪 – невзирая на!
310
11
Уважаемые коллеги и дорогие читатели! С Днём строителя вас! Желаем стабильного потока заказов и нулевой дебиторки, чтобы кажд
Уважаемые коллеги и дорогие читатели! С Днём строителя вас! Желаем стабильного потока заказов и нулевой дебиторки, чтобы каждый реализованный объект приносил не только радость созидания, но и надежный финансовый результат. Пусть цифровизация строительства станет вашим верным помощником при решении прикладных задач и покорении новых высот. Оставайтесь с нами на борту! Мы обещаем держать штурвал и уверенно вести вас по безопасному фарватеру в обход всех коварных нормативных мелей и организационных шхер 😉
274
12
🏗 Накануне юбилейного, семидесятого Дня строителя в Правительстве Свердловской области чествовали тех, кто каждый день помог
🏗 Накануне юбилейного, семидесятого Дня строителя в Правительстве Свердловской области чествовали тех, кто каждый день помогает развивать строительную отрасль региона. Среди награждённых – и цифровые спецназовцы нашего Минстроя. На фото (слева направо): заместитель начальника отдела ГИСОГД Эмилия Хрущелёва, главный специалист ТИМ-отдела Андрей Пруцков и главный специалист отдела ГИСОГД Татьяна Крутакова. 👏 Эмилия Ринатовна удостоена Почётной грамоты Губернатора Свердловской области. Награду за многолетний добросовестный труд, высокий профессионализм и вклад в развитие строительной отрасли региона вручил министр строительства и развития инфраструктуры Свердловской области Григорий Сурганов. 📜 Андрей Александрович и Татьяна Валерьевна отмечены благодарственными письмами Министерства строительства и развития инфраструктуры Свердловской области за многолетнюю добросовестную государственную гражданскую службу и в связи с профессиональным праздником. За каждым нормативным документом, каждой цифровой системой, каждым успешно реализованным проектом стоят люди, которые делают свою работу профессионально и с полной отдачей. Энтузиазм, неравнодушие и готовность отвечать на новые вызовы – поистине, чиновники именно с такой прошивкой нужны нам и нашей стране. Поздравляем коллег с заслуженными наградами 💫 Пусть впереди будет ещё больше интересных задач, успешных проектов и поводов для профессиональной гордости. Браво и – так держать!
331
13
Телеканал Россия 24 опубликовал тематический выпуск «Цифровизация в строительстве» в рамках цикла программ Есть решение. Почт
Телеканал Россия 24 опубликовал тематический выпуск «Цифровизация в строительстве» в рамках цикла программ Есть решение. Почти половина жилья в России строится с использованием технологий информационного моделирования. Отрасль активно применяет искусственный интеллект. В реестре отечественного программного обеспечения больше 400 продуктов предназначено для стройкомплекса. Как новые технологии меняют процессы проектирования и возведения зданий, какие разработки предлагает бизнес и как его поддерживает государство? Об этом расскажет Марина Громова в программе «Есть решение».
304
14
No text...
296
15
Мы начали с того, что такое ТИМ, ЦИМ и ИМ в целом. Затем разобрались с дисциплинарными ЦИМ и их связью с разделами проектной документации 💪  Теперь спускаемся еще на уровень ниже и поговорим об элементах модели – о том, благодаря чему обычные линии на чертеже становятся для компьютера осмысленной конструкцией. Человек смотрит на план и сразу понимает: две параллельные линии рядом – это стена. Компьютер так не умеет. Для него это всего лишь геометрия: отрезки, вершины, ребра, грани и координаты. Чтобы программа «увидела» в этом наборе линий стену, ей нужна дополнительная информация – семантика. Если не усложнять, то семантика – это смысловое наполнение информации, которой дополнена графическая часть модели, их соответствие проектным решениям и нормативным требованиям; насколько достоверно содержание ЦИМ отражает существо реального объекта или проекта. В современных САПР эта логика обычно строится на трёх уровнях – смысловом (классификация), параметрическом и связях элементов модели.   1. Классификация Над геометрией появляется своего рода невидимая бирка: «Я – стена». Само геометрическое ядро программы этого не понимает – оно работает только с телами и поверхностями. Но прикладной слой считывает этот класс и применяет нужные правила. Без такой классификации стена для программы ничем не отличается от плиты перекрытия или случайного параллелепипеда.   2. Параметры Это не просто набор характеристик вроде материала, толщины или высоты. Параметры описывают, как именно построен элемент. Например, стена – это результат вытягивания профиля на определенную высоту. Изменили один параметр – геометрия автоматически перестроилась. Именно так работает параметрическое моделирование.   3. Связи Самая интересная часть. Окно связано со стеной не потому, что визуально находится внутри нее, а потому, что между элементами существуют строгие математические зависимости. Передвинули стену – окно автоматически переместилось вместе с ней. В разных САПР это реализовано по-разному: через дерево построения, систему ограничений или другие механизмы. Но принцип один – элементы модели «знают» друг друга и друг о друге.   —— Закрепляем: для компьютера строительная конструкция – это не просто объёмная фигура. Это геометрия, поверх которой добавлены: – классификация; – параметры; – связи с другими элементами. Именно благодаря этому обычный чертёж превращается в ЦИМ.   Если после прочтения вдруг покажется, что компьютер «думает» слишком сложно – это нормально. На самом деле он вообще не думает – он просто очень педантично следует правилам. И именно поэтому так важно соблюдать правила сборки цифровой информационной модели объекта.
263
16
No text...
243
17
Автоматизированная проверка ЦИМ – цифровых информационных моделей – становится всё ближе. Анастасия Гусева (УКС Свердловской области) и Ольга Галитарова («Форум-групп») методично продолжают работать над тем, чтобы требования к объектам можно было проверять автоматически, без долгого ручного анализа – вот такой отличный пример B2G-взаимодействия. На сегодня они составили перечень требований к проектной документации по детским садам. А часть из них специалисты NSR уже перевели в машинопонимаемый вид. Теперь система умеет проверять, например: – соответствует ли площадь помещений нормативам (не менее установленного количества квадратных метров на человека); – соблюдены ли требования к взаимному расположению помещений (например, спальни нельзя размещать над пищеблоком). Но для полноценной автоматической проверки нужен единый понятийный аппарат; в нашем случае – единые наименования помещений. Здесь нам в помощь – Классификатор строительной информации (КСИ), а именно таблица Rzo «Зоны и помещения». О работе с КСИ мы уже рассказывали: ранее специалисты УКС направляли в ФАУ «ФЦС» предложения по дополнению классификатора наименованиями помещений из действующих сводов правил. Однако тот перечень не охватывал буквально все помещения детских садов. Поэтому мы подготовили дополнения и уточнения: ещё раз пересмотрели наименования групповых, вспомогательных и технических помещений, а также добавили категории помещений, которым раньше не было однозначного соответствия в КСИ. Отдельная благодарность коллегам из ФАУ «ФЦС» за оперативную работу! В классификатор уже добавлено более 30 новых наименований помещений с собственными кодами, а часть существующих позиций – уточнена и перераспределена по группам. _____________ P. S. Если вам нужно проверить цифровую модель своего ДОУ на соответствие нормативным требованиям – вы знаете, куда обращаться 😉
602
18
No text...
534
19
Месяц назад мы рассказывали, что сотрудники Минстроя Свердловской области и областного УКСа отправились изучать промпт-инжиниринг в строительстве. И вот обучение позади. Финальное тестирование сдали все: 14 из 14. Никто не сошёл с дистанции – уже хороший результат💪 Самое время рассказать, чему научились. За месяц участники прошли 7 модулей – от знакомства с тем, как вообще работают нейросети если честно, то с токенами некоторые из нас до сих пор на «вы» 😅, до вайб-кодинга и автоматизации рабочих процессов. Но главное – это не теория. Каждый модуль сопровождался практикой, поэтому участники не просто слушали лекции, а: – учились писать эффективные промпты; – примеряли на ИИ разные роли и сценарии; – готовили документы; – решали рабочие задачи; – создавали небольшие программы для автоматизации рутинных процессов. Насколько это было полезно, уже оценит руководство по результатам деятельности 😎 ————— Обучение прошло на базе Новосибирского государственного университета и Центра искусственного интеллекта НГУ. Если хотите организовать подобную программу для своей команды – смело обращайтесь. Коллеги помогут адаптировать обучение под ваши задачи.
271
20
🤖 Стандарт как код: почему цифровая трансформация упирается не в XML, а в лингвистику Когда говорят о цифровизации стандартов, чаще всего всплывают форматы - XML, JSON, ReqIF. Мол, переложи текст в теги, и вопрос решён. Но презентация Сергея Трофимова (Российский институт стандартизации) вскрывает куда более глубокую проблему: главный враг машиночитаемости не бумага, а язык. 🔴Вот несколько неочевидных точек, которые цепляют. 1. 593 тега это только начало NISO STS, используемый ISO и IEC, содержит почти 600 элементов разметки. Это не просто «структура», а попытка оцифровать юридическую иерархию. Но проблема в том, что даже идеальный XML не гарантирует понимания. Китайский AVIC пошёл дальше, они переобучают LLM на этих стандартах, чтобы извлечь не просто текст, а семантику для PLM и ERP. То есть переводят нормы на язык инженерных систем. Это уже не оцифровка, а интеграция. 2. Матрица рисков это диагностика всей отрасли Самый сильный слайд - таблица, где ошибки делятся по уровням: · Лексика → подмена терминов (искажение понятий). · Синтаксис → неверный парсинг (потеря структуры). · Семантика → сдвиг смысла (искажение требований). · Прагматика → ошибка применения (неверная норма). Цифровой стандарт это не документ, а система принятия решений. И если ИИ неправильно понял слово «должен» или «рекомендуется», последствия это не баг в интерфейсе, а сбой в производственном цикле. 3. Модальность это убийца логики «Должен», «следует», «может» - для нас привычные слова. Для модели - три разных правовых режима. Трофимов справедливо отмечает: сводить их к одной логической форме нельзя. Это требует отдельного слоя онтологий, где условие (антецедент) и действие (консеквент) не просто выделены, но и привязаны к контексту применения. 4. Российский институт стандартизации строит «цифровой полигон» Не просто базу терминов «Ростерм» (266 000 терминов!), а конструктор документов с автоматическим выделением требований. И это уже не про чтение, а про извлечение. Когда из текста вынимают метаблок с правилами, которые можно сразу скормить CAD или BIM-системе. 🔴Итоговая мысль из презентации: цифровая трансформация стандартов - это не перевод в PDF/A или XML. Это инженерия смысла. И успех здесь зависит не от выбранного формата, а от того, как мы формализуем иерархию, связи, модальность и условия применения. Иначе получаем удобную, но юридически ничтожную модель. А это дороже любого бумажного архива. #ИИ #ИИ_ИНП #TechNews  #ИНП 📲MАХимально на связи🔴 🤖 подписывайтесь: @NextGenInfrastructure
1 111