تصور کنید یک دستیار هوشمند دارید که هر بار با او صحبت می‌کنید، انگار اولین بار است شما را می‌بیند یا بدتر از آن، جزئیاتی را به یاد می‌آورد که سال‌ها پیش تغییر کرده‌اند. VoltMem با شکستن چرخه یادگیری صرفاً در زمان گفتگو، قصد دارد این تجربه ناقص را به کلی تغییر دهد. در حالی که اکثر عامل‌های هوش مصنوعی تنها زمانی یاد می‌گیرند که کاربر در حال صحبت است — درست مانند انسانی که فقط وقتی کسی دیگر حرف می‌زند فکر می‌کند — VoltMem این چرخه را می‌شکند.
این پروژه با پیاده‌سازی یک «پنجره نگهداری» (Maintenance Window) بر اساس اصل محاسبات زمان خواب (Sleep-time Compute)، در حال حل محدودیت بنیادی یادگیری در لحظه (Real-time Learning) است. این لایه حافظه تخصصی برای مدل‌های زبانی بزرگ (LLM) اجازه می‌دهد عامل‌ها در زمان‌های بیکاری، اطلاعات را تثبیت کنند. بسیاری از عامل‌های فعلی دارای حافظه کاری (Working Memory) عالی هستند اما فاقد یک حلقه نگهداری بلندمدت‌اند. آن‌ها در واقع بین جلسات گفتگو «خاموش» هستند، به این معنی که نمی‌توانند اطلاعات را تلفیق کنند یا متوجه تضادهایی شوند که به‌کندی در طول زمان ظاهر می‌شوند. این رویکرد یادآوری‌کننده سیستم «رؤیاپردازی» Olund است که برای جلوگیری از آلودگی حافظه از طریق تثبیت شبانه استفاده می‌کند.
این وضعیت تضادی میان «پایداری» (Stability) — یعنی قفل کردن ترجیحات اصلی — و «انعطاف‌پذیری» (Plasticity) — یعنی به‌روزرسانی حقایقی مانند شهر فعلی کاربر — ایجاد می‌کند. این موضوع در «معمای برلین به پاریس» به بهترین شکل توصیف شده است: یک عامل می‌داند شما در برلین زندگی می‌کنید. شما به پاریس نقل مکان می‌کنید. سه ماه بعد، عامل هنوز درباره آب‌وهوای برلین می‌پرسد. در مقابل، یک ترجیح پایدار برای پاسخ‌های کوتاه که سال‌هاست وجود دارد، ممکن است به دلیل یک نظر گذرا بازنویسی شود، زیرا سیستم با تمام حقایق به یک اندازه برخورد می‌کند و همه را به یک میزان ناپایدار می‌بیند. VoltMem برای حل این مشکل ساخته شده است تا «پیش‌فرض‌های ناپایداری» (Volatility Priors) را بر اساس دامنه تخصیص دهد: ویژگی‌های شخصیتی قفل می‌شوند، مکان‌ها آزادانه به‌روزرسانی می‌شوند و وظایف جاری به‌سرعت محو می‌گردند.
بر اساس معماری پیشنهادی Letta، توسعه‌دهنده VoltMem دریافت که به‌روزرسانی‌های حافظه در لحظه اغلب بسیار گران یا بسیار محدود هستند و نمی‌توانند تغییرات پیچیده زندگی انسان را مدیریت کنند. مستندات پروژه فاش کرد که تکیه صرف بر منطق «زمان نوشتن» (Write-time logic) منجر به ایجاد عامل‌های شکننده‌ای می‌شود که یا خیلی سریع فراموش می‌کنند یا از به‌روزرسانی حقایق پایدار سر باز می‌زنند. این چالش‌ها در واقع همان نقاط ضعفی هستند که مکانیزم «لایه نشانی اصلاحات» سعی دارد با تثبیت خطاهای تکراری در عامل‌های AI برطرف کند.
چهار گره کور در معماری حافظه
پیش از روی آوردن به رویکرد زمان خواب، VoltMem با چهار چالش ساختاری خاص دست‌وپنجه نرم می‌کرد که در فایل docs/OPEN_PROBLEMS.md ردیابی شده بود:
- شکنندگی طبقه‌بندی (Classification Brittleness): برچسب‌گذاری حقایق در زمان نوشتن، یک تصمیم تخمینی است. اگر حقیقتی در لحظه ورود اشتباه برچسب بخورد (مثلاً جمله «امروز عالی هستم» به جای
emotional_contextبا برچسبcore_preferenceثبت شود)، پیش‌فرض ناپایداری اشتباه خواهد بود و هر تعامل بعدی مسموم می‌شود. - شکاف سیگنال و نویز (The Noise vs. Signal Gap): سیستم‌هایی که برای رد کردن نظرات گذرا و «نویزی» طراحی شده‌اند، اغلب به‌طور تصادفی تغییرات مشروع را نیز مسدود می‌کنند. محافظت در برابر نویز، به‌روزرسانی‌هایی را که به‌کندی و از طریق مشاهدات متعدد شکل می‌گیرند، متوقف می‌کند.
- بازیابی ناقص (Under-specified Retrieval): وقتی پرسش‌های کاربر مبهم هستند (مثلاً «داشتم روی چه چیزی کار می‌کردم؟»)، امتیازهای شباهت (Similarity Scores) تخت می‌شوند. در این موارد، بازرتب‌بندی بر اساس ناپایداری ممکن است در واقع گزینه اشتباهی را انتخاب کند. برای درک بهتر این چالش‌ها، می‌توان معماری RAG را بررسی کرد که از جست‌وجوی برداری برای حذف توهمات در مدل‌های زبانی استفاده می‌کند.
- رویدادهای چندوجهی (Multi-facet Events): مشاهدات واقعی در هر لحظه چندین سیگنال را با هم منتقل می‌کنند — مانند مکان، وظیفه و حالت احساسی. اکثر سیستم‌ها، از جمله نسخه فعلی VoltMem، فرض می‌کنند که هر حقیقت برابر با یک دامنه است.
مفهوم محاسبات زمان خواب
برای حل این گره‌ها، VoltMem به تحقیقات Letta درباره محاسبات زمان خواب نگاه کرد. این یک طراحی دو-عاملی است که در آن یک عامل اصلی در گفتگو پاسخگو باقی می‌ماند، در حالی که یک عامل مجزای «زمان خواب» به‌صورت ناهمگام (Asynchronous) اجرا می‌شود.
این عامل پس‌زمینه حقایق جدید اختراع نمی‌کند، بلکه از چرخه‌های بیکاری برای موارد زیر استفاده می‌کند:
- پردازش و تقطیر رویدادهای جلسات فعال.
- ادغام خاطرات جدید با خاطرات موجود.
- شناسایی تضادهایی که در لحظه به دلیل محدود بودن شناخت فعال، نامرئی بودند.
- ساخت ساختارهای تداعی‌گر (Associative Structures) که تنها از طریق فاصله و شناسایی الگوها ظاهر می‌شوند.
این فرآیند شبیه به «افکار دوش» یا پریشانی‌های شبانه انسان است؛ لحظاتی که مغز تکه‌های نیمه‌تمام فکر را با الگوهای قدیمی تطبیق می‌دهد. این استراحت نیست، بلکه تعمیر و نگهداری روی ایندکس حافظه است.
پیاده‌سازی پنجره نگهداری
سیستم VoltMem از حالت واکنشی خالص فاصله گرفته است. به‌جای اینکه فقط هنگام رسیدن شواهد جدید آستانه‌ها را بررسی کند، از چرخه‌های بیکاری برای اجرای ممیزی‌های پس‌زمینه استفاده می‌کند.
حل شکاف سیگنال در برابر نویز: برای مشکل «سیگنال در برابر نویز»، پنجره نگهداری تاریخچه کامل logged_mismatch را بررسی می‌کند. تضاد اصلی در ریاضیات ارتقای VoltMem، اجتناب از فساد ناشی از نویز و در عین حال عدم چشم‌پوشی از تغییرات واقعی است. در حال حاضر، سیستم در زمان نوشتن بررسی می‌کند که آیا $E_t > \theta_t$ است تا یک ممیزی را فعال کند.
با این حال، برخی تغییرات به صورت الگوهایی در چندین مشاهده ضعیف ظاهر می‌شوند. اگر کاربر در طول دو هفته چهار بار به‌طور گذرا به «شغل جدید» اشاره کند، هیچ‌یک از این اشاره‌ها به‌تنهایی ممکن است از آستانه عبور نکند. ریاضیات ارتقا که برای رد نویز کالیبره شده، سیگنال را از دست می‌دهد. پنجره نگهداری با تحلیل آفلاین عدم‌تطابق‌های ثبت‌شده، این الگو را شناسایی کرده و پیش از شروع جلسه بعدی، به‌طور فعال ممیزی تغییر شغل را اجرا می‌کند.
رفع شکنندگی طبقه‌بندی: در مورد طبقه‌بندی، حلقه نگهداری یک مرحله اصلاحی اضافه می‌کند. در زمان نوشتن، VoltMem دامنه‌ها را از طریق اکتشافات کلیدواژه‌ای یا یک LLM محلی تخصیص می‌دهد. حلقه نگهداری به سیستم اجازه می‌دهد تا حقایق مبهم را با استفاده از کل تاریخچه گفتگو، به‌جای تکه‌ای که در زمان نوشتن در دسترس بود، بازطبقه‌بندی کند.
سیستم می‌تواند یک ممیزی شبانه انجام دهد و بپرسد: «این ۴۷ حقیقت با برچسب core_preference ثبت شده‌اند، اما تنها ۳ مورد ممیزی شده‌اند، در حالی که ۱۲ مورد چندین بار نقض شده‌اند. آیا برخی از آن‌ها در واقع emotional_context یا current_task هستند؟»
مدیریت رویدادهای چندوجهی: برای رویدادهای چندوجهی، پنجره نگهداری توازن میان سرعت و عمق را جدا می‌کند. جمله‌ای مانند «خسته‌ام اما با آپارتمان جدیدم به باشگاه می‌روم» حاوی حالت احساسی، وظیفه فعلی و مکان است. پردازش این جمله به چندین وجه در زمان نوشتن، گران و مستعد خطا است.
در طول جلسات فعال، سیستم ذخیره‌سازی سریع و ساده انجام می‌دهد. در ساعات بیکاری، این گفته‌ها را دوباره تجزیه کرده و آن‌ها را به وجه‌های مرتبط تحت یک event_id مشترک تبدیل می‌کند و برای هر وجه، ناپایداری مجزایی تخصیص می‌دهد. این کار API مربوط به add_event() چندوجهی را که در مستندات مشکلات باز پیشنهاد شده بود، به‌صورت ناهمگام پیاده می‌کند تا مسیر نوشتن مسدود نشود.
برتری در بازیابی
اگرچه ارتباط این موضوع با بازیابی ضعیف‌تر است، اما ادغام پس‌زمینه با ساختن ساختارهای تداعی‌گر کمک می‌کند. وقتی پرسش‌ها مبهم هستند، شباهت خام اغلب بی‌فایده است.
با تشخیص اینکه «مهاجرت دیتابیس» در ۸۰٪ مواقع با «پروژه فعلی» هم‌آیند است، یا اینکه خاطرات وظایف خاصی حول مراحل خاص پروژه خوشه‌بندی می‌شوند، سیستم پیوندهای غنی‌تری ایجاد می‌کند. این یک مسیر جایگزین برای سیستم بازیابی فراهم می‌کند تا زمانی که مسیر مستقیم مبهم است، از آن پیروی کند.
نقشه راه جدید برای حافظه عامل‌ها
این چرخش، ادعای بنیادی محصول را تغییر می‌دهد. دیگر بحث فقط بر سر اکتشافات بهتر برای حافظه نیست؛ بلکه درباره ایجاد یک سطح نگهداری صریح برای عملیاتی است که برای مسیر «داغ» (Hot Path) یک گفتگو، بیش از حد گمانه‌زن، گران یا سنگین هستند.
چرخه بعدی VoltMem این موضوع را با عرضه یک API فعال‌ساز — شامل event_id، رویدادهای چندوجهی و TTL اختیاری — و ایجاد یک «اجراکننده نگهداری» (Maintenance Runner) عملیاتی می‌کند. این اجراکننده موارد زیر را مدیریت خواهد کرد:
- ممیزی الگوها در عدم‌تطابق‌های ثبت‌شده.
- بازطبقه‌بندی موارد مبهم.
- پاک‌سازی داده‌های منقضی شده.
این یک معماری کامل عامل زمان خواب نیست، بلکه یک پنجره نگهداری قابل حمل است که لایه حافظه می‌تواند مالک آن باشد. این رویکرد اذعان می‌کند عاملی که تنها در حضور کاربر یاد می‌گیرد، اساساً محدود است.
این حرکت معماری نشان می‌دهد که آینده حافظه عامل‌محور تنها در پنجره‌های متنی بزرگ‌تر یا پایگاه‌داده‌های برداری بهتر نیست، بلکه در «ساعات سکوت» است که ادغام رخ می‌دهد. بدون این، عامل‌ها بین سخت‌گیر بودن (شکنندگی) و بیش از حد انعطاف‌پذیر بودن (فساد داده) گیر خواهند کرد.
توسعه‌دهندگانی که حافظه پایدار برای عامل‌ها می‌سازند، اکنون باید بررسی کنند که آیا سیستم‌هایشان حلقه نگهداری بلندمدت دارند یا خیر. هدف، حرکت از یک لایه حافظه واکنشی به لایه‌ای است که بتواند ساعت‌ها تنها بماند و یکپارکه‌تر از قبل بازگردد.
گام بعدی شما
- اگر در حال توسعه عامل‌های دارای حافظه هستید، بررسی کنید که آیا سیستمتان حلقه‌ای برای بازبینی ناهمگام داده‌ها دارد یا خیر.
- معماری Letta را برای پیاده‌سازی تفکیک بین عامل پاسخگو و عامل تحلیل‌گر مطالعه کنید.
- برای کاهش هزینه استنتاج، پردازش‌های سنگین استخراج ویژگی را از مسیر اصلی گفتگو به یک Job پس‌زمینه منتقل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو