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

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

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


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

🤩Я была в отпуске. И честно пообещала себе ничего не смотреть про работу.
Но, как назло прогремела новость:
👆👆👆🌟🌟🌟🌟🙂🙂🙂🙂
Состав цифровой информационной модели, дополняющей графическую часть разделов проектной документации, направлен на публичное обсуждение
И тут же началось активное осуждение обсуждение.❓

Много весёлого заметили будущие пользователи 👀
Например, требование указывать массу у помещения. Или, определение количества символов в коде КСИ заданием на проектирование, в определённых случаях...

Я честно ждала выхода на работу, чтобы высказать свою боль. Это – наименование габаритов у элементов. 👻

Например, судя по положениям нового документа, у стены нужно указать: толщину, ширину, длину, высоту.🎰
❗️Оставим шутки про стены в четырёх измерениях.

Допустим, что можно что-то из перечисленных параметров не заполнять.👓
Высота и толщина – худо-бедно однозначны для понимания.

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

Почему длина и ширина взаимозаменяемы ❓

Потому что, длиной невольно хочется назвать габарит, который явно больше всех, включая высоту. А шириной – если меньше.

🟠То есть, в одном и том же проекте, одни и те же элементы будут иметь отличный набор наименований характеристик 🐊

Как же тогда реализовывать нормативные проверки❓
(Никак)
Мы никогда не сдвинемся с мёртвой точки, если не установим твердо и четко перечень характеристик для описания разных объектов: стен, перекрытий, ступеней, помещений. И не зафиксируем, что, в какую сторону будем измерять.🖋

Утопия, но куда ж без неё 🥲

🔥NSR Specification отправляется в большой тур вместе с nanoДРАЙВ! 🔥

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

✈️Наш маршрут:
📌 10 апреля — Казань (СиСофт Казань)
📌 15 апреля — Тюмень (СиСофт Омск)
📌 22 апреля — Санкт-Петербург (Ромбит, ТиБиЭс)
📌 24 апреля — Екатеринбург (АйДиТи)
📌 14 мая — Красноярск (Макссофт-24)
📌 20 мая — Новосибирск (МедиаТехнологии)
📌 3 июня — Челябинск (Нормасофт)
📌 5 июня — Уфа (Бюро САПР)

Стартуем в Казани!
🚀 10 апреля, Kazan Palace by Tasigo
✨ От NSR Specification — Максим Журавлев

🔊 Что будет ?
🔹 nanoCAD — универсальная САПР-платформа для инженеров
🔹 BIM/ТИМ — эффективное проектирование и управление
🔹 Цифровая документация и автоматизация процессов
🔹 3D-моделирование и геотехнический мониторинг
🔹 Паспортизация объектов и сводные цифровые модели

О чем расскажем мы❓
👉 Машинопонимаемые правила проверки — как автоматизировать контроль проектов и избежать ошибок.
👉Новые функционал — свежие обновления, которые расширяют возможности проверок, делая процесс точнее и удобнее.

🎁 Плюс:
💡 Нетворкинг с экспертами
🎧 Розыгрыш умной колонки, наушников и других крутых призов

✈️ Следите за нашими анонсами! Будем напоминать вам о каждой встрече, чтобы никто не пропустил своё событие.

✅ Регистрируйтесь на ближайшую конференцию:
Присоединиться
Увидимся на nanoДРАЙВ! 👀

‼️ ВАЖНЫЕ НОВОСТИ ‼️

С 1 апреля 2025 года вступило в силу Постановление Правительства РФ №157, согласно которому все коммерческие организации обязаны провести ревизию оборудования и изделий в административных помещениях! 🏢

Что это значит?
Теперь каждая компания должна присвоить объектам коды Классификатора Строительной Информации. Включая:
✔ Офисную мебель
✔ Технику и оборудование
✔ Даже розетки и выключатели!

⚠️ Первые проверки стартуют уже этим летом. Несоблюдение требований грозит серьёзными санкциями⚠️

🦾 Команда NSR Specification гордится тем, что одной из первых выполнила все требования и готова помочь остальным!

⏳ Времени осталось немного – советуем не откладывать! 🚀

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

1️⃣ Проверка информационных свойств объектов (верификация/валидация) 📊
2️⃣ Проверка геометрических коллизий 📏❌

А нам же, для решения наших задач, надо и то, и то, да еще с перламутровыми пуговицами! ✨
Тем радостнее нам было начать работу с панелью проверки nanoCAD , в которой каждый день можно открывать для себя новую функциональность:

✅ Многоэтапные проверки — позволяют оценивать положение множества объектов относительно друг друга 🔄
✅ Возможность использовать формулы — не только в условиях проверки, но и в условиях отбора объектов 🧮
✅ Расчет площади группы — не по атрибутивным значениям, а по геометрическим размерам 📐 (например, можно собрать группу помещений и сравнить суммарное значение площади с допустимым)
✅ Расчет суммы атрибутов группы — снова собираем группы и оцениваем сумму значений любого числового атрибута ➕
✅ Количество объектов в группе — или общее количество в модели. Например, можно посчитать количество эвакуационных выходов в здании или на каждом этаже.

Вояж по Санкт-Петербургу закончился в офисе NSR Specification, где продакт-менеджер одноименного продукта очаровательная Ольга Кутузова провела ликбез на тему перевода документов в машинопонимаемый вид.
Вторым слушателем Ольги Константиновны стал начальник отдела информационных технологий в градостроительной деятельности Министерства строительства и архитектуры Архангельской области Алексей Холопов.
---
Кроме этого, успели обсудить:
– возможность и перспективы добавления функционала по генерации задания на проектирование в «Подсистеме требований» NSR Specification;
– поиск требований, влияющих на оптимальность принимаемых проектных решений;
– повышение доверия к поисковым наборам цифровой информационной модели на соответствие требованиям нормативной документации.
---
Сердечно благодарим Ольгу за готовность помогать решать не самые простые задачи в работе бюджетных заказчиков 🔥

P.S. А на втором фото вы можете лицезреть прекрасный вид из нового офиса команды NSR.

Как здорово было встретиться с нашими потрясающими коллегами и друзьями!

Всем привет! 😊 Хотим немного нагнать жути 👻 и заодно похвастаться. Мало того, что мы осилили разметку требования из ПУЭ, которая больше напоминала макраме, так еще и настроили экспорт РАБОТАЮЩЕЙ проверки для CADLib МиА! 🔥 Слабонервным не смотреть! 😱😆

👋 Всем привет!

Ну а пока удобный сервис для подбора нормативных требований (из вчерашнего видео) ещё в работе, хочу показать инструмент, которым можно пользоваться уже сейчас 🚀.

🔎 Это фильтрация требований стандартов проектирования с помощью кодов КСИ.

📌 Для нашей подсистемы требований мы классифицируем КАЖДОЕ НОРМАТИВНОЕ ПОЛОЖЕНИЕ, привязывая к нему:
🏗 Коды объектов и характеристик
🏢 Коды зданий/сооружений
📅 Коды стадий строительства

В общем, лучше один раз увидеть! 👀
Приглашаю посмотреть короткий обзор!

🛠️ Терпение и труд всё перетрут... или как заставить ИИ работать над инженерными задачами?

Хотим поделиться своим частным опытом 🤓

📌 Задача: систематизировать параметры для классификации зданий, которые есть в нормативных документах 📑, для фильтрации требований.

🔍 Для чего? Чтобы одним махом ⚡ определить требования из различных документов, которые подходят к конкретному объекту.

💡 Гипотеза: а что если попробовать загрузить в Perplexity Своды Правил и попросить ИИ 🤖 проанализировать, какие параметры зданий и сооружений учитываются в условиях применения требований?

🎛️ Режимы генерации: Deep Research, Reasoning, Pro search
📊 Формат представления результатов: таблица.

❌ Результаты: ответы были каждый раз неполные. В промптах были использованы и угрозы, и уговоры, и мольбы 🙏... После многочисленных попыток заставить Perplexity выдавать осмысленные и полные данные, возникла идея экспертного модуля.

🧐 Что это такое?
Это механизм, в котором ИИ анализирует свои же ответы, играя роль эксперта по нормативным документам 📖, заполняя пробелы в информации. Происходит полная донастройка space, назначение всех входных данных и требований к форме отчёта.

✅ Такой подход позволил глубже систематизировать данные и выделить ключевые параметры, отсутствовавшие при простых ответах.
📈 В результате мы получили объёмную таблицу, качество которой сложно было оценить с первого и второго взгляда 👀.

😵 Замучившись сами и замучив R1, решили упростить задачу.

🆕 Новая задача:
📌 Проанализировать области применения Сводов Правил серии 13330 и снова попробовать выделить классификационные параметры.

❓ Формат представления результатов:
Мы поняли, что сами не знаем, чего хотим. Табличный вид сильно ограничивает возможности отображения данных сложных по структуре. Так что, как постановщики задач, мы так себе.

💡 Решение: не просто попросить ИИ проанализировать данные, но ещё и предложить лучший вариант отображения результатов.

⚡ Результат: после потока угроз начали пробовать вежливые, но настойчивые промпты. Эффект был ошеломительный: спустя час ИИ смог выдать код на Python 🐍, который запускал очень симпатичный сервис. Там можно было заполнить основную информацию об объекте строительства и получить подборку СП 📑, чьи требования нужно соблюдать.

👀 Сперва набор параметров выглядел неполным, но после множества промптов удалось довести его если не до идеала, то хотя бы до предела текущих возможностей ИИ (и нашего терпения 😅).

🎥 Смотрите видео!

📢 Выводы:
Без экспертной валидации/верификации пока не обойтись 🧐. Мы сейчас будем работать над этим. Тем более, что у каждого нормативного положения могут быть свои дополнительные критерии области применения.

Тем не менее, мы всё равно остались под впечатлением от возможностей рассуждалки R1 🤯.

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

🟠Это чисто обывательская подборка! Мне показалось, судя по вопросам от друзей и знакомых, что часто бывает интересно попробовать, но, не всегда понятно с чего начать.

Сразу скажу, что для начала никаких специализированных знаний не требуется!
1️⃣ https://www.perplexity.ai/ - Поисковая система в интернете в режиме реального времени, на основе ИИ (Подключены разные LLM, включая самые последние). Доступна загрузка документов, а значит, можно загрузить статью или стандарт и запросить анализ). Есть free режим!
2️⃣ https://chat.mistral.ai/ - Французская LLM, очень ее люблю. Тоже можно загружать документы и есть free режим.
3️⃣ https://chat.qwenlm.ai/ - Китайская LLM, не "та самая", но, тоже очень хорошая. Примечательна стабильной работой, free доступом, возможностью загружать документы, и даже видео она умеет создавать.
4️⃣ https://chat.deepseek.com/ - Та самая LLM, о которой все говорят. Базово отвечает V3, но можно включить режим рассуждения R1. К сожалению, работает не всегда стабильно (Server busy).... Free режим в наличии!

Если Вам интересно понять, чем отличаются разные LLM (ИИ), вот любопытный сервис:
5️⃣ https://llmarena.ru/ - Бенчмарк LLM моделей на русском языке. Задаете вопрос, получаете ответ от двух моделей, оцениваете, кто лучше, и наконец-то видите, кто вам отвечал. LLM разные! Есть и наши-отечественные и зарубежные.

Когда устанете от экспериментов с генерацией текста- можно отдохнуть, создавая музыку:
6️⃣ https://suno.com/ - free режим с ограничениями по количеству, но, зато какие крутые результаты!

Еще есть хорошая подборка в статье с habr, актуальная до сих пор. Правда, для доступа к многим сервисам нужен vpn... https://habr.com/ru/companies/first/articles/753922/

Хочу немного позанудствовать и пооткровенничать заодно.🤓
О том, что с документами области технического регулирования надо что-то делать - говорят сейчас практически все. Обсуждают Реестр требований, создаваемый в рамках ресурса Стройкомплекс.РФ. Рассуждают на тему перспектив внедрения параметрического метода нормирования и разных подходов к нему.

С замиранием сердца команда NSR следит за новостями из прекрасного будущего. Но, необходимо признать, что живем то мы в суровом настоящем, и позитивных перемен хочется уже здесь и сейчас.
🤔А что если попробовать автоматизировано поискать связи между "Исключениями" и "Требованиями"? - подумали мы. Нет, речь не идет о жестких связях, только подборки предсказаний. Векторный поиск нам в руки и барабан на шею. Да и база нормативных положений у нас есть в наличии.
Начать решили с поиска определений для требований и исключений, а заодно и всего остального, чем может быть "нормативное положение".
Заглянули в ГОСТ 1.1-2002* "Международная стандартизация. Термины и определения" и нашли там чудесный набор ценных сведений. О том, что положение нормативное может быть и требованием, и правилом, и рекомендацией.... Об исключениях ни слова, но есть "альтернативное требование" : требование нормативного документа, которое должно быть выполнено в рамках выбора, допускаемого этим документом.
Может быть это и оно, подумали мы и полезли смотреть в ГОСТ 1.5-2001 "Общие требования к построению, изложению, оформлению, содержанию и обозначению". А там - никаких альтернативных требований. Зато появляются "инструкции", как возможное содержимое стандарта.
Может, хотя бы какие-то слова-маркеры найти, для классификации нормативных положений? - спрашивают меня наши программисты. Смотрю - действительно есть такое! "При изложении требований и инструкций в тексте стандарта применяют слова: "должен", "следует", "подлежит", "необходимо", "требуется", "разрешается только", "не допускается", "запрещается", "не должен", "не следует", "не подлежит", "не могут быть" и т.п."
Не успели порадоваться - читаем: "Допускается использовать в стандарте для требований и инструкций повествовательную форму изложения, если из его наименования или заголовков разделов (подразделов) ясно, какие положения стандарта являются требованиями (инструкциями)."
Но, хоть с исключениями все понятно, понадеялись мы. Стандарт четко говорил, что "могут быть", "как правило", "при необходимости", "допускается", "разрешается" - явный признак возможности отступить от требования или инструкции.

А теперь, внимание: "В одномаршевых лестницах, а также в одном марше двух- и трехмаршевых лестниц в пределах первого этажа допускается не более 18 подъемов." - требование или исключение? Мне кажется, все же требование.

Есть еще ГОСТ Р 1.19-2023, конкретно про изложение положений Сводов Правил. К сожалению, внутри нет никаких тайных знаний. Примечательно только вот это заявление: "Использование в тексте свода правил формулировок "как правило", "при соответствующем обосновании", "в случае особой необходимости", "преимущественно", "рекомендуется", "предпочтительно", "могут", "в необходимых случаях", "целесообразно", "нецелесообразно" и тому подобных, придающих требованию статус рекомендательного, не допускается, за исключением случая, когда после использования таких и аналогичных им формулировок в тексте размещается пояснение, исчерпывающим образом характеризующее отступление от требований, выраженное путем применения указанных выше формулировок".

Мы не сдаемся! Мы даже попытались сформулировать классификацию нормативных положений, а ИИ как мог улучшил формулировки)
🔵Требование: Нормативное положение, содержащее критерии, которые должны быть соблюдены при проектировании, строительстве или эксплуатации элементов объектов капитального строительства (ОКС). Эти критерии поддаются объективной проверке методами расчетов, измерений, экспертиз или моделирования.
🔴Исключение: Нормативное положение, содержащее условия, при которых допускается отступление от установленных требований. Оно определяет обстоятельства, при которых требования могут не применяться полностью или частично.
🟢Инструкция: Нормативное положение, регламентирующее способы оценки соблюдения требований и порядок выбора критериев оценки. Оно может описывать методику проверки, порядок действий, критерии классификации или расчета параметров элементов ОКС.
🟠Справочная информация: Нормативное положение, содержащее советы, рекомендации, разъяснения или ссылки на другие требования, без введения обязательных критериев. Оно может указывать на существующие нормы, лучшие практики или условия, которые следует учитывать, но не содержит проверяемых обязательств. Характерные фразы: "рекомендуется", "может применяться", "целесообразно", "для информации", "следует учитывать".

Пытаемся сейчас применить эту классификацию в нескольких документах и далее натравить на задачу ИИ. Попытка не пытка.... Может хоть термины уточним.

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

«Я вам посылку принес, вот только я вам ее не отдам» (с) И.И.Печкин
🚀 Друзья, с радостью представляем вам наш обновленный — NSR Specification модуль семантического анализа! Это пока еще наш внутренний продукт, но мы усердно работаем над улучшением его функционала и готовим его к бета-тестированию пользователями 🔥
Хотим похвастаться:
✨ Измененный интерфейс ✨
Первое, что бросается в глаза — это совершенно новый, интуитивно понятный интерфейс. Мы постарались сделать его удобным для себя самих, а значит, есть надежда, что он понравится и нашим будущим пользователям. 😎 Выглядит круто, не правда ли?
🧠 Расширение набора семантических компонентов 🧠
Мы добавили новые семантические компоненты, которые значительно расширяют функциональность и делают продукт более интеллектуальным. Например, Calculated property используется для обозначения параметров, которые нужно измерить в ЦИМ, а не просто сравнить значение атрибутов. 💡
🔗 Новые связи между объектами 🔗
Теперь можно работать с новыми типами связей: структурной и связью местоположения. Это позволяет точно и гибко описывать взаимодействия между объектами 🔄
⚡️ Калькулятор ⚡️
Мы заменили связи между ограничениями и правилами, которые выполнялись через стрелки, на более продвинутый калькулятор. Теперь можно просматривать каждый шаг создания правила проверки и все варианты результатов. Это не только нагляднее, но и быстрее! ⚡️
📊 Поддержка работы с формулами
Очень часто в требованиях критерии проверки имеют не абсолютное, а относительное, расчетное значение. Теперь мы можем размечать и их!
📈Обновленное окно классификации
Мы также внесли изменения в этап классификации.
Теперь, помимо кодов КСИ, можно привязывать понятия в тексте требований к пользовательским атрибутам из реальной ЦИМ.
Появились 4 режима выбора значения: код классификатора, выбор из списка, ручной ввод и понятие из текста. 🔢
Логику (равно/не равно, больше/меньше) мы считываем автоматически из текста, но добавили возможность назначения логики вручную. ⚙️
⚠️ Внимание! ⚠️
В видео мы разбираем не настоящее требование, а скорее набор слов, отдаленно напоминающий требование. Просьба понять и простить, мы не смогли найти реальный пример, на котором можно показать работу всех новшеств. 📹
🙏 Выражаем благодарность команде программистов, которые терпели и терпят наш нескончаемый поток пожеланий к доработке. Мы это ценим! 💪

Мы рады поделиться, что наша коллега Ольга Кутузова недавно приняла участие в увлекательном подкасте Игоря Рогачёва! 🎙️
В этом выпуске обсудили как технологии ИИ уже применяются в строительной и проектной деятельности, какие возможности открываются и зачем нужны машиноинтерпретируемые правила проверок в BIM-проектах.
А также, не пропустите разговор о применении LLM и машинного обучения для работы с проектными данными!🎧

https://m.vkvideo.ru/video-167876578_456239198

🔥🔥🔥 Важная новость.
Спешу рассказать, пока еще она теплая😋
Вчера состоялся релиз 25 версии Платформы nanoCAD, в которой появилась панель проверки модели.
Почему это круто?
Потому что, для того, чтобы отработать все многообразие логических операций, которые можно выделить в нормативном требовании средней заковыристости, нужен незаурядный функционал программы, реализующей проверки.
В процессе отладки проверок для пилотных проектов мы постоянно сталкивались с необходимостью комбинировать подчас не подходящие операции для воссоздания нормативного сценария. 🙂‍↕️
И вот, разработчики nanoCAD (тысячу раз спасибо их терпению) вняли нашим мольбам и реализовали панель, где есть 1001 операция, для того, чтобы рассматривать положение объектов относительно друг-друга, учитывать структурные связи, рассчитывать параметры (в том числе и с использованием формул). Вплоть до подсчета количества. Отдельная песня - бесконечность вложенных операций проверки, которые могут передавать друг-другу результаты своего анализа. Там так много всего, что мы еще до конца не разобрались😅
❗️nanoCAD конечно не заменит BIM-агрегатор, где можно анализировать тяжеленную сводную ЦИМ.
Зато, именно в САПР будет правильнее всего получать подсказки в процессе проектирования чтобы избежать нарушений!
Осталось нам настроить выгрузку правил для nanoCAD из нашей разметки!
А вот ссылка на отрывок записи релиза платформы, где я рассказываю о панели проверок!
https://rutube.ru/video/private/f8ba9ebcf76112695fbf41f1b79bb621/?r=wd&t=1985

Логика рассуждений нам очень понравилась! Но...(ох уж эти "но")...
Мы честно пытались получить подтверждение со ссылкой на спецификацию w3c или protégé. Deepseek же писал логичные мысли и даже ссылался на похожие разделы, но цитаты были некорректные😔

Может, нужно лучше пытаться! И мы конечно же продолжим.

P.S. Лично меня бесконечно радуют аналитические способности китайского чудо-думателя. Ну, и то, что меня поддержали, тоже было очень приятно😘

Причём тут R1, спросите вы? А именно к нему мы обратились за помощью.
Ответом мне очень хочется поделиться.
Ответ с позиции логики и онтологического подхода: Если школа онтологически является подклассом общественного здания (т.е. принадлежит к категории "общественные здания"), то между требованиями возникает формальное логическое противоречие. Обоснование: 1. Логический анализ Исходные утверждения: Требование 1: ∀x (ОбщественноеЗдание(x) → ШиринаЛестницы(x) > 2м). Требование 2: ∀x (Школа(x) → ШиринаЛестницы(x) > 1м). Онтология: Школа ⊂ ОбщественноеЗдание. Противоречие: Если школа — подкласс общественного здания, то для всех школ автоматически должно выполняться Требование 1 (>2 м). Однако Требование 2 разрешает школам иметь лестницы >1 м, что ослабляет условие для подкласса. Это нарушает принцип наследования свойств в онтологиях: подкласс не может иметь менее строгих ограничений, чем родительский класс, если иерархия не допускает явных исключений.
Онтологический подход Классическая онтология: Если свойство родительского класса (ОбщественноеЗдание) задано как обязательное (например, "все общественные здания имеют лестницы >2 м"), то подкласс (Школа) не может его отменить или ослабить без явного указания на исключение.
В противном случае возникает конфликт наследования: объект класса Школа одновременно должен удовлетворять двум взаимоисключающим условиям: Ширина лестницы >2 м (как общественное здание). Ширина лестницы >1 м (как школа).
Возможное решение: Если в онтологии явно указано, что для школ действует специальное правило, переопределяющее общее требование для общественных зданий, противоречия нет.
Например: ∀x (Школа(x) → [Переопределить(ШиринаЛестницы(x) > 1м)]).
Типы противоречий.
Логическое противоречие: Для объекта Школа выполняются оба условия: Школа → ОбщественноеЗдание → ШиринаЛестницы >2 м. Школа → ШиринаЛестницы >1 м. Если ширина лестницы школы = 1.5 м, она удовлетворяет Требованию 2, но нарушает Требование 1. Это неконсистентность в онтологии.
Прагматическое противоречие: Даже если в онтологии зафиксировано исключение для школ, возникает вопрос: почему для подкласса (Школа) установлено менее строгое требование, чем для родительского класса (ОбщественноеЗдание), если школы — места массового скопления людей, где безопасность критически важна? Это противоречит принципу специализации (подклассы должны уточнять, а не ослаблять свойства).
Пример формализации утверждения: ОбщественноеЗдание(x) ⟹ ШиринаЛестницы(x) > 2 (Требование 1). Школа(x) ⟹ ОбщественноеЗдание(x) (онтология). Школа(x) ⟹ ШиринаЛестницы(x) > 1 (Требование 2). Вывод: Для любого x, где Школа(x), из онтологии следует ОбщественноеЗдание(x), а значит, должно выполняться ШиринаЛестницы(x) > 2. Однако Требование 2 позволяет ШиринаЛестницы(x) > 1, что создает противоречие при значениях 1 < Ширина < 2.
Как устранить противоречие? Уточнить онтологию: Либо исключить школы из класса общественных зданий. Либо явно указать, что для школ требование о ширине лестниц переопределяется. Иерархия требований: Если требование для школ — специальная норма, а для общественных зданий — общая, то специальная норма имеет приоритет (при условии, что это зафиксировано в правилах).
Корректировка требований: Сделать требования согласованными, например: "Для общественных зданий, кроме школ, ширина лестницы >2 м". "Для школ ширина лестницы >2 м" (устраняет противоречие). Итог Противоречие есть, если школа онтологически является подклассом общественного здания, а в требованиях нет явных исключений. С точки зрения логики и онтологического моделирования, это нарушает принцип непротиворечивости и наследования свойств.
Решение: Пересмотреть онтологию или требования, чтобы устранить конфликт (например, разделить категории или согласовать нормативы).

Добрый вечер всем!
Какое напряженное выдалось начало года, дни летят с утроенной скоростью: презентации, вебинары, интервью.... 🤪 Мы обязательно расскажем обо всем по порядку. Но сейчас хочется поговорить о главной новости в области ИИ: выход модели DeepSeek-R1 и первом опыте применения для решения наших разработческих бытовых задач.
🤓Так вот, бытовая задача, актуальность которой стала прямо таки давить на нас: определение того, что является противоречием в нормативных требованиях. Казалось бы, ответ очевиден. Но, только на первый взгляд🧐
Придется вас погрузить в наши рассуждения, уж извините. Сегодня мы пробовали рассмотреть комбинации выдуманных требований с количественными критериями оценки.
1⃣Пример 1.
Требование 1: "В здании школы ширина лестницы должна быть более 2 метра".
Требование 2: "В общественном здании ширина лестницы должна быть более 1 метра"
На мой субъективный взгляд, требования не являются противоречивыми, т.к. школа является подвидом общественного здания, и соблюдение требований к ширине лестницы (более 2 метров) не нарушит требований к ширине лестницы общественного здания (более 1 метра).
2⃣Пример 2
Требование 1: "В общественном здании ширина лестницы должна быть более 2 метров".
Требование 2: "В здании школы ширина лестницы должна быть более 1 метра"
А вот эти требования, как мне кажется, являются противоречивыми, т.к школа является подвидом общественного здания, и возможны варианты, когда соблюдение требований к ширине лестницы в школе (допустим 1,5 метра, это более 1 метра) нарушит требования к ширине лестницы общественного здания (более 2 метров).

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

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

Так вот, специалисты в области онтологии тут же мне возразили, что Пример 2- не является противоречием, с точки зрения логики. Т.к. есть варианты исполнения, когда будут выполнены оба требования. Мол, противоречием является "А" и "не-А" и аналогичные конструкции...