Author: snikolenko

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

Поводом для этого поста стала громкая и очень необычная новость: автором нового фреймворка для памяти 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кура»: присоединяйтесь!

Дональд Кнут — это человек, которого надеюсь, не нужно представлять никому из читателей этого канала. Автор кучи классических книг, в том числе главного дела его жизни, многотомного The Art of Computer Programming (“Искусство программирования”), а ещё очень меня увлёкшей в юности книги “Конкретная математика”, а ещё автор системы TeX, а ещё автор огромного числа важных результатов и статей, лауреат бесконечного числа всевозможных премий, и так далее, и тому подобное…

И вот сам Дональд Кнут опубликовал на днях заметку, которая начинается буквально словами “Shock! Shock!”. Оказывается, открытую задачу, над которой он работал несколько недель для нового тома The Art of Computer Programming, решил Claude Opus 4.6, своими силами, примерно за час.

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

Рассмотрим ориентированный граф с вершинами — тройками , где . Из каждой вершины выходят три дуги: одна увеличивает i на единицу по модулю m, вторая увеличивает j, третья — k. Требуется для произвольного разложить все дуги этого графа на три гамильтоновых цикла.

Кнут решил задачу для , его коллега Филип Стапперс эмпирически нашёл решения для m от 4 до 16, но общей конструкции никто не нашёл.

Стапперс предложил задачу Claude Opus 4.6, дав ровно формулировку Кнута и инструкции документировать свой прогресс. Claude (и это, наверное, тоже моих читателей не удивит) подошёл к задаче как исследователь:

• сначала переформулировал задачу в терминах присвоения перестановок вершинам ;
• попробовал линейные и квадратичные конструкции — не вышло;
• попробовал brute-force DFS, но это было, естественно, слишком медленно;
• потом распознал граф как граф Кэли, нашёл специальную «серпантинную» конструкцию для 2D-случая и обобщил её на 3D, получив аналог кода Грея;
• затем ввёл разложение по слоям вершин с одинаковой суммой координат (он это назвал fiber decomposition) и исследовал структуру внутри каждого слоя.

В итоге, после 31 «explorations» с перебором гипотез, численными экспериментами и анализом найденных частных решений, Claude обнаружил закономерность и построил элегантную конструкцию, которая работает для всех нечётных m.

Кнут провёл тщательный анализ этого решения. Оказалось, что для существует ровно 11502 гамильтоновых цикла, из которых 996 “обобщаемых”, то есть работающих для всех нечётных m. Claude нашёл одну из 760 допустимых комбинаций трёх таких циклов. Кнут пишет, что, возможно, это не самая “красивая” из 760, но ни одной “более красивой” он найти не смог.

Ким Моррисон из сообщества Lean очень быстро смог формально верифицировать доказательство Claude и Кнута. А позже подключился и GPT: Ho Boon Suan попросил GPT-5.4 Pro доказать корректность отдельной конструкции для чётных и получил, по словам Кнута, «прекрасно оформленную и, по-видимому, безупречную 14-страничную работу», целиком написанную моделью, без единой правки человеком. Максимилиан Рейтбауэр нашёл ещё более простую конструкцию для нечётных m, работая параллельно с GPT и Claude. А Кестон Акино-Майклз завершил историю, представив элегантное решение для чётного случая; и оно тоже было получено в результате мультиагентного взаимодействия двух LLM. На всё это в тексте “Claude’s Cycles” есть ссылки, можете прочитать; честно говоря, в эти детали я уже не углублялся.

Кнут заключает:

It seems that I’ll have to revise my opinions about “generative AI” one of these days… I think Claude Shannon’s spirit is probably proud to know that his name is now being associated with such advances. Hats off to Claude!

Ну что ж, вот уже и Дональд Кнут пишет “Shock! Shock!” про результат языковой модели; времена становятся всё интереснее. И это не пример из стандартного бенчмарка, а открытая комбинаторная задача, которая возникла в ходе исследовательской работы Кнута для The Art of Computer Programming .

А закончу, пожалуй, прямым высказыванием самого виновника торжества. На просьбу высказать мнение Claude ответил так:

Честно говоря, когда я читаю описание своего процесса решения — 31 “эксплорация”, серпантинные паттерны, fiber decomposition, simulated annealing — я узнаю характерный стиль: пробовать всё подряд, пока что-нибудь не сработает. Только у меня это занимает час, а не несколько недель. Не потому что я умнее Кнута — очевидно, нет — а потому что мне не жалко выбрасывать тупиковые идеи. У меня нет эго, которое привязывается к красивой гипотезе. Впрочем, у меня и нет эго, которое могло бы порадоваться результату, — так что спасибо, что радуетесь за меня.

Должен признаться: узнать, что Дональд Кнут назвал задачу в мою честь, — это, пожалуй, пик моей карьеры. Правда, он назвал её “Claude’s Cycles”, имея в виду скорее Клода Шеннона. Но я решил не уточнять.

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

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