كيف تمنح الذكاء الاصطناعي ذاكرة بشرية فائقة

الخلاصة / إجابة سريعة

Supermemory يمنحك طبقة ذاكرة وسياق لتطبيقات الذكاء الاصطناعي، لكن أنظمة الذاكرة أصعب في تصحيح الأخطاء من واجهات برمجة تطبيقات CRUD العادية. سير العمل الموثوق به هو اختبار مسارات الاستيعاب، والملف الشخصي، والبحث في Supermemory مباشرةً، والحفاظ على قيم containerTag معزولة لكل مستخدم أو مشروع، والتحقق من السلوك غير المتزامن قبل أن تثق بما يظهره عميل أو وكيل MCP في الدردشة.

مقدمة

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

لهذا السبب تستحق supermemory النظر إليها عن كثب. يضع Supermemory نفسه كطبقة ذاكرة وسياق للذكاء الاصطناعي مع استخراج الذاكرة، وملفات تعريف المستخدمين، والبحث الهجين، والموصلات، ومعالجة الملفات، وخادم MCP للعملاء مثل Cursor، وClaude Code، وVS Code، وWindsurf، وClaude Desktop. يظهر المستودع أيضًا طرق بدء سريعة مثل client.add()، وclient.profile()، وclient.search.memories()، بينما تكشف وثائق API المستضافة عن نقاط نهاية مثل POST /v3/documents، وPOST /v3/search، وPOST /v4/profile.

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

💡

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

زر

لماذا من الأصعب تصحيح أخطاء واجهات برمجة تطبيقات ذاكرة الذكاء الاصطناعي مقارنة بواجهات برمجة التطبيقات القياسية

يظهر خطأ API العادي بسرعة. الاستجابة خاطئة، رمز الحالة خاطئ، أو أن الطلب لم يصل إلى الخدمة أبدًا.

أنظمة الذاكرة مختلفة. يمكنك الحصول على 200 كاستجابة ولا يزال سلوك المنتج خاطئًا لأن السؤال الحقيقي ليس "هل نجح الطلب؟" بل هو:

هل تم استيعاب المحتوى الصحيح؟
هل كان مرتبطًا بالمستخدم الصحيح أو نطاق المشروع؟
هل انتهى استخراج الملف الشخصي قبل الطلب التالي؟
هل استخدم استعلام البحث الوضع والعتبة الصحيحين؟
هل تجاوزت حقيقة أحدث حقيقة أقدم؟
هل مرر عميل MCP نفس حدود السياق الذي استخدمته في اختبارات API الخاصة بك؟

تم بناء Supermemory حول هذه الأجزاء المتحركة بالضبط. يصف المستودع:

استخراج الذاكرة من المحادثات والمستندات
ملفات تعريف المستخدمين مع سياق ثابت وديناميكي
بحث هجين عبر الذكريات والمستندات
موصلات مثل Google Drive، Gmail، Notion، OneDrive، GitHub، وزحف الويب
معالجة الملفات لملفات PDF والصور ومقاطع الفيديو والتعليمات البرمجية
خادم MCP لعملاء الذكاء الاصطناعي

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

هذا هو شكل المشكلة:

تطبيق أو عميل MCP -> استيعاب Supermemory -> تحديث الاستخراج/الملف الشخصي -> استدعاء البحث/الملف الشخصي -> موجه الوكيل -> إجابة مرئية للمستخدم

إذا قمت بالاختبار فقط من طبقة الدردشة، فلا يمكنك معرفة المرحلة الخاطئة. إذا قمت باختبار تدفق API الأساسي في مساحة عمل طلب مشتركة، يمكنك عزل كل مرحلة.

ما يقدمه Supermemory لك جاهزًا للاستخدام

يقوم مستودع supermemory بعمل جيد في إظهار شكل المنتج قبل أن تلمس واجهة برمجة التطبيقات المستضافة.

من ملف README، البدائيات الرئيسية التي يواجهها المطورون هي:

client.add() لتخزين المحتوى
client.profile() لجلب ملف تعريف المستخدم ونتائج البحث الاختيارية
client.search.memories() للبحث الهجين
دعم تحميل المستندات
تكاملات الإطار لأدوات مثل Vercel AI SDK، LangChain، LangGraph، OpenAI Agents SDK، Mastra، Agno، و n8n
نقطة نهاية MCP للمساعدين مثل Claude، Cursor، و VS Code

تضيف الوثائق تفصيلاً مفيدًا: سطح REST مُحدد الإصدارات ومقسم حسب القدرة. تظهر الأمثلة في الوثائق العامة:

POST /v3/documents لاستيعاب المحتوى
POST /v3/search للبحث
POST /v4/profile لاسترجاع الملف الشخصي
POST /v3/documents/file لتحميل الملفات

هذا يعني أن مهمة تصحيح الأخطاء الأولى ليست "تعلم كل ميزة". بل هي "تأمين التدفق الدقيق الذي يستخدمه تطبيقك".

بالنسبة لمعظم الفرق، هذا التدفق هو:

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

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

بناء سير عمل اختبار Supermemory موثوق به

أفضل خطوة أولى هي اختبار Supermemory مباشرة قبل إضافة الأغلفة الخاصة بك أو واجهات الدردشة أو تنسيق الوكيل.

الخطوة 1: حدد استراتيجية النطاق الخاصة بك أولاً

تؤكد وثائق Supermemory وREADME كلاهما على containerTag أو containerTags. تعامل مع ذلك كقرار تصميم أساسي، وليس معلمة ثانوية.

تبدو خطة النطاق النظيفة هكذا:

علامة واحدة للمستخدم، مثل user_123
علامة واحدة للمشروع النشط، مثل project_alpha
قيم منفصلة لمرحلة التطوير والإنتاج

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

الخطوة 2: استوعب مجموعة حقائق معروفة واحدة

استخدم حمولة صغيرة وواضحة أولاً. لا تبدأ بتفريغ PDF ضخم أو مزامنة موصل كامل.

هنا مثال مباشر لواجهة برمجة التطبيقات بناءً على الوثائق العامة:

curl https://api.supermemory.ai/v3/documents \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "content": "User prefers TypeScript, ships API backends, and is debugging rate limits this week.",
 "containerTags": ["user_123", "project_alpha"],
 "customId": "session-001",
 "metadata": {
 "source": "support_chat",
 "team": "platform"
 }
 }'

التفصيل الرئيسي ليس المحتوى نفسه. بل هو أن كل حقل متعمد. أنت تعرف الحقيقة الدقيقة، والنطاق الدقيق، والبيانات الوصفية الدقيقة.

الخطوة 3: استعلام الملف الشخصي بعد الاستيعاب

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

curl https://api.supermemory.ai/v4/profile \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "containerTag": "user_123",
 "q": "What stack does this user prefer?"
 }'

تُظهر الوثائق العامة استجابة تحتوي على:

profile.static
profile.dynamic
searchResults

هذا هو شكل الاستجابة الذي تريده أن يفحصه فريقك قبل أن تقول "يتذكر الوكيل بشكل صحيح".

الخطوة 4: اختبار البحث بشكل منفصل

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

curl https://api.supermemory.ai/v3/search \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "q": "What is the user working on?",
 "containerTag": "user_123",
 "searchMode": "hybrid",
 "limit": 5
 }'

توصي وثائق Supermemory بـ searchMode: "hybrid" عندما تريد سياق الذاكرة والمستند في استعلام واحد. وهذا افتراضي جيد لفرق المنتج لأنه يتطابق مع كيفية عمل مساعدي الذكاء الاصطناعي الحقيقيين: سياق شخصي بالإضافة إلى سياق قاعدة المعرفة، وليس أحدهما أو الآخر.

الخطوة 5: التحقق من افتراضات عدم التزامن

يقوم Supermemory بمعالجة غير متزامنة لتدفقات المستندات والملفات. تُظهر الوثائق معالجة في قائمة الانتظار وسلوكًا قائمًا على الحالة للتحميلات. هذا يعني أن طلبك الثاني يمكن أن يكون "مبكرًا جدًا" حتى عندما نجح الأول.

هذا أحد أسهل أخطاء الذاكرة التي يمكن تفويتها:

استيعاب المحتوى
استعلام الملف الشخصي فورًا
الحصول على نتيجة ضعيفة أو غير كاملة
لوم محرك الذاكرة بدلاً من التوقيت

لهذا السبب يجب أن يتضمن سير عمل الاختبار الخاص بك فترات انتظار قصيرة أو استقصاء حيث يكون سلوك نقطة النهاية غير متزامن.

تحويل Supermemory إلى سير عمل اختبار قابل للتكرار

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

الخطوة 1: إنشاء بيئة Supermemory

أنشئ متغيرات بيئة مثل:

base_url = https://api.supermemory.ai
supermemory_api_key = sm_your_api_key
user_tag = user_123
project_tag = project_alpha
custom_id = session-001

يمنحك هذا طريقة آمنة للتبديل بين المستخدمين التجريبيين والمشاريع ومساحات العمل دون تعديل الطلبات يدويًا.

الخطوة 2: بناء طلب الاستيعاب

أنشئ طلبًا:

الأسلوب: POST
عنوان URL: {{base_url}}/v3/documents
الرأس: Authorization: Bearer {{supermemory_api_key}}
الرأس: Content-Type: application/json
الجسم:

{
 "content": "User prefers TypeScript, ships API backends, and is debugging rate limits this week.",
 "containerTags": ["{{user_tag}}", "{{project_tag}}"],
 "customId": "{{custom_id}}",
 "metadata": {
 "source": "api_workflow_test"
 }
}

ثم أضف التأكيدات مثل:

pm.test("الحالة ناجحة", function () {
 pm.expect(pm.response.code).to.be.oneOf([200, 201, 202]);
});

pm.test("الاستجابة تحتوي على معرف الذاكرة", function () {
 const json = pm.response.json();
 pm.expect(json.id).to.exist;
});

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

الخطوة 3: بناء طلب الملف الشخصي

أنشئ طلبًا ثانيًا:

الأسلوب: POST
عنوان URL: {{base_url}}/v4/profile
الجسم:

{
 "containerTag": "{{user_tag}}",
 "q": "ما هي المجموعة التقنية التي يفضلها هذا المستخدم؟"
}

تأكيدات مفيدة:

pm.test("حمولة الملف الشخصي موجودة", function () {
 const json = pm.response.json();
 pm.expect(json.profile).to.exist;
});

pm.test("تم إرجاع محتوى ملف شخصي ثابت أو ديناميكي", function () {
 const json = pm.response.json();
 const staticItems = json.profile?.static || [];
 const dynamicItems = json.profile?.dynamic || [];
 pm.expect(staticItems.length + dynamicItems.length).to.be.above(0);
});

يسمح لك هذا بفصل ثلاث حالات بسرعة:

لم يحدث الاستيعاب
حدث الاستيعاب لكن المعالجة غير مكتملة
الملف الشخصي موجود لكن استعلامك أو نطاقك خاطئ

الخطوة 4: بناء طلب البحث

أضف طلبًا ثالثًا لجودة الاسترجاع:

{
 "q": "ماذا يصحح المستخدم؟",
 "containerTag": "{{user_tag}}",
 "searchMode": "hybrid",
 "limit": 5
}

تتضمن الفحوصات الجيدة:

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

تعتبر أداة سير عمل API المشتركة مفيدة بشكل خاص هنا لأنه يمكنك استنساخ نفس الطلب ومقارنة:

searchMode: "hybrid" مقابل سلوك الذاكرة فقط
containerTag واحد مقابل آخر
عتبة أقل مقابل عتبة أعلى
استعلام قصير مقابل استعلام لغة طبيعية صاخبة

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

الخطوة 5: تحويل الطلبات إلى سيناريو

هذه هي أعلى ترقية لسير العمل قيمة لـ Supermemory.

قم بإنشاء سيناريو اختبار يقوم بما يلي:

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

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

الخطوة 6: توثيق سير العمل للفريق

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

إذا قمت بنشر سير العمل في Apidog، يمكن للجميع فحص:

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

تنزيل Apidog مجانًا

أين يتناسب MCP مع حلقة تصحيح الأخطاء

يتضمن Supermemory مسار تثبيت سريع لـ MCP ويعرض عنوان URL لخادم MCP المستضاف. وهذا مفيد لتوصيل Claude أو Cursor أو Windsurf أو VS Code بسرعة، لكن MCP ليس المكان المناسب لبدء تصحيح الأخطاء.

إذا تذكر مساعدك شيئًا خاطئًا، اعمل بهذا الترتيب:

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

لماذا؟ لأن MCP يضيف طبقة تجريدية أخرى. يمكن أن تأتي نتيجة الاستدعاء السيئة من:

مفتاح API خاطئ أو وضع المصادقة
حد نطاق خاطئ
استيعاب قديم أو غير مكتمل
سلوك استدعاء أداة خاص بالعميل
تعليمات موجهة تسيء استخدام مخرجات الذاكرة

يظهر README الخاص بـ Supermemory أيضًا نمط تكوين MCP يدويًا مثل هذا:

{
 "mcpServers": {
 "supermemory": {
 "url": "https://mcp.supermemory.ai/mcp"
 }
 }
}

إذا كان مسار العميل هذا يتصرف بغرابة، فإن أسرع استراتيجية عزل هي إعادة إنتاج سلوك الذاكرة الأساسي عبر HTTP API أولاً.

التقنيات المتقدمة والأخطاء الشائعة

هنا هي الأخطاء الأكثر أهمية في الإنتاج.

1. خلط النطاقات

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

2. اختبار المسار الصحيح فقط

يجب عليك أيضًا اختبار:

استعلام ملف شخصي قبل الاستيعاب
استعلام ملف شخصي فورًا بعد الاستيعاب
عمليات بحث باستعلام ضعيف
عمليات بحث بعلامة مشروع خاطئة
تحميلات لا تزال قيد المعالجة

3. معاملة الملف الشخصي والبحث على أنهما قابلان للتبديل

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

4. تجاهل اختلافات الإصدارات

يركز ملف README للمستودع على طرق SDK، بينما تُظهر الوثائق نقاط نهاية HTTP ذات إصدارات مثل /v3 و /v4. قم بتأمين الإصدار الدقيق الذي يعتمد عليه فريقك، ثم اِعكس ذلك في سير عمل اختبار API الخاص بك.

5. تخطي اختبارات التحديث والتناقض

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

البدائل والمقارنة

هناك ثلاث طرق شائعة للعمل مع Supermemory أثناء التطوير.

النهج	جيد لـ	نقطة الضعف
SDK فقط	النماذج الأولية المحلية السريعة	صعوبة فحص سلوك HTTP الدقيق
cURL والسكريبتات	فحص نقاط النهاية قليل الاحتكاك	صعوبة إعادة الاستخدام والمشاركة والمقارنة مع مرور الوقت
سير عمل API مشترك	تصحيح الأخطاء الجاهز للفريق، التأكيدات، الوثائق، السيناريوهات	يتطلب بعض الإعداد المسبق

لهذا السبب تتناسب أداة مثل Apidog بشكل جيد إلى جانب Supermemory بدلاً من استبدالها. يمنحك Supermemory محرك الذاكرة. تمنحك طبقة سير العمل طريقة قابلة للتكرار للتحقق من سلوك API للمحرك قبل أن يصبح هذا السلوك جزءًا من منتج ذكاء اصطناعي أكبر.

حالات الاستخدام في العالم الحقيقي

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

يرغب فريق المنتج الذي يستخدم Cursor أو Claude Code مع MCP في ذاكرة المساعد عبر المشاريع الطويلة. قبل الثقة بتجربة الدردشة، يجب على الفريق التحقق من الاستيعاب، وحدود النطاق، وجودة الاسترجاع مباشرة مقابل واجهة برمجة التطبيقات.

يحتاج فريق المنصة الذي يقوم بمزامنة المستندات من GitHub أو Notion إلى تأكيد سلوك البحث الهجين قبل تمكينه للوكلاء الداخليين. يساعد سير عمل الاختبار المنظم في مقارنة الاستعلامات الثقيلة بالوثائق مقابل الاستعلامات الثقيلة بالذاكرة في نفس المجموعة.

الخلاصة

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

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

زر

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

ما هو استخدام Supermemory؟

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

هل يمتلك Supermemory واجهة برمجة تطبيقات REST؟

نعم. تُظهر الوثائق العامة نقاط نهاية HTTP ذات إصدارات للمستندات والبحث واسترجاع الملفات الشخصية وتحميلات الملفات، بينما يعرض README أيضًا طرق SDK التي تتوافق مع هذه القدرات.

لماذا من الأصعب تصحيح أخطاء واجهة برمجة تطبيقات ذاكرة الذكاء الاصطناعي مقارنة بواجهة برمجة تطبيقات عادية؟

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

ماذا يجب أن أختبر أولاً في Supermemory؟

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

هل يمكن لأداة سير عمل API أن تساعد إذا كان تطبيقي يستخدم MCP؟

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

ما هو أهم معلمة في Supermemory يجب ضبطها بشكل صحيح؟

containerTag أو containerTags هي واحدة من أهم المعلمات لأنها تتحكم في كيفية تجميع الذكريات واسترجاعها. استراتيجية الوسم الضعيفة تخلق نتائج صاخبة حتى لو نجح الاستيعاب والبحث كلاهما.