كيفية تقييم الأنظمة متعددة الوكلاء

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

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

يعني النظام متعدد الوكلاء هنا سير عمل مدفوعًا بـنموذج لغوي كبير تتبادل فيه وكلاء متمايزة، لكلٍّ منها دور، الرسائلَ وتُسلّم بعضها التحكمَ لبعض. ويجد البحث في أسباب إخفاق هذه الأنظمة (تصنيف MAST، Why Do Multi-Agent LLM Systems Fail?) أن نصيبًا كبيرًا من الإخفاقات يقع بين الوكلاء: مشكلات في المواصفات، وعدم مواءمة بين الوكلاء، وغياب التحقق. ويخفي النص المسطّح هذه بالضبط.

لماذا لا يكفي تقييم الوكيل المفرد؟

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

فقد التسليم: يعرف الوكيل A قيدًا لا يصل الوكيلَ B أبدًا.
سوء العزو: يُخفق التشغيل، لكن الوكيل المسؤول يقع قبل موضع ظهور الخطأ.
إخفاق التنسيق: كل وكيل كفؤ على حدة، ومع ذلك يدور الفريق في حلقة، أو يتوقف، أو لا يتحقق أبدًا.
تنازع الموارد: يلمس وكيلان الأداة أو الملف نفسه في آنٍ واحد فيقعان في deadlock.

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

كيف أعزو إخفاقًا متعدد الوكلاء؟

تصوغ أدبيات عزو الإخفاق (Zhang وآخرون، Which Agent Causes Task Failures and When?، ICML 2025) التصنيف بوصفه ثلاثيًّا: الوكيل المسؤول، والخطوة الحاسمة، والسبب. وفي Potato يملأ مخطط failure_attribution مُنتقيَي الوكيل والخطوة من الأثر نفسه، فيختار المُعلّق من بين وكلاء وخطوات حدثت فعلًا:

yaml

annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

يعني اقتران مخطط النتيجة بالعزو أن الثلاثي لا يُجمَع إلا في التشغيلات التي أخفقت فعلًا.

كيف أراجع بنية الفريق، لا النص وحده؟

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

yaml

annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

أما للتقييم، فتقيّم agent_scorecard كل وكيل من حيث الوفاء بالدور والإسهام والتنسيق، وتسجّل درجة الفريق وفق أبعاده الخاصة، فيظهر في الأرقام وجودُ وكيل فردي قوي داخل فريق رديء التنسيق.

أي طريقة ينبغي أن أستخدم؟

تصحيح خط أنابيب: ابدأ برسم التفاعل البياني وعزو الإخفاق لتحديد موضع انكسار التشغيلات.
مقارنة أنماط التنسيق: أضِف بطاقة التقييم لتسجيل درجة التصاميم التتابعية مقابل الهرمية مقابل الدردشة الجماعية على المهام نفسها.
بناء بيانات تدريب أو مكافأة: وسِم الإخفاقات بدقّة الخطوة بأنماط MAST (عبر trajectory_eval) كي تلتصق التصنيفات بالوكيل الفاعل والخطوة.
عِلل التزامن: استخدم الخط الزمني لتنازع الأدوات لالتقاط حالات الـ deadlock وسباقات الوصول التي لا يستطيع النص إظهارها.

قِس الاتفاق على العزو بالطريقة نفسها التي تتبعها مع أي تصنيف ذاتي؛ انظر الاتفاق بين المُعلّقين.

قراءات إضافية

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