Травень 2026 · 10 хв читання · Фран Олівареш, засновник OlivaresAI
Сховище постійної памʼяті саме по собі нічого не робить. Сховище має бути запитане, оцінене і сформоване у системний промпт, що поміщається у контекстне вікно моделі перед тим, як приземлиться наступне повідомлення користувача. Цей крок — збирання контексту — це різниця між «у нас є база даних памʼяті» і «ШІ памʼятає». Цей посібник є детальною супутньою публікацією до технічної довідки на /docs/context-assembly і проходить через кожен етап конвеєра, числа, які Alma використовує за замовчуванням, і компроміси, які можна налаштовувати.
Бо модель бачить лише те, що в промпті. Сховище памʼяті з десятьма тисячами записів невидиме для моделі, якщо щось не обере правильні тридцять для цього ходу. Якщо вибір неправильний, модель пропускає релевантний факт і видає родову відповідь. Якщо вибір занадто широкий, промпт перевищує контекстне вікно або марнує токени на шум. Збирання — це вартовий, тихий крок, якого користувач ніколи не бачить, але вся відчутність «ШІ памʼятає» лежить на його якості.
Збирання також укладається в жорсткий бюджет затримки. Користувач чекає; будь-що понад ~100 мс починає відчуватися повільним до того, як один токен моделі стримив. Саме тому збирання покладається на індексований пошук, а не на повне сканування, чому скоринг — це зважена сума (а не виклик LLM), і чому токен-бюджети для кожного рівня обчислюються заздалегідь, а не узгоджуються динамічно.
Гібридний пошук у всіх трьох шарах памʼяті — memories, episodes, procedures — використовуючи як ключове слово, так і семантичні сигнали. Запит користувача embedingується тією самою моделлю, що проіндексувала сховище (bge-m3 1024-dim у конфігурації Alma за замовчуванням), і embedding запускається проти векторного індексу, щоб виявити семантично схожі записи. Паралельно пошук за ключовим словом звертається до реляційного індексу для точних збігів термінів, які іноді пропускає семантичний пошук (власні імена, ідентифікатори коду, рідкісні технічні терміни).
Обидві набори результатів обʼєднуються, дедуплікуються і обмежуються бюджетом кандидатів (за замовчуванням 100 на шар — максимум, що підтримує базовий векторний індекс на запит). Пул кандидатів — це те, що тече у скоринг; ніщо за цим етапом не рятує запис, який не виявив пошук.
Пʼять сигналів, зважених так у продакшн-функції скорингу:
Ваги навмисно налаштовані: релевантність домінує, але вторинні сигнали мають значення, коли релевантність зрівнюється (що часто буває у щільних сховищах памʼяті). Ваги — непорушні інваріанти у кодовій базі; зміни вимагають A/B-бенчмарку, бо відчуття користувачем якості «чи ШІ запамʼятав правильну річ» залежить від саме цієї суміші.
Кожен рівень (memories, episodes, procedures, блоки Soul) має власний токен-бюджет. За замовчуванням: memories ~2K токенів, episodes ~1K, procedures ~500, блоки Soul ~500. Загалом ~4K — добре під будь-яким сучасним контекстним вікном моделі і достатньо мало, щоб залишатися cache-friendly. У межах кожного рівня оцінені записи додаються у порядку рангу, доки не досягне бюджет.
Бюджет існує з двох причин. По-перше, ефективний контекст моделі зменшується, якщо запхати його за певну щільність — релевантні речі внизу 100K-токенового промпта де-факто невидимі для патерну уваги. По-друге, кешування промптів працює, лише якщо кешований префікс стабільний; роздування промпта memories з низьким сигналом ламає кеш і змушує кожен хід платити повну ціну за токени. Тісні бюджети тримають у лінії і якість, і економіку.
Структурований системний промпт з пʼятьма секціями (у цьому порядку): ідентичність (активні блоки Soul, рендерені як XML), вподобання (записи памʼяті з високою важливістю, позначені як вподобання), релевантні факти (memories з найвищою оцінкою для цього запиту), свіжий контекст (episodes з найвищою оцінкою), робочі процеси (procedures з найвищою оцінкою). Структура має значення: розміщення ідентичності зверху означає, що вона отримує повну увагу; розміщення робочих процесів знизу означає, що з ними консультуються лише якщо модель вирішить, що запит процедурний.
Повідомлення користувача потім додається як наступний хід. Модель отримує зібраний промпт + повідомлення користувача і видає відповідь. З погляду користувача, ШІ просто відповів. Під капотом збирання тихо консультувалося з тисячами записів памʼяті і показало моделі правильні тридцять.
У продакшн-розгортанні Alma наскрізна затримка збирання сидить у діапазоні 30-80 мс для типового користувача (кілька сотень memories, десяток episodes). Векторний пошук домінує (~20-40 мс), пошук за ключовим словом працює паралельно (~5-10 мс), скоринг — однозначні мс, а побудова промпта по суті безкоштовна. Ціль у 100 мс досягається з комфортним запасом навіть для користувачів з тисячами memories — обмеження кандидатів і токен-бюджети тримають роботу обмеженою, поки сховище росте.
До скорингу прохід виявлення суперечностей по пулу кандидатів позначає пари у діапазоні подібності 0.75-0.92, які семантично конфліктують. Свіжіший запис перемагає за замовчуванням; старіший позначається як замінений і видаляється з набору кандидатів для цього ходу (і глобально — на наступному проході консолідації). Це запобігає тому, щоб модель отримала «Ви сказали X» поряд з «Ви сказали не-X» і імпровізувала синтез, з яким користувач ніколи не погоджувався.
Повний життєвий цикл (дедуплікація, заміна, згасання) задокументовано у повному посібнику з постійної памʼяті; збирання — це лише місце, де ці рішення життєвого циклу проявляються під час запиту.
Архітектурно схоже (обидва отримують, обидва ранжують, обидва впорскують у промпт), але корпус і життєвий цикл відрізняються. RAG отримує з зовнішнього корпусу документів, авторованого один раз і переіндексованого за розкладом; записи зазвичай не еволюціонують. Збирання памʼяті отримує з власного сховища користувача, що постійно росте, з записами, що суперечать, обʼєднуються і згасають. Ваги скорингу також відрізняються — RAG ранжує переважно за подібністю і авторитетністю документа; збирання памʼяті зважує важливість, свіжість і частоту, бо ці сигнали мають більше значення, коли сховище особисте. Дивіться глибше порівняння у Постійна памʼять проти RAG.
Так. Ендпоінт POST /api/v1/context/assemble приймає перевизначення для бюджетів кожного рівня, мінімального порогу скорингу, обмеження кандидатів і ваг підсилення для категорійних тегів (щоб PM-агент міг підсилити рішення, агент письменника — правила голосу). Більшість команд залишаються на замовчуваннях — їх налаштовано так, щоб бути корисними «з коробки», — але важелі існують для спеціалізованих вертикалей.
Почніть на alma.olivares.ai, заповніть двадцять-тридцять memories про проєкт, який Вам важливий, потім почніть чат. Перша відповідь моделі в новій розмові посилатиметься на конкретні факти з Вашого сховища памʼяті — це збирання, просто приховане за чатом, орієнтованим на користувача. Для розробників, що інтегруються напряму: REST API виставляє сирий зібраний промпт, щоб Ви могли перевірити, що саме було вибрано для кожного запиту.
Повʼязане читання: Технічна довідка зі збирання контексту · Тришарова архітектура памʼяті · Постійна памʼять для ШІ: повний посібник 2026 · Постійна памʼять проти RAG · Soul Engine пояснено.