ذاكرة وكيل الذكاء الاصطناعي: من التعقيد إلى 300 سطر من الشيفرة

تُعدّ ذاكرة وكيل الذكاء الاصطناعي من أصعب المشكلات عند بناء الأنظمة المستقلة. أمضى المطوّر Nikolay Gusev أشهراً في البحث عن حل عملي، وروى كيف وصل إلى نظام يجمع بين البساطة وقابلية التوسع.

MemPalace والخطأ الأول

بدأ كل شيء بفكرة طموحة هي MemPalace، وهو نظام ذاكرة مستوحى من عمارة القصور في العصور الوسطى. بدا النظام ذكياً على الورق، لكنه أنتج عملياً 58 ألف مقطع مكرر، وتحوّل إلى متاهة يتعذّر عبورها. فقد احتوى على طبقات تجريد أكثر مما ينبغي، وعلى قدر مفرط من «السحر». وهكذا ضلّ الوكيل داخل ذاكرته نفسها.

الطريق إلى البساطة

بعد MemPalace، بسّط المؤلف المنظومة إلى خمسة مكونات: MEMORY.md (القاعدة الأساسية)، وUSER.md (سياق المستخدم)، وSQLite state.db (الحالة)، وHippoRAG (البحث)، وملفات wiki (البيانات المنظمة). لكنّ ذلك بدا مفرطاً أيضاً. وكانت الخطوة الصائبة كتابة `findings_to_wiki`، وهو سكربت بسيط بلغة Python من 300 سطر. يحفظ السكربت التحليلات المنظمة (المعلَّمة بعناوين من نوع `## Findings`) تلقائياً في ملفات markdown، ثم يحوّلها إلى صفحات wiki. لا أطر عمل ولا ORM، بل ملفات ونصوص فقط.

التوسع: ClickHouse

عندما يعمل وكيل واحد، يؤدي التخزين على الملفات عمله على أكمل وجه. أما إذا لزم دعم أكثر من 100 مستخدم في وقت واحد، فالأمر يتطلب قاعدة بيانات حقيقية. وهنا يأتي دور ClickHouse 24.x. أبرز إمكاناته:

• البحث المتجهي (Vector search) عبر الدالة `cosineDistance()`: بحث سريع عن الذكريات المتشابهة دلالياً
• البحث النصي (Text search) مع الفهرس `tokenbf_v1`: بحث نصي كامل في الذاكرة
• التقسيم حسب user_id: عزل بيانات المستخدمين مدمج في قاعدة البيانات نفسها
• TTL للحذف التلقائي: تُحذف السجلات القديمة دون تدخل يدوي

يُجري ClickHouse التحليلات والبحث في ملايين السجلات خلال أجزاء من الثانية. وهذا أكثر من كافٍ لذاكرة الوكيل.

ماذا يعني ذلك

الخلاصة الرئيسية: لا تبدأ بالتوسع. عالج المشكلة ببساطة (ملفات وmarkdown و300 سطر من الشيفرة)، ثم وسّع النظام فقط إذا دعت الحاجة. وقد أثبت Nikolay أن أفضل مسار هندسي هو الانتقال من التعقيد إلى البساطة، لا العكس.