R6 Задание: мета-моделирование из руководства R6. Системное моделирование

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

Пост с моими мыслями будет прямо здесь. Ценность моделирования в целом для меня понятна уже какое-то время, и по мере прохождения руководств рабочего развития методы моделирования, их применимость в различных рабочих ситуациях становятся всё понятнее. Вместе с тем есть и вопросы. Например, концепция альф как таковая тоже мною понята, но, как верно замечено в руководствах, альфы - весьма неформализованное понятие, поэтому и в голове оно укладывается несколько сложнее чем более формально определяемые элементы мета-мета-модели. Видимо, это как раз тот случай, где кроме обучения в оде систематического медленного чтения для закрепления материала нужно ещё и довольно много примеров и самостоятельной работы с подкреплением от преподавателя - что в каком случае корректно называть альфой, и по каким рабочим продуктам можно отслеживать её состояние в проекте. Ещё одна мысль касательно моделирования связана с тем что в моём проекте по созданию внутри нашей компании инфраструктуры для работы на равных инженеров с белковым мозгом и с кремниевым (проект AI-Ready) я занимаюсь моделированием табличками довольно много, но все таблички создаются в ходе моих диалогов с LLM. Диалоги эти происходят в среде с подгруженными FPF и DPF, разумеется, поэтому таблички корректны с точки зрения первых принципов, системного мышления, правил моделирования и метамоделирования. Но так как моделируются сразу довольно сложные структуры (имеющие в своём составе большое количество ролей, работающих по большому количеству методов, соответственно разделённые на несколько системных уровней с различными видами рабочих продуктов на выходе) - таблички получаются с большим числом и столбцов, и строк, и их восприятие человеком (мной) требует немало ресурсов. Фактически получается, что работа по их созданию кремниевым мозгом занимает гораздо более короткий временной промежуток, чем работа по их интерпретации и оценке на корректность мозгом белковым. Да, это такая наша новая реальность, но пока к этому просто сложно привыкнуть, поэтому констатирую здесь как факт.

Очевидное следствие такого делегирования - в ходе работы LLM развитие белкового мозга не происходит, или по крайней мере происходит сильно медленнее, он не тренируется создавать модели самостоятельно. Одно дело - ходить в спортзал тренироваться, а другое - смотреть футбол по телевизору. Поэтому получается что отдельно стоит заниматься моделированием вручную, на небольших примерах (хотя и важных в работе), для целей тренировки мастерства моделирования вручную, для тренировки машинки типов, и укоренения в мозге методов системного мышления.
И отдельно следует решать задачи по моделированию с привлечением LLM, так как производительность такой работы на порядки выше ручного моделирования, ну и при подгрузке соответствующих элементов вроде FPF строгость соблюдения типов мета- и метаметамоделей в такой работе будет гораздо выше, а вероятность ошибки будет ниже.

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

Если говорить о конкретном примере - при моделировании деятельности нашей компании из 30 человек (посредством изучения ИИ наших же регламентов опубликованных вот тут Структура управления проектами) было выделено несколько сотен ролей и подролей и сообразное им количество методов работы. Разумеется при моделировании вручную такой уровень детализации был и невозможен, и не нужен - так как метод работы например архитектора при создании им концепции здания включал в себя большое количество выполняемых последовательно шагов, и не было нужды выделять каждый из них в отдельности. Наличие же “в штате” кроме белкового архитектора ещё и многочисленных ИИ-субагентов требует выделять для них роли с максимально короткими задачами, максимально понятными входами и выходами, чтобы минимизировать для них самих неопределённость в деятельности, и таким образом снизить и количество потребляемой энергии/токенов, и снизить вероятность их ошибки из-за неопределённостей в задаче. И в итоге бывшие когда-то длинными последовательными операциями работы бьются на множество маленьких коротких работ, для каждой из которых у агента есть своя роль, и свой метод работы. Оркестрация этого - неважно, живым ли человеком, или ИИ-агентом, становится сложнее, но за счёт качественных описаний она по крайней мере возможна, и возможно достичь какой-то повторяемости, а на надеяться на случайное везение в работе агента.


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

Беседы с коллегами происходят регулярно. В качестве примеров - сегодняшнее совещание по подготовке инфраструктуры компании к замене исполнения части процессов с людей на ИИ. Удерживал в голове организацию как систему создания для проектируемых зданий, инфраструктуру предприятия как её функциональную подсистему (функция - обеспечивает физические носители для работы программ и связь между носителями для передачи данных между ними в процессе исполнения программ), и конструктивную подсистему (здесь инфраструктура включает в себя несколько конструктивов - сервер в офисе, облачные хранилища данных, сетевые кабели и маршрутизаторы, а также установленные на этих серверах программные продукты - то есть сама делится на подсистемы, и функционально, и конструктивно). Не то чтобы я совсем не требовал этого от коллег, так как говоря об инфраструктуре, невозможно при формулировании частных задач по работе с ней не говорить о том что она состоит из составляющих и задачи касаются только некоторых из этих составляющих. Но конечно непрерывно о многоуровневости и многоаспектности я не говорил так как это и не нужно. Типы из мета-мета-модели упоминались - организация как система создания, инфраструктура как подсистема, причём в двух темпоральных состояниях - существующее (как есть) и задуманное (на самом деле ещё не задуманное, определить какой она должна быть и было одной из задач) - то есть состояние её в будущем, хотя обсуждали мы её конечно так как будто она уже эксплуатируется, то есть описывали её функции, чтобы далее на основе этого описания сформировать уже её конструктивное разбиение на подсистемы, которые позволят ей выполнять те функции которые мы от неё ожидаем, то есть инфраструктуру рассматривали как четырёхмерный физический объект. Коллегам я эти типы разумеется не называл так как это не требовалось. В роли документации системы выступало описание, подготовленное моим коллегой совместно с ИИ-агентом и выложенное в виде файла на github для совместного просмотра. Таких описаний было два, одно - описание существующей системы, и второе - будущей, оба их можно назвать моделями, соответственно это модели одной и той же системы в разные моменты времени, и нашей целью было определить методы изменения её состояния чтобы из соответствия одной модели она стала соответствовать другой. Таким образом, мы работали с альфой - описанием системы (инфраструктуры компании), стремясь изменить её состояние и через него - состояние самой системы. Насколько мне удалась эта беседа? На мой взгляд на 7/10, так как пока не уверен что на 100% удалось донести свою мысль до коллеги о том на основе каких данных следует сформировать описание целевой инфраструктуры, чтобы определить конкретные работы по её достижению. Возможно стоит больше внимания уделить именно концепции использования, сделать её более явно описанной через описание основной деятельности компании (строительное проектирование методом информационного моделирования), чтобы из этого описания было понятно какая для него требуется инфраструктура с учётом выполнения части (значительной) работ по проектированию ИИ-агентами. Для этой работы планируем привлечь дополнительного инженера, который как раз находится ближе к работам по проектированию, более хорошо знаком с методами проектрования, и поэтому наша гипотеза состоит в том что он более точно сможет сформулировать где и как AI можно встроить в работу инженера-проектировщика для ускорения прохода и повышения качества результата проектирования.


Ещё две беседы не буду описывать столь подробно, но если вкратце то можно упомянуть встречу с нашим специалистом по развитию бизнеса (так называется должность специалиста по продажам), где мы обсуждали нашу клиентуру как целевую систему, и встречу с заказчиком по перспективному объекту, где он представлял нам описание (концепцию) будущего объекта и ожидал от нас предложения по тому каким методом мы можем осуществить проектирование этого объекта с максимальным сохранением его “концепции”. При этом под концепцией в данном случае понимался в первую очередь внешний вид будущего объекта, что для меня добавляло определённой сложности в разговор - так как понятно что для комплекса зданий практически никогда внешний вид не должен являться определяющим при их проектировании.

1 лайк