Mem0 و OpenAI: كيفية بناء طبقة ذاكرة عامة طويلة المدى لوكلاء الذكاء الاصطناعي

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

الإعداد الأساسي عملي للغاية. يقوم المؤلف بتثبيت mem0ai و openai و rich و chromadb، ثم يهيئ كائن Memory بالتكوين الافتراضي: gpt-4.1-nano يعمل كـ LLM، text-embedding-3-small يتعامل مع التضمينات، و ChromaDB يعمل كمستودع المتجهات المحلي.

الفكرة هي أن الوكيل يتوقف عن حمل سجل الدردشة بالكامل وبدلاً من ذلك يحفظ فقط الحقائق المستمرة: مهنة المستخدم وموضع العمل والتفضيلات والمشاريع الحالية والتفاصيل الشخصية وغيرها من المعلومات التي ستكون مفيدة فعلاً في الجلسات المستقبلية.

يتم استخدام ملف اختبار، Alice، للعرض التوضيحي. من عدة حوارات قصيرة، يستخرج النظام تلقائياً عشرات الذكريات المنفصلة: أن المستخدم يعمل كمهندس برمجيات، يحب Python والتعلم الآلي، يفضل المظهر الداكن، يستخدم VS Code، يبني خط أنابيب RAG للتوثيق الداخلي لشركة ناشئة في fintech، يستمتع بالمشي وقضاء الوقت مع كلب يسمى Max.

هذا تحول مهم: بدلاً من النص الخام في قاعدة البيانات، تظهر سجلات دلالية ذرية يمكن البحث عنها لاحقاً وتحديثها وحذفها بشكل مستقل عن بعضها البعض.

الخطوة التالية هي البحث الدلالي. يوضح البرنامج التعليمي كيف يتحول سؤال بسيط مثل "ما هو IDE الذي يستخدمه هذا المستخدم؟" إلى استعلام ذاكرة مصفى حسب user_id ويعيد أكثر السجلات ذات الصلة مع نقاطها.

بناءً على ذلك، يتم عرض عمليات CRUD كاملة: يمكنك تصدير الملف الشخصي بالكامل، واسترجاع سجل معين بواسطة ID، وتحرير محتواه والتحقق من الفور من النتيجة.

في المثال، يتم تحديث سجل واحد حول مشروع RAG بعلامة confirmed، وفي وقت لاحق يتم حذف ذاكرة أخرى بالكامل. أي أن هذا ليس مجرد غلاف أنيق فوق سجل الدردشة، بل طبقة بيانات منفصلة يمكن إدارتها كنظام فرعي مناسب.

الجزء الأكثر عملية هو حلقة الدردشة المعززة بالذاكرة. قبل كل إجابة، يبحث الوكيل أولاً في الذاكرة عن ما يصل إلى خمس حقائق ذات صلة، ثم يجمعها في prompt النظام، وفقط بعد ذلك يستدعي نموذج gpt-4.1-nano-2025-04-14.

بعد توليد الإجابة، يتم إرسال زوج user/assistant الجديد مرة أخرى إلى Memory حتى تستمر قاعدة البيانات في النمو. يعطي هذا النمط للوكيل سياقاً مستمراً: يتذكر stack الأفضل لديك وما تعمل عليه وما تحب فعله خارج العمل، لكن لا يضطر إلى إطعام السجل التاريخي بالكامل للنموذج في كل مرة.

يتم مناقشة جانبين أساسيين لاستخدام الإنتاج بشكل منفصل. الأول هو عزل المستخدمين. بالنسبة للملف الثاني، Bob، يتم الحفاظ على حقائق منفصلة: التخصص في رؤية الكمبيوتر و PyTorch والعمل من خلال Jupyter و Vim keybindings.

تعيد استعلامات البحث لـ Alice و Bob نتائج مختلفة، مما يؤكد أن الذاكرة مقيدة بصرامة بواسطة user_id ولا تخلط بيانات المستخدمين الآخرين.

الثاني هو التكوين المخصص. يمكن إنشاء Memory عبر from_config، مع تحديد النموذج ودرجة الحرارة وحد الرموز والمضمن واسم مجموعة ChromaDB ومسار التخزين بشكل صريح.

أخيراً، يعرض المؤلف أيضاً سجل الذاكرة مع الطوابع الزمنية وقائمة كاملة بالسجلات، وهو ما يكون مفيداً للتدقيق والتصحيح.

الخلاصة واضحة: الذاكرة طويلة الأجل للوكلاء تصبح تدريجياً طبقة بنية تحتية منفصلة بدلاً من كونها ميزة دردشة إضافية.

يوفر الجمع بين Mem0 و OpenAI و ChromaDB قالباً أدنى واضحاً للبدء محلياً، ثم استبدال متجر المتجهات بـ Qdrant أو Pinecone أو Weaviate ودمج الذاكرة في LangChain أو LangGraph أو CrewAI.

بالنسبة للفرق التي تبني مساعدات شخصية أو بوتات الدعم أو أدوات ذكاء اصطناعي داخلية، فهذا لم يعد تحسيناً ديكوراتياً بل طريقة لجعل الإجابات متسقة وشخصية وقابلة للإدارة عبر الجلسات.