Основы моделирования в онтологической работе

24 апреля 2025

Основы моделирования в онтологической работе hero image

Продолжая изучать системную инженерию по курсам ШСМ, я наконец подобрался чуть ближе к моделированию и онтологической работе.

Кажется – что модель это нечто очень сложное, возможно даже запредельно сложное. Но это лишь мое субъективное ощущение, которое рассыпается сразу о первые вопросы – что я знаю о моделях и моделировании? И почему я думаю, что я это знаю?

Ничего я не знаю, давайте разбираться!

Сегодня мы рассмотрим все кратко, то есть – базово. Более подробное погружение в Системную Инженерию впереди, это долгий путь, оставайтесь на связи!

Что такое модель?

Ранее я присал о представлениях в контексте обсуждения собранности, внимательности, и заземления в реальность.

Является ли представление моделью? Да, является. То, что наши представления могут быть далеко оторваны от физического, реального мира, не лишает их свойств моделей.

По одной простой причине – любое наше представление это некоторая “частичка” нашего мышления. И само по себе мышление, в принципе, и есть моделирование.

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

Мы будем понимать под моделью что-то, что помогает рассуждать о чём-то другом (моделируемом).

Но модели, интересные нам, это далеко не про результаты мышления, основанного на не заземлённых субъективных представлениях.

Модели могут быть осязаемыми-материальными – буквально модель, например, самолета или машины; или неосязаемыми-информационными – схемы, таблицы, программы и другие текстовые описания.

Зачем нам модели?

Модели нужны нам, чтобы хорошо заземляться. Хорошо заземлившись, мы сможем эффективно передавать информацию между людьми и/или AI агентами.

Благодаря хорошей модели мы можем более основательно, предметно рассуждать. Если посмотреть чуть внимательнее, то наше мышление всё пронизано моделированием, иначе как бы мы смогли хоть сколько-нибудь (пусть даже иногда и не очень эффективно) планировать свою бытовую деятельность?

Более правильно будет даже сказать – мышление человека и есть моделирование.

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

Языки моделирования и их роль

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

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

Онтология и модели

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

Иными словами, выходит, что моделирование это часть онтологической работы.

Под онтологией тут будем понимать систему представлений о физическом мире.

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

Реальность и моделирование

Лучшая модель реальности

«…the best material model for a cat is another, or preferably the same cat…» Артуро Розенблют и Норберт Винер, «The role of models in science»

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

Здесь же ещё и рассматривается материальная модель кошки. Мы можем материально кошку очень красиво и подробно нарисовать, даже анатомически схематично в разрезе. Или из каких-то материалов сделать объёмную модель «кошка», которая в целом даст ещё более подробное представление о внутренностях животного.

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

И всё ещё, если мы берём «эту другую кошку» за модель нашей кошки N, то кошка N является ещё лучшей моделью себя, потому что она максимально приближена, «заземлена» в саму себя.

Объекты и роли в моделировании

Восприятие и выделение объектов

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

То, что ребёнок сначала воспринимает – это фон. Но со взрослением фон никуда не девается. На самом деле «по умолчанию» мы продолжаем пребывать в постоянном переживании своими органами чувств этого фона.

У нас есть множество представлений, “знаний” про объекты, но постоянно и обо всех объектах осознанно мы не думаем, мы не можем держать все и сразу в фокусе внимания.

Но мы можем выделять отдельные объекты и удерживать во внимании. Вот эта способность выхватывать и является ключевой для направленного моделирования/мышления.

Контекст и роли в восприятии объектов

Важно еще и то, как работает наше выхватывание объектов в зависимости от контекста. Если мы находимся в контексте, где натягиваем на себя роль – строитель, то нас в первую очередь будут интересовать такие объекты, как инструменты (каждый нужный для выполнения работы в отдельности) и строительные материалы.

Погода нас будет интересовать только как препятствующая или не препятствующая выполнению нашей работы, а всё остальное… например — насколько шум от наших работ мешает окружающим людям, нас волновать, скорее всего, сильно не будет, пока мы работаем в законодательно допустимых рамках времени и децибел.

Нас так же не будет волновать цвет и фасон одежды, которую мы носим на работе – лишь бы не жалко было испачкать/испортить.

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

Значение ролей для моделирования

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

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

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

Вот и сегодня, в этом материале, я пишу про онтологию, про «разработку языка» для коммуникации между ролями. Так при чём же тут безнадёжно устаревшие представления? Ни при чём.

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

Другое встречающееся заблуждение – чёткие границы — это плохо, нужно быть такими вот agile, диффузионными, чтобы работать эффективно.

Отступление про agile

Во-первых, agile – это ИМХО размытый, эвристический набор подсказок по организации методов работы; во-вторых, посмотрите на манифест:

**Люди и взаимодействие** важнее процессов и инструментов
**Работающий продукт** важнее исчерпывающей документации
**Сотрудничество с заказчиком** важнее согласования условий контракта
**Готовность к изменениям** важнее следования первоначальному плану

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

Как я и сказал – хоть и разумная, сплошная эвристика, которая может быть полезна, а может не быть полезна. Вокруг agile вырос и продолжает расти целый зоопарк методов работы, и это, наверное, нормальный эволюционный процесс.

Единственное чего я не вижу – так это хоть какого-то упоминания о том, что «чёткие границы» — это плохо.

«Люди и взаимодействие – важнее процессов и инструментов?» – отлично, а про каких людей, взаимодействия, процессы и инструменты вообще идёт речь?

«Работающий продукт важнее исчерпывающей документации?» – тут спорить сложно, но тоже не понятно, про какую документацию вообще идёт речь. В любом случае, документация не должна быть «исчерпывающей» в смысле просто объёма, но должна быть: 1) актуальной, 2) эффективной.

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

«Готовность к изменениям важнее следования первоначальному плану» – возможно, вот это та строчка, за которую хватается консервативный ум и обманывает сам себя? Мы все такие «диффузионные» и готовы к изменениям, но вот «на основе моего опыта и 45 безнадёжно устаревших книжек» – чёткие границы ролей это плохо. Чуете?

Agile не учит системной инженерии, Agile не учит программной инженерии, Agile вообще ничему не учит – это не прикладное руководство, а попытка группы уважаемых и опытных учёных выразить самое важное на основании их коллективного субъективного опыта. Есть ли ценность в Agile-манифесте? Конечно есть! Хватит ли вам одного Agile-манифеста, чтобы выстроить эффективный и рациональный процесс? Не хватит.

Разглядывая манифест Agile сквозь призму системной инженерии можно его нагло и немного обновить так:

  1. Роли и онтологии важнее процессов и инструментов, потому что без них правильные инструменты не выбрать и эффективные процессы не построить.
  2. Готовность к изменениям и само эволюционное изменение – инвариант, преследующий любую жизнедеятельность системы/организации.

Все остальное сейчас – не интересно. За этими строками – ещё здоровенный пласт онтологической и методологической работы, которую нужно проводить в начале работы/преобразования каждой системы, прежде чем лыжи поедут.

Чёткие роли – ответственность и работа, которую придётся делать. Готовность постоянно меняться – готовность убить/продать/отдать/выбросить свои старые убеждения, как только они не подтверждаются метриками.

Системная инженерия не про эвристики и не для слабаков.

Роли и функции объектов

В таких бытовых ситуациях, как те, что я приводил в пример чуть ранее (строитель / бойфренд), – осознавать свою роль не очень интересно и мало полезно.

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

Например, если мы ловим себя на том, что нам очень сложно с кем-то договориться на работе, может быть достаточным осознать свою роль и/или роль собеседника, чтобы договариваться стало проще (или вообще возможно).

Главное – найти ответ на этот вопрос – кто есть кто.

Осознание роли достаточно конкретизирует контекст, “картину мира” в рамках которой эта “роль” работает, что естественным образом помогает выбирать нужные объекты и слова.

Нужные объекты, это такие которые обладают необходимой функцией для того чтобы они были полезны в ходе выполнения нашей работы (по нашей роли.)

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

Получается, что для выполнения работы мы искали объект с функцией «долбило».

Тут ещё важно отметить, что наша роль, на самом деле, тоже функция.

Понятие «роль» более корректно и удобно в применении касательно самостоятельных агентов – людей, роботов, ИИ-систем, чем просто «функция».

Рефлексивные вопросы для выделения объектов

Итак, для того чтобы качественно выделять роли и объекты в нашей работе, нам надо задавать себе подобные рефлексивные вопросы:

Разделяемые онтологии и коллективная работа

Онтология как общий язык

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

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

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

Множественность ролей агента

Человеку, не знакомому с SoTA системной инженерии, может довольно легко показаться, что если мы выделяем роли в компании, то это автоматически означает 1 роль == 1 агент, и никак иначе.

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

Это совершенно не так.

Роль и Агенты — это вполне себе может быть отношение многие ко многим, не обязательно один к одному. Каждый агент в организации может выступать в одном и том же контексте (фоне) в разных ролях, и нередко – одновременно!

Да, это накладывает некоторое требование к мастерству исполнения методов каждой роли и ещё больше — к собранности исполнителя: надо в каждый момент понимать, в какой ты роли.

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

Возможно также, что одни и те же объекты интересуют разные роли, либо целиком, либо отдельные характеристики объектов.

При этом все они могут называть одни и те же объекты по-разному или наоборот — одними словами, но осознавать-подразумевать разные характеристики.

И это касается всех областей. Вы на своей работе и ваши коллеги точно так же имеете разные картины мира (ваши мозги пока ещё не соединяются проводами друг с другом), поэтому и возникают бесконечные сложности при попытках договориться об «очевидных» объектах и тому, как с ними работать.

«Вот бэкендер идиот! Как я устал ему одно и то же объяснять! 😡»

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

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

Что-то типа эпилога

Сегодня мы запоминаем:

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

Чем больше ролей будут использовать нашу онтологию – тем лучше, тем больше пользы во всей совместной работе мы получаем.

Кому нужен ваш язык, на котором говорите только вы, да ещё и непонятными словами! Так что придётся как-то ещё пробиваться, договариваться об онтологии, чтобы потом начать её использовать и уже договариваться о процессах, работе, инструментах/объектах и так далее.

Создание общепонятной онтологии

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

Такое привычное описание ролями своих предметных областей называется – viewpoint, и нам эту “точку зрения” очень важно знать настолько хорошо, насколько это возможно, когда мы выполняем роль онтолога, иначе мы не сможем построить рабочую и удобную онтологию.

Суть работы онтолога

Если резюмировать работу онтолога, то она заключается в том, чтобы:

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

Это большая, сложная, не одноразовая, а скорее эволюционная работа, и очень интересная.