Elastic открыла исходный код Atlas — системы, которая решает одну из самых неприятных проблем агентных приложений: как хранить и вовремя доставать контекст о пользователе, не превращая каждый запрос в свалку из старых диалогов. Для оценки качества вопросно-ответного сценария Atlas показал 0,89 Recall@10, и это уже не разговоры про «агентов будущего», а вполне прикладная память для AI-агентов для команд, которые строят долгоживущие сервисы поверх LLM.
Как пишет InfoQ, Atlas построен на Elasticsearch, подключается к агентам через MCP и изолирует память по каждому пользователю на уровне документов. Для русскоязычной IT-аудитории здесь важен не сам факт очередного open source-релиза, а то, что Elastic предлагает довольно трезвую архитектуру для систем, где агент общается с человеком неделями и месяцами, а не только в рамках одной сессии.
Почему обычный контекст уже не спасает
Проблема, которую решает Atlas, знакома всем, кто пробовал делать не игрушечного чат-бота, а рабочего помощника: чем длиннее история общения, тем хуже идея просто запихивать ее в prompt. Это бьет сразу по трем местам. Во-первых, по стоимости: длинный контекст надо постоянно пересылать в модель. Во-вторых, по задержкам: каждый лишний кусок истории увеличивает время ответа. В-третьих, по качеству: даже большие контекстные окна не гарантируют, что модель действительно использует нужный факт, а не потеряет его где-то в середине промпта.
Elastic формулирует это довольно жестко: миллион токенов в окне контекста — это не память, а большой черновик. И с инженерной точки зрения спорить трудно. Если агент должен помнить, что пользователь уже согласовал требования, какой у него стек, какие действия сработали в прошлый раз и какие ограничения по безопасности нельзя нарушать, нужен не просто длинный prompt, а отдельный слой долговременного хранения и выборки. Собственно, память для AI-агентов и появляется здесь как инфраструктурный компонент, а не как красивый маркетинговый термин.
Atlas опирается на модель из когнитивной науки и делит память на три типа. Эпизодическая память хранит события — грубо говоря, что именно произошло в диалоге. Семантическая фиксирует устойчивые факты — что о пользователе или задаче можно считать верным. Процедурная отвечает за рабочие схемы — что именно помогает решать похожие задачи. Для каждого типа Atlas использует отдельный индекс Elasticsearch, потому что у них разный жизненный цикл и разные правила обновления. Это, кстати, одно из самых разумных решений в проекте: смешивать «факт», «событие» и «инструкцию» в одном бакете любят многие, а потом долго удивляются, почему retrieval начинает вытаскивать все подряд.
Логика формирования памяти выглядит так. Каждый пользовательский ввод сначала записывается как эпизодическое событие. Большая часть таких событий со временем теряет ценность, но часть становится доказательной базой для более устойчивых знаний. Дальше в работу включается LLM: она консолидирует материал, выделяет новые факты, записывает их в семантическую память короткими предложениями и сохраняет ссылки на эпизоды, которые эти факты подтверждают. Если новый факт заменяет старый, система также фиксирует, что именно было пересмотрено. Это важный момент для production-сценариев: память должна не просто накапливаться, а уметь корректно забывать и переписывать устаревшее.
Процедурная память обновляется по двум линиям. С одной стороны, Atlas формирует новые playbook'и — последовательности шагов для решения задач. С другой — ведет счетчики успехов и провалов по уже существующим схемам. Эти счетчики потом влияют на ранжирование: более успешные playbook'и поднимаются выше при выборке. По сути, система пытается запоминать не только содержание общения, но и рабочие способы действия. Для продуктовых команд это особенно интересно: если агент помогает саппорту, внутреннему HR-боту или copilot'у для аналитиков, ему важно помнить не только «кто ты», но и «что обычно срабатывает в твоем кейсе».
Почему Elastic сделала ставку на Elasticsearch
Доступ к памяти в Atlas организован через единый гибридный запрос по всем индексам сразу. Внутри используется Reciprocal Rank Fusion, который объединяет результаты лексического поиска BM25 и семантического поиска на Jina v5, а затем поверх этого работает cross-encoder reranker. На практике это означает довольно взрослый retrieval-стек вместо модной, но часто слишком упрощенной схемы «векторная база плюс top-k». Для команд, которые уже уперлись в ограничения чистого embedding search, такой подход выглядит знакомо и убедительно: ключевые слова, смысловая близость и финальное переранжирование решают разные задачи и редко хорошо заменяют друг друга.
Отдельно стоит сказать про изоляцию данных. Atlas использует document-level security, чтобы при запросе агент видел только те элементы памяти, которые относятся к конкретному пользователю. Для корпоративных внедрений это не опция, а базовая санитария. Любая система персональной памяти без жесткой границы между пользователями быстро превращается в источник утечек, галлюцинаций и крайне неприятных разговоров с безопасниками. Поэтому новость здесь не только в том, что Elastic выложила код, но и в том, что она сразу показывает модель эксплуатации, пригодную для multi-user среды.
В обсуждении на Hacker News ожидаемо всплыл спор о том, не слишком ли жирно использовать Elasticsearch для такой задачи. Скептики предположили, что с ролью хранилища справились бы и более легкие базы с поддержкой векторов, вплоть до SQLite-подобных вариантов. В ответ им заметили, что альтернатива выглядит привлекательной ровно до того момента, пока не понадобятся scripted scoring, сложное ранжирование и приемлемая задержка на реальных объемах. Аргумент не новый, но вполне жизненный: «простая база на старте» нередко заканчивается болезненным переездом, когда прототип внезапно становится продуктом.
Для разработчиков и архитекторов здесь есть вполне практический вывод. Рынок агентных систем постепенно уходит от фокуса на размере контекстного окна и начинает разбирать агент как набор специализированных подсистем: оркестрация, инструменты, безопасность, наблюдаемость и теперь уже отдельная память для AI-агентов. Atlas не обещает магию и не делает вид, что LLM сама разберется. Он предлагает довольно земной стек: хранить события, выделять факты, измерять успешные процедуры и искать по этому слою как по нормальной поисковой системе. Для бизнеса это означает более предсказуемых ассистентов. Для инженеров — меньше надежд на «ну модель же умная» и больше нормальной работы с данными, схемами и retrieval.
Главный вопрос теперь не в том, нужна ли долговременная память агентам, а в том, какой будет стандартная архитектура такого слоя через год. Если Atlas приживется в open source-среде, команды начнут сравнивать уже не только модели и фреймворки агентов, но и способы консолидации фактов, забывания, обновления playbook'ов и контроля доступа к памяти. Первоисточник новости и детали релиза доступны в .