Политическая информация
Русское (по языку, а не по стране) отделение INCOSE продолжает работать по-прежнему, игнорируя любые санкции и попытки остановить жизнь, работу, исследования и общение. Собрались на очередную (уже тринадцатую) рабочую встречу в Бекасово, 13-16 апреля 2023. Название не меняем, на формальные аспекты ситуации внимания не обращаем: пусть бюрократы заняты своим, а мы будем заниматься делом. Чтобы насилия в мире было поменьше, нужно иметь хорошую (то есть системную) инженерию, и не только киберфизических систем, но и всего инженерного стека систем разных уровней -- вещества, киберфизики (с софтом), существа, личности, организации, сообщества, общества, человечества. Напастей (эпидемий, войн, природных явлений, астероидов и так далее) в мире много, их число не будет уменьшаться, старые проблемы будут возвращаться вновь и вновь, а самые большие неприятные неожиданности нам пока ещё неизвестны. К этим проблемам нужно быть готовым и лично, и организационно. Так что решаем не прямо сегодняшнюю ситуацию, а играем вдолгую -- и стараемся работать быстро. Поэтому мы перестаём ориентироваться на происходящее в INCOSE, там всё как-то законсервировалось и инженерия там уже не такая уж и SoTA (из причин: много госпроектов, в том числе военных, отставание в программной инженерии и развития AI, отставание в непрерывной разработке, отставание в поколении системного мышления, задержки в развитии из-за необходимости преемственности в сертификации, надёжно устаревшей, равно как надёжно устарели и стандарты типа ISO 15288:2015). Приходится двигаться вперёд самостоятельно, находясь на глобусе, игнорируя при этом и границы стран, и границы общественных инженерных организаций.
AI в инженерии
Сейчас ключевой момент в инженерии: будет резко изменен метод инженерной работы, ибо самые умные решения уже не факт, что будет принимать человек или команда людей, даже с приданным им не-AI инструментарием. Основные черты современной ситуации:
-- Copilot X показывает основной путь развития: X означает всё, что угодно (и уже выпущен Copilot Security).
-- размер имеет значение, создание больших MLLM запредельно дорого, поэтому инженеры их будут пользовать стандартные (как все пользуются Гуглём). Основная инженерная экспертиза будет в доучивании на наборах данных, а также в prompt engineering.
-- теорема бесплатного обеда работает, две архитектуры для её использования: Toolformer и TaskMatrix. Похоже, что плагины к системноинженерному классическому софту не за горами, ждём-с. Инженерный софт продолжит развиваться, только дёргать его будет уже не всегда человек.
-- основной ресурс развития: память и "рекурсия", . Похоже, что всё будет как с людьми: разделение труда на множество ролей (это делается через domain knowledge и prompt engineering) и последовательная работа этих ролей над небольшой оперативной памятью (называют "рекурсивные вызовы нейросети", каждый раз задействуется обновлённая память и чуть другая часть самой нейросетки). Грубо говоря, "поставить задачу и оставить на ночь", для решения инженерных задач при помощи AI потребуются жуткие вычислительные ресурсы.
-- вычислительные ресурсы будут расти (алгоритмы, но и другая аппаратура -- кванты, оптика, непосредственно нейросети-на-квантах как у Ванчурина, плюс классические вычислители не стоят на месте, см. конкуренцию между TPU Гугля GPU NVIDIA).
-- наша стратегия во всём этом: мастерство prompt engineering (все наши курсы про ролевое мастерство, про семантику-онтологию с выходом на нейросемиотику, и даже системный менеджмент и лидерство у нас как раз про это, мы по факту готовы), плюс почищенные "ручной работы" наборы SoTA знаний, вытащенные из мировой помойки и как-то гармонизированные (обучение универсальной LMML на наш domain -- получаем "спеца", а не "эрудита"). Сейчас AI -- jack of all trades, master of none, а по идее, может стать спецом в решении проблем. Наш слоган остаётся "обучим всё, что думает", но обучение это будет, похоже, на базе универсальной MLLM модели и далее каких-то манипуляций эмбеддингами, маленькой памятью и последовательными вызовами MLLM в разных ролях (как говорит Karpathy, новый CPU -- это LLM, а новый язык программирования -- английский).
-- ещё жива идея корпусной инженерии (наборы данных современных инженерных решений) для дообучения каких-то маленьких моделей для вариантов TaskMatrix и Toolformer. Это тоже может помочь по линии конкурентных преимуществ, но сами решения будут быстро стареть, старые корпуса инженерных знаний быстро потеряют значение.
Довольно долго мучали наш бот https://chat.aisystant.com/, конечно, пытались его поломать. Ломается он легко, в бредогенерацию переходит уверенно и непринуждённо. Ждём GPT-4 как бэкенда, пока там не очень умная GPT-3.5-turbo. Шутили, что отвечает бот примерно так же как студент. Но бот поумнеет, а студент -- нет.
Исследования по системной инженерии
Про исследования по системной инженерии (такой курс читается изучающим системную инженерию в МИРЭА) есть подразделы курса системной инженерии в первом же разделе:
-- Инженерия и наука
-- Методология системной инженерии как инженерная наука
-- Ненаучность инженерии. Эвристики
-- Исследования/наука как «научение птиц полёту»
-- Инженерная наука
Конечно, учить будущих мастеров системной инженерии тому, как проводить исследования в этой предметной области, очень полезно. Вопрос (как всегда) в содержании образования и его форме. Для исследований профильной предметной областью с мета-мета-моделью будет эпистемология, которую мы делим на две дисциплины:
-- рациональность (и какой-то обзор текущего содержания дисциплины приведён вот тут: https://ailev.livejournal.com/1619025.html). Ключевой вопрос -- это рациональность против эмпирицизма-индукционизма, то есть аксиоматические теории с фальсификацией конструктивных моделей на основе этих аксиом против "выводимых из данных". У нас сейчас наиболее близок к обучению рациональности курс "Создание объяснений", но там ещё много надо добавлять (объяснения не только создавать нужно, но и использовать их для принятия решений, так что теории принятия решений -- это сюда).
-- познание/исследования как способ улучшать объяснения (попперианское науковедение с докрутками Дойча и Перла по поводу того, что не любая идея идёт в зачёт, но только контрфактически сформулированные объяснения). Внутрь объяснения и их использования не погружаемся, но зато понимаем, что нет "доказательств" по поводу объяснений, зато хорошо прокритикованные и устоявшие/нефальсифицированные объяснения надо "принимать всерьёз" (класть их в основу своего действия).
Рациональность и познание/исследования дают понимание, что же является содержанием научных статей и какое место занимает научная статья в общем прогрессе научного знания. И вот теперь можно читать статьи, для чего можно предложить написать обзор/реферат по статьям на какую-то тему.
Обещал дать ссылку на текст о том, как писать обзор (всё то же применимо и к обзору научных работ, хотя можно попросить давать и обзоры каких-то инженерных трендов): https://ailev.livejournal.com/94301.html. Основная мысль тут в том, что без опоры на теорию (как теорию рациональности и познания, так и теорию в обозреваемой предметной области) все усилия студентов будут пусты, ничему они не научатся. Если даже заставить "выбрать тип мета-исследования, а затем провести исследование по методичке этого исследования", непонятно, чему именно научатся студенты. Это всё равно как посылать студента сделать обзор зоопарка: что-то будет описано (морские млекопитающие, или особенности фундаментов под клетки, или уровни зарплаты сторожей в зависимости от стажа), но что и зачем, и кому это нанесёт пользу и как научить наносить непоправимую пользу студента -- это останется за рамками работы. Но это же самое главное, чему учить! Поэтому теория (а не списки примеров/кейсов) -- сначала, а обзоры -- потом. Но, конечно, результатом должна быть письменная работа студента, это не вызывает сомнений.
Как дотащить результаты образования до работы
Если смотреть на образование (а образование системных инженеров -- это тоже образование), то одной из важнейших проблем будет дотаскивание выученных практик до работы. Мы нашли четыре идеи, которые помогают это сделать:
- Явное введение многоуровневой онтологии, которая изучается на наших курсах. Это позволяет различать, типы какой из моделей мы можем опускать в речи, а в типах какой модели ведём мышление. Явный запрет на употребление в разговоре типов "птичьего языка" мета-мета-модели (то есть терминологии из наших учебников), но предписание собственное мышление (поиск того, о чём надо подумать -- это прежде всего: чеклисты) вести в типах этого языка.
- Смена фокуса действия, которому учим. Вместо "наши курсы делают вас лучше" теперь звучит "наши курсы помогают сделать лучше мир вокруг вас". Сюда добавляется инструкция, что "власть не дают, а власть берут": если от соседей прилетают разные пожары, надо инициативно (без команды и запроса разрешения) прийти к соседям и помочь им с распожаризацией. А как эту распожаризацию делать, рассказано в наших курсах. Но фокус смещается с "у себя" на "у коллег".
- У нас нет учебных упражнений/тренировок, у нас все задания на базе рабочих проектов. Мы учим использовать подручные универсальные моделеры (даже из воздуха, даже из руки, даже из флипчарта, даже из вордового файла), чтобы делать эти задания. В нашей вроде как учебной системе использован простейший моделер (по сравнению с которым coda.io или notion.so на работе -- это просто роскошь, которой грех не воспользоваться). Всё, что мы ожидаем от студентов -- они после окончания обучения по какой-то теме просто продолжают заполнять эти таблички ровно так же, как они это делали в ходе заданий. Возможно, будет более удобный моделер, но ничего принципиально нового (ибо мышление об этом ведётся на уровне мета-мета-модели, а domain model произвольна).
- Поскольку у нас нет упражнений и тренировок, то выполнение заданий -- это уже не тренировка, а просто работа по выученному в курсе материалу. Её надо делать в рабочее время! С этого момента отговорки, что "у меня время на личную жизнь, учёбу и работу строго лимитировано" не принимаются, ибо на учёбу времени практически не нужно -- условно можно считать чтение "учебника" из курса таким временем, но в предлагаемом подходе это только "контекстный хелп" к рабочим заданиям, инструкция по мышлению на работе. Так что и его можно читать на работе. По оценкам наших студентов, на работе этот подход окупается x10-x100, поэтому никаких угрызений совести, что рабочее время тратится на учёбу. Нет, это время тратится на выполнение работы, это не учёба, можно считать это "консалтинг со стороны Aisystant по работе", заниматься им в рабочее время, а подписка на курс -- это такая подписка на консалтинг по постановке SoTA инженерии и менеджмента.
Кто делает учебные программы для подготовки инженеров
Обсуждалось, как реагировать на критику по поводу содержания учебных программ, и на основе чего их готовить. Ответ тут простой: критику студентов игнорировать, они не могут критиковать то, в чём не разбираются. Поэтому идея тьюторства как "управляемый учеником запрос на образование" оказывается неверной (пункт 4 из https://ailev.livejournal.com/1145422.html). Как у Монтессори: педагоги там утверждают, что дети "самозаинтересовываются" каким-то материалом, но при проверке оказывается, что там довольно сложная и детальная процедура внешнего заинтересовывания детей (грубо говоря, котят мордой тыкают в блюдечко с молоком -- не ждут, пока они "догадаются", ибо не догадываются!). Со студентами так же. Университеты не должны подстраиваться под рыночный запрос и выпускать тех, кого просят работодатели, ибо работодатели не знают, что им надо будет через несколько лет, когда студенты будут выучены. Генералы всегда готовятся к прошлой войне. Университеты не должны подстраиваться под рыночный запрос и выпускать тех, кого просят студенты: студенты меньше всего знают, что им потребуется в будущем, они неквалифицированы принимать решения. Университеты должны понимать, что они готовят к будущему, а промышленники и студенты всегда просят образовать их в прошлом (о будущем они не знают), поэтому образовательный план должен формировать сам университет независимо от требований работодателей и студентов. Ибо через пять лет обучения работодатели и студенты будут сильно удивлены, как их требования поменялись: они ж экстраполируют прошлое, а заглядывать в будущее — университеты как раз для этого.
Это означает, что университет должен формировать рыночный запрос к своим учебным программам, в этих программах он вполне себе шумпетеровский предприниматель и смотрит в мутный кристалл будущего. А "чем докажешь качество товара" -- это только репутация, поэтому всё с университетами долго. Ну, и дальше эксплуатация ошибки выжившего: пять блестящих удачных в жизни выпускников на пятьсот безвестных (но в случае хороших вузов с правильно подобранными родителями -- безвестных в плане успехов, но "со связями", университет-не-для-знаний, а для "нетворкинга").
Если начинаем реально учить чему-то типа инженерии и менеджмента, то меняется и бизнес-предложение: само обучение в части его полезности занимает бОльшую долю в стоимости учебных программ, а тот самый "нетворкинг" (со скиллами prompt engineering к мокрым нейросеткам) -- меньшую. В этой области тоже целина непаханная. И если честно учить инженеров не ОБЖ (основы безопасности жизнедеятельности, где в том числе зарыта и военная подготовка), а интеллект-стеку, инженерии и менеджменту, но добавлять в плане этого "нетворкинга" программу лидерства себя, коллектива, сообщества -- то и рыночное предложение необычно, и даже ценообразование тут под вопросом.
Как обычно, попытки обсуждать вузовское образование "как надо бы это делать" сразу разваливались: как было замечено в кулуарах, какое-нибудь подписание даже рамочного безденежного соглашения с ШСМ увязло бы в административной трясине. Поэтому "в вузах делаем что можем" и пользуемся предложением бесплатного доступа к курсам ШСМ для студентов вузов, в этой опции не надо подписывать никаких бумаг с администрацией вузов: https://blog.system-school.ru/2022/10/13/predlozhenie-dlya-vuzov-i-prepodavatelej-vuzov-do-1-sentyabrya-2023-goda/. Что можем, то делаем.
Онтика сервисов
Онтика сервисов до сих пор вызывает множество вопросов. Она хорошо описана в новой версии "Практического системного мышления". Вот резюме дискуссии по этой онтике, которое подготовил по итогам встречи Кирилл Гайдамака: https://blog.system-school.ru/2023/04/16/k-obsuzhdeniyu-ontiki-servisov-i-use-cases/
Явное описание этой онтики в курсе позволило решить следующие задачи (в принципе, всё это есть в курсе ПСМ, и даже больше, и с примерами):
-- ввело две точки зрения относительно границы системы (внешняя и внутренняя). Снаружи точка зрения видит потребную функцию в надсистеме и ищет аффорданс с нужным сервисом. Изнутри функция обычно неизвестна, но можно визионерски предложить сервис -- и надеяться на то, что он для функции будет подходить.
-- различие имён сервиса и функции для одного и того же поведения системы важно как раз чтобы обсуждать подбор аффорданса под функцию. Назначаем работу (сервис от экземпляра системы) на функцию, требуемую от системы в надсистеме.
-- онтика сервиса очень удобна для описания юскейса.
Отдельный вопрос был на тему, чьё поведение описывают юскейсы. Я хорошо понимаю, что общепринятая позиция -- это "с точки зрения акторов, то есть описывается поведение акторов, как они удовлетворяются". Я читаю не так, я читаю, что описывается прежде всего поведение системы в сложной среде, и можно делать выводы о том, какое поведение ожидается из акторов, если система ведёт себя таким образом. Давайте обратимся к первоисточнику, статье Якобсона про Use Case 2.0 (https://www.researchgate.net/publication/301704896_Use-case_20), момент с определением юскейса "от автора":
A use case is:
-- A sequence of actions a system performs that yields an observable result of value to a particular user.
-- That specific behavior of a system, which participates in collaboration with a user to deliver something of value for
that user.
-- The smallest unit of activity that provides a meaningful result to the user.
-- The context for a set of related requirements.
Чётко видно, что юскейс -- это прежде всего поведение системы (в ответ на всякие триггеры от окружающих акторов), чтобы для акторов были в конечном итоге удовлетворительные результаты, то есть система выполняла требуемую для них функцию в надсистеме своим сервисом. Но я понимаю, что по большому счёту все эти рассуждения про "с чьей точки зрения описывается система" имеют правильный ответ -- как с точки зрения сервисов, так и с точки зрения функций, так надёжней всего. При этом, как обычно, в 9 из 10 случаях они по названию будут совпадать (особенно, когда речь идёт об интегрировании как способе достижения interoperability по ISO 11354 (то есть когда "всё разрабатываем сами", а не полагаемся на стандарты как в унификации и не прилаживаем неприлаживаемое как при федерировании). Но в одном случае из десятка функция и сервис будут различаться, и в этом месте ожидаются проблемы.
Для меня онтика сервисов показала себя в реальных студенческих группах очень хорошо: с ней очень хорошо работаем в случае таких систем как "экскаватор с приданным к нему экскаваторщиком и экскаваторным заводом", то есть позволяет говорить о всяких разных серверах/службах/провайдерах сервиса, коих сейчас каждый первый в связи с тотальным переходом от товаров к услугам. Мы делаем станок, который делает сервис шлифовки, которых подшлифовывает деталь, которая в свою очередь будет выдавать во время своего использования какое-то поведение. Для этого ещё и добавлена альфа работы целевой системы, чтобы не забывали, что всё изготавливаемое тоже будет работать, поэтому что-то там вовне себя менять-создавать. Цепочки создания с изготовлением всяких серверов и прочих станков стало очень легко проходить, путаницы стало много меньше. Ну, и там ещё сеансы сервиса -- они добавляют понятности, привязывают ко времени и ресурсам.
Архитектура предприятия: сначала курсы, иначе содержательного разговора не получается
Обсуждали разные подходы к архитектуре предприятия. Тут у меня два соображения:
-- перестаньте использовать архимейт, и будет вам счастье. Если используете архимейт -- не жалуйтесь, что всё получается плохо, что вас никто не понимает. Это не случайно, что получается всё плохо и вас никто не понимает. Используйте принципы моделирования, которым мы учим.
-- если уж занялись архитектурой, то прочтите профильную литературу, иначе это будет непрофессионально и вы будете изобретать кривые велосипеды. Например, учебник системной инженерии (там про архитектуру подробно) и учебник системного менеджмента (там про архитектуру предприятия). Одно дело, когда вы будете всех вокруг тыкать в литературу, где чётко выписаны все аргументы, "почему так", а другое дело, когда будете сочинять сами и подходы, и терминологию и изобретать кривоватый велосипед.
-- в наших учебниках вполне достаточно материалов, чтобы компактно обсуждать все эти архитектурные вопросы -- и про platform engineering, и про обратный манёвр Конвея, и про чем деятельность орг-архитектора отличается от деятельности орг-проектировщика, и где там governance в отличие от линейного управления. Эти учебники ровно для таких ситуаций написаны. Если учебники не читаны, то ничем помочь нельзя, кроме как послать их читать. Ибо вслух прочесть содержание этого учебника в ходе каких-то обсуждений -- это крайне нерациональная трата времени. И да, перед чтением этих учебников надо пройти курсы-пререквизиты. Иначе понимание не гарантируем. Ровно для таких целей помощи директорам по развитию мы и разрабатывали нашу учебную программу "Системная инженерия и менеджмент" (последовательность прохождения курсов вот тут: https://ailev.livejournal.com/1671965.html). Дальше там будет вторая часть про лидерство себя, коллектива, сообщества. А потом и третья часть по выходу на фронтир. Для этого и делается, чтобы не тратить время на изобретение кривых велосипедов, а сразу использовать SoTA.