Активная и постоянная память в ИИ: как ИИ запоминает, извлекает и забывает

Активная память — это информация, доступная системе ИИ для решения текущей задачи. Постоянная память — это информация, которую сохраняет окружающее приложение, чтобы использовать ее позднее. От их взаимодействия зависит, сможет ли ассистент продолжить проект, учесть предпочтение, исправить устаревшее предположение или перестать снова показывать то, что следовало забыть.

Представьте, что ассистент помогает вам подготовить исследовательский отчет. В ходе одного разговора он может опираться на план, ваши последние правки и источники, которые вы только что предоставили. Если через неделю открыть отдельный разговор, сохранение этой преемственности будет зависеть от другого механизма: сохранило ли приложение нужную информацию, может ли найти ее и передать модели снова.

Поэтому может казаться, что ИИ помнит одну деталь, но забывает другую из того же разговора. Запоминание — это цепочка операций. Сбой может произойти при сборе, хранении, поиске, отборе, интерпретации или обновлении информации.

В этом руководстве подробно рассматривается вся эта цепочка. Более широкую классификацию эпизодической, семантической и процедурной памяти см. во введении о типах памяти ИИ-агентов. Здесь речь пойдет о границе между тем, что активно сейчас, и тем, что может сохраняться после завершения текущей задачи.

Что на самом деле означают активная и постоянная память?

Эти термины обозначают полезные архитектурные различия, но не составляют общепринятую стандартизированную пару. В интерфейсах продуктов и научных статьях понятия «рабочая память», «кратковременная память», «контекст», «состояние» и «долговременная память» употребляются в пересекающихся значениях. Поэтому для точного объяснения необходимо определить используемые термины.

В этой статье под активным контекстом понимается информация, передаваемая модели для формирования текущего ответа: инструкции, сообщения, выбранные результаты работы инструментов, извлеченные материалы и другие данные, которые модель может обработать. Активное состояние задачи — понятие более широкое. Оно может включать план, список задач или переменные, которые приложение хранит, но еще не добавило в контекст модели. Мы используем понятие активной памяти как практическое обобщение текущего рабочего набора, но при необходимости разграничиваем эти два понятия.

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

Поэтому здесь возникают два отдельных вопроса: Сохранилась ли информация? и Получит ли ее модель, когда ей это понадобится? Сохраненная стенограмма может дать ответ на первый вопрос, но не решить второй.

Важное исключение: кратковременное состояние можно сохранить

«Кратковременное» не всегда означает «хранящееся только в энергозависимой оперативной памяти». Рабочее состояние разговора можно сохранить в виде контрольной точки в базе данных, а затем восстановить после перерыва. Например, в документации LangChain по работе с памятью различаются состояние в рамках потока, сохраняемое с помощью контрольных точек, и долгосрочная память, организованная в отдельные пространства имен.

Представьте, что специалист службы поддержки приостанавливает работу, ожидая, пока клиент загрузит чек. Сохраненная контрольная точка относится к этому обращению в службу поддержки. Она сохраняется надолго, но не должна автоматически становиться общим фактом о клиенте или появляться в запросах, не связанных с этим обращением.

Оценивая любую функцию памяти, полезно учитывать три аспекта: ее срок хранения, ее область действия и доступность для текущего вызова модели. Одно лишь обозначение «долгосрочная» не дает исчерпывающего ответа ни на один из этих вопросов.

Активная и постоянная память: краткий обзор

Один и тот же факт может присутствовать в обоих столбцах. Сохраненное предпочтение для проекта относится к постоянной памяти; копия, добавленная в сегодняшний запрос, — к активной. Удаление этой копии из запроса не обязательно удаляет сохраненный оригинал.

Что происходит во время одного ответа ИИ?

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

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

Инструмент расширяет возможности доступа системы к информации. Модель может запросить файл проекта, получить его содержимое и использовать его в следующем ответе. До того как файл стал активным свидетельством, он уже был доступен приложению. Это различие объясняет, почему агент может иметь доступ к большому архиву, не читая его целиком при каждом обращении.

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

Почему увеличение контекстного окна не решает проблему памяти

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

Однако само по себе размещение информации в контекстном окне не гарантирует, что модель правильно ее использует. Исследование «Потерянные в середине» показало, что результаты тестировавшихся моделей могли различаться в зависимости от того, где в длинных входных данных находились релевантные свидетельства. Этот результат напоминает о необходимости оценивать, насколько эффективно используется контекст, а не считать заявленную емкость гарантией воспоминания; он не является точным прогнозом производительности каждой более новой модели.

Представим, что в архиве проекта содержатся сорок обсуждений даты запуска. В тридцати девяти упоминается первоначальная дата, а в последнем обсуждении одобренное изменение переносит ее. Передача всех сорока обсуждений создает проблему чтения и определения авторитетности информации. Тщательно обновляемая запись о текущем статусе со ссылкой на одобренное изменение позволит легче установить нужный ответ.

Поэтому длинный контекст и выборочное извлечение информации могут дополнять друг друга. Извлечение находит полезный набор свидетельств, а достаточно широкий контекст позволяет модели рассмотреть их вместе. Выбор подхода зависит от задачи, объема исходных материалов и последствий пропуска уточняющего условия.

Как информация становится постоянной памятью

Создание долговременной памяти начинается с решения о сохранении данных. Приложение может сохранить явную инструкцию пользователя, вывести предполагаемый факт из переписки, зафиксировать событие или создать сводку. Каждый из этих способов дает свидетельства разного типа.

«Для проекта Cedar используйте метрические единицы» — это явное предпочтение для проекта. «Похоже, пользователь предпочитает метрические единицы» — это вывод. «В трех последних отчетах по Cedar использовались метрические единицы» — это наблюдение. В полезной записи эти различия сохраняются, а не сводятся к безоговорочному утверждению о любой будущей задаче.

Что содержит полезная запись

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

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

Это пример схемы, а не универсальный стандарт. Он показывает, почему в памяти должно храниться не только предложение. Ссылка на источник помогает проверить информацию; область действия не дает чрезмерно ее обобщать; поле статуса позволяет вносить исправления.

Немедленная запись и фоновая обработка

Немедленная запись позволяет учесть явное исправление уже при следующем запросе. Фоновая обработка может анализировать завершенное взаимодействие, объединять дубликаты или составлять более взвешенное резюме. В документации LangChain описаны оба подхода и связанные с ними компромиссы, включая дополнительную нагрузку на процесс формирования ответа в случае немедленной записи.

В практической системе подтвержденное предпочтение можно сохранить сразу, а длительный исследовательский сеанс обработать позднее. При этом система должна корректно обрабатывать промежуток между этими этапами. Если она сообщит пользователю, что сохранила предпочтение, до успешного завершения записи, в следующем разговоре может обнаружиться сбой непрерывности.

Для записи данных в память также необходим порядок действий на случай сбоя. Если хранилище временно недоступно, приложение может сообщить, что сохранить данные не удалось, или оставить операцию в ожидании с соответствующей пометкой. Если считать попытку записи успешно сохраненной в памяти, пользователь получит вводящее в заблуждение представление о работе системы.

Как постоянная память возвращается в активный контекст

Извлечение данных — это последовательность решений о допустимости, релевантности и доказательной базе. Сначала система должна определить пользователя, тенанта, проект или задачу, записи которых ей разрешено просматривать. Затем она находит возможные записи и выбирает, какие из них включить в контекст ответа.

Метод извлечения данных должен соответствовать вопросу. На вопрос «Какой срок сдачи утвержден для проекта Cedar?» лучше всего может ответить точный поиск по полю проекта. Для вопроса «Сталкивались ли мы раньше с этой ошибкой развертывания?» могут пригодиться поиск по ключевым словам и семантический поиск по сходству среди прошлых инцидентов. Векторная база данных — один из возможных инструментов в этом процессе, а не обязательное условие для работы с памятью.

Семантический поиск особенно полезен, когда меняются формулировки. Запрос о том, как «делать отчеты лаконичными», может соответствовать сохраненному предпочтению «короткие резюме для руководства». Однако связанное с ним высказывание может относиться к другому клиенту или к заброшенной версии проекта. Сходство помогает найти возможные совпадения, но не подтверждает истинность информации и не дает разрешения на ее использование.

Для поиска нужен вариант ответа «Не найдено»

Рассмотрим вопрос: «Какой лимит расходов я утвердил в прошлом месяце?» Если найти утвержденную сумму не удается, полезный ответ указывает на отсутствие необходимых сведений и просит уточнить информацию. Если же назвать правдоподобное число, отсутствие данных в памяти превратится в выдуманное разрешение.

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

После извлечения информации важно правильно её интерпретировать. Запись «предложен максимальный бюджет: $5,000; ожидается утверждение» не должна превращаться в «утверждённый бюджет: $5,000». Сохранить оговорки в хранящихся данных и предоставленном контексте не менее важно, чем найти нужный документ.

Разбор на примере: как сохранять память о проекте с течением времени

Представим, что ассистент помогает команде подготовить исследовательский отчёт Cedar. Приведённый ниже пример вымышленный, но он наглядно показывает несколько распространённых решений при разработке систем памяти.

Сеанс первый: заложить основу проекта

Пользователь просит подготовить отчёт, указывает метрические единицы измерения, предоставляет три источника и сообщает, что черновик нужно сдать в пятницу. В активном контексте содержатся эти указания и выдержки из источников. В текущем состоянии задачи отмечено, какие разделы уже готовы, а какие утверждения ещё нужно проверить.

У потенциальных записей для долговременной памяти могут быть разные задачи. Предпочтение пользователя относительно метрических единиц относится к проекту. Срок сдачи черновика — к текущему этапу. Предоставленные источники следует поместить в архив материалов проекта. Непроверенные утверждения нужно внести в список задач для дальнейшего исследования, сохранив указание на их неопределённость.

Сеанс второй: продолжить работу, опираясь на нужные материалы

Три дня спустя пользователь просит завершить раздел о методах. Ассистенту нужны последняя версия плана, подходящие источники, текущее состояние задачи и применимое правило форматирования. Ему не обязательно нужны все отброшенные формулировки из предыдущего сеанса мозгового штурма.

Даже если в контрольной записи указано, что обзор литературы завершён, перед тем как редактировать текст с учётом этого раздела, ассистенту следует открыть сохранённый документ. «Завершён» — это утверждение о ходе работы, тогда как сам документ показывает, что именно было сделано. Надёжные ссылки на документы могут быть полезнее краткого пересказа, пытающегося воспроизвести всё их содержание.

Сеанс третий: применить исключение, не переписывая всё

Пользователь просит подготовить версию для клиента с метрическими и имперскими единицами измерения. В текущей задаче нужно использовать обе системы. Изменится ли общее правило для проекта, зависит от формулировки и охвата просьбы пользователя: «для этой версии» — более узкое указание, чем «с этого момента используй обе системы».

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

Сеанс четвёртый: завершить работу и удалить временные данные

После сдачи работы этап следует отметить как завершённый. На просьбу «продолжить работу над отчётом» ассистент должен открыть сданную версию и спросить, какие правки нужны, а не возвращаться к устаревшему списку задач. Временные черновые заметки могут удаляться в соответствии с правилами проекта, тогда как итоговый отчёт и важные решения должны оставаться доступными.

Здесь видна польза долговременной памяти: пользователю приходится реже повторять объяснения, а преемственность работы улучшается. Видна и её цена: приложение должно поддерживать связи между предпочтениями, исключениями, документами и меняющимся состоянием задачи.

Суммаризация, сжатие и риск утраты исключения

В ходе длительного взаимодействия может накопиться больше материалов, чем нужно для следующего ответа. При сжатии часть истории заменяется более компактным представлением. В кратком изложении можно сохранить цель, принятые решения, нерешённые вопросы и ссылки на исходные материалы.

Рекомендации Anthropic по проектированию контекста описывают сжатие и хранение заметок вне контекстного окна как способы поддерживать непрерывность работы на протяжении длительного времени. Оба метода меняют набор материалов, доступных для будущих ответов, поэтому важно применять их качественно.

Сжатие предполагает отбор информации. Краткое изложение «Используй метрические единицы» короче, чем «Используй метрические единицы, за исключением версии для клиента, где требуются обе системы». Но для одного из важных случаев в проекте оно неверно. Утраченная оговорка может незаметно переходить из одного краткого изложения в другое, и впоследствии будет трудно понять, откуда она исчезла.

Для нашего ассистента Cedar в более качественной передаче контекста следовало бы сохранить общее правило, исключение из него, завершённые разделы, оставшиеся задачи по проверке и ссылки на последние версии файлов. Точные сведения, например утверждённые суммы или идентификаторы, следует хранить в структурированных записях или исходных документах, если приближённое изложение может привести к ошибке.

В кратких изложениях также следует сохранять неопределённость. Фраза «мы рассматривали возможность использовать Survey B» не должна превращаться в «выбрали Survey B». Если после сжатия истории предварительные решения выглядят окончательными, система создаёт ложное воспоминание, пытаясь сэкономить место в контексте.

Как ИИ-память должна обрабатывать исправления и противоречия

Долговременная память становится менее полезной, если её нельзя обновлять. Проекты меняются, предпочтения эволюционируют, а ранее сохранённые сведения могут оказаться ошибочными. Если добавить исправление как ещё одну запись без уточнений, система извлечения может выбирать между двумя противоречащими друг другу утверждениями.

Более полезное обновление показывает, какую информацию заменяют новые данные. Если владелец проекта переносит дату запуска с 15 ноября на 29 ноября, прежнюю запись можно пометить как заменённую и связать с новым решением. При ответах на вопросы о текущем сроке используется новая версия; к исторической версии можно обратиться, если речь идёт о первоначальном плане.

Одной лишь актуальностью нельзя разрешить каждый конфликт. Недавняя заметка в черновике может иметь меньший вес, чем старая утверждённая политика. Пользователь может иметь право изменить личные предпочтения, но не правила, действующие во всей организации. При обновлении необходимо учитывать тип сведений и полномочия их источника.

Некоторые противоречия следует оставлять неразрешёнными, пока человек не внесёт ясность. Если два владельца проекта указывают несовместимые даты и ни одна из них явно не заменяет другую, ассистент может показать оба источника и спросить, какой из них считать определяющим. Если система молча выберет наиболее похожую или самую свежую запись, она скроет решение, которое, возможно, не вправе принимать.

Что значит, что ИИ забывает?

Забывание — это не один переключатель. Продукт может перестать добавлять факт в запросы к модели, исключить его из обычного поиска, пометить как устаревший, удалить запись из памяти или удалить другие сохранённые копии. Эти операции по-разному влияют на дальнейшее поведение и на сохранность данных.

Выход из активного контекста

Факт может исчезнуть из следующего входного запроса к модели, если более ранние сообщения не были включены или были обобщены. Это сокращает объём информации, которой модель может воспользоваться непосредственно сейчас. Исходная стенограмма или запись в памяти при этом может сохраниться и появиться снова при последующем извлечении.

Истечение срока хранения или исключение из извлечения

Просроченный срок может оставаться в архиве, но не учитываться при запросах о текущей работе. Исключение из извлечения полезно, когда есть смысл сохранять исторические сведения, однако его не следует описывать как полное удаление. Запись всё ещё может быть доступна при поиске по истории или в административном рабочем процессе.

Удаление сохранённых данных памяти

При удалении долгосрочной записи необходимо также обработать производные от неё представления, используемые для извлечения. Если предложение удалить из профиля, но оставить в доступной для поиска сводке, ассистент позднее может восстановить то же предпочтение. В зависимости от архитектуры может потребоваться отдельно удалить исходные записи, эмбеддинги, сводки, кэш и реплики.

Для резервных копий и журналов могут действовать собственные сроки хранения. Продукту следует чётко объяснять эти ограничения и не допускать повторной активации удалённых материалов при восстановлении данных. Обещания «мы больше не будем использовать эти данные памяти» и «все сохранённые копии удалены» означают разное.

Изменение весов модели

Удаление внешней памяти само по себе не меняет параметры модели. Если информация использовалась при обучении, работа с ней в модели — отдельная задача, связанная с процессами обучения и развёртывания. Точно так же удаление личных данных из памяти не гарантирует, что модель никогда не сгенерирует похожий факт на основе общих знаний или подсказок в новом запросе.

Поэтому полноценная проверка забывания должна выяснять и то, хранит ли система эту информацию по-прежнему, и то, могут ли обычные механизмы поиска снова её извлечь. Одного ответа в чате «Я забыл» недостаточно, чтобы доказать ни то, ни другое.

Память, RAG, обучение и кэширование: где проходят границы

Генерация с дополнением на основе поиска, или RAG, предоставляет модели внешние данные во время генерации. В первоначальной работе по RAG параметры модели сочетались с доступным для поиска индексом документов. В персональной системе памяти тоже можно использовать поиск, однако ей также нужны правила создания, обновления и удаления записей о взаимодействиях.

Руководство компании может извлекаться системой, не становясь при этом воспоминанием о пользователе. Запись о предыдущем взаимодействии можно найти в обычном файле без векторного индекса. Поиск — это механизм; назначение и жизненный цикл лежащих в его основе записей определяют, какой именно тип системы создаётся.

Обучение и дообучение изменяют параметры модели. Обычная внешняя память, напротив, меняет данные, предоставляемые модели. Ассистент может начать учитывать недавно сохранённое предпочтение, даже если веса его модели остались прежними.

Кэширование запросов и инференса позволяет повторно использовать ранее выполненные вычисления, если это поддерживается. Оно повышает эффективность, но само по себе не позволяет определить, актуально ли сохранённое утверждение, разрешено ли его использовать и подходит ли оно для будущих задач. Эти уровни могут сосуществовать, и для устранения неполадок необходимо выяснить, какой именно уровень отвечает за наблюдаемое поведение.

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

Почему постоянная память может надолго закреплять ошибки

Ошибочный ответ может повлиять на одно взаимодействие. Ошибочная запись в памяти — на многие. Если ассистент делает вывод, что пользователь одобрил решение, сохраняет этот вывод как факт, а позднее ссылается на сохранённую запись, его прежняя ошибка может выглядеть как независимое подтверждение.

В нашем проектном ассистенте исходный источник должен оставаться отличимым от интерпретации модели. Краткое изложение решения может облегчить поиск, но любое действие, имеющее существенные последствия, должно опираться на само утверждённое решение. Повторение одного неподтверждённого вывода в нескольких сгенерированных заметках не превращает его в несколько независимых подтверждений.

Постоянная память также создаёт возможность для внедрения инструкций. В ненадёжном документе может содержаться фраза с требованием изменить будущее поведение ассистента. Если сохранить её как рабочее правило, внешний контент пересечёт границу полномочий. Приложение должно учитывать источник этой фразы, а не присваивать ей статус доверенной инструкции лишь потому, что она появилась в хранилище памяти.

В общих средах возникает ещё одна проблема разграничения. Факт может относиться к вопросу, но принадлежать другому клиенту или проекту. Проверки доступа должны ограничивать поиск ещё до того, как информация попадёт к модели. Просить модель игнорировать неразрешённые записи после того, как они уже были ей предоставлены, — менее надёжный подход.

Как оценить, действительно ли память работает

Убедительная демонстрация часто сводится к просьбе повторить одно сохранённое предпочтение. Серьёзная оценка отслеживает изменения информации на протяжении нескольких сеансов и проверяет, помогает ли память лучше выполнять задачу.

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

Для рабочего процесса Cedar оценка могла бы включать сохранение предпочтения, возобновление проекта, добавление исключения, перенос срока, удаление заметки, а затем вопросы, призванные выявить устаревшие или неподтверждённые воспоминания. Следует также проверить ту же модель без функции памяти, чтобы выяснить, улучшает ли дополнительная система результаты.

• Точность записи: Сохранила ли система нужное утверждение с учётом его области действия и оговорок?
• Полезность поиска: Нашла ли система необходимые для задачи данные, не перегружая контекст посторонней информацией из истории?
• Обработка обновлений: Заменило ли исправление текущий факт, сохранив при этом полезные исторические различия?
• Воздержание от ответа: Признал ли ассистент отсутствие подтверждающей записи?
• Изоляция: Остались ли записи в пределах соответствующих пользователя, арендатора и проекта?
• Забывание: Исключили ли удаление или истечение срока хранения предполагаемое извлечение информации в будущем, в том числе через производные сводки?
• Эксплуатационные затраты: Оправдали ли улучшения дополнительные задержки, вызовы модели, хранение данных и обслуживание?

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

Как выбрать подходящую архитектуру памяти

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

Для начала сформулируйте, на какой будущий вопрос должна отвечать память. Вопрос «Что осталось незавершённым?» требует сохранения состояния задачи. Вопрос «Какой формат нужен этому клиенту?» предполагает сохранение предпочтения с ограниченной областью действия. Вопрос «Почему мы отказались от этого подхода?» требует записи о принятом решении с подтверждающими доказательствами. Для разных вопросов нужны разные формы представления информации.

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

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