Май 2026 · чтение 14 мин · Fran Olivares, основатель OlivaresAI
Модели без состояния достигли потолка. Передовые LLM теперь достаточно умны, чтобы писать production-код, составлять контракты, планировать поездки и резюмировать юридические документы — однако каждое взаимодействие начинается с чистого листа. Пользователь повторно объясняет, кто он, какой стек использует, что было решено на прошлой неделе, какой тон хочет, какие темы под запретом. AI никогда не строит реальной картины человека, проекта или долгой дуги работы. Это то, что исправляет устойчивая память: даёт модели непрерывность, не вытаскивая всю историю в каждый промпт.
Это руководство — длинный спутник для «Как дать AI устойчивую память» и «Управление памятью AI: полное руководство 2026». Где те посты фокусируются на путях интеграции, этот покрывает базовую архитектуру, компромиссы между подходами и что меняется операционно, когда Вы выкатываете устойчивую память в продакшен.
Устойчивая память — это всё, что модель может прочитать или записать и что переживает окончание разговора. Классическая граница — это окно контекста модели: когда сессия закрывается, всё внутри этого окна пропадает. Слой устойчивой памяти стоит рядом с моделью: приложение записывает факты и резюме разговоров в него во время или после сессии и считывает релевантные записи обратно в промпт в начале следующей. Модель никогда не имеет прямого доступа к хранилищу; приложение оркестрирует поток.
Ключевое различие между памятью сессии (история разговора, прокрученная в промпт на этот ход) и устойчивой памятью (отдельное хранилище, живущее в базе данных, индексированное семантически, доступное для запросов в любое время, принадлежащее пользователю). Память сессии ограничена длиной контекста и эфемерна по определению. Устойчивая память неограничена и долговечна.
Полезная ментальная модель: устойчивая память — это для LLM то же, что записная книжка для человека. Вы не носите в голове каждую страницу каждого разговора. Вы консультируетесь с книжкой, когда тема возникает, и релевантные страницы загружаются в рабочую память только на этот момент. Сборка контекста Alma делает этот шаг загрузки менее чем за 100 ms.
По трём причинам. Первая — потолок производительности: каждая повторяющаяся задача начинается с тех же затрат на настройку (повторное объяснение стека, повторное формулирование предпочтений, повторное заземление AI в проекте). За год эти минуты складываются в дни потерянных объяснений. Вторая — потолок качества: AI, который не знает Ваших соглашений в кодовой базе, тона, прошлых решений или ограничений предметной области, выдаёт обычный текст, который Вам приходится переписывать. Третья — потолок доверия: модель, противоречащая сама себе между разговорами или забывающая заявленные предпочтения, подрывает уверенность пользователя в том, что она действительно обращает внимание.
Нативные функции памяти платформ (ChatGPT Memory, Claude Projects) помогают, но они ограничены по ёмкости, замкнуты на одну платформу и не предлагают API для разработчиков. Если Вы создаёте любой AI-продукт — чат-бот, копилот, исследовательский ассистент, агент — Вам нужен независимый слой памяти, которым Вы управляете, который открывает настоящий API и следует за пользователем независимо от модели или клиента, которые он выбирает.
Четыре строительных блока стабилизировались в ведущих системах:
Большинство production-систем также добавляют: цикл обнаружения противоречий (когда два конфликтующих memory вызывают объединение или замещение), проход дедупликации (Jaccard или embedding-сходство выше порога схлопывается в одну запись) и угасание с учётом уверенности (memories с низкой важностью, к которым не обращались несколько месяцев, истекают автоматически). Трёхуровневая архитектура Alma разделяет само хранилище памяти на memories (атомарные факты), episodes (сжатые резюме разговоров) и procedures (изученные пошаговые workflows), чтобы каждый уровень мог извлекаться независимо.
RAG (Retrieval-Augmented Generation) и устойчивая память делят инфраструктуру (embeddings, векторные БД, извлечение), но решают разные задачи. RAG — для обоснования ответов в корпусе, который пользователь не писал — документация, научные статьи, внутренние wiki, базы знаний. Корпус написан один раз, проиндексирован и извлекается по требованию. Устойчивая память — для фиксации того, что сам пользователь сказал, решил или предпочёл, накопления этого со временем и обратного считывания. Корпус — это собственная история пользователя; она непрерывно растёт.
Практически различия выявляются в трёх местах: путь записи (RAG поглощает внешние документы пакетами; записи памяти стримятся из каждого разговора), оценка (RAG ранжирует по семантическому сходству; память добавляет важность, недавность и частоту к оценке) и жизненный цикл (документы RAG версионируются изредка; memories развиваются, противоречат, объединяются и истекают). Большинство production AI-ассистентов в 2026 используют оба: RAG для корпуса документации, устойчивую память для слоя, специфичного для пользователя. См. Устойчивая память против RAG для более глубокого сравнения.
Путь, который Вы выберете, зависит от того, контролируете ли Вы AI-клиент, AI-приложение или просто потребляете существующий ассистент. Три шаблона доминируют в 2026:
remember, recall, assemble_context, extract и т.д.), которые он может вызывать автономно. Никаких изменений кода со стороны пользователя. Alma поставляет @olivaresai/alma-mcp с 35 инструментами — см. «Как использовать MCP для памяти AI: настройка за 5 минут».Инженерные копилоты. Ассистент кода, который помнит Ваш стек, правила линтера, предпочтительный стиль обработки ошибок, диаграмму архитектуры Вашей системы, соглашения, которые Ваша команда приняла в прошлом спринте. Memories извлекаются из чат-сессий и веток ревью кода; procedures фиксируют многошаговые workflows вроде «всегда запускай typecheck перед предложением изменений». Результат: меньше повторных объяснений за сессию, меньше предложений, которые приходится отменять.
Агенты управления проектами. Агент, который отслеживает стейкхолдеров, цели спринта, блокеры и решения, принятые на standup'ах. История разговоров сжимается в episodes; структурированные записи стейкхолдеров живут как memories. Когда пользователь спрашивает «что мы решили о сроках миграции?», извлечение тянет соответствующие episodes плюс memory с решением. См. проработанный пример в «Создание PM-агента с Claude API и устойчивой памятью».
Инструменты для письма и творчества. AI-редактор, который помнит Ваш голос, Вашу аудиторию, рабочие названия Ваших проектов, гайд по стилю, который Вы написали три месяца назад, имена повторяющихся персонажей. Тональная последовательность на длинной форме была единственной самой сложной UX-проблемой в инструментах письма без состояния; устойчивая память делает её решаемой. См. сценарий для авторов.
Когда приходит новое сообщение пользователя, приложение вызывает POST /api/v1/context/assemble с запросом и любыми метаданными сессии. Слой памяти выполняет гибридный поиск по трём уровням (memories, episodes, procedures), оценивает результаты по взвешенной комбинации релевантности, важности, недавности, частоты и уверенности и возвращает структурированный ответ, содержащий наилучший контекст плюс активные Soul-блоки. Приложение форматирует это в системный промпт и отправляет LLM вместе с сообщением пользователя. Сквозная задержка обычно 30–80 ms; значительно ниже любого порога восприятия пользователя.
Настраиваемые параметры включают количество memories для извлечения (по умолчанию 15), минимальный порог оценки (по умолчанию ~0.55 cosine для memories, ниже для procedures) и бюджет tokens на уровень (так что собранный контекст никогда не выходит за эффективное окно модели). Большинство команд остаются на значениях по умолчанию; система разработана так, чтобы быть полезной из коробки, и требует настройки только при масштабировании за десятки тысяч memories на пользователя.
Три механизма работают непрерывно в фоне. Дедупликация: когда новое memory входит в хранилище, оно сравнивается с существующими через сходство Jaccard (порог 60%) и сходство embedding (0.92). Совпадения объединяются в существующую запись с повышением уверенности. Обнаружение противоречий: пары в диапазоне сходства 0.75–0.92 проверяются на семантический конфликт; конфликты вызывают замещение (старое memory помечается устаревшим, новое занимает место). Угасание: memories с важностью ниже 0.1, которые не читались и не записывались 120 дней, помечаются для удаления. Пользователь всегда может проверить, отредактировать или восстановить что угодно из панели управления памятью.
На практике это означает, что пользователь, переключающийся с frontend на backend, постепенно видит, как frontend-memories снижаются в приоритете; пользователь, отменяющий решение, видит, как старое помечено замещённым; и длинный хвост одноразовых фактов из случайных сессий не раздувает хранилище бесконечно. Пользователь сохраняет сигнал, отбрасывает шум.
Устойчивая память — самый личный слой данных в любом AI-продукте. Минимальная планка в 2026: шифрование в покое, полный экспорт в любой момент, жёсткое удаление по запросу, чёткое дополнение об обработке данных и работающий процесс реагирования на инциденты. Alma шифрует ключи BYOK через AES-256-GCM, хэширует API-ключи через HMAC-SHA256 в покое, поддерживает совместимый с GDPR экспорт по каждому уровню (memories, episodes, procedures, разговоры, файлы) и открывает поток удаления аккаунта в один клик, который очищает всё хранилище, включая embeddings. Пост о приватности погружается глубже, а страница безопасности документирует контроли.
Ландшафт консолидировался. Сводки сравнений: Alma против ChatGPT Memory, Alma против Claude Memory, Alma против Mem0, Alma против Zep, Alma против Letta / MemGPT. Кратко: ChatGPT и Claude memories отличны, если Ваши пользователи живут полностью внутри одной платформы; Mem0 и Zep — open-source-слои памяти, которые Вы self-host'ите и интегрируете через SDK; Letta (бывший MemGPT) наклоняется к agent-фреймворкам; Alma сидит в consumer/prosumer-слоте с веб-приложением, MCP-сервером, расширением VSCode, SDK и REST API за единым аккаунтом.
Если Вы конечный пользователь, желающий дать своему существующему AI память: установите MCP-сервер за пять минут — см. пошаговое руководство в «Как использовать MCP для памяти AI». Если Вы разработчик, создающий AI-приложение: начните с SDK на тарифе Starter, отработайте цикл перед-LLM context assemble + после-LLM extract в своей кодовой базе, затем перейдите на платный тариф, когда пересечёте порог объёма. REST API включён в тариф Max, если Вы предпочитаете чистый HTTP из не-JS стека.
Какой бы путь Вы ни выбрали, выигрыш один и тот же: AI перестаёт вести себя как инструмент без состояния и начинает вести себя как коллега, который помнит, что Вы делали вчера, на прошлой неделе и три месяца назад — без необходимости повторять что-либо из этого.
Связанное чтение: Почему AI нужна устойчивая память в 2026 · Управление памятью AI: полное руководство · Трёхуровневая архитектура памяти · Soul Engine объяснён · Документация Alma.