Активна та персистентна пам’ять у ШІ: як ШІ запам’ятовує, знаходить і забуває

Активна пам’ять — це інформація, доступна системі ШІ для виконання поточного завдання. Персистентна пам’ять — це інформація, яку зберігає застосунок, щоб нею можна було скористатися пізніше. Взаємозв’язок між ними визначає, чи зможе помічник продовжити роботу над проєктом, врахувати вподобання, виправити застаріле припущення або перестати знову порушувати тему того, що він мав забути.

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

Саме тому може здаватися, що ШІ пам’ятає одну деталь, але забуває іншу з тієї самої розмови. Запам’ятовування — це послідовність операцій. Збій може статися під час збирання, зберігання, пошуку, відбору, інтерпретації або оновлення інформації.

У цьому посібнику ми детально розглянемо цю послідовність. Ширшу класифікацію епізодичної, семантичної та процедурної пам’яті дивіться у вступі до типів пам’яті ШІ-агентів. Тут зосередимося на межі між тим, що активне зараз, і тим, що може зберігатися після завершення поточного завдання.

Що насправді означають активна та персистентна пам’ять?

Ці терміни описують корисні архітектурні відмінності, але ця пара понять не має загальноприйнятого стандартного визначення. В інтерфейсах продуктів і наукових працях поняття «робоча пам’ять», «короткочасна пам’ять», «контекст», «стан» і «довготривала пам’ять» часто перетинаються за значенням. Тому для точного пояснення потрібно визначити вживані терміни.

У цій статті активний контекст — це інформація, яку передають моделі для формування поточної відповіді: інструкції, повідомлення, вибрані результати роботи інструментів, знайдені матеріали та інші дані, які модель може опрацювати. Активний стан завдання — ширше поняття. Він може включати план, контрольний список або змінні, які застосунок зберігає, але ще не додав до контексту моделі. Ми використовуємо поняття активної пам’яті як практичну загальну назву для цього поточного робочого набору, розрізняючи ці два поняття там, де це важливо.

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

Отже, є два окремі запитання: Чи досі існує ця інформація? і Чи отримає її модель, коли вона знадобиться? Збережений запис розмови може дати відповідь на перше запитання, але не вирішити другого.

Важливий виняток: короткочасний стан можна зберегти

«Короткочасний» не завжди означає «збережений лише в енергозалежній оперативній пам’яті». Робочий стан розмови можна зафіксувати в базі даних і відновити після переривання. Наприклад, у документації LangChain про пам’ять розрізняються стан у межах одного потоку, збережений за допомогою контрольних точок, і довготривала пам’ять, упорядкована в окремих просторах імен.

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

Оцінюючи будь-яку функцію пам’яті, корисно зважати на три параметри: її тривалість зберігання, її сферу дії та доступність для поточного виклику моделі. Позначення на кшталт «довготривала» не дає повної відповіді на жодне з цих запитань.

Активна та персистентна пам’ять: короткий огляд

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

Що відбувається під час однієї відповіді ШІ?

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

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

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

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

Чому більше контекстне вікно не розв’язує проблему пам’яті

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

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

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

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

Як інформація стає довготривалою пам’яттю

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

«Для проєкту Cedar використовуйте метричні одиниці» — це пряма вподобана настройка проєкту. «Схоже, користувач надає перевагу метричним одиницям» — це висновок. «В останніх трьох звітах Cedar використовували метричні одиниці» — це спостереження. Корисний запис зберігає ці відмінності, а не зводить їх до беззастережного твердження про всі майбутні завдання.

Що має містити корисний запис

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

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

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

Записи відразу чи фонова обробка

Негайний запис дає змогу врахувати чітке виправлення вже в наступному запиті. Фонова обробка може проаналізувати завершену взаємодію, об’єднати дублікати або підготувати ретельніше узагальнення. У документації LangChain описано обидва підходи та пов’язані з ними компроміси, зокрема додаткове навантаження на процес підготовки відповіді в разі негайного запису.

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

Для запису даних у пам’ять також потрібна політика на випадок помилок. Якщо сховище тимчасово недоступне, застосунок може повідомити, що збереження не вдалося завершити, або залишити чітко позначену операцію в очікуванні. Якщо вважати спробу запису успішним збереженням у пам’яті, це вводитиме користувача в оману.

Як записи з довготривалої пам’яті повертаються в поточний контекст

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

Метод пошуку має відповідати запитанню. На запитання «Який крайній термін затверджено для проєкту Cedar?» найкраще відповісти, точно знайшовши потрібне поле проєкту. Для запитання «Чи траплялася нам раніше ця помилка розгортання?» можуть стати в пригоді пошук за ключовими словами та семантична подібність із даними про минулі інциденти. Векторна база даних — один із можливих засобів у цьому процесі, а не обов’язкова умова для роботи будь-якої системи пам’яті.

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

Пошук має передбачати результат «не знайдено»

Розгляньмо запитання: «Який ліміт витрат я затвердив минулого місяця?» Якщо знайти затверджену суму не вдається, корисна відповідь має вказати, яких даних бракує, і попросити уточнення. Якщо натомість назвати правдоподібне число, відсутність запису в пам’яті перетвориться на вигаданий дозвіл.

Тому інтерфейс пам’яті має розрізняти підтверджений збіг, непевний збіг, суперечність і відсутність запису на підтвердження. Ці результати можуть зумовлювати різну поведінку: відповісти прямо, уточнити відповідь, попросити уточнення або відмовитися діяти на підставі непідтвердженого припущення.

Після пошуку важливо правильно інтерпретувати знайдене. Запис «запропонований максимальний бюджет: $5,000, очікується погодження» не можна перетворювати на «погоджений бюджет: $5,000». Зберігати уточнення в записі та наданому контексті не менш важливо, ніж знаходити потрібний документ.

Практичний приклад: як пам’ятати проєкт упродовж часу

Уявімо, що помічник допомагає команді підготувати дослідницький звіт Cedar. Наведений приклад гіпотетичний, але він демонструє кілька поширених підходів до проєктування пам’яті.

Сеанс перший: закласти основу проєкту

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

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

Сеанс другий: продовжити роботу з потрібними джерелами

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

Якщо в контрольному записі зазначено, що огляд літератури завершено, помічник усе одно має відкрити збережений документ, перш ніж вносити до нього зміни. «Завершено» — це твердження про поступ роботи; фактичний документ свідчить про те, що саме було зроблено. Надійні посилання на матеріали можуть бути кориснішими за підсумок, який намагається відтворити весь їхній вміст.

Сеанс третій: застосувати виняток, не переписуючи все

Користувач просить підготувати версію для клієнта, у якій зазначено і метричні, і імперські одиниці. У поточному завданні слід використовувати обидві системи. Чи змінюється загальне правило проєкту, залежить від формулювання та сфери дії прохання користувача: «для цієї версії» має вужчу сферу дії, ніж «відтепер використовуйте обидві системи».

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

Сеанс четвертий: завершити роботу й очистити тимчасові дані

Після передавання результату етап слід позначити як завершений. На вказівку «продовжити роботу над звітом» помічник має відкрити передану версію й запитати, які зміни потрібні, а не повертатися до застарілого списку завдань. Тимчасові робочі нотатки можуть видалятися відповідно до правил проєкту, тоді як остаточний звіт і важливі рішення мають залишатися доступними.

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

Узагальнення, ущільнення та ризик втратити виняток

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

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

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

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

У підсумках також слід зберігати непевність. «Ми розглядали можливість використати опитування B» не можна перетворювати на «Було обрано опитування B». Якщо після стиснення історії попередні рішення видаються остаточними, система створила хибний спогад, намагаючись зекономити місце в контексті.

Як ШІ має працювати з виправленнями та суперечностями в пам’яті

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

Корисніше оновлення визначає, що саме замінюють нові докази. Якщо керівник проєкту переносить дату запуску з 15 листопада на 29 листопада, старий запис можна позначити як замінений і пов’язати з новим рішенням. На запитання про поточний крайній термін слід відповідати за новою версією, а для запитань про початковий план можна звернутися до історичної версії.

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

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

Що означає забування для ШІ?

Забування — це не один перемикач. Продукт може припинити додавати факт до промптів, виключити його зі звичайного пошуку, позначити як застарілий, видалити запис із пам’яті або прибрати інші збережені копії. Ці операції по-різному впливають на подальшу поведінку та збережені дані.

Вихід з активного контексту

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

Завершення строку дії або придушення відтворення

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

Видалення збереженої пам’яті

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

Для резервних копій і журналів можуть діяти власні графіки зберігання. Продукт має чітко пояснювати ці обмеження та не допускати повторної активації видаленого матеріалу під час відновлення. Обіцянки «ми більше не використовуватимемо цю пам’ять» і «усі збережені копії видалено» — не одне й те саме.

Зміна ваг моделі

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

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

Пам’ять, RAG, навчання та кешування: де проходять межі

Генерація з доповненням пошуком, або RAG, забезпечує модель зовнішніми даними під час генерування. У перших дослідженнях RAG параметри моделі поєднувалися з індексом документів, доступних для пошуку. Система персональної пам’яті теж може використовувати пошук, але їй також потрібні правила створення, оновлення та вилучення записів про взаємодії.

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

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

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

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

Чому через постійну пам’ять помилки можуть мати триваліші наслідки

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

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

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

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

Як оцінити, чи справді працює пам’ять

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

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

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

• Точність запису: Чи зберегла система потрібне твердження разом із його межами застосування та уточненнями?
• Корисність пошуку: Чи знайшла система потрібні для завдання дані, не перевантаживши контекст сторонньою історією?
• Обробка оновлень: Чи замінило виправлення актуальний факт зі збереженням важливих історичних відмінностей?
• Утримання від відповіді: Чи визнав помічник, що підтверджувального запису немає?
• Ізоляція: Чи залишилися записи доступними лише відповідному користувачеві, клієнту й проєкту?
• Забування: Чи перешкодило видалення або завершення строку зберігання запланованому відтворенню інформації в майбутньому, зокрема через похідні зведення?
• Експлуатаційні витрати: Чи виправдовують поліпшення додаткові затримки, виклики моделі, витрати на зберігання та обслуговування?

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

Як обрати правильну структуру пам’яті

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

Спершу визначте майбутнє запитання, на яке має відповідати пам’ять. Запитання «Що ще не завершено?» потребує стану завдання. Запитання «Якого формату вимагає цей клієнт?» потребує налаштування з чітко визначеною сферою застосування. Запитання «Чому ми відхилили цей підхід?» потребує запису про рішення з підтверджувальними доказами. Для різних запитань потрібні різні способи подання інформації.

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

Активна пам’ять формує для системи ШІ цілісне уявлення про теперішній стан. Постійна пам’ять може забезпечити їй безперервність у часі. Якість цієї безперервності залежить від рішень, що визначають взаємодію між ними: що зберігається, що відновлюється, яка версія є чинною та що можна видалити.