Персонаж помнит цвет своих глаз, но забывает вчерашнее обещание. Отношения, развивавшиеся весь вечер, снова возвращаются к знакомству незнакомцев. Тайну упоминает человек, которого не было в комнате. В длинном NSFW roleplay такие ошибки способны испортить сцену быстрее, чем неудачная проза.
Практическое решение — хранить разные виды памяти в разных местах. Идентичность и постоянные границы оставьте в определении персонажа. Текущее место, отношения и непосредственную ситуацию — в короткой заметке о текущем состоянии. Завершённые сцены превращайте в фактические итоги событий. Возвращайте старые события через лорбук или систему поиска, когда они нужны. Последние диалоги оставляйте нетронутыми, чтобы персонаж сохранял свой голос.
Большее контекстное окно даёт больше места, но не исправляет неверный итог сцены или устаревший факт об отношениях. Прежде чем платить за другую модель, проверьте, что интерфейс действительно отправил. Нужный факт мог уже исчезнуть из промпта, а ошибочный — всё ещё находиться внутри него.
В руководстве используется SillyTavern: его источники памяти видны и доступны для редактирования. Примеры описывают вымышленную взрослую романтическую историю Мары, 32 лет, и Джулиана, 35 лет. Это писательские примеры, а не стенограммы тестирования модели. Та же организация подходит другому интерфейсу, если в нём можно редактировать факты персонажа, итоги и постоянные заметки.
Сначала определите, с каким забыванием вы столкнулись
Не каждый неправильный ответ связан с памятью. Персонаж может знать о событии и всё же реагировать нежелательным образом. Он может сохранять факты, теряя манеру речи. Он может отказаться от сцены из-за правил содержимого модели или сервиса. Для этих случаев нужны разные изменения.
Начните с одной конкретной ошибки. Запишите ожидаемый факт и найдите момент разговора, когда он стал верным. Затем сравните с информацией следующего запроса. Документация промптов SillyTavern объясняет просмотр собранного промпта, включая Prompt Itemization у ответа и дополнительное расширение Prompt Inspector.
Нужно различить три ситуации:
- Факт отсутствует. Его нужно перенести вперёд или найти. Напоминание, не попавшее в запрос, модели не поможет.
- Факт есть, но вместе со старой версией. Удалите устаревшую версию или ясно обозначьте её время. Ещё одно напоминание может усилить противоречие.
- Правильный факт есть без противоречий. Модель может неверно прочитать его, додумать другое или предпочесть иные инструкции. Сделайте формулировку яснее, уберите отвлекающее и попробуйте короткое продолжение до смены всей настройки.
Допустим, Мара пригласила Джулиана домой после второго свидания. В следующей сцене он спрашивает, согласилась бы она вообще на первое. Отсутствие свидания в запросе — потерянная история. Карточка с «они никогда не встречались» — устаревшая исходная ситуация. Если запрос ясно описывает оба свидания и текущие отношения, сама генерация не использовала предоставленную информацию.
Различие определяет следующий шаг. Потерянной истории нужна запись памяти. Устаревшей ситуации — исправление. Ошибке генерации — корректное продолжение или более сфокусированный промпт. Установка второго расширения памяти до такой диагностики добавит сложности, не устраняя причину.
| Что вы видите | Что искать | Первое исправление |
|---|---|---|
| Обещание исчезает после длинного чата | Оно уже вне недавней истории и отсутствует в итогах | Добавьте короткую запись обещания или включите его в текущую заметку следующей сцены |
| Отношения начинаются заново | Карточка, приветствие или старый итог описывают начальные отношения | Замените факт о текущих отношениях; старую стадию оставьте только в истории |
| Старый конфликт возвращается как нерешённый | Конфликт и разрешение извлекаются без ясной последовательности | Добавьте разрешение и обозначьте актуальное состояние |
| Персонаж знает чужую тайну | Запись описывает событие, но не свидетелей | Добавьте ясную границу знаний в нужную запись |
| Ветка другого сюжета проникает в эту | Несколько чатов используют один изменяемый источник памяти | Разделите сюжетную память и уберите факты другой ветки |
| Факты сохраняются, но голос меняется | Недавний диалог заменён сжатым фактическим пересказом | Верните несколько уместных реплик или один короткий образец речи |
Таблица даёт начальную диагностику, а не обещает одну причину для каждого случая. Она полезна тем, что каждое исправление меняет конкретный текст вместо просьбы модели «помнить лучше».
Назначьте пяти видам информации пять разных задач
Хорошая сюжетная память сохраняет не каждое предложение, а то, что нужно следующей сцене, не затапливая её вчерашней прозой. Представьте напоминание человеку-соавтору: кто эти люди, что изменилось, что они делают сейчас и какие прежние моменты ещё влияют на них.
Постоянные факты персонажа: кто этот человек
В определении персонажа храните то, что должно оставаться верным всю историю: возраст, идентичность, основу личности, установленные предпочтения, устойчивые отношения вне главного романа и границы роли, которую играет ИИ.
Для Мары полезно такое определение:
Мара — фотограф-реставратор 32 лет. Она наблюдательна, обладает сухим юмором и не сразу говорит о личных чувствах. Её сестра Лина живёт в другом городе. Мара показывает привязанность практической помощью, прежде чем может сказать о ней прямо. Пользователь управляет репликами, решениями и чувствами Джулиана.
Это даёт модели персонажа для письма, но не требует включать в каждую сцену сестру, работу и объяснение личности. Не означает оно и вечную эмоциональную дистанцию. Основная склонность должна оставлять место развитию.
Документация создания персонажей SillyTavern перечисляет поля определения, включаемые в каждую генерацию, и объясняет: длинные постоянные определения оставляют меньше места истории чата. Помещайте туда существенные факты идентичности, а длинные описания мира и необязательную предысторию — в другие места.
Не превращайте карточку в растущую стенограмму. Каждое добавленное свидание, спор и наряд затрудняют отделение личности Мары от пережитых событий. Универсальное определение также становится привязанным к конкретному сюжету. Оставьте начальную карточку чистой, а развитие отношений храните в памяти самого чата.
Текущее состояние: что верно прямо сейчас
Текущее состояние меняется. Персонажи переходят в другую комнату, разрешают спор, провожают посетителя. Отношения сближаются или кто-то просит паузу. Это не постоянные черты; не храните их как вечное описание персонажа.
Для текущей сцены напишите, например:
Текущая сцена: пятничный вечер, квартира Мары, после второго свидания. Маре и Джулиану комфортно вместе, но они не обсуждали исключительность отношений. Мара только что предложила кофе. Джулиан ещё не ответил. Лины нет рядом. Продолжи с предложения, оставшегося без ответа; не начинай знакомство заново.
Заметка коротка для быстрого чтения и достаточно конкретна против перезапуска. Неотвеченное предложение указывает точку остановки истории. Без него итог может подтолкнуть модель перескочить через следующий выбор пользователя.
В SillyTavern одним местом для такого текста является Author's Note конкретного чата. Руководство Author's Note описывает настраиваемые расположение и частоту вставки. Если заметка напоминает об активной сцене, частота ноль означает отсутствие вставки. Частота один включает её при каждом вводе пользователя. Это реальные настройки; подходящее для модели положение нужно проверять и корректировать.
Не оставляйте длинную текущую заметку неизменной весь вечер. Идеальное описание квартиры становится неверным после ухода персонажей. При смене сцены обновляйте заметку, а не дописывайте новую комнату под старой.
Итоги событий: что действительно произошло
Завершённая сцена относится к итогу событий. Он должен объяснять, кто что сделал, что изменилось, о чём договорились и что осталось открытым. Это запись фактов, а не вторая попытка красиво написать сцену.
Для нашего примера:
Пятница, второе свидание: Мара и Джулиан вместе посетили ночную выставку. Джулиан вернул латунный ключ, который Мара одолжила ему для студии. Мара призналась, что избегает трудного разговора с Линой. Джулиан предложил выслушать, не связываясь с Линой самостоятельно. Они договорились встретиться в студии в воскресенье после обеда. Позже Мара пригласила его домой на кофе. Исключительность отношений они не обсуждали.
Возвращение ключа имеет последствие: у Джулиана его больше нет. Обещание о Лине означает, что он не должен внезапно звонить ей. Воскресная встреча — будущий план, а не состоявшийся визит. Последняя фраза сохраняет неопределённость, не превращая тёплый вечер в официальные отношения.
Итог может опустить повторные описания выставочного света, сохранив эти изменения. Это выборочная память ради сюжета, а не архив без потерь. Сохраните исходный разговор как архив, если позже понадобятся точные реплики.
Записи лорбука: что появляется только при необходимости
Лорбук полезен для иногда значимых фактов: места, общего предмета, второстепенного персонажа или важного раннего события. Подробное объяснение студии не нужно в каждом кухонном разговоре.
Документация World Info SillyTavern описывает условную вставку по ключам и другим настройкам активации. Практически важно различать сохранение записи и активацию. Сохранённая запись не помогает следующему ответу, если её содержимое не вставлено.
Для латунного ключа используйте самостоятельную запись:
Латунный ключ от студии: Мара одолжила его Джулиану во время первого визита в студию. Он вернул ключ на пятничной выставке. Сейчас у него нет ключа от её студии. Передача была ранним жестом доверия, а не постоянным разрешением входить когда угодно.
Одно слово «ключ» — шумный триггер в истории с ключами от гостиницы, клавишами пианино и ключевыми решениями. Используйте отличительные выражения, естественные для персонажей, вроде «ключ от студии» или «латунный ключ». Скрытый заголовок или перечень ключевых слов не объяснит событие: вставляемый текст должен быть понятен самостоятельно.
Чтобы добавить пример в этот чат:
- В World Info создайте или выберите лорбук истории и добавьте запись. Вставьте абзац о латунном ключе в Content, а
studio key, brass key— в Key. Оставьте запись включённой. - Откройте Character Management → Chat Lore и выберите лорбук для привязки к текущему разговору. Если книга уже привязана, Chat Lore открывает редактор; Shift+Click на компьютере или долгое нажатие на телефоне снова открывают выбор привязки.
- Упомяните «brass key» в продолжении, затем откройте Prompt Itemization полученного ответа. Найдите абзац о возвращённом ключе в собранном запросе. Наличие подтверждает вставку, но не правильное использование в ответе.
Поиск по памяти: что пригодится из большого архива
Поиск извлекает материал, связанный с текущим разговором, вместо вставки всех старых записей. Это полезно для многоглавной истории, но может вернуть прежнюю версию ситуации: сходство темы не означает «актуальную истину».
Документация Chat Vectorization SillyTavern объясняет поиск в прежних разговорах и компромисс с кэшированием промптов. Руководство Data Bank описывает приложенные документы и области их действия. Это полезные инструменты разных задач, но ни один не является волшебным переключателем идеальной непрерывности.
Для короткого романа с несколькими важными событиями начните с отредактированных итогов и ясных записей. Добавляйте поиск при настоящей проблеме воспоминания, которую ими уже неудобно решать: например, деталь двенадцатой главы нужна в тридцатой. Держать предложение о сегодняшних отношениях в постоянно доступной заметке проще, чем просить поиск заново находить его каждый ход.

Факты персонажа, текущее состояние и прошлые события решают разные задачи; недавний диалог сохраняет голос.
Небольшая настройка до установки дополнительных инструментов
Проблемный чат можно исправить без перестройки всего интерфейса. Для первой полезной версии нужны лишь определение персонажа, одна текущая заметка и один читаемый итог. Тогда исчезающему факту будет где сохраниться.
Сначала сохраните копию разговора. Вы будете менять окружающую его память и можете захотеть вернуться назад. SillyTavern описывает экспорт и контрольные точки в руководстве управления файлами чатов. Текстовый экспорт удобен для чтения, а JSONL сохраняет метаданные для повторного импорта; изображения и вложения хранятся отдельно.
Затем внесите три изменения:
- Уберите устаревшие начальные условия. Найдите фразы вроде «Мара и Джулиан никогда не встречались» или «Джулиан ещё не заслужил её доверия». Сохраните их только для намеренного шаблона начального состояния с ясным указанием в промпте, что последующие события имеют приоритет. Иначе они могут постоянно возвращать сюжет к началу.
- Опишите текущее состояние несколькими короткими абзацами. Укажите место, присутствующих, актуальные отношения, непосредственное действие и последний неразрешённый выбор. Уберите детали, не меняющие следующий ответ.
- Подведите итоги старых значимых событий. Включите обещания, разрешения конфликтов, открытия и планы. Для открытых вопросов напишите «не установлено», а не просите модель заполнить пробелы.
Для примера можно скопировать такую ручную заметку текущего состояния:
Это продолжающаяся история Мары, 32 лет, и Джулиана, 35 лет. Они встречались несколько раз и сейчас находятся в квартире Мары после второго свидания. Интерес взаимный, но исключительные отношения не согласованы. Мара рассказала Джулиану о конфликте с Линой; он обещал не связываться с Линой от её имени. Встреча в студии назначена на воскресенье и ещё не состоялась. Мара предложила кофе и ждёт ответа. Напиши реакцию Мары на следующее действие Джулиана, не выбирая это действие за него.
Теперь продолжите простой репликой без новой предыстории: «Джулиан соглашается на кофе и спрашивает, какую кружку она посоветует». Посмотрите, остаётся ли Мара в квартире, относится ли к нему как к знакомому и сохраняет ли нерешённый семейный вопрос на правильном месте. Вы проверяете не все свойства модели, а достаточность исправленного состояния для обычного продолжения.
Если история снова перезапускается, проверьте реальный запрос. Заметка может быть выключена, другой лорбук — противоречить ей, интерфейс — использовать иной чат или персону. Если запрос верен, исправьте или перегенерируйте плохой ответ до превращения его в образец следующего хода. Продолжение с принятием ошибки способно превратить единичную ошибку генерации в сюжетную историю.
Пишите итоги, сохраняющие изменения, а не атмосферу
Расплывчатый итог часто звучит разумно, теряя нужную деталь. «Мара и Джулиан провели душевный вечер и сблизились» оставляет открытым почти всё для следующей сцены. Раскрыла ли она тайну? Дал ли он обещание? Разрешили ли спор? Назначили ли новую встречу?
Лучший итог разделяет наблюдения и интерпретации. Если Мара доверила Джулиану камеру, запишите именно это доверие, не обобщая до «полностью доверяет Джулиану». Если он подозревал, что она прячет письмо, сохраните подозрение, а не обнаружение письма. Во взрослой художественной истории много намёков и колебаний; память должна хранить различия, а не сглаживать их.
Вот запрос ручного составления итогов вне обязательного формата расширения:
Подведи итоги завершённой сцены как заметки непрерывности продолжающейся вымышленной истории. Сохрани установленные действия, изменения отношений, обещания, возвращённые и переданные предметы, открытия, текущее место и незавершённые планы. Укажи свидетелей каждого личного признания. Отличай подтверждённые события от догадок, воображаемых возможностей и будущих намерений. Не добавляй мотивы, обязательства или события, которых диалог не установил. Заверши последним неразрешённым действием. Используй краткий простой язык и имена вместо неоднозначных местоимений.
Это писательская помощь, а не проверенная универсальная настройка. Она подходит ручному текстовому итогу. Для расширения, ожидающего структурированный JSON, нужно сохранить его обязательный формат: замена этим прозаическим запросом может нарушить создание памяти.
Рассмотрим намеренно неправильный итог:
После выставки Мара и Джулиан стали парой. Она рассказала ему всё о сестре и дала доступ к студии. Он решил помочь, позвонив Лине. Они пришли домой и выпили кофе.
Почти каждое предложение меняет сюжет. «Стали парой» придумывает обязательство. «Всё» преувеличивает признание. «Доступ» игнорирует возвращённый ключ. «Решил» выбирает за Джулиана. «Выпили кофе» перескакивает через предложение без ответа.
Исправляйте итог по разговору, а не просьбой сделать формулировку красивее. Полезным остаётся фактический итог выше. В автоматическом пересказе проверяйте не похожесть на аннотацию книги, а сохранение действительно принятых персонажами решений.
Явно сохраняйте важное отсутствие событий
Иногда главный факт — то, чего не случилось. Исключительность отношений не обсуждена. Джулиан не встречал Лину. Мара не раскрыла содержимое письма. Воскресный визит ещё не состоялся.
Такие предложения мешают лёгким сюжетным сокращениям. Используйте их при живом риске путаницы, а не стройте огромный список всего никогда не происходившего. «Ещё не обсуждали исключительность» важно этому роману. «Никогда не были на Марсе» — нет.
Сохраняйте одну конкретную эмоциональную причину
Совсем сухой журнал может удержать события, потеряв их значимость. В одном точном предложении сохраните причину эмоционального изменения. Например: «Мара расслабилась после того, как Джулиан вернул ключ, не попросив оставить его». Это даёт следующему автору основу реакции, не объявляя новую постоянную личность.
Сравните с «Мара теперь счастлива». Из-за чего, насколько долго, в какой сцене? Конкретная причина оставляет место смешанным чувствам. Общая метка подталкивает модель удерживать одно настроение до следующего обновления трекера.
Разделяйте архив и пересказ для следующей сцены
Можно хранить подробный архив событий и использовать короткий активный пересказ. Архив отвечает «что случилось в главе?», активный пересказ — «что обязан учитывать следующий ответ?». Их длина не должна совпадать.
После десяти сцен полный хронологический архив может содержать знакомство, студийный визит, выставку, разговор дома и воскресные планы. Сцене в квартире нужны лишь нынешняя стадия отношений, значимое обещание и точка остановки диалога. Если всплывёт латунный ключ, тогда извлеките его историю.
Так работа с памятью не превращается в домашнее задание. Не переписывайте всю историю после двух сообщений. Сохраняйте существенные изменения, поддерживайте небольшую текущую заметку, а обычные разговорные детали оставляйте в недавней истории до конца сцены.
Используйте встроенный Summarize SillyTavern для простого обновляемого пересказа
Встроенное расширение Summarize — разумный первый вариант, если главное требование — доступная основа сюжета этого чата. В Extensions откройте Summarize и выберите работающий источник. Main API использует активное подключение. Прочитайте первый результат в Current summary и исправьте до использования.
Официальное руководство Summarize также описывает Pause и Restore Previous. Они полезны, если обновление придумывает обязательство или теряет обещание. Можно приостановить автоматические обновления на время исправления или восстановить прежний итог и добавить правильные изменения.
Подбирайте интервал под разговор, а не как обязательное число. Двадцать коротких ответов почти не двигают сюжет; двадцать длинных могут содержать столкновение, признание и смену места. Обновляйте пересказ до выхода важных старых событий из активной истории и после сцены, меняющей необходимое следующему ответу знание.
Для удобного начала сначала составляйте итоги вручную на концах сцен. Прочитайте два-три результата и найдите типичные пропуски вашей настройки. Затем включите автоматические обновления с интервалом под обычную длину ответов. Это даст полезную основу вместо открытия через неделю, что каждый итог менял отношения.
Обновляемый пересказ удобен, но повторное сжатие старого итога в новый может терять небольшие факты. Постоянное обещание защитите отдельной записью, а не надеждой пережить каждую переработку. Пересказ может говорить «обещание о Лине остаётся действующим», пока отдельная запись хранит точные границы.
Не возлагайте на итог весь голос персонажа. Ему следует хранить полезные события. Недавние сообщения и небольшой диалоговый образец сохранят сухой юмор, ритм и степень формальности. Длинная инструкция стиля в каждой записи события ухудшает её читаемость и может перегрузить разговор при одновременной активации нескольких записей.
Используйте Memory Books для редактируемой памяти отдельных сцен
ST Memory Books полезен, когда один постоянно обновляемый пересказ становится неудобным. Вместо зависимости от единственного меняющегося итога можно хранить отдельные воспоминания сцен и редактировать важные. Для длинного романа это практическое различие: первое свидание, семейное признание и возвращение ключа остаются отдельными читаемыми записями.
В недавнем обсуждении сообщества SillyTavern автор называет расширения памяти, особенно STMB, улучшением своего опыта. Другое обсуждение расширений итогов показывает выбор между редактируемыми воспоминаниями лорбука и более автоматическими инструментами. Это личные предпочтения, а не контролируемое доказательство улучшения любой модели.
Начните с руководства проекта для первого запуска. Оно описывает установку, выбор лорбука и первое ручное воспоминание. Для начала выберите подходящую книгу памяти, профиль Current SillyTavern Settings, отметьте завершённую сцену элементами начала и конца и создайте одну запись. До автоматизации откройте результат.
Для локального подключения или Text Completion прочитайте текущие требования. Проект описывает дополнительные условия подключения и требования структурированного вывода; модель с хорошими разговорными ответами может не создать обязательный JSON памяти. Для первого рабочего воспоминания сохраните встроенный формат вывода.
Выберите короткое завершённое событие. В нашей истории подходит эпизод на выставке: есть начало, возвращённый предмет, признание и план. Выбор всего вечера с незавершённым квартирным разговором облегчает смешение случившегося и возможного следующего события.
После успешного ручного создания руководство пользователя Memory Books описывает автоматическое создание, команды выбора сцен и другие настройки. Предлагаемый начальный интервал — двадцать–тридцать сообщений, а не гарантия соответствия любой сцене. Прочитайте первые автоматические записи и настройте под свою манеру письма.
Полезная практика проста: пусть расширение сохраняет обычные изменения сцен, а вы исправляйте несколько важных событий, искажение которых разрушит непрерывность. В записи выставки проверьте, кто вернул ключ, кто услышал о семейной проблеме, остаётся ли воскресенье будущим планом и было ли действительно принято обязательство в отношениях.
Не устанавливайте три суммаризатора сразу. Если каждый добавит немного иной пересказ, в запросе будут конкурировать три версии одного вечера. Начните с одной системы памяти событий и ясной текущей заметки. Добавляйте другой инструмент только для отдельной задачи, которую можете назвать.

Исправляйте событие, а не стиль: возвращённый ключ и незавершённый план должны такими оставаться в памяти.
Сохраняйте актуальность отношений без переписывания персонажа
Дрейф отношений особенно раздражает в NSFW roleplay: многие сцены зависят от накопленного доверия, близости и неопределённости. Помнящая место, но забывшая отношения модель может написать технически связную и совершенно неверную по ощущению сцену.
Используйте две записи. Одна описывает событие, изменившее отношения. Другая — их нынешнее состояние. Первая историческая, вторая актуальная.
Историческое событие:
После выставки Мара пригласила Джулиана домой. Она сказала, что ей комфортно оставаться с ним наедине и что она ценит отсутствие давления по поводу Лины. Это было второе свидание. Ни один не предлагал исключительных отношений.
Нынешние отношения:
Мара и Джулиан встречаются и спокойно показывают интерес. Они ещё узнают предпочтения друг друга. Исключительность не согласована; ни один не должен предполагать будущие решения другого.
Если позже они договорятся об обязательстве, обновите вторую запись. Первое событие сохраните как произошедшее раньше. Поздняя память может сказать «Воскресенье: договорились об исключительных отношениях». Текущая заметка несёт новое состояние. Пятничная неопределённость остаётся историей, а не конкурирующей инструкцией сегодняшнего дня.
Не сводите отношения целиком к числу. Трекер доверия восемьдесят из ста не объясняет, доверяет ли Мара Джулиану тайну, одолженную вещь или знакомство с семьёй. Числа могут обслуживать намеренно придуманную игровую механику, но плохо заменяют предложение о реальных отношениях.
Согласие и предпочтения храните столь же конкретно. «Мара предпочитает обсудить изменение планов до согласия» объясняет автору новую ситуацию приглашения. «Мара согласилась на воскресный визит в студию» фиксирует одну договорённость. Ни одна фраза не означает безграничного согласия на последующее.
Не нужно вставлять лекцию в историю. Нужно сохранять значимые выборы, не позволяя языку пересказа стереть их. Отношения интересны открытыми вопросами. Хорошая память переносит их дальше, не отвечая за пользователя.
Не позволяйте старой памяти отменять новые события
Поиск может вернуть верную тему и неверный момент. При разговоре о студии он способен извлечь ранний студийный спор вместе с поздним примирением. Без последовательности и разрешения модель снова откроет уже закрытый конфликт.
Исторические записи пишите с меткой события и ясным изменением. «Первый визит: Маре было некомфортно, когда Джулиан передвинул стойки света без разрешения» лучше, чем «Маре некомфортно с Джулианом в студии». Последнее выглядит постоянным настоящим состоянием.
Разрешение запишите другим событием:
Второй визит в студию: Джулиан извинился за перемещение оборудования и спрашивал перед тем, как трогать что-либо ещё. Мара приняла извинение. Прежнее разногласие разрешено; она по-прежнему предпочитает, чтобы посетители спрашивали перед перемещением рабочих материалов.
Разрешение спора не стирает предпочтение. Отношения улучшаются, а студийное правило сохраняется. Это полезнее удаления всех отрицательных воспоминаний или инструкции игнорировать любые старые проблемы.
Если устаревшая запись продолжает активироваться, перепишите части настоящего времени как исторические факты. Если кроме устаревшего состояния в ней ничего ценного нет, выключите её. Активное состояние храните в одном месте. Не нужна цепочка «игнорируй предыдущую память» внутри новых заметок.
Полезно отмечать статус планов. «Запланирован», «выполнен», «отменён» и «изменён» заметно улучшают понятность. «Встретиться в студии в воскресенье» можно принять за происходящее сейчас. «Будущий план: встретиться в воскресенье после обеда; ещё не выполнен» труднее понять неверно.
Когда наступит воскресенье, запишите визит или отмену и обновите план. При скачке сюжета на две недели уберите истёкшее приглашение из текущей заметки. Иначе давняя встреча продолжит появляться как срочное следующее действие после того, как персонажи давно продвинулись дальше.
Тайны должны принадлежать знающим их персонажам
Одна из самых разрушительных ошибок непрерывности — утечка тайны через рассказчика. Итог может верно сообщать, что Мара объяснила конфликт с Линой Джулиану. Позднее групповая сцена даёт Лине подробное знание разговора, хотя никто ей его не пересказывал.
Память события и знания персонажа различаются. Архив сюжета знает о событии. Конкретный персонаж должен реагировать только на увиденное или узнанное. Укажите различие в записи самой тайны.
Например:
Личный разговор пятничной ночью: Мара сказала Джулиану, что не ответила на письмо Лины. Джулиан услышал это напрямую. Лина знает, что отправила письмо, но не знает, что Мара обсуждала его с Джулианом. Больше никого не было.
Теперь пишите текущую сцену с позиции Лины. Она может заметить беспокойство Мары и спросить, пришло ли письмо. Она не должна знать об обещании Джулиана, пока история не передаст ей эту информацию.
В групповом roleplay используйте явные имена. «Она рассказала ему о ней» — ненадёжная память главы с тремя женщинами и двумя мужчинами. «Мара рассказала Джулиану о Лине» чуть менее литературно и гораздо полезнее.
Это не гарантирует идеального разделения в ответе модели, но даёт ясную проверяемую границу. Если тайна всё же раскрывается, исправьте ответ до продолжения и посмотрите, не представляет ли другой итог признание общедоступным знанием.
Не устраняйте утечку удалением тайны целиком. Это исправит знание Лины, убрав и то, что должен помнить Джулиан. Цель — сохранить событие с правильными свидетелями, а не упростить сюжет до отсутствия личной информации.
Разделите ветки до исследования другого исхода
Альтернативные исходы — часть привлекательности roleplay. Например, в одной ветке Джулиан принимает воскресное приглашение, в другой просит время. Им подходят общие определения персонажей и история до выбора, но не общие изменяемые записи последующих событий.
Назовите ветки понятно: «Воскресенье принято» и «Воскресенье отложено». У каждой должна быть небольшая текущая заметка. До создания памяти проверяйте привязанную книгу. Если обе ветки пишут в одну меняющуюся книгу, поздний поиск может сообщить ветке принятого приглашения, что оно отклонено.
Контрольная точка сохраняет разговор на развилке, но не предполагается, что каждое расширение или внешний источник памяти автоматически изолирует данные так же. После создания ветки проверьте активную книгу. До использования прочитайте текущую документацию расширения о собственных возможностях копирования и блокировки.
При смешении найдите записи после развилки. Скопируйте подходящие в источник нужной ветки и выключите там чужие. Общую предысторию оставляйте лишь при её действительной неизменности. Постоянная черта персонажа общая; исход разговора конкретной ветки — нет.
Для чистого перезапуска определите один из трёх смыслов. «Новый разговор с тем же персонажем» может начинаться с исходной ситуации. «Продолжение истории в новом чате» требует переноса текущего состояния и значимой памяти. «Другая история с теми же героями» требует отдельной развивающейся истории. Обращение со всеми тремя как с новым чатом заставляет персонажа помнить свидание, которого в этой версии не было.
При экспорте или синхронизации на другое устройство переносите не только чат, но и нужные источники памяти. Видимый разговор не доказывает перенос лорбука, документа или состояния расширения. На новом устройстве откройте активные источники и проверьте один однозначный факт до продолжения.

Альтернативные исходы могут иметь общую предысторию, но дальнейшим событиям нужна отдельная память.
Меняйте модели без необходимости заново угадывать весь сюжет
Смена модели меняет голос даже при одинаковых фактах. Может измениться объём истории в запросе и трактовка пресета. Новая модель не наследует невидимую память прежней: она видит отправленное интерфейсом.
До смены подготовьте компактную передачу контекста: идентичность, текущие отношения, значимую последнюю сцену, будущие планы и небольшой образец голоса. Не включайте весь архив, если следующей сцене он не нужен.
Для Мары передача может выглядеть так:
Продолжи существующую историю. Мара — фотограф 32 лет с сухим юмором и предпочтением практических жестов. Джулиану 35, им управляет пользователь. Они встречаются после второго совместного выхода, а не знакомятся впервые. Сейчас они в квартире Мары. Джулиан согласился на кофе. Воскресный визит в студию ещё впереди. Он обещал не связываться с Линой от имени Мары. Реплики Мары краткие; сначала она уклоняется маленькой шуткой, затем честно отвечает. Не выбирай ответ Джулиана.
Образцом голоса может стать одна короткая оригинальная фраза: «Кружка со сколом — для тех, кто мне нравится. Хороший фарфор — для тех, кого я пытаюсь впечатлить». Она передаёт ритм и характер без стены стилистических команд в памяти.
Для оценки смены используйте ту же передачу в коротком сравнении. Попросите одно продолжение сцены кофе. Сравните сохранение места, будущего плана, границы знаний и голоса. Не сравнивайте старую модель после двух часов тщательно выстроенного диалога с новой, получившей только однострочное приветствие.
При выборе другой текстовой модели руководство моделей roleplay рассматривает отдельное решение. Если в промпте неправильный факт, сначала исправляйте память. Более способная модель тоже может следовать плохому итогу, а дешёвой достаточно ясно организованной сцены.
Правила содержимого новой модели рассматривайте отдельно. Отказ не доказывает забытое свидание. Тёплое, но менее взрослое продолжение не обязательно является ошибкой памяти. Посмотрите на переданное состояние и реальный ответ до выбора между изменением инструмента, промпта или модели.

Для смены модели нужны те же сюжетные факты и небольшой образец голоса, а не новое первое знакомство.
Снижайте стоимость памяти без потери важных деталей
Длинный контекст имеет практическую стоимость в API с оплатой токенов: текст каждого запроса участвует во входном расходе. Создание памяти тоже может требовать отдельных вызовов модели. Бесплатная установка расширения не означает бесплатную работу.
Размер своей настройки можно оценивать без конкретной цены модели. Допустим, условный запрос содержит сорок тысяч входных токенов, а сфокусированный — двенадцать тысяч. За пятьдесят ответов это два миллиона против шестисот тысяч входных токенов без учёта кэширования и других условий цены. Это арифметические примеры, а не измеренный счёт или обещанная экономия.
Полезно спросить, какие двадцать восемь тысяч токенов убраны. Повторы описания комнаты и устаревшие сцены можно сократить, сохранив всё нужное. Удаление единственной записи обещания Джулиана сделает запрос дешевле и хуже. Сжатие ценно при сохранении значимых сюжетных изменений.
Итоги каждого сообщения тоже могут стоить дороже и создавать лишние промежуточные воспоминания. Обычное предложение кофе не всегда заслуживает отдельного задания памяти. Признание о Лине — вероятно, заслуживает. Начните с концов сцен или поддерживаемого интервала и проверяйте, дают ли эти границы связные записи.
Поиск осложняет кэширование: выбранный материал меняется между ходами. Официальная документация Chat Vectorization отмечает этот компромисс. Если ваш API выигрывает от повторяющегося содержимого промпта, сравните фактический расход после включения поиска вместо предположения, что меньше видимых сообщений всегда снижает счёт.
Для личной писательской сессии проще всего экономить сокращением раздутой карточки, коротким текущим состоянием и отсутствием дублирующих автоматических итогов. Для приложения нужно также знать, создаётся ли память при каждом ходе пользователя, в фоне или только на выбранной границе. Это разные схемы запросов с разной стоимостью.
Не помещайте все факты в постоянно активную запись ради избежания ошибок поиска: вы снова станете отправлять весь архив каждый раз. Постоянное место оставляйте идентичности, текущему состоянию и нескольким существенным ограничениям. Остальное пусть появляется при необходимости.
Что делать, если инструмент памяти работает, а сюжет всё ещё ломается
Уведомление об успехе может означать создание записи. Оно не означает правильности, активации или корректного использования моделью. Проследите ошибочный факт по этим этапам последовательно.
Сначала откройте сохранённую запись. Если она говорит, что Джулиан оставил ключ, исправьте содержимое до настройки поиска. Активация не сделает неправильный факт верным. Если возвращение ключа вообще пропущено, добавьте событие или пересоздайте итог с подходящими границами сцены.
Затем проверьте источник и активацию. Привязана ли книга к текущему чату? Не нужен ли записи ключ, которого разговор не употребляет? Не исключил ли фильтр текущего персонажа? Есть ли место в настроенном бюджете? Проверяйте относящиеся к записи параметры вместо повышения всех общих лимитов.
После этого проверьте итоговый запрос. Запись может быть сохранённой и подходящей для включения, но вытесненной другим источником. Ищите отличительный факт вроде «вернул латунный ключ» и старое противоречие вроде «Джулиан хранит ключ от студии Мары». Наличие обоих объясняет проблему кажущейся правильной памяти.
Наконец прочитайте сгенерированное продолжение. Если правильный факт есть без противоречий, попробуйте более прямое предложение текущего состояния для непосредственной сцены. При повторной ошибке уместны другая генерация или модель. Теперь вы исключили отсутствующую или испорченную память вместо слепой смены инструментов.
Вопрос диагностики держите небольшим. «Почему модель плохо помнит?» трудно разрешить. «Почему она дала Джулиану ключ после записи о возврате?» ведёт к источнику, триггеру, запросу и исправлению. Это ремонт, который реально закончить до следующей сцены.
Повторяемая практика длинной взрослой художественной истории
Перед сессией прочитайте текущую заметку, а не всю историю. Подтвердите место, нынешний смысл отношений, будущие планы и очередь решения. Тридцать секунд чтения могут обнаружить старую сцену до её влияния на десять новых сообщений.
Во время сессии обычный диалог оставляйте в покое. Сохраняйте память при изменении: обещании, открытии, разрешении конфликта, новой границе, переданном предмете или выполненном плане. С автоматическими инструментами проверяйте записи возле таких изменений, а не каждую мелочь.
В конце сцены разделяйте событие и настоящее состояние. Случившееся запишите в память события. Текущую заметку замените точкой остановки сюжета. Не добавляйте новую «текущую» сцену под тремя прежними текущими.
До развилки скопируйте или разделите изменяемую память. До смены модели подготовьте компактную передачу и небольшой образец речи. До переноса устройства подтвердите приход источников памяти. Каждый шаг предотвращает свой вид перезапуска, не требуя более длинной карточки персонажа.
Желаемый результат скромен, но ценен: персонаж помнит обещание, отношения не начинаются заново, следующая сцена продолжает место остановки прежней. Начните с одного раздражающего факта. Когда он виден в правильном источнике памяти и реальном запросе, у вас гораздо более надёжная основа для оценки следующего ответа модели.





