تصور کنید وارد دنیای یک بازی می‌شوید و شخصیتی که هفته‌ها پیش با او پیمانی بسته‌اید، شما را مانند یک غریبه تحسین می‌کند؛ این لحظه، تمام جادوی غوطه‌وری در بازی را می‌شکند. در حالی که شخصیتی که با بازگشت بازیکن او را به عنوان یک غریبه greeting می‌کند صرفاً یک دموی فنی است، یک شخصیت واقعی باید به یاد بیاورد. برای حل این مشکل «فراموشی» در شخصیت‌های غیرقابل‌بازی (NPC) که توسط هوش مصنوعی زاینده (Generative AI) هدایت می‌شوند، یک راهنمای فنی در ۵ اکتبر ۲۰۲۶ در وب‌سایت dev.to معماری حافظهٔ سه‌لایه را معرفی کرد. این رویکرد در راستای تلاش‌های گسترده‌تر برای حل مشکل فراموشی در عامل‌هاست، مشابه آنچه در راهکار لایهٔ تصویرسازی Baize برای درمان فراموشی عامل‌های هوش مصنوعی بررسی شده بود.
حفظ وضعیت در عامل‌های هوش مصنوعی چالشی همیشگی است؛ درست شبیه به «مشکل دوست» در بازبینی کدهای خصوصی که پیش‌تر بررسی کردیم. در حالی که بیشتر توسعه‌دهندگان به یک پرامپت طولانی تکیه می‌کنند، چالش واقعی مدیریت بودجهٔ سخت‌گیرانهٔ توکن (Token) — مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — است تا شخصیت بدون افزایش هزینه‌های استنتاج (Inference) تداوم داشته باشد. در همین راستا، استفاده از لایه‌های خلاصه‌ساز برای کاهش هزینه‌های API می‌تواند بهینه‌سازی مصرف توکن‌ها را در سیستم‌های پیچیده تسهیل کند.
طبق گزارش dev.to، یک خط لولهٔ قدرتمند برای NPC به چهار ماژول مجزا نیاز دارد: سازندهٔ زمینه (Context Builder)، رابط مدل زبانی (LLM Interface)، تجزیه‌کنندهٔ پاسخ (Response Parser) و مدیریت حافظه (Memory Manager). مدیر حافظه در اینجا نقش دروازه‌بان را دارد و تنها چند صد توکن از مرتبط‌ترین تاریخچه را به سازندهٔ زمینه تحویل می‌دهد.
پشتهٔ حافظهٔ سه‌لایه
- لایه اول: بافر گفتگو. این لایه جریان فوری را با استفاده از ۱۰ تا ۲۰ جفت پیام مدیریت می‌کند. برای جلوگیری از قطع ناگهانی حافظه، سیستم پیام‌های اضافی و سرریز شده را به یک خلاصهٔ دو تا سه جمله‌ای در ابتدای تاریخچه تبدیل می‌کند.
- لایه دوم: بازیابی برداری. حافظهٔ بلندمدت در پایگاه‌داده‌های برداری (Vector Database) — مثل کتابخانه‌ای که هر کتاب را بر اساس موضوع در جای دقیقش می‌گذارد — مانند ChromaDB، Pinecone، Qdrant یا Weaviate ذخیره می‌شود. سیستم خلاصه‌های جلسه را به بردار معنایی (Embedding) تبدیل کرده و ۲ تا ۴ خاطره را بر اساس یک امتیاز شباهت حداقلی بازیابی می‌کند تا از گیج شدن شخصیت با داده‌های نامرتبط جلوگیری شود. این تفکیک بین حافظهٔ کوتاه‌مدت و بلندمدت، یادآور معماری حافظهٔ SupportMind است که با جداسازی یادآوری از پنجرهٔ متنی از نشت اطلاعات جلوگیری می‌کند.
- لایه سوم: حقایق ساختاریافته. داده‌های حیاتی — مانند نام بازیکن یا قول‌های خاص — در قالب رکوردهای برچسب‌دار استخراج می‌شوند. این اطلاعات در هر بار اجرا، بدون توجه به موضوع فعلی، بارگذاری می‌شوند تا NPC هرگز نقاط کلیدی داستان را فراموش نکند.
این معماری تمرکز را از اندازهٔ مدل به مدیریت حافظه تغییر می‌دهد. یک مدل زبانی کوچک (SLM) که به‌درستی هدایت شده و از این سیستم لایه‌ای استفاده می‌کند، اغلب زنده‌تر از یک مدل پیشرو (Frontier Model) به نظر می‌رسد که فاقد مدیر وضعیت پایدار است.
برای توسعه‌دهندگان، این یعنی «هوش» یک NPC کمتر به توانایی‌های استدلالی مدل و بیشتر به دقت خط لولهٔ بازیابی وابسته است. با گروه‌بندی خاطرات در دسته‌های ۳ تا ۵ جفت پیام، توسعه‌دهندگان می‌توانند از تورم شاخص (Index Bloat) که معمولاً در بازیابی‌های تک-پیامی رخ می‌دهد، جلوگیری کنند.
پیاده‌سازی این سیستم وابستگی به مدل‌های گران‌قیمت با پارامترهای بالا را برای تعاملات سادهٔ شخصیتی کاهش می‌دهد. این رویکرد، NPC را از یک چت‌بات بدون وضعیت (Stateless) به موجودیتی با تاریخچه‌ای باورپذیر و پایدار تبدیل می‌کند.
توسعه‌دهندگانی که قصد پیاده‌سازی این سیستم را دارند، باید در گام بعدی الگوریتم‌های «زوال حافظه» (Memory Decay) را بررسی کنند تا اطمینان حاصل شود که خاطرات قدیمی‌تر و کم‌اهمیت‌تر به مرور زمان کمرنگ می‌شوند و تمرکز بازیابی دقیق باقی می‌ماند.
گام بعدی شما
- بررسی الگوریتم‌های «زوال حافظه» (Memory Decay) برای حذف خاطرات قدیمی و کم‌اهمیت.
- تست مدل‌های کوچک‌تر (مانند Llama-3-8B) با این معماری برای کاهش هزینه استنتاج.
- پیاده‌سازی لایه حقایق ساختاریافته برای متغیرهای کلیدی داستان.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو