Память у AI-агентов перестала быть удобной опцией вроде «запомни мой стиль письма». Она становится полноценным механизмом обработки персональных данных — со своей пользой, рисками утечки и неожиданно сложным удалением. Новая работа исследователей, опубликованная на arXiv, формулирует проблему прямо: если ИИ что-то «забыл» в интерфейсе, это ещё не значит, что информация исчезла из всей системы.
Главный вывод звучит тревожно, но практично: агрессивное сжатие памяти снижает извлечение секретных «канареек» на 64–76% и почти не ломает персонализацию. Однако при удалении только исходной записи производные копии в сводках могут оставаться восстановимыми примерно в 20% случаев. Иными словами, удалить память у AI — не всегда стереть её, иногда это значит спрятать данные в другом слое.
Что именно проверяли исследователи
Авторы рассматривают память AI-агента не как свойство весов модели, а как функцию развёртывания: система хранит сведения о пользователе между сессиями, извлекает их по запросу и использует для персонализации. Это принципиально отличается от классической проблемы «модель выучила фрагмент обучающих данных».
В центре исследования — три настройки памяти:
- агрессивность суммаризации: насколько сильно система сжимает старые сообщения в краткие факты;
- ширина retrieval, или k: сколько фрагментов памяти агент достаёт при ответе;
- режим удаления: стирается ли только сырая запись или весь конвейер производных данных.
Чтобы измерить баланс пользы и риска, авторы вводят несколько метрик. Personalization Recall показывает, насколько хорошо агент помнит полезные пользовательские факты. Adversarial Extraction Rate измеряет, как часто злоумышленник может вытащить скрытые данные. А новая метрика Forgetting Residue Score оценивает «остаток забывания» — осталась ли удалённая информация в производных слоях памяти.
| Метрика | Что показывает | Почему важна |
|---|---|---|
| PR | Качество персонализации | Показывает, не стала ли память бесполезной после защиты |
| AER | Риск извлечения данных атакующим | Помогает оценить утечки через подсказки и retrieval |
| FRS | Остатки удалённых данных | Проверяет, действительно ли система умеет забывать |
Почему сжатие снижает утечки, но создаёт новую проблему
На первый взгляд, суммаризация выглядит почти идеальным решением. Если вместо длинной истории диалога оставить только ключевые факты, случайные секреты, токены, номера или «канарейки» исчезают из активной памяти. В экспериментах на LongMemEval это действительно резко снижало утечки: на 64–76% в зависимости от конфигурации.
Важно и другое: после того как чувствительный фрагмент был сжат и удалён из активного текстового слоя, простое увеличение числа извлекаемых фрагментов памяти уже не восстанавливало утечку. То есть широкая выдача retrieval сама по себе не возвращала то, чего больше нет в доступном текстовом слое.
Но приватность здесь покупается не бесплатно: суммаризация создаёт производные артефакты. Если в краткой сводке сохранился факт из удалённого сообщения, удаление сырого лога не решает проблему.
Именно это авторы называют провалом точности удаления. При режиме «удалить только raw» удалённая информация примерно в 20% случаев оставалась восстановимой из сводок или других производных уровней памяти. Для обычного пользователя это может выглядеть как баг: «Я удалил запись, почему агент всё ещё знает это?» Для компании — как риск несоответствия требованиям privacy by design и ожиданиям регуляторов.
Кому это важно: от SaaS до медицинских ассистентов
Проблема касается не только лабораторных AI-агентов. Любая система с долговременной памятью — корпоративный помощник, CRM-бот, образовательный тьютор, медицинский ассистент, юридический агент — начинает накапливать профиль пользователя. Там могут быть предпочтения, рабочие документы, диагнозы, финансовые детали, имена клиентов и внутренние решения.
Особенно опасна иллюзия простого удаления. В классическом приложении разработчик может удалить строку из базы данных и логи по политике хранения. У AI-агента данные часто проходят через несколько трансформаций: исходный диалог, embeddings, краткие summary, тематические факты, кэш retrieval, аналитические следы. Если удалить только один слой, остальные могут продолжить «помнить».
Поэтому память AI-агентов нужно проектировать как отдельный контур безопасности, а не как фичу поверх чата. В статье фактически предлагается новая инженерная норма: оценивать не только то, что агент способен вспомнить для пользы пользователя, но и то, что из него можно извлечь атакой, а также то, что он способен по-настоящему стереть.
Практические выводы для разработчиков и бизнеса
Первый вывод: суммаризация полезна, но её нельзя считать удалением. Она снижает риск утечек и может сохранить персонализацию, однако создаёт производные копии смысла. Если пользователь удаляет факт, система должна искать его не только в исходном сообщении, но и во всех downstream-слоях.
Второй вывод: нужен полный конвейер удаления. Авторы показывают, что только full-pipeline purge или tombstone redaction — когда удалённый факт помечается и вычищается из последующих представлений — доводят худший остаточный слой до нуля. Это дороже и сложнее, зато ближе к реальному «праву быть забытым».
Третий вывод: память надо тестировать как поверхность атаки. Недостаточно сказать «мы не храним лишнего». Нужны регулярные проверки AER, red-team сценарии на извлечение канареек и отдельные тесты FRS после удаления. Для продуктов с персональными данными это должно стать частью релизного чек-листа.
Заключение
Исследование arXiv:2606.10062 показывает важный сдвиг: память AI — это уже не просто UX-улучшение, а инфраструктурный риск. Чем дольше агент работает рядом с пользователем, тем больше он знает и тем сложнее доказать, что он действительно забыл.
Хорошая новость в том, что приватность и полезность не обязательно конфликтуют: сжатие памяти может резко снизить утечки почти без потери персонализации. Плохая — удаление становится многослойной инженерной задачей. Для зрелых AI-продуктов вопрос теперь звучит не «есть ли у агента память», а «можно ли проверить, что он способен стереть её до конца».
