Habr AI объяснил, как память помогает ИИ-агентам помнить диалоги и не терять контекст
Habr AI выпустил понятный разбор памяти ИИ-агентов — от ограничений контекстного окна до внешних хранилищ. В материале объясняют, почему длинный диалог ухудшает
На Habr AI вышел подробный разбор того, как устроена память ИИ-агентов и почему без неё нельзя построить полезного ассистента дольше одного диалога. Материал разбирает базовую механику: ограничения контекстного окна, три типа внешней памяти и способ, которым агент собирает всё это в один рабочий запрос к модели.
Почему окна мало Автор начинает с самого важного: LLM не «помнит» прошлые сессии сама по себе.
Каждый новый запрос модель получает заново вместе с системным промптом, историей чата, результатами инструментов и дополнительными документами. Всё это живёт внутри контекстного окна — ограниченного объёма текста, который модель способна обработать за один вызов. Если в него попадает лишнее, например огромный HTML после парсинга страницы, полезные детали вытесняются, а качество ответа падает.
«Что не влезло, не существует».
Даже когда лимит формально не превышен, возникает другая проблема — lost in the middle. Модель лучше держит в фокусе начало и конец длинного контекста, а середина начинает «плыть». Поэтому простое наращивание окна не решает задачу памяти. В статье выделяют три базовые техники, которые уменьшают перегрузку: суммаризацию старых сообщений, скользящее окно только для последних реплик и селективное хранение действительно важных фрагментов. На практике их чаще комбинируют, а не используют по отдельности.
Три типа памяти
За пределами контекстного окна живёт внешняя память — файлы, базы данных, векторные индексы и графы знаний, которые переживают любые сессии. Автор делит её на три слоя по аналогии с человеческой памятью. Такой разрез полезен не ради терминов, а потому что у каждого слоя своя логика хранения, поиска и подгрузки в контекст.
Если смешать всё в одну кучу, агенту будет сложнее понять, что нужно помнить всегда, а что доставать только по запросу. * Эпизодическая память — факты о пользователе и прошлых взаимодействиях: предпочтения, жалобы, привычки, удачные и неудачные действия агента. Она особенно нужна персональным ассистентам и поддержке.
База знаний — документы, справка по продукту, доменная информация и всё, что обычно называют RAG по документам. Такая память отвечает за факты о мире или компании, а не о конкретном человеке. Процедурная память — правила, инструкции и сценарии поведения.
Это могут быть куски системного промпта, markdown-файлы для разных задач или наборы rules в coding-агентах. Из этого следует важный практический вывод: память агента — не одна «волшебная база», а набор разнотипных источников. Эпизоды полезно хранить как в сыром виде, так и в сжатом, пригодном для поиска.
Знания о предметной области можно держать в векторной БД или графе. Инструкции часто живут в текстовых файлах и подгружаются по ситуации. Архитектура зависит не столько от инструмента, сколько от того, какую именно память ты сохраняешь.
Как память включают Важная мысль статьи: эпизодическую память нельзя просто «включить галочкой».
Её приходится проектировать в коде. Типовой пайплайн выглядит так: система сохраняет диалог, затем отдельным LLM-вызовом делает резюме беседы и извлекает из неё долговременные факты в структурированном виде — например, JSON с типом записи, важностью, идентификатором пользователя и датой. После этого каждая запись превращается в embedding и отправляется в подходящее хранилище.
Так агент не тащит в следующий сеанс всю переписку целиком, а возвращает только релевантные выводы. Во время нового запроса оркестратор параллельно подтягивает инструкции, доменные знания и пользовательские воспоминания, а затем склеивает их в единый промпт для модели. При этом разные типы памяти лучше держать в разных коллекциях или каналах доступа: процедуры и пользовательские факты могут загружаться почти всегда, а база знаний — только после семантического поиска по смыслу.
В статье отдельно упоминаются Mem0, Letta и Graphiti как готовые решения, которые автоматизируют часть этого процесса и прячут сложность под капотом.
Что это значит
Для разработчиков агентных систем этот материал полезен как минимальная карта местности. Он напоминает, что рабочий агент строится не вокруг одной мощной LLM, а вокруг памяти, оркестрации и аккуратной подгрузки контекста. Чем раньше эти слои заложены в архитектуру, тем меньше галлюцинаций, потерь деталей и повторных ошибок в реальных сценариях.