Одно из главных ограничений современных LLM — фиксированный размер контекстного окна. Даже модели с окном в 128K или 200K токенов не могут удерживать информацию между сессиями без внешнего хранилища. Для AI-агентов, которые должны помнить историю взаимодействий, предпочтения пользователя или результаты предыдущих вызовов инструментов, долговременная память становится критической инфраструктурой.
К началу 2026 года сложилось несколько архитектурных подходов к организации памяти за пределами одного диалога. Ни один из них не является универсальным — выбор зависит от сценария, бюджета задержки и требований к согласованности данных. Разберём каждый подход с точки зрения практического внедрения в российских проектах.
Векторные базы данных и RAG: самый зрелый путь
Самый распространённый метод — сохранять документы, логи или историю диалога в векторной базе и извлекать релевантные фрагменты перед генерацией ответа. Это Retrieval-Augmented Generation (RAG) в его классической форме. На российском рынке популярны Qdrant (есть on-premise развёртывание) и Milvus, а также облачные решения вроде Pinecone.
Плюсы: зрелые инструменты, обширная документация на русском языке, поддержка фильтрации по метаданным, возможность обновления записей без переобучения модели. Для типового сценария — чат-бота с базой знаний компании — это наиболее надёжный вариант.
Минусы: точность извлечения зависит от качества эмбеддингов и стратегии чанкинга. При объёме данных свыше 100 тысяч документов растёт задержка на поиск. Модель не «помнит» в человеческом смысле — она получает подсказку из хранилища на каждый запрос. Важный нюанс: если чанки слишком короткие (менее 200 токенов), теряется контекст, если слишком длинные (более 1000 токенов) — падает релевантность.
Практический совет: для российских проектов стоит начать с теста на 500 диалогов, используя эмбеддинги от Yandex GPT или ruBERT. Измерьте recall@10 — если он ниже 0.7, пересмотрите стратегию чанкинга.
MemGPT (Letta): память как операционная система для LLM
Проект MemGPT (сейчас развивается как Letta) предложил иерархическую модель памяти, вдохновлённую архитектурой операционных систем. Агент имеет «основную память» (working context) и «внешнюю память» (archival storage), а специальный контроллер решает, когда и какие блоки памяти загружать в контекстное окно.
В 2025 году Letta добавила поддержку «самовосприятия» (self-reflection) — агент может анализировать собственную историю и перестраивать структуру памяти. На практике это означает, что агент способен сам решать, какую информацию забыть, а какую сохранить для долгосрочного использования.
Однако подход остаётся экспериментальным: сложность отладки высока, а стоимость одного шага с обращением к памяти может быть в 3–5 раз выше обычного вызова LLM. Для российских проектов это означает дополнительные расходы на API при использовании облачных моделей. Letta требует Python 3.11 и значительных вычислительных ресурсов — минимум 8 ГБ ОЗУ только для контроллера памяти.
Графы знаний: структура вместо поиска
Вместо поиска по векторной близости некоторые команды используют графы знаний. Память организуется как набор сущностей и связей между ними. Агент может выполнять графовые запросы и получать точные, а не вероятностные результаты. В России популярны Neo4j и Amazon Neptune, а также легковесные решения вроде ArangoDB.
Плюсы: детерминированные ответы на структурные запросы, возможность вывода по цепочке связей, меньшая чувствительность к шуму. Например, агент CRM может точно ответить: «Какие сделки в статусе “переговоры” были у клиента Иванова за последний квартал?» — без риска ложного извлечения.
Минусы: необходимо проектировать схему графа заранее, сложность обновления при появлении новых типов сущностей, высокий порог входа для разработчиков. В российских реалиях это означает, что для внедрения графа знаний нужен отдельный инженер данных, что не всегда оправдано для небольших проектов.
Кэширование и сжатие контекста: быстрая память без БД
Для сценариев, где важна скорость, применяется кэширование последних N диалогов или сжатие истории в саммари. Этот подход используется в автодополнении кода, чат-ботах первого уровня, голосовых ассистентах. В России часто применяют Redis или SQLite для лёгкого кэширования.
Ограничение: при росте объёма истории сжатие теряет детали. Агент может забыть ключевые факты, если они не попали в последнее саммари. Например, если пользователь упомянул важный срок в середине длинного диалога, а саммари сжало только начало и конец, этот факт будет потерян.
Практический тест: запустите агента на 50 диалогах по 10 сообщений каждый. Если точность извлечения ключевых фактов (дат, имён, чисел) падает ниже 60% — кэширование не подходит для вашего сценария.
Сравнительная таблица подходов
| Подход | Задержка на запрос | Точность извлечения | Сложность внедрения | Типичный сценарий |
|---|---|---|---|---|
| Векторная БД + RAG | Средняя (200–800 мс) | Зависит от эмбеддингов | Средняя | Чат-боты с базой знаний |
| MemGPT / Letta | Высокая (1–3 с) | Высокая в контролируемых тестах | Высокая | Исследовательские прототипы |
| Граф знаний | Средняя (100–500 мс) | Детерминированная | Высокая | Аналитика, CRM-агенты |
| Кэш / саммари | Низкая (10–50 мс) | Низкая при больших объёмах | Низкая | Быстрые ассистенты |
Практические ограничения, о которых редко говорят
Первое — согласованность памяти. Векторные базы не гарантируют актуальность: если агент записал факт, а потом изменил его, старый чанк может остаться в индексе и быть извлечён первым. Нужны механизмы версионирования или инвалидации. В российских проектах это часто решают через добавление поля timestamp и фильтрацию по дате.
Второе — стоимость. Каждое обращение к внешней памяти — это не только запрос к БД, но и токены на вставку извлечённого контекста в промпт. При 10–20 обращениях за диалог стоимость сессии может превысить стоимость самого ответа модели. Для российских API (Yandex GPT, GigaChat) это особенно критично, так как тарификация по токенам выше, чем у OpenAI.
Третье — приватность. Если память агента хранит персональные данные пользователей, необходимо шифрование, политика удаления и соответствие регуляторам (152-ФЗ, GDPR). Большинство open-source решений не имеют встроенных механизмов compliance. В России для хранения данных пользователей рекомендуется использовать сертифицированные СУБД или облачные решения с сертификацией ФСТЭК.
Что смотреть дальше
В 2026 году ожидается появление гибридных архитектур, где векторный поиск комбинируется с графовым, а кэш используется для часто запрашиваемых фактов. Проекты вроде MemGPT постепенно переходят из исследовательской фазы в продуктовую. Для production-систем пока наиболее надёжным остаётся RAG с тщательно настроенным пайплайном чанкинга, эмбеддингов и реранжирования.
При выборе инструмента стоит начать с простого теста: сохранить 100 диалогов, запустить 10 запросов и проверить, сколько раз агент извлёк нерелевантный контекст или пропустил нужный. Если точность ниже 80% — проблема не в модели, а в архитектуре памяти. Для российских проектов рекомендую начать с Qdrant и эмбеддингов ruBERT — это даст стабильный базовый уровень с минимальными затратами на внедрение.