Пам'ять агента ШІ: чотири типи та як їх зберігати

Пам'ять агента ШІ дозволяє агентові перенести щось з одного кроку або однієї сесії до наступної. Мовна модель сама по собі нічого не пам'ятає між викликами. Усе, що вона ніби пам'ятає, ваш код повернув у промпт. Те, як ви зберігаєте й отримуєте цей матеріал, визначає, що агент може пригадати, як швидко і якою ціною за кожен хід.

Коротко. Агентам потрібні чотири типи пам'яті: коротке вікно розмови, довгострокові факти, що знаходяться за змістом, чернетка для поточного завдання та журнал того, що сталося. Кожен має іншу форму, строк життя й спосіб пошуку, тому одна таблиця пам'яті погано підходить для будь-якого з них. HotKV зберігає всі чотири в одному рушії в оперативній пам'яті командами AMEM.*. Ми вимірювали кешування та векторний пошук HotKV, а не пам'ять агентів, тож ця стаття пояснює задум і не заявляє про жодне прискорення.

Чому контекстне вікно не є пам'яттю

Контекстне вікно це текст, який ви надсилаєте з кожним запитом. Воно має обмеження розміру, ви щоразу платите вхідними токенами за все, що в ньому є, і воно зникає, коли сесія закінчується. Крім того, в ньому не можна шукати. Якщо агентові потрібен один факт тритижневої давності, вставити всю історію не є відповіддю.

Пам'ять це шар, що вирішує, що потрапить у вікно далі. Вона зберігає останні репліки й знаходить кілька старіших фактів, які важливі. Вона тримає стан поточного завдання та записує, що зробив агент. Дослідники описують агентів схожими термінами. Фреймворк CoALA Самерса, Яо, Нарасімхана та Гріффітса відокремлює робочу пам'ять від довгострокової епізодичної, семантичної та процедурної пам'яті.

Чотири типи пам'яті агента ШІ

Чотири сховища HotKV охоплюють більшу частину тієї самої території, адаптовані до того, що має будувати застосунок. Процедурна пам'ять, тобто знання, закладені в код і промпти агента, зазвичай живе у вашому репозиторії або реєстрі промптів і не є окремим сховищем.

Розмовна пам'ять

Це короткостроковий запис однієї сесії. Повідомлення мають роль (system, user, assistant або tool). Вони лежать в обмеженому ковзному вікні, тож найстаріші репліки випадають, коли ліміт досягнуто. Вона відповідає на одне запитання. Що було сказано нещодавно? У HotKV це AMEM.CONV.CREATE, AMEM.CONV.APPEND і AMEM.CONV.WINDOW.

Семантична пам'ять

Семантична пам'ять це довгострокові знання, збережені як факти з вектором ембедингу. Агент пригадує їх за змістом, а не за ключем. Її підтримує індекс HNSW, такий самий, на якому працює векторний пошук. AMEM.SEM.STORE зберігає факт, а AMEM.SEM.RECALL повертає найкращі збіги з оцінкою подібності. Саме тут місце документам, уподобанням користувачів і засвоєним виправленням.

Робоча пам'ять

Робоча пам'ять це чернетка для поточного завдання, плаский набір ключів і значень у межах сесії. Вона зберігає поточний крок, заявку, що обробляється, або частковий результат. Вона має зникнути, коли завдання закінчується. AMEM.WORK.SET приймає час життя саме з цієї причини.

Епізодична пам'ять

Епізодична пам'ять це журнал подій з мітками часу лише для додавання, як-от виконана дія, зроблене спостереження чи ухвалене рішення. Вона дозволяє агентові або людині, що його перевіряє, запитати, що сталося і коли. AMEM.EPIS.LOG записує подію, а AMEM.EPIS.QUERY читає їх назад за типом і діапазоном часу.

Пам'ять агента ШІ на практиці

На практиці важливі дві речі. Як ви записуєте в пам'ять і що читаєте назад на кожному ході.

Збереження пам'яті командами

Ось агент підтримки, що веде одну розмову. Вигаданий текст політики та вектори з трьох чисел призначені лише для ілюстрації. Справжня модель ембедингів видає вектори з 768 або 1536 чисел, і простір імен створюється з цією розмірністю.

AMEM.CONV.CREATE session-42 WINDOW 50 TTL 86400
AMEM.CONV.APPEND session-42 user "My invoice shows the wrong VAT number."
AMEM.WORK.SET session-42 ticket "INV-1932" TTL 3600
AMEM.EPIS.LOG agent-support action "Looked up invoice INV-1932"

AMEM.SEM.CREATE support-kb 3
AMEM.SEM.STORE support-kb vat-policy "VAT details can be corrected within 30 days." 0.1 0.2 0.3
AMEM.SEM.RECALL support-kb 3 0.1 0.2 0.3
AMEM.CONV.WINDOW session-42 10

На кожному ході агент читає останнє вікно й пригадує кілька фактів, що відповідають запитанню. Він перевіряє свою робочу нотатку і будує промпт із цих частин. Після дії він записує подію в журнал. Нічому в цьому циклі не потрібна вся історія.

Читання пам'яті на кожному ході

Зберегти пам'ять легко. Майстерність у тому, щоб вирішити, що читати назад, бо все прочитане потрапляє в промпт і коштує вхідних токенів. Розумний цикл читає кілька речей у фіксованому порядку. Спершу останні репліки, потім кілька фактів, що відповідають запитанню, потім стан завдання. Ось він з офіційним клієнтом Python, з вашою власною функцією ембедингу та шаблоном промпту.

import hotkv

r = hotkv.from_url("hotkv://localhost:6379")
MIN_SIMILARITY = 0.8          # налаштуйте на власних даних

def start_session(session: str) -> None:
    r.amem_conv_create(session, window=50, ttl=86400)   # створіть один раз, перед першим append

def build_context(session: str, question: str) -> str:
    r.amem_conv_append(session, "user", question)
    turns = r.amem_conv_window(session, 10)
    facts = r.amem_sem_recall("support-kb", 3, embed(question))
    facts = [f for f in facts if f["similarity"] >= MIN_SIMILARITY]
    ticket = r.amem_work_get(session, "ticket")
    return render(turns, facts, ticket)      # ваш шаблон промпту

def finish_turn(session: str, agent: str, reply: str) -> None:
    r.amem_conv_append(session, "assistant", reply)
    r.amem_epis_log(agent, "action", "Answered a billing question")
    r.amem_work_set(session, "last_step", "answered")

Поріг подібності вам налаштовувати самим. Значення, що годиться для однієї моделі ембедингів і одного набору фактів, буде неправильним для іншого, тож перевіряйте пригадування на запитаннях, відповіді на які ви знаєте. Відкидати слабкі збіги важливіше, ніж здається, бо поганий факт у промпті гірший за відсутність факту.

Стабільні частини цього промпту, як-от системні інструкції, також є тією частиною, яку здешевлює кешування промптів на боці провайдера. Розміщуйте прочитану пам'ять у кінці, після стабільного тексту, щоб її зміна не робила цей кеш недійсним.

Резюме замість дедалі довших вікон

Вікно повністю відкидає старі репліки. Для балаканини це нормально, а для довгого завдання погано, де репліка 3 може ще мати значення на репліці 300. Звичайна відповідь це ковзне резюме. Після кожного відрізка розмови агент або дешевша модель записує, що було з'ясовано, а резюме замінює старі репліки в промпті.

HotKV зберігає одне резюме на агента через AMEM.SUMMARY.SET, AMEM.SUMMARY.APPEND і AMEM.SUMMARY.GET. SET замінює текст, а APPEND додає рядок. Кожне оновлення збільшує номер версії, тож інший компонент може дешево дізнатися, що резюме змінилося і коли.

Резюме втрачає частину інформації, а резюмування резюме втрачає дедалі більше. Тримайте точні значення, як-от ідентифікатори, суми й дати, поза прозою, у робочій пам'яті або семантичних фактах, де вони виживають. Використовуйте резюме для загального вигляду роботи, як-от уподобань, ухвалених рішень і того, що лишилося.

Правила проєктування та зберігання

Пам'ять росте без обмежень, якщо її не зупинити, тож задайте ліміти до першого запису.

Правила, що зберігають пам'ять корисною

• Обмежуйте все. Задайте WINDOW для розмов і TTL для сесій та робочих значень. Для розмов, робочих значень і фактів HotKV записує час спливання для файлу лише для додавання та реплік, тож запис, термін дії якого вже сплив, не повертається, коли файл відтворюється після перезапуску.
• Зберігайте факти, а не стенограми. Резюмуйте перед записом у семантичну пам'ять. Факт легше пригадати, ніж сторінку діалогу.
• Тримайте агентів окремо. Використовуйте окремий ідентифікатор або простір імен на агента й на тенанта, щоб пам'ять одного клієнта ніколи не пригадувалася для іншого.
• Пригадуйте кілька, а не багато. Беріть три-п'ять найкращих збігів і відкидайте слабкі за оцінкою подібності до того, як вони потраплять у промпт.
• Тримайте секрети осторонь. Пам'ять читається назад у промпти, тож ніколи не зберігайте паролі, ключі чи дані, які ви не показали б моделі.

Як довго зберігати кожен тип

Ці строки це наші пропозиції, а не типові значення. Обирайте свої залежно від того, як швидко змінюються основні факти й що вам дозволено зберігати.

Зберігання це також питання приватності. Якщо пам'ять містить щось про людину, обраний вами строк є частиною того, що ви їй обіцяєте, тож запишіть його.

Як пам'ять агента ламається

Більшість помилок пам'яті повільні. Агент добре працює тиждень, а потім починає працювати гірше. Ось збої, від яких треба проєктувати захист.

Поширені збої

• Застарілі факти. Факт, що був правдою в березні, пригадується в жовтні. Задайте фактам час життя або зберігайте їх під ключем на сутність, щоб нове значення перезаписувало старе.
• Суперечності. Два збережені факти розходяться, і агент вибирає один навмання. Віддавайте перевагу одному факту на ключ, а не додаванню нових нотаток поруч зі старими.
• Надмірне пригадування. Забагато збігів заповнюють промпт слабко пов'язаним текстом. Пригадуйте мало й відкидайте слабкі збіги.
• Витоки між користувачами. Пам'ять одного клієнта пригадується для іншого. Окремі ідентифікатори чи простори імен для кожного тенанта, перевірені в коді перед кожним читанням.
• Необмежене зростання. Ніщо ніколи не спливає, тож пошук сповільнюється, а витрати повзуть угору. Кожен тип потребує строку життя. Де в HotKV немає часу життя, як для епізодичного журналу, самостійно заплануйте очищення або експорт.
• Дрейф резюме. Резюме резюме поступово перестає відповідати тому, що сталося. Тримайте журнал подій як джерело правди й відновлюйте резюме з нього.

Ставтеся до збереженого тексту як до недовіреного

Останній пункт заслуговує більшої уваги. Усе, що агент записує в пам'ять, згодом може потрапити в промпт. Це включає текст, що надійшов з вебсторінки, листа чи від користувача. Це непряма форма ін'єкції в промпт, яку OWASP наводить як LLM01. Зберігайте джерело разом з кожним фактом. Менше довіряйте пам'яті, записаній із зовнішнього вмісту, і ніколи не дозволяйте пригаданій нотатці переважати ваш системний промпт.

Що ми виміряли, а що ні

Опубліковані бенчмарки HotKV охоплюють пропускну здатність команд, векторний пошук і економію токенів завдяки кешуванню відповідей. Пам'ять агентів поки не має власного бенчмарка. Ми не заявляємо нічого про її затримку чи про те, наскільки вона покращує якість агента. Що ми можемо сказати, то це архітектурне. Чотири сховища працюють у тому самому процесі, що й кеш та векторний індекс. Пошук у пам'яті це один виклик до системи, яку ви вже обслуговуєте.

Бенчмарк економії токенів і порівняння кешування промптів та семантичного кешування показують виміряний бік. Сценарій використання пам'яті агента показує команди в повному сценарії.

Використання пам'яті агента з Claude Code або Cursor

Асистент, що підтримує Model Context Protocol, може використовувати частину цієї пам'яті без власного коду. Сервер hotkv-mcp з відкритим кодом відкриває розмовну пам'ять, робочі нотатки, журнал подій і ковзне резюме як інструменти. Він має режим лише для читання та простір імен, що обмежує агента. Він не відкриває семантичну пам'ять, а його інструменти не можуть задати вікно чи час життя, тож для цього використовуйте клієнтську бібліотеку. Наступна стаття, сервер MCP для пам'яті агента, показує, як його підключити і що охоплюють його запобіжники.

Поширені запитання