MemGPT: Віртуальне керування контекстом для агентів LLM

Обмеженням, яке стримує більшість агентів LLM, є не інтелект, а пам'ять. Я міркував про це конкретно в контексті гросбухів Beancount, що охоплюють роки транзакцій: незалежно від можливостей базової моделі, щойно історія гросбуха перевищує вікно контексту, агент починає забувати. MemGPT (Packer et al., UC Berkeley, 2023) атакує цю проблему безпосередньо, запозичуючи рішення, яке операційні системи знайшли десятиліття тому.

Стаття

«MemGPT: Towards LLMs as Operating Systems» (Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez; arXiv:2310.08560) пропонує віртуальне керування контекстом — свідому аналогію до того, як ОС створюють ілюзію великої віртуальної пам'яті шляхом підкачування (paging) між швидкою ОЗП та повільним диском. Вікно контексту LLM відіграє роль ОЗП: дефіцитне, швидке, безпосередньо доступне. Два зовнішніх сховища виконують роль диска: сховище відтворення (recent message history) та архівне сховище (пошукова довгострокова база даних для довільного тексту). Сам агент вирішує, що зчитувати із зовнішнього сховища і що витісняти з контексту, використовуючи явні виклики функцій — інструменти, які переміщують дані між рівнями. Система ініціює попередження про витіснення при 70% заповнення контексту та примусово очищує його при 100%, генеруючи рекурсивне резюме витіснених повідомлень, щоб уникнути повної втрати інформації.

У статті MemGPT оцінюється у двох доменах: багатосесійні розмовні агенти (набір даних Multi-Session Chat) та аналіз документів у великих корпусах, що перевищують нативне вікно контексту моделі.

Ключові ідеї

• Три рівні пам'яті: робоча пам'ять у контексті (швидка, обмежена), сховище відтворення (нещодавні повідомлення, доступні для пошуку) та архівне сховище (довгострокове, індексоване). Агент записує в усі три рівні через виклики інструментів.
• Глибоке відтворення пам'яті (Deep Memory Retrieval, DMR): завдання оцінки, яке вимагає послідовного відтворення інформації з багатьох минулих сесій. З GPT-4 стандартна базова лінія з фіксованим контекстом досягає 32,1% точності; MemGPT підвищує її до 92,5%. Базова лінія GPT-4 Turbo: 35,3% → 93,4%.
• Вкладений пошук «ключ-значення»: стрес-тест аналізу документів. Стандартна GPT-4 демонструє 0% точності на трьох рівнях вкладеності; MemGPT з GPT-4 підтримує продуктивність, здійснюючи ітеративні пошуки в архіві.
• Управління потоком через переривання: агент подає сигнал, коли йому потрібно більше часу (для виконання операцій з пам'яттю) перед відповіддю, що аналогічно перериванню в ОС. Це дозволяє системі залишатися чуйною, не змушуючи втискати все в один прохід виводу.
• Проблема витіснення (eviction): коли контекст заповнений, вміст резюмується та витісняється. Рекурсивне резюмування зберігає суть, але неминуче втрачає деталі — компроміс, який автори визнають, але не оцінюють кількісно повною мірою.

Що витримує критику, а що — ні

Показники DMR вражають: 60-відсотковий розрив у точності між MemGPT та стандартною базовою лінією GPT-4 на наборі даних Multi-Session Chat — це не просто випадковість. Результат із вкладеними KV (ключ-значення) — де базові лінії показують 0%, тоді як MemGPT продовжує працювати — демонструє реальну цінність ітеративного, опосередкованого інструментами пошуку порівняно з пасивним довгим контекстом. Це перегукується з висновком Лю та ін. «Загублені посередині» (Lost in the Middle, arXiv:2307.03172): навіть коли інформація фізично вміщується у вікно контексту, моделі працюють гірше з контентом, що знаходиться в середині. MemGPT обходить це, вилучаючи лише те, що потрібно безпосередньо зараз.

З іншого боку, оцінка має суттєві прогалини. Набір даних Multi-Session Chat досить вузький — це згенеровані людиною чати персонажів із жорстко контрольованими форматами. Як цей підхід масштабується на більш хаотичні реальні розмови або специфічні для певних галузей корпуси (фінансові звіти, регуляторна кореспонденція), залишається неперевіреним. Архівне сховище в експериментах — це проста векторна база даних; чи залишиться якість пошуку високою, коли архів розростеться до мільйонів документів, невідомо. Що більш фундаментально: стратегія пошуку агента настільки ж хороша, як і його запити. Якщо агент не знає, чого він не знає (поширений сценарій у довготривалих завданнях), він ніколи не зробить правильний запит до архіву, і вся архітектура вийде з ладу так само, як і варіант із фіксованим контекстом.

Також існує затримка (latency), до якої стаття ставиться легковажно. Кожен пошук в архіві — це додатковий виклик LLM (для генерації запиту) плюс векторний пошук. Для агента Beancount, що виконує рутинне звіряння за роки даних, це може перетворитися на багато ітерацій на одну відповідь. У статті не наводяться порівняння реального часу виконання.

Подальші роботи загострили цю критику. A-MEM (arXiv:2502.12110) заявляє про щонайменше вдвічі кращу продуктивність, ніж у MemGPT, у завданнях з кількома кроками (multi-hop), стверджуючи, що жорстка трирівнева структура MemGPT поступається більш динамічному куруванню пам'яті. Тести Mem0 (2024-2025) показують, що конкуруючі підходи перевершують MemGPT за точністю та швидкістю в деяких сценаріях. Оригінальні автори з того часу розвинули проект у Letta (вересень 2024), фреймворк агентів із відкритим кодом з асинхронними «обчисленнями під час сну» для консолідації пам'яті — непряме визнання того, що синхронний дизайн з одним агентом має межі масштабування.

Чому це важливо для фінансового ШІ

Гросбух Beancount для малого бізнесу накопичує десятки тисяч транзакцій протягом десятиліття. Агент, якому доручено річне звіряння, дослідження аномалій або аналіз багаторічних трендів, не може вмістити все в контекст. Трирівнева конструкція MemGPT відображається майже безпосередньо: робоча пам'ять містить поточну групу транзакцій, що перевіряються; сховище відтворення містить контекст нещодавніх сесій (що ми звіряли минулого разу); архівне сховище містить повну історію гросбуха, записи в журналі та попередні звіти про аномалії. Інтерфейс виклику функцій для операцій з пам'яттю — це, по суті, той самий інтерфейс, який уже потрібен агенту для операцій запису — це не новий клас можливостей, а нове застосування того самого механізму виклику інструментів.

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

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

Що читати далі

• Lost in the Middle: How Language Models Use Long Contexts (Liu et al., arXiv:2307.03172) — емпірична база того, чому самі по собі довші вікна контексту не вирішують проблему; моделі не можуть приділити увагу контенту в середині документа, що спонукає до підходів на основі пошуку, таких як MemGPT.
• A-MEM: Agentic Memory for LLM Agents (arXiv:2502.12110) — подальше дослідження 2025 року, що заявляє про кращу продуктивність багатокрокової пам'яті шляхом заміни жорсткої структури MemGPT на динамічне курування; необхідна точка порівняння.
• Gorilla: Large Language Model Connected with Massive APIs (arXiv:2305.15334) — наступний у цьому списку; дизайн виклику інструментів з доповненням пошуком там доповнює керування пам'яттю MemGPT, вирішуючи, як агенти вибирають правильний інструмент із великого набору API.