هيكلة الذاكرة حسب النوع تقلل الرموز (tokens) المسترجعة بنسبة 40% تقريبًا.
لماذا تفشل مخازن الذاكرة المسطحة (flat memory store)
تُعلم معظم الدروس التعليمية للمبتدئين وكلاء LLM كيفية "التذكر" عن طريق إلحاق كل معلومة جديدة بقائمة واحدة وتغذية النموذج بتلك القائمة في كل دورة. الكود يتكون حرفيًا من ثلاثة أسطر فقط، وينتج عنه نموذج تجريبي يعمل. ولكن في الممارسة العملية، تنمو القائمة دون رقابة، وتظهر علامتان:
- يتعامل الوكيل مع البيانات القديمة على أنها لا تزال صحيحة، على سبيل المثال، تقديم وقت وصول متوقع (ETA) انتهت صلاحيته منذ ساعات.
- تمتلئ نافذة السياق (context window) بمعلومات ثانوية لا تؤثر أبدًا على الإجابة، مما يؤدي إلى تضخم تكاليف API وإبطاء أوقات الاستجابة.
لا يستطيع مخزن المتجهات (vector store) العادي أو ذاكرة التخزين المؤقت البسيطة (key-value cache) التمييز بين المسمى الوظيفي للمستخدم وحالة مشروع مؤقتة. عندما يقوم الوكيل بإجراء بحث دلالي (semantic search)، قد تظهر خوارزمية التشابه وقت وصول متوقع (ETA) قديمًا لمجرد أن الاستعلام يحتوي على نفس الكلمات، على الرغم من أن المعلومة لم تعد ذات صلة.
الذاكرة المهيكلة: أربع فئات، وهدف واحد
الحل هو التوقف عن معاملة الذاكرة ككتلة واحدة والبدء في تصنيف كل إدخال إلى واحدة من أربع فئات:
- حقائق المستخدم – سمات مستقرة مثل دور المستخدم، أو اللغة المفضلة، أو التصريح الأمني. هذه السمات نادرًا ما تتغير ويمكن تخزينها مؤقتًا طوال الجلسة.
- الملاحظات (Feedback) – قواعد صريحة يجب على الوكيل الالتزام بها، مثل "لا تكشف أبدًا عن كلمات مرور قاعدة البيانات" أو "تجنب الفكاهة في استفسارات الامتثال". ولأنها تحكم السلوك، فيجب أن تكون في الـ system prompt بدلاً من مجموعة البيانات القابلة للبحث.
- حالة المشروع – بيانات سريعة التغير مثل أوقات الوصول المتوقعة (ETAs) الحالية، أو تقدم المهام، أو الرموز (tokens) المؤقتة. تحتاج هذه الفئة إلى فحص انتهاء الصلاحية؛ فبمجرد خروج الطابع الزمني عن النطاق المحدد، يجب حذف الإدخال.
- المراجع – مؤشرات إلى خدمات خارجية، أو معرفات المستندات، أو نقاط نهاية API. هي ليست محتوىً للعرض، بل مسارات لجلب بيانات حديثة عند الحاجة.
يتيح Mem0 للمطورين إرفاق بيانات وصفية (metadata) عشوائية بكل سجل ذاكرة. ومن خلال الفهرسة بناءً على حقل "kind"، يمكن للاستعلام تصفية الفئة ذات الصلة أولاً قبل أن يقرر LLM كيفية استخدام النتيجة.
استرجاع على خطوتين باستخدام Mem0
- سحب الذكريات حسب النوع – يقوم استعلام تصفية قصير بطلب "كل الملاحظات" أو "إدخالات حالة المشروع الأحدث من فترة زمنية قصيرة" من Mem0. تكون مجموعة النتائج مقصوصة بالفعل لتناسب الفئة المناسبة.
- ترك القرار لـ LLM – يتم إدراج المقتطفات المصفاة في الـ prompt مع سؤال المستخدم الحالي. يمكن للنموذج الآن الاستنتاج بناءً عليها دون البحث في حقائق غير ذات صلة.
مثال ملموس: بدلاً من انتظار مطابقة دلالية لإظهار قاعدة "لا تسخر من قاعدة البيانات"، يقوم المطور بحقن تلك القاعدة مباشرة في الـ system prompt عند بدء الجلسة وتخزينها مؤقتًا طوال فترة التفاعل. وحتى لو لم يتضمن استعلام المستخدم أي إشارة صريحة إلى قواعد البيانات، فإن النموذج يعرف القيد بالفعل.
حيل عملية للحفاظ على انخفاض التكاليف
- تخزين قواعد الملاحظات مؤقتًا – قم بتخزين مجموعة القواعد مرة واحدة لكل جلسة وأعد استخدامها بدلاً من إعادة البحث في كل دورة. هذا يقلل من استخدام الرموز (tokens) في كل جولة.
- تخطي عمليات البحث عن حالة المشروع عندما تكون غير ذات صلة – إذا طرح المستخدم سؤالاً مفاهيميًا بحتًا ("ما الفرق بين التعلم الخاضع للإشراف والتعلم المعزز؟")، فلا داعي لسحب أي بيانات تتعلق بـ ETA أو تقدم المهام.
من خلال تطبيق هاتين العادتين، يمكن تقليل استخدام الرموز (tokens) بنسبة 40% تقريبًا مقارنة بنهج الذاكرة المسطحة البدائي. وتترجم هذه المدخرات مباشرة إلى فواتير API أقل وسرعة أكبر في الإنجاز، خاصة بالنسبة للوكلاء الذين يستمر تفاعلهم عبر العديد من المبادلات.
من المستفيد، ومن القلق؟
الرابحون – الفرق التي تبني بوتات دعم العملاء، أو مساعدي سير العمل الداخليين، أو أي واجهة LLM متعددة الأدوار. سيحصلون على إجابات أكثر موثوقية، ويتجنبون الأخطاء المحرجة الناتجة عن البيانات القديمة، ويستفيدون من ميزانياتهم بشكل أكبر.
الخلاصة
إذا كنت تريد وكيل LLM يظل دقيقًا خلال الجلسات الطويلة، فتوقف عن حشو كل حقيقة في نافذة سياق واحدة. قم بوسم كل ذكرى كحقيقة مستخدم، أو ملاحظة، أو حالة مشروع، أو مرجع، وافرض انتهاء الصلاحية حيثما لزم الأمر، واترك أداة مثل Mem0 تقوم بالعمل الشاق. النتيجة هي إجابات أكثر حداثة، ورموز (tokens) ضائعة أقل، وخفض ملحوظ في التكاليف التشغيلية.