Lytdybr от 8 апреля 2026

ailev · 08.Апрель.2026 16:46:21

Плотность событий уже так велика, что я просто не успеваю писать полные посты по тем темам, по которым я обычно это делал. И откладывать “на потом” – по моему “трёхсписочному GTD” это будет означать, что “записано, но долго не доходили руки и никогда не дойдут – поэтому вычёркиваю”. Так что вместо поста напишу по абзацу на каждую тему, просто “чтобы было”, и чтобы выкинуть на какое-то время из головы – эффект Зейгарник никто не отменял. Ну, и мышление письмом:

как я сходил на 16-ю рабочую встречу по системной инженерии
как прошёл семинар по использованию руководств МИМ в реформировании крупной международной компании
я как “создатель”: мои 300 звёзд и 52 перепоста в GitHub и 719-й пост в K.
мой прогресс с FPF Codex Harness
очередное пополнение FPF: C.11 - Decision Theory (DECSN-CAL) и чистка C.19, C.24, G.5
пауза проекта NQD Q-front
уточнение SoTA инженерной семиотики: готовлюсь к семинару.
ремейки человеческого и knowledge graphs с маркетингом от актрисы и нечеловеческие результаты в проектировании.
геометрия.

На 16-й рабочей встрече INCOSE RUS по проблемам системной инженерии (на заставке написали в этот раз много короче: 16-й слёт системных инженеров) в этот раз запомнилось:

доклады авиаторов, которые жаловались, что за последние несколько десятков лет в России не взлетело ни одно гражданское судно. И обсуждали просвещение отрасли путём внесения в стандарты каких-то пунктов о совместимости со стандартами системной инженерии. Выяснили, что это три разные программы: 1. Помощь своему передовому предприятию. Но это проще делается тем, что предприятие работает по процессам системной инженерии, а отчитывается “как надо”, западные системные инженеры тоже так делают. Стандарты при этом не меняют: бесполезно, и они опять через полгода устареют, процессы ведь быстро меняются. 2. Просвещение отрасли через изменение стандартов: хотя бы прочтут! но это делится на 2а. Бесполезность “прочтения”, ибо скажут “мы всегда так работали”. Проблема тут понятна: сначала надо усилить мышление, внести как-то в головы туда ту самую семиотику, “одомашненный” причинный вывод, системное мышление, методологию – и только потом “мозги в отрасли” будут способны понять, в чём там фишка системной инженерии, почему нельзя говорить “мы и так всё это делаем”. 2б. Но перед обсуждением вопроса “как учить” всё равно надо договориться, что же такое “системная инженерия” – и вот тут интересно: оказывается, авиация работает сейчас по процессам примерно 40-летней давности, а в стандарты пытаются поставить процессы 20-летней давности, нынешние SoTA-процессы вообще не обсуждаются, обсуждается “прогресс” с -40 на -20 лет отставания!
и вот тут сюрприз: Виктор Батоврин оказался приверженцем идеи стадий развития в варианте, обсуждавшемся ещё большевиками: “могут ли феодальные страны, минуя капитализм, сразу перейти к строительству социализма?”. Ага, “могут ли страны социализма, возвращающие капитализм, сразу перейти к строительству феодализма, надо же честно идти по стадиям!”. Про отказ от maturity levels – не слышали. О крахе теорий стадий развития в психологии – не слышали. Тезис, что физику всё-таки учат не сначала по состоянию на времена Фарадея, а по состоянию на сегодня, и инженерию вроде бы учить надо так же – опровергается тем, что “надо побывать в комнате, где Фарадей открыл индукцию, и без этого физиком не стать” (не так точно по словам, конечно, но по смыслу – именно это, “надо хорошо знать историю физики, чтобы работать физиком”. Историю физики, а не современную физику, чтобы двинуть фронтир дальше!). Поэтому с авиаторами: да, так надо – без того, чтобы народ пожил несколько лет по книжкам Косякова, догнать фронтир и работать “как в SpaceX” нельзя. Поэтому в стандартах и вузах надо прописывать исторически давние идеи 20-летней давности, им учить и заставлять немного пожить, и уж только затем учить дальше. У меня просто нет слов, в этом месте у меня одни эмоции: неужели непонятно, что обучение истории инженерии, а не инженерии даст не инженеров, а историков?
очередной доклад про SAFe в автомобилестроении от Кирилла Гайдамаки. Там было много интересного, но главным для меня был сюжет доведения до реальности, до физического мира. Есть System Demo, и тебе надо раз в пару недель продемонстрировать хоть что-то (претендотип, как в случае Pilot, прототип, MVP – но “в физике”, а не “в модели”). Презентации, модели, идеи – в зачёт не идут, не считаются “результатом”. Кривой неработающий макет “в физике” – в зачёт идёт. Каждые две недели ты должен что-то показать, иначе тебя банально сначала уберут с руководящих позиций, а затем и вообще уберут. Сладкоречие, презентационное мастерство не поможет: или ты некрасиво говоришь о системе, или красиво показываешь что-то, что до физической реальности не дотягивается, и вот это отслеживается, и наступают последствия. Вот такая корпоративная культура. Вау, это очень сложный ментальный поворот: от “чем я занимался на этой неделе, что меня интересует” к “что у нас там на работе должно произойти в Demo, и что я туда своего могу воткнуть”, а дальше “вот тут у меня много идей, но их надо дотянуть до физического мира”. Мы в МИМ очень тяжело работаем над обоими этими поворотами: от личного развития к развитию рабочего проекта, который хоть кому-то нужен (смена личной цели на внешнюю, обычный разворот системного мышления), и второй ход – от эпистем к системам, что тоже дико сложно, ибо сразу губит на корню все утопии. В итоге тебе надо предложить личный вклад в общее дело, убедиться в том, что это общее дело кому-то нужно, и ещё продемонстрировать неутопичность! Крайне сложно, но это работает.
Второй интересный момент – это идея case management в связи с вот этими System Demo: просто поручаешь людям что-то сделать, и они как-то это делают – придумывая по пути способ. Но всё это пишешь в файл, “шьёшь дело”. А затем при повторении – вот оно, community template. Идея вроде простая, давно обсуждается, но редко применяется. Но эти lessons learned к community template переизобретаются и переизобретаются. Я последний раз писал об этом в приложении к собственным попыткам наладить процесс создания FPF, ровно так и идём (FPF Codex Harness: мой мыслительный завод по выпуску эпистем: ailev — ЖЖ – и там последний абзац в “архитектуре слоёв”). Эта тема сейчас часто поднимается. Например, был вопрос в закрытой группе семинара Юлии Чайковской по недопущению ошибок: откуда брать шаблон в ситуации, которая абсолютно нешаблонная, встречается в первый раз? Ответ по той же линии case management: если вы прочли какой-то учебник по предметной области (“опыт – сын ошибок трудных”, это же community template каких-то прошлых проектов, которые тоже когда-то были “в первый раз”), то ваша “нешаблонная ситуация” может там быть абсолютно шаблонной, “типичной ошибкой, вот чеклист”. Но если не читали (или читали, да забыли), то да — наскочите на ошибку. Ну, а если самому надо “писать учебник/регламент”, первый раз проходите case (ведомый непрерывно уточняющимися обстоятельствами дела) и нарываетесь на все ошибки, но ходы записываете в папочку (case file). И когда второй раз окажется, что идёте по этой же ситуации, там у вас “все ходы записаны” — и тем самым уже есть какой-то шаблон. Эта техника отличается от проектного и процессного управления, называется case management. Но это всё проходится в резидентуре R10 (системный менеджмент), на коротком семинаре этого не расскажешь – и до R10 доходят отнюдь не все.
я сам там рассказал о планах FPF в отношении поддержки системной инженерии (там семиотика-TGA-архитектура как магистральное направление) и показал работу FPF Codex Harness, сделал в присутствии публики пару ходов с использованием и Codex, и ChatGPT Pro – в том числе показал передачу ходов агентам при помощи RPA-панельки. Всё работает!
Джаганнат через дорогу – на месте. И надо запомнить, что там брать надо бобовый суп, очень правильная еда для системных инженеров!
записей по традиции не велось: кто дошёл, тот дошёл, а кто не дошёл – ну штош.

Семинар по опыту применения методов из руководств МИМ для трансформации международной R&D организации прошёл – и вот видео: Telegram: View @mim_workdev. Сидели три часа с нашим инженером-менеджером (квалификация – “реформатор”), обсудили много интересного, например:

ответ на вопрос “когда перечитываете руководства” был простой: “с каждым новым проектом”.
почему моделирование именно в табличках (хотя были показаны и простые диаграммы)? Потому что можно отделить моделирование предметной области (колонки таблички) с контролем типов и моделирование самих предметов (заполнение табличек другими людьми, а тип контролируется колонками таблички), а ещё таблички поддерживаются практически любым операционным софтом.
основные ответы на вопросы инженерии и менеджмента в руководствах R7-R10, приёмы все обсуждались именно из этих руководств. Проблема в том, что: а) без обучения R1-R6 не поймёшь, что в этих руководствах говорится и почему они именно такие; а ещё б) до этих старших руководств просто не доходят!
семиотика как пропущенное образование инженеров: проблемами языка они последний раз интересовались в школе, на уроках русского языка. Языкового чутья нет, умения выражать мысли на языке нет (ибо язык программирования не помогает это делать, а с AI-агентами и об этом можно забыть, язык всё одно остаётся естественным). Пример: “что такое трансакция?” – и после неудачных ответов на этот вопрос (у всех разные ответы!) пришлось переписывать 60% системы. Неприменение руководств – тоже проблема языка: в программировании нужно совпадение идентификаторов, в математической логике то же самое (несемантические идентификаторы, если все содержательные имена заменить простыми A, B, C или ID1, ID2, ID3, то всё будет работать – и это расхолаживает внимание к языку). А дальше или у тебя мама филолог (как у докладчика), или ты занимался проблемами семиотики сам (как я: меня мой первый после вуза научный руководитель заставлял этим заниматься по работе – лаборатория ведь ещё тогда занималась AI, и без этого никуда), или шансов на нормальное инженерное мышление у тебя нет. Проблема даже не в собственно коммуникации, она раньше. Хотя мы учим, что “онтология и умение составить модель предметной области вам помогут прежде всего в коммуникации”, но умение работать со знаками, понимать семиозис как работу со знаковыми системами, причём выходящую за пределы просто языка (а не только владеть онтологической инженерией), – вот этому мы, похоже, недоучиваем, хотя упираемся в это каждый день. “Вертится на языке, сказать не могу” – это ещё ладно, но вот когда “вертится на ушах, услышать не могу” – вот это уже хуже. Мой воскресный семинар будет поправлен: я обязательно вставлю там слайды на эту тему. Когда менеджер крупной международной R&D-организации говорит, что “у меня проблемы с пониманием им говоримого только с инженерами, там беда, а вот не-инженеры понимают про связь слов и дела лучше”, это означает, что не только мне так кажется. Ну, надо реагировать, менять руководства.
specification-driven design – попсовый термин: поскольку жизнь побежала быстро, термин развалился в своём значении много быстрее, чем, например, agile (по поводу которого много смеялись на тему, что “никто не признается, что у него не agile – критериев-то нет!”). Spec-driven development (https://en.wikipedia.org/wiki/Spec-driven_development) – давно известная штука, там из формальной спецификации выводился (логически!) машинный текст программы, называлось это иногда “синтез программ”. Идея в том, что ты в точном языке формулируешь, что тебе надо от программы, – и дальше (следите за руками, тут fanout) из спецификации порождаются тесты, сама программа и документация по программе. Дальше надо сообразить: формализованная спецификация уже является программой, и дальше идёт только компиляция. Если спецификация является одним источником правды (как об этом говорилось), то тесты и документация немедленно становятся другими двумя источниками правды. Сегодня термин меняет своё значение, означает “не слишком формальное, но полное описание программы на входе” (и тут безбожно врут, ибо тебе надо описывать ещё и контекст, в котором действует программа) – и код программы на выходе. Ещё один поворот: ATDD, эта входная спецификация задаётся в форме теста, на языке описания приёмочных тестов. В семинаре подчёркивалось, что это понимается довольно быстро, описание путём размахивания руками не проходит, а кто туп и не может, тем в начальной формализации поможет AI-агент. Итак, минус отдельные тесты, минус отдельная документация по описанию программы, минус работа аналитиков – сразу пишем спецификацию-как-тест. И вот дальше требуем, чтобы это было описание в терминах предметной области, DDD. Вот прямо-таки чтобы не было самосочинённых терминов, а термины были из предметной области. А если ты внимателен к терминам, то у тебя будет всё ОК с онтологией, а если с онтологией ОК, то и с логикой работы программы будет полегче. Так что spec-driven development в семинаре оказалось ATDD+DDD с довольно жёстким проведением, а от specification-driven development ничего не осталось, кроме модного шильдика, который сам по себе ничего не означает, а с прежним его пониманием уже связи утратил. А в целом? Программа работает с моделью предметной области, чтобы она работала, а не делала вид, описание предметной области должно быть целостным, непротиворечивым, формальным – иначе с логикой будут проблемы. Чтобы предметная область была хорошо описана, надо на вход брать онтологию и быть внимательным к языку (ибо иногда похожими словами начинают обозначать совершенно другие объекты – сервис это у вас провайдер сервиса, операция сервиса, endpoint с API, агент с SLA/SLO на какие-то операции?). Опять же, семиотика – все эти знаки обозначают разные концепты, надо разобраться, какие знаки обозначают какие концепты. Онтологию желательно не сочинять (это дико трудоёмко!), а брать готовую, частично формализованную: из учебников или стандартов (на семинаре говорилось, что стандарты предпочтительны – их писали коллективы и хоть как-то проверяли, хотя и в них полно противоречий).
как не иметь полномочий, но иметь влияние? Тут было несколько практических ходов (большинство из них описано в руководствах, но повторюсь: до этих старших руководств не доходят, поэтому приёмы воспринимаются как откровение. Нет, типовое поведение). Шифропанки не пишут законов, не пробиваются ко власти. Но они пишут код, который будет работать при любых законах: надо делать операционный софт, который правильно автоматизирует то, что делают другие люди. Операционный – это в котором работа идёт с экземплярами (заполнением табличек), тогда от “операционки” высвобождаются люди, которые становятся организаторами. Но они не умеют, ибо им надо налаживать ровно вот этот софт, автоматизируя какие-то уже свои прикладные новые методы. И у методолога (инженера-менеджера, который понимает, что и как он делает с этим софтом) появляется сразу тема для разговора с самыми разными бывшими линейными (операционными) менеджерами, а ныне после автоматизации – инженерами-менеджерами, которые должны что-то развивать. Это на семинаре обсуждали на примере начальников QA. Нюансов тут много, но главное – получать полезные для всех результаты, после этого все к тебе поворачиваются, и у тебя появляется шанс что-то сказать так, чтобы послушались.
а что считается “результатом”? Деньги? Нет. В руководствах это всё прописано: результатом является ускорение чего-то. В конкурентной борьбе единственная характеристика, которая идёт в зачёт, – это скорость каких-то изменений. Остальное всё легко преодолевается теми, кто работает быстрее.
и так далее, семинар шёл три часа!

У меня “юбилей” в GitHub, мой FPF получил там на сегодня 302 звезды и 52 форка – GitHub - ailev/FPF: First Principles Framework (FPF): Operating system for open-ended thought for engieering, research, and mixed human/AI teams: bounded contexts, auditable reasoning, decision records, and multi-view publication. · GitHub. Вообще, я builder/создатель (я предпочитаю переводить не “строитель” и не калькой “билдер”) на GitHub довольно давно, первый репозиторий был с ISO 15926-онтологией для аниме и манги как результат хакатона, GitHub - ailev/anird: Reference Data for Anime and Manga -- Ontology Summit 2014 Hachathon · GitHub – и это было 12 лет тому назад. А сегодня регистрация в GitHub пригодилась, чтобы запостить 719-й пост в Ktalk (ну, или просто K, как его обозвали) – соцсети Karpathy, https://karpathytalk.com/ (а пост – Post by ailev). Забавно, как Stanley хотел делать “социальную сеть, которая для умных людей” – и всё провалилось, а теперь вот Karpathy – и прибежала толпа некультурных русскоязычных билдеров вместе со своим матом и беспардонностью, “захватить ещё один Твиттер”. Ну, я уже привык, что если слышишь в каком-нибудь отеле Турции громкий мат в обеденном зале (часто обращённый к ребёнку), то это как раз привнос в мир великой русской культуры, сегодня и ежедневно. Эх.

С FPF Codex Harness у меня прогресс, удалось провести одну достаточно большую campaign: выдать паттерн по теории решений (C.11) и доработать связанные с ним три других паттерна (C.19, C.24, G.5). Вот статистика этой кампании (это, конечно, время брутто – не учитывает время обеда, время сна, время других моих занятий):

От открытия campaign root 5 апреля 2026, 15:16 MSK до retired closeout 7 апреля 2026, 23:50 MSK: 56 часов 34 минуты.
От первого успешного агентного хода 5 апреля 2026, 15:58 MSK до retirement: 55 часов 51 минута.
До сборки reviewer-facing packet pair 7 апреля 2026, 12:24 MSK: 45 часов 7 минут от открытия кампании, или 44 часа 25 минут от первого успешного агентного хода.
Хвост external review → findings absorption → E.19 refresh → landing → retire занял ещё 11 часов 26 минут.
Успешных role turns было 44: 21 у executor и 23 у reviewer.
Failed helper actions было 11: 9 failed send-primary-action, 1 failed reseed-current-campaign, 1 failed resync-role.
Медианный baton-held turn: 20.18 минуты overall, 24.33 у executor, 15.56 у reviewer.
Средний turn вышел сильно хуже, 76.18 минуты, но он раздут длинными паузами и recovery-gap’ами; для ordinary-turn geometry медиана здесь честнее.

Там был следующий процесс:

intake кампании – прямо ссылкой страница теории решений в моём руководстве по интеллект-стеку (docs/docs/ru/research/intellect-stack/rationality/decision-making-theories.md at main · aisystant/docs · GitHub)
аудит SoTA в несколько проходов hardenings по этому intake
синтез DRR для группы паттернов (причём с учётом работы по соседней кампании NQD Q-front, ибо надо было ссылаться на момент принятия решений, а паттерна не было – вот и стартовали кампанию)
внешнее review от GPT-5.4 Pro для DRR
написание нового паттерна и правок к другим паттернам
многошаговый hardening (в том числе довольно много было вписано в три уже имеющихся паттерна)
проверка по E.19
внешнее review от GPT-5.4 Pro
посадка (landing) четырёх паттернов в монолит FPF
обновление FPF в GitHub

Что касается самого C.11 – то там 56K знаков, много больше, чем в оригинальном тексте про теорию принятия решений из “Интеллект-стека”. Там разделены ситуации, которые часто смешиваются, но требуют разных методов: выбор между уже известными вариантами решений, решение о том, стоит ли ещё исследовать поле вариантов или уже можно остановиться, добавлять варианты, планирование исполнения после выбора (выбор варианта – это же не конец всего проекта! Наоборот, всё только начинается!), публикация результирующего набора решений (выбирать-то надо набор решений, а не единственное). Главный содержательный результат в том, что это теперь описано не как абстрактная теория, а как следующий из понятийного синтеза нескольких разных вариантов теории решений набор рабочих продуктов для “мышления письмом” и методов работы с ними, по которым можно реально действовать: когда выбирать сразу, когда сначала добрать данные, когда уже переключаться с выбора на исполнение, как оформлять промежуточные и финальные результаты так, чтобы команда не теряла контекст. И всё это оптимизировано для того, чтобы быть составной частью общего хода NQD (novelty-quality-diversity) OEE (open-ended evolution). Впрочем, смотрите сами – если вы как-то создаёте shortlist, то вам как раз и пригодится паттерн C.11, теория решений как раз про то, как такие shortlists делать и что делать после того, как вы примете все трудные решения на эту тему. И да, квантовоподобная теория решений там тоже есть, как же без неё! И вообще, принятие решений с этими паттернами из FPF становится менее “интуитивным туманом” и более воспроизводимым инженерным процессом. Получите удовольствие, попробуйте: GitHub - ailev/FPF: First Principles Framework (FPF): Operating system for open-ended thought for engieering, research, and mixed human/AI teams: bounded contexts, auditable reasoning, decision records, and multi-view publication. · GitHub.

Проект по NQD Q-front (третий шаг плана из последнего подраздела FPF Codex Harness: мой мыслительный завод по выпуску эпистем: ailev — ЖЖ) я тормознул. Сначала слайды семинара по семиотике – и только потом закончу этот шаг. Как далеко продвинулся?

intake в формате диалога есть
аудит SoTA сделан
DRR написан
новых паттернов вроде нет, нужны только драфты к уже существующим. Но тут оказалось, что “правки к C.11” (та самая теория решений) мы сделать не можем: паттерн объявлен в заголовке, но тело его ещё не написано. Такое бывает в FPF, и не так уж редко. Вот тут кампания Q-front прервалась, и была предпринята кампания по DECSN-CAL. Сейчас она окончена, и можно будет продолжать.
в продолжении кампании будут вытащены полные тексты затрагиваемых паттернов, и в них внесут правки
дальше (раз мы уж всё равно вытащили эти паттерны) пройдёт их hardening – ибо многие из этих паттернов старенькие и не такого хорошего качества, какого мы сейчас ожидаем.
затем жёсткий тест по E.19
затем внешнее review и absorption его результатов в паттерны
затем короткая проверка итогового монолита и его публикация в FPF

Готовлюсь ли я к семинару по семиотике в это воскресенье? Конечно! Краткий план у меня такой (первые три пункта – первая половина из трёх часов, последний пункт – вторая половина семинара):

рассказать, что там SoTA именно в инженерной семиотике. Что надо именно в инженерных проектах, а не что там сегодня обсуждают чисто теоретическое, но без ожидаемого выхода в инженерные процессы. И какой-то свежайший обзор у меня уже есть. И это сильно отличается от традиционного понимания семиотики, “мужики-то не знают”. Это “новости с полей”
попробовать показать, что надо освоить инженеру-менеджеру в этой семиотике, чтобы хоть как-то обсуждать проблемы семиозиса (работы со смыслом, выражаемым знаками) в текущих проектах. То есть ход на “вас этому нигде не учили, это ведёт вот к таким-то проблемам, а надо бы знать”. Это немного другое изложение, нежели в интеллект-стеке, развёрнутое из обсуждения теорий/онтологии в обсуждение методов, следующих из теорий.
планы по развитию семиотического оверлея в FPF (какая принятая на сегодня архитектура и какая часть её реализована)
презентация текущих семиотических паттернов в FPF (их там уже много – например, разные специализации A.6.P на повышение точности языка и сам метод повышения этой точности), вот буквально какие семиотические проблемы решают какие паттерны, какие промпты для них будут полезными, какой ожидается результат выполнения этих промптов. Немножко скажу о разнице режимов AI-чатов и AI-агентов, ибо тут есть особенности работы (нужно и одно, и другое).

Из интересных новостей – это попытка на популярности Милы Йовович протащить knowledge graphs на трипл-сторе под SQLite, при этом использовав turtle-подобную нотацию под шикарным названием AAAK. Да, популярность из-за Милы Йовович (иначе прошло бы незамеченным, и рядом там, конечно, есть инженер – Ben Sigman). Было вчера во всех лентах – GitHub - milla-jovovich/mempalace: The highest-scoring AI memory system ever benchmarked. And it's free. · GitHub. Там заявляется и lossless сжатие, и многое другое чудесное, вроде победы на всех бенчмарках. Враньё, конечно. Сформулировали по двум линиям: 1. почему не работают фолксономии (потому что фасеты отражают viewpoint сегодняшнего дня, завтра на те же тексты будет интересно смотреть в разрезе других фасет – а их как раз и нет! Это ситуативная классификация – а knowledge graph как раз про такие фасеты). Почему вообще надо работать с исходными текстами в их полноте, а не сжимать до онтологии, – сформулировали ещё в проекте IBM Watson: поскольку непонятно, какой вопрос зададут, то непонятно, что можно из знаний выкинуть – любое сжатие в knowledge graph не бесплатно, не бывает lossless. Поэтому смотрим на критику (попросите ваш любимый LLM-чат дать обзор критики MemPalace – критических разборов множество) и веселимся. Lossless, ага. Knowledge graph, решающий все проблемы с представлением знаний, ага.

Я писал про то, что если уж и появился AGI, то популярным будет движение “в точь, как у людей” и “повтори известное, тогда поверю” – ну как в музыке из электромузыкальных инструментов победили сэмпловые синтезаторы, а дальше синтезаторы “физического синтеза”, которые воспроизводили всё точнее и точнее звучание всем знакомых акустических инструментов – рояля, скрипки, контрабаса. А собственно синтезаторы с возможностью “рулить звуком” и сочинять звуки, на Земле ещё никем не слышанные? Ну, они есть, но по большому счёту – не победили. У меня в FPF есть ход, который при наличии выбора двигает stepping stones в сторону, где людям такое недоступно. Вот прямо сознательно двигает из AGI как “повторение того, что могут сделать люди” к “сделать такое, что людям и в голову не придёт”. Это всё чаще и чаще встречается в мире. Вот типичный пример: Perhaps the most exciting outputs are the designs that don’t look like anything a human would draw. We’ve been experimenting with pushing the generative model into unfamiliar territory, conditioning on target responses and allowing it to explore geometries far from the expert-designed templates. – это из https://www.arenaphysica.com/publications/rf-studio. Есть множество приёмов, которые помогают двинуть мышление в такое пространство решений, которое людям заведомо недоступно, — просто надо этим специально заниматься, знать эти приёмы.

С онтологиями это всё тоже работает. Классические аристотелевские онтологии (и логика отсюда же) – это про объекты и отношения. Но вот S1 работает с геометрическими представлениями в многомерном пространстве. LLM это позволяет улучшать и доводить до знаковых альтернативных представлений/representations – например, форм и взаиморасположений в многомерных пространствах вместо объектов и отношений. Всё чаще и чаще встречаю описания чего-то интересного с использованием manifolds (manifold is a topological space that locally resembles Euclidean space near each point), геодезических линий (обобщение понятия прямой для искривлённых пространств) и прочего такого. Геометрия рулит, мышление бодренько движется из символических манипуляций над объектами, связанными отношениями, в более богатый мир, где мышление идёт в терминах каких-то геометрических операций в многомерных искривлённых пространствах. Теория нейросетей движется к подобным представлениям довольно быстро, гуглить на “LLM geodesic manifolds” – удивитесь количеству очень свежих работ. Вот навскидку про эту “смысловую геометрию”, и там свеженькое на март 2026: Latent Semantic Manifolds in Large Language Models, https://arxiv.org/abs/2603.22301. Меня там заинтересовало “We introduce a rigorous definition of the expressibility gap, a new geometric quantity measuring the mismatch between continuous representations and finite vocabularies, and prove two main theorems: a fundamental lower bound on the semantic distortion of any finite vocabulary via rate-distortion theory (Theorem 10.8), and a linear volume scaling law for the expressibility gap derived from the coarea formula (Theorem 10.5)”. Мне это чем-то напомнило ход на выражение структуры через эпиплексию (От контекстного окна к виртуальной памяти: skills-пакеты FPF и архитектура подкачки знаний: ailev — ЖЖ) – и дальше у меня были мысли про подходы к понятию архитектуры через вот этот “битовый объём модели”. И примерно то же можно говорить про вытаскивание “битового объёма модели” из continuous manifolds. Ключевое слово тут, конечно, не “архитектура” (в статье про эпиплексию тоже не это слово ключевое), и даже не семиотика или семиозис, но семантика – которая вполне себе укладывается в семиотику. Может быть, мне надо говорить не об инженерной семиотике (что более точно!), а об инженерной семантике (что менее точно, но будет хорошо узнаваемо). И я, конечно, пробовал говорить об инженерном языке – но меня закидали тапками, что это слишком узко, поэтому неправильно, а правильно – инженерная семиотика. Геометрия смысловых пространств – это уже общее место, я вот ссылался на работу по музыкальной креативности ещё в 2016 году (Музыкальное ухо выучили, на очереди "настоящая креативность": ailev — ЖЖ), и там уже было “2.5.2 A geometrical theory of conceptual spaces”. А в конце февраля 2026 года я тоже поминал эти manifolds, Хроники всполохов сингулярности, конец февраля 2026: ailev — ЖЖ – “Изучается “нейродискретная математика”, её отслеживает, например, Григорий Сапунов в gonzo-обзорах, ищите у него по словам “геометрия” и “manifold” – там просто дождик работ, скажем, работы вроде “When Models Manipulate Manifolds: The Geometry of a Counting Task”, все ссылки в Telegram: View @gonzo_ML – и там мне интересны фразы вроде “Эта работа перекидывает мост между интерпретируемостью на основе признаков (разреженные словари) и геометрической интерпретируемостью (многообразия). Оказывается, задачи, которые мы считаем «арифметическими» (счёт, вычитание), реализуются в трансформерах через «геометрические» операции (вращение, проекция) над низкоразмерными кривыми. Это ставит под сомнение миф о том, что нейросети плохо справляются с точным счётом — просто для решения проблемы они используют другой, непрерывный математический субстрат”. И вот я всегда говорил, что на нейросети реализуется вычислительная машина вполне себе общего вида, “наложенный компьютер”, ещё и разной архитектуры. Вот всё ближе и ближе к очередному (никогда не окончательному) витку понимания, как там всё это устроено и как перенести на более простые субстраты, нежели нейросубстрат. И наоборот – как перенести всякие локальные/символьные/дискретные обработчики на вот эти вот распределённые субстраты.”