الفصل 14 — المقارنة والاختبار والأداء
المقالة الخامسة عشرة والأخيرة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. حيث يجب على المعمارية أخيراً الإجابة على السؤال غير العاطفي — هل يَعمل النظام فعلاً؟ — وتَأتي الإجابة عبر معاييرَ حقيقية، وضعيَتَي فشلٍ نظاميتَين، وهاوية إنتاجيةٍ بعشرة أضعاف يَكتشفها مُعظم الفِرَق يوم إطلاق الإنتاج.
لماذا يوجد هذا الفصل
بروتوكولٌ صُمِّم بعناية، صُلِّبَ أمنياً، وغُلِّفَ نظيفاً في إطارٍ ما زال عليه الإجابة على السؤال غير العاطفي: هل النظام يَعمل فعلاً؟ هل يَحلّ الوكيل المهام التي بُني لها؟ هل يَصمد حين يَتضاعف الحِمل؟ أين هاويات الأداء التي تُحَوِّل التَدَهور اللطيف إلى انقطاع؟ كانت الفصول السابقة عن صحة المعمارية؛ هذا الفصل عن قياس هل تُسَلِّم المعمارية، حالما تُبنى. يَمشي على معيار MCP-Universe — أول حزام اختبارٍ عام يُمارس نماذج لغوية حقيقية ضد خوادم MCP حقيقية — وضعيَتَي الفشل النظاميتَين اللتَين كَشَفهما المعيار والتخفيفات التي بَدَأت تَعمل، وجانب الإنتاجية حيث الفجوة بين بِركة جلساتٍ مهندَسةٍ جيداً والنمط الساذج لكل طلبٍ من رتبة الحجم.
14.1 MCP-Universe: قياس الوكلاء على خوادمٍ حقيقية
لمُعظم 2024 وأوائل 2025، سَكَن تقييم الوكلاء العام في مكانٍ غريب. معايير استخدام الأدوات قاسَت هل تُصدر النماذج استدعاءاتٍ صحيحة نحوياً ضد APIs اصطناعية. ومعايير الوكلاء قاسَت إكمال المهام في بيئاتٍ صندوقية. ما كان مفقوداً معيارٌ يُمارس النماذج ضد خوادم MCP حقيقية بمصادقةٍ حقيقية، حدود معدلٍ حقيقية، مخططاتٍ حقيقية تَنجرف، أدواتٍ حقيقية تُعيد أحياناً نتائج فارغة. MCP-Universe، أصدرته Salesforce AI Research في 2025، كان أول محاولةٍ جدية. ستة مجالات تقييمٍ تَمتدّ عبر أحد عشر خادم MCP إنتاجي حقيقي — Google Maps وGitHub وYahoo Finance وBlender وPlaywright ومحركات بحثٍ حقيقية — و231 مهمة، لكلٍّ مُقَيِّمٌ آلي يَفحص هل تُطابق الحالة النهائية النتيجة المتوقعة بدلاً من هل أصدر النموذج استدعاءات الأدوات «الصحيحة» على الطريق.
النتيجة الرئيسة صَمَدَت عبر تَحديثات النماذج. Claude 3.5 Sonnet، الذي يُسَجِّل في الثمانينات على المعايير الاصطناعية، بَلَغ فقط الأربعينات المنخفضة إلى المتوسطة على MCP-Universe إجمالاً. تَجَمَّعَت GPT-4o وGemini 1.5 Pro ونُسَخ Llama-3 70B في إقليمٍ مشابه. الفجوة بين أداء استخدام الأدوات في حلقةٍ مغلقة والأداء على MCP الحقيقي قرابة أربعين نقطة مطلقة، والمقياس وحده لم يُغلقها. تَتجَمَّع الإخفاقات في فئاتٍ معروفة: تَدَهور السياق الطويل مع امتلاء النافذة بنواتج الأدوات؛ اِستكشاف الأدوات المجهولة مع سوء قراءة النموذج للمخططات غير المألوفة؛ التنسيق عبر الخوادم حيث تَتعارض تنسيقات النواتج ولا يَوجد جسرٌ دلالي؛ والاستدلال الخاص بالمهمة حيث يَختار النموذج الأداة الصحيحة، يَستدعيها صحيحاً، يَستلم الإجابة الصحيحة، ومع ذلك يَصل إلى الاستنتاج النهائي الخطأ لأنه فَشِل في دمج ناتج الأداة في الاستدلال الأوسع. القرارات البنيوية التي تَجعل MCP-Universe أداةً جدية هي التقييم القائم على التنفيذ (تشغيل الاستدعاءات ضد خوادم حقيقية، لا المقارنة بأثر مرجعي)، بياناتٌ في الزمن الحقيقي (بيانات سوقٍ حية، مع مُقَيِّمٍ يَتعقَّب ما كانت الإجابة وقت التشغيل)، وتقييمٌ متعدد الأدوار (تَدريج الحالة النهائية، لا كل خطوة). أثرٌ جانبي مفيد: المعيار يَعمل بوصفه إشارة جودةٍ غير مباشرة على تصميم الخادم، ومؤلِّفو الخوادم الذين يَهتمون بأداء الوكلاء لديهم الآن هدفٌ عام.
14.2 التحديان النظاميان وما يَعمل
تَدَهور السياق الطويل واِستكشاف الأدوات المجهولة هما وضعيَتا الفشل الكبيرتان بقدرٍ يَستحقّ معالجةً عناية، لأن التخفيفات غير بَدَهية. لتَدَهور السياق الطويل في وكلاء MCP شكلٌ بعينه: يَمتلئ السياق بنواتج أدواتٍ كلها ذات صلةٍ بمعنى ما — كلٌّ كان نتيجة استدعاءٍ اختار النموذج إجراءه — لكن كلٌّ ضخم والحقيقة الفعلية الحاملة للحِمل داخل كلٍّ صغيرة. تَعمل التخفيفات على مستوى عرض المعلومات. تلخيص نتائج الأدوات يُشَغِّل نموذجاً رخيصاً (Haiku، GPT-4o-mini، Gemini Flash) فوق ناتج الأداة الخام قبل أن تَهبط النتيجة في سياق الوكيل؛ النشر الإنتاجي يُبَلِّغ بتحسينٍ ضِعفَين إلى ثلاثة في معدلات إكمال السياق الطويل، وكلفة كل استدعاءٍ يَهيمن عليها النموذج الرخيص. ناتج أداةٍ مهيكَل بحقل summary جنباً إلى جنب مع حمولة JSON — مُقَنَّن في مراجعة بروتوكول 2025 — يَفعل عملاً مشابهاً دون استدعاء نموذجٍ إضافي. كَبس السياق على حلقة الوكيل، مُقترناً بلوحٍ يُديره الوكيل يَنجو من الكَبس حرفياً، يُعالج الحالة حيث نَمَت المحادثة ذاتها طويلةً جداً؛ النشر الإنتاجي يُطلق الكَبس كل عشرين إلى أربعين خطوة ويَحفظ قرابة الثلث من السياق الأصلي.
لاستكشاف الأدوات المجهولة شكلٌ مختلف. حين يَتصل وكيلٌ بخادمٍ بأدواتٍ لم يُدرَّب عليها، تَفشل استدعاءاته الأولى غالباً — أنواعٌ خاطئة، ترتيبٌ خاطئ، أحياناً أداة خاطئة كلياً. التخفيف مرحلة استكشاف قبل الحلقة الرئيسة: يَطلب الإطار من النموذج قراءة وصف كل أداة، تَلخيص ما تَفعله، توليد استدعاء مثالي، والإشارة إلى المعاملات التي ليس متأكداً منها. الملاحظة الناتجة تُلصَق ببداية سياق الوكيل. الكلفة بضعة استدعاءاتٍ رخيصة عند بدء الجلسة؛ والفائدة عشرون إلى ثلاثون نقطة مئوية من تحسين الإكمال على معاييرَ مثل MCP-Universe وسجلٌّ قابلٌ للتدقيق لفَهم الوكيل المُعلَن يُساعد على إسناد الإخفاقات اللاحقة. النمط يَمتدّ للأدوات المُتَغَيِّرة: هَش سطح الأداة عند الاتصال، شَغِّل التَدفئة كلما تَغَيَّر الهَش، وتَختفي وضعية فشل الانجراف الصامت (الخادم حُدِّث، الوكلاء يَفشلون لأسابيع قبل أن يُلاحظ أحد). موضوعٌ ثالث متعلق جدير بالتسمية: جودة وصف الأداة. شَحَنَت كثيرٌ من الخوادم أوصافاً مكتوبةً لمطوِّرين بشر — مُقتضبة، مُحَمَّلة بمصطلحات، تَفترض السياق. الخوادم التي أُعيدت كتابتها كأنها لمتدرِّبٍ لم يَر النظام قطّ تُظهر تحسناتٍ قابلة للقياس مقابل النماذج ذاتها دون تغيير شيفرة الوكيل. نافذة النموذج الوحيدة على الأداة هي الوصف، ووصفٌ لا يَقف وحده يُنتج نموذجاً لا يَستطيع استخدام الأداة.
14.3 هاوية إنتاجية بِركة الجلسات
الصحة نصف القصة؛ الواقع الإنتاجي أن قرارات التصميم التي تَجعل وكيلاً سريعاً غالباً لها آثارٌ على الصحة والعكس. أكبر مشكلة إنتاجيةٍ مفردة في نشر MCP لـ2025–2026 هي الفجوة بين طريقتَين لإدارة جلسات HTTP القابل للبث، والفجوة عشرة-إلى-واحد تقريباً. الجلسة-لكل-طلب تَفتح جلسةً جديدة لكل طلب وكيل، تُجري استدعاءات الأدوات داخلها، وتُغلقها عند الاكتمال. بِركة جلساتٍ مُشتركة تَحتفظ ببِركة جلساتٍ طويلة العمر وتُسنِد كل طلبٍ إلى واحدةٍ منها. فرق الإنتاجية على خادمٍ قياسي بحِمل عمل تَمثيلي يَهبط ثباتاً حول عشرة أضعاف — قرابة ثلاثين طلباً في الثانية للجلسة-لكل-طلب، قرابة 290 إلى 300 للبِركة، على عتادٍ تجاري. الفِرَق غير الواعية بالفجوة تَكتشفها بالطريقة الصعبة: التَهيئة تَجري جيداً، إطلاق الإنتاج يَصطدم بجدارٍ عند معدل الطلب حيث يَهيمن عبء إنشاء الجلسة.
الآلية مباشرة. إنشاء الجلسة مُكَلِّف — تخصيص حالة، تَفاوض قدرة، تَحقُّق اعتماد، تسجيل تنظيف، تسجيل مهيكَل — ومصافحة مستوى MCP تُضيف ذهابات-وإيابات بروتوكولية لا يَستطيع النقل تَجَنُّبها. الجلسة-لكل-طلب تَدفع هذه الكلفة في كل طلبٍ مفرد؛ والبِركة تَدفعها مرةً لكل جلسةٍ وتُوَزِّع. تفاصيل التنفيذ التي تُقَرِّر هل تَعمل البِركة عملياً: العزل (حالة كل طلبٍ سياقٌ فرعي داخل الجلسة، يُنشأ ويُدمَّر لكل طلب، بينما حالة كل جلسةٍ مُشتركة)، تحديد حجم البِركة (عدد التَزامن p95 مع تَمدُّدٍ تلقائي للدفعات)، فحص الصحة (فحوصاتٌ خلفية على الجلسات الخاملة، فحوصاتٌ سريعة على الإسناد)، وتَقَارُب الطلب عبر جلساتٍ لاصقة للأدوات التي حالتها تَمتدّ عبر استدعاءاتٍ متعددة. مُلصَقاً فوق، تَعَدُّد قنوات اتصال HTTP/2 أو HTTP/3 — اتصالٌ كامن واحد يَحمل تيارات متزامنة كثيرة — يُنتج أرقام الإنتاجية المُستشهَد بها؛ طبقة البِركة وحدها تُنتج تحسناً أصغر بكثير. بُعد الذيل-الكَموني يَهُمّ أيضاً: خادم الجلسة-لكل-طلب لديه كَمونات ذيلٍ طويلة من لحظاتٍ غير سعيدة خلال الإنشاء، البِركة لديها ضَيِّقة لأن كلفة الإنشاء غير متزامنةٍ خارج المسار الساخن للطلب. p99 يَتحسَّن عادةً ثلاثة أو أربعة أضعاف — مكسبٌ أكبر من الإنتاجية، والذي يُشَكِّل فعلاً تجربة المستخدم.
14.4 ماذا بَنَت السلسلة
المُجَلَّدات الأربعة مَشَت قَوساً متعمَّداً. كان المُجَلَّد الأول عن داخل النموذج. والثاني عن الموجِّهات والاستدلال. والثالث عن التوليد المُعَزَّز بالاسترجاع. وهذا المُجَلَّد عن الوكلاء والأدوات، مُنَظَّماً حول MCP لأن MCP القاعدة التقنية التي جَعَلَت معمارية الوكلاء متماسكة. ثلاثة خيوطٍ جَرَت عبره. الأول فصل الإدراك عن العمليات: النموذج طبقة الإدراك، والإطار وخوادم MCP طبقة العمليات، ومُعظم إخفاقات الإنتاج تأتي من جمعهما معاً. الثاني الميزانية السياقية المنتهية: السياق مَوردٌ شحيح، والاختيارات المعمارية التي تُنتج وكلاء موثوقين هي التي تَحترم هذا الشُّحّ. الثالث البروتوكول-كحدود: MCP ليس فقط صيغة سلكٍ بل حدودٌ تَتدفَّق عبرها القدرات، يجب التَفاوض على الثقة، وسيَستمرّ التطوُّر المستقبلي بالحدوث. بروتوكولٌ يَصمد تحت الضغط الهندسي يَصير بنية تحتية؛ ويَبدو MCP يَفعل كذلك.
ماذا يُمَهِّد له المُجَلَّد الرابع
هذا آخر فصل المُجَلَّد، فما يُمَهِّد له ليس الفصل التالي بل المُجَلَّد التالي. المُجَلَّد الخامس — بناء تطبيقات LLM في العالم الحقيقي — يَأخذ الأُسُس المُوضوعة عبر المُجَلَّدات الأول إلى الرابع ويَجمعها في أنماط تطبيقاتٍ بعينها: مُساعدات لهندسة البرمجيات، وكلاء لأتمتة الأعمال، مُساعدات داخل تطبيقاتٍ عمودية، أدوات بحثٍ مستقلة. ستكون المعالجة أقل عن الآليات الكامنة (التي غَطَّتها المُجَلَّدات السابقة) وأكثر عن الاختيارات الهندسية على مستوى التطبيق — كيف تُحَدِّد نطاق تطبيق LLM ليُسَلِّم القيمة موثوقاً، كيف تُقَيِّمه إنتاجياً، كيف تُدير دورة حياة الموجِّهات والأدوات والذاكرة مع تطوُّر التطبيق. القارئ الذي يُنهي المُجَلَّد الخامس سيكون قد مَشى الطريق من رأس انتباهٍ مفرد إلى تطبيقٍ منشورٍ يُمارس وكيلاً على كومة خوادم MCP حقيقية على بنيةٍ تحتية حقيقية، بحُكمٍ هندسي يَعرف لماذا بُنيت كل طبقةٍ بالطريقة التي بُنيت بها.
تَستمرّ السلسلة في LLM Primer V — بناء تطبيقات LLM في العالم الحقيقي.