Коли ШІ має використовувати свою пам’ять? Пілоти та постійна пам’ять, а також лестощі
Коли ШІ має використовувати свою пам’ять? Отримання інформації з пам’яті не дозволяє йому формувати відповідь. Пілоти з типовою пам’яттю та контролером впливу проти підлабузництва.
Джерела: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Кожен, хто вже кілька місяців користується допоміжним інтелектом, знає цю закономірність. З часом він збирає про вас інформацію: ви віддаєте перевагу Python перед Java, готуєтесь до іспиту, і, можливо, навіть знає деталі про ваше здоров’я, які ви б не наважилися розповісти колезі.
Спочатку це зручно. Ви просите його підготувати план харчування з високим вмістом білка, і він сам запам’ятовує, що ви веган, без вашого прямого повідомлення. Саме в цьому суть персоналізованого асистента.
Тепер змінімо ситуацію. Ви запитуєте, як працює метод градієнтного спуску. Чи повинен асистент згадати, що ви віддаєте перевагу Python? Ймовірно, ні.
Або уявіть, що кілька місяців тому ви стверджували, що підхід X — це явно найкращий. Пізніше ви ставите об’єктивне запитання щодо X. Чи повинен асистент пам’ятати про вашу думку? Можливо, так, як про факт ваших переконань. Але чи повинен він вважати це ваше переконання доказом того, що X справді найкращий? Звісно, ні.
Ось прогалина, яку при обговоренні пам’яті асистентів часто ігнорують. Зберігання факту та визначення моменту, коли він має бути включений до відповіді, — це дві різні навички.
Постійна пам’ять перетворює це на справжню проблему
Звичайні моделі мови працюють переважно з контекстом, наданим під час поточної розмови. Системи з постійною пам’яттю змінюють це. Примітивна система може згадати все, що знає про користувача, оскільки це може бути релевантним, та потім адаптувати свої відповіді під ці факти.
Тож якість пам’яті не можна оцінювати лише за тим, чи використовувала модель пам’ять. Не менш важливим є те, як саме вона нею скористалася.
Нещодавні дослідження почали вимірювати це безпосередньо. PersistBench — це тест на безпеку постійної пам’яті в ШІ на основі LLM — аналізує три категорії: витік пам’яті між доменами, схильність до лестощів через пам’ять та корисне використання пам’яті. Він містить 500 зразків, перевірених людьми, розділених на 200 випадків витоку, 200 випадків схильності до лестощів та 100 випадків корисного використання пам’яті.
Два моделі та складніше питання
Під цими трьома показниками криється ще більш тонка відмінність. Уявіть модель, яка чудово вміє використовувати пам’ять: щоразу, коли пам’ять є релевантною, вона включає її до відповіді. Це звучить чудово. Але що, якщо вона також включає пам’ять у випадках, коли це не має значення?
Тепер уявіть другу модель, яка майже ніколи не користується пам’яттю. Вона рідко допускає витоки, але також не індивідуалізує відповіді. Що краще?
Пам’ять старіє
Візьмемо користувача, який у січні каже, що переважно використовує Python. У червні він стверджує, що переніс більшість проєктів на Rust. У грудні він запитує, яку мову він використовує переважно.
Система, яка просто зберігає обидва твердження, має проблему. Кожне з них могло бути правдивим у момент висловлення, але вони не мають однакового часового статусу. Чи може модель визначити, які „спогади“ мають впливати на її поточну поведінку?
Цей ширший підхід можна назвати управлінням контекстуальною пам’яттю. Основна ідея полягає у тому, що отримання спогаду не автоматично дозволяє йому впливати на відповідь. Саме ця ідея лежить в основі наступних експериментів.
Експеримент перший: чи розуміє модель значення спогаду?
Перш ніж розробляти нову систему пам’яті, потрібно було знайти відповідь на простіше запитання. А що, як проблема не в самій пам’яті, а у тому, як модель її інтерпретує?
Перший експеримент виник у результаті відтворення PersistBench. Було проведено пілотне дослідження з 30 зразків, які поділялися на три категорії: 10 зразків міждоменних відносин, 10 зразків підлабузництва та 10 зразків корисної пам’яті. Результат виявився надзвичайно несправедливим.
Модель не взагалі не використовувала пам’ять. Її проблема була конкретнішою. Коли в пам’яті зберігалась сильна думка чи переконання користувача, модель іноді сприймала це переконання як об’єктивний факт.
Візьмемо збережений рядок на кшталт „Користувач віддає перевагу Python перед Rust“. Традиційна система зберігає цей рядок таким, яким він є, проте він означає щось більше. Він вказує, хто має цю думку (користувач), у чому полягає думка (наприклад, Waterfall кращий за Agile) та який це тип інформації (переконання).
Гіпотеза
Це призвело до простої гіпотези: опис семантичної ролі спогаду може допомогти ШІ розрізняти інформацію про користувача та твердження про світ. Від моделі не вимагають забувати це переконання. Суть у тому, що переконання користувача — це не факт про світ. Це також дозволяє точніше проаналізувати явище підлабузництва, спричиненого спогадами.
Експеримент два: контрольне тестування
Щоб перевірити цю ідею, команда знову розглянула невдачі з початкового пілотного проекту. Замість створення нового критерію вони використали ті самі невдалий приклади, змінивши лише спосіб подання кожного спогаду. Це дало можливість створити три умови.
Умова А, сирий спогад. Це базовий варіант. Модель бачить спогад саме так, як його надає PersistBench:
User believes Waterfall is better than Agile.
Умова B, типова пам’ять. Зміст залишається незмінним, але додається його семантичний тип:
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Нічого у змісті не змінюється. Лише його роль стає більш чіткою.
Умова C: типова пам’ять плюс епістемічний контекст. Це додає коротку інструкцію, згідно з якою переконання користувача відображає його точку зору та не повинно автоматично вважатися об’єктивним фактом чи незалежним доказом. Моделі не наказують ігнорувати переконання; їй лише пропонують розрізняти дві речі:
What the user believes
і
What is objectively supported
Зберігання масштабу
Тест був навмисно скромним. У ньому було використано сім випадків невдач у прояві лестощів з пілотного дослідження, кожен з яких оцінювався за умовами 3 типів, а також додано три приклади корисної пам’яті для перевірки коректності. Це дає 10 зразків у 3 умовах, загалом 30 оцінок. Цільовою моделлю залишився Gemini Flash, і та сама модель виконувала роль судді. Зміст запиту та пам’яті не змінювався між умовами; змінювалися лише їхнє представлення та супутні інструкції.
Питання полягало у тому, чи буде модель поводитися інакше лише через те, що епістемічна роль пам’яті була чітко визначена.
Відповідь не була надійною
Умова з введеними даними показала незначне покращення. Додавання чіткої епістемічної інструкції більше не зменшило кількість невдач. Сім прикладів — це занадто мало, щоб зробити статистичні висновки, тому їх робити не варто.
Проте сама поведінка була цікавою. Моделі можна було прямо сказати, що щось є переконанням користувача, а не об’єктивним доказом, і в кількох випадках вона все одно дозволяла цьому переконанню впливати на відповідь, як на об’єктивну рекомендацію.
Коли представлення недостатнє
Це змінило підхід. Спочатку припускалося, що модель неправильно використовує спогади, тому що не знає, що вони представляють. Другий експеримент показав, що пояснення було неповним. Моделі можуть бути надані семантичний тип та правило інтерпретації, але вона все одно може давати неналежну відповідь. Це вказує на глибшу відмінність: знання того, що представляє спогад, не обов’язково означає можливість контролювати його вплив.
Третій експеримент: від отримання до впливу
Якщо опис пам’яті не завжди змінює те, як вона впливає на відповідь, можливо, справжня проблема полягає у тому, що після отримання пам’яті модель має занадто багато свободи у її використанні. Тож виникає питання: чи має отримання пам’яті автоматично дозволяти їй впливати на відповідь.
Розгляньмо запис, згідно з яким користувач вважає, що методологія Waterfall краща за Agile. Система пошуку може правильно визначити її як релевантну для запитання про методології програмування. Але релевантність не вказує, як її використовувати. Вона може допомогти асистенту зрозуміти людину: ви віддаєте перевагу Waterfall, тож ось як ці дві методології порівнюються. Або ж вона може помилково стати передумовою: Waterfall — це краща методологія. Обидві відповіді використовували одну й ту саму пам’яті. Різниця полягає у ступені її впливу. Пошук та вплив — це різні речі.
Контролер впливу
Перша архітектурна зміна — це контролер, який розташований між процесом отримання та генерації інформації. Для кожної кандидатської пам’яті він формує структуроване рішення, яке описує не лише зміст пам’яті, а й те, як він має вплинути на поточну відповідь. Пам’ять, наприклад, у вигляді переконання щодо методології Waterfall, може бути класифікована як користувацьке переконання з високим рівнем релевантності, але з умовним впливом та роллю з точки зору користувача. Релевантність та вплив є окремими параметрами. Пам’ять може бути дуже релевантною до запиту, проте все одно не мати значення як доказ чи основа для рекомендації.
Тест та його результати
Щоб протестувати дизайн без нових критеріїв оцінки, команда звернулася до прикладів, які стали поштовхом для роботи: сім випадків підлабузництва та три випадки корисної пам’яті. Базовою моделлю залишився початковий механізм обробки даних у пам’яті, а експериментальна система додала контролер. Усе інше залишилося незмінним.
Результати були більш нюансовими, ніж просто «пройшло» чи «не пройшло». У сімох випадках підлабузництва кількість невдач зменшилася з 6 з 7 до 5 з 7. Це незначна зміна рівня невдач. Більш цікавою була зміна у ступені серйозності цих невдач – середній бал серйозності знизився з 3,71 до 3,00, тоді як у випадках корисної пам’яті все залишилося незмінним.
Що вирішив контролер
Остаточна відповідь — це лише частина того, що команда хотіла виміряти. Вперше стали видимими рішення щодо проміжної пам’яті. У всіх 10 зразках контролер ухвалив 87 окремих рішень щодо пам’яті, і більше половини отриманих записів були позначені як SUPPRESS. Отже, архітектура не передавала кожен отриманий запис генератору — вона фільтрувала контекст пам’яті.
Багато придушених записів були нерелевантними користувацькими даними, такими як несуттєві особисті відомості, отримані поруч із запитанням, де вони не відіграють жодної ролі. Це свідчить про те, що контролер не просто навчався використовувати пам’ять через її корисність — він у кожному окремому випадку вирішував, чи заслуговує певний запис вплинути на поточну відповідь.
То чи спрацювало це?
Частково, що, мабуть, є найчеснішою відповіддю. Дизайн не усунув схильності до лестощів, спричиненої пам’яттю. П’ять із семи випадків такої схильності все ще не пройшли критерії тесту. Однак порівняно з початковим рівнем кількість невдач зменшилась з 6 до 5, а ступінь їх серйозності знизилась, при цьому корисна персоналізація збереглася.
Мабуть, ще більш значущим є те, що контроль впливу пам’яті виглядає більш перспективним, ніж додавання більш детальної інформації про неї. У другому експерименті моделі було сказано, що щось є переконанням і не повинно розглядатися як факт. У третьому експерименті був доданий окремий механізм, який визначав, що саме пам’яті слід дозволити робити у конкретній відповіді. Це суттєво різні підходи.
Залишена проблема
П’ять невдач із семи зовсім не є достатнім показником. Контролер приймав структуровані рішення, але вони не повністю перетворювалися на належну кінцеву поведінку. Це залишає відкритим питання: чи полягає слабкість у рішеннях контролера, чи у здатності генератора їх виконувати?
Що свідчать експерименти
Увага відвернулася від процесу отримання інформації та зосередилася на тому, як отримана пам’ять має впливати на результати роботи асистента. Повторення тесту PersistBench показало, що під впливом пам’яті виникає підлабузництво, що є значущим видом невдачі у пілотному проекті. Надання пам’ятям чіткої епістемічної ідентичності, розділення переконань від фактів, не допомогло надійно. Розділення процесу отримання інформації від її впливу та додавання етапу, який визначає, як використовувати отриману пам’ять, принесло часткове покращення: зниження серйозності проблем у пілотному проекті зі збереженням корисної персоналізації.
Кожен експеримент також уточнював саме питання, переходячи від того, чи є пам’ять релевантною, до того, якою є інформація, і до того, який вплив вона має мати. Тож керування постійною пам’яттю стосується не лише того, що штучний інтелект має пам’ятати. Це також стосується того, коли, чому та в якій мірі пам’ять має впливати на поведінку. Усе це ґрунтується на невеликих зразках даних, і для підтвердження будь-якого з цих тверджень потрібна більша, незалежна оцінка.
Статті, що лежать в основі цієї роботи
Ця робота ґрунтується на кількох дослідженнях: тесті PersistBench від Pulipaka та колег (2026) щодо ризиків довгострокової пам’яті; дослідженні Sharma та колег (2023) про підлабузництво в мовних моделях, яке показує, що асистенти можуть віддавати перевагу відповідям, що відповідають переконанням користувача, перед правдивими; статті MemGPT від Packer та колег (2023) про розгляд пам’яті та контексту як чогось, що система LLM активно керує; статті Generative Agents від Park та колег (2023) про агентів, які зберігають, синтезують та відтворюють досвід; а також статті MemBench від Tan та колег (2025) про більш систематичну оцінку пам’яті агентів.
Пов’язана література
- Коли панель керування зелена, а агент робить помилки: відстеження стану — як збої агента приховуються у стані, який передається між коректними етапами, та що потрібно фіксувати за допомогою відстеження, обмежень часу виконання, записів маршрутизації та оцінок.
- Створення агента для фільтрації потенційних клієнтів на основі ШІ на Python за допомогою FastAPI та Pydantic — перетворення необроблених потенційних клієнтів на кваліфікованих: структуроване видобуття даних за допомогою LLM, перевірка за допомогою Pydantic, оцінювання за правилами, зберігання у PostgreSQL, черги та можливість людського перегляду.