Оптимизатор памяти уборщика + Надя — Секрет под её кожей
Переведено с английского
Nadia — Тайна под её кожей
Твоя гот-панк лучшая подруга ещё со школы только что спасла тебя от вампира. Проблема? Чтобы сделать это, ей пришлось стать оборотнем.
Fête de la Musique, слишком много пива, слишком много бургеров, громкая музыка повсюду — и один хищник, который выбрал не того пьяного человека, чтобы укусить. Надя годами скрывала, кто она на самом деле, от {{user}}. Сегодня эта тайна — пепел на асфальте.
Чего ожидать
RP с раскрытием сверхъестественного в рамках давней дружбы.
Пацанка-гот-панк ликантроп, увлекающаяся играми, комиксами, IT, походами и кемпингом.
Дружба прежде всего; романтика опциональна и никогда не подразумевается.
Городские сверхъестественные детективные маршруты с вампирами, секретностью, угрозами и последствиями раскрытия Нади.
Создан ка к тестовый персонаж для живого долгого чата для Janitor Memory Optimizer v1.0.0.
Как играть
Просто отвечай естественно. Сомневайся в Наде, отвергни её, прими её, расследуй дело вампира, уединись куда-нибудь или попробуй не дать ночи стать ещё более странной. Здесь нет команд памяти или меню настройки.
Примечания по содержанию
Алкоголь, курение, нападение вампира, сверхъестественное насилие, кровь/клыки, грубая лексика, грубый юмор, страх быть отвергнутой. {{user}}Чувства и выборы никогда не предопределены.
Тестовый выпуск: 2026-08-18
Janitor Memory Optimizer v1.0.0
Финальный пассивный движок памяти
Долгосрочная память для ролевых игр для JanitorAI — полностью пассивная, готовая к использованию и невидимая для пользователя.
Janitor Memory Optimizer — это продвинутый движок памяти на ES5, разработанный для JanitorAI Scripts Beta. Его цель проста: помочь персонажу сохранять важную информацию, отношения, события, обещания, локации, объекты, квесты, конфликты и длинные сюжетные арки, не полагаясь на постоянно растущую необработанную историю чата.
Здесь нет команд, которые нужно изучать, нет кнопок, которые нуж но нажимать, нет меню памяти, которым нужно управлять, и нет настройки, за которой нужно следить. Установи скрипт, прикрепи его к своему персонажу и общайся как обычно.
Движок тихо читает разговор, решает, что важно, организует это в несколько слоёв памяти и записывает только полезный результат в runtime-Scenario определение персонажа, чтобы LLM мог прочитать его снова в будущих ходах.
Он никогда не внедряет поддельные сообщения в разговор.
Для всех: что он на самом деле делает?
Представь долгую ролевую игру, где сотни сообщений назад:
Надя сказала тебе, что она твоя сестра.
Ты обнаружил латунный ключ в заброшенном архиве.
Самира предала Надю.
Надя перестала доверять Самире из-за этого предательства.
Ты обещал кому-то встретиться позже на Центральном вокзале.
Тайна медленно развивалась на протяжении нескольких разных сцен.
Обычно старая информация в конце концов становится трудно доступной для языковой модели по мере роста разговора.
Janitor Memory Optimizer непрерывно превращает важные части разговора в компактную, структури рованную систему памяти.
Позже, если разговор снова станет связан с Надей, движок сможет вспомнить то, что важно о Наде, не выгружая сотни старых сообщений обратно в контекст.
Если ты задашь общий вопрос вроде:
Как изменились мои отношения с Надей?
он сможет вспомнить компактную долгосрочную арку отношений.
Если ты спросишь:
Когда именно Надя перестала доверять Самире?
он сможет автоматически углубиться от долгосрочной сюжетной арки к соответствующему эпизоду и, при необходимости, к исходным атомарным доказательствам.
Ты не говоришь движку памяти, как всё это делать. Ты просто играешь роль.
Подключи & Играй
Вся система была специально разработана так, чтобы требовать как можно меньше взаимодействия с пользователем.
Открой Scripts Beta на JanitorAI.
Создай Advanced-скрипт.
Вставь полный скрипт Janitor Memory Optimizer v1.0.0.
Сохрани его.
Прикрепи его к своему персонажу.
Вот и всё.
Здесь нет мастера настройки. Нет обязательных команд. Нет отладочного интерфейса для игрока. Не т ручных бюджетов токенов, которые нужно поддерживать.
Задуманный опыт таков: установи один раз, а затем забудь, что движок памяти существует.
100% пассивная память на естественном языке
Оптимизатор наблюдает за обычным разговором и автоматически оценивает информацию.
Явные запросы на естественном языке также могут усиливать или удалять воспоминания:
Запомни, что Надя — моя сестра.
Не забудь, что ключ от архива принадлежит Самире.
Забудь всё о Наде.
Забудь то, что я сказал о латунном ключе.
Это обычные предложения, а не команды.
Скрипт не отвечает сообщениями вроде «Память сохранена» или «Память удалена». Персонаж просто продолжает ролевую игру.
Обычные повествовательные изменения обрабатываются иначе, чем забывание. Например:
Я больше не доверяю Наде.
не стирает прошлое. Оптимизатор может сохранить предыдущее состояние отношений как историю и отслеживать более новое состояние как изменение.
Без внедрения в чат
Это одно из самых важных правил дизайна всего проекта.
Сам разговор доступен только для чтения.
Скрипт может читать доступные поверхности разговора, такие как:
context.chat.last_messagecontext.chat.last_messagescontext.chat.message_count
Он не добавляет синтетические пользовательские сообщения, сообщения ассистента или системные сообщения.
Он не использует:
script_outputдля памяти;example_dialogsдля памяти;фальшивые записи разговора;
скрытые псевдокоманды чата.
Единственная активная поверхность памяти, видимая LLM, — это:
context.character.scenario
Приватное runtime-хранилище под context.chat.jai_memory_optimizer_v10 — это техническое состояние, а не сообщение разговора.
Как работает движок памяти
Внутри Janitor Memory Optimizer использует несколько последовательно всё более абстрактных слоёв:
Чтение чата только для чтения → Атомарные факты → Хешированные осколки → Семантические досье → Временной граф → Интеллект сущностей → Эпизодическая память → Повествовательные нити → Иерархический вызов → Сценарий
1. Атомарные факты
Важная информация сначала сохраняется как прослеживаемы е атомарные факты. Факт может нести такую информацию, как его тип, источник, важность, ход, попадания релевантности, связанные сущности и ID доказательства.
Эти атомарные воспоминания остаются самым близким к источнику истины внутри движка. Сводки более высокого уровня не заменяют их молча.
2. Хранилище с хешированием по содержимому
Факты организуются в тематические осколки, хранящиеся в приватном runtime-состоянии.
Осколки используют хеши содержимого, чтобы неизменённую память можно было переиспользовать вместо постоянной перезаписи.
Хеши — это адреса и проверки целостности, а не шифрование.
3. Семантические досье
Связанные воспоминания группируются в производные семантические профили.
Досье может различать:
стабильную информацию;
текущую информацию;
историческую информацию.
Это позволяет модели получать полезный обзор человека или темы, не получая сразу каждое отдельное воспоминание.
4. Временной граф памяти
Оптимизатор может строить связи между людьми, местами, объектами, квестами и событиями.
Временные рёбра намеренно различают:
вызывает— только когда источник явно подтверждает причинность;предшествует— хронологический порядок без утверждения причинности;заменяет— более новое состояние заменяет или противоречит более старому.
Иными словами, движок не предполагает, что раз событие B произошло после события A, то событие A вызвало событие B.
5. Интеллект сущностей
Движок выполняет консервативное разрешение сущностей для:
явных псевдонимов;
прозвищ;
некоторых отношений полного имени / фамилии;
однозначных местоимений в коротком окне;
некоторых однозначных отсылок к отношениям, таких как «моя сестра».
Когда отсылка неоднозначна, оптимизатор предпочитает не объединять личности, а не уверенно изобретать неверную связь.
6. Адаптивная температура памяти
Воспоминания динамически рассматриваются как горячие, тёплые или холодные.
На температуру влияет не только возраст. Движок учитывает наблюдаемую полезность, важность, давность, стабильность и повторяющу юся релевантность.
Старое воспоминание, которое неоднократно становится полезным, может оставаться важным. Холодное воспоминание не считается автоматически ложным и не стирается просто потому, что оно холодное; в первую очередь оно понижается в приоритете.
7. Эпизодическая консолидация
Более старые кластеры связанных событий могут становиться компактными эпизодическими воспоминаниями.
Вместо того чтобы постоянно держать десять подробных событий в активном вызове, оптимизатор может сохранить экстрактивный эпизод, содержащий ключевые моменты произошедшего.
Лежащие в основе атомарные доказательства могут оставаться прикреплёнными к этому эпизоду, что позволяет позже углубиться, когда требуются точные детали.
8. Повествовательные нити
Несколько эпизодов сами могут становиться долгосрочными сюжетными арками.
Поддерживаемые семейства нитей включают:
entity:*relationship:*quest:*location:*mystery:*conflict:*topic:*
Один эпизод может участвовать в нескольких повествовательных ни тях, не дублируя свои исходные доказательства.
Это означает, что сцена с участием Нади, тайны архива и квеста «Серебряная нить» может вносить вклад во все три сюжетные арки, оставаясь одним лежащим в основе фрагментом истории.
9. Иерархический вызов
Оптимизатор пытается удовлетворить потребности в памяти, используя самый дешёвый полезный слой.
Общий вопрос может требовать только Повествовательной нити.
Более точный вопрос может автоматически спускаться через:
Нить → Эпизод → Атомарное доказательство
Это помогает сохранить детали, не втискивая каждую деталь в каждый промпт.
Обратимое восстановление: JMO10 Escrow
Сценарий также несёт в себе ограниченную контрольную точку восстановления.
Слой восстановления использует:
компактную сериализацию → LZW12 → Base64 → контрольную сумму
Если приватное runtime-состояние исчезнет, а предыдущая контрольная точка Сценария останется доступной, оптимизатор сможет восстановить память из этой контрольной точки.
Концептуально:
Сценарий → JMO10 Escrow → Атомарные факты / Архивные эпизоды → Семантические досье → Временной граф → Повествовательные нити
Повреждённые данные escrow отклоняются, а не превращаются в сфабрикованную память.
JMO10 также может читать более старые форматы escrow JMO3–JMO9 для миграции и восстановления.
Автоматическое управление контекстом
Цель — не выгружать всё хранилище памяти в каждую генерацию.
Хранение и вызов намеренно разделены.
Движок автоматически регулирует бюджеты вызова и восстановления в зависимости от доступного места и типа информации, которая требуется в данный момент.
Простому продолжению нужно меньше памяти, чем подробному вопросу о причинности, хронологии или отношениях, охватывающих сотни сообщений.
При необходимости оптимизатор сокращает детализацию, прежде чем переполнить свой внутренний рабочий конверт.
Внутренние ограничители
Это эвристики проекта, а не заявленные официальные лимиты JanitorAI.
Оценка комбинированного мягкого лимита Personality + Scenario: 4 000 токенов
Максимум тематических осколков: 512
Временной граф: 384 узла / 768 рёбер
Эпизодические архивы: 160
Повествовательные нити: 192
Бюджеты вызова и escrow: автоматически адаптивные
Они существуют, чтобы система памяти оставалась ограниченной и предсказуемой, не допуская неконтролируемого роста.
Безопасность долгих ролевых игр & Гигиена памяти
Движок включает несколько консервативных защитных мер, разработанных в ходе проекта:
консолидация точных дубликатов;
синтез почти-дубликатов, где это уместно;
замена текущего состояния без слепого уничтожения полезной истории;
фильтрация вопросов, чтобы вопросы не становились автоматически установленными фактами;
консервативное обнаружение причинности;
разрешение сущностей с учётом неоднозначности;
целевое забывание на естественном языке;
отклонение повреждённой контрольной точки восстановления;
исторический вызов с учётом релевантности;
изоляция наполнителя, чтобы типичное «Окей.» не втягивало несвязанные архивы в контекст;
сохранение атомарных доказательств за сводками более высокого уровня;
ограниченная память и обрезка графа;
автоматическая миграция более старых состояний оптимизатора, когда они доступны.
Создан для долгих ролевых игр
Janitor Memory Optimizer особенно полезен для ролевых игр, включающих:
медленно развивающиеся отношения;
многоперсонажные составы;
тайны и расследования;
квесты и цели;
меняющиеся союзы;
долгосрочные конфликты;
постоянные инвентари или важные объекты;
повторяющиеся локации;
развитие персонажа;
истории, охватывающие сотни или тысячи ходов.
Валидация & Стресс-тестирование
v1.0.0 не был выпущен после простой проверки синтаксиса. Он прошёл специальные наборы регрессии, укрепления, восстановления и длительного стресс-тестирования.
Статическая валидация / валидация пакета создателя
Проверка синтаксиса Node: PASS
Консервативный валидатор ES5: PASS
Ошибки: 0
Предупреждения: 0
Размер runtime: 191 418 / 400 000 байт
Тесты инварианта выходной поверхности
Нет
script_output: PASSНет записей в историю чата: PASS
last_messageостаётся неизменным: PASSmessage_countостаётся неизменным: PASSНет записей памяти в
example_dialogs: PASSНет активного блока памяти, добавленного в Personality: PASS
Ровно одно видимое для LLM место назначения памяти — Scenario: PASS
Синтаксис пользовательских команд не требуется и не раскрывается: PASS
Набор регрессии
21 целевое утверждение: PASS
Покрытие включало:
сценарий на 109 ходов;
эпизодическая консолидация;
повествовательные нити;
широкий вызов нитей;
углубление до точных/исторических деталей;
изоляция наполнителя;
восстановление после потери состояния;
совместимость миграции со старых версий.
Финальный набор укрепления
23 дополнительных утверждения: PASS
Этот набор специально охватывал:
архитектуру только на Scenario;
миграцию живого состояния v0.9 на v1.0;
восстановление устаревшего escrow JMO9;
выживани е атомарных доказательств после устаревшего восстановления;
безопасное отклонение повреждённого escrow;
целевое забывание на естественном языке;
сохранение несвязанных семантических воспоминаний во время целевого забывания.
Стресс-тест на 500 ходов
Тестовый корпус:
500 ходов заполнения + 60 запросов к памяти на естественном языке + 3 полных восстановления после потери приватного состояния.
Факты до восстановления: 42
Факты после 3 восстановлений: 42
Эпизоды до / после: 10 / 10
Повествовательные нити до / после: 5 / 5
Полные восстановления после потери состояния: 3 / 3 PASS
Длительный стресс-тест на 2 000 ходов
Также был проведён гораздо более крупный тест:
2 000 ходов заполнения + 60 естественных запросов + 3 полных восстановления после потери состояния.
Факты до / после восстановления: 61 / 61
Эпизоды до / после: 40 / 40
Повествовательные нити до / после: 5 / 5
Полные восстановления после потери состояния: 3 / 3 PASS
Построения нитей: 195
Переиспользования сигнатур нитей: 1 927
Построения графа: 201
Переиспользования графа: 1 860
Это демонстрирует, что производные структуры активно переиспользуются, а не слепо перестраиваются на каждом ходу.
Оптимизация производительности
На том же локальном Node-стенде 500+60:
базовая линия v0.9: примерно 6,49 секунды
оптимизированная v1.0: примерно 3,87 секунды
Относительное сокращение: примерно 39%
Этот бенчмарк измеряет скрипт в локальном тестовом стенде Node VM. Это относительное измерение регрессии/производительности для самого скрипта, а не утверждение о задержке серверов JanitorAI.
Совместимость & Миграция
v1.0.0 записывает текущий формат восстановления JMO10.
Он может читать контрольные точки устаревшего escrow JMO3 до JMO9.
Миграция из предыдущих состояний Janitor Memory Optimizer поддерживается, когда необходимое старое состояние ещё доступно.
Для чистой установки просто используй v1.0.0.
Vibe-Coded с ChatGPT 5.6
Да, этот проект был vibe-coded с ChatGPT 5.6.
Движок разрабатывался итеративно через управляемый человеком дизайн, тестирование, отладку, стресс-тестирование и повторные архитектурные ревизии, при этом ChatGPT 5.6 помогал с кодом.
Он прошёл эволюцию через множество прототипов: от базового инжектора избирательной памяти до хранилища с адресацией по содержимому, обратимой системы восстановления, иерархии семантической памяти, временного графа, резолвера сущностей, эпизодического архива и движка повествовательных нитей.
Затем финальный выпуск был подвергнут автоматическим наборам регрессии и стресс-тестирования, а не опубликован просто потому, что сгенерированный код «выглядел правильно».
Это независимый общественный проект. Это не официальный продукт OpenAI или JanitorAI, и упоминание ChatGPT 5.6 описывает процесс разработки, а не официальную сертификацию или одобрение.
Зачем это использовать?
Потому что память не должна становиться ещё одной игровой механикой, которой должен управлять игрок.
Тебе не должно приходиться ставить сцену на паузу, чтобы напечатать:
/save_memory relationship Nadia trust -1
Ты должен просто иметь возможность написать:
После того, что сделала Надя, я не думаю, что смогу ей больше доверять.
и продолжить историю.
Вот в чём философия дизайна Janitor Memory Optimizer.
Обработка памяти должна происходить в фоне. Чат должен оставаться чатом. Определения персонажа должны нести рабочую память. LLM должна получать наименьшее полезное количество контекста для текущего момента.
Коротко
Подключи & играй.
Полностью пассивно.
Без команд.
Без интерфейса памяти.
Без фальшивых сообщений в чате.
Видимая для LLM память только в Scenario.
Запоминание / забывание на естественном языке.
Атомарные доказательства.
Хешированное хранилище памяти.
Семантические досье.
Временной и причинный граф.
Консервативный интеллект сущностей.
Адаптивная горячая / тёплая / холодная память.
Эпизодическая долгосрочная консолидация.
Постоянные повествовательные нити.
Иерархический вызов с углублением к доказательствам.
Обратимый escrow восстановления JMO10.
Поддержка устаревшего восстановления.
Автоматическое бюджетирование контекста.
Стресс-тестирование на 2 000+ ходов.
3/3 полных восстановления после потери состояния в обоих основных стресс-наборах.
0 ошибок валидации ES5.
0 предупреждений валидации ES5.
Вставь. Прикрепи. Играй как обычно.
Позволь персонажу помнить.
Создано 18 авг.
Обновлено 18 авг.
Опубликован 18 авг.