ساختارمند کردن حافظه بر اساس نوع، توکن‌های بازیابی‌شده را حدود ۴۰٪ کاهش می‌دهد.

چرا یک ذخیره‌ساز حافظه تخت (flat) از کار می‌افتد

بیشتر آموزش‌های مقدماتی به یک عامل LLM یاد می‌دهند که با افزودن هر قطعه اطلاعات جدید به یک لیست واحد و بازگرداندن آن لیست به مدل در هر مرحله، «به خاطر بسپارد». کد آن به معنای واقعی کلمه تنها سه خط است و یک دموی کارآمد ارائه می‌دهد. اما در عمل، این لیست بدون کنترل رشد می‌کند. دو نشانه ظاهر می‌شود:

  • عامل با داده‌های قدیمی همچنان مانند داده‌های درست برخورد می‌کند؛ مثلاً زمان تخمینی (ETA) رسیدنی را ارائه می‌دهد که ساعت‌ها پیش منقضی شده است.
  • پنجره بافت (context window) با اطلاعات جزئی و بی‌اهمیتی پر می‌شود که هرگز تأثیری بر پاسخ ندارند، که این امر باعث افزایش هزینه‌های API و کند شدن زمان پاسخ‌گویی می‌شود.

یک ذخیره‌ساز برداری (vector store) معمولی یا یک کش ساده‌ی کلید-مقدار (key-value) نمی‌تواند عنوان شغلی کاربر را از وضعیت موقت یک پروژه تشخیص دهد. وقتی عامل یک جستجوی معنایی (semantic search) انجام می‌دهد، الگوریتم شباهت ممکن است صرفاً به این دلیل که پرس‌وجو (query) شامل کلمات مشابهی است، یک ETA قدیمی را نمایش دهد، حتی اگر آن داده دیگر مرتبط نباشد.

حافظه ساختارمند: چهار دسته، یک هدف

راه حل این است که از برخورد با حافظه به عنوان یک واحد یکپارچه (monolith) دست بردارید و شروع به دسته‌بندی هر ورودی در یکی از چهار دسته زیر کنید:

  • حقایق کاربر (User facts) – ویژگی‌های پایدار مانند نقش کاربر، زبان ترجیحی یا سطح دسترسی امنیتی. این موارد به ندرت تغییر می‌کنند و می‌توان آن‌ها را برای کل جلسه (session) کش کرد.
  • بازخورد (Feedback) – قوانین صریحی که عامل باید از آن‌ها پیروی کند، مثلاً «هرگز رمز عبور پایگاه داده را فاش نکن» یا «در پرس‌وجوهای مربوط به انطباق (compliance) از شوخی پرهیز کن». از آنجایی که این قوانین رفتار عامل را کنترل می‌کنند، باید در دستور سیستم (system prompt) قرار بگیرند تا در مخزن قابل جستجو.
  • وضعیت پروژه (Project state) – داده‌های پرتحرک مانند ETAهای فعلی، پیشرفت وظایف یا توکن‌های موقت. این دسته نیاز به بررسی انقضا دارد؛ به محض اینکه یک برچسب زمانی (timestamp) از بازه زمانی تعریف‌شده خارج شود، آن ورودی باید پاک شود.
  • ارجاعات (References) – اشاره‌گرهایی به سرویس‌های خارجی، شناسه‌های سند یا نقاط پایانی API (endpoints). این‌ها محتوایی برای نمایش نیستند، بلکه مسیرهایی برای بازیابی داده‌های تازه در صورت نیاز هستند.

Mem0 به توسعه‌دهندگان اجازه می‌دهد متادیتای دلخواه را به هر رکورد حافظه پیوست کنند. با ایندکس کردن بر اساس فیلد "kind"، یک پرس‌وجو می‌تواند پیش از آنکه LLM در مورد نحوه استفاده از نتیجه تصمیم بگیرد، ابتدا دسته مربوطه را فیلتر کند.

بازیابی دو مرحله‌ای با Mem0

  1. استخراج حافظه‌ها بر اساس نوع – یک پرس‌وجوی فیلتر کوتاه از Mem0 درخواست می‌کند که «تمام بازخوردها» یا «ورودی‌های وضعیت پروژه که جدیدتر از یک بازه زمانی کوتاه هستند» را برگرداند. مجموعه نتایج از قبل برای دسته مناسب محدود شده است.
  2. اجازه دهید LLM تصمیم بگیرد – قطعات فیلتر شده همراه با سوال فعلی کاربر در پرامپت (prompt) قرار می‌گیرند. اکنون مدل می‌تواند بدون جستجو در میان حقایق بی‌ربط، درباره آن‌ها استدلال کند.

یک مثال ملموس: به جای اینکه منتظر بمانیم تا یک تطابق معنایی قانون «از پایگاه داده تمسخر نکن» را پیدا کند، توسعه‌دهنده آن قانون را مستقیماً در ابتدای جلسه در دستور سیستم تزریق کرده و آن را برای کل تعامل کش می‌کند. حتی اگر پرس‌وجوی کاربر هیچ اشاره صریحی به پایگاه‌های داده نداشته باشد، مدل از قبل با این محدودیت آشناست.

ترفندهای کاربردی برای کاهش هزینه‌ها

  • کش کردن قوانین بازخورد – مجموعه قوانین را یک بار در هر جلسه ذخیره کنید و به جای جستجوی مجدد در هر مرحله، از آن دوباره استفاده کنید. این کار مصرف توکن را در هر دور کاهش می‌دهد.
  • نادیده گرفتن جستجوهای وضعیت پروژه در صورت بی‌ربط بودن – اگر کاربر یک سوال کاملاً مفهومی بپرسد («تفاوت بین یادگیری نظارت‌شده و یادگیری تقویتی چیست؟»)، نیازی به استخراج داده‌های ETA یا پیشرفت وظایف نیست.

با به‌کارگیری این دو عادت، مصرف توکن را می‌توان در مقایسه با رویکرد ساده‌ی حافظه تخت، حدود ۴۰٪ کاهش داد. این صرفه‌جویی مستقیماً به کاهش صورت‌حساب‌های API و سرعت پاسخ‌گویی بیشتر منجر می‌شود، به‌ویژه برای عامل‌هایی که در طول تبادلات طولانی فعال می‌مانند.

چه کسانی سود می‌برند و چه کسانی نگران خواهند بود

برندگان – تیم‌هایی که در حال ساخت ربات‌های پشتیبانی مشتری، دستیاران گردش کار داخلی یا هر رابط کاربری چندمرحله‌ای LLM هستند. آن‌ها به پاسخ‌های قابل‌اعتمادتر دست می‌یابند، از اشتباهات خجالت‌آور ناشی از داده‌های قدیمی جلوگیری می‌کنند و بودجه خود را به شکل بهتری مدیریت می‌کنند.

نتیجه‌گیری

اگر می‌خواهید یک عامل LLM داشته باشید که در طول جلسات طولانی هوشیاری خود را حفظ کند، از چپاندن هر فکتی در یک پنجره بافت واحد دست بردارید. هر حافظه را با برچسب‌های حقایق کاربر، بازخورد، وضعیت پروژه یا ارجاع مشخص کنید، در صورت نیاز انقضا را اعمال کنید و اجازه دهید ابزاری مانند Mem0 کارهای سنگین را انجام دهد. نتیجه، پاسخ‌های تازه‌تر، توکن‌های اضافی کمتر و کاهش محسوس در هزینه‌های عملیاتی خواهد بود.