Гришины “любимые гиперсети” против моей “любимой evolvability”
Ровно месяц назад я приводил пример обзора как у Григория Сапунова, только в формате архитектурного решения (ADR) – FPF и gonzo-обзоры архитектуры нейросетей: ailev — ЖЖ. Сегодня не удержался, ибо в его обзоре появилось evolvability не как классическая архитектурная характеристика, но как “навык”, то есть мастерство. Я удивился такому отнесению к типу, глаз зацепился – но текст там и впрямь хорош, Telegram: View @gonzo_ML.
Моё “evolvability” классическое: насколько система не разваливается после неизбежных модификаций в ходе разработки, ибо непрерывно находятся новые обстоятельства, которые ведут к внесению изменений, и в какой-то момент надо “переписать всё”, изменения становятся разрушительными. Разработчик и архитектор конфликтуют, ибо разработчик хочет внести изменение, а архитектор требует, чтобы вносимое изменение не запрещало дальнейшую эволюцию, да ещё и заставляет разработчика сделать что-то специально для этой evolvability, то есть для него, а не непосредственно для клиента. За удовлетворение клиента разработчику дают премию, а за удовлетворение архитектора – нет. Если разработчик и архитектор в одном лице – это конфликт интересов.
Для Григория его обзор про “любимые гиперсети”, а для меня – про evolvability как архитектурную характеристику, ведущую к конфликту интересов агента-нейросети как “саморазработчика” и “самоархитектора”: в ходе обучения/приспособления нейросеть должна быстро находить новые (novelty) полезные (quality) вариации (diversity) поведения после смены условий, не разрушая уже найденное. В этой работе NQD явно не упоминается, но это классика для OEE (open-ended evolution, хотя в статье не совсем open-ended, ибо там нет бесконечной новизны задач, а статья осторожно говорит, что это “шаг к open-ended агентам”). Для Григория это выглядит как “мастерство/умение”, потому что механизм NQD (“novelty + quality с контролем разнообразия популяции” – где и насколько и какой вносить мутационный “шум” в модель) перестаёт быть внешней эвристикой разработчика и архитектора и становится внутренним объектом, который сам отбирается средой и селекцией. Грубо говоря, если “разработчикоархитектор” не справляется со своим конфликтом интересов, то он эээ… вымирает, у него не будет шансов дать потомство.
Просим LLM+FPF пересказать статью как стандарт для действия, а не результат исследования
Повторяю это месячной давности развлечение с генерацией архитектурного решения по научной статье. Вы тоже такое можете: загружаете в LLM файл FPF (не бойтесь “маленького контекста”, с этим файлом там будет работать RAG вашего любимого чат-агента), который берёте в GitHub - ailev/FPF: First Principle Framework и даёте промпт на пару строчек вроде этого моего. Вот итоговый промпт вместе с цитированием записи:
Сделай по следующему тексту паттерн ML.2 по шаблону из E.8, пиши для инженеров и добавь дидактичность в стиле написания, пиши по-русски. Учти E.TGA и OEE для понимания, но не повторяй их положений в паттерне, используй обычный язык инженеров, а не лексику FPF. Вот текст со ссылками на технологию:Hypernetworks That Evolve Themselves
Joachim Winther Pedersen, Erwan Plantec, Eleni Nisioti, Marcello Barylli, Milton Montero, Kathrin Korte, Sebastian Risi
Статья: [2512.16406] Hypernetworks That Evolve Themselves
Код: https://github.com/Joachm/self-referential_GHNs
Ревью: Hypernetworks That Evolve Themselves - ArXivIQTL;DR
ЧТО сделали: Авторы предложили Self-Referential Graph HyperNetworks (GHNs) — класс нейросетей, способных генерировать параметры не только для решения задачи (policy), но и для создания собственного потомства. Встроив механизм стохастической вариации прямо в архитектуру, система интернализировала эволюционные операторы (мутацию и наследование), которые обычно находятся во внешних алгоритмах.
ПОЧЕМУ это важно: Это структурный сдвиг от парадигмы «оптимизации фиксированной модели» к «моделям, которые оптимизируют сами себя». Подход показал превосходную адаптацию в нестационарных средах (где правила игры меняются на лету), обойдя традиционные стратегии вроде CMA-ES или OpenES. Работа доказывает, что «evolvability» (способность к эволюции) — это навык, который можно выучить в зависимости от контекста, а не фиксированная эвристика.
Подробнее: Telegram: View @gonzo_ML_podcasts
Архитектурный паттерн “ML.2 - Самореферентная GHN: встроенная «эволюция» для быстрой адаптации в меняющейся среде”
Через 16 минут 20 секунд ожидания (в прошлый раз это была быстрая бесплатная Gemini 3 Pro Preview, а в этот раз я поручил это GPT-5.2 Pro на extended thinking) читаем текст паттерна ML.2 в форме архитектурного решения (https://chatgpt.com/share/6954df4f-8108-8013-8152-3f6ade4423a7):
Текст я взял прямо кнопкой копирования ответа, не менял даже разметку (она вставилась в Semagic как HTML-блок). В итоге не столько “объяснялка” (но можно попросить объяснить, это же чат!), сколько вполне годный результат архитектурного паттерна, полученного по тексту статьи: ответ на вопрос “зачем делать, что делать, на что обратить внимание, как проверить, что делаю что надо” – классические ответы на классические инженерные, а не исследовательские вопросы. Попробуйте сами FPF с подобным промптом для ваших любимых статей.ML.2 - Самореферентная GHN: встроенная «эволюция» для быстрой адаптации в меняющейся среде
Type: ML / neuroevolution / архитектурный паттерн
Status: DraftML.2:1 - Problem frame — где это применимо на практике
Вы строите систему, которая должна продолжать работать, когда среда меняется: динамика, правила, инверсия управления, смена сенсоров/актуаторов, внезапный сдвиг распределения. При этом:
Градиенты либо недоступны, либо бесполезны (чёрный ящик, недифференцируемые компоненты, дискретные решения, симулятор как «API»).
Перетренировать модель «с нуля» долго, а надо “откатываться” к хорошему поведению за считанные итерации/поколения.
Вы готовы платить параллельными прогонками (много воркеров, короткие эпизоды/батчи), но хотите экономить на внутреннем обучении каждого кандидата.
Типовой пример из статьи — RL-бенчмарки с резкими сдвигами (CartPoleSwitch, LunarLander-Switch) и локомоция (Ant‑v5), где показана адаптация популяции после смены условий. (arXiv)
ML.2:2 - Problem — почему «внешняя эволюция» часто не дотягивает
Классические эволюционные стратегии и генетические алгоритмы обычно устроены так: есть оптимизатор (внешний код мутации/наследования/селекции) и есть оптимизируемая модель. Проблемы в инженерном смысле:
Мутация слепая к структуре модели. Часто это «гауссов шум по всем весам» с глобальным шагом — без понимания, какие части архитектуры критичны, а какие можно «трясти» сильнее. (ArXivIQ)
Шаг мутации приходится тюнить извне. После смены среды/правил оптимизатору нужно время «переобучить» ковариацию/шаг, и вы ловите провал качества. (ArXivIQ)
Сложно встроить в продуктовый контур. Внешний оптимизатор живёт отдельным компонентом со своим состоянием, эвристиками и версиями; тяжело обеспечивать воспроизводимость, откат и понятный контроль рисков.
ML.2:3 - Forces — компромиссы, которые нужно удерживать
Сила Напряжение (что конфликтует) Скорость адаптации Быстро “встать на ноги” после сдвига ↔ не разрушить то, что уже работало Исследование vs эксплуатация Сильнее «трясти» модель ↔ удерживать стабильное качество Стоимость оценок Больше эпизодов/прогонов ↔ меньше времени и денег Шум в фитнесе Реальная метрика нестабильна ↔ селекция требует надёжного сигнала Управляемость релизов Онлайн-адаптация ↔ требования к safety/rollback/аудиту Структурная осмысленность мутаций Учитывать граф/архитектуру ↔ усложнять реализацию ML.2:4 - Solution — что делаем и как это собрать
Идея в одной фразе: вместо того чтобы держать «мутацию» снаружи, мы делаем так, чтобы модель сама генерировала свои вариации и тем самым “училась быть эволюционируемой”.
4.1. Архитектурный скелет
Берём Graph HyperNetwork (GHN) как генератор весов: он читает вычислительный граф целевой сети и выдаёт параметры для её узлов/операторов (то есть «инициализирует» или «собирает» веса под конкретную архитектуру). (OpenReview)
Дальше добавляем самореференцию, как в Self‑Referential GHN:
Детерминированная ветка генерирует веса policy‑сети (или вашей рабочей сети), по которым мы измеряем качество в среде. (arXiv)
Стохастическая ветка генерирует возмущение для копии самой GHN, т.е. создаёт «потомка». Это делается через предсказание параметров шума (например, σ для гаусса с нулевым средним), плюс вводится управляемая интенсивность мутаций на уровне узлов/блоков. (arXiv)
Таким образом одна и та же сущность:
порождает веса для политики (чтобы играть/управлять),
порождает изменения своих же параметров (чтобы эволюционировать).
4.2. Эволюционный цикл (минимально достаточный)
На уровне системы это выглядит как популяционный цикл:
Инициализируем популяцию GHN-индивидов (разные веса). (arXiv)
Каждый индивид:
генерирует policy‑веса детерминированно,
получает фитнес через прогоны в среде,
делает 1–N потомков: копия + добавление самосгенерированного возмущения. (arXiv)
Селекция: выбираем топ‑K по фитнесу (или более мягко: турнир/элитизм), получаем следующее поколение. (arXiv)
Ключевой эффект: популяция сама начинает регулировать «силу тряски» — в статье отмечено, что вариативность падает, когда найдено хорошее решение (эксплуатация), и остаётся выше на ранних этапах (поиск) без внешнего расписания. (arXiv)
4.3. Псевдокод (для закрепления)
P = init_population(N) # популяция гиперсетей
for gen in 1..G:
C = # кандидаты (родители + потомки)
for h in P:
# 1) делаем потомков
for i in 1..offspring_per_parent:
child = copy(h)
delta = h.stochastic_self_update(graph_of(h)) # шум/апдейты, сгенерированные самим h
child.params += delta
C.append(child)
C.append(h)2) оцениваем всех
for h in C:
w_policy = h.det_generate(policy_graph)
h.fitness = rollout(env, w_policy, seeds, episodes)3) селекция
P = select_top_k(C, K)
(Подробности про то, что именно предсказывается стохастической веткой и как устроена узло‑специфичная интенсивность мутации, см. описание в arXiv‑версии; в частности, используется генерация σ и масштабирование “mutation rate” на узлах. (arXiv))
4.4. Инженерные правила сборки (то, что обычно ломает внедрение)
Версионируйте среду и интерфейсы. Если “среда поменялась”, это должно быть выражено в конфиге/версии, иначе вы смешаете фитнесы из разных миров и селекция станет шумом.
Делайте реплей и воспроизводимость. Логи: seed’ы, конфиги, распределение фитнеса, параметры шума/вариативности, идентификатор “чемпиона”, lineage (кто чей потомок).
Ограничьте онлайн‑самоизменение в проде. Практика: адаптацию гонять в песочнице/канареечном контуре и «поднимать» нового чемпиона только после регрессионного набора тестов (см. чек‑лист ниже).
Сразу проектируйте параллелизм. ES‑подходы масштабируются воркерами; Self‑Referential GHN тоже выигрывает от параллельной оценки популяции. (arXiv)
ML.2:5 - Archetypal Grounding — два примера, чтобы “схватить” идею
Суть (Tell): мы превращаем «оператор мутации» из внешней эвристики в часть модели. Тогда селекция начинает оптимизировать не только поведение в задаче, но и способ изменения самой модели под контекст.
Пример как система (Show #1):
Представьте контроллер для робота/дрона/манипулятора, у которого периодически меняются условия: нагрузка, трение, задержки, инверсия оси управления (условно “перепутали полярность”). Вам нужна схема, которая:
быстро перестраивает управление без дифференцирования по физике,
умеет «снизить хаос», когда снова стало стабильно,
не требует ручного тюнинга шага мутации под каждый сценарий.
Self‑Referential GHN как раз демонстрируется на задачах с резкими переключениями условий, где популяция восстанавливает качество за несколько поколений. (arXiv)
Пример как эпистема/метод (Show #2):
Вы строите AutoML/контур оптимизации, где вместо фиксированного “оптимизатора гиперпараметров” хотите, чтобы система сама выучила стратегию исследования (когда агрессивно искать, когда стабилизироваться). Это родственно:
learned optimizers (оптимизатор как обучаемая модель), (arXiv)
популяционным схемам, которые учат расписания гиперпараметров (PBT), (arXiv)
и open‑ended подходам, где важен перенос решений между меняющимися задачами (POET). (arXiv)
Разница тут в том, что «правила вариативности» кодируются внутри самой гиперсети и подпадают под отбор. (arXiv)
ML.2:6 - Bias-Annotation — где вас может обмануть результат
Байас бенчмарков: “Switch‑среды” могут быть проще реальных сдвигов (в реальности часто медленный дрейф + редкие скачки). (arXiv)
Байас вычислительного бюджета: если у вас меньше воркеров/эпизодов, селекция становится шумной, «саморегуляция вариативности» может не проявиться.
Байас по seed’ам: эволюционные методы чувствительны к шуму оценок; без мультисидов и усреднения вы будете видеть “ложные чемпионы”.
Байас индуктивной структуры: графовое представление архитектуры задаёт, где именно модель может «умно» дифференцировать мутации; при плохом граф‑энкодинге получите почти случайный поиск. (OpenReview)
ML.2:7 - Conformance Checklist — что должно быть выполнено
Определён контракт среды: что считается «сменой условий», какие параметры среды/симулятора логируются и сравниваются.
Есть воспроизводимость оценки: фиксируем seed’ы, набор эпизодов/сценариев, версию среды, версии кода/модели.
Фитнес устойчив: используете либо несколько эпизодов на индивида, либо повторную оценку для топ‑кандидатов (re‑eval), либо бутстрэп/медиану.
Явно ограничена вариативность: есть верхние границы на шум/дельты, есть аварийный “стоп” при деградации.
Разделены контуры: (а) поиск/адаптация, (б) промоутинг в эксплуатацию. В релиз попадает только проверенный «чемпион».
Линейдж и откат: вы можете ответить “из каких родителей получился этот кандидат” и быстро откатиться на стабильного предка.
Мониторинг популяции: трекаете распределение фитнеса и показатель “разброса” (вариативности) — иначе вы не заметите коллапс в один клон.
Параллелизм не меняет смысл: увеличение воркеров должно давать ускорение, а не менять поведение из-за гонок/асинхронных багов (особенно если делаете асинхронную селекцию).
ML.2:8 - Common Anti-Patterns That Break It — типовые способы сломать паттерн
“Запустим эволюцию прямо в проде без предохранителей.” Итог: дрейф качества, необъяснимые регрессии, невозможность расследования.
Оценка на одном эпизоде. Шум доминирует, селекция выбирает lucky‑run.
Смешивание разных конфигов среды в одной популяции. Фитнесы становятся несравнимы → вы отбираете мусор.
Внешний фиксированный шаг мутации “поверх” саморегуляции. Вы забиваете сигнал отбора: модель не может “научиться трястись” в нужные моменты.
Никакого учёта структуры. Если вы подали неверный граф или упростили до “вектор весов”, вы возвращаетесь к слепому шуму, теряя главную идею GHN. (OpenReview)
Нет чётких ограничений по бюджету. Эволюция легко «съедает» весь compute, если не поставить лимиты на поколения/эпизоды/воркеры.
ML.2:9 - Consequences — что получите и чем заплатите
Что выигрываете:
Быстрая адаптация к нестационарности (показано на Switch‑задачах). (arXiv)
Производная не нужна: можно оптимизировать недифференцируемые элементы, дискретные архитектуры, “симулятор как чёрный ящик”. (arXiv)
Самонастройка интенсивности поиска: вариативность может снижаться, когда найдено хорошее семейство решений, и снова расти при необходимости — без внешнего расписания. (arXiv)
Цена/риски:
Высокая стоимость оценок: это всё равно популяционный метод; выгоден при хорошей параллелизации. (arXiv)
Сложнее дебажить: у вас одновременно эволюционирует “как действовать” и “как изменяться”.
Риск неконтролируемого дрейфа, если не построить guardrails (лимиты, тесты, промоутинг через гейт).
Инженерная сложность граф‑представления и корректного соответствия “узлы ↔ параметры”.
ML.2:10 - Rationale — почему механизм даёт эффект
В классической схеме вы фиксируете оператор мутации/наследования и оптимизируете только поведение модели. Здесь вы делаете шаг в сторону “оптимизировать оптимизатор”: способность менять себя становится частью модели и попадает под отбор — ровно то, что давно делается в learned optimizers, но в другом форм‑факторе. (arXiv)
Дополнительный усилитель — графовая осмысленность: GHN видит структуру архитектуры, поэтому вариативность можно распределять по узлам/блокам, а не шуметь равномерно по всему вектору весов. (OpenReview)
ML.2:11 - SoTA-Echoing — связь с современной линией работ (2016+)
Graph HyperNetworks (2018): GHN как быстрый генератор весов по вычислительному графу, изначально для удешевления NAS. ML.2 использует тот же “graph‑aware weight generation”, но замыкает петлю на саму гиперсеть. (OpenReview)
Evolution Strategies в RL (2017): масштабируемая производно‑свободная оптимизация, хорошо ложится на параллельные воркеры. ML.2 остаётся в этой семье, но делает вариативность эндогенной (встроенной). (arXiv)
CMA‑ES (tutorial 2016) как представитель “умных” внешних стратегий; в обзоре к статье подчёркивается сравнение с CMA‑ES/OpenES на нестационарности. (arXiv)
Population Based Training (2017): популяция + автоматическое расписание гиперпараметров. ML.2 похож духом (популяция как механизм адаптации), но переносит “расписание” на уровень самой модели (через само‑мутацию). (arXiv)
Self‑reference линия (2018–2024): Neural Network Quine (2018), SRWM (2022), SeRANN (2024) — разные способы сделать модель самореферентной/самоизменяющейся. ML.2 добавляет масштабируемость через GHN‑подход и убирает градиентные апдейты из самого эволюционного цикла. (arXiv)
POET (2019): акцент на смене задач и переносе решений. ML.2 логично комбинируется с такими постановками, потому что показывает сильную сторону именно в нестационарных режимах. (arXiv)
Контекст по гиперсетям в целом: обзорные работы по hypernetworks (2024). (Springer Link)
ML.2:12 - Relations — с чем хорошо сочетается в инженерном стеке
Детектор дрейфа/смены условий → переключение режима адаптации. (Если просадка качества/анализ телеметрии сигналит о смене, можно временно увеличить допустимую вариативность и расширить поиск.)
Canary/Shadow‑режимы для промоутинга чемпиона. Эволюция остаётся «внутри», но выпуск наружу делается как обычный релиз.
Портфель решений вместо одного. Храните несколько топ‑индивидов под разные «режимы среды» и быстро переключайтесь.
PBT‑подходы и многокритериальные селекторы. Можно селектировать не только по среднему фитнесу, но и по риску/вариативности/стабильности.
ML.2:End
Нумерация разделов паттерна в этом примере правильная, отражает мою войну за управление конфигурацией FPF и дружественность к RAG, это я делал как раз на прошлой неделе. Вот примерно такие паттерны будут генерироваться для second и third principles frameworks. На выходе рабочие стандарты мышления и действия: зачем, что, как, почему, что проверять, какие ошибки лучше бы не делать. Это уже сегодня ещё в 2025 году!
И где же в инженерном паттерне слово “evolvability”?
По-русски “evolvability” - это эволюционируемость. Слово появляется в паттерне тут: “Идея в одной фразе: вместо того чтобы держать «мутацию» снаружи, мы делаем так, чтобы модель сама генерировала свои вариации и тем самым “училась быть эволюционируемой””. Ну, переводчикам трудно, я это знаю! По-английски термин проскакивал в thinking:
Clarifying design and considerationsОчень полезно читать thinking, ибо в итоговом названии вместо “гиперсети, которая мутирует сама себя” оказалось таки более заумная “самореференция” (это ж вывод “для исследователей”!): “ML.2 - Самореферентная GHN: встроенная «эволюция» для быстрой адаптации в меняющейся среде”.
In Ant-v5, emergent gaits and decreasing variation suggest evolvability. We may open the PDF for more details, like the algorithm and hyperparameters, but the HTML info might suffice. We’ll focus on creating a design recipe, avoiding over-specification. I’ll keep E.TGA and OEE in mind, especially understanding OEE’s relation without directly repeating provisions.
…
Planning pattern content and title for self-evolving hypernetworks
We have key lines describing adjustable mutation rates and the evolutionary loop. Now, we need to integrate the idea that “evolvability emerges” from the algorithm. I’ll cite the relevant arxiv abstract lines. For the pattern name, we could go with “ML.2 - Self-Referential GHN” or adapt it to Russian: “Гиперсеть, которая мутирует сама себя”.
Важный сдвиг в статье не в том, что “эволюция и эволюционируемость стали нейросетевыми”, а в том, что внутрь индивида перенесён механизм порождения вариаций и управления их величиной — параметры мутаций становятся наследуемыми и подлежат отбору. Поэтому evolvability здесь можно назвать и характеристикой системы (снаружи), и навыком (изнутри): тип зависит от того, кто агент изменений и где расположен контур управления изменениями.
Какой же “истинный” вид/тип/класс у evolvability? Такого нет: мы тут налетаем на “пограничное явление” (писал в “Границы в эпоху LLM: распаковка контрактов сигнатур и прочих интерфейсов для машин и людей”, Границы в эпоху LLM: распаковка контрактов сигнатур и прочих интерфейсов для машин и людей: ailev — ЖЖ и о дисциплине слотов в lytdybr: ailev — ЖЖ).
Если ребёнок завязывает шнурки, то взгляд взрослого на это снаружи – “свойство/признак/возможность/property/trait/capacity” ребёнка относительно класса вмешательств, но не skill. А вот если агент вмешательств внутри (сам ребёнок!), то это его умение/навык/мастерство/skill. Поэтому “можно и так, и так”, как всегда с приграничными понятиями, где есть несколько roles и их viewpoints с разных сторон границы, термины надо “распаковывать”, уточнять не “определениями” (единственное view), а привязкой к ситуации. “Определения и единственная типизация – гробик для умершей мысли”.
