MemGPT: مدیریت فضای متنی مجازی برای عامل‌های مدل زبانی بزرگ (LLM)

محدودیتی که اکثر عامل‌های مدل زبانی بزرگ (LLM) را با چالش مواجه می‌کند، هوش نیست — بلکه حافظه است. من به طور مشخص در مورد دفترهای روزنامه Beancount فکر می‌کنم که تراکنش‌های چندین سال را در بر می‌گیرند: مهم نیست که مدل زیربنایی چقدر توانمند باشد، به محض اینکه تاریخچه دفتر از پنجره متن (context window) فراتر برود، عامل شروع به فراموشی می‌کند. MemGPT (پکر و همکاران، دانشگاه برکلی، ۲۰۲۳) با استفاده از راهکاری که سیستم‌عامل‌ها دهه‌ها پیش آن را حل کرده‌اند، مستقیماً به این مشکل می‌پردازد.

مقاله

مقاله «MemGPT: به سوی مدل‌های زبانی بزرگ به عنوان سیستم‌عامل» (Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez; arXiv:2310.08560) موضوع مدیریت فضای متنی مجازی را پیشنهاد می‌دهد — که تشبیهی آگاهانه به نحوه ایجاد توهم حافظه مجازی بزرگ در سیستم‌عامل‌ها از طریق صفحه‌بندی بین رم (RAM) سریع و دیسک کند است. پنجره متن LLM نقش رم را ایفا می‌کند: کمیاب، سریع و مستقیماً قابل دسترسی. دو منبع ذخیره‌سازی خارجی نقش دیسک را دارند: یک ذخیره‌ساز بازخوانی (تاریخچه پیام‌های اخیر) و یک ذخیره‌ساز آرشیوی (یک پایگاه داده بلندمدت قابل جستجو برای متون دلخواه). خودِ عامل تصمیم می‌گیرد چه چیزی را از ذخیره‌ساز خارجی بخواند و چه چیزی را از فضای متن خارج (evict) کند. این کار با استفاده از فراخوانی صریح توابع — ابزارهایی که داده‌ها را بین لایه‌ها جابجا می‌کنند — انجام می‌شود. سیستم در ظرفیت ۷۰ درصدِ فضای متن، هشدار خروج صادر می‌کند و در ۱۰۰ درصد، عملیات تخلیه (flush) را اجباری می‌کند و یک خلاصه بازگشتی از پیام‌های حذف شده ایجاد می‌کند تا از دست رفتن کامل اطلاعات جلوگیری شود.

این مقاله MemGPT را در دو حوزه ارزیابی می‌کند: عامل‌های گفتگو در چندین جلسه (مجموعه داده Multi-Session Chat) و تحلیل اسناد در مجموعه‌های بزرگی که از پنجره متن بومی مدل فراتر می‌روند.

ایده‌های کلیدی

• سه لایه حافظه: حافظه کاری درون-متنی (سریع، محدود)، ذخیره‌ساز بازخوانی (پیام‌های اخیر، قابل جستجو) و ذخیره‌ساز آرشیوی (بلندمدت، نمایه‌گذاری شده). عامل از طریق فراخوانی ابزارها در هر سه لایه می‌نویسد.
• بازیابی عمیق حافظه (DMR): وظیفه ارزیابی که نیازمند یادآوری مداوم در چندین جلسه گذشته است. با GPT-4، خط پایه استاندارد با فضای متنی ثابت به دقت ۳۲.۱٪ می‌رسد؛ MemGPT آن را به ۹۲.۵٪ می‌رساند. خط پایه GPT-4 Turbo: از ۳۵.۳٪ به ۹۳.۴٪.
• بازیابی کلید-مقدار تودرتو: تست استرس تحلیل اسناد. GPT-4 استاندارد در سه سطح تودرتویی به دقت ۰٪ می‌رسد؛ MemGPT با GPT-4 با انجام جستجوهای آرشیوی تکرار شونده، عملکرد خود را حفظ می‌کند.
• جریان کنترل از طریق وقفه (Interrupt): عامل زمانی که برای انجام عملیات حافظه قبل از پاسخگویی به زمان بیشتری نیاز دارد، سیگنال می‌دهد، مشابه با وقفه در سیستم‌عامل. این کار سیستم را پاسخگو نگه می‌دارد بدون اینکه مجبور باشد همه چیز را در یک مرحله استنتاج انجام دهد.
• مشکل تخلیه (Eviction): وقتی فضای متن پر می‌شود، محتوا خلاصه‌سازی و تخلیه می‌شود. خلاصه بازگشتی اصل مطلب را حفظ می‌کند اما به ناچار جزئیات را از دست می‌دهد — موازنه‌ای که مقاله به آن اذعان دارد اما به طور کامل آن را کمی‌سازی نمی‌کند.

چه چیزی تداوم دارد — و چه چیزی نه

اعداد DMR خیره‌کننده هستند: فاصله دقتی ۶۰ امتیازی بین MemGPT و خط پایه استاندارد GPT-4 در مجموعه داده Multi-Session Chat اتفاقی نیست. نتیجه کلید-مقدار تودرتو — که در آن خط پایه‌ها در ۰٪ شکست می‌خورند در حالی که MemGPT به کار خود ادامه می‌دهد — نشان‌دهنده ارزش واقعی بازیابی تکرار شونده و مبتنی بر ابزار در مقابل مواجهه غیرفعال با فضای متنی طولانی است. این موضوع با یافته «گم‌شده در میان» (Lost in the Middle) لیو و همکاران (arXiv:2307.03172) مرتبط است: حتی زمانی که اطلاعات به طور فیزیکی در پنجره متن جا می‌شود، مدل‌ها برای محتوایی که در میانه‌های متن دفن شده است، دچار افت عملکرد می‌شوند. MemGPT با بازیابی تنها آنچه بلافاصله مورد نیاز است، از این مشکل عبور می‌کند.

با این حال، ارزیابی حفره‌های واقعی دارد. مجموعه داده Multi-Session Chat محدود است — چت‌های شخصیت‌محور تولید شده توسط انسان با فرمت‌های کاملاً کنترل شده. اینکه این رویکرد چگونه با گفتگوهای واقعی و آشفته یا مجموعه‌ داده‌های خاصِ دامنه (گزارش‌های مالی، مکاتبات نظارتی) مقیاس‌پذیر است، آزمایش نشده است. ذخیره‌ساز آرشیوی در آزمایش‌ها یک پایگاه داده برداری ساده است؛ اینکه آیا کیفیت بازیابی با رشد آرشیو به میلیون‌ها سند همچنان بالا می‌ماند یا خیر، بی‌پاسخ مانده است. بنیادی‌تر از آن: استراتژی بازیابی عامل فقط به اندازه پرس‌وجوهای (queries) آن خوب است. اگر عامل نداند چه چیزی را نمی‌داند — که یک حالت شکست رایج در وظایف طولانی‌مدت است — هرگز جستجوی آرشیوی درستی انجام نخواهد داد و کل معماری به همان حالت شکست در فضای متنی ثابت سقوط می‌کند.

همچنین هزینه تأخیر (latency) وجود دارد که مقاله به سادگی از کنار آن می‌گذرد. هر جستجوی آرشیوی یک فراخوانی استنتاج LLM اضافی (برای ایجاد پرس‌وجو) به علاوه یک جستجوی برداری است. برای یک عامل Beancount که در حال انجام عملیات تطبیق روتین روی داده‌های چندین سال است، این می‌تواند منجر به چندین رفت و برگشت به ازای هر پاسخ شود. مقاله مقایسه‌ای از تأخیر زمانی واقعی گزارش نمی‌کند.

کارهای بعدی این نقدها را تندتر کرده‌اند. A-MEM (arXiv:2502.12110) ادعا می‌کند در وظایف چندمرحله‌ای حداقل ۲ برابر عملکرد بهتر از MemGPT دارد و استدلال می‌کند که ساختار لایه‌ای صلب MemGPT نسبت به سازماندهی پویای حافظه عملکرد ضعیف‌تری دارد. بنچمارک‌های Mem0 (۲۰۲۴-۲۰۲۵) نشان می‌دهند که رویکردهای رقیب در برخی تنظیمات از نظر دقت و سرعت از MemGPT پیشی می‌گیرند. نویسندگان اصلی از آن زمان پروژه را به Letta (سپتامبر ۲۰۲۴) تغییر داده‌اند، یک چارچوب عامل متن‌باز با «محاسبات زمان خواب» (sleep-time compute) ناهمگام برای تثبیت حافظه — که اعترافی ضمنی به این است که طراحی تک‌عاملی و همگام دارای محدودیت‌های مقیاس‌پذیری است.

چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد

یک دفتر روزنامه Beancount برای یک کسب‌وکار کوچک، ده‌ها هزار تراکنش را طی یک دهه جمع‌آوری می‌کند. عاملی که وظیفه تطبیق پایان سال، بررسی ناهنجاری‌ها یا تحلیل روندهای چندساله را بر عهده دارد، نمی‌تواند همه چیز را در فضای متن جای دهد. طراحی سه‌لایه MemGPT تقریباً مستقیماً با این نیاز منطبق است: حافظه کاری، دسته تراکنش‌های فعلی تحت بررسی را نگه می‌دارد؛ ذخیره‌ساز بازخوانی، فضای متنی جلسات اخیر را نگه می‌دارد (آنچه دفعه قبل در حال تطبیق بودیم)؛ ذخیره‌ساز آرشیوی، کل تاریخچه دفتر، ثبت‌های روزنامه و گزارش‌های ناهنجاری قبلی را در خود جای می‌دهد. رابط فراخوانی تابع برای عملیات حافظه اساساً همان رابطی است که عامل از قبل برای عملیات ثبت (write-back) به آن نیاز دارد — این یک کلاس قابلیت جدید نیست، بلکه کاربرد جدیدی از همان مکانیزم فراخوانی ابزار است.

ارتباط عمیق‌تر در تغییر چارچوب ذهنی است: به جای اینکه بپرسیم «آیا می‌توانیم حجم بیشتری را در فضای متن جا دهیم؟»، MemGPT می‌پرسد «آیا عامل می‌تواند توجه (attention) خود را مدیریت کند؟». برای امور مالی، این سوال درست است. یک ممیزی مالیاتی ممکن است سوالی درباره تراکنشی از سه سال پیش ایجاد کند. یک حسابدار انسانی ماهر، فاکتور اصلی را بازیابی می‌کند، آن را با دفتر روزنامه مطابقت می‌دهد و زمینه خط‌مشی آن سال را به یاد می‌آورد. این رفتار بازیابی در صورت نیاز (retrieval-on-demand) دقیقاً همان چیزی است که 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) — پیگیری‌ای در سال ۲۰۲۵ که با جایگزینی ساختار لایه‌ای صلب MemGPT با سازماندهی پویای حافظه، ادعای عملکرد برتر در حافظه چندمرحله‌ای را دارد؛ یک نقطه مقایسه ضروری.
• Gorilla: Large Language Model Connected with Massive APIs (arXiv:2305.15334) — مورد بعدی در این لیست مطالعه؛ طراحی فراخوانی ابزار تقویت‌شده با بازیابی در آنجا، مدیریت حافظه MemGPT را با پرداختن به نحوه انتخاب ابزار مناسب توسط عامل‌ها از یک سطح بزرگ API تکمیل می‌کند.