Lytdybr от 11 сентября 2025

Текущая версия FPF (вот тут: First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск, размер теперь 2.4M знаков в .md) содержит две новации:
– в ней существенно уменьшено количество лексического долга, поправлены заголовки (стали более дружествены к RAG), поправлены паттерны, ответственные за лексику (и обнаружено ещё огромное количество нового технического долга, вроде более 300 упоминаний plane с самыми разными значениями). Основной тут затык в том, что младшие модели лексически тупы и доверять нельзя даже GPT-5 Thinking, а GPT-5 Pro очень долго думает, но хотя бы отвечает осмысленно – поэтому всё происходит очень медленно и печально. Да, эти модели могут сделать grep по тексту и найти все вхождения (и выдать отдельным файлом эти вхождения), но и всё. Это я могу и сам, без моделей. Вот рассортировать эти 300 вхождений plane на senseFamily, I/D/S layer и ReferencePlane (а иногда и что-то вообще другое) это трудно. Поэтому работаем медленно, медленно, медленно и печально.
– дан старт новой части G с пока условным названием Discipline SoTA architheory generator, так что опубликованы скелеты (пока не полные тексты) шести паттернов этой части. Основной затык пока там с тем, что мне нужны SoTA дисциплины, а для этого надо и понятие дисциплины доопределить (это будет класс над методами), и определить их сравнение между собой, для чего начинается там всё с CG-Frame (comparability and gauge frame, куда входят основные характеристики и их шкалы, нужные для сравнения), а также по разделению слоёв I, D, S (интенсионалы/intensions, их неформальные описания/descriptions и их более-менее формальные спецификации/specs) ещё и описания и спецификации этих GC-Frame. И заодно идёт отладка понятия эпистемы, ибо в количестве появляются описания, описания описаний (и долго убирали путающее слово “мета”) и т.д. Это всё продолжение работ с лексикой (часть E), унификацией (часть F) и прочим тем, что делаю я сам. Типичный процесс knowledge aquisition в экспертную систему (subject matter expert тут я сам), но на новом витке технологий.

Думаю про семинар в начале октября. Что надо было бы рассказать про FPF на этом семинаре? И кто вообще туда придёт, это же явно программа исследовательского развития, к которой пока интерес был минимальный? Например, можно было бы выйти вот с таким рассказом (это сугубо черновик, комментируйте):
Семинар “First Principles Framework в программе исследовательского развития инженеров-менеджеров”

  1. Онтологические новации FPF
    – назначение FPF
    – основные принципы FPF
    – от онтологии к руководству: формат языка паттернов
    – конструктивная холоническая мереология, спрятанная от инженеров (CT2R).
    – привычное инженерное мышление в видах/типах (в FPF это kinds). Унифицированные виды/типы U-Types.
    – присвоение/assignment ролей и алгебра ролей
    – рефлексивное разделение (моделирование “само-”, в том числе моделирование управления)
    – задействование/enactment ролей (методы, работы, сервисы, обещания, свидетельства графы состояний)
    – унифицированный механизм охвата (Scope: ClaimScope, WorkScope)
    – цикл эволюции и open-endedness
    – цикл мышления и абдукция
    – уровни обоснований/assurance
    – …
  2. Эпистемология и самообновление
    – авторство и лексика (часть E)
    – унификация (часть F)
    – генерация архитеорий для SoTA дисциплин (часть G)
    – …
  3. Примеры наборов архитеорий:
    – эпистемы и их характеристики формальности F, охвата G и доверия R
    – творчество/creativity на базе теорий open-endedness
    – теория решений
    – …
  4. Использование и разработка
    – особенности использования AI в разработке FPF.
    – примеры использования FPF с AI
    – что планируется с FPF дальше
    – …

По части G работы ещё невпроворот, поскольку для автомагического (кхм, эээ… помечтаем) пополнения SoTA каких-то дисциплин надо в FPF доопределить ещё очень много в абсолютно ручном режиме. Вот для примера один из промежуточных моих промптов на этом нелёгком пути, а часть результата уже отражена в FPF:

Я подгрузил тебе файл со спецификацией FPF. В FPF творчество — дисциплина, а не “вдохновение по пятницам”. Есть набор архитеорий (A-kit) Creativity-CHR (C.17) с измеримыми характеристиками (Novelty@Room, Use-Value, Surprise, ConstraintFit, Diversity_P), NQD-CAL (C.18) как open-ended search/illumination-исчисление и E/E-LOG (C.19) как политика explore-exploit. Эти части сочленены с Канонической эволюционной петлёй (Explore → Shape → Evidence → Operate): гипотезы генерируются/оцениваются, проходят через доказательство пригодности, попадают в проверку реальностью и возвращаются с данными.

В FPF сейчас не хватает чётко определённых понятий, которые бы позволили бы обсуждать формализацию описания каких-то методов/дисциплин (таких, как творчество, принятие решений, архитектурные trade-offs и многие другие). Как минимум, надо создать набор архитеорий для теорий науковедения, чтобы обсуждать понятия дисциплины, в том числе прикладной дисциплины и трансдисциплины, предметной области, методов решения каких-то мыслительных задач и их описаний.

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

Другая сложность в том, что по теореме бесплатного обеда нет оптимальных методов решения всех задач, поэтому решение задач начинается с нахождения метода, эффективно решающего частный случай. Это поддерживается лучшими пакетами методов решения вычислительных задач, которые при общей сигнатуре метода предлагают разные варианты реализации сигнатуры, оптимальные для тех или иных частных случаев. Так устроены лучшие в мире (SoTA) пакеты решения задач ODE (DifferentialEquations.jl) и оптимизации (JuMP) для языка Julia, поддерживающего эту идею “общий вызов снаружи, обработка большого числа частных случаев внутри”. Можно принять, что проблема - это когда ты не знаешь метода, который может решить эту задачу (в том числе не знаешь реализации специализированного для частного случая метода, хотя сигнатура может быть известна). Проблема требует стратегирования, искомый метод - стратегия (иногда называемый policy). Тут есть множество терминологических нюансов, с которыми надо как-то разобраться (в FPF уже задействовано довольно много из упомянутых терминов и надо с предложением новых терминов быть аккуратней, всё проверять).

Третья сложность в том, что речь идёт о довольно длинной цепочке методов:

  • методы, которыми решается прикладная проблема. Это за пределами FPF как трансдисциплинарного фреймворка.
  • методы, которыми решается трансдисциплинарная проблема (например, перевод прикладной проблемы в задачу: это чаще всего основное, чем занимаются трансдисциплинарные методы: их предметом служат прикладные методы). Именно эти методы должны быть в наборе SoTA архитеорий по какой-то трансдисциплине.
  • методы, которыми создаётся плагин набора архитеорий по предыдущему пункту. Этим могли бы заниматься методы, описываемые паттернами, которые мы уложим в часть G SoTA architeory generation примерно так, как уложили набор паттернов по унификации в части F.
  • Вот этот чат с его методами, которыми мы создаём набор архитеорий из части G (SoTA architheory generation, но это имя хорошо бы уточнить, чтобы оно лучше отражало смысл).

Все имена и объекты, которые даны в этом коротком тексте, надо уточнять по технологии из паттернов из части F, в том числе используя принципы минимальной общности в наименовании и наименованию по назначению, чтобы каждое имя было самодокументируемым и чётко указывало на boundedcontext. Я подготовил также набор из скелетов паттернов, которые должны решить задачу генерации набора паттернов какой-то SoTA архитеории, заданной на уровне сигнатуры (краткого описания входов-выходов). В этом наборе паттернов много чего пропущено, они плохо согласуются с текущим набором паттернов FPF. Поэтому надо проверить эти паттерны и предложить недостающую терминологию и план доработки (включая разработку недостающих паттернов части G). Обсуждать будем по-русски, но писать паттерны и давать к ним правки (формат min diff) надо по-английски.

Всё время возникает вопрос, где же в МИМ обсуждают проблемы сложных проектов, которыми занимаются “люди со стороны”. Последний раз по вопросу проектного управления в больших (больше 200 человек) командах разработчиков софта, неожиданно в чате экзкокортекса МИМ (с Telegram: View @exocortexssm). Тут вопрос распадается на два: 1. Ответ по сути вопроса: там хором было отвечено, что довольно много материала на эту тему в руководствах по программе рабочего развития, а опыт инженеров-менеджеров, которые имели дело с такими проектами, регулярно докладывается на конференциях МИМ (и ещё некоторое количество общих замечаний про то, что серебряной пули нет, каждый проект имеет свои особенности, что хорошо в одном проекте – плохо в другом). 2. Почему отвечают не про проекты, а про руководства?! Потому что у нас сообщество носителей некоторой культуры мышления, и чтобы с тобой там общались на равных, надо как-то пропитаться этой культурой, иначе разговора не получится кроме как “пойди куда-то, поучись, потом возвращайся, поддержим”. Ну как в танцах, какое-нибудь там танго (у нас тут уже поучаствовали в разговоре занимающиеся танго). Если хочешь потанцевать с красивыми девочками, которые хорошо владеют своим телом — сначала учатся, овладевают культурой. А просто кто с улицы пришёл — смотри, но танцевать с тобой не будут, ибо есть с кем, кто уже умеет. Если хочешь танцевать с теми мускулистыми, кто в хип-хоп умеет — иди и занимайся сам хип-хопом. Других вариантов что-то не просматривается. Если идёшь в сообщество какой-то интересной культуры, надо обычно как-то ей овладеть перед тем как свободно общаться. До этого тебе будут вежливо указывать на что-то для начинашек: курсы, книги, школы и т.д., ибо разговора по существу всё равно ведь не получится. Сообщество МИМ тут не исключение. Вместо хождения в “танцевальную школу” тут предлагаются стажировки, в три этапа (1. РР, 2. СМ+Методология, 3. инженерный цикл). Многие тут это прошли, теперь вот обсуждают экзокортекс как набор инструментов для поддержки некоторой культуры, а не любые инструменты для чего угодно и любые методы для чего угодно. Сколько времени надо “входить в сообщество”? Как и в танцах: на входе есть поверье, что “три месяца занятий – и на вечеринку” (и это иногда даже правда), но не добавляют, что к тебе разворачиваются и начинают относиться как к своему только через три года (это не значит, что танцуешь хорошо, это означает, что приняли уже за своего, “вошёл в культуру”, “стал членом сообщества”). Через три года у тебя и важность того, что там в культуре поменяется. В танцах станет понятно, что там за “база” и почему надо долго и много заниматься не хорошо понятными “фигурами”, а именно этой “базой”. В сообществе МИМ станет понятно, зачем так много внимания уделяется вопросу о целевой системе, и зачем нужен наставник (если сам “читаешь руководства”, то можно уклониться от ответа на вопрос о целевой системе, а если у тебя стажировка с наставником – он не даст тебе уклониться от ответа, и это главная причина, почему наставник нужен. В танцах такой эффект тоже есть, там “чтение руководств” называют “учился по роликам в ютьюбе”, то есть “заучивал намертво свои ошибки”). При этом танцы - это культура хобби, хотя и очень полезная культура для здоровья. А культура МИМ – главным образом культура работы, полезна для работы (хотя культура программы личного развития полезна и для себя, любимого).

Как-то незаметно прошёл год регулярных занятий бальбоа. Теперь мне вполне можно посещать мероприятия с цензом “Ждём танцоров бальбоа с опытом от 1 года” (их множество таких, каждую неделю). Нет, база бальбоа у меня ещё не очень чистая, правильней было бы сказать, что я танцую бальбокиз: помесь зонтика бальбоа (три танца: Pure-Bal, Bal-Swing и Slow-Bal) и зонтика кизомбы (тут этих танцев штук восемь, включая даже компу).

seminarFPF

1 лайк