Май 2026 · чтение 10 мин · Fran Olivares, основатель OlivaresAI
Само по себе хранилище устойчивой памяти ничего не делает. Хранилище нужно запросить, оценить и сформировать в системный промпт, который помещается в окно контекста модели, до того как придёт следующее сообщение пользователя. Этот шаг — сборка контекста — это разница между «у нас есть база данных памяти» и «AI помнит». Это руководство — длинный спутник для технической справки на /docs/context-assembly и проходит через каждую стадию pipeline, числа, которые Alma использует по умолчанию, и компромиссы, которые можно настроить.
Потому что модель видит только то, что в промпте. Хранилище памяти с десятью тысячами записей невидимо для модели, если что-то не выберет правильные тридцать для этого хода. Если выбор неправильный, модель пропускает релевантный факт и выдаёт обычный ответ. Если выбор слишком широкий, промпт выходит за окно контекста или тратит tokens на шум. Сборка — это привратник; тихий шаг, которого пользователь никогда не видит, но всё ощущение «AI помнит» сидит на её качестве.
Сборка также попадает в жёсткий бюджет задержки. Пользователь ждёт; всё выше ~100 ms начинает ощущаться медленным до того, как стримится хоть один token модели. Поэтому сборка опирается на индексированный поиск, а не на полные сканы, поэтому оценка — это взвешенная сумма (а не вызов LLM), и поэтому бюджеты tokens на уровень вычисляются заранее, а не согласуются динамически.
Гибридный поиск по всем трём уровням памяти — memories, episodes, procedures — с использованием и keyword, и семантических сигналов. Запрос пользователя представляется embedding'ом той же моделью, которая индексировала хранилище (bge-m3 1024-dim в конфигурации Alma по умолчанию), и embedding запускается против векторного индекса, чтобы поднять семантически похожие записи. Параллельно keyword-поиск попадает в реляционный индекс для точных совпадений терминов, которые семантический поиск иногда упускает (имена собственные, идентификаторы кода, редкие технические термины).
Оба набора результатов объединяются, дедуплицируются и ограничиваются бюджетом кандидатов (по умолчанию 100 на уровень — максимум, который поддерживает базовый векторный индекс на запрос). Пул кандидатов — это то, что течёт в оценку; ничто после этой стадии не спасает запись, которую поиск не поднял.
Пять сигналов, взвешенных следующим образом в production-функции оценки:
Веса намеренно настроены: релевантность доминирует, но вторичные сигналы имеют значение, когда релевантность совпадает (что часто происходит в плотных хранилищах памяти). Веса — неприкосновенные инварианты в кодовой базе; изменения требуют A/B-бенчмарка, потому что пользовательски ощущаемое качество «вспомнил ли AI правильную вещь» зависит от этой точной смеси.
У каждого уровня (memories, episodes, procedures, Soul-блоки) есть собственный бюджет tokens. По умолчанию: memories ~2 K tokens, episodes ~1 K, procedures ~500, Soul-блоки ~500. Итого ~4 K — значительно ниже любого современного окна контекста модели и достаточно мало, чтобы оставаться cache-friendly. Внутри каждого уровня оценённые записи добавляются в порядке ранга, пока бюджет не достигнут.
Бюджет существует по двум причинам. Первая, эффективный контекст модели сжимается, если набивать его за определённой плотностью — релевантные вещи внизу 100K-token промпта де-факто невидимы для шаблона attention. Вторая, prompt caching работает только если кэшированный префикс стабилен; раздувание промпта memories с низким сигналом ломает кэш и заставляет каждый ход платить tokens по полной цене. Плотные бюджеты держат и качество, и экономику в строю.
Структурированный системный промпт с пятью секциями (в этом порядке): идентичность (активные Soul-блоки, отрендеренные как XML), предпочтения (записи памяти высокой важности, помеченные как предпочтения), релевантные факты (наилучше оценённые memories для этого запроса), недавний контекст (наилучше оценённые episodes), workflows (наилучше оценённые procedures). Структура имеет значение: размещение идентичности наверху означает, что она получает полное внимание; размещение workflows внизу означает, что они консультируются, только если модель решает, что запрос процедурный.
Сообщение пользователя затем добавляется как следующий ход. Модель получает собранный промпт + сообщение пользователя и выдаёт ответ. С точки зрения пользователя, AI просто ответил. Под капотом сборка тихо консультировалась с тысячами записей памяти и показала модели правильные тридцать.
В production-развёртывании Alma сквозная задержка сборки сидит в диапазоне 30-80 ms для типичного пользователя (несколько сотен memories, дюжина episodes). Векторный поиск доминирует (~20-40 ms), keyword-поиск работает параллельно (~5-10 ms), оценка — однозначные ms, и построение промпта по сути бесплатно. Целевые 100 ms достигнуты с комфортным запасом даже для пользователей с тысячами memories — ограничение кандидатов и бюджеты уровней держат работу ограниченной по мере роста хранилища.
До оценки проход обнаружения противоречий по пулу кандидатов помечает пары в диапазоне сходства 0.75-0.92, которые семантически конфликтуют. Более новая запись побеждает по умолчанию; более старая помечается замещённой и удаляется из набора кандидатов для этого хода (и глобально, на следующем проходе консолидации). Это не даёт модели получать «Вы сказали X» рядом с «Вы сказали не-X» и импровизировать синтез, на который пользователь никогда не соглашался.
Полный жизненный цикл (дедупликация, замещение, угасание) задокументирован в полном руководстве по устойчивой памяти; сборка — это просто там, где эти решения жизненного цикла появляются во время запроса.
Архитектурно похоже (оба извлекают, оба ранжируют, оба вставляют в промпт), но корпус и жизненный цикл отличаются. RAG извлекает из внешнего корпуса документов, написанного один раз и переиндексируемого по расписанию; записи обычно не развиваются. Сборка памяти извлекает из собственного непрерывно растущего хранилища пользователя, с записями, которые противоречат, объединяются и угасают. Веса оценки также отличаются — RAG ранжирует в основном по сходству и авторитету документа; сборка памяти взвешивает важность, недавность и частоту, потому что эти сигналы имеют большее значение, когда хранилище личное. См. более глубокое сравнение в «Устойчивая память против RAG».
Да. Эндпоинт POST /api/v1/context/assemble принимает переопределения для бюджетов на уровень, минимального порога оценки, ограничения кандидатов и весов повышения для category-тегов (так что PM-агент может повышать решения, агент автора может повышать правила голоса). Большинство команд остаются на значениях по умолчанию — они были настроены, чтобы быть полезными из коробки — но рычаги существуют для специализированных вертикалей.
Начните на alma.olivares.ai, заполните двадцать или тридцать memories о проекте, который Вам важен, затем начните чат. Первый ответ модели в новом разговоре будет ссылаться на конкретные факты из Вашего хранилища памяти — это сборка, просто спрятанная за пользовательски видимым чатом. Для разработчиков, интегрирующих напрямую: REST API открывает сырой собранный промпт, чтобы Вы могли проверить, что именно было выбрано для каждого запроса.
Связанное чтение: Техническая справка по сборке контекста · Трёхуровневая архитектура памяти · Устойчивая память для AI: полное руководство 2026 · Устойчивая память против RAG · Soul Engine объяснён.