Память для LLM-агентов: почему проще забыть, чем хранить

Память для LLM-агентов: что хранить и что забывать

Агент без памяти — болтун. Агент с памятью, которая не умеет забывать, — узел проблем.

Данные есть, контекста нет

Модели с длинными контекстами (200K–1M токенов) теряют нить в середине документов — эффект lost in the middle (Liu et al., 2023) убивает производительность, даже когда память формально присутствует. Николенко в обзоре отмечает: фреймворк MemPalace показывает лучшие результаты в режиме без «чертога разума» — то есть когда система не хранит всё подряд, а селективно отбирает релевантное. Память для агентов — это фильтр, а не склад.

Даже лучшие инструменты не решают проблему полностью. Николенко называет Hindsight (Latimer et al., 2025) самым надёжным решением, но и он требует ручной настройки: что хранить, как обновлять, когда забывать. Бенчмарки вроде LoCoMo тестируют способность «вспомнить факт», но не «вспомнить факт для решения задачи» — а именно это критично в реальных сценариях.

В тесте MemoryArena (He et al., 2026) системы, показывающие 95% на синтетических данных, падают до 40–60% в реальных задачах. Разрыв между бенчмарками и продакшеном — не опечатка, а закономерность.

Что хранить — не главное. Главное — что забыть

Классификация памяти по CoALA (Sumers et al., 2024) применима к агентам, но на практике каждая категория становится источником проблем:

• Рабочая память (текущий контекст) обновляется быстро, но теряется при рестарте сессии.
• Эпизодическая память (события) хранится в логах, но извлечение требует поиска. В продакшене агенты тратят время на разбор логов, а не на решение задач.
• Семантическая память (факты) хранится в векторных представлениях или графах, но модели часто игнорируют её, полагаясь на встроенные знания.
• Процедурная память (навыки) реализуется через инструменты или скрипты, но агенты не всегда понимают, когда и как их применять.

От чат-бота к мультиагентной системе

Одноагентные системы с длинным контекстом или RAG — временное решение. Если задача растёт, система разбухает, а производительность падает. Мультиагентные архитектуры появляются не из моды, а из необходимости: они распределяют нагрузку, но добавляют новые проблемы.

Три класса агентов по степени автономности:

• Базовый: выполняет строго заданные задачи (например, чат-бот поддержки).
• Workflow-агент: координирует сложные процессы с возможностью вмешательства человека (например, DevOps-система).
• Автономный: самостоятельно планирует и корректирует задачи (например, агент для кодирования или исследовательской работы).

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

Как память распределяется между агентами

В мультиагентных системах память может быть:

• Централизованной: оркестратор хранит общую память (например, семантическую базу знаний). Риск: единая точка отказа.
• Децентрализованной: каждый агент хранит свою память (например, эпизодическую). Риск: противоречия между агентами.
• Гибридной: оркестратор хранит общую память, агенты — локальную. Баланс между согласованностью и отказоустойчивостью.

Практический кейс от RedMadRobot: мультиагентная система для промышленной компании, встроенная в «КОМПАС-3D». Агент проверял схемы и отвечал на вопросы инженеров. Интеллектуальный ассистент для службы поддержки сократил время до первого ответа с 1–2 часов до меньше двух минут, долю решённых запросов на первом уровне — с 20–30% до 60–80%.

Что это меняет на практике

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

Мультиагентные архитектуры становятся единственным способом построить надёжные решения, но их успех зависит от того, как они управляют памятью, ролями и отказами. Бенчмарки памяти часто завышают реальную производительность. Тестировать системы нужно в реальных сценариях (например, MemoryArena), а не только на синтетических данных.

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