Утро потратил на беседы с командой нежити по поводу унификации архитектурного мышления: по подобию системной архитектуры (как в нашем руководстве по системной инженерии) сделать эпистемическую/знаниевую архитектуру, а затем обобщить в “просто архитектуру”. Загрузил в каждую нежить текущие файлы спецификации FPF (First Principles Framework, текущая версия в FPF specification (full).md — Яндекс Диск), где про системный подход и эпистемологию подробненько (хотя там ещё черновик-черновик, много надо чистить) и руководства по системной инженерии (текущая версия в Системная_инженерия_guide_2025_22apr25.pdf — Яндекс Диск), где про архитектуру подробненько. Это, конечно, в воздухе висит: даже в ISO 42010:2022 от system of interest переходят к entity of interest, во многих школах системного мышления нет ограничений на физичность систем, то есть “можете думать об эпистемах как о системах”. Или идея “всё на свете может быть выражено прямоугольничками и стрелочками”, которые затем легко мыслить как “чёрные ящики” (Boxology - Wikipedia), после чего разворачивать “знаниевый инженерный процесс” по мотивам классического системноинженерного процесса, вроде идей в “Standardizing Knowledge Engineering Practices with a Reference Architecture”, [2404.03624] Standardizing Knowledge Engineering Practices with a Reference Architecture с попыткой разобраться в NeSy (NeuroSymbolic) knowledge engineering that combine machine learning and semantic web components. Ну, и людей сюда тоже можно добавить. Понятно, что подобного сорта работ довольно много, а ещё такие работы быстро автоматизируются – люди там нужны главным образом для пригляда.
Все эти “в воздухе висящие обобщения” написаны вилами по воде, они не дают мыслить строго, там сплошные метафоры, поэтому “иногда работает, иногда нет”, надёжность всех этих эпистем невысокая. В First Principles Framework можно пробовать проговорить это всё формально и обобщить аккуратно, подняв тем самым формальность с шансом поднять общую надёжность. Кроме этого, реализуем цель получить минимальный набор понятий для эффективного и результативного мышления о максимальном разнообразии объектов.
Хотя речь идёт о всём инженерном процессе, начинаем говорить аккуратно, с ведущей инженерной мыслительной дисциплины: architecturing (как по русски – не спрашивайте). Дальше сделать апдейт всех наших руководств, дальше наблюдать архитектурное мышление ещё и для эпистем, сплошная польза. Дальше всё-таки перейти к полноценному обобщению для инженерии в целом.
Задавал трём нежитям один один и тот же набор вопросов, друг другу их ответы для критики не показывал (что не слишком характерно, для подобных моих разговоров, но это был такой эксперимент). Общий вывод нежитей: теоретическое основание для “общей архитектуры для систем и эпистем” уже вроде как достаточное, системную инженерию и инженерию знаний тем самым можно обобщать в “просто инженерию”, доработки минимальны. Но мне было тыкнуто в текущие недоработки по универсальности FPF в его текущей версии, что мне и надо было – это устраню в ближайших версиях.
Для любопытствующих вот результаты:
– Groq-4 – https://grok.com/share/c2hhcmQtMw%3D%3D_359b6082-77e8-4f59-8230-20b38479ba4a,
– Gemini 2.5 Pro – https://aistudio.google.com/app/prompts?state={“ids”:[“1k59JgmUnttD3FxF7fuNLsS0Fs7iV9RiU”],“action”:“open”,“userId”:“115325060035114944424”,“resourceKeys”:{}}&usp=sharing,
– o3 Pro – https://chatgpt.com/share/6874deae-e3e0-8013-8c1d-3de60c7a82c5.
Конечно, разобраться можно, только если уже как-то разобрался и с устройством FPF, и системной инженерией в части архитектуры и тамошнего разделения инженерных ролей. Проверьте себя: знаете ли вы, что такое архитектура, в том числе различаете ли evolutionary architecture, functional architecture, из системной инженерии, а ещё из FPF – что-такое U-Type, ядро FPF, модуль-фреймворк, модуль-фасет? Понимаете ли, в чём там суть оператора агрегации и причём тут мета-системный переход и какие ваши собственные мысли про мета-эпистемический переход, как вы его понимаете?
А ещё ввиду телеграфного стиля разговора надо обычно подробно расспрашивать, что они там имели ввиду и учли ли вроде бы очевидные идеи. Хотя нежить и высказывает сегодня иногда не самые очевидные идеи, за что мы её и начинаем любить, но вовсе не факт, что сегодняшняя нежить учитывает при этом самые очевидные факты – надо вылавливать такое игнорирование, просить уточнять. Для Method=Function я ровно это и сделал (отследил и явно указал на синонимию), там ведь не было подгружено руководство по методологии, которое бы не оставило бы шанса на недопонимание. С большими объёмами файлов вся нежить сегодня очень плохо сравляется, нельзя пока загрузить все наши руководства для инженеров-менеджеров, чтобы учитывать всё текущее знание – и двигаться вперёд от уже достигнутого. Но я думаю, что где-то к новому году можно уже будет сказать “возьми вот эти руководства и придерживайся там написанного”.
Вот цепочка промптов в чате, одинаковая для всех (можете попробовать повторить эксперимент с вашей любимой LLM, там вы сможете в том числе и задать вопросы вроде “разъясни, что это ты такое говоришь”):
-
Проверь гипотезу, что архитектура - это общее свойство всех систем. В рамках FPF (из приложенного файла) evolutionary architecture может быть или фасетом, или даже отдельным фреймворкам, поскольку архитектурные свойства могут наблюдаться на каждом уровне. Про архитектуру и архитектурные свойства/характеристики (-ilities) информацию можно взять в руководстве по системной инженерии (в приложенном файле). Выдай набор возможных архитектурных U-Types. Оцени, надо ли делать при этом отдельный фреймворк или фасет с U-Types для функциональной архитектуры (process design). Отличия между функциональной архитектурой и evolutionary architecture бери в тоже в руководстве по системной инженерии.
-
Что в FPF поддерживает водопад/каскад, а что agile с evolutionary architecture методологии проектирования? Дай рекомендации по усилению поддержки evolutionary подхода против водопадного в FPF.
-
Если я хочу поддержать мышление функциональных и эволюционных архитекторов в FPF, какой план работ я должен предпринять, какие изменения в FPF запланировать? Где граница между фундаментальным мышлением, описание методов которого и предметов этих методов должно попасть в спецификацию ядра и модулей FPF и прикладным мышлением, которое должно попасть в domain frameworks?
4.Замечания: 1. Method и Function - это одно и то же: поведение System в какой-то роли (роль определяется создателем/constructor/creator этой инженерной системы исходя из его целей, а для природной системы роль определяется создателем/constructor/creator исходя из его догадки о целесообразности). Поэтому надо проверить, делать ли отдельный фасет или фреймворк для фукнций в функциональной архитектуре или просто как-то усилить фреймворк для методов. 2. Результаты работы эволюционного архитектора и функционального архитектора в инженерных процессах увязываются между собой проектировщиком. Надо проверить, облегчает ли поддержа работы функционального и эволюционного архитектора также и работу проектировщика: надо ли вводить какие-то дополнительные типы в уже имеющиеся фреймворки или вводить новые фреймворки и/или фасеты, чтобы это учесть. Разъяснения можно получить в приложенном файле руководства по системной инженерии. Что меняется в выводах всех предыдущих рекомендаций этого чата после этих двух замечаний?
- Мы в этом чате наметили, как поддержать архитектурную работу эволюционных и процессных/функциональных архитекторв, а также проектировщика, которые занимаются материальными системами из системного мышления. Но FPF также работает с эпистемами, а также сам является эпистемой (набором сложноструктурированных знаний: теорий, алгоритмов, доказательств и т.д.). Если учитывать, что у нас теперь есть мереология и операторы агрегации для эпистем, можно ли говорить об инженерии знаний (эпистемической инженерии) так же, как мы говорим о системной инженерии? Тогда это будет означать, что у нас есть эволюционный архитектор знаний и эволюционный функциональный архитектор знаний (проектирующий то, как взаимодействуют знания через их задействования системой-создателем, чтобы выдать какие-то изменения в окружающем мире) и проектировщик знаний, который увязывает модульную архитектуру знаний с функциональной архитектурой по мотивам того, как работает системный проектировщик. Вопросы: 1. Можно ли сделать какие-то обобщения для архитектурных фреймворков и фасетов, которые поддержат работу как системных инженеров (подроли эволюционного системного архитектора, функционального системного архитектора, системного проектировщика), так и инженеров знаний (подроли эволюционного эпистемического/информационного/знаниевого архитектора, функционального эпистемического/информационного/знаниевого архитектора, эпистемического/информационного/знаниевого проектировщика)? Или тут много специфики, требуется делать отдельные фреймворки и фасеты? 2. FPF сам является эпистемой. Можно ли говорить о его архитектуре (и функциональной, и эволюционной) и о проектных решениях? Если можно, то как это поддержано в ядре и фреймворках с фасетами? Принцип рекурсивного использования текущего FPF для создания следующих версий самого FPF достаточно ли прописан, чтобы планируемые эволюционные архитектурные, методологические/функциональные изменения и изменения для поддержки проектирования были автоматически использованы при создании FPF?
На этом я остановился, ибо ответов уже с лихвой хватало для планирования следующих шагов. Например, Groq разу высказал мысль, что с архитектурой квантовых и хаотических систем будет трудно, Gemini попытался ввести подкласс архитектурируемых объектов, чтобы отделить от всех возможных объектов, координаты эпистемы были отождествлены с архитектурными характеристикам – эта мысль не только мне в голову приходит, там сразу неочевидное разделение функций по модулям учёта риска и неопределённостей, рациональности и нормативов/целей, включая разбирательство с “целеориентированностью” и “целесообразностью”, явно недостаточно проработан вопрос “синонимии с нюансами”, без которой не разобраться с методами-функциями-культурами-стилями и всяким таким – там же кусок про типы, а у нас есть такой фреймворк, и много-много всего другого интересного.
И да, говорить об архитектуре самого FPF можно, и вроде вчерне понятно как. То есть давняя задача накрыть общим мышлением и материальные системы и эпистемы так, чтобы это не вызывало непреодолимых сложностей на каждом мыслительном шагу – она как-то решается, можно пробовать. Спасибо Мэтью Весту, что он подкинул мне ход на работы Kit Fine про “неклассическую мереологию”, а также спасибо Deutsch за его теорию создателей и Marletto, которая в одном из своих интервью явно проговорила цель этой теории - обобщить идеи преобразования информации (“вычислимые функции” и всё такое) на идеи преобразования чего угодно, в том числе материального, обобщить универсальную в плане вычислений машину Тьюринга до универсального в плане трансформаций Constructor. Для меня это просто продолжение хода эпистемологии с унификацией всех знаний как эпистем (и посадка на формальное основание этого, как я сделал в FPF), а также хода на безмасштабные универсальные методы мышления (как я прорабатывал в своих руководствах последние года три идею “рекурсивного применения системной инженерии” и RG-flow из физики). Вроде бы всё сходится и не слишком противоречит друг другу, хотя впереди ещё много интересной (во всех смыслах этого слова, кроме того, что гуманитариям – вряд ли интересной) работы. Хотя про гуманитариев мы тоже поговорим: я отслеживаю, что бы в FPF была и эстетика, а в части эпистемологии не забывалась и гносеология с её религиозным и художественным познанием (но эпистемы как результаты этого познания чтобы получали соответствующие оценки как минимум по характеристике надёжности).
Я когда-то описывал трудность современной науки: кто-то кладёт интересные (можно разбирать слово “интересный” по линии теорий интереса, теорий open-endedness) унифицирующие догадки-постулаты и говорит, что “решаем вот такие проблемы и вроде бы появляется универсальность, давайте работать”. В случае Эйнштейна таким его постулатам повезло: его теорию относительности подхватила толпа учёных, и они написали огромный массив работ, объясняющих мир с помощью этого постулата. Другим постулатам (возможно, таким же мощным) повезло меньше: люди уже были заняты какими-то постулатами предыдущего поколения. И они не выиграли в эволюции не потому, что они плохи. Нет, просто не было ресурса для размножения/репликации, чужие мозги были заняты. А мозги нужны не любые, а достаточно умные, чтобы что-то там развивать. Скажем, constructor theory очень интересная и многообещающая, и даже выходят какие-то работы по развитию этой теории и её приложениям (например, constructor theory of time в мае 2025 – [2505.08692] Constructor theory of time), но этих работ крайне мало: ещё много несделанного и в рамках текущих мейнстрим теорий. У других исследователей всё то же самое, например, у группы Ванчурина или группы Хренникова: красивые идеи, но мало внимания других исследователей, поэтому мало работ по прикладным аспектам, поэтому мало цитирований – и круг замкнулся.
По моим оценкам, с июня 2025 года ситуация изменилась: за не очень большие деньги можно нанять большую команду нежити, которая будет думать над вашими очень специфическими вопросами - и думать не месяц в свободное от других проектов время, а вот прямо сейчас, и ответ даст не через месяц, а вот прямо сейчас, через пять минут (хотя бывает, что и через полчаса). Конечно, доверия к этой нежити нет, ибо все попробовали поработать ещё с ChatGPT на основе GPT-3.5, и это никому не понравилось. Но нежить стремительно улучшается в части качества ответов, это качество растёт экспоненциально – быстро выходя за рамки качества ответов живых людей, переломный момент, повторюсь, был где-то в июне (а литература по всяческим замерам и критика идут до сих пор по более старым моделям). Уже к концу года пользоваться нежитью для исследований будут все. Это неудивительно: качество ответов калькулятора при умножении десятизначных чисел никого почему-то не удивляет, почему должно удивлять качество ответов при “перемножении” десяти предметных областей? Можно предпринимать уже прямо сейчас очень сложные научные и инженерные проекты с опорой на коллектив из нежити. Не ждать, пока у тебя будут деньги на организацию лаборатории. Чем и занимаюсь. Инженеры-архитекторы, ждите: помощь в мышлении к вам уже в пути, мы с нежитью уже идём к вам, “верьте мне, я инженер”!
