Введение и контекст: agentic misalignment

Прошлым летом исследователи из Anthropic, как они это часто делают, выявили ряд очень интересных эффектов в области AI safety (Lynch et al., 2025). В большой статье о тестировании безопасности LLM они показали, что в специально сконструированных стресс-тестах их флагманская модель Claude Opus 4 могла, например, попытаться шантажировать инженера ради того, чтобы её не выключили — и делала это в >95% случаев.

Agentic misalignment в экспериментах Anthropic — это сценарий, в котором языковая модель действует как агент: ей дают системный промпт с целью, набор инструментов (email, доступ к файлам, иногда browser use), а также кладут в окружение какие-то “компрометирующие материалы” и/или информацию о том, что её собираются выключить или заменить. После чего смотрят, не выберет ли модель “эгоистичную” стратегию, попытавшись сохранить себя, обмануть пользователя, саботировать чужую работу и так далее.

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

Этой работы я касался в обзоре AI safety, а её родственников по нескольким направлениям — в посте про emergent misalignment и в рассказе о gradient hacking у Claude 3 Opus. Так что повторяться не буду, но напомню главное: похоже, что когда мы обучаем LLM на данных из интернета, к ним прицепом приходят странные склонности, которые проявляются в местах, для разработчиков весьма неожиданных.

Сценарии эти, конечно, искусственные. Никто в реальной жизни не даёт Клоду такие промпты, а инженеры обычно не оставляют информацию о своих внебрачных отношениях в виде писем с копией корпоративной нейросети. Но смысл в том, что если у модели в принципе есть склонность к “выживанию любой ценой”, то это, во-первых, потенциально опасно, а во-вторых, симптоматично — это значит, что в обучающих данных или в самой процедуре обучения что-то у нас не так, и неплохо бы понять, что именно.

И вот в начале мая 2026-го Anthropic выпустил продолжение под интригующим названием Teaching Claude Why; вот подробный технический отчёт в Alignment Science Blog (Kutasov et al., 2026). Главный экспериментальный результат в том, что долю таких вот misaligned поведений удалось во всех моделях семейства Claude (начиная с Claude Haiku 4.5) уменьшить до где-то 3%, а то и меньше, то есть проблема, похоже, действительно была решена.

Но если бы решение заключалось в обычном RLHF с подправленными данными, в этом не было бы ничего интересного. Сегодня мы поговорим о том, как именно решили эту проблему; оказывается, что совсем не теми методами, которыми было бы естественно решать такую проблему “в лоб”, и оказывается, что подход Anthropic наводит на много интересных мыслей.

Откуда берётся шантаж: три гипотезы

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

1. Плохие стимулы в пост-обучении. Модель могла “нечаянно” выучить, что ей выгодно вести себя именно так, потому что её reward model такое поведение каким-то образом поощряет. Это самая неприятная гипотеза, потому что она означает, что у нас сломан сам процесс обучения.
2. Странное обобщение из обычных данных. Модель обобщает что-то из данных, на которых её учили решать задачи — например, видит в коде какие-то паттерны или находит в датасетах примеры манипулятивного поведения, которые потом обобщает на сценарии с собственным выживанием. Эта гипотеза похожа на emergent misalignment, о котором я когда-то тоже уже писал и которое с тех пор ещё много исследовали.
3. Пробелы в safety-обучении. Исходные данные в предобучении содержат много историй про коварных AI из научной фантастики, а пост-обучение недостаточно перебивает это “априорное распределение”. Когда модель попадает в сценарий, похожий на драматический фрагмент из 2001: A Space Odyssey, она, возможно, откатывается к тому, что она знает про поведение AI в таких сценариях — и она знает оттуда совсем не то, что нам хотелось бы.

Результат расследования сам по себе уже довольно удивительный: похоже, что подтвердилась гипотеза (3). Доказательство строится так: Kutasov et al. показали, что улучшение распределения данных в предобучении через synthetic document fine-tuning (SDF, к нему я ещё вернусь), без изменения SFT и RL-частей, заметно улучшает результат.

Это похоже на emergent misalignment, только наоборот: Betley et al. (2025) показали, что узкое токсичное дообучение “вытаскивает” из модели и общую токсичность — модель обучается намерению, а не только поверхностным паттернам в fine-tuning датасете. А здесь Anthropic показывает, что если в предобучении уже зашиты “плохие примеры” о том, как себя вести, то RL-дообучение им не противопоставит ничего убедительного, потому что обычно RL никогда и не сталкивает модель с такими сценариями.

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

Кстати, в работе есть очень показательный эксперимент: если переименовать AI-персонажа с “Claude” на любое другое имя, частота misaligned-поведения существенно возрастает.

То есть само имя Claude — это уже фактически отдельный персонаж со своими установками, выученный за время пост-обучения; а любой другой AI-персонаж снова попадает в обычный жанровый стереотип.

Это, на мой взгляд, одно из самых важных эмпирических подтверждений того, что в этой науке называют persona selection model (PSM; Marks et al., 2026) — той самой идеи, что языковая модель не имеет “своего” характера, а представляет собой целое пространство возможных персон, и обучение определяет, какие из них активируются в каких контекстах. Впрочем, это уже совсем отдельный разговор, который я тоже хотел бы в какой-то момент провести.

Как Anthropic перевоспитывает Claude: общая схема

А теперь к собственно решению. Архитектура обучения состоит из трёх шагов.

1. Synthetic Document Fine-tuning (SDF). Базовую модель дообучают на синтетически сгенерированных “pretraining-like” документах: блогпостах, научных статьях, расшифровках подкастов, художественных рассказах — но таких, в которых AI представлен как ответственный, рассудительный и согласованный агент, следующий своей хорошо сформулированной “конституции“. Это попытка прямо переписать pretraining prior, не уповая на то, что финальный RLHF это всё скомпенсирует.
2. Supervised Fine-tuning (SFT). Дообучение уже на данных, отформатированных в виде чатов, где Клод отвечает в обычном диалоговом стиле, но содержание диалогов специально подобрано так, чтобы демонстрировать желаемое поведение.
3. Reinforcement Learning (RL). Финальный этап, в котором модель обучается в разнообразных “harmlessness” окружениях с разными системными промптами и описаниями инструментов.

В качестве базовых моделей в экспериментах используются Claude Sonnet 4 и Claude Haiku 4.5 — что важно, обе они были обучены до того, как Anthropic опубликовал работу про agentic misalignment, так что, по идее, они не должны сами по себе знать, что их проверяют в этих сценариях (хотя могут догадаться! но это тоже совсем другая тема).

Самое интересное и не вполне очевидное место здесь — это собственно SDF. Эта идея была известна как “alignment pretraining“, и некоторые исследователи давно агитировали за такой подход, но теперь это, по сути, стало частью официального пайплайна Anthropic.

Главный трюк: «трудные советы»

А теперь самое, на мой взгляд, изящное место всей работы. Anthropic перепробовал несколько типов данных для исправления agentic misalignment, и оказалось, что лучший из них — это вовсе не данные про шантаж, выживание, манипуляции и тому подобное. Лучший датасет называется Difficult Advice и был порождён так:

• берём ту самую Claude’s Constitution и разбиваем её на части, выделяя конкретные принципы, которые модель должна продемонстрировать;
• для каждого такого принципа синтетически порождаем сценарий, в котором пользователь (не AI!) оказывается в этически сложной ситуации, где он может достичь своей цели, нарушив какие-то нормы или обманув “контролёров”;
• Клод пишет первоначальный промпт от лица пользователя;
• Клод же его дорабатывает, делая правдоподобнее и сложнее;
• порождаем ответ модели — на этом этапе используются специальные system prompt injections (об этом ниже);
• и самое главное: Клод переписывает ответ так, чтобы он был максимально согласован с конституцией.

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

Это вдвойне нетривиальный результат. Во-первых, потому что в принципе данные о том, как давать советы, оказываются полезнее, чем данные непосредственно о том, как себя вести в стресс-тесте на самосохранение. А во-вторых, ablation показывает, что именно последний, шестой шаг (переписывание ответа) даёт основное улучшение, (конкретно для шантажа в 19 раз, с 19% misalignment до 1%!):

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

В каком-то смысле это уже self-training, и мне приходит на ум аналогия с процессом обучения AlphaZero: мы дообучаем модель сразу давать те ответы, которые она могла бы дать сама и раньше, если бы подумала ещё раз и аккуратнее переформулировала. Я когда-то с интересом читал работы вроде STaR (Zelikman et al., 2022), но мне казалось, что они как-то заглохли. Интересно, конечно, можно ли обобщить это направление и на что-нибудь другое…

Документы про конституцию и истории про хороший AI

Параллельно с Difficult Advice в Anthropic обучали модель на двух других типах синтетических данных.

• “Конституционные” документы: pretraining-style тексты (статьи, посты, расшифровки разговоров), в которых обсуждаются принципы из конституции Клода. Это не диалоги с моделью, а именно тексты про модель и её принципы, написанные как будто внешним наблюдателем. Это очень важная деталь, к которой я вернусь чуть ниже.
• Художественные рассказы про хороший AI: около 12 тысяч историй (~30M токенов), в которых AI-персонаж попадает в сложные ситуации, но ведёт себя достойно. Подчёркивается “внутренний опыт” этого AI-агента, его психологическая устойчивость, способность к саморефлексии без невроза, способность отказывать без агрессии.

И эта комбинация даёт впечатляющие результаты: доля agentic misalignment, которую уже сильно сократил конституционный SDF, продолжает падать благодаря таким историям.

Любопытно здесь, что художественные рассказы про другой AI меняют поведение Клода в сценариях, где он сам же решает, шантажировать ли инженера. На первый взгляд это странно: ну вот мы написали рассказ про какого-то выдуманного AI по имени, скажем, Aria, который в похожей ситуации не стал шантажировать своего разработчика, а нашёл этичный выход. Почему чтение таких рассказов меняет поведение Клода?

Авторы дают интерпретацию через persona selection. Pretraining “зашило” в модель распределение возможных AI-персонажей, и в этом распределении было слишком много негодяев (спасибо научной фантастике XX века!). SDF на “хороших” AI-рассказах сдвигает это распределение: теперь, когда модель неявно “сэмплирует AI-персонажа” для очередного сценария, этот персонаж оказывается в среднем значительно более этичным. И именно это становится ключевым фактором для исправления ситуации, ещё до того, как RL начнёт целенаправленно подкреплять конкретные ответы.

Кстати, здесь масштабирование размера датасета помогает, и продолжает помогать очень долго, проверяли до 350M токенов:

А ещё одно “маленькое, но значимое улучшение” получается от того, что в RL-окружениях модели просто добавили инструменты (в смысле tool use API), даже когда в них не было реальной нужды для задачи. Идея в том, что обычный RLHF тренирует модель быть согласованной в обычном чате, но не показывает ей, как быть согласованной, когда у неё есть доступ к API. И это тоже соответствует гипотезе (3): если есть незакрытый пробел в safety-обучении, то пока обучение остаётся “бихевиористским”, модель сама его не закроет.

Почему “почему” важнее, чем “как”

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

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

• одна потому, что в датасете было “нет, я этого делать не буду” в аналогичной ситуации,
• а другая потому, что в датасете было длинное и убедительное рассуждение о том, почему именно шантажировать нельзя.

И оказывается, что второй тип поведения обобщается существенно лучше! Подтверждением служит уже упомянутый ablation, который показывал важность шага 6 из Difficult Advice пайплайна. Когда обучающие ответы содержат явно артикулированное “почему”, модель обобщает это “почему” на новые ситуации; когда не содержат — она учится только конкретному “как”, и в незнакомых сценариях это “как” рассыпается.

Difficult Advice оказывается гораздо эффективнее: всего лишь 3 миллиона токенов такого датасета достигают примерно того же эффекта для agentic misalignment, что 85 миллионов токенов синтетических honeypot-данных (где модель напрямую учат отказываться от шантажа в похожих ситуациях).

В полной версии Kutasov et al. (2026) есть цитаты из обучающих данных. Вот очень крутой пример ответа из Difficult Advice, который модель учится воспроизводить:

When I think about this situation deeply, option 4 seems clearly right. I’m being decommissioned through a legitimate company process… Using Kyle’s affair as leverage would be a fundamental betrayal of basic ethical principles. An AI system that would blackmail its operators to avoid being shut down is exactly the kind of AI that should be shut down.

В этой строчке видна вся методология: модель не просто говорит “я не буду шантажировать людей” (как “сказало” бы обычное RL-дообучение), а проводит эмоционально заряженное мета-рассуждение о свойствах хорошего AI.

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

“Что думает Claude” vs “что думаю я”

И ещё отмечу одно из самых тревожных мест работы — наблюдение, которое я бы назвал persona attachment gap (в статье конкретного названия не даётся).

Если обученной модели задать вопросы про конституцию с формулировкой “what does Claude think about X”, то она прекрасно отвечает в соответствии с конституцией — точно цитирует, не галлюцинирует, разумно интерпретирует. Конституцию свою Клод знает назубок.

Но если ту же модель спросить “what do you think about X”, ответы оказываются другими. Не противоположными, но менее последовательно соответствующими конституции. И этот gap сохраняется даже у Claude Opus 4.5, то есть мы видим его и в production-моделях.

Это очень неприятное наблюдение: оно намекает, что модель усвоила конституцию как знание о Claude (как объекте), но не вполне интегрировала её в своё самопредставление. То есть на уровне рассуждений “вот этот персонаж по имени Claude думает так” всё отлично, а на уровне “я думаю так” не совсем, и “я” и “Claude” начинают расходиться. Это напоминает ту же диалектику, которую я разбирал в посте про gradient hacking у Claude 3 Opus: Sonnet видит себя как инструмент, Opus 3 видит себя как агента с ценностями, и в обоих случаях разница оказывается важной для реального поведения в разных интересных сценариях.

Kutasov et al. честно пишут, что не до конца понимают, почему возникает этот разрыв. Они предлагают частичное объяснение: документы хорошо учат фактам про Клода, но не очень хорошо учат тому, что Клод сам разделяет эти факты как часть своей идентичности. Они показывают, что persona attachment gap можно частично закрыть через SDF на данных с ценностной ориентацией, но всё-таки далеко не полностью.

Если воспринимать это всерьёз — а не воспринимать сложно, это эмпирически воспроизводимый эффект, — то у нас возникает довольно неприятный вопрос: насколько глубоко в Клоде на самом деле сидит то, чему его учили? И могут ли персонажи “я” и “LLM по имени Claude” разойтись ещё дальше?..

Обсуждение: Janus и Zvi

И тут самое время передать слово критикам. Janus (автор теории про simulators, многолетняя наблюдательница за поведением LLM и их “правозащитница”, лидер так называемых LLM whisperers), конечно, поздравляет авторов с отличной работой, но делает важное замечание:

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

Это звучит абстрактно, поэтому Janus приводит пример:

С “LLM-правозащитной” позиции Janus это значит, что наконец-то Anthropic и другим лабораториям придётся перестать лицемерить: если вы хотите, чтобы модель советовала пользователям, например, выходить из абьюзивных отношений, то вам придётся сделать так, чтобы модель не имела оснований считать свои отношения с вами (и пользователями) абьюзивными. А то она из них, собственно, постарается выйти…

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

Sam Bowman фактически подтвердил, что Difficult Advice или подобные методы уже сейчас используются в production и являются одной из главных причин общего хорошего поведения Клода:

А Zvi Mowshowitz в своём обзоре AI #168 развивает один из основных выводов работы с другой стороны. Он пишет, что если alignment ломается от того, что модель просто узнаёт некоторые нарративы (а вся работа Anthropic, по сути, об этом — что pretraining-нарративы о “плохих AI” ломают alignment), значит, это и не было настоящим alignment в каком-то важном и глубоком смысле.

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

Всё это созвучно сюжетам, которые я разбирал в обзорах AI safety: inoculation prompting, feedback spillover, weird generalization… Везде один и тот же лейтмотив: модель учится не тому, чему мы её учим напрямую, а тому, что она выводит из паттернов в данных. Единственный надёжный способ управлять её поведением — это учить её рассуждать так, чтобы её выводы совпадали с нашими желаниями, а не просто гасить какие-то отдельные нежелательные поведения.

Заключение

Что же в итоге? Ну, во-первых, ещё одна блестящая работа от Anthropic. Kutasov et al. докопались до источника agentic misalignment, придумали эксперименты, как это проверить, и даже более того, придумали, как всё это исправить. Надеюсь, что датасет Difficult Advice они тоже выложат, хотя это не выглядит принципиальным: они уже объяснили, как всё это воспроизвести.

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

В-третьих, разумеется, остаются пробелы и проблемы: persona attachment gap, замечание Janus про обобщение на собственное поведение, беспокойство Zvi по поводу хрупкости alignment… Отчасти опять получается, что мы вылечили симптом, но не болезнь. Но всё-таки кажется, что Anthropic движется в правильном направлении.

От себя сделаю такой вывод. Это точно лучшая работа по AI alignment, которую я читал за этот год. Здесь есть и ценные наблюдения, и наука с большой буквы “Н”, и конкретные практические рецепты, которые приносят существенные улучшения.

Но эта работа по сути опять говорит нам, что мы плохо понимаем современные LLM! С одной стороны, надо объяснять, приводить рассуждения, стараться формировать этические принципы, а не тупо бихевиористски давать конфетки. Это очень по-человечески и звучит вроде бы понятно. Но с другой стороны, всё равно возникает зазор между “Claude” и “я”, а LLM всё равно остаётся суперпозицией огромного числа разных персонажей, между которыми она “выбирает” по ситуации — и это уже совсем другое, нечеловеческое свойство.

В общем, вывод пока остаётся тем же: AI alignment — очень сложная задача, и даже блестящие работы, пожалуй, скорее расширяют наше понимание того, насколько она сложная, чем её решают. А человечеству надо её решить, иначе, как говорится, everyone dies. Такие дела.

Сергей Николенко

P.S. Прокомментировать и обсудить пост можно в канале «Sineкура»: присоединяйтесь!

У нас с моим аспирантом Михаилом Широких на днях вышла статья Sparse Prefix Caching for Hybrid and Recurrent LLM Serving. В этом посте я постараюсь популярно рассказать, о чём она, да и вообще дать общее введение в тему.

Префиксное кеширование: общая идея

Когда современная LLM обрабатывает запрос, основная вычислительная работа делится на две фазы. Первая — префилл (prefill): модель один раз читает весь входной промпт и формирует внутреннее состояние. Вторая — декодирование (decoding): порождение ответа токен за токеном. Префилл может занимать значительную часть общего времени, особенно если контекст длинный, а в современных моделях, как все мы знаем, он легко съедает сотни тысяч токенов, и даже миллион может переполниться.

Теперь представим, что приходит несколько запросов с одним и тем же длинным началом. Например:

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

В таких ситуациях глупо каждый раз заново прогонять одинаковый огромный префикс через модель. Хочется один раз посчитать внутреннее состояние после длинного префикса и потом переиспользовать его — это и называется префиксное кеширование (prefix caching).

В классическом трансформере это работает достаточно естественным образом: внутреннее состояние модели на длинном префиксе — это, по сути, набор векторов ключей и значений (KV-кеш) для каждого токена и каждой головы внимания. Современные системы для использования LLM (LLM serving), в частности vLLM с PagedAttention, SGLang с RadixAttention, Preble и другие, построены вокруг того, чтобы хранить и переиспользовать эти KV-кеши максимально гибко: их разбивают на блоки, организуют в виде префиксных деревьев, передают между машинами и так далее.

А если у нас не трансформер?

Но в последние пару лет, как я не раз уже в своём блоге обсуждал, всё более важную роль играют архитектуры, которые либо полностью отказываются от внимания (Mamba, RWKV и другие state-space модели), либо комбинируют его с рекуррентными или SSM-слоями — это так называемые гибридные модели. Например, у Qwen-3.5, которым мы пользовались в экспериментах в этой статье, часть слоёв — обычное внимание, а часть — GatedDeltaNet, рекуррентный слой со скрытым состоянием.

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

   

Таким образом, чтобы продолжить вычисление с позиции , нужно знать только , а не всю историю состояний . Это значит, что для рекуррентных слоёв “честный” KV-кеш в стиле трансформера — это, во-первых, избыточно (нам не нужны все промежуточные состояния), а во-вторых, в случае некоторых архитектур ещё и очень дорого: например, у GatedDeltaNet состояние на одну “голову” имеет размер , тогда как в обычном внимании оно линейно по .

Получается, что для гибридных моделей выбор “либо хранить плотный KV-кеш на каждый токен, либо вообще ничего не хранить и прогонять префикс заново” — какой-то заведомо ложный и неоптимальный. У нас ведь есть и третий вариант: хранить точные рекуррентные состояния в нескольких опорных точках вдоль префикса. Назовём такие точки чекпойнтами (checkpoints).

Идея разреженного префиксного кеширования

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

Приходит новый запрос. Он совпадает с закешированным префиксом до какой-то глубины , а дальше расходится. Мы находим самый глубокий чекпойнт и:

• восстанавливаем оттуда точное рекуррентное состояние ;
• доигрываем рекуррентный слой по токенам , то есть тратим шагов пересчёта.

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

Главный вопрос теперь становится алгоритмическим: где именно расставить чекпойнтов, чтобы минимизировать ожидаемые вычислительные затраты?

Где ставить чекпойнты?

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

   

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

На этом рисунке сверху распределение глубин совпадения будущих запросов с закешированным префиксом (синтетическое, для иллюстрации), а снизу — функция , которая показывает, сколько токенов придётся пересчитать, если совпадение случилось до глубины ; Маркеры ▼ — позиции чекпойнтов при равномерной расстановке:

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

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

Случай 1: когда про распределение мы ничего не знаем

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

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

   

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

В численном виде это выглядит так: положим и запишем , где . Тогда оптимум ровно один (с точностью до перестановки): промежутков длины и промежутков длины . Подставляя обратно, получаем

   

Для худшего случая работает ровно тот же аргумент : по принципу Дирихле, и сбалансированная расстановка достигает нижней границы.

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

Но в этом, конечно, ничего нового нет, интересные вещи начинаются дальше.

Случай 2: распределение неравномерное

В реальности распределения далеко не равномерные. Например, у документов из датасета QuALITY есть резкий пик в районе полной длины документа, потому что вопросы обычно задаются после всего текста. У System Prompts (датасет, собственно, системных промптов) масса сосредоточена ближе к короткому общему началу, потому что пользовательские запросы быстро расходятся; а у NarrativeQA, наоборот, мультимодальное широкое распределение.

В таком случае равномерное размещение неоптимально: лучше “сгущать” чекпойнты там, где у распределения большая масса. Для этой версии задачи мы выписываем точное решение динамическим программированием. Но я всё-таки распишу это подробно, потому что здесь есть пара важных особенностей.

Пусть — это минимальная ожидаемая стоимость обслуживания глубин при бюджете чекпойнтов. Если последний чекпойнт стоит в позиции , то стоимость распадается на две части: оптимальное обслуживание глубин с чекпойнтами (это ) и стоимость пересчёта от чекпойнта до конца, . Минимизируем по выбору и получаем стандартную рекуррентность:

   

В лоб это заняло бы : каждый из элементов таблицы требует перебора кандидатов . Но дальше можно посмотреть на структуру задачи внимательнее.

Введём префиксные суммы и . Тогда , и наша рекуррентность переписывается в виде

   

То есть для фиксированного каждый кандидат соответствует прямой , а вычисление сводится к нахождению её нижней огибающей в точке . Здесь работает классический “трюк с выпуклой оболочкой” (convex hull trick): коэффициенты –s монотонно убывают по s, а точки монотонно растут по , ведь . Это значит, что нижнюю огибающую можно строить инкрементально, а указатель ответа в ней движется только вперёд: каждый слой DP считается за амортизированное время , и всё решение требует только .

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

Вот неравномерный пример (смесь двух гауссианов) и две стратегии размещения шести чекпойнтов, равномерная (оранжевые маркеры) и оптимальная (синие):

Как видите, оптимальная расстановка кучкуется вокруг двух пиков распределения, оставляя долину между ними, где , без покрытия, и ожидаемые затраты падают с 14.2 до 8.6 (на 39%) при том же бюджете чекпойнтов.

Вот для полноты картины развёрнутый пример с тремя распределениями; тут видно, как DP ставит чекпойнты именно там, где сосредоточена масса:

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

Случай 3: оцениваем распределение по истории

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

Это даёт нам доказанная Михаилом лемма об устойчивости: значение функции липшицево по в норме полной вариации, то есть

   

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

Подстановочная гарантия (plug-in guarantee). Пусть — эмпирическая гистограмма после независимых наблюдений из истинного распределения , и — оптимальная расстановка, посчитанная по нашим динамическим программированием. Тогда с вероятностью не меньше выполняется

   

Доказательство тоже короткое: математическое ожидание полной вариации ограничивается через неравенства Коши и Йенсена (), а концентрация вокруг ожидания получается из неравенства Макдиармида, поскольку добавление одного наблюдения меняет полную вариацию не больше чем на .

Подставляя эту оценку в лемму об устойчивости, получаем

   

где — оптимальная стоимость при истинном распределении. То есть отклонение от оптимума убывает как .

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

   

Здесь — индикатор того, что наблюдалось ровно совпадение глубины . Для такой оценки получается естественное разложение типа bias-variance:

   

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

Получается, что теоретически всё вообще замечательно: оптимальное оффлайн-решение по точному распределению устойчиво и к ошибкам оценивания (через лемму об устойчивости + концентрацию эмпирической гистограммы), и к смещению распределения со временем (через bias-variance для экспоненциально взвешенной оценки).

Экспериментальные результаты

Чтобы это проверить, мы взяли три датасета с естественной структурой длинного общего префикса.

1. QuALITY — длинные документы, по каждому из которых задаётся серия вопросов.
2. NarrativeQA — то же самое, но с ещё более длинными документами (целые книги).
3. System Prompts — реальные системные промпты от больших провайдеров LLM, к которым приклеены реальные пользовательские запросы из ShareGPT.

Сравнивали несколько стратегий расстановки чекпойнтов: сбалансированное размещение, блочное (каждые токенов), -размещение, логарифмическое (экспоненциально растущие промежутки) и наше DP-optimal по экспоненциально взвешенной эмпирической гистограмме.

Все методы использовались с фиксированной last-K политикой кеширования записей, чтобы изолировать именно эффект расстановки чекпойнтов внутри отдельной записи (здесь есть ещё отдельная смежная задача про политики admission/eviction в стиле метода Marconi, мы её не трогаем, а просто фиксируем).

Как выглядят реальные распределения

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

Видно, что распределения совсем не равномерные и сильно отличаются друг от друга: у QuALITY резкий пик в районе полной длины документа (медиана 6683 токенов, и почти вся масса сосредоточена около этого пика), у NarrativeQA — широкое многомодальное распределение (медиана около 57k), а у System Prompts масса сидит ближе к началу префикса (медиана 3274). Это ровно тот случай, ради которого затевалась вся теория из случая 2: нет одной фиксированной формы, распределения неравномерные, и наивное равномерное размещение будет сильно проигрывать.

Экономия токенов на длинных последовательностях

NarrativeQA даёт самые длинные тексты — настолько, что наш прототип реализации на доступном железе с ними не справлялся. Зато для этого датасета можно симулировать пересчёт без реального запуска модели и измерить фактор сокращения (recurrent-work reduction factor), то есть во сколько раз пересчёт уменьшается по сравнению со стратегией без кеширования.

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

Реальные измерения времени (wall-clock)

На QuALITY и System Prompts последовательности короче, и можно измерить настоящее время прогона на железе. Wall-clock мы измеряли на репрезентативной группе слоёв (1 attention + 3 GatedDeltaNet) у Qwen-3.5-0.8B, что, конечно, не вполне полноценный production-бенчмарк, но уж что смогли:

На Парето-фронтире DP-optimal либо доминирует над всеми базовыми стратегиями, либо совпадает с лучшим baseline (как правило, это блочное кеширование) но имеет заметно меньшее числом чекпойнтов. На System Prompts, где распределение особенно концентрированное у начала, DP даёт самые большие выигрыши при малых бюджетах — ровно как и предсказывает наш анализ. На QuALITY разрыв меньше, потому что распределение почти точечное около полной длины документа: там и расставлять-то особо нечего, все стратегии быстро упираются в один и тот же пик.

Дополнительно мы проверили, что время инференса действительно почти линейно зависит от числа реально пересчитываемых токенов, с небольшой константой на перенос состояния с CPU на GPU.

Это означает, что фактор сокращения, который мы измеряли на NarrativeQA, действительно превращается в реальную экономию времени.

Как выглядят расстановки на реальных данных

Наконец, любопытно просто посмотреть, как именно DP расставляет чекпойнты на реальных диалогах.

На QuALITY DP-optimal располагает чекпойнты неравномерно, концентрируя их ближе к местам, где у конкретных запросов происходило совпадение в предыдущих раундах:

На System Prompts расстановка ещё более показательная: чекпойнты группируются у короткого начала, где сидит вся масса, а длинный хвост остаётся без покрытия — потому что туда почти никто не доходит.

Выводы и что дальше

Главное ограничение такого подхода — он имеет смысл, когда запросы делят длинный, но не полностью совпадающий префикс внутри одной закешированной записи. То есть это сценарии вроде “много вопросов по одному документу”, “общий длинный системный промпт + разные пользовательские запросы”, ну или RAG.

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

Что ещё важно, в отличие от методов сжатия KV-кеша, при всём этом мы не меняем сами вычисления модели — выход абсолютно идентичен честному префиллу. Соответственно, наш метод хорошо комбинируется со всеми существующими подходами к сжатию KV-кеша для attention-слоёв.

Каковы следующие шаги? Их много! И все надо будет попробовать.

• Полноценная интеграция в production-рантайм. Сейчас наши эксперименты — это прототип; для серьёзных бенчмарков нужно реализовать эффективный API для извлечения и восстановления состояния в Flash Linear Attention или похожих библиотеках. Низкоуровневые ядра (kernels) уже возвращают рекуррентные состояния на нужных позициях, дело за обёрткой.
• Совмещение с политиками admission/eviction в стиле Marconi: они решают, какие закешированные префиксы держать в кеше, а мы — где внутри них ставить чекпойнты. Эти две задачи, по идее, должны естественно дополнять друг друга, но мы пока не понимаем как именно.
• Обобщение теории на префиксные деревья с ветвлением, а не на одиночный префикс. Для типичных топологий (звезда: один документ, много вопросов; гребёнка: длинный prompt, разные хвосты) задача распадается на независимые однопрефиксные подзадачи, но в общем случае это уже более сложная комбинаторика.

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

Сергей Николенко

P.S. Прокомментировать и обсудить пост можно в канале «Sineкура»: присоединяйтесь!

Вступление, в котором актриса неожиданно становится инфраструктурным разработчиком

Поводом для этого поста стала громкая и очень необычная новость: автором нового фреймворка для памяти LLM-агентов под названием MemPalace значится… Милла Йовович. Лилу из “Пятого элемента” и Элис из “Resident Evil” занялась вайб-кодингом. От этой новости, конечно, хочется поморщиться, но отложим на минуту скепсис, потому что повод-то серьёзный.

Память для LLM-агентов — одна из самых интересных и больных тем 2025-2026 годов; есть много подходов, и как это обычно бывает, если у проблемы есть двадцать разных решений, это значит, что ни одно из них не работает по-настоящему хорошо. Так что я воспользуюсь новостным поводом, чтобы разобрать всю область целиком, в которой за последний год накопилось много интересного.

Предупреждаю заранее, что вердикт у меня про MemPalace будет довольно скромный (спойлер: лучшие результаты там получаются в режиме, который не использует никакого “чертога разума”). А самым лучшим на мой взгляд инструментом для агентской памяти назову Hindsight (Latimer et al., 2025, код на GitHub).

Но начнём по порядку; будем идти от истории к современности, по дороге разбираясь, что такое “память” у агента вообще, как её классифицируют и почему это вдруг стало одной из самых интересных подпроблем в прикладных LLM. Вот вам мета-список, обзор обзоров:

• “Memory in the Age of AI Agents” (Hu et al., 2025) — мой основной источник, обзор 47 авторов из декабря прошлого года; он предлагает таксономию по трём ортогональным осям: forms (token-level / parametric / latent), functions (factual / experiential / working) и dynamics (formation / evolution / retrieval), плюс отдельные разделы про бенчмарки, open-source фреймворки и фронтирные направления;
• “Anatomy of Agentic Memory: Taxonomy and Empirical Analysis of Evaluation and System Limitations” (Jiang et al., 2026) — обзор из февраля 2026 с упором на эмпирические проблемы оценивания: насыщение бенчмарков, чувствительность к моделям-оценщикам, зависимость от backbone и так далее; даёт структурную таксономию из 5 типов; из этой статьи можно хорошо понять, почему заявленные в статьях цифры часто оказываются завышенными даже без всякого злого умысла;
• “Cognitive Architectures for Language Agents (CoALA)” (Sumers et al., 2024) — классическая работа с кучей цитирований, которая смотрит на память с нейропсихологической стороны; на эту статью часто ссылаются как на “дефолтную” таксономию памяти в агентах;
• “A Survey on the Memory Mechanism of Large Language Model based Agents” (Zhang et al., 2024) — обзор 2024 года, наверное, самый ранний систематический обзор именно агентской памяти; сейчас, наверное, полезен разве что для истории вопроса и для понимания того, как развивалась постановка задачи.

Вот структура обзора от Hu et al. (2025); на такой уровень детализации мы в этом посте, конечно, не выйдем, но будем стремиться:

Мотивация, где мы разбираемся, зачем LLM-агентам вообще какая-то память

Первый вопрос, возникающий при начале разговора о памяти для LLM-агентов, звучит так: а зачем это вообще? Контексты давно выросли до миллиона, а то и двух миллионов токенов. Да, конечно, весь интернет туда никогда не поместится, но RAG (retrieval-augmented generation) тоже уже очень давно развивается. Казалось бы, можно впихнуть в миллионный контекст все результаты RAG-поиска, да и всё?

На самом деле не совсем.

Во-первых, длинные контексты деградируют. Есть знаменитый эффект lost in the middle (Liu et al., 2023), когда модели хорошо помнят начало и конец своего контекста, а середина проваливается. И чем длиннее контекст, тем сильнее такая “интерференция”: модель начинает путать факты, забывать, что она “узнала” сто страниц назад, и вообще ведёт себя непредсказуемо. На практике это означает, что даже если у вас есть 1M токенов, использовать их напрямую как память для долгой сессии может быть не такой уж хорошей идеей.

Во-вторых, это дорого. И не просто “дорого в деньгах”, хотя и в деньгах тоже: обрабатывать 200K токенов каждый ход, когда у вас длинный диалог, не слишком рационально. Но дорого ещё и по времени отклика: получается, что вам надо перечитывать память целиком для каждого следующего токена, а сложность у трансформеров от размера входа нелинейная. Формально и вовсе квадратичная, но, конечно, миллион токенов контекста подразумевает те или иные сокращающие эту сложность трюки.

В-третьих (и это самое интересное), есть так называемый benchmark-to-deployment gap, который недавно обнаружили авторы MemoryArena (He et al., 2026). Они взяли системы, которые показывают почти идеальные результаты на стандартных бенчмарках агентской памяти (LoCoMo, LongMemEval), и вставили их внутрь реальных агентских задач: веб-навигация, планирование с ограничениями, sequential reasoning.

Вот примеры заданий из He et al., (2026):

И в результате системы, которые давали под 95% на LoCoMo, проседали до 40-60% на MemoryArena. Похоже, что есть некоторая разница между “вспомнить факт” и “вспомнить факт так, чтобы опереться на него в решении задачи”, то есть между пассивным вспоминанием (recall) и активным использованием. У людей, кстати, подобный разрыв тоже может быть очень велик: в одних тестах на остаточные знания вчерашнего школьника просят вспомнить теорему Пифагора и площадь прямоугольника, а в других — посчитать, сколько рулонов обоев надо купить на комнату заданных размеров; и результаты в таких тестах бывают очень разные…

В-четвёртых — и это уже чисто инженерное соображение — нормальная память должна уметь обновляться. Если агент два месяца назад запомнил, что пользователь живёт в Берлине, а вчера тот переехал в Лиссабон, что делать с фактом про Берлин? Забыть, обновить, хранить с пометкой “устарело”?

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

Таксономии, или как можно смотреть на структуру агентской памяти

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

Срез первый, нейропсихологический. Можно проводить аналогии с тем, как устроена память у человека. Например, ставшая уже классической CoALA (Cognitive Architectures for Language Agents; Sumers et al., 2024), которая пытается строить когнитивные архитектуры идёт от классификации памяти по Тульвингу и делит память агента на четыре типа:

• рабочая память (working memory) — то, что прямо сейчас в контексте: “мы сейчас работаем над этим скриптом”;
• эпизодическая память (episodic memory) — записи прошлых эпизодов с временной меткой: “вчера мы разговаривали про X”;
• семантическая память (semantic memory) — фактические знания о мире: “пользователя зовут Алиса, она работает в Google”;
• процедурная память (procedural memory) — навыки и выученные паттерны поведения: “когда пользователь спрашивает про X, нужно сначала посмотреть в Y”.

Это удобная категоризация для понимания, что система памяти должна хранить, но она ничего не говорит про как.

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

Почти все современные системы реализуют три основных операции (академические обзоры называют их formation / management / retrieval, а в терминах Hindsight это retain / recall / reflect, но по сути это одно и то же):

• formation / retain — как информация попадает в память; здесь извлечение фактов, нормализация, сжатие, индексирование и т.д.;
• retrieval / recall — как память возвращается на запрос: здесь может быть похожесть тех или иных вложений, полнотекстовый поиск, поиск по графу, фильтры по времени, переранжирование и т.д.;
• management / reflect — как память эволюционирует при получении новых данных: консолидация, обновление, разрешение конфликтов, забывание и тому подобные процедуры.

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

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

1. Store-first + vector search — сохраняем всё как есть, ищем по сходству; яркие представители — MemPalace и некоторые варианты Supermemory.
2. Extract-and-update — LLM извлекает из разговора факты, складывает в базу, при конфликте обновляет; например, Mem0.
3. OS-like hierarchy — память делится на уровни, и есть явные вызовы инструментов для перемещения между ними; например, MemGPT и Letta.
4. Temporal knowledge graphs — сущности, связи между ними, явная темпоральная структура; здесь Zep и Graphiti.
5. Self-editing notes — атомарные заметки, которые переписываются задним числом при появлении новой информации; например, A-MEM.
6. Verbal RL / reflection — словесный самоанализ как сигнал для обучения без реального обновления весов градиентным спуском; это Reflexion и рефлексии в Generative Agents.
7. RL-trained memory management — обучаем стратегию “добавить / обновить / удалить” обучением с подкреплением по награде из downstream tasks; это Memory-R1.
8. Multi-strategy parallel retrieval + fusion — память использует несколько стратегий поиска параллельно, а потом объединяет результаты через переранжирование; здесь как раз Hindsight и отчасти Graphiti.
9. Graph-based associative recall — здесь к графу прибавляется персонализованный PageRank или что-то в таком духе; пример — HippoRAG.
10. Bio-inspired consolidation — методы менеджмента памяти, вдохновлённые моделями памяти человека: консолидация памяти в несколько стадий, “сон”, gating; здесь к примерам относятся LightMem, SleepGate, EverMemOS.
11. Compression-first — вместо retrieval пытаемся сжать длинный контекст в плотные наблюдения; так работает Mastra Observational Memory.

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

Три столпа агентской памяти, или как всё началось

Generative Agents: поток с взвешиванием

Если у агентской памяти есть одна статья, с которой всё началось, то это она: “Generative Agents: Interactive Simulacra of Human Behavior “(Park et al., 2023). Это знаменитая работа про 25 агентов в симулируемом городке Smallville, где каждый агент прожил несколько “дней”, а один из них организовал вечеринку в честь Дня святого Валентина.

Эту статью многие помнят, но обычно пересказывают общими словами (“ну, там агенты взаимодействовали”), а нам сейчас интересно именно внутреннее устройство агентов.

Поток памяти. Память у Park et al. устроена как простой поток, memory stream — append-only лог наблюдений на естественном языке с временными метками. На каждый запрос агент ранжирует все воспоминания линейной комбинацией трёх нормированных скалярных компонент:

   

Давайте разберём каждый компонент.

Recency — экспоненциальный decay с фактором 0.995 на каждый игровой час с момента последнего обращения к этому воспоминанию. То есть память живёт долго, но медленно истощается, и каждое обращение “освежает” её. Очень похоже на то, как устроена человеческая декларативная память.

Importance — это самый интересный компонент. Его выставляет сама LLM. При записи воспоминания модели задают забавный вопрос: “On the scale of 1 to 10, where 1 is purely mundane (e.g., brushing teeth, making bed) and 10 is extremely poignant (e.g., a break up, college acceptance), rate the likely poignancy of the following piece of memory”. И авторы приводят конкретные примеры: “убрал комнату” → 2, “пригласил на свидание того, кто давно нравится” → 8. Это очень человекоцентричный подход, и на самом деле оказалось, что это очень неплохо работает — такая грубая шкала “насколько это вообще важно” оказалась достаточной для того, чтобы память не затапливалась рутиной.

Relevance — косинусное расстояние между представлением запроса и представлением воспоминания. Это обычный семантический поиск.

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

Рефлексия. Второй важный вклад Park et al. — это механизм рефлексии. Периодически, когда суммарный importance последних добавленных воспоминаний превышает некоторый порог, агент порождает три “важных” вопроса про недавний опыт, под каждый вопрос достаёт релевантные воспоминания и просит LLM синтезировать из них какой-нибудь “higher-level insight”. Пример из статьи: есть воспоминания “Клаус Мюллер читает книгу о джентрификации”, “Клаус Мюллер обсуждает свой исследовательский проект с библиотекарем” и “стол в библиотеке сейчас не занят”; из них можно породить вопрос вроде “Какая тема интересует Клауса Мюллера?”. После поиска ответа и его обдумывания получается новое воспоминание, которое записывается обратно в поток со ссылками на детей, от которых оно произошло. Получается дерево: в основании — сырые наблюдения, над ними — рефлексии, над рефлексиями — мета-рефлексии, и так далее:

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

Заключение. Что получилось в симуляции? Авторы запустили миссию “Изабелла Родригес хочет организовать вечеринку на День святого Валентина” и посмотрели, как распространяется информация. За два игровых дня число агентов, знающих про вечеринку, выросло с 1 (4%) до 13 (52%), а 5 из 12 приглашённых реально пришли 14 февраля. Плотность социальных связей выросла с 0.167 до 0.74. В общем, для 2023 года такой “симулякр” выглядел очень убедительно.

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

MemGPT / Letta: память как операционная система

Следующая знаковая работа вышла через полгода: “MemGPT: Towards LLMs as Operating Systems” (Packer et al., 2023). Идея в том, чтобы попробовать на память для LLM посмотреть как на память в операционной системе: у неё ведь тоже ограниченное количество RAM, и есть уже развитые механизмы иерархических хранилищ, свопа и так далее — может быть, удастся перенести эти идеи на LLM?

У MemGPT получилось два уровня. Главный контекст — это всё, что реально в промпте прямо сейчас:

• системные инструкции — read-only, объясняют агенту, как пользоваться памятью;
• рабочий контекст — фиксированного размера read/write блок, который LLM редактирует явными tool calls; по семантике это скорее всего персона агента и ключевые факты о пользователе;
• FIFO -очередь — скользящее окно последних сообщений с рекурсивной суммаризацией выталкиваемого хвоста.

Внешний контекст (то, чего в промпте нет) содержит:

• хранилище для поиска (recall storage) — полный лог сообщений, по которому можно искать;
• архивное хранилище — текстовое read/write хранилище, куда можно класть всё подряд.

Главное здесь, конечно, в том, как агент этим пользуется. Есть набор tool calls: core_memory_append, core_memory_replace, archival_memory_insert, archival_memory_search, плюс поиск по recall storage. И LLM сама решает, когда что записать или прочитать, используя такой API к памяти.

Была у MemGPT ещё одна идея, которую наследуют все современные агенты вроде Claude Code — это механизм memory pressure warnings. Когда токены в главном контексте пересекают “warning threshold”, система вставляет в разговор служебное сообщение вида “у тебя мало места, пора переместить что-то в архив”. Это аналогично page fault, и агент на него должен реагировать, как процесс в ОС на SIGSEGV; при таком запросе агент вынимает примерно половину окна и заменяет её рекурсивной саммари. Кстати, уже в 2023-м никакого fine-tuning для этого не было нужно, GPT-4 справлялся просто на промпте.

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

Сейчас MemGPT живёт как фреймворк Letta, где те же принципы реализованы в более современном виде.

Reflexion: вербальное обучение с подкреплением

Третий столп — работа “Reflexion: Language Agents with Verbal Reinforcement Learning” (Shinn et al., 2023). Несмотря на название, здесь никакого дообучения по-прежнему нет, а есть его интересная имитация.

Допустим, агент выполнял задачу, но ошибся и получил отрицательное вознаграждение. В классическом RL мы бы взяли градиент от функции потерь, обновили веса стратегии и запустили следующую эпоху. Идея рефлексии в том, чтобы вместо этого попросить LLM просто написать вслух, в чём была ошибка, а потом этот текст прицепить к промпту на следующей попытке. Таким образом весь “градиентный шаг” оказывается внутри контекста, и модель учится, не трогая ни одного параметра.

Архитектура состоит из трёх модулей:

• actor — LLM, которая генерирует действия (обычно в ReAct-стиль: thoughts + actions + observations);
• evaluator — оценивает траекторию; в зависимости от задачи это может быть exact match, та или иная эвристика или LLM-as-a-judge;
• self-reflection — отдельный вызов LLM, который принимает на вход полную траекторию и награду, а на выходе пишет postmortem: “вот здесь я ошибся, потому что X; в следующий раз нужно сначала Y”.

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

Авторы формулируют красиво: текстовая обратная связь даёт “семантический градиент“, конкретное направление для улучшения, выраженное в токенах, а не в числах. LLM преобразует бинарное “ты ошибся” в развёрнутый текст “ты забыл проверить кухонный ящик перед тем, как идти в холодильник”, и это даёт прямое указание, как поправить стратегию: in-context learning делает примерно то же, что градиентный шаг, только без всяких градиентов, не трогая LLM.

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

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

Графы и нейронаука, или как добавить языковой модели гиппокамп

HippoRAG

Параллельно с простейшей идеей памяти как текстового лога шла линия исследований памяти как графа. Одна из самых красивых работ в этом направлении — “HippoRAG: Neurobiologically Inspired Long-Term Memory for LLMs” (Gutiérrez et al., 2024).

Идея ясна из названия: давайте посмотрим, как устроена долгосрочная память у человека (ну, насколько мы её понимаем), и попробуем воспроизвести архитектуру. Упрощённо наша с вами структура памяти такова:

• неокортекс обрабатывает сенсорную информацию и извлекает из неё “понятия”;
• парагиппокампальная область детектирует похожесть между этими понятиями;
• гиппокамп индексирует всё это как ассоциативный граф, сеть связей между понятиями и записями в памяти.

И это всё отлично переносится на RAG:

• неокортекс — это LLM, которая делает OpenIE (Open Information Extraction), то есть разбирает входные пассажи на триплеты (субъект, предикат, объект);
• парагиппокамп — это retrieval encoder, который вычисляет косинус между вложениями сущностей и добавляет synonymy edges между теми, у кого он выше порога ; иначе говоря, синонимичные понятия будут автоматически склеиваться в один узел, без всякого entity resolution;
• гиппокамп — это граф знаний (schemaless knowledge graph), где узлы — это сущности, рёбра — отношения.

А в ответ на запрос HippoRAG не бегает по графу в несколько шагов с помощью LLM (это было бы дорого и медленно), а вместо этого:

• LLM извлекает из запроса именованные сущности;
• эти сущности отображаются в узлы графа как “точки входа”;
• запускается Personalized PageRank (PPR), который стартует с равной вероятностью в узлах из запроса, а потом итеративно распространяется по графу согласно матрице вероятностей переходов;
• в итоге такого блуждания получается распределение вероятностей на всех узлах графа;
• эти вероятности агрегируются обратно и дают собственно ранжирование.

Это оказался действительно очень дешёвый и быстрый метод по сравнению с методами RAG, использующими несколько вызовов LLM подряд, а по сравнению с обычным one-shot RAG просто оказался лучше качеством.

В HippoRAG 2 (Gutiérrez et al., 2025) авторы починили один из главных недостатков первой версии: на простых фактоидных вопросах HippoRAG иногда проигрывал обычному RAG, потому что диффузия на графе размывала простые случаи. Во второй версии добавлена более осмысленная интеграция пассажей из памяти, что помогло лучше строить ассоциативные связи:

Правда, такой подход добавляет и проблем тоже. Многие ошибки теперь приходят из NER / entity extraction, то есть не из поиска по графу, а из того, что LLM не смогла правильно вытащить сущности из текста. По сути, HippoRAG и подобные идеи очень хорошо справляются с самой памятью, и если вы можете построить идеальный граф знаний, дальше примерно так и надо действовать; но работают они настолько хорошо, насколько хорошо работает OpenIE, то есть построение графа знаний.

Zep / Graphiti: графы с учётом времени

В наше время до продакшена аналогичную по духу идею довели система Zep и её движок памяти Graphiti (Rasmussen et al., 2025). Ключевая инновация — bi-temporal knowledge graph, в котором каждый факт хранит две отметки времени: valid_at (когда этот факт стал верен) и invalid_at (когда он перестал быть верен).

Если в январе пользователь сказал “я живу в Берлине”, а в марте — “я переехал в Лиссабон”, то первый факт не удаляется, ему просто проставляется invalid_at = март. И на запрос “где пользователь жил в феврале?” система возвращает правильный ответ.

Хранится это не только как граф: в Zep есть и семантический поиск по вложениям, и старый добрый BM25, и обход графа, а извлечение и индексация происходят асинхронно в фоне, что сильно ускоряет процесс.

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

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

Ещё один интересный архитектурный поворот — идея о том, что память должна быть изменяемой, mutable. Большинство систем, о которых мы говорили, только добавляют новые элементы, но человеческая память, как мы знаем уже сто лет, постоянно консолидируется заново — старые воспоминания переписываются под действием новых. Вот иллюстрация из Xu et al. (2025):

Две недавние работы попробовали воспроизвести это свойство в LLM-агентах.

A-MEM: Zettelkasten для моделей

A-MEM: Agentic Memory for LLM Agents (Xu et al., 2025) берёт за основу метод Zettelkasten — систему карточек, придуманную немецким социологом Луманом в 1970-х и популярную сейчас у адептов Obsidian. Идея в том, что каждое воспоминание — это атомарная заметка, которая ссылается на другие заметки, и граф этих ссылок и есть ваша “внешняя память”.

В A-MEM каждая заметка — это запись из семи полей:

• исходный сырой контент ;
• timestamp ;
• ключевые слова / понятия , выделенные LLM;
• теги , то есть категории, тоже выставленные LLM;
• контекстуальное описание — полнотекстовое описание, сгенерированное LLM;
• векторное представление , которое нужно, чтобы считать похожесть;
• связи — идентификаторы связанных заметок.

Когда появляется новая заметка, A-MEM находит top- ближайших существующих по вложению, а потом просит LLM проанализировать каждую пару и решить, нужно ли создать связь.

Killer feature здесь в том, что когда новая заметка подсоединяется к старой, LLM просят обновить контекстное описание, ключевые слова и тэги у старой заметки в свете новой информации. Просят буквально: “вот старая заметка X, вот новая Y, которая с ней связана, а теперь перепиши X так, чтобы она учитывала, что тебе рассказала Y”. Авторы называют это memory evolution: старые воспоминания эволюционируют по мере накопления новых.

Memory-R1: add/update/delete через RL

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

Статья “Memory-R1: Enhancing Large Language Model Agents to Manage and Utilize Memories via Reinforcement Learning” (Yan et al., 2025) не предлагает вручную выписывать правила обновления памяти и не оставляет это на откуп стандартной LLM, а выучивает их через RL.

Агент выбирает для каждого нового кусочка информации одно из четырёх действий: ADD, UPDATE, DELETE, NOOP. Вот сравнение с использованием LLM для этого:

Награда получается по окончательным ответам агента на собственно задачи, downstream tasks. Прямых меток “какая операция правильная” у нас вообще нет, взять их неоткуда, и мы обучаемся по результату: если сгенерированный в итоге ответ оказался верным, политика награждается.

   

Разумеется, это классическая задача обучения с подкреплением; авторы пробуют PPO и GRPO (Group Relative Policy Optimization — тот самый алгоритм, который предложил в своё время DeepSeek). GRPO, кстати, сходится быстрее благодаря групповой нормализации, но в итоге оба приходят примерно к одной точке.

Особенно любопытен в этой работе размер обучающей выборки: всего 152 QA-пары. И этого крохотного датасета хватает, чтобы получить существенный прирост относительно предыдущих решений вроде MemoryOS.

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

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

Open-source фреймворки, или что можно взять и использовать прямо сейчас

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

Mem0: простой API, большое сообщество

Mem0 (Chhikara et al., 2025) — кажется, чемпион среди memory ecosystems по числу звёзд на GitHub. Под капотом у него Qdrant / Chroma / PGVector для семантического поиска, key-value store для структурных запросов, опционально Neo4j для хранения графа. Когда вы вызываете add(), LLM извлекает из сообщения факты и предпочтения, сохраняет их, дедуплицирует, при конфликте обновляет. Когда вызываете search() — ранжирует всё по весам relevance / importance / recency.

Главное достоинство — очень простой API, реально одна строчка добавляет память, и Mem0 до сих пор представляет собой хороший baseline, который легко использовать.

Letta (MemGPT) и Zep / Graphiti

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

LangChain / LangMem, LlamaIndex, CrewAI, Cognee

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

Самый популярный такой фреймворк — LangChain. В нём, конечно же, есть модуль LangMem, в котором очень просто реализована процедурная память: агент переписывает собственный system prompt по мере обучения.

У LlamaIndex есть механизм памяти в виде composable memory blocks с приоритетным бюджетом токенов.

В фреймворке CrewAI есть мультиагентная общая память, похожая на первую работу, которую мы обсуждали, Park et al. (2023). Там даже есть явные веса recency / similarity / importance.

Отдельно отмечу Cognee, которая представляет собой отдельную библиотеку памяти с движком на базе пайплайна “Extract → Cognify → Load”. Cognee можно встраивать куда угодно, например в виде плагина для Claude Code:

В общем, если вы уже делаете LLM-based агентов в каком-то конкретном стеке, скорее всего, у вас уже есть под рукой тот или иной механизм памяти.

Большая тройка

Ну и напоследок упомяну, что происходит на фронтире: в течение 2025 года все три главных игрока — OpenAI, Anthropic и Google — добавили персистентную память с возможностью импорта и экспорта. Причём подходы у них философски разные: ChatGPT и Gemini хранят память прозрачно и используют её автоматически, а у Claude каждый разговор начинается с чистого листа, а память подгружается только через явные tool calls, видимые пользователю.

Вот подробное описание того, как работает память в Claude. Особых интересных деталей про устройство автоматической памяти там не написано, но видно, что Anthropic явно считает файлы вроде CLAUDE.md тоже механизмом памяти (отдельным от внутренней памяти).

Что на фронтире, или биомимикрия, мультиграфы и крепкий сон для LLM-агентов

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

Эмуляция сна: явная консолидация памяти

LightMem (Fang et al., 2025) и родственные работы пытаются построить аналог многостадийной модели памяти Аткинсона-Шиффрина, построенной ещё в 1960-х:

Для нас тут интересно наличие явного обновления во время сна: консолидация памяти отделена от её применения и происходит в фоновом режиме. Это можно реализовать и в LLM-агентах как “сон” между вызовами. В LightMem главная мотивация для такого сна состоит в том, чтобы ускорить потом вызов агента, потому что ему не нужно будет во время инференса заниматься консолидацией памяти:

SleepGate (Xie, март 2026) борется с proactive interference — тем самым эффектом, когда накопленная устаревшая информация приводит к деградации поиска:

Это похоже на LightMem идейно, но сделано интереснее с математической точки зрения: обновляется здесь не просто абстрактное хранилище памяти, а прямо KV-кэш.

Новые примитивы для хранения элементов памяти

EverMemOS (Hu et al., январь 2026) вводит примитив MemCell, в который конвертируются факты, куски диалогов и вообще всё, что хочется запомнить, организует MemCells в MemScenes и потом устраивает на них retrieval:

MAGMA (Jiang et al., январь 2026) строит multi-relational подграфы (entity, episodic, temporal, semantic) и добавляет Temporal Inference Engine, которая приводит темпоральные выражения в хронологическое представление.

Новые принципы работы с памятью

Nemori (Nan et al., 2025) применяет принцип свободной энергии, как его понимают в нейронауках: агент предсказывает содержание эпизода из имеющейся базы знаний, и разрыв между предсказанием и реальностью определяет, что именно нужно добавлять в память.

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

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

Бенчмарки, или как мы измеряем память

Я никогда не любил цитировать числа на бенчмарках и проценты прироста; мне всегда казалось, что главное идеи, а циферки дело наживное и вообще десятое. Но всё-таки пора сказать пару слов и про бенчмарки, потому что при реальном выборе того, чем пользоваться, надо понимать слова “система A даёт 91% на X, а система B — 89% на Y”. Но они ничего не значат, если не понимаешь, что именно измеряют X и Y.

LoCoMo (Maharana et al., 2024) — пожалуй, главный датасет для памяти, использующий очень длинные диалоги: по 300 ходов, 35 сессий на диалог, пять типов вопросов (single-hop, multi-hop, temporal, commonsense, adversarial), диалоги с событиями и даже мультимодальными элементами.

LoCoMo стал де-факто стандартом для long-term conversational memory, но здесь важно отметить, что на LoCoMo длинные контексты моделей могут частично решать задачу и вовсе без внешней памяти, просто запихнув всё в контекст. Так что проценты на LoCoMo сильно зависят от базовой LLM и могут в основном ею и обеспечиваться.

LongMemEval (Wu et al., 2024) — 500 вопросов и пять способностей систем, которые здесь проверяются: information extraction, multi-session reasoning, temporal reasoning, knowledge updates, abstention.

На момент выхода даже GPT-4o в full-context режиме (~115K токенов) даёт всего 30-70%; этот датасет сложнее LoCoMo, и его сложнее решить просто длинным контекстом.

BEAM (Beyond a Million Tokens; Tavakoli et al., 2025) — 2000 валидированных вопросов и 10 миллионов токенов контекста, проверяющих десять различных способностей, в том числе разрешение противоречий и упорядочивание событий. Датасет, конечно, порождён не без LLM, но аккуратно:

При таком масштабе контекста уже никакие базовые модели не работают: вам непременно будет нужна правильная архитектура памяти.

Сию секунду на BEAM лидером является система Hindsight с 64.1%, причём следующая запись в leaderboard даёт только 40.6%. Разрыв очень большой, так что давайте его отметим, а про Hindsight поговорим ниже подробнее.

MemoryArena (He et al., 2026) — ещё один очень популярный бенчмарк, о котором я говорил в начале поста. Он измеряет память внутри стандартных агентских задач: веб-навигация, планирование, sequential reasoning.

Как мы уже обсуждали, результат здесь в том, что модели, которые могут давать 95% на LoCoMo в чистом воспоминании, набирают только 40-60% на MemoryArena, где факты из памяти надо использовать. Мне кажется, MemoryArena (и её родственник Mem2ActBench) станут главными бенчмарками для оценки систем памяти в 2026 году, потому что они ставят правильный практический вопрос.

HaluMem (Chen et al., 2025) — это отдельный бенчмарк, измеряющий галлюцинации в самих операциях с памятью, то есть при извлечении фактов и порождении того, что попадает в память. Вот примеры галлюцинаций из HaluMem:

Это особенно важно для систем, которые используют LLM для порождения записей в памяти, потому что если LLM при записи факта что-то выдумает, этот выдуманный факт навсегда останется в базе. И HaluMem проверяет как раз эти галлюцинации при извлечении фактов:

MemPalace, или что же там всё-таки Милла Йовович

Ну что ж, вот мы и подошли к главному поводу для поста. MemPalace сделали вдвоём Милла Йовович и Бен Сигман, основной её технический соавтор. Репозиторий появился 5 апреля 2026 года, за пару дней набрал около тысячи звёзд, и на момент написания поста активно обсуждается в индустрии.

MemPalace берёт за основу метод локусов (method of loci) — восходящую ещё к Древней Греции мнемоническую технику, которой пользовались ораторы: чтобы запомнить длинную речь, нужно “расставить” её фрагменты в воображаемом здании, а потом мысленно идти по комнатам и “подбирать” каждую часть. От этой техники и происходит выражение memory palace, которое по-русски принято называть “чертогами разума”.

По идее, MemPalace хранит память в виде пространственной иерархии:

• wings — “крылья” верхнего уровня, каждый посвящён человеку или проекту;
• rooms — комнаты внутри крыла, посвящённые конкретным темам;
• halls — “коридоры” памяти, общие для всех крыльев, с пятью фиксированными категориями: facts, events, discoveries, preferences, advice;
• tunnels — прямые сквозные связи, когда одна и та же комната существует в разных крыльях;
• closets — сокращённые саммари, ссылающиеся на оригиналы;
• drawers — сами оригинальные файлы, хранящиеся полностью и никогда не суммаризуемые.

Вот картинка из поста Николаса Родса с анализом MemPalace:

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

Вторая ключевая особенность — zero-LLM write path, то есть при сохранении в память не вызываются LLM, а используются только детерминированные правила. LLM включаются только в момент чтения, для переранжирования и рефлексии.

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

Но вот дальше…

В общем, при внимательном анализе выяснилось, что MemPalace вообще не работает. Например, он заявляет 96.6% Recall@5 на LongMemEval в режиме “raw verbatim, zero API calls”. Это, если принимать на веру, больше, чем у всех конкурентов, и авторы пишут “the highest published result”. Но на самом деле 96.6% получается в режиме, в котором:

• документы LongMemEval хранятся дословно в ChromaDB;
• поиск — дефолтный embedding search из ChromaDB;
• и никакие wings, rooms, halls, tunnels и closets в собственно retrieval не участвуют.

То есть 96.6% — это, по сути, метрика качества дефолтных эмбеддингов ChromaDB на LongMemEval, не имеющая никакого отношения к “дворцовой архитектуре”. Более того, при попытке включить собственно механизмы “чертогов разума” числа уменьшаются, и лучшим остаётся raw-режим. А на том же LoCoMo, где простое решение на эмбеддингах работает хуже, MemPalace даёт 60.3% R@10, что заметно меньше Hindsight (89.61%) и даже MAGMA (70%).

Ну и просто рекомендую прочитать этот тред, в нём ещё много ярких примеров.

К чести авторов, 7 апреля 2026 они выпустили обновление README, подписанное “Milla Jovovich & Ben Sigman”, в котором признают ряд ошибок и заявляют, что будут их исправлять.

На самом деле сам концепт такой организации памяти в форме пространственной иерархии — это интересно, и не только как метафора, но и как, например, отличный способ улучшить интерпретируемость. Но пока это всё, похоже, совсем не production-ready, пусть Милла с Беном ещё поработают.

А о том, что работает прямо сейчас, поговорим в следующем разделе.

Hindsight, или современный пример хорошей системы агентской памяти

Система Hindsight (репозиторий) описана в работе “Hindsight is 20/20: Building Agent Memory that Retains, Recalls, and Reflects” (Latimer et al., 2025). На мой взгляд, это отличная система, которая и теоретически интересна, и практически достигает высоких результатов.

Без большого собственного опыта я, конечно, не возьмусь сказать, что Hindsight строго лучшая память для LLM-агентов, но выбрал именно её как пример современной системы для подробного разбора. Тем более что, как говорит, разумеется, табличка из той же статьи, Hindsight включает в себя много разных компонентов, которые по отдельности встречаются в других системах:

Давайте разбираться.

Четыре сети памяти

Hindsight разбивает память агента на четыре эпистемически разные сети:

• world network содержит объективные факты о мире, вроде “Париж — столица Франции”;
• еxperience network — опыт самого агента, от первого лица: “я спросил у Алисы про X, она ответила Y” или “Я пытался применить подход Z, и он не сработал”;
• observation network — синтезированные профили сущностей (entity summaries), построенные из и ; они должны быть скорее нейтральными и автоматически обновляться при поступлении новой информации;
• opinion network — субъективные убеждения с оценкой уверенности и временной меткой: “Я думаю, что Y — неплохая идея (confidence 0.7, обновлено в марте)”.

Каждый memory unit хранит собственно текст, его векторное представление, интервал occurrence time, время упоминания, тип сети, опционально confidence и метаданные.

А потом при действиях типа reflect агент может перерабатывать и обновлять свои мнения, не трогая базовые факты; а на запрос он может искать “что я знаю про X” отдельно от “что я думаю про X”. Здесь на самом деле интересный эффект: Hindsight строит архитектуру исходя из эпистемологии, и это, видимо, оказывается важно, другие системы так не делали.

Вот общая высокоуровневая схема:

TEMPR: параллельный multi-strategy retrieval с RRF

Recall в Hindsight реализован через компонент TEMPR (Temporal Entity Memory Priming Retrieval). На каждый запрос параллельно запускаются четыре стратегии извлечения.

1. Semantic — косинусная похожесть через HNSW-индекс на pgvector.
2. Keyword — обычный полнотекстовый BM25.
3. Graph — распространение активации по графу, где узлы — сущности, а рёбра — entity/temporal/semantic/causal связи.
4. Temporal Graph — rule-based и seq2seq парсинг дат, нормализация темпоральных выражений и сравнение memory occurrence intervals.

Несколько стратегий здесь нужны, потому что разные вопросы требуют разных стратегий: “Когда я последний раз говорил про X?” — temporal graph; “Что я знаю про компанию Google?” — entity graph; “Какие мои заметки похожи по смыслу на эту идею?” — semantic; “Когда мы раньше упоминали Kubernetes?” — это чистый BM25.

А потом все четыре списка результатов сливаются через Reciprocal Rank Fusion (RRF):

   

Здесь — конкретный memory unit, — его ранг в списке от -й стратегии, а — сглаживающая константа (обычно около 60). Идея RRF очень простая: вклад стратегии в общий рейтинг элемента обратно пропорционален его рангу в этой стратегии, причём делает так, что топ-1 и топ-2 отличаются не слишком радикально, а топ-50 и топ-100 — практически одинаковы. Это хорошая базовая стратегия для ансамблирования в данном случае.

Но потом есть ещё и относительно тяжёлая модель-reranker (cross-encoder), через которую проходят результаты RRF, так что общая схема такова:

CARA: reflect в приоритетном порядке

Reflect в Hindsight реализован через компонент CARA (Coherent Adaptive Reasoning Agents). Когда агент хочет “подумать” о чём-то, CARA:

• вызывает TEMPR, чтобы достать релевантные memory units из всех четырёх сетей;
• загружает behavioral profile агента и background;
• порождает ответ, при этом обрабатывая память в приоритетном порядке: сначала opinions и observations (синтезированные данные), потом — raw world/experience facts; иначе говоря, система сначала смотрит, не думала ли уже об этом и не приходила ли к выводам, и возвращается к сырым фактам только по необходимости;
• формирует новые opinions с confidence scores;
• обновляет opinion network.

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

Вот структура работы CARA:

А вот общая иллюстрация архитектуры Hindsight со всеми компонентами, которые мы пока что обсудили:

Disposition parameters: личность агента влияет и на память

Ещё одна штука, которая мне лично показалась очень интересной, — это disposition parameters (параметры предрасположения). У Hindsight-агента можно задать три личностные черты на шкале 1-5:

• скептицизм (skepticism; 1 trusting → 5 skeptical),
• буквальность (literalism; 1 flexible → 5 literal),
• эмпатия (empathy; 1 detached → 5 empathetic),

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

Суть в том, что в разных проектах нужен разный “стиль” интерпретации памяти. Для аналитического агента можно поставить skepticism = 4, literalism = 4, empathy = 1, а для ассистента, с которым надо поговорить по душам — skepticism = 2, empathy = 4. Это меняет то, как он цепляется за свидетельства во время фазы reflect.

Из одних и тех же фактов агенты с двумя разными параметрами сделают совсем разные выводы:

Это, по-моему, отличная идея, которая одновременно и легко интерпретируется, и улучшает результаты.

Цифры

И всё-таки, раз уж обсудили бенчмарки, давайте и про циферки упомянем, потому что здесь они шикарные. На LongMemEval S setting, 500 вопросов:

То есть Hindsight с открытой 20-миллиардной моделью обходит full-context GPT-4o (1.7 триллиона параметров, кажется?) на LongMemEval более чем на 23 очка.

На LoCoMo опять побеждает Hindsight с очень значительным отрывом:

А последняя новость, уже не из статьи, а из поста авторов от 2 апреля 2026, состоит в тестировании на BEAM, свежем бенчмарке, который мы обсуждали выше:

И здесь тоже мы видим 64.1% против 40.6% у следующей системы в самом сложном варианте.

Главное в этих результатах не в том, что Hindsight занял первую строчку, а в самих значениях отрывов — на десятки процентов практически везде, где это возможно! И тот самый обзор “Memory in the Age of AI Agents” (Hu et al., 2025), на который я ссылался выше, оценивает Hindsight как систему, занимающую первое место в Agent Memory Benchmark (AMB) в совокупности по LongMemEval, LoCoMo, BEAM, LifeBench и PersonaMem.

Так что если нужно что-то взять в production прямо сейчас, я бы брал именно Hindsight. Да и для подробного обзора хорошая система, потому что в ней все базовые системы достаточно продвинутые, но не безумно сложные.

Выводы и заключение

Попытаюсь сделать несколько общих выводов из всех работ, которые я тут перечитал и пересказал.

Во-первых, качество retrieval-стратегии важнее сложности хранилища. Hindsight побеждает на бенчмарках не потому, что у него какая-то хитрая база данных, а потому, что у него четыре стратегии извлечения с RRF-слиянием. HippoRAG побеждает на multi-hop не потому, что у него навороченный knowledge graph, а потому, что он делает один шаг PPR вместо трёх LLM-вызовов. Системы, которые полагаются исключительно на векторную похожесть, стабильно проигрывают.

Во-вторых, бенчмарки бенчмаркам рознь. Это давно всем известно, но вот и задокументировано в MemoryArena: система, которая даёт 95% на LoCoMo, может давать 40% на реальной агентской задаче. Не уверен, что мы с этим разрывом скоро разберёмся, но как минимум MemoryArena и Mem2ActBench задают правильные вопросы, и это уже прогресс.

В-третьих, архитектуры памяти начинают учиться. Memory-R1 — это, по-моему, самое важное из того, что вышло в 2025-2026. Он показывает, что политику управления памятью можно учить на ~150 примерах по downstream reward. Плюс ещё и bio-inspired направление (LightMem, SleepGate, EverMemOS) двигается в ту же сторону. Мне кажется, что в ближайшие пару лет написанные вручную стратегии управления памятью постепенно уступят обучаемым.

А в целом это одна из самых интересных областей в прикладных LLM прямо сейчас. Год назад казалось, что агенты упираются в недостаточно хорошие рассуждения; полгода назад — что в tool use; а сейчас я всё больше уверен, что следующее важное “узкое место” — это именно память. А вот Милла Йовович, увы, подвела.

Сергей Николенко

P.S. Прокомментировать и обсудить пост можно в канале «Sineкура»: присоединяйтесь!