Сжатие памяти AI-агентов без потери данных

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

Зачем сжимать

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

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

Инструменты сжатия

Несколько техник, от простых к глубоким:

• Суммаризация — сворачивание старой истории в резюме. Иерархическая суммаризация (резюме резюме) держит самый старый материал крошечным, но при этом сохраняет общую нить событий.
• Выборочное удержание (pruning) — сохранение критически важных фактов, отсев шума. Не всё стоит запоминать, и явная фильтрация часто полезнее слепого сжатия.
• Офлоадинг — вынос объёмного контента на диск с указателем и кратким превью. Полный текст возвращается только по запросу, а агент держит в контексте лишь ссылку.
• Провайдерское сжатие — некоторые API автоматически сжимают старые ходы разговора при достижении порога (сообщается о сжатии ~80%), чтобы длинная сессия продолжала работать.
• Структурированная дистилляция — упаковка каждого обмена в плотную символическую форму. На инженерных разговорах достигается ~11x, а специализированные диалекты памяти заявляют значительно более высокие коэффициенты.

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

Ловушка: потери непредсказуемы

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

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

Паттерн: храни оригинал, сжимай копию

Чистый ответ — отказаться от ложного выбора между «без потерь, но огромно» и «компактно, но с потерями» — и хранить оба варианта. Так устроен слой семантической памяти MemPalace в Munder Difflin, и это та часть, которую стоит позаимствовать:

• Каждая сырая память живёт в drawer, который хранит полный оригинал, дословно — без суммаризации, без пересказа. Поиск возвращает именно те слова, которые вы сохранили.
• При включении сжатия рядом стоит closet с компактным символическим резюме (диалект AAAK в MemPalace даёт ~30x сжатие), сохраняющим семантическую и реляционную суть.
• При пробуждении агент загружает сжатые closets — поглощая большой период истории за несколько тысяч токенов — при этом глубокий lookup всегда может вытянуть lossless drawer.

На стороне обвязки всё намеренно тонкое: каждый агент пишет память в plain markdown, а фоновый процесс feeding'ает заметки в общий дворец. Recall — это search или wake-up. Markdown — источник истины; сжатый индекс — ускоритель, построенный поверх него, а не вместо. Этот порядок и есть весь трюк: сжатие покупает скорость; сохранённый оригинал покупает корректность. Вы получаете компактный дайджест при пробуждении, никогда не ставя единственную копию на кон резюме.

Когда не стоит сжимать

Сжатие — компромисс, не дефолт. Пропустите его (или всегда храните оригинал рядом), когда:

• Рабочий набор уже помещается комфортно — сжатие крошечного контекста добавляет задержку и риски потерь без выгоды.
• Задача аудито- или комплаенс-критична и нужен точный исходник, слово в слово.
• Контент полон исключений и краевых случаев, которые суммаризация склонна сглаживать.
• Данные несут классификацию или происхождение, которые должны travelling'ать вместе с ними.

Сквозное правило остаётся тем же: никогда не позволяйте сжатой копии стать единственной копией того, что вам может понадобиться защитить или отследить.

Связь с RAG

Сжатие памяти — не то же самое, что RAG. Retrieval находит релевантные чанки; сжатие меняет плотность хранения и загрузки этих чанков. Они комплементарны: вы делаете retrieve, и то, что вы retrieve'ите, может быть сжато для более компактного, чёткого контекста. Два слоя работают вместе — сжатие уменьшает то, что попадает в контекст, а retrieval решает, что именно оттуда извлекать.

Сколько можно сжимать

Столько, сколько хотите — если lossless-оригинал сохранён и связан указателем. Задача сжатой формы — быстрый recall; корректность живёт в нетронутом исходнике, к которому всегда можно откатиться. На практике это означает, что агрессивное сжатие (20-30x) допустимо, когда поверх него работает надёжная система указателей обратно к оригиналам. Без таких указателей даже умеренное сжатие (3-5x) становится рискованным.