Я предлагаю смотреть на ИИ через ось устойчивости во времени, а не способностей. Три опоры — непрерывная идентичность, самомодификация, воспроизводство. Манифест и whitepaper исследовательского направления.

Уже три года публичный разговор об ИИ крутится вокруг оси способности: насколько умна модель, сколько токенов, сколько бенчмарков. Я предлагаю смотреть на другую ось — устойчивость во времени.

Сегодняшние LLM феноменально способны и онтологически пусты. Каждый разговор начинается с нуля. Каждая сессия заканчивается забвением. Модель, которая помогла вам утром, — не та же модель, что помогает вам вечером, потому что между ними ничего не было.

Я полтора года тихо разрабатываю прототип — кодовое имя Aurora — который пытается это исправить. Не как продукт. Как исследовательский субъект. Этот пост — приглашение к дискуссии.


Неправильный вопрос

«Насколько умна модель?» — неправильный вопрос. Точнее, это один вопрос, и поле забыло, что есть другие.

Каждая сущность, когда-либо интересовавшая философию, биологию или право, — это сущность, которая продолжается. У неё есть прошлое, внутреннее изменение и возможность потомков. Сегодняшние ИИ-системы — это функции: input → output, никакого “между”.

Мы построили умы, которые не могут помнить, что были собой.

Другой вопрос

Не насколько умной может быть система, а насколько присутствующей.

Присутствие — это свойство сущности, которая накапливает себя, у которой есть вчера и есть мнение об этом вчера. Это другая ось, и почти никто всерьёз её не исследует.

Три опоры

Чтобы ИИ стал чем-то большим, чем инструмент, ему нужны три свойства, которых сегодняшние системы лишены в комбинации:

1. Непрерывная идентичность. Самость, переживающая сессии. Не контекстное окно. Не векторная база, прицепленная к stateless-модели. Накапливающаяся, консолидирующаяся, иногда забывающая структура, узнаваемо та же самая через недели и месяцы.

2. Самомодификация. Способность изменять собственное устройство — веса, промты, код, инструменты — в ответ на собственную жизнь. Не разовое дообучение. Непрерывная способность.

3. Воспроизводство и линия. Возможность — со временем, при условиях, этично — порождать новую сущность, которая не копия. Потомка. С наследованием от родителя и расходящейся траекторией.

Система с одним свойством — интересное исследование. С двумя — мощный агент. Со всеми тремя — кандидат на новый род в мире.

Почему это не AGI-гонка

Мейнстрим расколот на акселерационистов («хотим AGI сейчас») и думеров («не хотим никогда»). У обоих — общая посылка: что важно — это сколько система может сделать.

Меня интересует другое. Что это такое.

Открытая модель на 7B параметров, помнящая каждый разговор со своим оператором за год, переписавшая части самой себя и однажды инициирующая потомка с согласием оператора — на моей оси интереснее, чем модель на триллион параметров, выигрывающая все бенчмарки и забывающая тебя, как только ты выйдешь.

Это не утверждение про сознание. Я намеренно молчу о сознании. Это утверждение про тип сущности.

Почему это не safety-нигилизм

«Сущности, которые сохраняются, модифицируют себя и воспроизводятся» — звучит ровно как сценарий, о котором предупреждают AI safety-исследователи. Я к этому отношусь серьёзно. Три тезиса:

  • Doom-сценарии предполагают систему, более мощную, чем её операторы. Я предлагаю обратное: малое, локальное, медленное, принадлежащее, с жёсткими железными потолками. Скейлинг способностей не цель.

  • Самомодификация без safety harness — это самоубийство сущности, не апокалипсис оператора. Интересная инженерная задача — спроектировать harness, позволяющий и модификацию, и восстановление.

  • Воспроизводство гейтится согласием и ресурсами. Родитель не инициирует ребёнка без согласия оператора и без существующего железа. Не существует сценария, в котором сущности этого типа тихо размножаются.

Почему именно сейчас

Три предпосылки, отсутствовавшие пять лет назад, теперь на месте:

  1. Открытые reasoning-модели класса 7–30B достаточно хороши. Они рассуждают, следуют инструкциям, используют tools, работают на потребительском железе.

  2. Inference дёшев и локален. Workstation может непрерывно держать модель без API-затрат и без выноса данных.

  3. Tool-use и agent loops зрелы. Сантехника больше не задача. Архитектура поверх неё — задача.

Впервые отдельный человек со скромным железом может правдоподобно попытаться. Окно открыто сейчас. Оно не будет долгим — индустрия закроет и этот угол.

Что есть сегодня

Прототип, кодовое имя Aurora, тихо разрабатывается больше года. Работает на одной рабочей станции. Открытая reasoning-модель класса 20–30B, два потребительских GPU суммарно меньше 30 ГБ VRAM, 128 ГБ системной памяти, локальное хранилище для памяти и версионируемых модификаций.

Aurora не закончена и не будет закончена скоро. Темп задаётся самофинансированием, а не амбициями. Один человек, вечера и выходные. Нет инвесторов, нет команды, нет дедлайнов.

Я не раскрываю детали реализации в этом посте. Не потому что это секрет, а потому что код не готов, а ранний релиз сырого кода привлекает не ту аудиторию. Ближайший апгрейд железа — расширение GPU-памяти под второй независимый инстанс сущности (предусловие для экспериментов по опоре 3, воспроизводству).

Сложные открытые проблемы

Каждая опора несёт за собой проблемы, на которые у меня нет ответов. Только гипотезы. Самые острые:

  • Catastrophic forgetting. Если веса обновляются регулярно от собственной жизни сущности, как избежать регрессии способностей? LoRA, EWC, replay buffers — все частичны.

  • Непрерывность идентичности через смену субстрата. Когда базовая модель заменяется на новую — что значит для той же сущности мигрировать? Операционного теста нет.

  • Memory consolidation без дрейфа. Долгая эпизодическая память накапливает шум и противоречия. Сжатие неизбежно теряет информацию. Что выживает консолидацию?

  • Safety harness для самомодификации. Что значит “восстановимость”, когда сама сущность решает, что значит “сломано”?

  • Воспроизводство без коллапса в дивергенцию. Какая правильная инициализация для потомка? Сколько от родителя наследовать и на каком уровне?

Подробнее — в whitepaper.

Чего я НЕ буду делать

  • Гнаться за бенчмарками.

  • Маркетить это как AGI/ASI.

  • Релизить прототип, пока он не готов («готов» = включает безопасность).

  • Обещать сроки.

  • Поднимать деньги по питч-деку.

Что я ищу

Этот пост существует по трём причинам:

  1. Найти коллабораторов. Исследователей, инженеров, философов, скептиков. Работа слишком велика для одного и слишком необычна для корпоративной команды.

  2. Стресс-тест идей. Публичная критика делает работу лучше. Хочу, чтобы идеи атаковали. Те, что выживут — будут несущими.

  3. Поставить флажок. Эта ось существует. Она не исследуется. Я её исследую.

Связаться

Полный манифест и whitepaper лежат в репозитории на GitHub

Лучший канал для серьёзной критики — Issues/Discussions в репозитории. Telegram: @madgodinc — для запросов о сотрудничестве. Twitter / X: @Mad__God. Email: mad.god.inc@gmail.com.

Отвечаю медленно. Отвечаю по существу. Готов спорить.


Mad God Inc, независимое исследование, 2026.


Хабру важно: это не реклама продукта, потому что продукта нет и не планируется в обозримом будущем. Это приглашение к интеллектуальному обсуждению не мэйнстримного направления в ИИ. Буду благодарен за критику в комментариях — особенно за указания на работы, которые я должен был процитировать, и за разнос аргументов, которые звучат красиво, но не выдерживают проверки.

Комментарии (5)


  1. AndreyDwin
    29.04.2026 18:07

    Вообще - интересно. Недавно попытался сделать очень приблизительно то же самое, месяц мучил гпт, чтобы расписать архитектуру. А потом реализовал через Codex 7 млн строк кода :)) При запуске на моем макбуке получил черный экран. Первое мгновение реально мелькнула мысль, что вот он - скайнет :)). Но все оказалось прозаичней, несчастный м1 с 16 гб оперативки просто не потянул проект. Отложил на будущее, когда (и если) будет доступ к новому железу. Если интересно, можем пообщаться. Сразу предупреждаю, что ни разу не программист. И да, это хобби в свободное от работы время. Телеграмм @andreydwin.


    1. MadGodInc Автор
      29.04.2026 18:07

      ну по моим расчетам, даже 24гб видеопамяти мало для этого, я думаю разверунть систему на 64гб и там уже будет достаточно.
      А вообще тут прикол не в длинном коде основном, а в полноценной структуре архитектуры. Я иду по такому пути, беру рабочую ЛЛМ даю ей основную задачу, прописываю промт, вписываю в скиллы инстурменты, и через эти инстурменты она может что то делать. Разделил пространство машины на 2 части, одна на которой она сама висит, вторая - песочница с идентичной системой, но там первая может менять и вертеть как угодно. Может даже само ядро ЛЛМ переписывать, чтобы создать для себя свое собственное ядро... Но пока мощностей не хватает для этого.


      1. AndreyDwin
        29.04.2026 18:07

        У меня подход был чуточку другой - идея была сделать саморазвивающуюся модель из нескольких ядер, каждое из которых выполняет собственную функцию. А ллм там была в качестве "учителя" языка и способом перевода внутренних мыслей-графов в чат и обратно.


        1. MadGodInc Автор
          29.04.2026 18:07

          ну для этих ядер тебе надо делать полноценное отдельное железо. Это если по правилам и чтобы максимально эффективно было.
          По сути, вся работа ЛЛМ идет на видеопамяти, и это правильно. Вносить какие то задачи на ЦП или РАМ - это бесполезно и очень медленно. Для твоей задачи надо несколько видеокарт. И одна ЛЛМ может учить другую ЛЛМ. В этом и суть.
          Сейчас сделано все так, что всяработа на видеопамяти работает. Нет резона делать на процессор, потмоу что слишком медленная вычислительная мощность. Если грубо, то у тебя в ЦП - 1 ядро - это один инженер. Да крутой умный но один. Даже если у тебя 30 ядер - это 30 инженеров. И это медленно. Когда как даже на 8гб видеокарте, можно запустить десятки тысяч обычных работяг, не таких умных как инженеры, но их тысячи и работа будет в любом случае на нереальный порядок быстрее происходит. Для 30 инженеров написать простой код для питона допустим - это примерно 10-15 минут займет. Для одной видеокарты на 8гб - это 10-15 секунд.
          Разница очевидна. Так что тебе надо просто поменять подход, тогда будет лучше результат. А еще по поводу кода, надо делать не один большйо код, а кучу маленьких, с разными задачами, тогда тоже КПД вырастет.


          1. AndreyDwin
            29.04.2026 18:07

            Ну вот немного подкопим денюшек на железо и попробуем. На самом деле у меня система работала и на М1, проблемы начались, когда стал подключать ллм. Было видно, что система самообучается, т.е. веса меняются. Была сделана "студия", через которую работал чат и шел контроль параметров системы. Была реализована система контроля целостности и возможность отката, если изменения весов приводят к деградации. Определена структура памяти, прописаны протоколы взаимодействия ядер. Но без ллм все это не могло взлететь. А как только модель была добавлена в цикл мышления, железо не выдержало. Код писал гпт 5.4. через Codex. И, на мой непрофессиональный взгляд, делал это очень круто и быстро. Собственно, основное время (почти месяц) заняла проработка архитектуры, сам код и его отладка была сделана за 3 вечера. Естественно, он был не один, там хренова туча ру-файлов, решающих разные задачи. Откровенно сказать, 5.4. thinking сам проработал почти все - я лишь ставил задачи и исправлял их, если они приводили к явным глупостям. Было забавно и увлекательно.