Учебный центр СПб ГАУ «Центр государственной экспертизы» 👩‍💻 предоставил нам уникальную возможность рассказать о своей работе слушателям курса "Технология Информационного Моделирования" (https://t.me/spbexp_ru/784).

👽Я изо всех сил старалась быть максимально откровенной освещая текущую ситуацию.
🌏А, чтобы поддержать надежду на светлое будущее автоматизации ⭐️ впервые показала вживую полный цикл преобразования требований в правила проверки ЦИМ на разнообразных примерах.

Процесс разметки требований сложно назвать легким, зато этот метод реально работает и рушит опасные иллюзии про волшебную красную кнопку.🚨


💫Огромное спасибо @AlexanderShilo за поддержку
Ещё большее спасибо слушателям за внимание, терпение и интерес к нашей непростой работе!⭐️

Давно хотели показать, как мы мастерски научились обращаться с текстом требований для конвертации правил проверки ЦИМ! Надеемся, что вам будет не слишком скучно🐱
P.S. Процесс разметки текста - ерунда по сравнению со съемками демонстрационного видео) Зато сколько багов поправили в процессе!🌌

В предыдущем посте мы выложили видео, где во всех подробностях был показан процесс разметки текста требований. ⬆️
Внимательный зритель неизбежно задастся вопросом: "Ну и где же ваш хваленый ИИ, с помощью которого происходит автоматизация? Не считая подсказки семантических компонентов?"
Поэтому, хотим показать вам еще одно видео. С подсказками разметки простых суждений, которые мы можем запрашивать у генеративной модели.
Да, эти подсказки пока далеки от идеала: ИИ ошибается при выборе типа суждения (тип структурный вместо местоположения); добавляет лишние компоненты в суждения... Но, он учится! 👩‍🚀
И, мы очень надеемся, что наш модуль разметки не только выполнит конкретную задачу преобразования текста требований в правила, но и поможет ИИ начать лучше понимать тексты требований.❤️

У нас ничего не получается 🤩

💜💜💜

крик души разработчика ПО (а душа у нас все-таки есть♍️).

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

Это очень напоминает управление марионеткой на ниточках с помощью креста (ваги).🤩

Чем мы можем оперировать:
💜 фильтры по свойствам объектов
💜 оценка минимального расстояния (когда в случае наличия одного объекта относительно другого на определённом расстоянии- работает условие проверки)
💜 оценка наличия объекта (трудно для понимания, но, против факта не попрешь: в этом случае условие проверки будет работать, когда не получилось обнаружить один объект на определённом расстоянии, относительно другого)
💜 оценка пересечения объектов (условие проверки работает в случае, если есть физическое пересечение объектов)

И это все. Понимаете🪻Все🪻

А это означает 🤩
что из требования к лестницам в лестничных клетках, у которых должна быть определённая ширина или уклон, надо получить условие минимального расстояния: искать помещение/зону лестничной клетки относительно объекта лестницы, и, если она обнаружилась, то проверять значение ширины

🤩 Если же проверять надо лестницы не в зоне лестничной клетки, то, позарез надо обратить внимание на это коротенькое отрицание 🤩"не"🤩 и зацепившись за него, как за якорь ⚓️ создать условие проверки наличия объектов.
Чтобы оценивать свойства только тех лестниц, у которых лестничных клеток не нашлось😊

И это еще пол беды, а вот что делать с "открытыми лестницами"🪻
Как из этого текста получить в явном виде указание на то, что речь о лестницах не в лестничной клетке🪻

🖇Колясочная должна располагаться на расстоянии менее (не более) Х метров от входа - наличие соседних объектов
🖇Котельная должна располагаться на расстоянии более (не менее) Х метров от склада горючих материалов - минимальное расстояние

Тут уже надо искать 🖇comparative relation🖇, разумеется вместе с отрицанием "не" и в зависимости от их значения создавать правильное условие

❕А ведь может быть и "колясочная не должна располагаться на расстоянии более X метров от входа"😁

Вы только не подумайте, это все решаемо✅
Просто за любым алгоритмом автоматизации обязательно есть человек, который продумал и описал логику работы во всем многообразии вариантов🙏
А мы ещё и первые на этой не самой прямой дорожке🏃‍♀️

В качестве благодарности всем, кто выдерживает наши занудства, хотим показать интерфейс нового QA-чата (Вы будете первыми!).🚀

Совсем скоро начнем бета-тестирование. Надо только улучшить поиск фрагментов НД (за счет добавления мета-информации и внедрения гибридного поиска).

А! Еще добавим гиперссылки на подсистему требований. И будет совсем хорошо.🌌

Меня часто спрашивают:

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

Причём отвечать надо в деньгах, на крайний случай, в процентах💰

Я, наверное, очень плохой продакт-менеджер☹️
потому что, подобные вопросы ставят меня в тупик.
До чертиков не люблю оперировать данными, которые невозможно проверить...🥲

Хочу пооткровенничать тут.⬇️

Итак, любая новая технология (а NSR- это новая технология) при внедрении неминуемо приведёт к увеличению трудоёмкости ⏺️

Взять хотя бы автоматические проверки для ЦИМ.

📌Чтобы их применять, необходимо не только пересмотреть и переработать нормативы, но и навести порядок в самом процессе проектирования.
Как минимум, понадобится разработать и внедрить стандарт, который позволит создавать единообразные, насыщенные информацией и структурированные ЦИМ ✅

Только тогда можно будет применять универсальные проверки по нормативным сценариям 🖇️

И, если из такой ЦИМ будут выгружены комплекты чертежей ПД/РД, то, количество ошибок, разумеется, сократится. И можно будет ожидать повышение эффективности проектирования в виде сокращения сроков,  трудозатрат и прочее, прочее.

➡️Судя по проведённым пилотным проектам, в каждой пользовательской ЦИМ, около 30% проверок показывают реальные проблемы и ошибки.

❌Не соблюдаются минимальные расстояния между коммуникациями

❌Встречаются нарушения площадей помещений

❌Размещение объектов там, где их нельзя размещать

Здорово ли то, что мы можем найти такие нарушения?

Конечно здорово✨

Найденные и исправленные ошибки повышают шансы пройти экспертизу с первого раза🙏

Но, если ЦИМ так и останется красивым трехмерным образом🎰, который подняли по чертежам просто "чтобы было", то проверяй её автоматизировано, вручную или не проверяй вовсе -

пользы не будет никакой🐱🐱

🌚
Как бы так закончить чем-то позитивным?

У нас всех есть два пути:

1️⃣Оставить все как есть, без лишних трудностей и дополнительной пользы

2️⃣Не пожалеть своих усилий, чтобы потом иметь шанс на качественное улучшение рабочего процесса

🌼Мы выбираем не мечтать о светлом будущем, а твердо шагать в его направлении!🌼

Испытала непреодолимое желание показать вживую конвертацию правил проверки ЦИМ из разметки. Без купюр, так сказать🤪
Сразу дико извиняюсь за то, что показываю на примере, который мы уже успели заездить. Но текст этого требования слишком удачный с точки зрения вариативности интерпритации🔥.
Для тех, кто смотрел прошлые демонстрации - что-то новенькое начинается с 6-й минуты🎆
Upd* Я очень боюсь внимательного зрителя, поэтому поясняю: CADLib МиА нумерует группы отбора начиная с 0, поэтому проверка характеристики "Высота ограждения" совершенно правильно сработает для группы1, под которой как раз и скрываются фильтры для отбора объекта "Лестница"😊

Если сам себя не похвалишь... это за тебя сделает ИИ!!(Спасибо SUNO AI за песню🤩) Вот ссылка, если вам тоже хочется, чтобы про вас спели:

https://suno.com/ 🤩

Я торопыга🤪 Так спешила продемонстрировать работу новой функции отображения правил проверки ЦИМ в Подсистеме требований NSR Specification, что снимала ролик на одном дубле и забыла попрощаться🧑‍🚀Надеюсь, вы простите эту оплошность!
Самое главное: в скором будущем мы сможем начать публиковать базы профилей проверок ЦИМ для наших пользователей!🔥

Рубрика: NSR любит усложнять🔥

📍ЗАДАЧА:

Подготовить векторную базу фрагментов из пользовательских документов. Это нужно для реализации RAG-системы — движка, на котором будет работать наш QA-чат (мы уже активно его готовим к релизу).
🟡🟡🟡
Зачем❔
Чтобы чат мог не просто «искать по PDF-ке», а по-настоящему понимать документы, анализировать их, отвечать на вопросы, выявлять противоречия, несоответствия и прочие радости технической документации.

Кажется, всё уже придумали: передал документ в LLM — и готово.
❕Но, как обычно, не всё так просто.

Сегодня активно обсуждается end-to-end подход: загружаем в мультимодальную языковую модель весь PDF целиком, и она сама всё делает — определяет, где заголовки, где таблицы, где просто текст, и возвращает идеально структурированный результат✔️

Звучит как магия🔶
А по сути:
➡️один пайплайн,
➡️минимум ручной настройки,
➡️гибкость под любые форматы.

📎Но реальность вносит коррективы:
➡️стоит дорого,
➡️работает медленно,
➡️не всегда понятно, что модель сделала внутри (а сделала ли?),
➡️и, самое неприятное — возможны «галлюцинации»: модель может сгенерировать текст, которого в документе никогда не было. Даже если очень попросить — не делать🙃

Такой подход действительно выглядит как самое очевидное и желанное решение.
❕Но внедрять его в прод — рискованно. Особенно если важна точность.
⚫️⚫️⚫️
Поэтому вот другие, не менее крутые (а местами и надёжнее) варианты извлечения данных из PDF⬇️:

1️⃣▶️Извлечение текстового слоя (GetText)
Если в PDF документе текст сохранён как текст, а не как изображение, его можно извлекать напрямую — символы, строки, абзацы.
➕ высокая точность, «чистый» текст, без искажений и опечаток.
➖ структура PDF может быть нестандартной — текст часто хранится как фрагменты с координатами, а не логически связанные абзацы. В итоге порядок строк может нарушаться. Метод неприменим к сканированным страницам✉️

2️⃣▶️OCR (оптическое распознавание символов)
Если PDF — это скан или изображение, каждую страницу можно конвертировать в картинку (например, PNG) и передать в OCR✔️
На выходе — текст с координатами. Но возможны искажения, «битые» токены, проблемы с кодировкой.
Для повышения читаемости можно дополнительно применять языковые модели👤

3️⃣▶️OCR + LLM
Сочетание OCR и LLM позволяет восстановить логическую структуру текста — используя координаты и контекст, модель делает текст более читаемым и структурированным.
➖Но есть недостатки:
⏹️повышенная нагрузка на вычисления,
⏹️увеличение времени обработки,
⏹️и опять же — риск генерации лишнего текста (галлюцинации).

4️⃣▶️Гибридный подход (GetText + OCR + LLM)
Наиболее сбалансированное решение:
✔️если в документе есть текстовый слой — используем GetText,
✔️если это скан — подключаем OCR,
✔️затем применяем LLM для очистки и структурирования результата.

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

Мы, как пионеры, не боимся трудностей, сами их находим и с честью преодолеваем 🔥

🔘🔘🔘
🗣Наконец-то заработал режим диалога в нашем QA-чате!

Зачем он нужен❓

Чтобы LLM при обработке запроса пользователя смогла задать уточняющие вопросы и найти более подходящие фрагменты требований для ответа📍

📱На скринах видно, как модель переспросила, что именно интересует пользователя, и на основе уточнённого запроса нашла нужную выдержку из СП 106.13330.2012 — да-да, даже про зелёного попугая 🦜

Это тоже осознанно сделано из экономии ресурсов: сейчас ограничено одним уточняющим ответом от LLM❓
Но в перспективе можно будет расширить: например, до 3–5 шагов, а может и вовсе без ограничений🔴

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

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

👨NSR Specification смогли проверить работоспособность своих инструментов обработки требований в рамках пилотного проекта с РЖД!👩

🟢Мы очень хотим выпустить универсальный инструмент, который действительно будет работать на практике. Именно поэтому нам важны пилотные проекты, в ходе которых мы дорабатываем свой функционал.

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

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

🌐А на практике - никто не знает,  будет ли это работать.

Поэтому, нам надо показывать и доказывать🔈Форсировать интерес, создавать спрос. И когда РЖД согласились показать нам свою ЦИМ, чтобы мы смогли попробовать применить наши сценарии проверки - это была фантастическая возможность🪄

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

Наивные мы.
Итак, к делу.

➡️Укрупненный список вызовов:

1️⃣ РЖД использует свой отраслевой классификатор для описания элементов ЦИМ.  И он прекрасен, потому что позволяет обеспечить настоящую информационную полноту модели.
Решено было использовать только его и не добавлять новых атрибутов (обычно мы добавляем характеристики элементам, значения которых задаём на основе визуального осмотра, расчёта на основе других значений или запрашиваем информацию у Заказчика)

2️⃣ ЦИМ была передана в формате ifc. А проверки решено было запускать в CADLIB Модель и Архив. Из-за данных факторов мы не смогли использовать некоторые структурные связи элементов.

3️⃣ Требований для пилота было отобрано немного. Всего четыре. Зато каких! Тут тебе и табличный формат, и заковыристые формулировки, и расчётные значения которые нам надо было преобразовывать в формулы...

4️⃣ Одно из требований устанавливало минимальные расстояния в свету. Специально для таких случаев у CADLIB МиА есть функционал проверки минимального расстояния в плане. А вот у нас в Модуле семантического анализа требований не оказалось нужного инструмента для передачи данной особенности. Пришлось реализовывать!👦

И вот, счастливый финал, мы показываем коллегам из РЖД результаты наших экспериментов... 🚆

🚅И слышим в ответ, что мы не учли важный момент:

нормативное требование устанавливает минимальное расстояние между осями трубопроводов, а CADLIB МиА измеряет расстояние между стенками труб. В самом требовании этот нюанс прямым текстом не озвучен.
Но, специалисты то знают!

В общем, нужно пересчитать.

О, счастье,  у нас получилось и это👍
С костылями и молитвами (ибо прямого указания нет).
Но, получилось!
В, общем, смотрите видео:

💡 ИИ в nanoCad. Максим Журавлёв о сценариях использования ИИ в отечественном ПО

В этом видео:
00:30 - процесс цифровизации стандартов проектирования
01:40 - перевод документов в машиночитаемый вид (модуль семантической разметки)
02:27 - база машиночитаемых требований
03:48 - почему нужно проверять ЦИМ, а не чертежи
05:00 - как выглядят машиночитаемые требования
05:28 - как создавать машиночитаемые требования
06:28 - модуль семантического анализа от nanoSoft
06:57 - настройка правил на основе результатов семантического анализа
09:42 - анализ модели на основании правил
11:09 - требования к BIM-агрегаторам, выполняющим проверку
12:06 - панель проверки моделей в nanoCAD
12:55 - предпосылки разработки инструментов
14:04 - анализ технических текстов с помощью ИИ
16:25 - схема связи модулей NSR Specification

➡️ Cмотреть на 💙 ВК | 📺 YouTube | 📺 Rutube | 📝 Дзене
➡️ Блог NSR Specification
➡️ Презентация

🟡Стать партнёром BIM Просвета

#BIMПросвет #BIMПросветAI #BIMSupport #AI #AIBIM #ИИ #ИИТИМ #нанософт

Два года мы собирались с мыслями, чтобы наконец-то опубликовать статью о работе Модуля семантического анализа NSR Specification, который преобразовывает нормативные требования в вид правил проверки ЦИМ (настоящий машинопонимаемый вид).

Спешим поделиться ❤️
https://habr.com/ru/companies/nanosoft/articles/936874/