Agentis Memory: تخزين متوافق مع Redis مع بحث متجه وتضمينات محلية

يقترح Agentis Memory فكرة بسيطة لكن مهمة لسوق وكلاء الذكاء الاصطناعي: ذاكرة مشتركة تتصرف مثل Redis العادي. بدلاً من قاعدة بيانات متجهة منفصلة وواجهة برمجة تطبيقات تضمين خارجية وحزم SDK مخصصة، يجمع المشروع بين تخزين المفاتيح والقيم والبحث الدلالي وحساب التضمينات محلياً في عملية واحدة. بالنسبة للفرق التي تبني أنظمة متعددة الوكلاء، هذه محاولة لحل أحد أكثر المشاكل إيلاماً: تبادل السياق بين الوكلاء بدون طبقات شبكة إضافية وكمون.

ظهرت المشكلة في سيناريو حقيقي لتحقيق حادث الإنتاج. عندما يعمل عدة وكلاء متخصصين بالتوازي دراسة السجلات والمقاييس والمحادثات وسجل الحوادث، يرى كل منها فقط جزءه الخاص من الصورة الكاملة. قد يجد أحد الوكلاء OOMKilled في السجلات وبالفعل يتتبع السبب الجذري، لكن الآخرين يستمرون في بناء فروضهم الخاصة: ارتفاعات وحدة المعالجة المركزية أو نشر حديث أو أي ارتباط آخر.

ينتهي المركب بجمع عدة فرضيات متعارضة، الكثير منها مجرد ضوضاء. محاولة تخزين مثل هذه النتائج في ملف markdown مشترك لا تساعد: تبدأ تضارب الكتابة، لا توجد TTL، لا توجد بنية ولا بحث دلالي. بالنسبة لنظام وكلاء، هذا غير كافٍ بالفعل.

أظهر استقصاء الحلول الموجودة نفس المشكلة من زاوية أخرى. يضع Mem0 و Zep نفسيهما بالفعل كطبقات ذاكرة لوكلاء الذكاء الاصطناعي، لكنهما يأتيان مع واجهات برمجة تطبيقات REST وحزم SDK منفصلة وتخزين متجه وخدمات خارجية للتضمينات. Redis Stack أقرب إلى النموذج المطلوب لأنه يحافظ على التوافق مع عملاء Redis، لكنه يترك حساب المتجه خارج الخادم.

بالنسبة لـ RAG طويل الأمد هذا محتمل، لكن بالنسبة للذاكرة العاملة حيث يحفظ أحد الوكلاء حقيقة ويجب أن يجدها آخر في أجزاء من الثانية، مثل هذا المخطط ثقيل جداً. يؤثر كل قفزة شبكة إضافية على الكمون والموثوقية. الفرضية الهندسية الأولى كانت واضحة: خذ Redis نفسه، انسخه وادمج ONNX Runtime وفهرس متجه بداخله.

عملياً، اصطدم هذا المسار بسرعة بعمل معقد مع C والمكتبات الأصلية وإدارة الذاكرة وعدم الاستقرار تحت الطلبات المتزامنة. بعد نموذج أولي فاشل، تمت إعادة كتابة المشروع من الصفر في Java 25 باستخدام GraalVM native-image. أسفر هذا عن ملف ثنائي أصلي واحد بحجم حوالي 150 ميجابايت مع نموذج تضمين مدمج بالفعل.

يستخدم داخلياً Java Vector API لتسريع SIMD للتشابه الكوسيني و Project Loom للخيوط الافتراضية و ONNX Runtime للاستدلال المحلي لنموذج all-MiniLM-L6-v2 ومكتبة jvector للبحث HNSW عن الجيران الأقرب. من الخارج، يتصرف Agentis Memory مثل خادم Redis المألوف. يدعم أكثر من 90 أمر قياسي و TTL و SCAN و pub/sub الأساسي، ويمكن الوصول إليه من خلال عملاء عاديين مثل redis-py و Jedis و ioredis و go-redis.

الفرق الرئيسي هو أربع أوامر ذاكرة إضافية. تأخذ MEMSAVE النص وتقسمه إلى أجزاء حسب الجمل وتحسب متجهات ذات 384 بُعد وتفهرسها بشكل غير متزامن، عادة في 5-10 ميلي ثانية لكل جزء. تأخذ MEMQUERY استعلام باللغة الطبيعية وتعيد أقرب السجلات حسب تشابه جيب التمام.

تعرض MEMSTATUS ما إذا كان الفهرس جاهزاً لمفتاح معين، وتحذف MEMDEL البيانات في نفس الوقت من طبقة المفتاح والقيمة والفهرس المتجه. بالنسبة للمطور، يبدو هذا مثل إضافة بسيطة لنموذج Redis المألوف بالفعل، وليس منصة منفصلة مع نظام بيئي جديد. كانت قصة الأداء أيضاً تعليمية.

كانت النسخة الأولى من Java تعمل بشكل أبطأ تقريباً مرتين من Redis. بعد الانتقال إلى GraalVM native-image وإعادة كتابة المسار الحار باستخدام Vector API، انعكست الحالة: نمت عمليات السلسلة من حوالي 60 ألف إلى 168 ألف عملية/ثانية، مما يضع المشروع بحوالي 1.36x من مستوى Redis.

في حمل العمل المختلط كانت النتيجة حوالي 1.40x. بعمق خط أنابيب 100 حقق النظام 3.

19 مليون عملية في الثانية، أو حوالي 1.71x Redis، وذلك بفضل البنية متعددة الخيوط بدون حلقة أحداث أحادية الخيط. لكن التنازل يبقى: في كمون p99 Redis لا يزال متقدماً على السلاسل — 3.

82 ميلي ثانية مقابل 6.27 لـ Agentis Memory، وهذا هو السعر المدفوع لجمع القمامة. يتم التركيز بشكل خاص على الخصوصية والتكلفة.

يتم حساب التضمينات محلياً عبر ONNX Runtime مباشرة داخل العملية، بدون مفاتيح API، بدون استدعاءات للخدمات الخارجية وبدون إرسال السجلات أو المقاييس أو حركة الخدمة إلى السحابة. بالنسبة للأنظمة التي تعمل مع الحوادث والبنية الأساسية الداخلية، هذا ليس تحسيناً تجميلياً بل قرار معماري مهم. يستغرق الاستدلال المحلي حوالي 2-5 ميلي ثانية لكل جزء، ولا يكلف أي فاتورة تضمين منفصلة، ويزيل الاعتماد على وقت التشغيل لطرف ثالث.

كلما كانت البيانات أكثر حساسية وزادت تكرار الوصول، كانت فوائد هذا النهج أكثر وضوحاً. على مستوى أوسع، يوضح Agentis Memory جيداً كيف تتغير البنية الأساسية حول وكلاء الذكاء الاصطناعي. السوق لم يعد لديه مجال لمجرد توصيل LLM والأدوات والمنسق.

نقطة المنافسة التالية هي الذاكرة المشتركة وسرعة مزامنة السياق وقدرة النظام على التخلص بسرعة من الفرضيات الخاطئة. إذا اكتسب نموذج متوافق مع Redis مع التضمينات المحلية القوة في الأحمال الحقيقية، يمكن لمثل هذه الحلول أن تصبح بالنسبة لأنظمة الوكلاء ما أصبح Redis العادي منذ فترة طويلة بالنسبة لمطوري الواجهات الخلفية التقليديين: طبقة سريعة من التنسيق والتخزين المؤقت والذاكرة المشتركة.