ما الذي ينكسر فعلاً عند توسيع سرب وكلاء LLM

مشكلة التنسيق ليست النموذج

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

الوكيل الواحد هو حلقة. أما السرب فهو نظام موزّع بعُقد غير موثوقة تتواصل باللغة الطبيعية. هذا التأطير الثاني هو الذي يتنبأ بأنماط الفشل بدقة.

لماذا تكون عمليات التسليم باللغة الطبيعية هشّة

عندما يسلّم وكيل عملاً إلى آخر، يكون التسليم عادةً نصاً غير مُهيكل. هذا مريح أثناء النماذج الأولية ومكلف في الإنتاج لثلاثة أسباب.

أولاً، عمليات التسليم باللغة الطبيعية فاقدة للمعلومات. يجب على الوكيل المستقبِل أن يستنتج النية من جديد من النص. إذا أغفل الوكيل المُرسِل قيداً ما، فلا يمكن للمستقبِل استعادته. لا يوجد مخطط (schema) للتحقق منه.

ثانياً، هي غير حتمية. يمكن تفسير المخرجات نفسها من المنبع بشكل مختلف بين التشغيلات، مما يجعل الفشل صعب الاستنساخ.

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

الحل ليس إلغاء اللغة الطبيعية. بل تقييد سطح التسليم. عرّف مغلفاً مُنمّطاً (typed envelope) للرسائل بين الوكلاء: معرّف المهمة، والمنتَج (artefact)، والقيود الواجب تحققها، وحالة صريحة. يمكن أن يعيش نص الوكيل داخل حقل، لكن المغلف هو ما يوجّهه المنسّق (orchestrator) ويتحقق منه.

آلية ملموسة: المغلفات المُنمّطة وبوابات التحقق

تخيّل خط أنابيب للبحث والصياغة يتكوّن من مخطط (planner)، وعدة أدوات استرجاع (retrievers)، ومُركّب (synthesiser)، وناقد (critic). بدون هيكلة، يستقبل المُركّب كومة من النصوص ويخمّن ما يهم.

مع المغلفات المُنمّطة، يبدو التدفق هكذا:

{
  "task_id": "r-014",
  "produced_by": "retriever-2",
  "status": "partial",
  "artefact": { "claims": [ { "text": "...", "source": "..." } ] },
  "constraints": ["no claims without a source", "max 12 claims"],
  "missing": ["coverage of the cost dimension"]
}

لا يقرأ المنسّق النص. بل يقرأ status وconstraints وmissing. إذا كانت status هي partial، يمكنه إعادة إرسال البُعد المفقود بدلاً من تمرير منتج متدهور إلى الأمام. لا يستقبل المُركّب إلا المغلفات التي تحققت قيودها.

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

خيارات الطوبولوجيا وتكاليفها

لا يوجد شكل سرب صحيح عالمياً. ثلاثة أشكال شائعة، وكل منها يتنازل عن شيء.

نمط المشرف (Supervisor). وكيل منسّق واحد يوزّع على العمال ويجمّع النتائج. سهل الاستدلال، وسهل التسجيل، ويركّز معالجة الفشل. التكلفة هي عنق الزجاجة: يجب أن تحمل سياق المشرف ما يكفي للتوجيه الصحيح، ويصبح نقطة الفشل الوحيدة التي تنتشر أخطاؤها في كل مكان.

نمط خط الأنابيب (Pipeline). الوكلاء متسلسلون، كل منهم يحوّل مخرجات السابق. بسيط وقابل للتنبؤ. التكلفة هي الهشاشة: خطأ مبكر يتراكم، ولا يوجد فرع لامتصاصه. تناسب خطوط الأنابيب التحويلات محددة المواصفات، لا البحث المفتوح.

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

عملياً، معظم أنظمة الإنتاج هي مشرف مع مغلفات مُنمّطة وخط أنابيب فرعي أو اثنين متخصصين، لا شبكة متصلة بالكامل.

المقايضة الصادقة: التوازي يشتري زمن الاستجابة ويكلّف التماسك

تشغيل الوكلاء بالتوازي يقلل الزمن الفعلي ويزيد الإنتاجية. كما يزيل السياق التسلسلي الذي يسمح لوكيل لاحق برؤية ما تعلّمه وكيل سابق. قد تعيد أداتا استرجاع تعملان بالتوازي ادعاءات متداخلة أو متناقضة؛ كان التس

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

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

يجب أن يستهدف التقييم نقاط الوصل

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

النهج العملي هو التقييم على ثلاثة مستويات.

• مستوى الوكيل. هل يحقق الوكيل عقده الخاص عند إدخال جيد التكوين؟ هذا الأسهل اختباراً والأقل تنبؤاً بسلوك النظام.
• مستوى التسليم. عند إدخال مغلفات منبع مسجّلة، هل ينتج الوكيل في المصب مغلفاً يحقق قيوده المعلنة؟ هذا يلتقط انحراف المخطط والفشل الجزئي الصامت.
• مستوى المسار (Trajectory). عند إدخال مهمة كاملة، هل يصل النظام إلى نتيجة مقبولة ضمن عدد محدود من الخطوات والرموز؟ هنا تُختبر الطوبولوجيا وسياسة الدمج فعلياً.

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

ما الذي يجب بناؤه أولاً

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

1. أدخل مغلفات مُنمّطة لكل رسالة بين الوكلاء. هذا وحده يجعل الأعطال مرئية.
2. أضف بوابات تحقق عند كل تسليم، مع حالة partial صريحة ومسار إعادة إرسال.
3. عرّف سياسة دمج للفروع المتوازية، بما في ذلك كيفية كشف التعارضات وحلها.
4. جهّز أثراً مُهيكلاً لكل مغلف حتى يمكن إعادة تشغيل الجولات.
5. عندها فقط اضبط الـ prompts أو استبدل النماذج.

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

الخاتمة

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