Методолог -- то, что не вошло из старого в современного архитектора и осталось в разработчике
Разделение труда инженера-разработчика
Роль архитектора в ходе разделения труда потихоньку отплыла от понимания "опытный разработчик, который делает концепцию системы" и приплыла к ответственности за конструктивный/модульный синтез (нарезка на конструктивные части и определение интерфейсов для них, чтобы удерживать значения метрик для важных архитектурных характеристик в scaled agile проектах). Где-то с 2017 года это стало общепринятым, отражено у нас в курсе "Системная инженерия" (а отличия конструктивных и прочих рассмотрений системы, а также понятие важных характеристик для разных ролей -- в "Системном мышлении"). Примерно тем же оказались заняты и безопасники, как "альтернативные архитекторы": они защищают интерфейсы от хака (привет John Doyle) и тоже заинтересованы в минимизации распространения ошибок в одном модуле на другие. Их тесты идут в общий пакет испытаний, объединяясь с тестами разработчиков, а также fit functions архитекторов (при этом fit function -- это "историческое название" для архитектурных тестов/испытаний, кладущихся в основание архитектурных обоснований).
У разработчиков остались и концепция использования, и концепция системы. По сути, они должны вроде как делать функциональную декомпозицию (у машиностроителей это "разузловка", узел -- это ролевой/функциональный объект, времени эксплуатации), причём сначала вроде как надсистемы (для концепции использования -- надо предложить саму целевую систему как функциональный объект в функциональной декомпозиции надсистемы), а затем для системы (чтобы там где-то внизу делать "изобретения", находя аффордансы и укладываясь в крупную нарезку на конструктивы от "новых архитекторов").
В ходе разделения труда роль разработчиков разделяется (функциональная декомпозиция, чтобы потом разные роли специализировались на разных методах работы и мастерство накапливалось в разных агентах с их специфическими инструментами поддержки) на:
-- визионера (шумпетеровский предприниматель, часто исполняется должностью продакт-менеджера -- и не путать роль и должность),
-- затем архитектора (отслеживание "-остей" в ходе развития системы, чтобы не было их деградации и неожиданного "придётся переделывать всё с нуля" из-за невозможности отладки в силу переплетения зависимостей между конструктивами/модулями),
-- затем инженера внутренней платформы разработки (DevOps) -- это понятно.
Но у разработчиков осталось ещё очень много ролей. Если декомпозировать то, что у них осталось, на текущую онтику процесса разработки (предметы метода разработки), то составляющими метода будут:
-- функциональная декомпозиция
-- изобретение
-- изготовление (ибо в современном процессе они работают на заводе, а не в конструкторском бюро -- хотя сам завод, конечно, поддерживают инженеры внутренней платформы разработки, с которыми разработчики конфликтуют так же, как с архитекторами)
Интересно, что выделение роли инженера по требованиям (выхолощенного в корпоративном айти до "аналитика") было не очень удачной попыткой, требования не выжили. Напомним, почему: деонтика (а нужна была гипотеза), жуть со scaled AI, ибо надо было "собрать и утвердить полные требования" (аргумент по части разделения труда между командами -- собранный пакет требований как раз "лишние зависимости", переговоры по цвету корпуса и предельной скорости передвижения транспортного средства оказывались зависимыми друг от друга, а это нехорошо), а также "испорченный телефон" (один человек собирает требования из сценариев использования, а другой восстанавливает эти сценарии из требований), в итоге разработчик и сам общается с клиентами, собирая эти сценарии использования, и сам потом делает систему, удовлетворяющую этим сценариям использования, но главное -- это же делает и архитектор, он сам общается с клиентом и изучает надсистему.
Проблемы диаграммы функциональной декомпозиции и потом модульного синтеза
В итоге мы имеем что-то типа V-диаграммы функциональной декомпозиции и потом модульного синтеза, приведённой в курсе "Системного мышления" на основе IEC 81346-1 так:
Понятно, что это диаграмма для целей управления конфигурацией, поэтому не отражает метод работы разработчика, но она достаточно наглядна, чтобы отражать в целом происходящее. Моя критика этого представления:
-- очень мутно в части функциональной декомпозиции, там непонятно что происходит, но именно это традиционно обсуждалось как работа архитектора. "Разузловка", "орг-функциональное моделирование", P&ID, везде по разному -- но начинали с функциональных описаний, это и есть "системность". А архитектор вроде как был ведущей системноинженерной специальностью -- и вдруг он оказался ответственным только за конструктивную часть и интерфейсы! А что с функциями?
-- я бы вернул рассмотрение сэндвича как принятия архитектурных решений. Но там понятное противоречие: используется конструктивный язык (например, "интерфейсы", а не "порты") для фукнциональных ("методы работы"!) рассмотрений. Если просто заменить язык на функциональный, то там ровно та самая "функциональная декомпозиция"
-- в реальности "функциональная декомпозиция" часто выполняется с акцентом на методы работы (функции), а не просто на нужные для управления конфигурацией роли (как в диаграмме). Сценарии -- они не столько про роли, сколько про их поведение.
В ходе написания "Системного мышления" мы сделали следующее:
-- основным синонимом "практики" сделали "метод/способ работы"
-- перешли к создателям и ушли от антропоморфности, при этом ввели агентов (интеллектуальных, и не очень)
-- для не очень интеллектуальных агентов "метод работы" оказался "функцией"
-- поиск метода -- стратегирование, ищущий метод ("когда непонятно, что делать") -- стратег
И вот "стратегирование" для неживых систем -- это ж "поиск метода работы", функциональная архитектура (при этом были возражения против использования термина, ибо архитектура-по старому -- это про концепцию системы, функциональная архитектура -- это ж не "вся архитектура", то есть не архитектура). Отсюда несколько интересных выводов:
-- методами работы занимается методология. Тот, кто ищет функции/методы -- в общем случае системной инженерии он методолог (в менеджменте -- стратег, там все имена другие). Методологи занимаются методами/функциями и "предметами методов", в том числе входами и ожидаемыми выходами методов (все эти варианты input и income, output и outcome).
-- нахождение функций только выглядит как "декомпозиция функциональных объектов" (ход сверху вниз в системной иерархии). По факту же там композиция, мы должны предложить/породить/generate функцию нижнего уровня, чтобы появилась эмерджентность уровнем выше. А анализ? Ну анализ тоже нужен, когда есть что анализировать и дальше искать в наанализированном ошибки (критика из колёсика "догадка-формализация-критика-принятие всерьёз" из курса "Системного мышления", приводил картинку в https://ailev.livejournal.com/1706789.html). В любом случае, полноценное творчество, порождение (композиция, синтез) функциональной декомпозиции.
Дальше мы говорим о том, что акцент с "декомпозиции функциональных объектов (ролей)" переходит на "композицию функций (методов)" и разговор сразу становится конструктивным в смысле конструктивной математики:
-- ужас в том, что слово "конструктив" используется исторически для конструкции в физическом мире, а тут мы говорим про конструктивное описание систем, задавая методы их построения -- а методы как раз относятся к функциональным описаниям, а не конструктивным! Это засада, как преодолевать -- непонятно. В любом случае, от разбиений (объекты и отношения), мы переходим к операциям. Методы рассматриваются как крупные объекты (несмотря на то, что они -- поведение) их составляющие методы -- как более мелкие объекты, "конструктивная декомпозиция поведения". "Подметод" не используем, ибо тип отношения (часть-целая, классификация, специализация) будут путаться, а конструктивного захода тут вообще нет. Композиция для "составляющих" тут -- та самая "операция построения".
-- методы как паттерны/шаблоны/узоры/ритмы работы задаются их знаниями/объяснениями/алгоритмами (про алгоритмы и объяснения -- помним Curry-Howard). Но мы онтологически мыслим методы как паттерны работ, которые ведутся по методу, а работы -- реальное взаимодействие ресурсов. Будет жуткая путаница с описаниями и конструктивным подходом к описаниям. А тут наоборот -- как в конструктивной математике, морфизмы/преобразования/операции. Иногда с описаниями, иногда с физическими объектами -- и тут ход на математику теории категорий, идеи Kit Fine и много чего ещё, чтобы разобраться.
-- речь идёт не столько о методе работы системы как совокупного набора составляющих этого метода (общей функции системы как совокупности всех её функций), сколько о развитии метода работы системы в ходе проектирования и в ходе инженерного проекта. То есть мы идём на эволюционные описания -- и там на каждом шаге идут smart mutations. При этом в отличие от "точно цифрового генома" мемом метода чаще всего не формализован даже в виде псевдокода. Предметы метода имеют онтику, а вот знание метода отражено в регламентах, стандартах, а переходя на методы работы всякой нежити (разумной и не очень разумной) -- в пейперах/статьях, монографиях, раскидано по профессиональным чатам, а иногда и содержится в специально обученной нейронной не очень живой сетке.
-- Тем самым мы попадаем в задачу управления конфигурацией методов, которая транслируется в задачу управления конфигурацией методов в условиях эволюции идей: как понять, какой состав экосистемы "прямо сейчас", если каждый день появляются и исчезают множество видов? Учёт времени эволюции знания/объяснений/теорий/алгоритмов и управление конфигурацией знаний. То есть надо как-то уметь проводить мышление на методологическом фронтире (грубо говоря, не вплетать в рассуждение теорию флогистона, а заменять её термодинамикой — и так отслеживать фронтир по многим и многим дисциплинам/теориям). Ошибки конфигурации обычно очень дорогие, ибо каждая коллизия ведёт к переделкам больших кусков проектов, а обнаружение ошибки часто оттягивается до момента, когда при эксплуатации получается катастрофа.
-- управление конфигурацией означает, что надо иметь какие-то методы гранулирования/модуляризации (термин "модуляризация" тут хорош, ибо указывает на "автономность", но опять же -- это термин конструктивных описаний в смысле системного мышления, а не конструктивных описаний в смысле конструктивной математики!) знания. Причём все ремарки, что это знание должно быть объяснением, сохраняется. И там вопрос в том, что это за такая штука "объяснение" со всем аппаратом "измерений", "причинности" и т.д. Это и есть проблема: коснувшись эволюции знаний (о методах как процессах изменения предметов!), мы тут же из относительно простой онтологии попадаем в эпистемологию. И тут вплывает вся дискуссия по методологии науки, только теперь это и методология инженерии.
-- масштабироваться работа со знаниями не может в голове методолога, поэтому в помощь он получает компьютеры, методологическая работа должна быть автоматизирована. По факту это означает не только удержание текущей функциональной конфигурации системы (то, что я называл декомпозицией функций/методов), в том числе конфигурации методов работы предприятия как системы-создателя, но и удержание конфигурации того, что можно там использовать в качестве "функциональных аффордансов" (уфф, опять полезла конструктивная в смысле системного мышления терминология! Ещё чуть-чуть и надо будет переписывать это разделение каким-то другим языком, это будет жёсткая языковая коллизия между "математиками" и "инженерами" -- но если слишком много слов совпадает, то там может быть и общая закономерность, и надо просто переонтологизировать, а не переименовать: осознать наличие объектов с общими характеристиками и описать эту онтику. Может быть, надо как-то вернуться к старинному моему спору с Ian Dietz, https://ailev.livejournal.com/952625.html -- тот считал "функциональную декомпозицию" бессмысленной, примерно так же считают люди в SAFe, ибо там архитекторы бьют систему конструктивно, а методологов на верхних уровнях нет, есть только методологи-разработчики в узких domain, это обсуждали в докладе Кирилла Гайдамаки в https://ailev.livejournal.com/1718668.html, и ещё смотрим на собственно гамбургер-диаграмму Gielinh 1988 с путаницей функции и конструкции ).
-- методолог ведёт своё рассуждение (в отличие от аналитика) не для одного закона (функциональное описание мира, "методов работы мира"), одного набора функций системы, а в удержании общего рассуждения по всем открытым законам в их последней версии для предметной области (domain), для функционального проектирования (в менеджменте -- стратегирования). Для мета-мета-модели всё сохраняется, только речь идёт о полноценной (а не прикладной) эпистемологии, но если с этой эпистемологией идти в жизнь (например, при обучении мастерству людей или AI), то надо удерживать как-то "конфигурацию фронтира".
Управление конфигурацией методов для системы (функциональное разбиение при развитии системы) и для предметной области (SoTA методов работы)
Эти тезисы можно разворачивать и разворачивать, каждый из них. Так, если взять тезис о необходимости автоматизации методологической работы, то мы быстро приходим к тому, что текущая "модель методов" содержится в LLM и таких расширениях как LLM плюс инструменты поиска (доступ к Гуглу или даже RAG в разные базы текстовых знаний -- научных/фундаментальных и инженерных/прикладных). LLM же -- это статистика. Статистически чем старее рассуждение, тем большая вероятность, что примеров этого рассуждения много и оно будет встречаться чаще, bias всегда в пользу уже устаревших воззрений). Какие методы удержания конфигурации могут сработать, пока неведомо.
Поскольку это всё очень похоже на "методологию как прикладную эпистемологию", приведём пример из объяснений в науке. Вот нейронная сетка в LLM выучила 100500 раз, что Земля плоская. А потом лучшие умы пишут, что всё-таки круглая. Но есть ещё примерно столько же умов, которые говорят про Землю неопределённой формы и даже многомерную Землю. То, что иногда земля — это просто почва, я умалчиваю, тут не про разные значения слов. Тут про разные онтологии. Как закрепить при выводе/рассуждениях/inference, что надо брать методы работы с круглой землёй и не брать с плоской землёй? Кстати, про ту же силу — гравитация предполагала, что сил притяжения нет, но после Ньютона — силы притяжения между объектами с большой массой есть, а после Эйнштейна — сил притяжения опять нет, но зато есть искривление пространства, а идеи по квантовой гравитации опять меняют объяснение. Как заставить нейросетку придерживаться современной картины мира, сделать её школяром какой-то школы мысли? Она ж будет всегда выдавать винегрет изо всех теорий прошлого и будущего, на эту тему даже мемы были.
Douglas Lenat говорил, что "Граф Дракула — вампир, это все знают, но ещё все знают, что вампиров не существует — и нормально так люди с этим живут. Но логический движок тут сдыхает". Тут два аспекта:
-- гносеология против эпистемологии (в гносеологии могут быть религиозные методы познания мира, художественные методы познания мира, так что единороги и вампиры -- достойные объекты исследований, а в эпистемологии хорошо бы говорить о научном познании мира, поэтому оговаривать несуществование единорогов и вампиров)
-- чисто логический, речь идёт банально о наличии логического противоречия, потому как логика работает с онтиками, а онтики имеют огромные проблемы при объединении их непротиворечивых логик в общую онтологию (поэтому на верхних онтологических уровнях, прежде всего мета-мета-модели, да и уровне мета-модели какого-то domain мы и предлагаем меньшую формальность, выражение текстами).
И Lenat предложил в knowledge graph работать с микротеориями, и всё как-то пошло с рассуждениями в bounded context (ту же идею переизобрели люди из DDD). Микротеории и bounded contexts — это как раз "модульность в знаниях". В нейросетках распределённые представления, а модульность хорошо наводить в локальных представлениях, например в knowledge graphs или программных репозиториях в случаях DDD (напомним основную идею DDD: программа должна содержать те же объекты, которые мы находим в предметной области поддерживаемого метода работы, они должны вести себя так же. Тем самым код программы -- это в сущности онтологическое описание). Более того, коммуникацию надо тоже хорошо делать в локальных представлениях, и накопление знания (гены!) тоже предпочтительно делать в локальных/символьных (их часто называют "цифровыми") представлениях. Но с "хорошей модульностью" всё-таки проблемы, "народные онтики" являются результатом эволюции, а там бывают странные вещи.
Если не удерживать модульные представления в работе с методами (в работе со знаниями о методах, знаниях мастерства работы по методу -- можно говорить об этом чуть разными языками), то невозможно наладить разделение методологического труда. А это разделение труда важно. По большому счёту, современные архитекторы работают с архитектурами (нарезкой на конструктивы и заданием интерфейсов) целевых систем именно для того, чтобы в scaled agile можно было автономизировать работу команд-создателей подсистем-конструктивов. Каждая команда работает со своим bounded context подсистемы, вместе они как-то договариваются о выходе их функциональности для достижения эмерджентных свойств на более высоких системных уровнях, архитекторы контролируют то, что они не нарушают общей архитектуры (и тем самым могут длительное время удерживать авнономию в своей работе), визионеры контролируют, чтобы команды реализовывали нужные клиентам эмерджентные свойства, а не самые лёгкие для достижения -- чтобы финансирование не прекращалось. Так что методологическая работа оказывается распределена по командам, деятельность "методолога системы" разделяется по разным агентам, каждый агент специализируется на своей предметной области и должен удерживать SoTA знаний цивилизации в этой области. Один агент с одним мозгом банально не удержит "компьют" (не сможет выполнить всех потребных вычислений, не будет иметь всех необходимых знаний, станет узким местом).
Тут ещё один аспект: все эти описания методов многоуровневы -- и методолог должен каждый раз удерживать SoTA методов работы надсистемы, целевой системы и подсистем. Методолог должен работать на фронтире, а удержание фронтира в голове в момент работы -- это и есть "управление конфигурацией" методов. То есть у нас две конфигурации:
-- конфигурация методов, задействованных в системе (функциональное описание системы, причём нет "версии описания", а как в "информации о телефоне": даны множество дат выпуска для разных частей операционки, разной аппаратуры. Тут то же самое, но для составляющих общего метода, на много уровней вниз и желательно много уровней вверх, в надсистему). Тут надо учитывать, что конфигурацию меняют автономно во многих местах, и надо учить её как-то учитывать, чтобы бороться с конфигурационными коллизиями.
-- конфигурация фронтира, SoTA методов работы в прикладной системной области. Скажем, надо хорошо понимать, какие сейчас (то есть "что у нас сейчас фронтир", SoTA, в методах это "лучшие методы" или даже "хорошие методы", в традиционной/старинной архитектуре -- "типовые архитектурные решения") методы программирования (это ж давно уже не императивное программирование времён Фортрана), какие методы создания больших языковых моделей, методы разработки проходческой техники для строительства туннелей, какие методы оргразвития. Прикладных методологов надо учить фронтиру. Дойч особо обговаривал, что метод изучения физики как "истории физики" и "отсылки к идеям отдельных людей" не работает, учить надо сразу фронтиру (давая в том числе аргументы против скатывания к уже фальсифицированным когда-то идеям). Для этого надо уметь описывать/моделировать текущее состояние метода мышления "на фронтире". Но дальше надо учитывать, что фронтир плывёт во времени, и учить переучиваться: управлять конфигурацией своих знаний о методах.
Люди не очень справляются с этими двумя проблемами:
-- удержание многоуровневого стека методов, хорошо бы специализироваться на методах хотя бы трёх системных уровней, а больше предметных областей не удержать. Полиматы очень, очень редки. Широта знаний требует запредельного числа вычислений. В нейросетках, например, вводят подход MoE (mix of experts, то есть командную работу сеток-специалистов), а у людей -- командную работу людей-специалистов.
-- невозможность удерживать SoTA, поэтому "наука развивается с каждыми похоронами учёного" (и, похоже, инженерия -- с похоронами каждого инженера). Новых учёных просто не учат подробно старым теориям, и им поэтому счастье. Но новые нейросетки и даже knowledge graphs при них будут учить всем теориям — и это проблема, "управление конфигурацией знаний агентечества". Инженеры тоже не справляются, поэтому крупные компании помирают, ибо не могут быстро переучить своих инженеров с одних методов как SoTA на другие (мы в ШСМ решаем ровно эту задачу -- как сделать так, чтобы люди таки быстро переучивались. Для начала просто знали, что они работают не как-нибудь, а по каким-то методам -- чтобы осознали свой метод и осознали, как устроена эволюция методов, почему им всё время надо переучиваться).
Какие тут архитектуры (стеки архитектур, с учётом предыдущего пункта, причём заведомо распределённые, "рыночные") устройства методологической работы могут сработать — неведомо. Архитекторов для конструктивов выделили отдельно, а вот методологов растворили в "разработчиках" вместе с, например, кодировщиками в программной инженерии и CAD designers в машиностроении. Так что "незримая половинка старого архитектора" по-прежнему -- "старший опытный разработчик", только уже вроде как не архитектор, ибо значение термина поменялось.
Заземление: пример с методологом интеллектуальных систем
Давайте теперь сделаем заземление на конкретный пример методологической работы прикладного методолога. Возьмём сложный случай, методолога искусственных нейронных сетей, ANN (и там ещё можно давать разные имена для этой прикладной методологии -- "интеллектуальных систем", "систем обработки информации в распределённых представлениях" и т.д.). В качестве конкретного агента, выполняющего роль такого методолога рассмотрим Григория Сапунова, ведущего канал "Gonzo-обзоры ML статей" (https://t.me/gonzo_ML, примерно 16 тысяч подписчиков). Я считаю Григория гениальным описателем разных функциональных архитектур, который как-то научился видеть "модульность в алгоритмах". Повторим: модульность при этом -- слово из языка конструктивов/аффордансов, а алгоритм — это же теория/объяснение/знание, только изложенное не в логической, а в конструктивистской манере, но мы не будем тут слишком строгими. Григорий тем самым гениальный "архитектор ANN" в старом смысле слова, но вот беда -- он, похоже, в своём канале не описывает концепции создания систем с ANN и не описывает нарезку систем с ANN на конструктивы с описанием того, как это влияет на "-ости" (надёжности, доступности и т.д.). Но Григорий как-то освоил методологическое мышление по линии функционального синтеза нейросетевых алгоритмов. Далее он в ходе нескольких лет описания этих алгоритмов грокнул идею эволюционного развития функциональных композиций (эволюцию методов/функций через smart mutations) и пишет обзоры на этом "языке эволюции функциональных архитектур" (собственно, это и есть его вклад: авторы пишут статику, а автор обзоров описывает мутации и их rationale, обоснования — это ж не просто "идеи, как изменить архитектуру ANN, чтобы они стали получше", а smart mutations, термин из https://arxiv.org/abs/2206.08896, Evolution through Large Models).
Так что Григорий -- хороший пример инженера-методолога, в данном случае методолога методов обучения представлениям (всё-таки у него чат не про ML в целом и не про именно ANN, а чуток пошире -- про алгоритмику методов работы с распределёнными представлениями, distributed representations). Увы, понимания на уровне мета-мета-модели, что же именно делают методологи (как раньше -- понимания, что же именно делают "архитекторы старой школы", там были главным образом "записки архитекторов") нет, так что Григорий и сам не очень . Курс "методология" я только-только начал переписывать, а онтику метода только-только прописал в "Системном мышлении" (вот тут синопсис — https://ailev.livejournal.com/1722262.html, а раскрываются понятия на многих страницах текста "Системного мышления").
Вот типичный пример рассуждений Григория (берём из относительно свеженького поста от 10 мая 2024, https://t.me/gonzo_ML/2625):
Понятно, что это диаграмма для целей управления конфигурацией, поэтому не отражает метод работы разработчика, но она достаточно наглядна, чтобы отражать в целом происходящее. Моя критика этого представления:
-- очень мутно в части функциональной декомпозиции, там непонятно что происходит, но именно это традиционно обсуждалось как работа архитектора. "Разузловка", "орг-функциональное моделирование", P&ID, везде по разному -- но начинали с функциональных описаний, это и есть "системность". А архитектор вроде как был ведущей системноинженерной специальностью -- и вдруг он оказался ответственным только за конструктивную часть и интерфейсы! А что с функциями?
-- я бы вернул рассмотрение сэндвича как принятия архитектурных решений. Но там понятное противоречие: используется конструктивный язык (например, "интерфейсы", а не "порты") для фукнциональных ("методы работы"!) рассмотрений. Если просто заменить язык на функциональный, то там ровно та самая "функциональная декомпозиция"
-- в реальности "функциональная декомпозиция" часто выполняется с акцентом на методы работы (функции), а не просто на нужные для управления конфигурацией роли (как в диаграмме). Сценарии -- они не столько про роли, сколько про их поведение.
В ходе написания "Системного мышления" мы сделали следующее:
-- основным синонимом "практики" сделали "метод/способ работы"
-- перешли к создателям и ушли от антропоморфности, при этом ввели агентов (интеллектуальных, и не очень)
-- для не очень интеллектуальных агентов "метод работы" оказался "функцией"
-- поиск метода -- стратегирование, ищущий метод ("когда непонятно, что делать") -- стратег
И вот "стратегирование" для неживых систем -- это ж "поиск метода работы", функциональная архитектура (при этом были возражения против использования термина, ибо архитектура-по старому -- это про концепцию системы, функциональная архитектура -- это ж не "вся архитектура", то есть не архитектура). Отсюда несколько интересных выводов:
-- методами работы занимается методология. Тот, кто ищет функции/методы -- в общем случае системной инженерии он методолог (в менеджменте -- стратег, там все имена другие). Методологи занимаются методами/функциями и "предметами методов", в том числе входами и ожидаемыми выходами методов (все эти варианты input и income, output и outcome).
-- нахождение функций только выглядит как "декомпозиция функциональных объектов" (ход сверху вниз в системной иерархии). По факту же там композиция, мы должны предложить/породить/generate функцию нижнего уровня, чтобы появилась эмерджентность уровнем выше. А анализ? Ну анализ тоже нужен, когда есть что анализировать и дальше искать в наанализированном ошибки (критика из колёсика "догадка-формализация-критика-принятие всерьёз" из курса "Системного мышления", приводил картинку в https://ailev.livejournal.com/1706789.html). В любом случае, полноценное творчество, порождение (композиция, синтез) функциональной декомпозиции.
Дальше мы говорим о том, что акцент с "декомпозиции функциональных объектов (ролей)" переходит на "композицию функций (методов)" и разговор сразу становится конструктивным в смысле конструктивной математики:
-- ужас в том, что слово "конструктив" используется исторически для конструкции в физическом мире, а тут мы говорим про конструктивное описание систем, задавая методы их построения -- а методы как раз относятся к функциональным описаниям, а не конструктивным! Это засада, как преодолевать -- непонятно. В любом случае, от разбиений (объекты и отношения), мы переходим к операциям. Методы рассматриваются как крупные объекты (несмотря на то, что они -- поведение) их составляющие методы -- как более мелкие объекты, "конструктивная декомпозиция поведения". "Подметод" не используем, ибо тип отношения (часть-целая, классификация, специализация) будут путаться, а конструктивного захода тут вообще нет. Композиция для "составляющих" тут -- та самая "операция построения".
-- методы как паттерны/шаблоны/узоры/ритмы работы задаются их знаниями/объяснениями/алгоритмами (про алгоритмы и объяснения -- помним Curry-Howard). Но мы онтологически мыслим методы как паттерны работ, которые ведутся по методу, а работы -- реальное взаимодействие ресурсов. Будет жуткая путаница с описаниями и конструктивным подходом к описаниям. А тут наоборот -- как в конструктивной математике, морфизмы/преобразования/операции. Иногда с описаниями, иногда с физическими объектами -- и тут ход на математику теории категорий, идеи Kit Fine и много чего ещё, чтобы разобраться.
-- речь идёт не столько о методе работы системы как совокупного набора составляющих этого метода (общей функции системы как совокупности всех её функций), сколько о развитии метода работы системы в ходе проектирования и в ходе инженерного проекта. То есть мы идём на эволюционные описания -- и там на каждом шаге идут smart mutations. При этом в отличие от "точно цифрового генома" мемом метода чаще всего не формализован даже в виде псевдокода. Предметы метода имеют онтику, а вот знание метода отражено в регламентах, стандартах, а переходя на методы работы всякой нежити (разумной и не очень разумной) -- в пейперах/статьях, монографиях, раскидано по профессиональным чатам, а иногда и содержится в специально обученной нейронной не очень живой сетке.
-- Тем самым мы попадаем в задачу управления конфигурацией методов, которая транслируется в задачу управления конфигурацией методов в условиях эволюции идей: как понять, какой состав экосистемы "прямо сейчас", если каждый день появляются и исчезают множество видов? Учёт времени эволюции знания/объяснений/теорий/алгоритмов и управление конфигурацией знаний. То есть надо как-то уметь проводить мышление на методологическом фронтире (грубо говоря, не вплетать в рассуждение теорию флогистона, а заменять её термодинамикой — и так отслеживать фронтир по многим и многим дисциплинам/теориям). Ошибки конфигурации обычно очень дорогие, ибо каждая коллизия ведёт к переделкам больших кусков проектов, а обнаружение ошибки часто оттягивается до момента, когда при эксплуатации получается катастрофа.
-- управление конфигурацией означает, что надо иметь какие-то методы гранулирования/модуляризации (термин "модуляризация" тут хорош, ибо указывает на "автономность", но опять же -- это термин конструктивных описаний в смысле системного мышления, а не конструктивных описаний в смысле конструктивной математики!) знания. Причём все ремарки, что это знание должно быть объяснением, сохраняется. И там вопрос в том, что это за такая штука "объяснение" со всем аппаратом "измерений", "причинности" и т.д. Это и есть проблема: коснувшись эволюции знаний (о методах как процессах изменения предметов!), мы тут же из относительно простой онтологии попадаем в эпистемологию. И тут вплывает вся дискуссия по методологии науки, только теперь это и методология инженерии.
-- масштабироваться работа со знаниями не может в голове методолога, поэтому в помощь он получает компьютеры, методологическая работа должна быть автоматизирована. По факту это означает не только удержание текущей функциональной конфигурации системы (то, что я называл декомпозицией функций/методов), в том числе конфигурации методов работы предприятия как системы-создателя, но и удержание конфигурации того, что можно там использовать в качестве "функциональных аффордансов" (уфф, опять полезла конструктивная в смысле системного мышления терминология! Ещё чуть-чуть и надо будет переписывать это разделение каким-то другим языком, это будет жёсткая языковая коллизия между "математиками" и "инженерами" -- но если слишком много слов совпадает, то там может быть и общая закономерность, и надо просто переонтологизировать, а не переименовать: осознать наличие объектов с общими характеристиками и описать эту онтику. Может быть, надо как-то вернуться к старинному моему спору с Ian Dietz, https://ailev.livejournal.com/952625.html -- тот считал "функциональную декомпозицию" бессмысленной, примерно так же считают люди в SAFe, ибо там архитекторы бьют систему конструктивно, а методологов на верхних уровнях нет, есть только методологи-разработчики в узких domain, это обсуждали в докладе Кирилла Гайдамаки в https://ailev.livejournal.com/1718668.html, и ещё смотрим на собственно гамбургер-диаграмму Gielinh 1988 с путаницей функции и конструкции ).
-- методолог ведёт своё рассуждение (в отличие от аналитика) не для одного закона (функциональное описание мира, "методов работы мира"), одного набора функций системы, а в удержании общего рассуждения по всем открытым законам в их последней версии для предметной области (domain), для функционального проектирования (в менеджменте -- стратегирования). Для мета-мета-модели всё сохраняется, только речь идёт о полноценной (а не прикладной) эпистемологии, но если с этой эпистемологией идти в жизнь (например, при обучении мастерству людей или AI), то надо удерживать как-то "конфигурацию фронтира".
Управление конфигурацией методов для системы (функциональное разбиение при развитии системы) и для предметной области (SoTA методов работы)
Эти тезисы можно разворачивать и разворачивать, каждый из них. Так, если взять тезис о необходимости автоматизации методологической работы, то мы быстро приходим к тому, что текущая "модель методов" содержится в LLM и таких расширениях как LLM плюс инструменты поиска (доступ к Гуглу или даже RAG в разные базы текстовых знаний -- научных/фундаментальных и инженерных/прикладных). LLM же -- это статистика. Статистически чем старее рассуждение, тем большая вероятность, что примеров этого рассуждения много и оно будет встречаться чаще, bias всегда в пользу уже устаревших воззрений). Какие методы удержания конфигурации могут сработать, пока неведомо.
Поскольку это всё очень похоже на "методологию как прикладную эпистемологию", приведём пример из объяснений в науке. Вот нейронная сетка в LLM выучила 100500 раз, что Земля плоская. А потом лучшие умы пишут, что всё-таки круглая. Но есть ещё примерно столько же умов, которые говорят про Землю неопределённой формы и даже многомерную Землю. То, что иногда земля — это просто почва, я умалчиваю, тут не про разные значения слов. Тут про разные онтологии. Как закрепить при выводе/рассуждениях/inference, что надо брать методы работы с круглой землёй и не брать с плоской землёй? Кстати, про ту же силу — гравитация предполагала, что сил притяжения нет, но после Ньютона — силы притяжения между объектами с большой массой есть, а после Эйнштейна — сил притяжения опять нет, но зато есть искривление пространства, а идеи по квантовой гравитации опять меняют объяснение. Как заставить нейросетку придерживаться современной картины мира, сделать её школяром какой-то школы мысли? Она ж будет всегда выдавать винегрет изо всех теорий прошлого и будущего, на эту тему даже мемы были.
Douglas Lenat говорил, что "Граф Дракула — вампир, это все знают, но ещё все знают, что вампиров не существует — и нормально так люди с этим живут. Но логический движок тут сдыхает". Тут два аспекта:
-- гносеология против эпистемологии (в гносеологии могут быть религиозные методы познания мира, художественные методы познания мира, так что единороги и вампиры -- достойные объекты исследований, а в эпистемологии хорошо бы говорить о научном познании мира, поэтому оговаривать несуществование единорогов и вампиров)
-- чисто логический, речь идёт банально о наличии логического противоречия, потому как логика работает с онтиками, а онтики имеют огромные проблемы при объединении их непротиворечивых логик в общую онтологию (поэтому на верхних онтологических уровнях, прежде всего мета-мета-модели, да и уровне мета-модели какого-то domain мы и предлагаем меньшую формальность, выражение текстами).
И Lenat предложил в knowledge graph работать с микротеориями, и всё как-то пошло с рассуждениями в bounded context (ту же идею переизобрели люди из DDD). Микротеории и bounded contexts — это как раз "модульность в знаниях". В нейросетках распределённые представления, а модульность хорошо наводить в локальных представлениях, например в knowledge graphs или программных репозиториях в случаях DDD (напомним основную идею DDD: программа должна содержать те же объекты, которые мы находим в предметной области поддерживаемого метода работы, они должны вести себя так же. Тем самым код программы -- это в сущности онтологическое описание). Более того, коммуникацию надо тоже хорошо делать в локальных представлениях, и накопление знания (гены!) тоже предпочтительно делать в локальных/символьных (их часто называют "цифровыми") представлениях. Но с "хорошей модульностью" всё-таки проблемы, "народные онтики" являются результатом эволюции, а там бывают странные вещи.
Если не удерживать модульные представления в работе с методами (в работе со знаниями о методах, знаниях мастерства работы по методу -- можно говорить об этом чуть разными языками), то невозможно наладить разделение методологического труда. А это разделение труда важно. По большому счёту, современные архитекторы работают с архитектурами (нарезкой на конструктивы и заданием интерфейсов) целевых систем именно для того, чтобы в scaled agile можно было автономизировать работу команд-создателей подсистем-конструктивов. Каждая команда работает со своим bounded context подсистемы, вместе они как-то договариваются о выходе их функциональности для достижения эмерджентных свойств на более высоких системных уровнях, архитекторы контролируют то, что они не нарушают общей архитектуры (и тем самым могут длительное время удерживать авнономию в своей работе), визионеры контролируют, чтобы команды реализовывали нужные клиентам эмерджентные свойства, а не самые лёгкие для достижения -- чтобы финансирование не прекращалось. Так что методологическая работа оказывается распределена по командам, деятельность "методолога системы" разделяется по разным агентам, каждый агент специализируется на своей предметной области и должен удерживать SoTA знаний цивилизации в этой области. Один агент с одним мозгом банально не удержит "компьют" (не сможет выполнить всех потребных вычислений, не будет иметь всех необходимых знаний, станет узким местом).
Тут ещё один аспект: все эти описания методов многоуровневы -- и методолог должен каждый раз удерживать SoTA методов работы надсистемы, целевой системы и подсистем. Методолог должен работать на фронтире, а удержание фронтира в голове в момент работы -- это и есть "управление конфигурацией" методов. То есть у нас две конфигурации:
-- конфигурация методов, задействованных в системе (функциональное описание системы, причём нет "версии описания", а как в "информации о телефоне": даны множество дат выпуска для разных частей операционки, разной аппаратуры. Тут то же самое, но для составляющих общего метода, на много уровней вниз и желательно много уровней вверх, в надсистему). Тут надо учитывать, что конфигурацию меняют автономно во многих местах, и надо учить её как-то учитывать, чтобы бороться с конфигурационными коллизиями.
-- конфигурация фронтира, SoTA методов работы в прикладной системной области. Скажем, надо хорошо понимать, какие сейчас (то есть "что у нас сейчас фронтир", SoTA, в методах это "лучшие методы" или даже "хорошие методы", в традиционной/старинной архитектуре -- "типовые архитектурные решения") методы программирования (это ж давно уже не императивное программирование времён Фортрана), какие методы создания больших языковых моделей, методы разработки проходческой техники для строительства туннелей, какие методы оргразвития. Прикладных методологов надо учить фронтиру. Дойч особо обговаривал, что метод изучения физики как "истории физики" и "отсылки к идеям отдельных людей" не работает, учить надо сразу фронтиру (давая в том числе аргументы против скатывания к уже фальсифицированным когда-то идеям). Для этого надо уметь описывать/моделировать текущее состояние метода мышления "на фронтире". Но дальше надо учитывать, что фронтир плывёт во времени, и учить переучиваться: управлять конфигурацией своих знаний о методах.
Люди не очень справляются с этими двумя проблемами:
-- удержание многоуровневого стека методов, хорошо бы специализироваться на методах хотя бы трёх системных уровней, а больше предметных областей не удержать. Полиматы очень, очень редки. Широта знаний требует запредельного числа вычислений. В нейросетках, например, вводят подход MoE (mix of experts, то есть командную работу сеток-специалистов), а у людей -- командную работу людей-специалистов.
-- невозможность удерживать SoTA, поэтому "наука развивается с каждыми похоронами учёного" (и, похоже, инженерия -- с похоронами каждого инженера). Новых учёных просто не учат подробно старым теориям, и им поэтому счастье. Но новые нейросетки и даже knowledge graphs при них будут учить всем теориям — и это проблема, "управление конфигурацией знаний агентечества". Инженеры тоже не справляются, поэтому крупные компании помирают, ибо не могут быстро переучить своих инженеров с одних методов как SoTA на другие (мы в ШСМ решаем ровно эту задачу -- как сделать так, чтобы люди таки быстро переучивались. Для начала просто знали, что они работают не как-нибудь, а по каким-то методам -- чтобы осознали свой метод и осознали, как устроена эволюция методов, почему им всё время надо переучиваться).
Какие тут архитектуры (стеки архитектур, с учётом предыдущего пункта, причём заведомо распределённые, "рыночные") устройства методологической работы могут сработать — неведомо. Архитекторов для конструктивов выделили отдельно, а вот методологов растворили в "разработчиках" вместе с, например, кодировщиками в программной инженерии и CAD designers в машиностроении. Так что "незримая половинка старого архитектора" по-прежнему -- "старший опытный разработчик", только уже вроде как не архитектор, ибо значение термина поменялось.
Заземление: пример с методологом интеллектуальных систем
Давайте теперь сделаем заземление на конкретный пример методологической работы прикладного методолога. Возьмём сложный случай, методолога искусственных нейронных сетей, ANN (и там ещё можно давать разные имена для этой прикладной методологии -- "интеллектуальных систем", "систем обработки информации в распределённых представлениях" и т.д.). В качестве конкретного агента, выполняющего роль такого методолога рассмотрим Григория Сапунова, ведущего канал "Gonzo-обзоры ML статей" (https://t.me/gonzo_ML, примерно 16 тысяч подписчиков). Я считаю Григория гениальным описателем разных функциональных архитектур, который как-то научился видеть "модульность в алгоритмах". Повторим: модульность при этом -- слово из языка конструктивов/аффордансов, а алгоритм — это же теория/объяснение/знание, только изложенное не в логической, а в конструктивистской манере, но мы не будем тут слишком строгими. Григорий тем самым гениальный "архитектор ANN" в старом смысле слова, но вот беда -- он, похоже, в своём канале не описывает концепции создания систем с ANN и не описывает нарезку систем с ANN на конструктивы с описанием того, как это влияет на "-ости" (надёжности, доступности и т.д.). Но Григорий как-то освоил методологическое мышление по линии функционального синтеза нейросетевых алгоритмов. Далее он в ходе нескольких лет описания этих алгоритмов грокнул идею эволюционного развития функциональных композиций (эволюцию методов/функций через smart mutations) и пишет обзоры на этом "языке эволюции функциональных архитектур" (собственно, это и есть его вклад: авторы пишут статику, а автор обзоров описывает мутации и их rationale, обоснования — это ж не просто "идеи, как изменить архитектуру ANN, чтобы они стали получше", а smart mutations, термин из https://arxiv.org/abs/2206.08896, Evolution through Large Models).
Так что Григорий -- хороший пример инженера-методолога, в данном случае методолога методов обучения представлениям (всё-таки у него чат не про ML в целом и не про именно ANN, а чуток пошире -- про алгоритмику методов работы с распределёнными представлениями, distributed representations). Увы, понимания на уровне мета-мета-модели, что же именно делают методологи (как раньше -- понимания, что же именно делают "архитекторы старой школы", там были главным образом "записки архитекторов") нет, так что Григорий и сам не очень . Курс "методология" я только-только начал переписывать, а онтику метода только-только прописал в "Системном мышлении" (вот тут синопсис — https://ailev.livejournal.com/1722262.html, а раскрываются понятия на многих страницах текста "Системного мышления").
Вот типичный пример рассуждений Григория (берём из относительно свеженького поста от 10 мая 2024, https://t.me/gonzo_ML/2625): Если полученные новые варианты [mLSTM и sLSTM для LSTM] вставить в residual blocks (с pre-LayerNorm), то получаются xLSTM блоки, которые можно стыковать. Есть два варианта xLSTM блока: с post up-projection и pre up-projection. Первый (post, как в трансформерах) делает нелинейную суммаризацию прошлого в своём оригинальном пространстве, затем линейно преобразует его в пространство более высокой размерности, применяет там нелинейную функцию активации и переводит обратно в пространство поменьше. Второй (pre, как в SSM) сначала переводит в пространство размерности побольше, там делает суммаризацию, и переводит обратно. См. картинки. Для первого обычно используется sLSTM, для второго mLSTM (в высокоразмерном пространстве матричная память лучше работает).В этом описании чётко видны методологические операции проведения smart mutations в алгоритмах -- "если один функциональный блок вставить::композиция в другой блок", или вот цепочка методов как выполнение алгоритма над какими-то предметами метода: "делает нелинейную суммаризацию прошлого в своём оригинальном пространстве, затем линейно преобразует его в пространство более высокой размерности, применяет там нелинейную функцию активации и переводит обратно в пространство поменьше". Дальше Григорий с необходимостью (системные уровни же!) от функциональных архитектур блоков нейросетей и функциональных архитектур нейросетей перешёл к обсуждению архитектур LLM, дальше мы уже знаем из биологии про законы роста сложности в эволюции (к эволюции методов они ведь вполне применимы): LLM оказались состоящими из нескольких ANN (MoE), далее появились идеи, как интеллектуальный агент может быть program of thoughts -- классическим алгоритмом, который вызывает по мере необходимости LLM для обработки локально сформулированных "мыслей" в распределённом представлении, то есть последовательностей токенов в нейросетях. Так что интерес методолога теперь к функциональным архитектурам надсистем для LLM, обсуждаются идеи по эволюции таких фреймворков PoT (это уже понятно, как обсуждать, те же функциональные архитектуры). Ещё системный уровень вверх — и надо обсуждать функциональную архитектуру того, как общаются люди с их ограниченным компьютом и нежить с PoT и диким количеством компьюта, тот же вопрос вопрос функционального синтеза: каких эмерджентностей можно ожидать от того, что мы забацаем такую-то архитектуру "программ мысли над лучшими LLM" и в архитектуре общения агентов-нежити и кожаных мешков вдруг возникнет эмерджентность, "новые свойства". Например, мышление много школ мысли считают существующими не в людях, а в сетях людей (СМД-методологи любят говорить "промеж людей", а "люди — это случайные носители мышления"), поэтому вопрос "что там в сетях агентов разной природы и какая там эволюция этих сетей" — для методологов (по-старому — архитекторов) нижних уровней агентов (нейросетевых алгоритмов) важен. Поэтому и интерес к возможным проблемам безопасности сеток, alignment. Мы обсуждали, что "безопасники" — это, неожиданно, исполнители ролей архитектора, они тоже главным образом про интерфейсы и имунные защиты прошибания этих интерфейсов, но там должны быть и безопасники-методологи, которые про эмерджентные дырки в защите (защита от того, чего не знаю ещё — ибо собранная система работает не так, как работают её отдельные части). Что и как делать дальше Вопросы сложные, ибо обсуждаем сразу две методологии, два стека методов: — обсуждаем многоуровневые методологические/функциональные (а не платформенные) стеки интеллектуальных агентов в их техно-эволюции (Gonzo-обзоры как раз об этом) — обсуждаем сам метод обсуждения, что же такое делает автор обзоров Григорий Сапунов в своём мышлении как "методолога по методам работы с распределёнными представлениями". Мопед тут мой: хорошо бы отмоделировать его методологическое мышление и сделать курс, чтобы научить так думать про стек алгоритмов мышления других агентов (живых и не очень живых). Может быть, такой курс подготовит не сам @che_shr_cat (Григорий Сапунов в телеграм), а обученный им интеллектуальный агент — снимет "метод мышления" из текстов gonzo-обзоров. Как это делать? Ну вот так: — определяется инженерная роль "методолог алгоритмики интеллектуальных агентов" — определяется метод работы (в данном случае — метод мышления) этой роли. Методологическая работа методолога для инженерных проектов создания и развития агентов, работающих с распределёнными представлениями (ограничимся пока этим, но там и локальные представления будут). — далее смотрим на типы мета-мета-модели (функциональные против конструктивных описаний, метод и предмет метода, всякое такое — это предмет моих курсов) и ищем объекты в типах мета-модели предметной области (многоуровневые развивающиеся архитектуры агентов-на-распределённых-представлениях). Строим онтику предметной области. — проблема в том, что онтика предметной области быстро меняется, поэтому возвращаемся регулярно к предыдущим пунктам. Один человек узкую предметную область скейлит при таком подходе, а если брать чуть пошире — уже нет. Поэтому учим этим шагам какого-нибудь AI-агента. Но пока первый шаг для меня самого -- срочно переписывать "Методологию", а затем и "Системную инженерию". Тут для меня главное -- это всё-таки не слишком уходить от текущего мейнстрима во фронтирные рассмотрения, но как культуртрегер я обязан делать entrepreneurial bet, "предпринимательскую ставку" шумпетерского предпринимателя -- определять, чему именно надо учить студентов и AI в части фронтира методов разработки, в данном случае разработки функциональных архитектур. Но уже понятно, что фронтир работ по функциональным архитектурам сейчас -- это функциональные архитектуры систем обработки информации в распределённых представлениях. Так что я как методолог поработаю если не с самим Григорием, то с его текстами обзоров -- надо бы понять, какая у него онтика функциональных архитектур интеллектуальных систем, все эти "вставить блок" и "выполнить действия". Ну, и надо решить множество проблем, описанных тут в тексте. Ремарка тут ещё и в том, что я сам, конечно, тоже методолог. Только меня интересует больше не прикладная методология какой-то предметной области, а фундаментальная -- методы работы с собственно методами работы, то есть методы фундаментального мышления, методы интеллект-стека. UPDATE: дискуссия в https://www.facebook.com/ailevenchuk/posts/pfbid02BQdodFoaa54xVaDvXxHmEw6LaJ3axcDC1jN2g96vjuka8gTNwmhkkkpRZ5d6giy7l