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

يقترح Agentis Memory فكرة بسيطة لكنها مهمة لسوق وكلاء الذكاء الاصطناعي: ذاكرة تشغيلية مشتركة يمكن التعامل معها كما يُتعامل مع Redis العادي. فبدلًا من قاعدة بيانات متجهية منفصلة وواجهة API خارجية للتضمينات وحزم SDK مخصصة، يجمع المشروع في عملية واحدة بين مخزن المفتاح والقيمة (key-value) والبحث الدلالي وحساب التضمينات محليًا. وبالنسبة إلى الفرق التي تبني أنظمة متعددة الوكلاء، تمثل هذه المحاولة معالجة لإحدى أكثر المشكلات إيلامًا، وهي تبادل السياق بين الوكلاء دون طبقات شبكية زائدة ودون تأخير.

ظهرت المشكلة في سيناريو واقعي هو التحقيق في حوادث الإنتاج. فعندما يدرس عدة وكلاء متخصصين السجلات والمقاييس والمراسلات وتاريخ الأعطال السابقة بالتوازي، لا يرى كل منهم سوى جزء من الصورة. قد يعثر أحد الوكلاء في السجلات على OOMKilled ويصل فعليًا إلى السبب الجذري (root cause)، بينما يواصل الآخرون في اللحظة نفسها بناء فرضياتهم الخاصة: ارتفاع في CPU، أو عملية نشر حديثة، أو أي ارتباط آخر. والنتيجة أن الوكيل المُجمِّع يتلقى عدة فرضيات متعارضة، بعضها مجرد ضوضاء. ولا تحل المشكلةَ محاولةُ تخزين هذه النتائج في ملف markdown مشترك: إذ تنشأ حالات تسابق عند الكتابة، ولا يوجد TTL، ولا بنية، ولا بحث بحسب المعنى. وهذا لم يعد كافيًا لنظام قائم على الوكلاء.

وأظهرت دراسة الحلول الجاهزة المشكلة نفسها من زاوية أخرى. فـ Mem0 وZep تُقدَّمان بالفعل بوصفهما طبقة ذاكرة (memory layer) لوكلاء الذكاء الاصطناعي، لكنهما تجرّان معهما REST API وحزم SDK منفصلة ومخزنًا متجهيًا وخدمات خارجية للتضمينات. أما Redis Stack فأقرب إلى النموذج المطلوب لأنه يحافظ على التوافق مع عملاء Redis، لكنه يُبقي حساب المتجهات خارج الخادم. وهذا مقبول في RAG طويل الأمد، لكنه ثقيل جدًا في الذاكرة التشغيلية، حيث يحفظ وكيل حقيقة ما ويجب أن يجدها وكيل ثانٍ خلال أجزاء من الثانية. فكل قفزة شبكية (hop) إضافية هنا تضر بزمن الاستجابة وبالموثوقية معًا.

كانت الفرضية الهندسية الأولى بديهية: أخذ Redis نفسه وعمل fork له ودمج ONNX Runtime وفهرس متجهي بداخله. لكن هذا المسار اصطدم سريعًا بتعقيد العمل مع لغة C والمكتبات الأصلية وإدارة الذاكرة وعدم الاستقرار تحت الطلبات المتزامنة. وبعد نموذج أولي فاشل، أُعيدت كتابة المشروع من الصفر بلغة Java 25 مع GraalVM native-image. وهكذا نتج ملف تنفيذي أصلي واحد بحجم نحو 150 ميغابايت يتضمن نموذج التضمينات مدمجًا. ويستخدم المشروع من الداخل Java Vector API لتسريع حساب تشابه جيب التمام (cosine similarity) عبر SIMD، وProject Loom للخيوط الافتراضية (virtual threads)، وONNX Runtime للاستدلال المحلي لنموذج all-MiniLM-L6-v2، ومكتبة jvector للبحث عن أقرب الجيران بخوارزمية HNSW.

ومن الخارج يتصرف Agentis Memory كخادم Redis مألوف. فهو يدعم أكثر من 90 أمرًا قياسيًا، إضافة إلى TTL وSCAN وpub/sub الأساسي، ويمكن الاتصال به عبر عملاء اعتياديين مثل redis-py وJedis وioredis وgo-redis. أما الفارق الجوهري فهو أربعة أوامر إضافية خاصة بالذاكرة. يستقبل MEMSAVE نصًا ويقسمه إلى مقاطع (chunks) بحسب الجمل، ويحسب متجهات ذات 384 بعدًا ويفهرسها بشكل غير متزامن، وعادةً خلال 5–10 ميلي ثانية للمقطع الواحد. ويستقبل MEMQUERY استعلامًا بلغة طبيعية ويعيد أقرب السجلات بحسب تشابه جيب التمام. ويُظهر MEMSTATUS ما إذا كان الفهرس جاهزًا لمفتاح معيّن، بينما يحذف MEMDEL البيانات من طبقة المفتاح والقيمة ومن الفهرس المتجهي في آن واحد. وبالنسبة إلى المطور، يبدو ذلك امتدادًا بسيطًا لنموذج Redis المألوف، لا منصة منفصلة بمنظومة جديدة.

وجاءت قصة الأداء بدورها دالة. فقد كانت النسخة الأولى بلغة Java أبطأ من Redis بنحو الضعف. وبعد الانتقال إلى GraalVM native-image وإعادة كتابة المسار الحرج (hot path) عبر Vector API، انقلب الوضع: ارتفعت العمليات النصية من نحو 60 ألفًا إلى 168 ألف عملية في الثانية، أي إن المشروع بلغ مستوى يقارب 1.

36 ضعف Redis. وفي حمل العمل المختلط (mixed workload) بلغت النتيجة نحو 1.40 ضعف.

وعند عمق pipeline يساوي 100 سجّل النظام 3.19 مليون عملية في الثانية، أي نحو 1.71 ضعف Redis، بفضل بنية متعددة الخيوط دون حلقة أحداث (event loop) أحادية الخيط.

لكن يبقى هناك مقايضة: ففي زمن الاستجابة p99 على العمليات النصية لا يزال Redis متقدمًا، إذ يسجل 3.82 ميلي ثانية مقابل 6.27 لـ Agentis Memory، وهذا هو الثمن الذي لا بد من دفعه مقابل جمع المهملات (garbage collection).

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

وعلى مستوى أوسع، يُظهر Agentis Memory بوضوح كيف تتغير البنية التحتية المحيطة بوكلاء الذكاء الاصطناعي. فلم يعد يكفي السوق مجرد ربط LLM والأدوات والمنسّق (orchestrator). ونقطة التنافس التالية هي الذاكرة المشتركة، وسرعة مزامنة السياق، وقدرة النظام على استبعاد الفرضيات الخاطئة بسرعة. وإذا ترسّخ النموذج المتوافق مع Redis ذو التضمينات المحلية في الأحمال الفعلية، فقد تصبح هذه الحلول لأنظمة الوكلاء ما أصبح Redis العادي منذ زمن طويل لمطوّر الـ backend الكلاسيكي: طبقة سريعة للتنسيق والتخزين المؤقت وذاكرة العمل المشتركة.

*Meta признана экстремистской организацией и запрещена в РФ.