По поводу вчерашнего “E.TGA: Eulerian Transduction Graph Architecture” (E.TGA: Eulerian Transduction Graph Architecture: ailev — ЖЖ) мне уже написал Артём Глушко (Telegram: View @ailev_blog_discussion):
Выбор эйлерового представления - это гениально. (Извините.)Я ему в ответ написал, что извиняться не надо, это и впрямь гениально: ход на акаузальное моделирование.С таким подходом в моделировании с LLM, например, при поступлении новых вводных мы не занимаемся перестройкой графа, а просто дописываем дополнительные условия в контекст, а LLM пусть ищет удовлетворяющие решения. Антихрупкость получается.
В этом один из затыков у меня и, похоже, других людей с опытом программирования, кто привык моделировать потоками. Прям принудительно разучиваться приходится. При этом часто люди без опыта программирования легко принимают новую парадигму работы с LLM. Теперь этому есть теоретическое обоснование и понятно куда двигаться.
Подробно про разницу каузального (скажем, SimuLink, SimInTech) и акаузального (иногда называемого “физическим” и там лидером были системы на Modelica, потом основные разработчики Modelica ушли в Julia, а сейчас вырывается в лидеры Dyad) моделирования я писал в “Цифровые двойники: физика ведёт математику, математика ведёт компьютерную науку” в 2021 (Цифровые двойники: физика ведёт математику, математика ведёт компьютерную науку: ailev — ЖЖ):
Традиционно инженеры пользовались MatLab (более удобен для вычислительных задач, чем Фортран) и SimuLink для создания имитационных моделей, программные среды для вычислений с ODE (odinary differential equations in state space form – дифференциальные уравнения для пространства состояний входов и выходов). Это стало мейнстримом, но оказалось, что сопровождать модели в такой форме невозможно: для типовых случаев нельзя сделать библиотеки отдельных функциональных элементов, которые присутствуют в системе, и приходится каждый раз понимать, куда и как вписать очередное уточнение модели, или куда и как вписать очередное изменение модели.Вот примерно по этому пути и пошли с эйлерианской архитектурой графа трансдукций. На английском – Eulerian, мне это больше нравится, чем “эйлеровым”, ибо “эйлеров граф” не про то, да и Эйлер в оригинале ближе к Ойлеру, да и говорить так мне кажется эстетичней – “Венерианские хроники”, а не “Венеровы хроники”, “Батлерианский джихад”, а не “Батлеров джихад”, и таки “эйлерово описание/представление потока” (Эйлерово и лагранжево описания движения сплошной среды), но эйлерианская архитектура графа трансдукций, чтобы не путать с элеровым графом, Эйлеровость графов — Викиконспекты, но это всё нюансы, “поговорить” – мой ответ тут “знаю, игнорирую, ибо “Роза пахнет розой, хоть розой назови её, хоть нет””.Потому моделированию в ODE было противопоставлено акаузальное моделирование/acausal modeling с использованием DAE (differential algebraic equations) с алгебраическими переменными, которым a priori не могло быть придано никакого входного или выходного статуса – порядок вычислений не мог быть предсказан, ибо непонятно заранее, где у какого-то резистора вход, а где выход в составе модели.
Но как же проходит такой трюк с переходом от ODE к DAE? А вот так: разные уравнения собираются в большую систему из сотен, или даже тысяч (а в последнее время речь идёт и о миллионах) дифференциальных уравнений, и дальше решением этой огромной системы уравнений занимается компьютер (или даже суперкомпьютер, если система реально большая). Вот сравните удобство для инженеров моделирования электрического мотора с учётом инерции его вращения при представлении модели в DAE и ODE формах (https://www.researchgate.net/publication/336846217_Multi-Mode_DAE_Models_-_Challenges_Theory_and_Implementation).
Конечно, заходов на evolvability архитектуре много, все они решают одну и ту же задачу: “вот обнаружились новые обстоятельства, надо в систему добавить фичу. Как её просто взять и добавить, чтобы не перетряхивать для этого всю систему?”. В эпистемах всё то же самое. Вот я хочу поменять термин в двухтомничке (часто это делал! Скажем, 500 вхождений). Как его поменять в одном месте, чтобы не втыкаться в каждую точку этого текста, где есть этот термин? А если это русский язык – то надо ещё отследить согласования (род, падеж, склонение), и ещё надо отследить местоимение для этого термина и поменять согласование и для него. Кстати, выбор английского для FPF я сделал в том числе и по этой причине: если надо, просто “полнотекстовая замена”, и дело с концом. Очень удобно! Английские тексты тем самым “более evolvable”.
В хардвере “по-настоящему evolvable” архитектуры - это патефон и пластинки прежде всего. Один патефон, но играет вообще всё, ибо разнообразие - в пластинках. Это идеал, в IT это “микроядерная архитектура”: микро-ядро и огромное число плагинов. Операционная система с её plug-and-play как раз пример. Микросервисы с их оркестрацией тут отдыхают, добавить ещё один в их паутину можно, но сложно.
В языках программирования добавление чего бы то ни было – тоже проблема, у неё есть имя, expression problem (Expression problem - Wikipedia ), решения тут все паллиативны. Я писал об этом много, вот ещё десяток лет назад в “Две большие фичи Julia и инженерное шапкозакидательство на их основе”, Две большие фичи Julia и инженерное шапкозакидательство на их основе: ailev — ЖЖ (моя шапка долетела до цели: акаузальный моделер на Julia таки был написан, “Dyad is the modeling system for next-generation engineers”: Dyad).
И проблематизация системного подхода с его “делением на части” со стороны коннекционизма – вот тоже туда: Коннекционистская проблематизация системного подхода.: ailev — ЖЖ, модульность нейронных сетей не очень-то даётся, хотя для неестественных нейронок, конечно, кое-что в части “таблеток знаний” придумано, это естественные мокрые нейронные сети в части этой модульности вообще никакие.
Так что иметь граф, где какие-то узлы можно просто добавить, какие-то проверки на рёбра можно навесить, а дальше “мощный неживой мозг” будет с этим разбираться – это большое дело.
Но нужен “хак мозга”, чтобы с этим разобраться. Первые принципы контринтуитивны, каждая новая свобода в мышлении (свобода – это когда есть из чего выбрать, например, из лагранжева и эйлерова представления потока, а не только из лагранжева) даётся тяжким мыслительным трудом. А потом? Потом метанойя: “непонятно, что было непонятно”.
Как я к этому пришёл? Я пытался описать цепочку морфизмов как principle enactment architecture (Principled Enactment Architecture: от аксиом к постулатам, затем к чашке кофе (и обратно): ailev — ЖЖ), и понял, что LLM напихивает какое-то невероятное число одинаковых проверок в каждую точку, а также каждое усложнение цепочки (“механизм, уточняющий другой механизм, который на выходе даёт сигнатуру” – вот примерно такое) порождает “взрыв проверок”. Захотелось вынести эти проверки куда-нибудь за скобки. По факту пришлось вручную задать структуру трансдукционного графа общего вида и подсказать лексику. После этого LLM сказала, что знает SoTA математику для такого, что в инженерии эту математику для “вынесения проверок за скобки”, “плагинной структуры для проверок” тоже используют – главным образом там, где важна сертификация (скажем, созданием авионики). Ocaml 5 (OCaml - Wikipedia) и Koka с Effekt (https://effekt-lang.org/) c их функториальной математикой для effect handlers (Effect system - Wikipedia) у архитектуры графа трансдукций в FPF – близкие родственники. Это не совсем акаузальное “физическое моделирование” (и даже “совсем не”), но цели там такие же: добавить модульности, чтобы поднять evolvability. Для этого нужны “функции, которые работают с функциями” – и сразу попадаем в теорию категорий.
Дальше у меня в планах потихоньку на эту архитектуру графа трансдукций перевести весь FPF, ибо сейчас там “официально” микроядерная архитектура с архитеориями, и мне она не очень нравится, ибо “трансдисциплины и их архитеории” над “прикладными дисциплинами и их теориями” подразумевали фиксированное число уровней. В FPF их было зашито аж четыре (см. E.11 ATS), и это было ужасно! Вместо E.11 уже был написан E.17 для графа трансдукций, теперь будет задача E.11 с его 4 уровнями изобразить как “частный случай” для E.17, а то и вообще убрать. По большому счёту, теперь весь FPF надо переписывать – появился огромный эпистемический долг, “наши представления о мире существенно поменялись, давай существенно перепишем всё”.
Огромный объём текстов также привнёс свои проблемы: я теперь задействую два файла (FPF и “задание”), в ChatGPT я их указываю обязательно в порядке “задание, затем FPF” из-за местной архитектуры RAG, в задании я сделал подробное RAG-ориентированное оглавление. И ещё у меня промпты где-то на 100Кзнаков (десяток Кзнаков моих просьб и текст создаваемого-редактируемого нового паттерна, а то и пары паттернов). 196Ктокенов контекста для таких задач категорически не хватает, поэтому ждём GPT-6 или Gemini 3.0, или Grok-5, что там будет раньше. Модель GPT-5.1 пока не использую, её в Pro варианте нет, а Thinking – не тянет, проверено, да и контекст там – те же 196Ктокенов.
Основные проблемы всё те же, они ровно те же, что у наших инженеров-менеджеров “на входе”: неудерживание строгой типизации, подбор сверхобобщений в терминологии, чтение только заголовков (если не сказать “прочти целиком из файла”) и откровенное сочинение того, что там внутри, отношение к тексту и жизни в целом как программированию, ибо главное направление обучения AI – это математика и программирование. Чуть что неправильно назовёшь – нежить уносит тебя по ассоциациям в неведомые мыслительные края, потом это долго приходится вычищать.
Проверок и запретов для них нейросеть вносит дикое количество самых разных видов и самой разной жёсткости, причём прямо там, где они используются, а не отдельно в каком-то месте, где они должны задаваться. Ну, и не только проверки. Скажем, Viewpoint-View по мотивам ISO 42010 появился дважды (для узла графа и для описаний), и это спокойно вставлялось без вынесения этого механизма за скобки. При попытке вынести за скобки по прямой наводке – без попытки вынести за скобки ещё и проекцию как более общий паттерн. При указании на проекцию – всё тут же наладилось, “проекция - это не механизм, потому как у неё нет внешних эффектов, и вот у нас тут куча всего в FPF такого, это будут частные случаи”. И, понятно, тут тоже математика: функториальные композиции для графа я уже называл (это где механизмы с эффектами), а это будут оптики/линзы – и всё это указано в SoTA-echoing паттернов, я включил этот раздел в шаблон разделов паттернов (E.8), чтобы хоть как-то гарантировать SoTA в FPF.
Деонтика против контрфактичности (законы людей против законов физики) тоже доставляет забот. Вслед за “проверкой выполнения заданных уравнениями условий в узле графа и на его ребре” приходили нейронные законники и силовики (это же “проверка”, как же без них! бойтесь лексики! нейросети работают по ассоциациям, если неправильно что-то назовёте, то будете удивляться далёким последствиям!) и устраивали административный адъ (они ведь больше ничего не умеют, им на нейронебесах именно за это платят, за “а если найду”), содержательная работа становилась не видна – и у неё даже не было названия, лучшее предложение нейросетки было… “семантическая”, ага. То есть опять про информацию, а что там теплоэнергоперенос какой – это нейроразум не интересует, он же на кодирование настроен, все бенчмарки нежити сейчас проверяют только качество работы для программистов, всё остальное только как побочный эффект и показывается “для галочки”. Вот в работе этот нейропрограммист и выпрыгивает первым, а за ним DevOps, а за ним – офицер compliance, safety и security. Всё, работа остановлена, 100% времени уходит на вписывание новых и новых проверок во все места, а когда указываешь на то, что “вот у нас тут указана уже эта проверка”, тебе говорят “там её не прочтут, давай для надёжности повторим вот тут”. И это, возможно, правильно: без денормализации этот объём текстов в текущих объемах контекста не проворачивался бы. А тут – ключевые “первые принципы” повторяются во многих местах, и это нормально, что не “шестая нормальная форма” (Нормальная форма — Википедия ). Но всё равно: тебе приписывают “контрактное программирование”, дальше начинается ужас-ужас с “контактами”, и хоть как-то это упорядочивается только когда жёстко указываешь на то, что контрактное программирование “не взлетело” ровно по этим причинам: когда контракт на контракте и контрактом погоняет, то идёт взрыв проверок выполнения контрактов, и уже никто контракты не выполняет, на выполнение контрактов ресурсов нет, ибо все заняты только проверками. Помогает против этого математика: она указывает на способы теоретического минимизирования числа этих проверок.
“Водопад” в разработке медленно и кроваво заменился agile, а в agile управление жизненным циклом оказалось “постановкой инженерного процесса, где непрерывное всё”, разработка стала тестоориентированной и руление ей отошло отошло DevOps, которые стали ответственны и за прогон тестов (включая тесты архитекторов - fit functions), а также NoOps в части развития инструментария (вот я писал “Эволюция методологий тест-ориентированной разработки”, декабрь 2024, Эволюция методологий тест-ориентированной разработки: ailev — ЖЖ), это оказалась инженерия внутренней платформы разработки. И потихоньку оказывается, что “непрерывное” - это эволюционное. И самое интересное, конечно, в метриках и замерах. Курируемая эволюция, в том числе эволюция и метрик, но под чётким управлением метрик - идеала не достичь, в тамошних шкалах выбор каждой точки это trade-off, побеждает не лучшее решение, а не самое плохое. В терминах NQD и open-endedness это означает про оперирование всегда кучей решений на непрерывно ползущем Парето, и эти решения недоминируемы. Разговор об этом идёт в очень разной терминологии, но эволюционная суть – одна. Open-endedness добавляет при этом, что это не просто эволюция, но “развитие”, когда потихоньку растёт сложность решаемых системой проблем – и отслеживаем эволюцию не только 1. самой системы, но и 2. проблем, которые она может решать. Кто знаком с моими руководствами по рабочему развитию и постами последней пары лет в моём блоге, то даже что-то поймёт в этом абзаце. Вот на моделирование этого всего “из первых принципов” и нацеливаемся.
Всё это – обычная лексическая, онтологическая и методологическая работа в 2025 году, на пределе возможностей собственного мозга и возможностей таких его усилителей, как ChatGPT.
Кое-как я почти завершил эту часть с архитектурой графа трансдукций “в принципе”, но там ещё на месяц чисток всяких технических долгов: лексика, модульность, универсальность (в конце задания штук двадцать пять примеров без эволюции, и ещё десяток примеров с эволюцией, на которых моделирование не должно развалиться, но и эти примеры надо чистить!). Поэтому больших прорывов ждать пока не надо.
Ну, и буду готовиться к семинарам по FPF. Есть даже ещё несколько дней для того, чтобы уточнить тему первого семинара (он будет 7 декабря, а объявление о нём будет где-то через неделю). В комментах пишите, что вам наиболее любопытно про FPF, постараюсь это учесть.
