AWS показала, как очищать устаревшую память ИИ-агентов
AWS опубликовала готовую архитектуру управления памятью долгоживущих агентов на Amazon Bedrock AgentCore. Ночной процесс на AWS Step Functions применяет три политики: удаляет записи старше заданного срока, оценивает снижение их актуальности и объединяет повторяющиеся наблюдения. Цель - не позволить старым разговорам ухудшать ответы или нарушать требования к хранению данных.
Что изменилось
Разные воспоминания получили разные правила хранения
AWS делит память на эпизодическую, семантическую и процедурную. Эпизодическая хранит события и резюме отдельных разговоров, быстро растет и первой теряет ценность. Семантическая содержит компактные факты и предпочтения, поэтому обычно живет дольше. Процедурная описывает рабочие приемы и последовательности инструментов, имеет меньший объем, но может сильнее влиять на действия агента. Одинаковый срок для всех типов либо сохраняет слишком много шума, либо преждевременно удаляет полезные правила.
TTL задает жесткую верхнюю границу
Первый этап удаляет записи старше установленного срока. В демонстрации для эпизодической памяти используется отправная точка 90 дней, а в рекомендациях краткие резюме предлагается хранить 30-60 дней, семантические сведения - 6-12 месяцев. Это не универсальные нормативы: срок зависит от назначения и закона. В AgentCore нет встроенного автоматического TTL для таких записей, поэтому процесс выбирает их по системным временным полям и удаляет самостоятельно.
Оценка актуальности учитывает не только возраст
Свежая запись тоже может быть бесполезной, а старое предпочтение - по-прежнему действовать. Поэтому следующий слой вычисляет снижение релевантности и выбирает кандидатов на очистку по возрасту, использованию и типу. Параметр pruneDays позволяет менять агрессивность. Порог нельзя переносить в продакшен без контрольного набора: слишком мягкая политика оставит устаревшие инструкции, слишком жесткая заставит пользователя повторять важные сведения и ухудшит непрерывность обслуживания.
Консолидация превращает повторения в одну запись
Модель может объединить несколько эпизодов в авторитетный семантический факт. Например, повторяющиеся просьбы использовать регион us-east-1 сворачиваются в одно предпочтение вместо десятков почти одинаковых реплик. Консолидация экономит место и уменьшает конфликтующий контекст, но создает риск ложного обобщения. Перед заменой исходных записей полезно сохранять происхождение факта, дату последнего подтверждения и возможность восстановить цепочку, из которой он был выведен.
Рабочий процесс запускается ночью и оставляет наблюдаемость
Решение разворачивается через AWS CDK, стартует по расписанию EventBridge и координируется Step Functions. В набор входят Lambda, CloudWatch, CloudTrail, S3 и уведомления SNS. Это делает очистку отдельной управляемой операцией, а не скрытым побочным эффектом ответа агента. Команда видит число просмотренных, объединенных и удаленных записей, может ограничить пакет и остановить процесс при аномалии. После изменений качество нужно повторно измерять на тех же сценариях памяти.
Что это дает пользователю
Сначала проведите инвентаризацию: какие записи существуют, кто их владелец, как они используются и какой срок требуется. Нельзя безопасно включить массовое удаление, пока система не различает историю разговора, подтвержденный факт и рабочую процедуру.
Запускайте политику в режиме отчета. Несколько ночей она должна только перечислять кандидатов, причины и ожидаемый объем освобождения. Выборочно проверьте записи с высоким влиянием и только затем разрешайте фактическое удаление.
Для консолидации храните ссылки на исходные эпизоды и уровень уверенности. Если пользователь меняет предпочтение, новая запись должна явно вытеснять старую. Простое объединение противоречий в длинный абзац не решает проблему актуальности.
После очистки запускайте набор контрольных диалогов: возвращающийся клиент, закрытый спор, обновленный регламент и запрос на удаление данных. Сравнивайте точность ответа, долю ошибочно возвращенных фактов, задержку и стоимость до и после процесса.
Что нужно учитывать
Опубликованные сроки хранения являются примерами архитектуры, а не юридической рекомендацией.
Для решения нужны дополнительные сервисы AWS, права, мониторинг и расходы на модельную консолидацию.
Автоматическая оценка релевантности может удалить редкий, но критически важный факт.
Удаление производной памяти нужно согласовать с резервными копиями, журналами и требованиями пользователя.
Коротко
AWS формулирует полезную для зрелых агентов мысль: память является управляемым ресурсом, а не бесконечным приложением к чату. Старые эпизоды, устойчивые факты и рабочие навыки нельзя очищать одной кнопкой. Практичная схема сочетает жесткий срок, оценку актуальности, консолидацию и наблюдаемую ночную операцию. Самый безопасный старт - отчет без удаления и контрольные диалоги, которые покажут, не исчезло ли вместе с шумом действительно нужное знание. После включения очистки команда должна отслеживать не только освобожденное место, но и рост повторных вопросов, ошибочных рекомендаций и ручных исправлений. Эти сигналы покажут, не выбран ли чрезмерно агрессивный порог. Полезную удаленную запись восстанавливают из защищенного журнала только по проверяемой процедуре.