الخلاصة
تفشل وكلاء الذكاء الاصطناعي ليس لأنهم يفتقرون إلى الذكاء ولكن لأنهم ينسون. فهم الأنواع الأربعة لذاكرة الوكيل، وكيفية تخزينها، وكيف تؤثر على سلوك واجهة برمجة التطبيقات (API) يتيح لك بناء وكلاء أكثر موثوقية واكتشاف الأخطاء قبل وصولها إلى الإنتاج.
مقدمة
إليكم السر الرئيسي وراء معظم حالات فشل وكلاء الذكاء الاصطناعي: النموذج غالبًا يعمل كما يجب، لكن طبقة الذاكرة هي مصدر الخلل.
أي وكيل لا يستطيع تذكر ما حدث في آخر جولات أو يفقد سياق المستخدم بين الجلسات أو يناقض نفسه في منتصف المهمة، لا يعاني عادة من مشكلة في النموذج نفسه، بل في بنية أو اختبار الذاكرة.
Hippo هو نظام ذاكرة وكيل مفتوح المصدر يعتمد على تقسيم الذاكرة إلى قصيرة وطويلة وعرضية كما في الذاكرة البشرية. هذا المشروع كشف أن معظم المطورين يبنون طبقة الذاكرة كفكرة جانبية، ليكتشفوا الخلل لاحقًا عند التشغيل الفعلي.
💡 سيناريوهات اختبار Apidog تساعدك على اختبار محادثات الوكيل المتعددة الجولات والتحقق من انتقال وتخزين السياق بين استدعاءات الـ API. يمكنك أيضًا محاكاة تعطل الذاكرة باستخدام Smart Mock. هذه الطبقة من الاختبار ستتعلم تطبيقها عمليًا في القسم التالي. للاطلاع على منهجية اختبار أوسع، راجع [internal: api-testing-tutorial].
ما هي ذاكرة وكيل الذكاء الاصطناعي؟
ذاكرة الوكيل هي أي آلية تسمح لنظام الذكاء الاصطناعي بتخزين أو استرجاع معلومات تتجاوز الطلب الحالي. بدونها، كل استدعاء API يكون عديم الحالة: يرد النموذج على الطلب وينسى كل شيء.
هناك أربعة أنواع رئيسية من الذاكرة، لكل منها استخدام عملي مختلف:
الأنواع الأربعة故 لذاكرة الوكيل
1. ذاكرة العمل
ذاكرة العمل هي نافذة السياق النشطة: كل ما هو موجود في الطلب الحالي. في وكلاء LLM، هذا يعني نافذة السياق الخاصة بالنموذج (مثلاً: GPT-4o بـ 128 ألف توكن، Claude 3.5 Sonnet بـ 200 ألف توكن، Gemini 1.5 Pro بمليون توكن).
- سريعة ودقيقة ولكن مكلفة ومحدودة الحجم.
- عند تجاوز الحد، تُحذف أقدم المعلومات بصمت.
- مصدر شائع للأخطاء في المهام الطويلة أو المحادثات المستمرة.
2. الذاكرة العرضية
تخزن سجل التفاعلات السابقة، كالدفتر اليومي للوكيل.
- عادة تُخزن في قاعدة بيانات متجهة (Chroma، Pinecone، Qdrant) أو سجل أحداث.
- عند الحاجة، يبحث الوكيل دلاليًا عن الحلقات ذات الصلة ويسترجعها للسياق.
- مثال عملي: Hippo تخزن التفاعلات مع طوابع زمنية وأوزان انحلال لتعطي الأولوية للأحدث.
3. الذاكرة الدلالية
تخزن معارف وثوابت الوكيل، مثل الحقائق، تفضيلات المستخدم، والمعلومات الثابتة.
- يمكن تحميلها مسبقًا عبر مطالبة النظام، أو بناؤها ديناميكيًا من الحوارات، أو الاستعانة بمصادر خارجية (RAG).
- ليست مرتبة زمنيًا.
4. الذاكرة الإجرائية
تخزن "كيف" يقوم الوكيل بالأشياء: الإجراءات، استخدام الأدوات، والمهارات المكتسبة.
- عادة تكون أمثلة مضمنة في مطالبة النظام أو مخططات عمل قابلة للاسترجاع.
- أصعب أنواع الذاكرة في البناء وغالبًا ما تُتجاهل في الإنتاج.
كيف يتم تخزين الذاكرة في الأنظمة الحقيقية
نادراً ما توجد أربعة مخازن منفصلة. غالبًا يتم الدمج كالتالي:
- نافذة السياق (ذاكرة العمل): تدار من قبل إطار العمل وتنتهي مع نهاية الجلسة.
- متجر متجه خارجي (عرضي + دلالي): Chroma أو Pinecone أو Qdrant لتخزين التفاعلات والمعرفة، يُستعلم عنها كل دورة وتُحقن النتائج في الطلب.
- قاعدة بيانات منظمة (دلالية + إجرائية): PostgreSQL أو SQLite لتخزين تفضيلات المستخدم أو قوالب الإجراءات.
- ذاكرة تخزين مؤقت (Cache): Redis أو قاموس بسيط لتخزين السياق السريع.
Hippo يتميز بمنطق تسليم صريح: يُدمج ما لم يُستخدم من ذاكرة العمل في العرضية، ثم تُلخّص العرضية في الدلالية، كما في الدمج البشري أثناء النوم (لدى المشروع أمر "نوم" لتفعيل الدمج).
كيف تؤثر ذاكرة الوكيل على سلوك واجهة برمجة التطبيقات (API)
ذاكرة الوكيل تؤثر مباشرة على شكل طلبات واستجابات الـ API، وهنا نقاط عملية يجب الانتباه إليها:
- معرفات الجلسة: معظم واجهات برمجة التطبيقات تعتمد على معرف جلسة أو مؤشر ترابط. فقدان أو إعادة استخدام المعرف ينتج فقدان السياق أو خلط جلسات مستخدمين.
- حجم السياق: حقن الذاكرة في الطلبات يزيد حجم الحمولة بمرور الوقت. راقب حدود حجم الطلب في عميل HTTP لتفادي فشل صامت.
- زمن الاسترجاع: البحث في متجر المتجهات قد يضيف 50-200 مللي ثانية. إذا كنت تراقب الأداء، احسب وقت استرجاع الذاكرة.
- حالة متسقة بعد الأعطال: فشل استدعاء أداة أثناء المهمة قد يترك الذاكرة في حالة غير متسقة. استخدم نقاط تفتيش (checkpoint) قبل وبعد الأدوات.
كيف تختبر ذاكرة الوكيل عبر واجهة برمجة التطبيقات باستخدام Apidog
اختبار واجهات برمجة التطبيقات ذات الحالة يتطلب أكثر من تأكيد طلب منفصل. يجب اختبار انتقال السياق، وتغير الاستجابات المدعومة بالذاكرة، وسلوك النظام عند تعطل الذاكرة.
إليك سيناريوهات اختبار عملية يمكنك تنفيذها في Apidog:
الاختبار 1: نقل السياق
- أرسل طلب POST إلى
/agent/chatمع رسالة تحتوي على معلومة ("مشروعي يستخدم PostgreSQL 16"). - أرسل POST آخر بطلب متابعة ("ما هي قاعدة البيانات التي يجب أن أحسّنها؟").
- تحقق أن الاستجابة الثانية تتضمن "PostgreSQL" في
response.message.content.
إذا كانت طبقة الذاكرة تعمل، ستظهر المعلومة في الاستجابة. إذا لم تعمل، ستحصل على إجابة عامة.
الاختبار 2: عزل الجلسات
- كرر نفس التسلسل بخطوتين ولكن مع قيم مختلفة لـ
session_id. - تأكد أن الجلسة الثانية لا تسترجع أي سياق من الأولى.
هذا يكشف عن أخطاء الذاكرة المشتركة بين الجلسات، وهي من أصعب المشاكل في بيئات الإنتاج متعددة المستأجرين.
الاختبار 3: تدهور الذاكرة عند الفشل
- استخدم Smart Mock في Apidog لمحاكاة فشل في الذاكرة الخلفية (مثلاً، إرجاع 503 عند نقطة نهاية البحث).
- اختبر أن الوكيل:
- لا يتعطل.
- يعيد رسالة تراجع لطيفة ("ليس لدي سياق كافٍ للإجابة على ذلك").
- يمكن استئناف الجلسة بعد إزالة العطل.
الاختبار 4: تجاوز نافذة السياق
- أرسل أكثر من 30 رسالة متتالية لدفع ذاكرة العمل لتجاوز الحد.
- تحقق أن:
- الوكيل لا يرمي خطأ
context_length_exceeded(يجب أن يقتطع السياق بلطف). - يستمر في الإجابة بشكل صحيح باستخدام الاسترجاع العرضي.
- عدد التوكنات في
response.usageيبقى ضمن النطاق المتوقع.
- الوكيل لا يرمي خطأ
يمكنك ربط جميع هذه الاختبارات في سيناريو اختبار واحد في Apidog مع متغيرات مشتركة لمعرفات الجلسة وبيانات الاستجابة. لمزيد من التفاصيل حول كيفية عمل نوافذ السياق، راجع [internal: how-to-build-tiny-llm-from-scratch].
أنماط فشل الذاكرة الشائعة
-
اقتطاع السياق الصامت: تمتلئ نافذة السياق وتختفي الرسائل القديمة دون إنذار. تحقق من
response.usage.prompt_tokensللتأكد من عدم تجاوز الحد. - تسرب الجلسات: جلستان تشتركان في نفس مساحة الذاكرة. اختبر ذلك عبر سيناريوهات عزل الجلسات.
- ذاكرة دلالية قديمة: معلومات قديمة تتعارض مع الحقائق الجديدة. أضف تأكيد لتاريخ اليوم في الاختبار.
- انحراف التضمين: تغيير نموذج تضمين البيانات قد يجعل الاسترجاع غير دلالي. أضف تأكيدات دلالية.
- حقن الذاكرة أو المطالبة: إدخال مستخدم ضار يغير ما يُخزن أو يُسترجع. اختبر بإرسال مدخلات معادية وتأكد من تجاهلها بالشكل الصحيح. للمزيد حول اختبار الأمان، راجع [internal: rest-api-best-practices].
الخلاصة
ذاكرة الوكيل هي ما يميز بين مساعد ذكي وآخر فاقد للذاكرة. الأنواع الأربعة (العمل، العرضية، الدلالية، الإجرائية) لكل منها دور محدد. فهم كيفية تخزين واسترجاع هذه الأنواع عمليًا يرشدك لاكتشاف الأخطاء المحتملة ومكان اختبارها داخل واجهة برمجة التطبيقات.
أدوات مثل Hippo توضح أن الاتجاه نحو بنية ذاكرة أكثر تنظيمًا. أيًا كان النظام الذي تعتمد عليه، سيناريوهات اختبار Apidog تمنحك طبقة تحقق فعالة، خاصة في حالات الفشل التي تظهر فقط عند التشغيل على نطاق واسع.
الأسئلة الشائعة
ما هي أبسط طريقة لإضافة الذاكرة إلى الوكيل؟
الطريقة الأبسط هي نافذة منزلقة (sliding window) على المحادثة: احتفظ بآخر N رسائل في الطلب. هذا لا يمنحك ذاكرة عرضية حقيقية لكنه كافٍ للمهام القصيرة. للمهام الأطول، أضف متجر متجه واسترجاع دلالي.
كيف يتعامل OpenAI Assistants API مع الذاكرة؟
الـ Assistants API يدير كائن thread يخزن سجل المحادثة على الخادم. يمكن ربط أدوات خارجية تمنح الوكيل معرفة إضافية. إدارة الذاكرة تصبح أوتوماتيكية، مما يسهل البناء ويصعب التصحيح.
ما هي أفضل قاعدة بيانات متجهة لذاكرة الوكيل؟
للتطوير المحلي: Chroma (بدون متطلبات بنية تحتية). للإنتاج: Qdrant أو Pinecone، حسب الحاجة لاستضافة ذاتية أو مُدارة. مكتبة Hippo تدعم واجهات تخزين قابلة للتوصيل. راجع [internal: claude-code] لمزيد حول استخدام Claude Code للذاكرة.
كيف أمنع الوكلاء من التوهم بتفاعلات سابقة؟
خزن السجلات بتنسيق منظم مع بيانات وصفية (تاريخ، موثوقية، مصدر). عند الاسترجاع، أضف البيانات الوصفية للمطالبة: "حسب محادثتنا بتاريخ [التاريخ]، ذكرت X." هذا يقلل من التوهم.
هل يمكنني اختبار ذاكرة الوكيل بدون تشغيل وكيل فعلي؟
نعم. استخدم Smart Mock في Apidog لمحاكاة استجابات الوكيل، بما فيها تلك المعتمدة على الذاكرة. صمّم استجابات وهمية تتغير حسب session_id أو محتوى الطلب لاختبار منطق الواجهة الأمامية أو التكامل دون الحاجة لوكيل فعلي.
كم تكلفة تخزين المتجهات في الإنتاج؟
الطبقة المجانية من Pinecone تدعم فهرس واحد حتى 100 ألف متجه. للإنتاج: Pinecone حوالي 0.096$/ساعة لـ p1.x1 (مليون متجه × 768 بعد). Qdrant ذاتي الاستضافة مجاني. التكلفة الأكبر غالبًا في توليد التضمينات وليس التخزين. لمزيد من التفاصيل حول تكاملات MCP Server، راجع [internal: what-is-mcp-server].
ما الفرق بين RAG وذاكرة الوكيل؟
RAG (التوليد المعزز بالاسترجاع) يسترجع مستندات من قاعدة معرفة ثابتة عند كل استعلام. ذاكرة الوكيل ديناميكية، تتغير مع كل تفاعل. RAG يجيب "ماذا تقول المستندات؟" بينما الذاكرة تجيب "ماذا أعرف عن هذا المستخدم وماذا فعلت معه؟"

Top comments (0)