🔘🔘🔘
🗣Наконец-то заработал режим диалога в нашем 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/