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

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

التركيبة الأساسية عملية إلى أبعد حد. يثبّت المؤلف حزم mem0ai وopenai وrich وchromadb، ثم ينشئ كائن Memory بالإعدادات الافتراضية: يُستخدم gpt-4.1-nano بوصفه LLM، وtext-embedding-3-small للتضمينات (embeddings)، وتؤدي ChromaDB دور مخزن المتجهات المحلي. الفكرة أن الوكيل يكفّ عن حمل سجل الدردشة بأكمله، ويبدأ بحفظ الحقائق الثابتة فقط: مهنة المستخدم، وحزمة أدواته التقنية، وتفضيلاته، ومشاريعه الحالية، وتفاصيله الشخصية، وغيرها من المعلومات التي ستفيد فعلًا في الجلسات اللاحقة.

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

الخطوة التالية هي البحث الدلالي. يبيّن الدليل كيف يتحول سؤال عادي مثل «ما بيئة التطوير (IDE) التي يستخدمها هذا المستخدم؟» إلى استعلام على الذاكرة مقيّد بـ user_id، فيعيد أقرب السجلات مع score لكل منها. وفوق ذلك تُعرض عمليات CRUD كاملة: يمكن استخراج الملف الشخصي بأكمله، أو جلب سجل محدد بمعرّفه، أو تعديل محتواه والتحقق من النتيجة فورًا. في المثال يُحدَّث أحد السجلات المتعلقة بمشروع RAG بإضافة وسم confirmed، ثم تُحذف ذاكرة أخرى بالكامل لاحقًا. أي أن الأمر لا يتعلق بغلاف جميل فوق سجل المحادثة، بل بطبقة بيانات مستقلة يمكن إدارتها كمنظومة فرعية قائمة بذاتها.

أكثر الأجزاء عملية هو حلقة الدردشة المعززة بالذاكرة (memory-augmented chat). قبل كل ردّ، يبحث الوكيل أولًا في الذاكرة عن ما يصل إلى خمس حقائق ذات صلة، ثم يجمعها في system prompt، وبعد ذلك فقط يستدعي النموذج gpt-4.1-nano-2025-04-14. وبعد توليد الرد، يُرسَل زوج user/assistant الجديد إلى Memory مرة أخرى، لتواصل القاعدة النمو. يمنح هذا النمط الوكيل سياقًا متصلًا: فهو يتذكر أي حزمة أدوات تفضّلها، وما العمل الذي تنشغل به، وما الذي تحب فعله خارج العمل، من دون أن يضطر في كل مرة إلى تمرير السجل التاريخي كاملًا إلى النموذج.

يتناول الدليل بصورة منفصلة أمرين يصعب تصور هذا النهج في بيئة الإنتاج من دونهما. الأول هو عزل المستخدمين. فللملف الثاني، Bob، تُحفظ حقائقه الخاصة: التخصص في computer vision وPyTorch، والعمل عبر Jupyter مع اختصارات لوحة المفاتيح الخاصة بـ Vim. وتعيد استعلامات البحث الخاصة بـ Alice وBob نتائج مختلفة، ما يؤكد أن الذاكرة مقيّدة بصرامة بـ user_id ولا تخلط بيانات المستخدمين. والثاني هو الإعداد المخصص. يمكن إنشاء Memory عبر from_config مع تحديد صريح للنموذج، وtemperature، وحد الرموز (tokens)، والمُضمِّن (embedder)، واسم مجموعة ChromaDB، ومسار التخزين. وفي الختام يعرض المؤلف أيضًا سجل تاريخ الذاكرة مع الطوابع الزمنية وقائمة كاملة بالسجلات، وهو أمر مفيد للتدقيق وتصحيح الأخطاء.

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