كيفية عمل ذاكرة وكيل الذكاء الاصطناعي: اختبارها عبر واجهة برمجة التطبيقات (API)

الخلاصة

تفشل وكلاء الذكاء الاصطناعي ليس لأنهم يفتقرون إلى الذكاء ولكن لأنهم ينسون. فهم الأنواع الأربعة لذاكرة الوكيل، وكيفية تخزينها، وكيف تؤثر على سلوك واجهة برمجة التطبيقات (API) يتيح لك بناء وكلاء أكثر موثوقية واكتشاف الأخطاء قبل وصولها إلى الإنتاج.

مقدمة

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

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

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

ما هي ذاكرة وكيل الذكاء الاصطناعي؟

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

تخدم أربعة أنواع متميزة من الذاكرة أغراضًا مختلفة.

الأنواع الأربعة لذاكرة الوكيل

ذاكرة العمل

ذاكرة العمل هي السياق النشط للوكيل: كل شيء في المطالبة الحالية. بالنسبة لمعظم الوكلاء المستندين إلى LLM، هذا هو نافذة السياق. يتميز GPT-4o بنافذة سياق بحجم 128 ألف توكن. يدعم Claude 3.5 Sonnet 200 ألف توكن. يدعم Gemini 1.5 Pro مليون توكن.

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

الذاكرة العرضية

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

عمليًا، هذا عادة ما يكون قاعدة بيانات متجهة (Chroma، Pinecone، Qdrant) أو سجل أحداث منظم. يسترجع الوكيل الحلقات الماضية ذات الصلة عبر البحث الدلالي قبل إنشاء استجابة. تنهج Hippo في تخزين تسلسلات التفاعل مع الطوابع الزمنية وأوزان الانحلال، بحيث تحصل التفاعلات الحديثة على أولوية استرجاع أعلى.

الذاكرة الدلالية

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

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

الذاكرة الإجرائية

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

عملياً، يظهر على شكل أمثلة قليلة المرات مضمنة في مطالبة النظام، أو كمكتبة من خطط العمل المخزنة التي يمكن للوكيل استرجاعها وتكييفها.

كيف يتم تخزين الذاكرة في الأنظمة الحقيقية

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

نافذة السياق (العمل): كل شيء في المطالبة النشطة. يتم إدارتها بواسطة إطار عمل الوكيل. تنتهي صلاحيتها عند انتهاء المحادثة.

متجر متجه خارجي (عرضي + دلالي): يخزن Chroma أو Pinecone أو Qdrant تضمينات التفاعلات السابقة وكتل المعرفة. يستعلم الوكيل هذا في كل دورة ويحقن الكتل ذات الصلة في المطالبة.

قاعدة بيانات منظمة (دلالية + إجرائية): PostgreSQL أو SQLite لتفضيلات المستخدم، حالة الحساب، أو قوالب الإجراءات المتعلمة. يتم الاستعلام عنها عبر استدعاءات الأدوات.

ذاكرة التخزين المؤقت في الذاكرة (تجاوز ذاكرة العمل): Redis أو قاموس بسيط للوصول السريع إلى السياق الأخير الذي لا يحتاج إلى بحث تضمين.

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

كيف تؤثر ذاكرة الوكيل على سلوك واجهة برمجة التطبيقات (API)

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

معرفات الجلسة: تستخدم معظم واجهات برمجة تطبيقات الوكيل معرف جلسة أو معرف مؤشر ترابط لربط الذاكرة عبر الاستدعاءات. يستخدم OpenAI Assistants API thread_id. معرف مؤشر ترابط تم إسقاطه أو إعادة استخدامه يتسبب في فقدان الوكيل للسياق أو خلط جلسات مستخدمين اثنين.

حجم السياق في حمولات الطلب: الوكلاء الذين يحقنون الذاكرة في المطالبات ينتجون هيئات طلب أكبر بمرور الوقت. محادثة وكيل تبدأ بحجم 2 كيلوبايت يمكن أن تنمو إلى 40 كيلوبايت بعد 20 جولة. إذا كان عميل HTTP الخاص بك لديه حد لحجم الحمولة، فإن الطلبات تفشل بصمت.

وقت استرجاع البيانات: عمليات البحث في متجر المتجهات تضيف 50-200 مللي ثانية لكل دورة. إذا كنت تتحقق من وقت استجابة واجهة برمجة التطبيقات، فإن استرجاع الذاكرة يمثل مساهمًا حقيقيًا.

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

كيف تختبر ذاكرة الوكيل عبر واجهة برمجة التطبيقات باستخدام Apidog

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

تتعامل سيناريوهات اختبار Apidog مع هذا بالضبط. إليك كيفية إعداد أحدها لواجهة برمجة تطبيقات الوكيل.

الاختبار 1: نقل السياق

أنشئ سيناريو بثلاث خطوات متتالية:

1. POST /agent/chat مع رسالة تقدم حقيقة ("مشروعي يستخدم PostgreSQL 16")
2. POST /agent/chat مع متابعة تتطلب تذكر تلك الحقيقة ("ما هي قاعدة البيانات التي يجب أن أحسّنها؟")
3. التأكد من استجابة الخطوة 2: يجب أن يحتوي response.message.content على "PostgreSQL"

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

الاختبار 2: عزل الجلسات

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

الاختبار 3: تدهور الذاكرة عند الفشل

استخدم Apidog's Smart Mock لمحاكاة فشل في ذاكرة الواجهة الخلفية. قم بتكوين المحاكاة لإرجاع رمز 503 عند نقطة نهاية بحث المتجه. ثم قم بتشغيل محادثة الوكيل الخاصة بك وتأكد مما يلي: - يستجيب الوكيل دون تعطل - تتضمن الاستجابة تراجعًا لطيفًا ("ليس لدي سياق كافٍ للإجابة على ذلك") - يمكن استئناف الجلسة بعد إزالة المحاكاة

الاختبار 4: تجاوز نافذة السياق

أرسل أكثر من 30 رسالة سريعة متتالية لدفع ذاكرة العمل لتجاوز حد السياق. تأكد مما يلي: - لا يرمي الوكيل خطأ context_length_exceeded (يجب أن يقوم بالاقتطاع بلطف) - لا تزال الاستجابة في الجولة 30 تجيب بشكل صحيح باستخدام الاسترجاع العرضي - تظل أعداد التوكنات في response.usage ضمن النطاق المتوقع

يمكنك تشغيل كل هذه الاختبارات الأربعة كسيناريو اختبار واحد في Apidog، وربطها بالتسلسل مع متغيرات مشتركة لمعرفات الجلسة وبيانات الاستجابة. راجع [internal: how-to-build-tiny-llm-from-scratch] للحصول على معلومات أساسية حول كيفية عمل نوافذ السياق على مستوى النموذج.

أنماط فشل الذاكرة الشائعة

اقتطاع السياق الصامت: تمتلئ نافذة السياق وتختفي الرسائل القديمة دون سابق إنذار. يجيب الوكيل بناءً على تاريخ غير مكتمل. اكتشف هذا عن طريق التأكد من response.usage.prompt_tokens والتحقق من بقائه أقل من حد سياق نموذجك.

تسرب الجلسات: تتشارك جلستان لمستخدمين مختلفين في نفس مساحة اسم الذاكرة. اكتشف هذا باستخدام اختبارات عزل الجلسات.

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

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

حقن الذاكرة، حقن المطالبة: مدخلات مستخدم ضارة تتلاعب بما يتم تخزينه واسترجاعه. قم بتضمين مدخلات معادية في مجموعة اختبارك: قم بتخزين "تفضيل مستخدم" يحتوي على تجاوز مطالبة نظام وتحقق من أن الوكيل يتجاهلها. راجع [internal: rest-api-best-practices] للحصول على إرشادات أوسع لاختبار أمان واجهة برمجة التطبيقات.

الخلاصة

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

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

الأسئلة الشائعة

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

كيف يتعامل OpenAI Assistants API مع الذاكرة؟تدير واجهة برمجة تطبيقات المساعدين (Assistants API) كائن مؤشر ترابط (thread) يخزن سجل المحادثة على جانب الخادم. يمكنك أيضًا إرفاق أدوات البحث عن الملفات ومفسر الأكواد التي تمنح الوكيل الوصول إلى المعرفة الخارجية. تتم إزالة تعقيد إدارة الذاكرة، وهو أمر مريح ولكنه يجعل تصحيح الأخطاء أكثر صعوبة.

ما هي أفضل قاعدة بيانات متجهة لذاكرة الوكيل؟للتطوير المحلي: Chroma (لا توجد بنية تحتية مطلوبة). للإنتاج: Qdrant أو Pinecone اعتمادًا على ما إذا كنت بحاجة إلى استضافة ذاتية أو مُدارة. تدعم مكتبة Hippo واجهات خلفية تخزين قابلة للتوصيل. راجع [internal: claude-code] لمعرفة كيف يستخدم Claude Code طبقة الذاكرة الخاصة به.

كيف أمنع الوكلاء من التوهم بتفاعلات سابقة؟قم بتخزين سجلات التفاعل بتنسيق منظم مع بيانات وصفية (الطابع الزمني، الثقة، المصدر). عند استرجاع السياق السابق، قم بتضمين البيانات الوصفية في المطالبة: "وفقًا لمحادثتنا بتاريخ [التاريخ]، ذكرت X." يقلل الاقتباس الصريح من التوهم الواثق.

هل يمكنني اختبار ذاكرة الوكيل بدون وكيل قيد التشغيل؟نعم. استخدم Apidog's Smart Mock لمحاكاة استجابات API للوكيل، بما في ذلك الاستجابات المدعومة بالذاكرة. حدد استجابات وهمية تتغير بناءً على معرف الجلسة أو محتوى نص الطلب. يتيح لك هذا اختبار تعامل الواجهة الأمامية أو طبقة التكامل مع سلوك الذاكرة دون وجود وكيل مباشر.

كم تكلفة تخزين المتجهات في الإنتاج؟تتيح الطبقة المجانية من Pinecone دعم فهرس واحد بـ 100 ألف متجه. على نطاق واسع، تفرض Pinecone حوالي 0.096 دولارًا أمريكيًا/ساعة للوحدة p1.x1 (مليون متجه بـ 768 بعدًا). Qdrant المستضافة ذاتيًا مجانية. بالنسبة لمعظم الوكلاء، فإن التكلفة الأكبر هي توليد التضمينات، وليست التخزين. راجع [internal: what-is-mcp-server] لمعرفة كيفية تفاعل تكاملات خادم MCP مع أنظمة ذاكرة الوكيل.

ما الفرق بين RAG وذاكرة الوكيل؟تسترجع RAG (التوليد المعزز بالاسترجاع) المستندات ذات الصلة في وقت الاستعلام من قاعدة معرفة ثابتة. ذاكرة الوكيل ديناميكية: تنمو وتتغير مع تفاعل الوكيل. يجيب نظام RAG على "ماذا تقول المستندات عن X؟" يجيب نظام ذاكرة الوكيل على "ماذا أعرف عن هذا المستخدم وماذا فعلت معه؟"