Системы памяти в ИИ-ассистентах

Память превращает ассистентов из реактивных в персистентные, но именно в ней множество систем тихо деградируют. Исследования утверждают, что разделения на краткосрочную и долгосрочную память больше недостаточно для современных агентных систем памяти; SDK от OpenAI и LangGraph указывают на более простую стек-модель — рабочая память, персистентное состояние и поиск (retrieval).

Ассистентам нужна рабочая память для текущего запуска, персистентное состояние для стабильных фактов и предпочтений, а также память поиска для релевантного вспомогательного контекста. Мое чуть субъективное мнение состоит в том, что структурированное состояние недооценено, векторный поиск переоценен, и большинство сбоев в памяти вызваны не выбором хранилища, а политикой продвижения (promotion) и внедрения (injection) данных.

Другой важный момент заключается в том, что память не исправляет проблемы с длинным контекстом автоматически. LoCoMo показывает, что долговременное восстановление разговоров по-прежнему сложно, а «Lost in the Middle» демонстрирует, что простое увеличение количества токенов может ухудшить производительность, если релевантная информация оказывается в середине промпта. Хорошие системы памяти являются селективными, многослойными и ясными в части приоритетов.

Этот гайд находится в хабе по памяти в AI-системах и служит картой между фреймворками для слоя памяти внутри архитектуры AI-ассистента.

Как думать о памяти ассистента

Память ассистента — это не та же проблема, что PKM, вики или независимые RAG-конвейеры; PKM vs RAG vs Wiki vs Системы памяти сопоставляет эти парадигмы на уровне архитектуры знаний. Этот гайд остаётся на уровне ниже, в контрактах времени выполнения, которые реально реализуют ассистенты. Это также иная задача по обслуживанию: память управляет поведением агента от сессии к сессии, тогда как общая база знаний, такая как LLM Wiki, требует собственного [дисциплины по обслуживанию](https://www.glukhov.org/ru/knowledge-management/knowledge-systems-architectures/compiled-knowledge/llm-wiki-maintenance-knowledge-drift/ “Обслуживание LLM Wiki: дрейф знаний, противоречия и ревью”}, чтобы агенты, читающие из неё, не действовали на основе устаревших или противоречивых фактов.

Самый чистый способ думать о памяти — не как о «истории чата», а как о наборе контрактов хранилища с разными функциями. Одно хранилище сохраняет активный поток. Другое хранит персистентное состояние пользователя. Третье поддерживает семантический поиск по документам или прошлым взаимодействиям. Рекомендации OpenAI по памяти для персонализации делают это явно, разделяя глобальную и сессионную память, тогда как LangGraph разделяет персистентность на уровне потока (thread) от долгосрочных хранилищ между разговорами.

Память важна, потому что продакшен-ассистенты повторяют работу, возвращаются к целям и работают на протяжении дней или недель. Generative Agents популяризировали паттерн хранения опыта, рефлексии над ним и динамического извлечения для будущего планирования. MemGPT зашёл дальше, моделируя память как уровни (тиры) и перемещение между быстрыми и медленными хранилищами. Более новые системы, такие как A-MEM и Mem0, сосредоточены на связывании, консолидации и эффективности развёртывания, а не просто на объёме воспоминаний.

Типы памяти

Продакшен-ассистентам обычно нужны три cooperating (взаимодействующие) слоя. FAQ выше называет их; разделы ниже объясняют, как каждый из них работает в реальных системах.

Краткосрочная память

Краткосрочная память — это рабочий контекст текущего разговора или запуска. OpenAI Sessions автоматически вставляют историю разговора перед каждым запуском и добавляют новые элементы после каждого запуска. LangGraph реализует ту же идею как персистентность на уровне потока (thread) через чекпоинтер (checkpointer). Этот слой поддерживает локальную связность, но он же первым «взрывается» (перегружается), когда накапливаются результаты инструментов, чтение файлов или длинные чаты.

Долгосрочная память поиска

Долгосрочная память поиска хранит элементы, которые извлекаются при релевантности, а не воспроизводятся каждый ход. Это перекликается с RAG как с техникой поиска, но это не вся история о памяти ассистента — вики и корпусы PKM часто питают индекс, тогда как структурированное состояние и сессионная память живут в другом месте, как ясно из сравнения PKM/RAG/вики/памяти выше. В классическом RAG модель комбинирует параметрическую память с не-параметрической памятью, такой как плотный векторный индекс. Self-RAG улучшает наивный поиск, делая его по требованию, а не фиксированным для каждого запроса. В практических системах ассистентов это обычно слой векторного хранилища или ищущейся транскрипции.

Структурированная память

Структурированная память хранит долговечные факты, предпочтения или ограничения в явных полях с правилами приоритета. Кулинарная книга OpenAI по персонализации необычно ясна здесь. Глобальная и сессионная память имеют разные роли, последняя инструкция пользователя имеет приоритет, сессионная память может переопределять глобальную память для текущей задачи, а память, конфликтующая с текущим намерением пользователя, должна вызывать запрос на уточнение, а не молчаливое подчинение. Именно поэтому структурированное состояние часто лучше, чем поиск, для стабильных предпочтений, политик или постоянных ограничений.

Механика поиска

Типичный поток поиска состоит из пяти шагов: захват, кодирование, поиск, повторное ранжирование или фильтрация, затем внедрение. Pinecone, Weaviate, Qdrant, Redis и Milvus документируют варианты этого паттерна. Некоторые поддерживают только плотные векторы, другие поддерживают гибридный поиск, сочетающий семантический и лексический поиск, а некоторые предоставляют метаданные-фильтры или пространства имён (namespaces) для контроля многоарендности (tenancy) и области. Инженерный момент прост. Качество поиска зависит от стратегии фильтрации, фрагментации (chunking) и ранжирования не меньше, чем от самой модели эмбеддингов.

Гибридный поиск обычно является разумным значением по умолчанию, когда запросы смешивают смысл и точные термины. Weaviate документирует гибридный поиск с параметром alpha, балансирующим векторные и ключевые компоненты, Qdrant поддерживает гибридные и многоэтапные запросы через свой Query API и методы слияния скоростей (score-fusion), а Milvus описывает плотный, разреженный и гибридный поиск в одной системе. Это важно для ассистентов, потому что пользователи часто просят как приблизительный смысл, так и точные идентификаторы, имена файлов, номера ревизий или коды продуктов. Когда лексическая часть находится в Postgres или Elasticsearch, а не внутри векторной базы данных, полнотекстовый поиск PostgreSQL против Elasticsearch поможет выбрать, где должен выполняться ключевой поиск в продакшене.

Ещё один субъективный момент: поиск не должен определять политику. Он должен предоставлять кандидатов. Ассистенту всё равно нужны структурированные правила для приоритетов, приватности, новизны и разрешения конфликтов. Пример OpenAI с памятью на основе состояния делает это явным, и это гораздо более здоровый паттерн, чем притворяться, что только поиск по сходству может разрешить противоречивое состояние пользователя.

Частые проблемы

Самый частый сбой — это устаревшая или противоречивая память. Кулинарная книга OpenAI по долгосрочной памяти называет консолидацию памяти самым чувствительным и склонным к ошибкам этапом, перечисляя загрязнение контекста, потерю памяти, дублирование воспоминаний и обработку противоречий как основные проблемы. Это верно, и именно здесь многие ассистенты тихо терпят неудачу. Они запоминают слишком много, слишком рано и без правила забывания. Конкретный и всё чаще встречающийся вариант этого сбоя заслуживает глубокого погружения: собственное рассуждение модели (inference) продвигается в долговременную память, извлекается позже как будто это было наблюдением, и используется для обоснования ещё более сильной версии самого себя. См. Самовоспроизводящиеся петли памяти в AI-агентах для семи форм, которые это принимает, и как это тестировать.

Второй сбой — перегрузка контекста. LangGraph предупреждает, что длинные разговоры могут превысить окно контекста LLM и рекомендует обрезку, удаление, суммаризацию или управление чекпоинтами. OpenClaw аналогично удаляет старые выходы инструментов из контекста в памяти, сохраняя полную транскрипцию на диске. Это не опциональные оптимизации. Они необходимы, если ваш ассистент читает, ищет или выполняет что-либо нетривиальное.

Третий сбой — предположение, что длинный контекст равнонадежен с надёжным воспоминанием. LoCoMo показывает, что долговременная память разговоров по-прежнему сложна, а «Lost in the Middle» показывает чувствительность к позиции внутри длинных промптов. Если память важна, не полагайтесь на грубо-силовое заполнение промптов. Используйте компакцию, поиск и явное состояние.

Компромиссы

Слой векторной базы данных — это место, где многие команды ассистентов делают ранние ставки на платформу. Сравнение ниже фокусируется на задокументированных характеристиках продуктов, которые важны для проектирования памяти ассистента.

Система	Что выделяется	Лучшее применение
Pinecone	Управляемая векторная база данных с интегрированными эмбеддингами, ранжированием, фильтрами метаданных, пространствами имён и поддержкой плотных, разреженных и BM25-подобного полнотекстового поиска в одной схеме	Команды, желающие управляемый поиск с минимальной инфраструктурой
Weaviate	Векторная база данных с открытым исходным кодом, хранящая объекты и векторы, с семантическим и гибридным поиском и сильным позиционированием RAG	Команды, желающие гибкость открытого кода с гибридным поиском
Qdrant	Нативный AI векторный поиск с фильтрацией, гибридными и многоэтапными запросами, плюс встроенный офлайн-способный Edge-режим	Команды, желающие контроль над поиском, развёртывание на периферии (edge) или мощную фильтрацию
pgvector	Векторный поиск по сходству внутри Postgres, с точным и приближённым поиском, плюс ACID, JOINs и функции восстановления	Команды, уже стандартизированные на Postgres и реляционных данных
Milvus	Облачная векторная база данных с разделённым хранением и вычислениями, плюс плотный, разреженный и гибридный поиск	Крупномасштабные нагрузки по поиску и распределённые развёртывания

После выбора бэкенда, его эксплуатация — это проблема инфраструктуры данных — Postgres с pgvector для метаданных сессий и векторов в одном стеке, или Neo4j, если память поиска имеет форму графа, а не плоских фрагментов.

Паттерн задержки и стоимости ниже — это проектный синтез на основе операционных моделей, описанных в рекомендациях OpenAI Sessions и руководстве по компакции, управлении памятью LangGraph, памяти на основе состояния OpenAI и задокументированном поведении поиска Redis и векторных хранилищ. Он намеренно качественный, потому что реальные цифры зависят от размера корпуса, модели эмбеддингов, сетевого расположения и кэширования.

Тактика памяти	Задержка чтения	Задержка записи	Давление на стоимость токенов	Инфраструктурная стоимость	Когда это имеет смысл
Сырая история сессии	Минимальная	Минимальная	Максимальная	Минимальная	Простой многораундовый чат и короткие запуски
Суммарная или компактная память	От низкой до средней	Средняя, потому что суммаризация сама по себе является шагом модели	От средней до низкой	От низкой до средней	Долгие рабочие процессы, где активный запуск должен продолжиться
Структурированный профиль и состояние	Низкая	Средняя	Низкая	Низкая	Долговечные предпочтения, правила и постоянные ограничения
Векторный или гибридный поиск	Средняя	Средняя	От низкой до средней	Средняя	Крупные корпуса, ищущая история, обоснование по документам
Полное воспроизведение всего	Высокая и всё более нестабильная	Низкая	Максимальная	Низкая инфраструктура, высокие расходы на модель	Почти никогда, кроме крошечных корпусов и отладки

Примеры реализации

Текущий стек OpenAI даёт два полезных референсных паттерна. Первый — Sessions для краткосрочной непрерывности между запусками. Второй — долгосрочная память на основе состояния, где структурированные поля профиля и заметки глобальной памяти внедряются в начале сессии, сессионные заметки дистиллируются в ходе запуска, а шаг консолидации продвигает в глобальную память только долговечные элементы. Цикл «внедрение → рассуждение → дистилляция → консолидация» — один из самых чётких публичных паттернов памяти, доступных прямо сейчас.

LangGraph предоставляет аналогичное, но независимое от фреймворка разделение. Чекпоинтеры обрабатывают краткосрочную память потока (thread), а хранилища (stores) — долгосрочный поиск между разговорами. Хранилище можно искать внутри узлов во время выполнения, что делает хорошим референсным дизайном для ассистентов, которым нужна явная оркестрация, а не скрытая магия фреймворка.

Hermes — полезный публичный пример многослойной памяти в дикой природе. Его встроенная память использует MEMORY.md, USER.md и поиск сессий SQLite FTS5, тогда как плагины внешних провайдеров добавляют графовую память, семантический поиск, автоматическое извлечение фактов и моделирование пользователя. Полная механика задокументирована в Системе памяти агента Hermes, а восемь подключаемых бэкендов сравниваются в Сравнение провайдеров памяти агентов.

OpenClaw предлагает другой подход, с обрезкой сессий, опциональной активной памятью, которая запускается перед основным ответом, и опциональной системой Dreaming для фоновой консолидации памяти. Эти примеры заслуживают внимания, потому что они рассматривают память как операционную подсистему, а не просто трюк поиска. О том, как OpenClaw вписывается в более широкий пятислойный стек ассистента, см. Обзор системы OpenClaw.

Исследовательские прототипы указывают в том же направлении. MemGPT использует иерархические уровни памяти и поток управления для управления контекстом, A-MEM использует динамический индекс и связывание, вдохновлённые Zettelkasten, а Mem0 сообщает о лучшей точности с гораздо более низкой p95 задержкой и стоимостью токенов по сравнению с базовыми линиями полного контекста на LoCoMo. Вам не нужно копировать эти системы целиком, но их общий урок ясен. Качество памяти проистекает из отбора и организации, а не от вечного хранения всего.

Когда память помогает, а когда вредит

Память помогает, когда ассистент неоднократно сталкивается со стабильными предпочтениями, долговечными ограничениями, переиспользуемыми уроками рабочих процессов или крупными внешними корпусами, которые не помещаются в промпт. Гайд OpenAI по надёжным агентам хорошо проводит это различие. Компакция помогает текущему длительному запуску продолжиться, тогда как память помогает будущим запускам переиспользовать уроки рабочих процессов. Это правильная ментальная модель для большинства бизнес-ассистентов.

Память вредит, когда задача разовая, состояние пользователя часто меняется, индекс поиска зашумлён или система не может согласовать конфликты. Пример travel-memory от OpenAI предупреждает, что сессионная память не должна автоматически становиться глобальной, и явно указывает, что память не является границей безопасности. Если ваш ассистент относится к каждой вспомнившейся строке как к истине, вы построили не систему памяти, а машину путаницы.

Селективный цикл памяти

Самый простой устойчивый цикл памяти — селективный и поэтапный. Загрузите долговечное состояние, извлеките вспомогательный контекст, ответьте, захватите только кандидаты в память, затем консолидируйте позже. И паттерн на основе состояния от OpenAI, и недавние статьи о памяти движутся в этом направлении.

Без трассировки и оценок (evals) изменения в памяти трудно отлаживать. Когда вы продвигаете новые факты или меняете политику поиска, связывайте эти изменения с паттернами наблюдаемости в Наблюдаемость для LLM-систем, чтобы видеть, какой слой что внедрил.

Вывод

Практический стек памяти для ассистентов — это не «просто используйте векторную БД». Это рабочая память для живого запуска, структурированное состояние для долговечной истины, память поиска для вспомогательных доказательств и консервативная политика консолидации, которая забывает так же осознанно, как и запоминает. И недавние исследования, и текущие рекомендации SDK указывают в этом направлении.

Для полного стека ассистента вокруг этого слоя начните с Архитектуры AI-ассистента. Для специфичной для Hermes ограниченной памяти и плагинов провайдеров следуйте Системе памяти агента Hermes и Сравнению провайдеров памяти агентов. Когда ассистентам нужно следить за источниками и действовать проактивно, а не ждать промптов от пользователя, модель операционного состояния для опроса — курсоры, претензии (claims), записи дедупликации и журналы выполнения — описана в Опрос агентов в AI-ассистентах: 11 паттернов реализации.