Пам’ять AI-агента — це не база даних: що зберігати, що отримувати та що забувати.
Чому пам’ять агента є проблемою релевантності: у чому відмінності між контекстом, пам’яттю, станом та RAG, що зберігати, як визначати обсяг, контролювати термін дії та проводити аудит, і чому забування є корисною рисою.
Джерела: AI Agent Memory Is Not a Database
Пам’ять для штучних інтелектуальних агентів зазвичай пропонується як функція, яка робить їх розумнішими: згадування попередніх розмов, уподобань користувача, попередніх кроків робочого процесу, того, що спрацювало минулого разу, фактів з документів. Мрія полягає у створенні агента, який знає все, що коли-небудь бачив. Саме тут починається плутанина, адже агенту не потрібно пам’ятати все, і пам’ять — це не те саме, що зберігання даних.
База даних може містити мільйони записів, причому жоден з них не повинен знаходитися в пам’яті агента. Інженерні запитання є іншими: що слід пам’ятати та на який час? Де це зберігається, коли його завантажують, коли видаляють? І чи є це взагалі пам’яттю? Якщо дивитися з цієї точки зору, пам’ять — це скоріше проблема релевантності, ніж проблема зберігання.
Чому підхід „зберігати все“ не спрацьовує
Уявіть агента, який виконує тривале завдання. На першому кроці він з’ясовує мету користувача, обраний документ, кілька вилучених значень, результат роботи інструменту, тимчасове рішення та результат перевірки. Потім настає ще один крок, а потім ще один, і кількість інформації зростає.
Найпростіший спосіб реалізації — зберігати все: додавати кожне повідомлення, зберігати кожен результат роботи інструменту та пересилати все під час наступного запиту. Це працює деякий час. Потім обсяг контексту зростає, відповіді уповільнюються, витрати збільшуються, застаріла інформація починає впливати на нові рішення, а дані, які вже не мають значення, все ще залишаються у запиті. Фактично від моделі вимагають визначити, які з п’ятдесяти речей мають значення прямо зараз. На цьому етапі пам’ять перетворюється на шум.
Чотири терміни, які часто плутають
Ці концепції вирішують різні проблеми, і проекти агентів покращуються, коли їх розділяють.
Контекст — це те, що модель повинна знати у цю мить: поточний запит, обрані докази, кілька попередніх рішень, результати використання відповідних інструментів. Він є тимчасовим та слугує для поточного кроку міркувань.
Пам’ять — це інформація, яку система може знову потребувати пізніше, така як уподобання користувача, рішення, підтверджене кимось, корисний огляд або результат попереднього завдання. Вона може існувати довше, ніж один виклик моделі.
Стан вказує на те, на якій стадії знаходиться робочий процес. Це може бути статус на кшталт QUEUED, RUNNING, WAITING_FOR_TOOL, RETRYING або COMPLETED, або більш деталізовані позначки, такі як document_extracted = true, analysis_completed = true та report_generated = false. Стан дозволяє системі продовжувати роботу. Це не є знанням.
RAG означає отримання знань із зовнішнього джерела тоді, коли вони потрібні: документи, бази даних, політики, звіти, внутрішні вікі, сховища векторів. Ця інформація вже знаходиться деінде. Агенту не потрібно постійно її пам’ятати, достатньо знайти її за потреби, що є окремою проблемою.
Короткострокова пам’ять
Короткострокова пам’ять — це робочий набір інформації. Люди, які вирішують проблему, зберігають у своїй пам’яті певні факти та викидають більшість з них після завершення, і агенти мають таку саму потребу. Під час виконання певної роботи агент може використовувати поточний запит, обраний документ, результати нещодавніх операцій з інструментами, проміжні розрахунки, попередні рішення та прогрес у виконанні завдання. Усе це має значення зараз, але завтра може стати майже безцінним. Хорошим визначенням є найменший набір інформації, необхідний для продовження поточного завдання, а не все, що сталось з моменту його початку.
Довгострокова пам’ять мусить заслужити своє місце
Довгострокова пам’ять — це те, що ви навмисно зберігаєте, тому що це може знову стати в пригоді. Прикладами є чітко сформульована перевага, наприклад «віддаю перевагу стислим звітам», підтверджений бізнес-вибір, наприклад «використовувати цю форму звітності для майбутнього аналізу», або підтверджений факт, наприклад «у цьому проєкті система A вважається джерелом істини».
Тут стандарти мають бути вищими. Перш ніж щось зберігати, запитайте себе, чи це, ймовірно, покращить майбутнє рішення. Якщо ні, залиште це осторонь, адже довгострокова пам’ять має не лише витрати на зберігання: кожен елемент — це щось, що система може згодом отримати, довіритися, підтримувати чи сприйняти неправильно.
RAG — це не довгострокова пам’ять
Припустимо, у векторному індексі є 20 000 внутрішніх документів, і агент може їх шукати. Це не пам’ять агента. Документи є знаннями, а RAG — це спосіб їх отримання. Агент не повинен зберігати всі документи у своїй пам’яті, йому достатньо знати, як знайти потрібний. Здоровий підхід полягає у тому, що агент потребує інформації, шукає її у джерелі знань, отримує відповідні докази та використовує їх. Нездоровий підхід — це копіювання всіх знань у пам’ять. Знання можуть бути величезними, тоді як робоча пам’ять мусить залишатися обмеженою.
Стан часто має більше значення, ніж пам’ять
Більша частина того, що називається пам’яттю агента, насправді є станом робочого процесу. Припустимо, агент завершив вилучення документа, отримання доказів та їх аналіз, проте звіт ще потрібно створити. Якщо пристрій зупиняється до завершення звіту, система мусить знати, де продовжити роботу. Це і є станом. Моделі не потрібно пам’ятати, що крок аналізу завершено, адже про це знає додаток.
Статус завдання, кількість спроб повторної обробки, контрольні точки, ідентифікатори завдань, виконані кроки та дії, що залишилися, зазвичай належать до детермінованого стану додатку, а не до частини розмови з ШІ. Гарне правило: якщо програмне забезпечення може точно знати щось, нехай воно і зберігає це точно. Модель не повинна нести відповідальність за зберігання інформації про робочий процес.
Не все, що сталось, заслуговує на місце
Уявіть собі інструмент, який повертає JSON-дані об’ємом 500 рядків. Чи потрібні наступному кроку всі 500 рядків? Ймовірно, достатньо лише одного-двох полів, наприклад account_status = ACTIVE, total_balance = 120000 або document_found = true. Чистий вихідний даний можна залишити у журналах або сховищі, а в пам’яті можна зберігати лише ті частини, які мають значення.
Діалоги працюють так само. Якщо користувач та агент витратили десять повідомлень на уточнення вимог, стисла записка на кшталт „Користувач хоче, щоб звіт був групований за категоріями та впорядкований за ступенем серйозності“ принесе більше користі, ніж щоразу повторювати весь обмін повідомленнями.
Що варто запам’ятати
Жодна єдина відповідь не підходить до кожної системи, але існує кілька категорій, які зазвичай є хорошими варіантами:
- Стабільні уподобання: формат виведення, мова, стиль звітності.
Чого варто уникати під час зберігання
- Кожну відповідь моделі. Більшість проміжних міркувань не є корисними згодом.
- Кожен результат роботи інструменту, який може бути об’ємним, застарілим або стосуватися лише певного моменту.
- Тимчасові помилки. Вчорашній тайм-аут не повинен стати контекстом завтра.
- Неперевірені припущення моделі — найбільш ризиковане з усього. Якщо модель стверджує, що документ „схоже посилається на Компанію А“, а ніхто це не підтверджує, його зберігання може перетворити слабку припущення на постійний факт, на якому потім будуватиметься подальша робота.
- Конфіденційні дані без чіткої причини їх зберігання. Пам’ять має мати певну мету.
Пам’ять може бути неправильною
Це одна з найбільших проблем довгострокової пам’яті. Система зберігає інформацію про те, що валютою звітності клієнта є USD, а через шість місяців його уподобання змінюються, проте стара інформація залишається. Що має перевагу? Пам’ять потребує поняття актуальності. Деякі факти залишаються дійсними роками, а інші — хвилинами, і хороша система розрізняє їх.
Життєвий цикл, а не просто зберігання та забуття
Пам’ять не повинна постійно зберігати дані у одному місці. Більш реалістичний цикл включає кроки захоплення даних, їх перевірки, зберігання, отримання, використання, а потім оновлення, закінчення терміну дії чи видалення. Для підтримки цього процесу кожен запис може потребувати часу створення, джерела походження, позначки про підтвердження чи непідтвердження, часу останнього використання, правила щодо терміну дії та посилання на будь-яке новіше значення, яке його замінило. Запис даних — це лише половина роботи; інша половина — їх обслуговування.
Важливість джерела
Припустимо, існують дві записи пам’яті. Одна стверджує, що бажаним форматом є PDF, і користувач вчора прямо це підтвердив. Інша каже, що бажаним форматом може бути Excel, про що ШІ зробив висновок шість місяців тому. Вони не повинні мати однакової ваги, саме тому ідеально, щоб пам’ять фіксувала походження інформації: чи надав її користувач, створив система, зробив висновок модель, отримано з документа, повернуло інструмент чи скопійовано з іншого джерела? Саме цей контекст підказує системі, наскільки їй можна довіряти.
Рівень впевненості також має значення
„Термін дії контракту, схоже, закінчується у червні“ — це інший тип твердження, ніж „Дата закінчення контракту: 30 червня 2027 року“, отримана зі структурованого поля. Одне можна вважати дуже надійним, а інше — потребуючим підтвердження, тож розмиті висновки не перетворюються мимохідь на факти. Корисний довгостроковий запис часто містить більше, ніж просто значення; він також може мати source, confidence, timestamp, scope та status, що робить подальший пошук значно безпечнішим.
Резюме є інтерпретаціями
Резюме є одним із найкращих способів зменшити обсяг робочої пам’яті. Зберігайте формулювання на кшталт „користувач хоче стисле технічне пояснення з прикладами“ замість повної розмови, або „три результати підтверджені, один залишився нерозв’язаним“ замість опису кожного етапу аналізу. Проблема полягає у тому, що резюме є інтерпретацією та може пропустити важливу деталь. Для важливих робочих процесів поєднуйте резюме з посиланням на первинні докази. Резюме допомагає зберегти ефективність агента, а первинні дані залишаються доступними у разі необхідності перевірки.
Не створюйте друге джерело істини
Якщо дані клієнта вже зберігаються у основній базі даних клієнтів, їх копіювання до довготривалої пам’яті агента зазвичай є помилкою. Незабаром обидві копії починають не збігатися, і ніхто не знає, яка з них правильна. Краще використовувати авторитетну систему як джерело інформації у разі потреби та вводити отримані дані до контексту агента. Не створюйте дублікати системи запису без дуже чіткої причини. Критерій — чи можна надійно отримати інформацію з її джерела, замість того щоб пам’ятати її. Якщо так, то отримання інформації може бути кращим варіантом, ніж її зберігання у пам’яті.
Обсяг
Коли кілька користувачів, організацій чи робочих процесів користуються однією інфраструктурою агента, існують обмеження щодо потреб у пам’яті. Пам’ять одного користувача не повинна з’являтися в контексті іншого, одна організація не повинна отримувати дані іншої, а один робочий процес може не потребувати проміжних результатів іншого. Зазвичай пам’яті потрібен чітко визначений діапазон дії – глобальний, організаційний, користувацький, конверсаційний, робочий процес чи завдання. Чим вужчий діапазон, тим менша ймовірність потрапляння непотрібної інформації у рішення, яке не стосується її.
Отримання пам’яті – це проблема пошуку
З 500 збереженими спогадами ніхто не повинен включати їх усі до кожного запиту. Ми знову стикаємося з проблемою контексту, тому для отримання інформації з пам’яті потрібна власна процедура: аналізуємо поточне завдання, визначаємо, який тип пам’яті є релевантним, фільтруємо за користувачем, робочим процесом та структурою організації, шукаємо, ранжуємо, вибираємо та додаємо найкращі результати до робочого контексту. Саме тому інженерія пам’яті та контексту так тісно пов’язані. Пам’ять визначає, що може бути доступним у майбутньому, а інженерія контексту визначає, що використовується зараз.
Писати менше, отримувати краще
Замість того, щоб запитувати, що ще можна зберегти, потрібно запитувати, яка інформація має достатню майбутню цінність, щоб виправдати її збереження. Замість того, щоб запитувати, скільки пам’яті вміщується у запиті, потрібно запитувати, яка пам’ять є релевантною для цього рішення. Хороша архітектура пам’яті зазвичай має змушувати агента бачити менше, оскільки нерелевантна пам’ять — це просто нерелевантний контекст.
Спостережуваність
Уявімо, що агент дає дивну відповідь. Отриманий документ виглядає правильно, виклик інструменту успішний, проте відповідь неправильна, і зрештою хтось з’ясовує, що на рішення вплинула стара пам’ять. Без можливості бачити процес отримання пам’яті це дуже складно виправляти. Для кожного запуску корисно фіксувати, які пам’яті були використані та чому, їхнє походження та вік, підтверджений статус, чи потрапили вони до кінцевого контексту та чи змінили вони результат. Це перетворює пам’ять з прихованої складової на щось, що можна перевірити.
Більш реалістична архітектура
Замість того, щоб усе потрапляло спочатку до пам’яті, а потім до агента, уявіть таке: приходить користувач чи завдання, перевіряється стан робочого процесу, і система вирішує, яка інформація потрібна. Потім вона черпає дані з різних джерел:
- Контекст роботи щодо того, що потрібно зараз, наприклад поточний запит, останній результат інструменту та поточне рішення.
- Короткострокова пам’ять щодо того, що необхідно протягом цього робочого процесу, наприклад короткий опис завдання, тимчасові результати та нещодавні рішення.
- Довгострокова пам’ять щодо того, що може стати корисним для майбутніх робочих процесів, наприклад стабільні уподобання, підтверджені факти чи історичні результати.
- Знання та RAG для інформації, яка знаходиться в інших джерелах, таких як документи, політики, звіти та бази даних.
- Стан застосунку для визначення істини, наприклад статус, контрольні точки, кількість спроб та завершені кроки.
Після цього необхідно відфільтрувати, ранжувати та об’єднати поточний контекст, щоб агент міг міркувати. Називання всього цього просто пам’яттю приховує його структуру.
Питання, які потрібно поставити перед додаванням функції пам’яті
- Чи допоможе це у майбутньому завданні? Якщо ні, не зберігайте це.
Відповіді на ці запитання зазвичай мають більше значення, ніж вибір бази даних пам’яті.
Забування — це функція
Хороша пам’ять не означає здатності запам’ятовувати все. Корисний агент повинен забувати багато чого: тимчасові деталі, результати попередніх операцій, неперевірені припущення, застарілі факти та міркування, які більше не мають значення. Більша кількість пам’яті не робить систему автоматично розумнішою, а іноді навіть дає моделі більше можливостей поєднувати неправильні елементи. На практиці це означає: зберігати лише те, що стане корисним пізніше, зберігати стан робочого процесу у простому детерміністичному коді, отримувати знання з того місця, де вони знаходяться, дозволяти лише актуальним спогадам потрапляти до запиту, відзначати походження кожного з них та оновлювати або видаляти записи у міру зміни фактів.
Бази даних існують для зберігання інформації. Пам’ять агента має іншу функцію: підставляти потрібні факти перед моделлю у момент їх необхідності, водночас запобігаючи тому, щоб старі непотрібні дані перетворилися на остаточні істини.