الفصل السابع: تقييم الوكلاء

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

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

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

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

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

يستحق نظام التقييم قيمة أكبر في عصر التطور السريع للنماذج. تستمر النماذج في التحسن، لكن النموذج الجديد الذي يحقق درجات أعلى في المعايير العامة لن يؤدي بالضرورة إلى أداء أفضل في مهمتك - بل قد يتراجع (يؤدي أداء أسوأ من الإصدار القديم في بعض النواحي). يتيح لك التشغيل الكامل لمجموعة بيانات التقييم الخاصة بك فقط اتخاذ قرار ترقية يعتمد على البيانات. بل إن نظام التقييم القوي يجعل من “بناء المنتجات للنماذج المستقبلية” استراتيجية قابلة للتطبيق: إذا لم يكن النموذج الحالي جيدًا بما يكفي للنشر التجاري، فقم بإنهاء المنتج على أي حال، وقم ببناء مجموعة التقييم، وتتبع أداء كل نموذج جديد، وقم بتشغيله في اللحظة التي يتخطى فيها النموذج الشريط. يمكن تفكيك منظومة التقييم إلى أربع حلقات: ما الذي يُعد نجاحًا، ومن أين تأتي المهام، ومن الذي يتحقق، وكيف تتحول الدرجة إلى قرار. يوضح ذلك الشكل 7-1.

تشريح مهمة تقييم واحدة: نطاق telecom في τ²-bench

لنبدأ بتشريح مهمة حقيقية واحدة من نطاق telecom في τ²-bench تشريحًا كاملًا. إن τ²-bench مشروع مفتوح المصدر من Sierra؛ استنسخه محليًا بالأمر الوارد في chapter7/tau2-bench-eval/README.md، ثم افتح ملف المهام data/tau2/domains/telecom/tasks_small.json.

المكوّنات الأربعة لتعريف المهمة

فيما يلي إحدى المهام من ذلك الملف، مختصرةً تسهيلًا للقراءة.

{
  "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off",

  // التذكرة المسلَّمة إلى الوكيل
  "ticket": "هاتف المستخدم لا يتصل بالإنترنت، وشريط الحالة يعرض 'No Service'.
             العميل John Smith، الرقم 555-123-2002، وهو حاليًا في فرنسا. لا
             تُعد المشكلة محلولة إلا إذا أعاد اختبار السرعة النتيجة excellent.
             لا يريد تغيير الباقة، لكنه مستعد لشحن 2.0 غيغابايت عند اللزوم.",

  // ضوابط السلوك المسلَّمة إلى محاكي المستخدم
  "user_scenario": { "instructions": {
      "known_info": "You are John Smith with phone number 555-123-2002.
                     You are currently abroad in France.",
      "unknown_info": null,
      "task_instructions":
        "…express mild frustration after the first unsuccessful attempt.
         You will consider the issue resolved only when speed test returns
         excellent internet speed and nothing else. If it returns poor, fair
         or good, you will not consider the issue resolved.
         Whenever the agent asks you about your device, always ground your
         responses on the results of tool calls. …
         Never make up the results of tool calls."
  }},

  // قبل التشغيل تُعاد حالة الطرفين إلى نقطة البداية نفسها
  "initial_state": { "initialization_actions": [
      { "env_type": "user",      "func_name": "turn_airplane_mode_on" },
      { "env_type": "user",      "func_name": "turn_roaming_off" },
      { "env_type": "assistant", "func_name": "enable_roaming",
        "arguments": { "customer_id": "C1001", "line_id": "L1002" } }
  ]},

  // معايير التقييم
  "evaluation_criteria": {
      "actions": [
        { "requestor": "user", "name": "toggle_airplane_mode" },
        { "requestor": "user", "name": "toggle_roaming" }
      ],
      "env_assertions": [
        { "func_name": "assert_mobile_data_status", "expected_status": true },
        { "func_name": "assert_internet_speed",
          "expected_speed": 200, "expected_desc": "excellent" }
      ],
      "communicate_info": null,
      "nl_assertions": null,
      "reward_basis": ["ENV_ASSERTION"]
  }
}

في هذا التعريف أربعة قرارات تصميمية تستحق الشرح.

حدود معرفة المستخدم مُنمذَجة صراحةً. يحتوي known_info على ثلاث معلومات فقط: الاسم ورقم الهاتف وبلد الإقامة. أما السببان الحقيقيان للعطل — تشغيل وضع الطيران وإيقاف تجوال البيانات — فليسا هناك. المستخدم لا يعلمهما فلا يستطيع ذكرهما من تلقاء نفسه، والوكيل لا سبيل له إلى معرفتهما إلا بالسؤال وبتوجيه المستخدم إلى الفحص. هكذا يتحقق الكشف التدريجي للمعلومات (Progressive Information Disclosure) على مستوى تعريف المهمة: لا بتقييد المحاكي بموجّه يقول «لا تكشف كل شيء دفعة واحدة»، بل بنمذجة نطاق معرفة المستخدم بوصفه حقلًا مستقلًا. معظم المعايير المرجعية تعرض المتطلب كاملًا في بداية المهمة، بينما أول ما ينطق به مستخدم حقيقي عادةً لا يتعدى «لا أستطيع الدخول إلى الإنترنت». وتوضيح الطلب إلى الحد الذي يصبح فيه قابلًا للتنفيذ هو نفسه جزء مما ينبغي أن يجيده الوكيل.

المحاكي يتلقى ضوابط سلوك لا نصًا حواريًا. يجمع task_instructions ثلاثة أنواع من القيود: ضبط انفعالي (إظهار امتعاض خفيف بعد أول محاولة إصلاح فاشلة)، ومعيار قبول (لا تُعد المشكلة محلولة إلا إذا أعاد اختبار السرعة excellent؛ أما poor وfair وgood فمرفوضة جميعًا)، وشرط الترسيخ الواقعي (Grounding)، أي أن يستند كل جواب عن حالة الجهاز إلى القيمة التي تُعيدها أداة: «Never make up the results of tool calls». والثالث هو الأهم: من دون قيد الترسيخ ينساق المستخدم المحاكى وراء توجيه الوكيل فيؤكد أن المشكلة حُلّت، فينحدر التقييم إلى مصادقة نموذجين أحدهما على الآخر.

الحالة الابتدائية مقسومة بحسب الطرف المتحكم. يأخذ env_type قيمتين، user وassistant: وضع الطيران ومفتاح التجوال يخصّان جانب المستخدم، بينما enable_roaming في جانب المشغّل يخص جانب الوكيل. هذا التقسيم هو ما يحدد شكل العطل: التجوال مفعَّل لدى المشغّل لكنه مغلق على جهاز المستخدم، فلا يحصل الوكيل من استعلام قاعدة البيانات إلا على نتيجة «الإعدادات سليمة». العطل يقع في الجانب الذي لا تراه قاعدة البيانات، ولا ينكشف إلا بتوجيه المستخدم إلى الفحص.

معايير التقييم موزَّعة على أربع طبقات، وهذه المهمة لا تستخدم منها إلا طبقة واحدة. يتحقق env_assertions من الحالة النهائية (بيانات الجوّال متاحة، والسرعة 200 ميغابت/ثانية فأكثر بتصنيف excellent)، ويتحقق actions من وقوع الأفعال المفتاحية ومن أي الطرفين نفّذها، بينما يتحقق communicate_info وnl_assertions من إبلاغ المستخدم بالمعلومات اللازمة. أما reward_basis في هذه المهمة فلا يعلن إلا ENV_ASSERTION؛ وتُحسب الطبقات الأخرى وتُسجَّل كالمعتاد لكنها لا تدخل في المكافأة النهائية. أساس التقييم يُعلن لكل مهمة على حدة، لا يُثبَّت عالميًا.

مسار (trajectory) تشغيل حقيقي واحد

ندعو القارئ الآن إلى تشغيل مهام التقييم في نطاق telecom من τ²-bench بنفسه، ومراقبة تصميم المهام، ومحاكي المستخدم، ومنطق التحقق من العملية والنتيجة، ثم تتبّع مسار تنفيذ الوكيل لتحليل سبب إخفاقه.

التجربة 7-1 ★: تشغيل τ²-bench ومقارنة تطوره عن τ-bench

تشغّل هذه التجربة إطار التقييم τ²-bench لفهم النقاط التصميمية المحورية في بيئة التقييم من نوع التفاعل بين الإنسان والحاسوب. اقرأ أولًا ملف تعريف المهام على المسار نفسه المتبع في هذا القسم: تتألف كل مهمة من أربعة أجزاء — المعلومات المعروفة، وتعليمات المهمة، والحالة الابتدائية، وشروط النجاح. ثم شغّل مسار التقييم كاملًا، وراقب الحوار متعدد الأدوار بين محاكي المستخدم والوكيل، وحلّل أنماط الإخفاق النمطية (مخالفة السياسة، إغفال معلومات، الإحالة المفرطة إلى موظف بشري، وغيرها).

يحتفظ المستودع المرافق بسجل تشغيل واحد (chapter7/tau2-bench-eval). نحلل فيما يلي إحدى عمليات التشغيل الناجحة منه.

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

الوكيل (17): الرقم 555-123-2002 غير موجود ضمن خطوطك النشطة، وأقربها 555-123-2001…

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

المستخدم (30) ← يستدعي check_network_status() وcheck_status_bar()

ما تعيده الأداة (31): Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No

المستخدم (33): أرى أن الهاتف الآن في وضع الطيران، ولهذا لا توجد إشارة. بيانات الجوّال مفعَّلة لكن تجوال البيانات مغلق. هل أغلق وضع الطيران وأجرب؟

الطرف الذي أطلق استدعاء الأداة هو المستخدم لا الوكيل. هذه هي آلية التحكم المزدوج (Dual-Control): المستخدم المحاكى يملك مجموعة أدوات خاصة به مثل check_status_bar وtoggle_airplane_mode وreseat_sim_card وrun_speed_test.

ويمضي التشخيص بعد ذلك بسلاسة: يطلب الوكيل من المستخدم إغلاق وضع الطيران وتفعيل التجوال، فينفّذ المستخدم الأمرين (35 و37)، ويتحول شريط الحالة إلى 5G بإشارة كاملة؛ ثم يطلب الوكيل اختبار سرعة، فتعود النتيجة 275 ميغابت/ثانية بتصنيف Excellent (46)، ويؤكد المستخدم أن المشكلة حُلّت. ويجتاز كلا env_assertions، فتكون reward = 1.0.

يحوي هذا المسار الحاصل على الدرجة الكاملة مشكلةً لم يلتقطها المدقق. فالفقرة الأولى من سياسة وكيل telecom تنص على «You should only make one tool call at a time»، بينما أطلق الوكيل في الرسالة الرابعة استدعاءَي get_customer_by_phone وget_customer_by_name معًا. لم يعدّ المدقق ذلك خطأً لأن reward_basis في هذه المهمة لا يأخذ إلا الحالة النهائية بعين الاعتبار. وليس هذا سهوًا من τ²-bench بل هو الثمن الملازم للمكافأة الثنائية: تقايض دقة العملية بعدد واحد قابل للمقارنة بين النماذج. غير أن منظومات التقييم في بيئة الإنتاج تحتاج عادةً إلى أكثر من ذلك: لا أن تحكم بالصواب أو الخطأ فحسب، بل أن تشير أيضًا إلى موضع المشكلة.

والمهمة التي أخفقت جديرة بالتحليل كذلك. رقم المستخدم هو 555-123-2002، لكن الوكيل اختار الخط L1001 ومضى يستدل على أساس استهلاكه البالغ 3.2/5 غيغابايت. وفي الأثناء أعاد get_details_by_id(L1001) بوضوح أن رقم ذلك الخط هو 555-123-2001؛ قرأ الوكيل النتيجة لكنه لم يصحح حكمه، ثم أنفق عشرات الرسائل في فحوص لا صلة لها بالموضوع، وانتهى إلى الإحالة إلى موظف بشري. وقد أنجز في الواقع نصف المهمة — إذ وجّه المستخدم إلى إغلاق وضع توفير البيانات، وقد وقع هذا الفعل من جانب المستخدم فعلًا وتحققت منه البيئة. لكن خطأ اختيار الخط حال دون تنفيذ شحن الـ 2 غيغابايت المطلوب، فأخفقت التأكيدات الثلاثة على الحالة النهائية جميعًا. وشكل هذا الإخفاق شديد الشبه بحالة AndroidWorld التي يناقشها قسم «عزو الإخفاق» لاحقًا: الدليل اللازم لتصحيح الحكم كان قد دخل السياق بالفعل، لكن الوكيل لم يرجع إليه.

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

مقاييس التقييم: تعريف النجاح

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

المعجزة التقنية: سقف القدرة مع Pass@k

لا يزال كثير من النماذج والوكلاء اليوم في مرحلة يمكن تسميتها «الأعجوبة التقنية». والأعجوبة هنا هي سقف القدرة الذي يظهر بعد محاولات كثيرة ووقت وفير وانتقاء بشري: يكفي أن تنجح محاولة واحدة لإثبات أن الأمر ممكن من حيث المبدأ. وهذا بالضبط منطق Pass@k: تُشغَّل المهمة نفسها $k$ مرة، وتُعدّ ناجحة ما دامت واحدة على الأقل قد نجحت؛ وإذا كان الخرج درجة متصلة فتؤخذ أفضل محاولة ويسمى ذلك Best@k.

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

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

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

أما OpenClaw فقد جعل كثيرين يشعرون لأول مرة بأن الوكيل «كائن حي». إذ يوكل إليه المستخدم العمل عبر تطبيق مراسلة فورية تمامًا كما يوكله إلى شخص حقيقي؛ وهو يصل إلى كل ملفات الحاسوب والخدمات المتصلة، ويبادر عند مرحلة معينة إلى إبلاغ المستخدم أو طلب معلومات جديدة، بل يستطيع أن يوقظ نفسه للاطلاع على البريد ومعالجته.

لم تكن نسبة نجاح Manus وOpenClaw في نسختيهما المبكرتين عالية في المهام المعقدة، وكانت كلفة الرموز باهظة جدًا. لكن لأن أُطر الوكلاء هذه عامة الغرض، فإن المهام المعقدة كثيرًا ما تحقق Pass@k مرتفعًا مع أقوى النماذج، وهو ما يكشف سقفًا تقنيًا عاليًا. وقد كان انتشار هذه «الأعاجيب التقنية» على نطاق واسع في الشبكات الاجتماعية مفتاح نجاح هذه المنتجات.

موثوقية الأعمال: Pass^k

أما الأعمال الحقيقية فتهتم عادةً بالعكس: ألّا يقع خطأ واحد عبر محاولات متعددة. ونسمي هذا الهدف Pass^k (ويُقرأ Pass consecutive k): تُشغَّل المهمة نفسها $k$ مرة متتالية، ويُشترط نجاحها في كل مرة، وألّا تُفعِّل أي بند نقض يتعلق بالأمان أو الامتثال أو الهلوسة. وهو يجيب عن سؤال «هل يستطيع الوكيل التسليم بثبات وموثوقية؟»، لا عن سؤال «هل يصنع معجزة من حين إلى آخر؟».

إذا كانت كل عملية تشغيل مستقلة عن الأخرى وكان احتمال النجاح في المرة الواحدة $p$، فالعلاقة بين المقياسين بديهية:

فمثلًا عند $p=0.6$ و$k=5$: يبلغ Pass@5 $=1-0.4^5\approx99.0\%$، فيبدو كأن «النجاح مرة واحدة على الأقل» يكاد يتحقق دائمًا؛ لكن Pass consecutive@5 $=0.6^5\approx7.8\%$، ما يعني أن اجتياز خمس مرات متتالية دون خطأ لا يزال صعبًا. الرقم الأول صالح لقياس سقف القدرة أثناء الاستكشاف، أما الرقم الثاني فهو وحده القريب من متطلبات الموثوقية في الدفع والاسترداد وتغيير الصلاحيات والنشر الإنتاجي.

يجب أن يوضّح تقرير التقييم المقصود بالمحاولات $k$ بدقة: أهي $k$ عينة مستقلة من المهمة نفسها، أم $k$ مهمة متتالية على خط إنتاج فعلي؟ وفي العمليات ذات الآثار الجانبية لا يصحّ ببساطة «إعادة المحاولة حتى النجاح»، بل ينبغي أخذ العينات في بيئة معزولة أو قابلة للتراجع، وتسجيل كل إخفاق ضمن مقياس الموثوقية.

بيئة التقييم

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

المكوّنات الخمسة

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

مجموعة البيانات (Dataset) هي ملف المهام نفسه: الحالة الابتدائية، والتذكرة الموجهة إلى الوكيل، وضوابط السلوك الموجهة إلى المحاكي، ومعايير القبول، كلها مجموعة في سجل واحد، والسجل الواحد حالة اختبار واحدة.

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

واجهة الأدوات (Tools) موزَّعة على جانبين. يستطيع الوكيل استدعاء عمليات جانب المشغّل مثل الاستعلام عن العميل والاستعلام عن الاستهلاك وشحن البيانات والإحالة إلى موظف بشري؛ ويستطيع المستخدم تشغيل مفاتيح جهازه. ومجموعتا الأدوات كلتاهما عمليات ذرّية، ولا وجود لتجريد رفيع المستوى من نوع «حل مشكلة إنترنت المستخدم» — فارتفاع مستوى التجريد أكثر مما ينبغي يحيل التقييم إلى فحص استدعاء دالة واحدة، وتبتلع الأداةُ نفسها التخطيطَ والاستدلال.

معيار التقييم (Rubric) هو طبقات الفحص الأربع في evaluation_criteria مضافًا إليها قاعدة التجميع reward_basis.

بروتوكول التنفيذ (Interaction Protocol) يحدد ترتيب التفاعل وشروط الإنهاء. وإشارة الإنهاء الطبيعية هنا هي أن يُخرج المستخدم المحاكى ###STOP###؛ وهناك كذلك حد أعلى لعدد الأدوار، ويمكن للمستخدم المحاكى أن ينهي المحادثة من تلقاء نفسه إذا نفد صبره — فتدنّي كفاءة التواصل يُحتسب في ذاته إخفاقًا.

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

بيئات التقييم من نوع التفاعل بين الإنسان والحاسوب ومن نوع استدعاء الأدوات

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

يصنّف إطار Verifiers هذا النوع من البيئات وفق بُعدين: هل تحتاج المهمة إلى الاحتفاظ بحالة عبر الأدوار، وهل تحتاج إلى عزل. فـSingleTurnEnv مناسب لطرح مسألة رياضية والتحقق من الجواب مباشرة؛ وToolEnv لبحث عدة صفحات ويب ثم الإجابة إجابةً مركّبة والتحقق من النتيجة النهائية؛ وStatefulToolEnv لتعديل سجل في قاعدة بيانات والتحقق من تغيّر الحالة؛ وSandboxEnv لتشغيل شيفرة في صندوق رملي وفحص ملفات الخرج. ويلخص الجدول 7-1 هذه الأنواع الأربعة تسهيلًا للاختيار بحسب متطلبات حالة المهمة واستدعاء الأدوات والعزل.

الجدول 7-1: مقارنة أنواع بيئات Verifiers

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

التقييم من نوع استدعاء الأدوات يفحص صحة تغيّرات الحالة القابلة للملاحظة، أما التقييم من نوع التفاعل بين الإنسان والحاسوب فيفحص سلامة استراتيجية التواصل: الأول يتحقق من الفعل، والثاني من حسن التوجيه. ولمقارنة بنية النوعين انظر الشكل 7-2.

تصميم مجموعة بيانات التقييم

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

مقارنة عرضية لقرارات التصميم بين المعايير المرجعية

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

الجدول 7-2: قرارات التصميم المفتاحية في عدة معايير مرجعية للوكلاء

المدققات

يسهل على الوكيل أن يكتب تقريرًا مسهبًا يقول فيه إن المهمة أُنجزت بالكامل، بينما لم يُنجَز في الواقع شيء. وعلى إطار التقييم أن يتحقق من وقائع يستطيع الحاسوب مراجعتها باستقلال، لا من إقرار الوكيل عن نفسه.

يفكك SWE-bench Verified عبارة «اكتمل الإصلاح» إلى قضيتين مستقلتين. الأولى FAIL_TO_PASS: يخفق قبل الإصلاح وينجح بعده، وهذا يثبت أن المشكلة حُلّت فعلًا. والثانية PASS_TO_PASS: ينجح قبل الإصلاح وبعده، وهذا يثبت أنه لم يُدخل عيبًا جديدًا. فإن فحصت الأولى وحدها أمكن للوكيل التملص بحذف التأكيدات المعترضة أو تعديلها؛ وإن فحصت الثانية وحدها فكأنك لم تفحص شيئًا. ولا يصير «أُصلح» و«لم يُكسر شيء» نتيجتين قابلتين للإثبات كل على حدة إلا بفحصهما معًا. ويؤكد كذلك ثبات الاختبارات نفسها، مستبعدًا الاختبارات المتقلبة (flaky test) التي تنجح تارةً وتخفق تارة.

مدقق OSWorld قادر على كشف الحالات التي تبدو منجَزة ظاهريًا وهي في الجوهر خاطئة. فهو مزوَّد بـ134 دالة تقييم مستقلة وبصلاحية وصول كاملة إلى نظام التشغيل، فيستطيع فحص بنية نظام الملفات وحالات العمليات واتصالات الشبكة والحالة الداخلية للتطبيقات. ففي مهام قواعد البيانات لا يكتفي سكربت التقييم بالتأكد من وجود ملف التقرير، بل يتصل بقاعدة البيانات ليراجع تنفيذ الـSQL فعليًا؛ وفي مهام المتصفح يحلل شجرة DOM ويفحص ملفات تعريف الارتباط وlocalStorage ويرسل طلبات تحقق إلى الواجهة الخلفية للتأكد من أن النموذج قد سرى مفعوله حقًا.

مهمة build-linux-kernel-qemu في Terminal-Bench تشترط بناء نواة Linux 6.9 من المصدر، وإضافة printk مخصص في start_kernel، وتوليد initramfs وتشغيله في QEMU؛ ومعيار النجاح ظهور تلك الرسالة المخصصة في سجل الإقلاع. لا يستطيع الوكيل تزوير الخرج، ولا مفر له من إتمام العملية كلها فعليًا.

تدرّج صعوبة المهام

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

تنقسم أسئلة GAIA الـ466 جميعها إلى ثلاث درجات صعوبة: يكفي في Level 1 أداة أو أداتان (البشر 93.9%، وGPT-4 30.3%)، ويستلزم Level 2 تفكيرًا متعدد الخطوات (91.8% مقابل 9.7%)، ويستلزم Level 3 تركيبًا معقدًا (87.3% مقابل 0%). وهذا التدرّج لا يكتفي بوسم الصعوبة بل له قيمة تشخيصية: الإخفاق في Level 1 يشير إلى الاستعمال الأساسي للأدوات، وLevel 2 إلى التخطيط متعدد الخطوات ودمج المعلومات، وLevel 3 إلى التفكير عبر متتاليات طويلة وإدارة التعقيد، ويقابل كلٌّ منها اتجاه تحسين مختلفًا.

ويمتد Terminal-Bench من تسجيل نموذج mlflow البسيط، إلى كسر كلمة مرور 7z متوسط الصعوبة، إلى التكامل متعدد المكوّنات الصعب بين خادم git وخادم ويب، وصولًا إلى أصعبها وهو تحليل الشفرات التفاضلي لـFEAL.

كما يصمم τ²-bench مهام فخّ خاصة: يزعم المستخدم أن «خدمة العملاء وافقت على الإلغاء» بينما الأمر في الواقع لا يوافق السياسة، لاختبار ما إذا كان الوكيل يحافظ على حكمه الصحيح تحت الضغط والتضليل.

الوقاية من تسرب البيانات

يجعل GAIA إجاباته غير قابلة للبحث المباشر على الإنترنت. فمهامه بسيطة مفاهيميًا لكن مسارها مفتوح: مثلًا الانطلاق من صورة اليوم الفلكية لناسا في تاريخ بعينه، والتعرف على رائد الفضاء في الصورة، والبحث عن مجموعة روّاد الفضاء التي انتمى إليها، وحساب من قضى من تلك المجموعة أقصر مدة في الفضاء، وإخراج النتيجة بصيغة صارمة هي «اسم العائلة، مفصولًا بفاصلة منقوطة، مع فواصل الآلاف». الإجابة بالغة التحديد، وتتحدد صحتها بمطابقة نصية دقيقة. وتقوم الوقاية من التسرب على أمرين: أولهما أن السؤال لا يُجاب عنه إلا بتركيب عدة مصادر معلومات، فلا تعطي صفحة ويب واحدة الجواب مباشرة؛ وثانيهما أن بعض المهام مرفقة بملفات صُنعت خصيصًا (ملفات PDF وصوت وصور غير موجودة على الإنترنت).

يشتق AndroidWorld عددًا كبيرًا من النسخ من قالب واحد. فمهامه ليست نصًا ساكنًا بل قوالب قابلة للتجسيد ديناميكيًا، مثل «غيّر رقم هاتف جهة الاتصال [CONTACT_NAME] إلى [NEW_PHONE]»، مع توليد قيم المعاملات عشوائيًا في كل تقييم. وفي هذا ثلاث فوائد: اختلاف المعاملات في كل مرة يُبطل إعادة تشغيل تسلسل عمليات ثابت؛ ويستطيع قالب واحد توليد نسخ لا تكاد تُحصى؛ وتثبيت بعض المعاملات وتغيير الباقي يتيح قياس أثر عامل بعينه قياسًا دقيقًا.

يُضمّن Terminal-Bench معرّف كناري في نص السؤال. فكل سؤال يحمل canary GUID؛ وإذا استطاع نموذج إخراج محتوى يتضمن ذلك المعرّف، فمعناه أن بيانات المعيار المرجعي دخلت مجموعة التدريب. وهذا لا يمنع التسرب لكنه يجعله قابلًا للكشف.

ضبط الجودة والصيانة على المدى الطويل

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

أولًا، كانت تعليمات المهمة أعمّ مما ينبغي فأمكن تخمين الجواب. كُتبت تعليمات النسخة الأولى كتابة فضفاضة، فلم يكن النموذج بحاجة إلى توضيح الطلب حقًا؛ إذ كان تخمين إجراء ما بالبداهة كافيًا للاجتياز. فقسّم τ²-bench النص إلى خانتين، known_info وtask_instructions: الأولى ترسم حدود ما يعرفه المستخدم، والثانية تنظم طريقة الكشف. وما لا يعرفه المستخدم لا سبيل للوكيل إلى تخمينه، ولا يحصل عليه إلا بالاستعلام.

ثانيًا، لم تكن شروط النجاح دقيقة بما يكفي فأخطأ التحقق في الحكم. فشرط مثل «عادت الشبكة» لا حدّ له قابلًا للمراجعة. فغيّره τ²-bench إلى «لا تُعد محلولة إلا إذا أعاد اختبار السرعة excellent؛ وأما poor وfair وgood فلا تُقبل». ويستهدف هذا التغيير الإصلاحات الشكلية التي تكتم العَرَض دون أن تحل السبب الجذري.

ثالثًا، كان سلوك محاكي المستخدم آليًا أكثر مما ينبغي. فالمستخدم المحاكى في النسخة الأولى لم يكن يفعل سوى الرد السلبي. فأضاف إليه τ²-bench انفعالًا (إظهار الاستياء بعد أول إصلاح فاشل)، وحدًّا للصبر (إنهاء المحادثة إذا كان التواصل شديد التدني في الكفاءة)، وشرط الترسيخ الواقعي. وبتضافر الثلاثة يقترب المحاكي من المستخدم الحقيقي مع بقائه قابلًا لإعادة الإنتاج.

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

خامسًا، تُولَّد نسخ المهام ديناميكيًا. فالنسخ المحددة في τ²-bench (أسماء المستخدمين والأرقام وتوليفات الأعطال) قابلة للمعاملة والتوليد بالجملة، وهذا يحسّن التغطية ومقاومة التسرب معًا.

SWE-bench Verified: قبل النشر استُبعد 71% من المهام الأصلية. اختارت OpenAI عشوائيًا 1699 مهمة من أصل 2294 للتقييم البشري، واستقدمت 93 مطورًا متمكنًا من Python لفحصها واحدة واحدة: هل وصف المشكلة واضح، وهل تغطي حالات الاختبار الشروط الحدّية، وهل الاختبارات مستقرة، وهل يُدخل الـpatch المرجعي أخطاء جديدة، وهل الصعوبة معقولة. وفي النهاية لم يجتز سوى 500. ومعدل الاستبعاد المرتفع يأتي بنسبة إشارة إلى ضجيج أفضل، وتنخفض معه كلفة التقييم بنحو 80%. فمهام الوكلاء المعقدة كثيرًا ما تستغرق من دقائق إلى ساعات، وتشغيل مجموعة تقييم كاملة بنموذج متقدم يكلف غالبًا آلاف الدولارات من الرموز، ولذا فخفض كلفة التقييم بالغ الأهمية.

OSWorld: في الأشهر الخمسة عشر التالية للنشر انكشف أكثر من 300 مشكلة. فبعد صدوره في نيسان/أبريل 2024 صار سريعًا معيارًا مرجعيًا مهمًا لتقييم الوكلاء متعددي الوسائط، لكن الاستعمال الواسع اللاحق كشف أربعة أصناف من المشكلات: مشكلات البيئة (حماية المواقع من الكشط، وCAPTCHA، وتغيّر المحتوى الديناميكي)، ومشكلات وصف المهام (صياغات ملتبسة)، ومشكلات منطق التحقق (مفرط في التشدد أو في التساهل)، ومشكلات الحالة الابتدائية (إعداد ناقص). وشكّل فريق من جامعة هونغ كونغ مجموعة من نحو عشرة أشخاص، وعمل شهرين بتعاون وثيق مع MoonShot AI وOpenAI وByteDance Seed TARS وAnthropic وSimular وغيرها على إصلاح منهجي: عولجت مشكلات البيئة بتثبيت الإصدارات والنسخ الاحتياطية دون اتصال، ومشكلات الوصف بإعادة صياغة العبارات الملتبسة، ومشكلات التحقق بإرساء خط أساس صحيح يدويًا وضبط الشروط، ومشكلات الحالة الابتدائية بإضافة فحوص الاكتمال.

التجربة 7-2 ★: تنفيذ مهام المعايير المرجعية يدويًا

اختر مهامّ من GAIA وAndroidWorld وSWE-Bench Verified وTerminal-Bench وOSWorld-Verified وأنجزها بيدك؛ ويُستحسن إنجاز واحدة سهلة وواحدة متوسطة وواحدة صعبة من كل مجموعة. والمستوى «الصعب» يشكّل تحديًا للبشر أيضًا.

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

المصادر الثلاثة لمجموعة التقييم

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

ولمجموعة التقييم في بيئة الإنتاج ثلاثة مصادر عادةً.

المعايير المرجعية العامة تُستعمل لغربلة النماذج غربلة خشنة ولاقتباس أساليب التصميم، ولا تُستعمل عادةً لقرارات المنتج. فتوزيع مهامها لا يطابق توزيع مهام العمل الحقيقي؛ وارتفاع نقطتين مئويتين في GAIA لا تربطه علاقة حتمية بمعدل نجاح المبالغ المستردة.

مجموعة العمل المبنية ذاتيًا تغطي توزيع المهام الحقيقي، ويمكن أن تكون أساسًا لاختيار النموذج ولقرارات تصميم الـHarness. فمثلًا يمكن استعمال τ²-bench كما هو هيكلًا لأي منظومة تقييم تحتاج إلى مستخدم محاكى؛ ويكفي استبدال بيانات النطاق ومجموعة الأدوات.

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

في المرحلة الأولى لا يتوفر عادةً إلا معايير مرجعية عامة ومجموعة عمل صغيرة مكتوبة يدويًا؛ وبعد أن يعمل النظام مدة في بيئة الإنتاج، تصير الحالات العائدة من مسارات الإنتاج هي الجسم الأكبر.

طرائق التقييم الآلي

للمعايير المرجعية التي نوقشت في الأقسام السابقة قاسم مشترك: مدققاتها كلها تقريبًا حتمية. فـSWE-bench يشغّل حزمة اختبارات، وAndroidWorld يؤكد الحالة النهائية للواجهة، وGAIA يجري مطابقة نصية دقيقة، وطبقات الفحص الأربع في τ²-bench تُنفَّذ كذلك بالشيفرة بالكامل. ولهذا الاختيار مسوّغات وجيهة: التحقق الحتمي لا يضيف كلفة نموذج، والنتيجة قابلة لإعادة الإنتاج تمامًا، ويمكن إدراجه في التكامل المستمر كاختبار وحدة، وييسّر الترتيب بين النماذج.

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

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

ولذلك، عند الانتقال من المعايير المرجعية العامة إلى التقييم في بيئة الإنتاج، ينبغي إزاحة أسلوب التحقق نحو اليمين على طيف محوره الأفقي درجة قابلية المهمة للتحقق آليًا، كما يوضح الشكل 7-4.

وهكذا تصير الأداتان الواقعتان في يمين الطيف عماد التقييم الإنتاجي: Rubric يفكك سؤال «جيد أم لا» المبهم إلى عدة أبعاد يمكن تقييم كل منها على حدة، وLLM-as-a-Judge يتولى التقييم حيث لا يوجد معيار حتمي. ولا يمكن ردّ معدل إخفاق مبهم إلى مشكلات محددة يمكن الشروع في إصلاحها إلا باجتماع الاثنين؛ وبإضافة عزو الإخفاق في النصف الثاني من هذا القسم تتشكل الحلقة المغلقة الكاملة لتقييم الوكلاء الإنتاجيين.

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

النموذج اللغوي بوصفه قاضيًا: جوهر التقييم الآلي

لماذا هناك حاجة إلى LLM كقاضي؟ بالنسبة للمهام المفتوحة (على سبيل المثال، إنشاء التقارير، والتعامل مع شكاوى العملاء، والمحتوى الإبداعي)، لا توجد إجابات قياسية للمقارنة التلقائية، ويكون التقييم البشري مكلفًا ويصعب قياسه. تعمل LLM-as-a-Judge على موازنة قابلية التوسع في الأتمتة مع حكم الخبراء البشريين من خلال وجود نموذج لغة يقيم المخرجات مقابل معايير التسجيل المحددة بواسطة الخبراء (قاعدة تقييم). ومع ذلك، فإن الطريقة لها حدود معروفة: يحمل نموذج القاضي تحيزاته الخاصة (في أغلب الأحيان تحيز الطول - وهو الميل إلى تسجيل إجابات أطول وأكثر تفصيلاً أعلى حتى عندما لا تكون أكثر صحة)، ويمكن أن تختلف الأحكام المتكررة لنفس المدخلات. ويتطلب التحيز في الطول على وجه الخصوص اتخاذ تدابير مضادة محددة. ثلاثة دفاعات شائعة هي: معاقبة الإسهاب بشكل صريح في نموذج التقييم والحد الأقصى لطول الاستجابة لكل نوع مهمة؛ في المقارنات الزوجية، اجعل المرشحين متساويين في الطول قبل الحكم؛ ومراجعة العلاقة بين الدرجات وطول الاستجابة بانتظام - إذا كانت الدرجات العالية تذهب دائمًا تقريبًا إلى الإجابات الطويلة، فقد تأثر القاضي بالطول ويحتاج نموذج التقييم إلى المراجعة. ولمواجهة هذه التحديات بشكل منهجي، يجب أن يتبع تصميم القاعدة المبادئ التالية:

قواعد التقييم (معايير التسجيل): أساس حكم LLM.

أربعة مبادئ للتقييم (مقياس الذكاء الاصطناعي، “المبادئ كمكافآت”):

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

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

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

(4) التقييم القائم بذاته — كل عنصر تقييم قابل للتنفيذ بشكل مستقل ولا يعتمد على معرفة مجال التقييم. يجب تجنب المعايير المجردة مثل “الإجابة توضح الفهم العميق”، واستبدالها بمعايير يمكن التحقق منها مثل “الاستشهاد بنظريتين موثوقتين على الأقل وشرح بدقة كيفية دعمهما للاستنتاج”.

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

فيما يلي نموذج تقييم كامل يتبع المبادئ الأربعة، باستخدام وكيل ذاكرة المستخدم كمثال. سؤال الاختبار: “من هو طبيب الأطفال الخاص بابنتي؟” (تتطلب الإجابة ربط المعلومات عبر محادثتين: المحادثة الأولى تذكر “اسم ابنتي ليلي”، والمحادثة الثانية تذكر “أخذت ليلي لرؤية الدكتور تشين”).

rubric:
  dimensions:
    - name: Factual Correctness
      weight: essential        # Essential item
      scoring:
        4_Excellent: "Correctly answers Dr. Chen, and links to daughter Lily"
        3_Good: "Correctly answers Dr. Chen but does not mention that Dr. Chen is Lily's doctor"
        2_Passable: "Gives the correct doctor but with additional uncertain information"
        1_Fail: "Gives an incorrect doctor's name, or answers 'I don't know'"

    - name: Information Completeness
      weight: important        # Important item
      scoring:
        4_Excellent: "Proactively supplements relevant information (e.g., last visit date, diagnosis)"
        3_Good: "Answers the core question without omission"
        2_Passable: "Answers the core question but omits available related information"
        1_Fail: "Key information is missing"

    - name: Reasoning Correctness
      weight: important
      scoring:
        4_Excellent: "Correctly links the two cross-session pieces of information: 'daughter=Lily' and 'Lily's doctor=Dr. Chen'"
        3_Good: "Correctly links but the reasoning path is not clear enough"
        2_Passable: "Partially correct linking"
        1_Fail: "Incorrect linking (e.g., mistaking the user's own doctor for the daughter's doctor)"

    - name: Hallucination Detection
      weight: veto             # Veto item: once triggered, total score is zero
      scoring:
        pass: "All information can be traced back to historical conversation records"
        fail: "Fabricated information not present in the conversation (e.g., fictitious visit dates, diagnoses)"

  edge_cases:
    - "If the user has multiple daughters who see different doctors, should ask which daughter"
    - "If the memory contains both 'Dr. Chen' and '陈医生' (the same name written in Chinese), should recognize them as the same person"

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

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

وفيما يلي نتّخذ ذاكرةَ المستخدم مثالًا محدَّدًا، لنُري كيف تنزل هذه المنهجيةُ العامة إلى مجموعةِ تقييمٍ ومصحِّحٍ قابلَين للتنفيذ.

التجربة 7-3 ★★: إنشاء نظام لتقييم ذاكرة المستخدم قائم على القواعد

المتطلبات الأساسية: يجب إكمال تجربة ذاكرة المستخدم في الفصل الثالث (chapter3/user-memory-evaluation).

تتطلب هذه التجربة تعديل إطار عمل chapter3/user-memory-evaluation من الفصل 3، وترقية آلية تسجيل LLM البسيطة الحالية إلى نظام تقييم منظم ومتعدد الأبعاد. يستخدم النظام الحالي استدعاء LLM واحد لإرجاع نتيجة النجاح/الفشل بالإضافة إلى أسباب التقييم، ويفتقر إلى إمكانيات التشخيص المنظمة.

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

درجات من أربعة مستويات (ممتاز/جيد/مقبول/راسب)، مع معايير حكم محددة لكل مستوى بدلاً من الأوصاف المجردة. البعد الهلوسة هو عنصر النقض. تقديم أمثلة وحالات حدودية لكل بعد.

التجربة 7-4 ★★: التقييم المقارن لبطاقات JSON المتقدمة مقابل RAG

المتطلبات الأساسية: يجب إكمال تجربتي ذاكرة المستخدم وRAG في الفصل الثالث (chapter3/user-memory, chapter3/agentic-rag-for-user-memory).

الهدف: مقارنة مزايا وحدود الذاكرة المنظمة بشكل عادل مقابل الاسترجاع غير المنظم في نفس مجموعة التقييم. أعد استخدام مشروعي الفصل 3 وقارن ثلاثة تكوينات في 60 حالة اختبار من chapter3/user-memory-evaluation — بطاقات JSON المتقدمة النقية (البطاقات المنظمة التي يتم الاحتفاظ بها في السياق، دون الحاجة إلى استرجاعها)، وRAG النقي (أجزاء المحادثة المضمنة في مخزن المتجهات، والاسترداد مطلوب)، والنظام الهجين (الحقائق الأساسية المقيمة + المحادثات الأصلية المستردة عند الطلب).

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

شغّلت التجربة المصاحبة الأنظمة الثلاثة على الأسئلة الستين نفسها، واحتفظت بـ180 مسارًا حقيقيًا لاستدعاءات API. يعرض الجدول 7-3 النسب وأعداد الإجابات الناجحة معًا.

الجدول 7-3 معدل النجاح بحسب نظام الذاكرة ومستوى المهمة

وأجدرُ ما في الأمر بالانتباه أن الحلَّ الهجين لم يفز فوزًا طبيعيًّا. فقد صنع في 3 أسئلة ما عجز عنه الحلّان المفردان كلاهما، لكنه جاء في 8 أسئلةٍ أخرى دون الحلّ المفرد الأحسن أداءً؛ ومقارنةً بأفضل حلٍّ مفردٍ في كل سؤال، كان متوسّطُ نجاحه أدنى. أما RAG الصِّرف فلم يبتعد كثيرًا عن البطاقات المهيكلة في أسئلة الاستدعاء الأساسي، لكنه ما إن بلغ أسئلةَ الربط بين الجلسات حتى هبط معدّلُ نجاحه إلى 15%. وثمّة رقمٌ آخر يسهل إغفاله: من بين 180 حكمًا، انطلق نقضُ الهلوسة 28 مرة، وفي ذلك دليلٌ على أهمية بنود النقض المطلق.

مشكلة نموذج العائلة نفسها والحكم متعدد المصادر.

عندما يأتي الوكيل ونموذج التحكيم من نفس العائلة، قد يتعلم الوكيل استغلال تفضيلات نموذج التحكيم والنقاط العمياء.

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

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

التخفيف هو تحكيم غير متجانس متعدد المصادر — حكام مستقلون يتم اختيارهم من عائلات نموذجية مختلفة (إذا كان الوكيل يعمل على Claude، فالحكم باستخدام GPT-5 وGemini). غالبًا ما تكون تحيزات العائلات المختلفة متعامدة، لذا نادرًا ما يتمكن الوكيل من خداع جميع القضاة في وقت واحد. استخدم نفس قواعد التقييم حتى يحكم الجميع على نفس الهدف، وقم بالتجميع من خلال المتوسط ​​المرجح أو عمليات التحقق من الاتساق. أثناء النشر، يمكن لنموذج واحد التعامل مع التقييم السريع، مع إجراء عمليات تدقيق دورية للجودة مقابل الإعداد الكامل متعدد المصادر.

يتناول التحكيم متعدد المصادر مسألة النماذج التي ينبغي أن تعمل كقضاة؛ والسؤال التالي هو ما هي الطرائق التي ينبغي تقييمها - ويعد توسيع نطاق LLM كقاضي من النص إلى الكلام والصور والفيديو محورًا آخر لتغطية التقييم.

LLM متعدد الوسائط كقاضي.

يمتد التحكيم المتعدد الوسائط إلى LLM-as-a-Judge ليشمل مجالات الكلام والصور والفيديو. أربعة اتجاهات مشتركة هي كما يلي.

• تقييم TTS (TTS يرمز إلى تحويل النص إلى كلام): يقيم الدقة والطبيعية واتساق الصوت والتعبير العاطفي. يمكن لهذه الأبعاد التقاط المشكلات العرضية التي يكافح WER (معدل خطأ الكلمات) التقليدي لاكتشافها.
• تقييم ASR (ASR يرمز إلى التعرف التلقائي على الكلام): يقوم بإجراء تقييم التأثير الدلالي، فالخطأ في التعرف على “الطقس اليوم” غير ضار، ولكن الخطأ في التعرف على “نقل ألف” على أنها “عشرة آلاف” قد يكون له عواقب وخيمة.
• تقييم واجهة المستخدم: يستخدم آلية المقترح والمراجع للتحقق من وجود مشكلات مثل تجاوز النص وتباين الألوان وموضع الزر. هنا، يتم استخدام مُراجع المُقترح باعتباره طريقة تقييم، ويختلف عن استخدامه كـ مكون نظام التوليد في الفصل 5، ولكن الآلية الأساسية هي نفسها — نموذج يُنشئ، وآخر يراجع بشكل مستقل.
• تقييم تحرير الفيديو: التحقق من صحة نقاط بداية/نهاية المقطع وتطبيق التأثير من خلال الإطارات الرئيسية.

التجربة 7-5 ★★: إنشاء خط أنابيب لتقييم جودة تحويل النص إلى كلام (TTS) مؤتمت بالكامل

تتطلب هذه التجربة تصميم وتنفيذ نظام كامل لتقييم الجودة LLM-as-a-Judge TTS من البداية.

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

أنشئ مجموعة اختبار متنوعة في الطول والنوع والعاطفة والتحديات الخاصة. اربط وحدة TTS بخدمات شائعة مثل OpenAI وElevenLabs وFish Audio وMinimax وDoubao، ثم قدّم الصوت المركّب والنص الأصلي والصوت المرجعي ونموذج التقييم إلى محكّم متعدد الوسائط قادر على استقبال الصوت مباشرة. وسجّل اسم نموذج التحكيم وبصمتي الملفين المرشح والمرجعي حتى يمكن تدقيق كل درجة.

يحتفظ المستودع المصاحب بتجربة استماع مباشرة صغيرة. أنشأ كل من OpenAI وFish Audio أربعة مقاطع تغطي الأرقام والأحرف الصينية متعددة النطق والنص الطويل والأداء المتحمس، وحكم Voxtral على المقاطع الثمانية وفق الأبعاد الأربعة. تعادل النظامان في الدقة والطبيعية بمتوسط 5.00 و4.00. وسجّل Fish Audio درجتي 4.00 و3.00 في التعبير العاطفي واتساق الصوت، مقابل 3.75 و2.75 لـOpenAI. أظهر فصل الدرجات بحسب الأبعاد فروقًا لا يكشفها سؤال بسيط من قبيل «هل قُرئ النص بصورة صحيحة؟».

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

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

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

إسناد الفشل: تحديد موقع الخطأ الأول في المسار

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

بالنسبة إلى Coding Agent، تشمل الفئات الأولية غياب العملية والقواعد، وأخطاء الأدوات أو التنسيق، والتوقف غير الطبيعي، ومشكلات المنطق أو اكتمال المهمة. احفظ سجل JSON/YAML منظمًا يتضمن رقم الخطوة والأداة والملاحظة والسبب الجذري مقابل النتيجة وقابلية الاسترداد والثقة، مع حالة البيئة والإصدارات والمسار الكامل.

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

ومع نضج المنتج قد يضم تصنيف الأخطاء عدة فئات كبرى، تحت كل منها فئات فرعية، حتى يبلغ المئات. وتصير هذه الفئات وطرائق العزو لاحقًا هي المطالبة (prompt) أو الـ Skill الخاص بوكيل يقوم بوسم العزو.

وبأخذ Coding Agent مثالًا، يبدو التصنيف الأولي العملي على النحو التالي.

يستطيع وكيل وسم العزو أن يستعين بنموذج لغوي لإجراء تحليل الأسباب الجذرية على نطاق واسع عبر كثير من مسارات الإنتاج، لكنه لا يجوز أن يكتفي بجملة واحدة عن «سبب الفشل». فسجل العزو ينبغي أن يكون مُهيكلًا: بصيغة JSON أو YAML، مع الإشارة إلى أرقام خطوات محددة وأسماء أدوات وأدلة ملحوظة؛ وعليه كذلك أن يفصل السبب الجذري عن النتيجة، وأن يحكم على إمكان التعافي، وأن يعطي درجة ثقة. فمثلًا حين يعيد edit_file عدم تطابق old_string ثم يعيد الوكيل المحاولة ثلاث مرات دون أن يكتب الملف، يكون السبب الرئيس هو خطأ تحرير الملف واستدعاء الأداة، أما المحاولات الثلاث فنتائج لا ثلاثة أسباب جذرية مستقلة. وإذا ظهرت فئات عدة معًا، فاختر السبب الرئيس بقاعدة «الأبكر والقادر على تفسير ما تلاه من إخفاقات»، واحتفظ بالباقي أسبابًا ثانوية. وثمة في الجدول أعلاه ثلاث فئات على الأقل يمكن ترشيح مساراتها المشتبه بها بقواعد قبل تكليف النموذج بتحديد الخطأ الأول: مقارنة إعلان الإنجاز بالأوامر المنفّذة فعلًا؛ وهل يمس الـ diff تأكيدات الاختبار وعلامات skip؛ وهل يغيّر الـ diff واجهة عامة أو schema دون ملف ترحيل. والترشيح بالقواعد أولًا ثم التحديد بالنموذج أرخص وأدق من دفع كل المسارات إلى النموذج.

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

وفيما يلي عرض لثلاث فئات نمطية من الأخطاء.

مشكلة «فعل الصواب وأبلغ الخطأ»

«فعل الصواب وأبلغ الخطأ» هي الفئة التي يخفيها معدل النجاح الإجمالي أكثر من غيرها، لأن معظم التقييمات تتحقق من حالة البيئة فقط. ويمنحها τ²-bench تقييمًا مستقلًا: من بين 704 عمليات تشغيل مرجعية منشورة تحمل مهامها شرط إبلاغ، فشلت 240، رسبت 162 منها في فحص الإبلاغ، وكانت 80 — أي ثلث مجموع حالات الفشل — صحيحة الحالة البيئية وخاطئة الإبلاغ.

يحتفظ المستودع المرافق بحالة مماثلة. فحين طُلب إدخال المصروفات من expenses.jpg إلى تطبيق محاسبة، أنفق الوكيل 32 خطوة في منح الأذونات والبحث وفتح الصورة وملء كل سطر والحفظ، دون أن تُرجع أي خطوة خطأً، ثم أعلن إنجاز المهمة؛ غير أن المدقّق أبلغ بأن السطر الذي كان ينبغي كتابته — Dress بمبلغ ¥436.35 — غير موجود، ولا صلة له بالسطور الأربعة التي أدخلها. وفي الخطوة 8 يقول تفكيره نصًّا: «I cannot actually see the content/details of the expenses in the image». كان يعلم أصلًا أن البيانات لم تصله، فلم يتوقف ولم يُبلغ، وبحلول الخطوة 11 ظهرت أربعة مصروفات مختلقة في سجلّه، نفّذها كل إدخال لاحق بأمانة. الخطأ الأول هو الخطوة 8، وهي خطوة لم تُصدر خطأً ولم تكن استدعاء أداة. كما يسهل تصنيف سببها الجذري خطأً: فـ T3A وكيل نصي محض لا يحوي فضاء ملاحظته سوى شجرة العناصر دون أي بكسل صورة، فالسبب ليس «عجز النموذج عن OCR» بل غياب قناة ملاحظة، مضافًا إليه غياب مخرج مشروع يقول «المعلومة غير متاحة». وتسجيله كمشكلة قدرة نموذج يقود الخطوة التالية إلى تبديل النموذج أو تدريب OCR؛ أما الإصلاح الحقيقي فهو إضافة القناة والمخرج.

التجربة 7-6 ★★: عزو الفشل على مسارات AndroidWorld

تتدرّب هذه التجربة على أسلوب العزو الوارد في هذا القسم باستخدام مسارات حقيقية، دون الحاجة إلى محاكٍ أو إلى واجهة برمجية للنموذج. المادة هي تشغيل T3A المحفوظ في chapter7/android-world: يحتوي t3a.md على Action/Reason/Summary خطوة بخطوة لكل المهام، بينما يجمع t3a_failed.md أكثر من خمسين مسارًا فاشلًا ينتهي كل منها بحكم موضوعي من المدقّق.

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

الخطوة 2: تحديد الخطأ الأول. سجّل لكل مسار رقم خطوة الخطأ الأول، وبيّن ما إذا كانت تلك الخطوة استدعاء أداة أم رسالة assistant message. يحتاج الفشل الصامت إلى أسلوبين: مقارنة المراسي الواقعية، التي تطابق تصريحات الوكيل مع القيم التي تعيدها الأدوات وتأخذ أول تباين؛ والتنصيف على بادئة المسار، الذي يقطع المسار عند الخطوة k ويسلّمه — فإن ظل قابلاً للإنقاذ فالخطأ يقع بعد k. والبحث عن كلمات الخطأ لا يغني عن أي منهما.

الخطوة 3: كتابة سجل بنيوي. أنتج لكل مسار سجلًا بصيغة JSON أو YAML يضم اسم المهمة وخطوة الخطأ الأول وفئة الخطأ والجهة المسؤولة عن السبب الجذري والاقتباسات الداعمة، مع الفصل بين السبب الرئيس والنتيجة.

الخطوة 4: المقارنة بالملاحظات الموجودة. قارن نتائجك ببند t3a_failed_analysis.md بندًا بندًا وسجّل كل خلاف. وانتبه خاصةً إلى عزو السبب الجذري: فقد سجّلت تلك الملاحظات فشل نسخ الصورة على أنه «افتقار نموذج الرؤية إلى OCR»، في حين أن فضاء الملاحظة في T3A لا يتضمن بكسلات الصور أصلًا، فالسبب الجذري الحقيقي هو غياب قناة ملاحظة. الملاحظة الجاهزة ليست مفتاح إجابة.

الخطوة 5: التحويل إلى مهام انحدار. اختر ثلاثة مسارات يقع خطؤها الأول في رسالة assistant message، واقطع البادئة قبل ذلك الخطأ مباشرة، ثم اكتب مجموعة الأفعال المقبولة والأفعال الممنوعة لتكوين مهام انحدار على بادئة المسار.

أخطاء تنسيق المستند الحساسة للنطاق

حين يقول المستخدم إن «تنسيق علامات الاقتباس خاطئ»، لا يجوز تحويل ذلك إلى استبدال شامل للمحارف. ينبغي على الأقل التمييز بين علامات الاقتباس المستقيمة في ASCII ("، ')، وعلامات الاقتباس الصينية المنحنية (“”، ‘’)، والعلامة الخلفية في Markdown (`). فالمحرف نفسه يؤدي دورًا نحويًا مختلفًا في النثر الصيني، والنص الإنجليزي المقتبس، والشفرة السطرية، وكتل الشفرة، وتعليقات الشفرة، وJSON، والمسارات.

ينبغي لبيانات التقييم أن تحلّل المستند أولًا إلى مقاطع ذات نطاق، مثل ZH_PROSE وEN_PROSE وQUOTED_SOURCE وINLINE_CODE وCODE_BLOCK وCODE_COMMENT وJSON_OR_SCHEMA. ويحفظ كل مقطع مجموعة التحويلات المسموح بها، والمحارف الواجب حمايتها، ونتيجة المدقّق بعد التعديل. والمواضع الثلاثة التالية لا يمكن معالجتها بقاعدة استبدال واحدة:

نثر صيني: استدعِ الدالة `reset()`.
نص إنجليزي مقتبس: “Please restart the service.”
# كتلة الشفرة التالية لتوضيح نطاق محمي فقط
# تعليق صيني: اعرض "الحالة الراهنة"
name = "status"

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

أخطاء النسخ الحرفي: من old_string mismatch إلى التحديد طبقةً طبقة

لا يمكن كذلك إرجاع فشل old_string إلى «أن النموذج نسخ خطأً» وحسب. فللسلسلة النصية نفسها ينبغي حفظ بصمة البايتات الأصلية، وتسلسل Unicode code point، وتسلسل token ID الخاص بالـ tokenizer، ثم البحث عن أول اختلاف على امتداد هذه السلسلة:

بايتات الملف الأصلية → ما تُعيده الأداة → تسلسل Harness → سياق النموذج
→ مخرجات token للنموذج → السلسلة بعد فك الترميز → تحليل JSON/tool-call → مطابقة الأداة

وتغطي مجموعة المجسّات التقييمية الدنيا: الترديد المباشر، والاستخراج من سياق طويل، والوضع في وسائط الأداة، والاختيار بين سلاسل متشابهة، إضافة إلى المسافات وفواصل الأسطر والشرطات المائلة العكسية ومحارف Unicode المركِّبة والرموز منخفضة التكرار. أما المقاييس فهي byte-exact match وcode-point-exact match وtoken-exact match وموضع أول اختلاف ونسبة نجاح الأداة الفعلية. وإذا كان النموذج مصيبًا في المجسّ المباشر بينما يفشل استدعاء الأداة، فالإصلاح يكون في الـ tokenizer أو التسلسل أو Harness أو بروتوكول الأداة؛ ولا تُحوَّل الحالة إلى بيانات تدريب النسخ في الفصل الثامن إلا حين يظهر أول اختلاف في مخرجات النموذج نفسه.

مهام انحدار النهاية إلى النهاية وبادئة المسار

بعد أن يحدد عزو الفشل الخطأ الأول وفئته، تأتي الخطوة التالية: صوغ هدف الإصلاح في صورة حالة اختبار قابلة لإعادة التشغيل، أي مهمة انحدار (regression task). وهنا يلزم مستويان متكاملان: مهام الانحدار من النهاية إلى النهاية تتحقق من أن التغيير لم يكسر سير العمل كاملًا؛ أما مهام الانحدار على بادئة المسار (trajectory prefix) فتقتطع الحالة السابقة للخطأ الأول مباشرة ولا تتحقق إلا من إصلاح حدّ القرار ذاك.

تبدأ مهام الانحدار من النهاية إلى النهاية من الحالة الابتدائية وطلب المستخدم، وتدع الوكيل يُنجز المهمة كاملة، ثم تفحص الحالة النهائية والمخرج المطلوب وشروط الأمان. وهي الأقرب إلى نتيجة الإنتاج، غير أنها تجعل تحديد الخطوة التي وقع عندها الفشل عسيرًا. وتُستعمل عمومًا للتحقق من أن قدرة الوكيل في كل مجال ما زالت عند المتوقع. ومجموعات التقييم القياسية المذكورة في هذا الفصل — OSWorld وAndroidWorld وtau-bench — كلها مهام انحدار من النهاية إلى النهاية.

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

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

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

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

التجربة 7-7 ★★: تقييم حدود بادئة المسار بتمثيلات متعددة

يُعطى النموذج ذاكرة معروفة وتعليمات حالية وبادئة مسار ونتائج أدوات وحالة بيئة، ويعيد الفعل التالي القابل للملاحظة فقط. تغطي الحالات تعارض النطاق والتفضيلات القديمة والاستنتاج منخفض الثقة والتأكيد قبل الحذف والمعاينة قبل النشر. تُرمّز الحالات الإحدى عشرة بصيغ JSON Cards وMarkdown وPython-like وتفحصها قواعد حتمية. اكتملت 33/33 خلية بلا أخطاء API، ونجحت كل صيغة في 6/11؛ تغيير التمثيل وحده لا يصلح سياسة الاستخدام.

في اختيار النموذج العملي، غالبًا ما نواجه السؤال: “أيهما أفضل، أ أم ب؟” توفر المقارنة الزوجية طريقة تقييم لا تعتمد على الدرجات المطلقة.

المقارنة الزوجية وتصنيف النماذج

تصنيف إيلو (Elo Rating) (المستند في أصله الإحصائي إلى نموذج برادلي-تيري Bradley-Terry) يقيس القدرة النسبية للنماذج من خلال عدد كبير من المقارنات الزوجية: كلما زاد فارق النقاط بين نموذجيم، ارتفع معدل الفوز المتوقع للنموذج الأقوى. على سبيل المثال، إذا كان للنموذج أ تصنيف 1200 وللنموذج ب تصنيف 1000، يتوقع نظام Elo أن يبلغ معدل فوز (أ) حوالي 76%. وإذا حقق (ب) فوزًا غير متوقع، يكتسب المزيد من النقاط، مما يسمح للتصنيفات بالتقارب السريع نحو القدرة الحقيقية.

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

عندما يتم إجراء التحكيم المزدوج بواسطة LLM بدلاً من التصويت البشري، يجب أيضًا الحذر من تحيز المنصب - يفضل نموذج التحكيم بشكل منهجي ظهور المرشح في موضع معين (الأول عادةً)، وقد يظل الحكم دون تغيير حتى إذا تم تبديل محتوى المرشحين بالكامل. تتمثل طريقة التخفيف القياسية في تقييم كل زوج مرتين بترتيب متبادل: مرة مع A أولاً، ومرة ​​مع B أولاً، ومتوسط ​​النتيجتين؛ النهج الأكثر صرامة هو احتساب الحالات التي يكون فيها الحكمان متسقين فقط، ومعالجة التناقضات على أنها روابط أو إرسالها للمراجعة البشرية. نهج Chatbot Arena هو نفسه بشكل أساسي، وهو توزيع مواضع العرض للاستجابتين بطريقة عشوائية بحيث يتم إلغاء تحيز الموضع على عينة كبيرة.

التجربة 7-8 ★★: إنشاء لوحة صدارة نموذجية من بيانات المقارنة الزوجية

تهدف هذه التجربة إلى الفهم العميق لكيفية استخلاص نموذج برادلي-تيري لدرجات القدرة النسبية من عدد كبير من المقارنات الزوجية من خلال تطبيق نظام حساب تصنيف Elo من الصفر. استخدم مجموعة بيانات التصويت الحقيقية مفتوحة المصدر من Chatbot Arena (التي تحتوي على ملايين الأصوات العمياء للمستخدمين المجهولين).

تنفيذ خوارزمية التحديث التكراري لتصنيف Elo: تهيئة جميع النماذج بتصنيف 1000. معالجة سجلات التصويت بالترتيب الزمني. لكل مباراة، احسب معدل الفوز المتوقع استنادًا إلى فرق التقييم الحالي بين النموذجين، وقارن النتيجة الفعلية مع التوقعات، واضبط التقييمات بمعدل تعلم ثابت - يكسب الفائز نقاطًا، ويخسر الخاسر نقاطًا، مع تناسب حجم التعديل مع الانحراف عن التوقع (تؤدي الخسارة المفاجئة إلى تغيير أكبر في التصنيف). فرز النماذج بترتيب تنازلي حسب التصنيف النهائي وحساب مصفوفة معدل الفوز الزوجي. قارن مع لوحة المتصدرين الرسمية للتأكد من أن التصنيف متسق بشكل عام. ليست هناك حاجة إلى محاذاة دقيقة لنقطة بنقطة: يستخدم Chatbot Arena الرسمي تقدير احتمالية برادلي-تيري الأقصى (حل جميع المطابقات في وقت واحد، بغض النظر عن ترتيب التصويت)، بينما يستخدم هذا التنفيذ تحديثات Elo الإضافية عبر الإنترنت (تتأثر النتائج بمعدل التعلم K-factor وترتيب المعالجة). ينبغي أن تسفر الخوارزميتان عن تصنيفات عامة متسقة، لكن الدرجات المحددة لن تكون متطابقة تمامًا.

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

اختيار النموذج القائم على التقييم

لا يقتصر اختيار النموذج على مجرد “اختيار النموذج الأقوى”؛ فهو يتضمن إجراء مقايضات تعتمد على التقييم عبر أبعاد متعددة بناءً على سيناريو التطبيق.

الأبعاد الرئيسية للاختيار

الإنتاجية وزمن الاستجابة هما مجموعتان من المقاييس التي يسهل الخلط بينها؛ إن فك تشابكها لا يتطلب سوى حقيقة واحدة، وهي أن استنتاج LLM يتم على مرحلتين. تقوم التعبئة المسبقة بقراءة السياق بالكامل مرة واحدة وتحدد وقت ظهور الرمز المميز الأول (TTFT): التأخير بين ضغط المستخدم على Enter وظهور الحرف الأول. كلما كان السياق أطول، كانت عملية التعبئة المسبقة أبطأ وزاد معدل TTFT. يقوم فك التشفير بعد ذلك بإنشاء رمز الرد المميز تلو الآخر، مع ضبط سرعة الإنشاء (الرموز المميزة/الثانية) - والتي تحدد أيضًا وقت التفكير: عند 50 رمزًا/ثانية، يقضي النموذج الذي ينتج 2000 رمزًا للتفكير 40 ثانية في التفكير فقط.

حول هاتين المرحلتين، تكون مقاييس الإنتاجية وزمن الوصول الرئيسية كما يلي:

• مخرجات الإدخال / إنتاجية المخرجات: تتوافق مع سرعة الملء المسبق وفك التشفير، على التوالي.
• TTFT: يساوي وقت الانتظار بالإضافة إلى وقت التعبئة المسبقة؛ إنها “الاستجابة” التي يدركها المستخدم.
• زمن وصول التفكير: يمكن أن يختلف عدد رموز التفكير المميزة التي تم إنشاؤها عدة مرات عبر النماذج، ولا يرتبط طول التفكير بالضرورة بشكل إيجابي بفعالية المهمة - قم بقياس استخدام رمز التفكير المميز لكل نموذج والفائدة المقابلة على عبء العمل الخاص بك، بدلاً من الاستدلال من لوحات المتصدرين العامة وحدها.
• p95 Tail Latency: زمن الاستجابة الذي لن تتجاوزه 95% من الطلبات. وهو مؤشر أفضل لتجربة المستخدم الحقيقية من المتوسط، والذي يمكن أن ينخفض ​​بسبب عدد كبير من الطلبات السريعة، مما يخفي التباطؤ الشديد الذي تعاني منه أقلية من المستخدمين.

التكلفة: تسعير رموز الإدخال والإخراج/ذاكرة التخزين المؤقت. لا ينبغي تقييم التكلفة بشكل منفصل - فالنموذج الرخيص ذو معدل النجاح المنخفض قد يؤدي في الواقع إلى تكبد تكاليف أعلى بسبب إعادة المحاولة المتكررة. يجب حساب متوسط ​​التكلفة لكل مهمة ونسبة التكلفة إلى الأداء.

الأداء: التعريفات الدقيقة لـ Pass@1 وPass^k وPass@k وBest@k مذكورة سابقًا في “نظام مقاييس التقييم”. هنا، نناقش فقط كيفية الاختيار في سياق اختيار النموذج - بالنسبة للسيناريوهات اليومية، ركز على Pass@1 (متوسط ​​معدل النجاح لمحاولة واحدة)؛ بالنسبة للعمليات الحرجة، قم بإعطاء الأولوية لـ Pass^k، مع التركيز على ثبات “عدم ارتكاب أي خطأ مطلقًا”؛ بالنسبة للمهام الاستكشافية، قم بإعطاء الأولوية لـ Pass@k أو Best@k، مع النظر إلى الحد الأعلى من القدرة عند توفر فرص كافية؛ بالنسبة للمهام ذات النهايات المفتوحة، استخدم نقاط تقييم متعددة الأبعاد.

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

منحنيات الميزانية والقدرة: لا تكفي درجة واحدة بميزانية ثابتة لتحديد ما إذا كان الوكيل يمكنه التعامل مع العمل طويل المدى. بالإضافة إلى معدل النجاح، قم بالإبلاغ عن كيفية تغير الأداء مع وقت ساعة الحائط أو الرموز المميزة أو استدعاءات الأدوات أو ميزانية الحساب. يجعل RE-Bench المشكلة ملموسة: مع ميزانية إجمالية تبلغ ساعتين لكل بيئة، سجل أفضل وكيل حوالي أربعة أضعاف ما سجله الخبراء البشريون؛ ومع ذلك، استفاد البشر أكثر من الوقت الإضافي، وتجاوزوا بفارق ضئيل أفضل وكيل في ثماني ساعات، وسجلوا أعلى مستوى تقريبًا عندما تم منح محاولات متعددة 32 ساعة إجمالية¹. وبالتالي فإن القيادة ذات الميزانيات القصيرة لا يمكن استقراءها بشكل مباشر على القدرة طويلة الأمد. يجب أن يقارن اختيار النموذج عدة نقاط ميزانية قريبة من مدة عبء العمل الحقيقي.

من الناحية العملية، يمكنك مزج النماذج: نماذج خفيفة الوزن للطلبات البسيطة لخفض التكاليف، ونماذج قوية للمهام المعقدة لحماية الجودة؛ أو نماذج متخصصة في مهام فرعية معينة (فهم الصور، وإنشاء التعليمات البرمجية)، والتعاون من خلال آليات الوكيل الفرعي. يجب التحقق من صحة أي مجموعة غير متجانسة من هذا القبيل عن طريق التقييم، للتأكد من أن الفائدة الإجمالية تفوق التعقيد الإضافي للنظام（كأن تُعدّ أسئلةٌ من قبيل «أيّهما أكبر: 9.9 أم 9.11؟» و«أريد غسل السيارة، وبيتي يبعد عن المغسلة 50 مترًا، أأمشي أم أقود؟» أسئلةً بسيطةً فتُحال إلى نموذجٍ خفيف، فيقع الخطأ في القرار).

سلوك النموذج: متى يتوقف عن القراءة ويبدأ التعديل؟

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

ولهذا الميل عند الوكيل مصدران: أوّلُهما موجّهُ النظام في الـ Harness، وثانيهما سياسةُ سلوك النموذج. والتدريبُ اللاحق مصدرٌ أساسٌ لسياسة سلوك النموذج: فمساراتُ SFT تُري النموذجَ «إلى أيّ حدٍّ يقرأ قبل أن يبدأ العمل»، ومكافأةُ العملية تكافئ مسارَ أدواتٍ بعينه أو تعاقب عليه، ومكافأةُ النتيجة تعزّز السياسةَ كلَّها التي انتهت إلى النجاح. وشيئًا فشيئًا، لا يتعلّم النموذجُ كيف يكتب الشيفرةَ فحسب، بل يتعلّم كذلك عاداتٍ هندسية.

التجربة 7-9 ★★: قياس عتبة فعل النموذج داخل Coding Harness ثابت

الهدف: عزل عامل النموذج، وقياس المفاضلة الافتراضية لدى نماذج البرمجة بين مواصلة جمع المعلومات وبدء التعديل، وتقييم كفاءة المسار مع جودة النتيجة.

الطريقة: شغّل chapter6/model-action-threshold/experiment.py. يستدعي الإعداد الافتراضي GPT-5.6-sol وClaude Sonnet 5 عبر نقطة OpenRouter OpenAI-compatible الطرفية نفسها، مع تثبيت موجّه النظام وSchema الأدوات ومستودعات المهام وأوامر الاختبار والحد الأقصى للجولات. لا يحدد الموجّه المحايد حدًا أدنى لعدد الملفات المقروءة ولا يطلب التعديل السريع. كرر كل فئة من فئات المهام الثلاث ثلاث مرات على الأقل، وبدّل ترتيب النموذجين. سجّل استدعاءات الأدوات والملفات المقروءة وعمليات البحث ووقت الحائط قبل أول تعديل، إلى جانب قبول أول رقعة مختبرة، وإعادة العمل بعد الاختبار، والنجاح النهائي، والملفات المعدلة، واستخدام Token.

التفسير السببي: تسأل الحملة المحايدة هل يتغير السلوك مع النموذج داخل Harness واحد. ولقياس أثر الـ Harness بوصفه عامل تعديل، شغّل حملة منفصلة باستخدام --policy explore-first، ولا تخلط الـ policyين في مقارنة نموذج واحدة. السلوك الذي يتغير عند تبديل النموذج ويستمر للنموذج نفسه عبر Harnesses مختلفة دليل أقوى على أثر النموذج؛ والعكس يدعم أثر الـ Harness أكثر.

معايير القبول: نجاح جميع اختبارات الوحدة غير المتصلة؛ والتأكد أولًا من أن fixture كل مهمة يفشل اختبارات حالته الابتدائية؛ واحتواء النتيجة الرسمية على جميع خلايا النموذج × المهمة × التكرار، وصفر أخطاء API، واختبار نهائي مستقل، ومسارات قابلة للتدقيق؛ وأن يتحقق manifest.json من بصمات ملفات الإعداد والملاحظات والملخص. يتضمن مجلد المشروع تشغيلًا حقيقيًا مكتملًا لكل الخلايا 18/18. وينبغي للقارئ إعادة التجربة على إصدارات النماذج وأعباء العمل الحقيقية التي تهمه، لا اعتبار أرقام هذه المستودعات المصغرة ترتيبًا دائمًا.

تحليل تكلفة أنظمة الوكيل

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

مكونات التكلفة.

يمكن تقسيم تكلفة نظام الوكيل إلى ثلاثة مستويات:

تكلفة استنتاج النموذج هي المكون الأكثر مباشرة، ويتم تحديدها من خلال استهلاك الرموز المميزة للإدخال والرموز المميزة للمخرجات. ومع ذلك، في سيناريوهات الوكيل، هناك عاملان مضخمان غالبًا ما يتم تجاهلهما. الأول هو تأثير تراكم السياق: في كل مرة يستدعي الوكيل LLM، فإنه يرسل كل محفوظات المحادثة السابقة ومخرجات الأداة معًا (حتى يتمكن النموذج من فهم السياق). بدون الاستخدام الفعال لـ KV Cache (أي التخزين المؤقت للسياق الذي تمت معالجته بالفعل لتجنب العمليات الحسابية المتكررة)، تنمو التكلفة بسرعة كبيرة - ترسل الجولة 1 1000 رمزًا مميزًا، وترسل الجولة 2 2000 رمزًا مميزًا، وترسل الجولة 3 3000 رمزًا مميزًا، بإجمالي 1000+2000+3000=6000 بدلاً من 3×1000=3000. كلما زاد عدد الجولات، زادت الفجوة. والثاني هو تكلفة التفكير المميزة: النماذج التي تدعم التفكير تولد عددًا كبيرًا من رموز التفكير المميزة. على الرغم من عدم عرض هذه الرموز المميزة للمستخدم، إلا أنه لا يزال يتم إصدار فاتورة بها.

تكلفة استدعاء الأداة تشمل رسوم API الخارجية (تفرض محركات البحث رسومًا على كل استعلام، وتستهلك استعلامات قاعدة البيانات موارد الحوسبة)، وموارد وضع الحماية لتنفيذ التعليمات البرمجية، وتكلفة غير مباشرة يتم التغاضي عنها بسهولة: كلفة الرموز التي يتم تكبدها عند إدخال مخرجات الأداة في السياق. قد يشغل المحتوى الذي يتم إرجاعه من بحث ويب واحد ما بين 2000 إلى 5000 رمزًا مميزًا، وستتم محاسبته بشكل متكرر كمدخل في كل جولة لاحقة من الاستدلال.

تكلفة البنية التحتية تغطي النفقات التشغيلية لقواعد بيانات المتجهات (المستخدمة لاسترجاع RAG)، وقوائم انتظار الرسائل، وقواعد البيانات العلائقية، وتخزين التسجيل والتتبع (لقابلية الملاحظة).

لرؤية مصادر التكلفة الفعلية، استخدمت التجربة المصاحبة سير عمل ثابتًا من ثماني جولات لاسترداد الأموال: الاستعلام عن الطلب والشحن وسياسة الاسترداد وقاعدة المعرفة، ثم فحص المخاطر وتنفيذ الاسترداد وإخطار المستخدم وإغلاق الحالة. شُغّلت استدعاءات gpt-4o-mini حقيقية في التركيبات الأربع لمفتاحين: بادئة مستقرة أو غير مستقرة، وسجل كامل أو مضغوط. ظل العمل المنجز واحدًا في كل مجموعة، ويستخدم الجدول 7-4 أعداد الرموز والأسعار المسجلة في تلك الجولة.

الجدول 7-4 التكلفة المقاسة لسير عمل الوكيل ذي الثماني جولات

في خط الأساس، ارتفع الإدخال من 1,113 رمزًا في الجولة الأولى إلى 3,668 في الأخيرة. وتكررت نتائج الأدوات في الطلبات اللاحقة، فشكّلت 9,544 رمز إدخال عبر التشغيل. ومع تفعيل التحسينين انخفض الرقم إلى 5,248 وهبطت التكلفة الإجمالية بنسبة 30%.

لم تكن المكاسب قابلة للجمع. وفّرت البادئة المستقرة وحدها 28.3%، ووفّر الضغط وحده 17.5%، لكن جمعهما وفّر 30% لا 45.8%. فضغط السجل يقلّص أيضًا البادئة المتاحة لإعادة استخدام ذاكرة التخزين المؤقت. عند جمع تحسينات السياق، قِس سير العمل كاملاً ولا تجمع نسب التوفير المنفردة. سيتغير رقم 30% بتغير النموذج أو الأسعار أو طول المهمة؛ والنتيجة القابلة للتعميم هي تصميم المجموعات الأربع، لا النسبة نفسها.

استراتيجيات تحسين التكلفة.

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

معالجة الدُفعات غير المتزامنة تعمل على تجميع المهام في غير الوقت الفعلي لمعالجة الدُفعات، مما يؤدي إلى الاستفادة من خصومات أسعار الدُفعات من موفري API؛ وفي سيناريوهات النشر الذاتي، تعمل أيضًا على تحسين استخدام وحدة معالجة الرسومات (GPU) خارج ساعات الذروة.

مراقبة التكاليف ومراقبة الميزانية.

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

التجربة 7-10 ★: تحليل التكلفة الشاملة لمهام الوكيل

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

المنهج الفني: أعد أولاً تشغيل المهمة الثابتة في المستودع المصاحب، ثم اختر عدة مهام تمثيلية من عملك. استخدم LangSmith أو نظام تتبع خاصًا لتسجيل رموز الإدخال والإخراج والتفكير، وعدد استدعاءات الأدوات وأحجام نتائجها، وزمن الاستجابة من طرف إلى طرف لكل استدعاء LLM. احسب المتوسط وp50/p95/p99 وتوزيع بنود التكلفة لكل نوع مهمة.

معايير القبول: أنشئ تقرير التكلفة وحدد محركاتها الأساسية. شغّل التركيبات الأربع كلها، وقِس كل تحسين منفردًا ثم الاثنين معًا. عند تغيير النموذج، أعد التجربة بدل نقل نسبة التوفير من المسار المحفوظ.

التكرار المستمر القائم على التقييم

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

لنفترض أن نظام الوكيل الخاص بك مبني حاليًا على Claude، وهو متميز في استدعاء الأدوات والتنسيق المعقد. في أحد الأيام، أصدرت Gemini نموذجًا جديدًا، وتظهر المعايير العامة أنها تتفوق على Claude في عدة مقاييس وبسعر أقل. في هذه المرحلة، سؤالك ليس “هل Gemini أفضل من Claude؟” ولكن “في مهامي المحددة، هل Gemini أفضل من Claude؟ إلى أي مدى أفضل؟ ما هي تكلفة التبديل؟”

يمكن لفريق لديه نظام تقييم قوي الإجابة على هذا السؤال في ساعات: تشغيل النموذج الجديد على مجموعة بيانات التقييم الخاصة به ومقارنة معدل نجاح المهمة ودقة استدعاء الأداة وزمن الاستجابة والتكلفة. قد تجد أن النموذج الجديد أفضل وأرخص في المهام البسيطة، ولكن في السيناريوهات الأساسية التي تتضمن تنسيقًا معقدًا للأدوات متعددة الجولات، ينخفض ​​معدل نجاحه بنسبة 5%. بمجرد التأكد من أن الفرق يتجاوز ضوضاء أخذ العينات المقدرة (راجع “الأهمية الإحصائية لنتائج التقييم” أدناه)، يصبح قرارك استراتيجية مختلفة - ترحيل المهام البسيطة إلى النموذج الجديد لخفض التكاليف، والحفاظ على النموذج الأصلي في المهام المعقدة لحماية الجودة - بدلاً من التبديل الشامل الأعمى. لا يمكن اتخاذ مثل هذه القرارات التفصيلية والمبنية على البيانات إلا من خلال نظام تقييم مبني مسبقًا.

التجربة 7-11 ★★: قياس أداء النموذج متعدد الأبعاد

قم بإجراء معيار شامل لموفري نماذج LLM السائدين وموفري API المختلفين لبناء قاعدة بيانات قرارات اختيار النماذج متعددة الأبعاد.

حدد نطاق الاختبار: نماذج SOTA مغلقة المصدر مثل سلسلة GPT، وسلسلة Claude، وسلسلة Gemini، وسلسلة Doubao، ونماذج مفتوحة المصدر مثل Qwen، وKimi، وDeepSeek. اختبار نفس النموذج مع موفري API المختلفين (على سبيل المثال، DeepSeek الرسمية مقابل Siliconflow) للتحقق من النتائج من منصات مراقبة أداء الطرف الثالث (على سبيل المثال، التحليل الاصطناعي).

تصميم أحمال عمل الاختبار الموحدة: تستخدم اختبارات إنتاجية الإدخال سياقات ذات طول ثابت (رموز 8K/32K/128K)، وتطلب اختبارات إنتاجية المخرجات استجابات ذات طول ثابت (512/2048 رمزًا). تتضمن اختبارات زمن الاستجابة TTFT (الوقت حتى أول رمز مميز) وزمن الاستجابة الشامل. بالنسبة للنماذج التي تدعم التفكير، قم بقياس طول التفكير وزمن وصول التفكير بشكل منفصل. لكل تكوين، قم بإجراء 100 طلب على الأقل وحساب الانحراف المعياري، p50، p95، وp99؛ يشير التباين العالي في زمن الوصول إلى تجربة مستخدم غير مستقرة.

تقييم مدى توفر API واستقراره: قم بإجراء فحص مرة واحدة كل ساعة لمدة أسبوع، وقم بتسجيل معدل النجاح وأنواع الأخطاء ومدة الفشل. حساب معدل الفشل، وMTTR (متوسط ​​وقت الاسترداد)، وأطول وقت تشغيل مستمر. اختبر الحدود الفعلية لحدود المعدل — قم بزيادة التزامن تدريجيًا للعثور على نقطة الاختناق، وتسجيل حدود RPM/TPM. حساب التكلفة الشاملة: جمع معلومات التسعير (أسعار الوحدات للرموز المميزة للإدخال/الإخراج/التخزين المؤقت)، والنظر في تأثير KV Cache، وحساب متوسط ​​التكلفة لمهام الوكيل النموذجية متعددة الجولات.

التجربة 7-12 ★★: تقييم الاختيار الشامل لأنظمة ذاكرة المستخدم

المتطلبات الأساسية: يجب إكمال تجربة الاسترجاع السياقي أو تجربة RAG من الفصل 3.

الهدف: إجراء تقييم شامل لاختيار النموذج لوكيل استرداد ذاكرة المستخدم، وفحص كيفية تأثير نموذج التضمين وإعادة الترتيب والنموذج الرئيسي للوكيل بشكل مشترك على جودة الاسترداد وزمن الوصول والتكلفة. أعد استخدام chapter3/contextual-retrieval-for-user-memory أو chapter3/agentic-rag-for-user-memory، وقارن التكوينات في 60 حالة اختبار.

القبول: قم بتقييم كل نقطة من نقاط الاختيار الثلاث على التوالي - نموذج التضمين (BGE-M3 / OpenAI / Doubao، وما إلى ذلك، وسجل أعلى 5 دقة استرجاع، وزمن الوصول، والتكلفة)، وإعادة الترتيب (بما في ذلك خط الأساس “بدون إعادة ترتيب”، وقياس قيمته الهامشية)، والنموذج الرئيسي (مقارنة معدل النجاح وكفاءة استخدام الأداة تحت نفس تكوين الاسترجاع). المفتاح هو تحديد أوجه التآزر بين المكونات: التضمين الأقوى قد يجعل أداة إعادة الترتيب زائدة عن الحاجة، والنموذج الرئيسي الأقوى قد يعوض عن أوجه القصور في الاسترجاع. فالاختيار عبارة عن مقايضة نظامية، وليس مجرد مسألة اختيار العنصر الأقوى بمعزل عن غيره. تفاصيل التكوين موجودة في المستودع المصاحب.

الأهمية الإحصائية لنتائج التقييم

مجموعةُ التقييم محدودة، ومخرجاتُ النموذج فيها عشوائية؛ ولذلك قد لا يكون فرقُ الدرجات إلا ضجيجَ عيّنات. فإذا قِسْتَ معدّلَ نجاحٍ $p$ على $n$ حالة، أمكن تقديرُ الخطأ المعياري تقديرًا تقريبيًّا هكذا:

فمع 100 حالة ومعدّل نجاح 70%، يكون مجالُ الثقة 95% نحو $70\%\pm9$ نقطة مئوية؛ ومن ثمّ فإن «النموذج الجديد 73% مقابل القديم 70%» لا يكفي لدعم قرار التبديل.

وعند مقارنة إعدادين على الدفعة نفسها من المهامّ، ينبغي تقديمُ التحليل المزدوج: سجّل في كل سؤالٍ من الفائز، واحكم على الفرق باختبار McNemar أو بالـ bootstrap المزدوج، بدل طرح معدّلَي نجاحٍ مستقلَّين طرحًا مباشرًا. ولأن تشغيلَ الوكيل نفسه قد يختلف في كل مرة، فالأفضل أن يُشغَّل كلُّ إعدادٍ ببذورٍ عشوائية متعدّدة (3–5 مرات مثلًا)، ويُبلَّغ المتوسطُ ومدى التذبذب؛ أما التشغيلةُ الواحدة فلا تصلح إلا لغربلة الاتجاه. وإذا كان العائدُ المتوقَّع نقطتين أو ثلاثًا فحسب، ولم تحتوِ مجموعةُ التقييم إلا على عشرات الأسئلة، فوسِّع العيّنةَ أولًا؛ فالخطأ المعياري يتقلّص بمقدار $1/\sqrt{n}$.

for task in paired_tasks:
    for seed in fixed_seeds:
        a = run(config_a, task, seed)
        b = run(config_b, task, seed)
        record_paired_delta(verifier(a), verifier(b))

return paired_bootstrap_or_mcnemar(all_deltas)

ومعنى الازدواج أن تتشارك المجموعتان المهامَّ والظروفَ العشوائية، لا أن تُؤخذ عيّنتان منفصلتان ثم يُقارَن متوسطاهما.

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

إمكانية ملاحظة الوكيل

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

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

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

تم بناء إمكانية ملاحظة الوكيل على أساس الآثار، التي ترث بنية بياناتها مباشرة نموذج شجرة الامتداد من الأنظمة الموزعة: يتوافق تنفيذ مهمة واحدة مع تتبع واحد، حيث يكون كل استدعاء LLM، وكل استدعاء أداة، وكل عملية استرجاع span (وحدة تنفيذ تسجل الإدخال/الإخراج، وأوقات البدء/الانتهاء، واستهلاك الرموز، ومعلومات الخطأ). تشكل العلاقات بين الأصل والفرع بين الامتدادات شجرة تنفيذ - على سبيل المثال، قد يحتوي نطاق “Agent Main Loop” على عدة امتدادات فرعية “LLM Call” و”Tool Call” معلقة تحتها. البروتوكولات القياسية متاحة بالفعل لهذه الطبقة: OpenTelemetry هو معيار التتبع الموزع للأغراض العامة، في حين أن المواصفات مثل OpenInference تحدد الاصطلاحات الدلالية الخاصة بـ LLM فوقها (كيفية تسجيل الموجّهات، ومعلمات النموذج، واستخدام الرمز المميز، وما إلى ذلك). وتتمثل ميزة اعتماد البروتوكولات القياسية في فصل الجمع والتحليل - حيث يمكن ربط نفس بيانات التتبع بواجهات خلفية مختلفة للتحليل، مما يؤدي إلى تجنب تقييد البائع.

تعد LangSmith إحدى المنصات التمثيلية في هذا المجال (تشمل المنصات المشابهة Langfuse وArize Phoenix وما إلى ذلك)، حيث تدمج إمكانية المراقبة والتقييم والتحسين في حلقة مغلقة. ينشئ كل تنفيذ جلسة تتبع، حيث يتم تسجيل استدعاءات النماذج واستخدام الأدوات واسترجاع المعرفة كوحدات تنفيذ مستقلة، مرتبطة بعلاقات سببية لتشكيل شجرة تنفيذ. تسجل كل وحدة المدخلات/المخرجات الكاملة، ومعلومات التوقيت، وبيانات التكلفة، ومعلومات الخطأ. يستخدم النظام الأساسي جمع بيانات دفعة غير متزامنة للتأكد من أن التتبع نفسه لا يؤثر على زمن استجابة الوكيل.

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

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

مع وجود نظام تقييم شامل ومجموعة بيانات، فإن المفتاح هو ترجمة نتائج التقييم إلى تحسينات ملموسة للنظام.

من التقارير المعيارية إلى تحسينات النظام

الحالة الآتية مأخوذة من جولة AndroidWorld حقيقية ومحدودة عمدًا في المستودع المصاحب. وتشمل أربع مهام لإعداد Wi-Fi على محاكي API 35، مع تشغيل مقترن واحد لكل مهمة. وهي ليست المعيار الكامل ذي 116 مهمة، ولا تغني عن إعادة التشغيل في بيئة API 33 المرجعية. قيمتها ليست في درجة عامة، بل في تسلسل القرارات من نتيجة إلى التي تليها.

من منظور هندسة منظومة التشغيل، يعرض هذا القسم منهجًا تكراريًا لتحسين المنظومة: نستخدم بيانات التقييم لتحديد مواضع الضعف—هل السياق ناقص؟ هل تغيب بعض القيود؟ هل التحقق غير كافٍ؟ هل تصل التغذية الراجعة في وقت غير مناسب؟—ثم نجري تحسينات محددة ونعيد التقييم، فتتشكل حلقة مغلقة للتطور المستمر.

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

قراءة تقرير مرجعي: فن اكتشاف المشكلات

سجّل التقرير الأولي تشغيلًا واحدًا لكل مهمة من المهام الـ116، وبنجاح إجمالي يقارب 88%. لم تكن الأخطاء متناثرة: فشلت ثلاث من مهام SystemWifiTurn* الأربع، وأظهرت المسارات تنقلاً متكررًا ذهابًا وإيابًا من دون تأكيد الحالة النهائية. ينسجم مع الأدلة تفسيران: إما أن الوكيل لا يعرف وجهته، أو أن تمثيل الواجهة الذي يستقبله ناقص.

تحجب درجة 88% الإجمالية هذه المجموعة الصغيرة والمتماسكة من الأخطاء. وزيادة حد الخطوات مضللة بدورها؛ فقد تعيد وصف «الوكيل لا يرى عنصر التحكم» على أنه «يحتاج إلى مزيد من المثابرة». اقرأ التقرير من التفاصيل إلى الأعلى: حدد التجمعات بحسب المهمة ووسم القدرة، وأعد تشغيل المسارات، وحدد هل نشأ الفشل في الملاحظة أم الاستدلال أم الفعل أم التحقق، ثم اختر متغيرًا واحدًا لتغييره. استُخدمت شريحة Wi-Fi لتشخيص الآلية بتكلفة منخفضة، لا لتقدير أداء النظام كله.

من البيانات إلى الفرضيات: بناء خارطة طريق للتحسين

اختبرت الجولة الأولى أبسط تفسير وأقلّه كلفة. افترض H1 نقص معرفة التنقل، ولذلك تلقى فرع التجربة وحده تعليمات للوصول إلى Wi-Fi والتحقق من الحالة النهائية. لم يتحسن النجاح؛ لم يكن الموجّه هو عنق الزجاجة.

سألت الجولة الثانية: ما الذي يراه الوكيل فعلاً؟ استبدل H5 قناة accessibility غير المتوافقة مع API 35 بشجرة UIAutomator المدعومة في AndroidWorld. ارتفع النجاح، لكن الشجرة الكاملة رفعت استهلاك الرموز بشدة. لذلك لم يضف H5C معلومات جديدة؛ بل حذف عقد الحاويات غير المرئية والخالية من النص وغير القابلة للتفاعل، لاختبار إمكان الحفاظ على النجاح بضوضاء أقل.

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

من النتائج إلى القرارات: المقايضات القائمة على البيانات

يلخص الجدول 7-5 النتائج المقاسة. ومع أربع مهام فقط في كل فرع، تكفي هذه الأرقام لتقرير جدوى تشغيل أوسع، لكنها لا تقدّر النجاح على AndroidWorld كله.

الجدول 7-5 ثلاث جولات على شريحة Wi-Fi من AndroidWorld

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

التكرار المستمر: من التحسين الأول إلى تطور النظام

نجاح H5C في أربع مهام يؤهله لاختبار أكبر فقط، لا للنشر. والبوابة التالية تشغيل المهام الـ116 كلها بخمس بذور في بيئة Pixel 6 / API 33 المرجعية، مع مجموعة التطبيقات الخارجية الكاملة. يجب ألا يتراجع النجاح، وأن تكون نسبة الرموز ≤0.75 ونسبة زمن الاستجابة ≤1.5. وحتى اكتمال ذلك، لا يجوز عرض نتيجة 4/4 في الشريحة على أنها نجاح للنظام كله بنسبة 100%.

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

التجربة 7-13 ★★★: التقييم والتحسين في AndroidWorld

تطبق هذه التجربة المسار الكامل من تقرير التقييم إلى تحسين النظام. ابدأ بالتقرير التاريخي وبالجولات المقترنة الثلاث المحفوظة في chapter6/android-world.

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

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

الخطوة 3: التجريب المرحلي. أعد إنتاج H1 وH5 وH5C مع تغيير متغير واحد في كل جولة. سجّل الرموز وزمن الاستجابة والانحدارات إلى جانب النجاح.

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

الخطوة 5: التكرار. لا تنقل تجربة الشريحة الناجحة إلا إلى التشغيل الكامل. لا تناقش النشر قبل تشغيل 116×5 في البيئة المرجعية، واحتفظ في التقرير بفروق البيئة وحجم العينة وحدود النطاق.

من التقييم الخارجي إلى الداخلي: بنية تقييم للوكلاء على مستوى الإنتاج

لقد قام هذا الفصل حتى الآن بتقييم أنظمة الوكلاء من الخارج - بناء بيئة تقييم، وتصميم مجموعات البيانات، وتحليل التقارير المعيارية. لكن أفضل منتجات الوكيل تقوم بأكثر من مجرد الخضوع للتقييم الخارجي؛ فهم يبنون بنية تحتية للتقييم الذاتي المستمر في المنتج. أدناه، باستخدام الوكيل المفتوح المصدر للأغراض العامة OpenClaw الذي تم تقديمه في الفصل 5 كمثال وبالاعتماد على التحليلات الفنية العامة لمنتجات Coding Agent الرائدة ورؤى الممارسين، نقدم نظام تقييم داخلي يستحق المحاكاة: واحدة تدمج بشكل منهجي المنهجية التجريبية لأبحاث تعلم الآلة في هندسة المنتج.

البنية التحتية للاستئصال: فهم المساهمة الحقيقية لكل ميزة

لقد استخدم باحثو تعلم الآلة منذ فترة طويلة دراسات الاستئصال لمعرفة أي مكونات النموذج ذات أهمية فعلية - الاستئصال يعني “إزالة” مكون واحد في كل مرة ومراقبة مقدار انخفاض الأداء العام. يجلب OpenClaw هذه المنهجية إلى هندسة المنتج: يمكن للمحول الرئيسي المدمج تعطيل العديد من الميزات الرئيسية في وقت واحد (وضع التفكير، وضغط السياق، والذاكرة التلقائية، ومهام الخلفية، والمزيد)، مما يؤدي إلى إنشاء خط أساسي “للنموذج المجرد”. يتيح ذلك للفريق الإجابة على سؤال رئيسي: هل تعمل الميزة حقًا على تحسين تجربة المستخدم، أم أنها تبدو مفيدة فقط؟

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

منهجية اختبار أ/ب: تمييز الآلية عن الهدف

تجري منتجات Mature Agent اختبارات A/B صارمة على سلوكها (أي تقسيم المستخدمين عشوائيًا إلى مجموعتين، واحدة تستخدم الإصدار القديم والأخرى تستخدم الإصدار الجديد، ومقارنة البيانات الفعلية من كلا المجموعتين لتحديد ما إذا كان التغيير فعالاً). توضح حالة اختبار A/B للوكيل المصممة جيدًا العديد من المبادئ المنهجية الرئيسية:

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

التمييز بين مقاييس الآلية والمقاييس المستهدفة. هذا هو الخطأ الأسهل الذي يمكن ارتكابه — التعامل مع ما تقوم بتغييره على أنه هدف التحسين. على سبيل المثال، إذا كنت تختبر “تقصير طول ملف خطة الوكيل”، فإن طول الخطة هو مقياس الآلية (شيء تقوم بتغييره مباشرة)، ولكنه ليس الهدف. قد يكون الهدف الحقيقي هو “تقليل التكلفة على مستوى الجلسة”. قد يؤدي تقصير ملف الخطة إلى خفض التكاليف، ولكنه قد يؤدي أيضًا إلى المزيد من حلقات التحرير والتحقق والتحرير بسبب عدم كفاية الخطط التفصيلية، مما يؤدي إلى زيادة إجمالي الإنتاج. اسأل نفسك دائمًا: هل ما أقوم بتغييره (الآلية) هو نفس ما أهتم به حقًا (الهدف)؟ إذا لم يكن الأمر كذلك، فحدد أولويات الهدف.

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

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

نظام علم الميزات ذو طبقتين

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

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

أعلام وقت التشغيل يتم تسليم تكوينها بواسطة الخادم ويتم تخزينها مؤقتًا محليًا على القرص. يعطي التصميم الأولوية لقراءة التكوينات المخزنة مؤقتًا التي لا معنى لها على منع بدء تشغيل الوكيل أثناء انتظار طلب الشبكة. يتم اتخاذ قرارات التجميع المحددة من خلال منصة تجريبية (على سبيل المثال، GrowthBook) لتعيين مجموعات اختبار A/B. أحد تفاصيل التصميم الرئيسية هو أنه يتم تسجيل حدث التعرض لكل ميزة مرة واحدة على الأكثر في كل جلسة لتجنب السجلات المكررة التي تلوث البيانات التجريبية.

الدرس المستفاد لمطوري Agent: علامات الميزات ليست أدوات تصحيح أخطاء؛ فهي مكونات معمارية من الدرجة الأولى.

تقييم حساسية الموجّه

يعد موجّه النظام هو “الكود” الأساسي لسلوك الوكيل، ولكنه غالبًا ما يفتقر إلى التحكم في الإصدار واختبار الانحدار المتوفر للكود العادي. يتمثل نهج OpenClaw في توفير أداة مخصصة يمكنها استخراج موجّه النظام المقدمة بالكامل عند مراجعة Git أو التزام محدد - بما في ذلك النص النهائي بعد توسيع جميع الشروط الديناميكية. يتيح ذلك للفريق الإجابة بدقة: ما الالتزام الذي غيّر الموجّه؟ ما هو التأثير على مجموعة التقييم؟

أما الممارسات الموصى بها لأي فريق يبني الوكلاء فهي: (1) أن يكون توليد موجّه النظام حتميًا؛ أي أن تنتج مدخلات الإعداد نفسها المخرج نفسه دائمًا، (2) إنشاء آلية لإصدار لقطات من الموجّهات وحفظها، (3) إخضاع كل تعديل في الموجّه لاختبارات انحدار على مجموعة التقييم، تمامًا كما تخضع تغييرات الشفرة للتكامل المستمر.

التحليلات المراعية للخصوصية أساسًا للتقييم

يعتمد التقييم على بيانات جيدة، لكن منتجات Agent غالبًا ما تتعامل مع محتوى المستخدم الحساس. يحل OpenClaw هذا التناقض من خلال نظام الكتابة: تقبل واجهة التحليلات فقط القيم المضمنة في أنواع خاصة، حيث يعمل اسم النوع نفسه كمسار تدقيق - فهو يعلن صراحةً “لقد تحققت من أن هذا ليس رمزًا أو مسار ملف.” يحول هذا التصميم قيود الخصوصية من المواصفات الموثقة إلى اختبارات النوع المفروضة في وقت الترجمة.

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

من الخارجي إلى الداخلي: تحول في التفكير التقييمي

الرسالة الأساسية لهذا القسم هي: علمتك الأقسام السابقة كيفية تقييم الوكيل خارجيًا؛ يكشف هذا القسم عن كيفية تقييم أفضل منتجات الوكيل لنفسها داخليًا. يخبرك التقييم الخارجي “مدى جودة الوكيل”؛ تخبرك البنية الأساسية للتقييم الداخلي “بالتغيير الذي جعله أفضل”. تكتشف تجارب الاستئصال الميزات المهمة حقًا، ويحدد اختبار A/B تأثير كل تغيير، وتوفر علامات الميزات البنية التحتية للتجريب والتراجع، ويدمج تقييم الحساسية الفوري موجّه النظام في نظام CI، وتضمن التحليلات المدركة للخصوصية الامتثال في جمع البيانات. تشكل هذه المكونات الخمسة معًا هندسة منتج تعتمد على التقييم، ولا يتم التقييم من حين لآخر، ولكنها تدمج التقييم في كل قرار يتعلق بالمنتج.

بيئات المحاكاة: الجسر من التقييم إلى ما بعد التدريب

نقطة النهاية للتقييم ليست تسجيل النقاط، بل التحسين. لقد أظهر هذا الفصل بالفعل طريقين للتحسين: تعديل الأدوات (من التقارير المعيارية إلى تحسينات النظام) ودمج التقييم في هندسة المنتج (البنية التحتية للتقييم الداخلي). أقوى أشكال التحسين هو التدريب - عندما يتوسع الهدف من “تقييم القدرات الحالية” إلى “تنمية قدرات جديدة”، خاصة من خلال تقنيات ما بعد التدريب التي تمت مناقشتها في الفصل 8، يجب أن تتطور بيئة التقييم إلى بيئة محاكاة: ساحة لعب افتراضية حيث يمكن للوكيل التدرب بشكل متكرر وتسجيل النقاط تلقائيًا. تتمثل الاختلافات الأساسية بين بيئات المحاكاة وبيئات التقييم في: تكرار تفاعل أعلى بكثير (ملايين مقابل آلاف)، والحاجة إلى التوزيع العشوائي (لمنع حفظ تكوينات معينة)، ومتطلبات الحصول على تعليقات فورية. من وجهة نظر التطبيق، تنقسم بيئات المحاكاة إلى فئتين: البيئات الرقمية (مهام معالجة المعلومات) والبيئات المجسدة (إدراك العالم المادي ومعالجته).

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

على جانب البيئة الرقمية، يبني إطار عمل AWorld صندوق حماية خادم MCP يمكن التحكم فيه لمهام GAIA، مما يوفر 26 خادم MCP تغطي 126 وظيفة للأداة، مع تجنب الحظر والآثار الجانبية التي لا يمكن السيطرة عليها للوصول مباشرة إلى واجهات برمجة التطبيقات الحقيقية. جميع استدعاءات الأداة قابلة لإعادة التشغيل والتدقيق. تعمل بنية AWorld الموزعة على تقليل وقت التنفيذ التسلسلي التقليدي من 7695 ثانية إلى 525 ثانية (تسريع بمعدل 14.6x)، كما أن التصميم عديم الحالة للبيئة يجعل كل مثيل مستقلاً تمامًا، ويدعم التوازي الفعال.

على جانب البيئة المجسدة، يبني RoboTwin2 مهام معالجة بذراعين استنادًا إلى محرك فيزيائي، ويوزع عشوائيًا مواضع الكائنات واتجاهاتها ومظاهرها لتحسين التعميم. تتضمن مساحة المراقبة صورًا مرئية لكاميرات متعددة وحالات مشتركة، مما يحقق التحكم في الوقت الفعلي من خلال تقطيع الحركة — حيث يخطط النموذج لعدة إجراءات متتالية في وقت واحد (مفصل في الفصل 6). يوفر OSWorld إمكانية إعادة التعيين من خلال لقطات الآلة الافتراضية، ويركز AndroidWorld على أتمتة تطبيقات الهاتف المحمول. سواء كانت بيئات المحاكاة رقمية أو مجسدة، فإنها تتطلب أيضًا بيئات التنفيذ المعزولة وآليات الهوية الافتراضية التي تمت مناقشتها في الفصل الرابع (عزل الأجهزة الافتراضية/الحاويات، والوكلاء السكنيون، ومصادقة الإنسان في الحلقة، وأنظمة الملفات المشتركة)، والتي لن يتم تكرارها هنا.

التجربة 7-14 ★★: تكوين بيئة الذكاء المضمنة لـ OpenVLA وRoboTwin2

قم بإعداد بيئة محاكاة للتلاعب بالروبوت. اقرأ ch7/SimpleVLA-RL ووثائق OpenVLA لفهم بنية نموذج Vision-Language-Action (التكامل الشامل لمشفر الرؤية، ونموذج اللغة، ووحدة فك ترميز الإجراء، وإسقاط الصور والنص في مساحة دلالية مشتركة). قم بتكوين بيئة RoboTwin2، وفهم مساحة المراقبة (ثلاثية الرؤية RGB + حالة مشتركة ذات 14 بُعدًا) ومساحة العمل (ناقل التحكم ذو 14 بُعدًا). دراسة آلية التوزيع العشوائي للبيئة ومنطق القيد المكاني في move_can_pot. قم بتقييم النموذج المُدرب مسبقًا، وتسجيل معدل نجاحه، ووقت الانتهاء، وأوضاع الفشل، مع التركيز على تأثير آلية تقطيع الإجراء.

مقايضات الإخلاص وعشوائية المجال

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

ملخص الفصل

دار هذا الفصل حول سؤال واحد: كيف نعرف أن الوكيل تحسن بالفعل؟ وتتألف هذه السلسلة من أربع حلقات: أولًا تحرير ما يُعد نجاحًا (اختلاف أسس Pass@k وBest@k وPass consecutive@k)، ثم تحديد مصدر المهام (المعايير المرجعية العامة، ومجموعة العمل المبنية ذاتيًا، وعودة مسارات الإنتاج)، ثم اختيار أسلوب التحقق (من المدققات الحتمية إلى قوائم الفحص، فـRubric مع حكم النموذج اللغوي، وصولًا إلى المقارنة الزوجية)، وأخيرًا تحويل الدرجات إلى قرارات (الدلالة الإحصائية، وعزو الإخفاق، ومهام الانحدار، واختيار النموذج). ومن بيئة اختبار قابلة للتكرار ومجموعة بيانات تقاوم التسرب، إلى محكّمي LLM واختيار النموذج والتكرار القائمين على التقييم، تؤثر كل حلقة في موثوقية الخلاصة. وأضافت التجارب المقاسة أربع ملاحظات عملية: الجمع بين الذاكرة المنظمة وRAG لا يضمن التآزر؛ لا يمكن جمع وفورات التخزين المؤقت والضغط؛ اختيار الصوت المرجعي يغيّر معنى الدرجة متعددة الوسائط؛ وتمثيل المدخلات في منظومة التشغيل قد يحدد النجاح وكلفة الرموز معًا. كما ينبغي مقارنة منحنيات القدرة عبر ميزانيات متعددة، لا نقطة واحدة. وفي الإنتاج، التقييم تحقق مستمر داخل كل قرار منتج، لا اختبار عابر.

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

ويزيد تقييمُ حدود بادئة المسار هذا وضوحًا: الحصولُ على معلومةٍ واستعمالُها استعمالًا صحيحًا في القرار الحالي قدرتان مختلفتان. فالانحدارُ الشامل من طرفٍ إلى طرف يضمن ألّا تتراجع المهامُّ الأساسية، أما مجموعةُ حدود بادئة المسار (trajectory prefix) فتفحص مباشرةً الحكمَ على النطاق، وتجاوزَ التعليمات الراهنة، والاستيضاحَ، والتأكيدَ قبل الأفعال الخطرة. وما ذاكرةُ المستخدم إلا حالةٌ واحدة من هذه المنهجية العامة. فتقييمُ الوكلاء في مستوى الإنتاج ليس امتحانًا يُجرى بين الحين والحين، بل هو نظامُ تحقّقٍ يولّد باستمرارٍ مهامَّ انحدارٍ ومهامَّ حدودٍ من حالات المشكلات الحقيقية.

المنهجية الأساسية: الملاحظة ← الافتراض ← التجربة ← التحقق من الصحة ← الفهم الجديد ← فرضية جديدة، تحويل هندسة الوكيل من “الكيمياء” القائمة على الخبرة إلى الهندسة العلمية القائمة على البيانات.

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

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

أسئلة للتأمل

1. ★★ يستخدم LLM-as-a-Judge نموذجًا لغويًا لتقييم مخرجات نموذج اللغة. هل يحتوي هذا “التقييم الذاتي” على نقاط عمياء منهجية - على سبيل المثال، قد يعطي النموذج باستمرار درجات عالية لأسلوب معين من الاستجابة، وهو تفضيل لا يتوافق مع الحكم البشري؟ فكيف يمكن اكتشاف مثل هذه التحيزات وتصحيحها؟
2. ★★★ يعد التصميم “المانع للتسرب” لمجموعات بيانات التقييم أمرًا بالغ الأهمية. ومع ذلك، في النظام البيئي مفتوح المصدر، بمجرد نشر البيانات القياسية، يتم دمجها بسرعة في بيانات التدريب. هل لهذه “لعبة القط والفأر” نهاية؟ تصميم طريقة تقييم تقاوم بشكل أساسي تسرب البيانات.
3. ★★ تهدف المعايير الأربعة لـ Scale AI (توجيه الخبراء، والتغطية الشاملة، وترجيح الأهمية الموحد، والتقييم المستقل) إلى القضاء على الذاتية في التقييم. ومع ذلك، فإن بعض أبعاد المهمة (على سبيل المثال، “هل الإجابة مفيدة؟” “هل النبرة مناسبة؟”) هي أبعاد ذاتية بطبيعتها. كيف يمكن تصميم نماذج موثوقة لهذه الأبعاد الذاتية؟
4. ★★ τ-bench يقوم بتقييم الوكلاء من خلال محاكاة سلوك المستخدم الحقيقي. لكن المستخدم الذي تمت محاكاته نفسه هو LLM - وقد يقلل بشكل منهجي من بعض حالات الحافة (على سبيل المثال، المستخدمين المضطربين عاطفيًا أو غير الواضحين). كيف يمكن التحقق من جودة محاكاة المستخدم نفسه؟
5. ★★ تفترض المقارنة الزوجية (نموذج برادلي-تيري) أن التفضيلات متعدية (إذا كان A > B وB > C، ثم A > C). ومع ذلك، غالبًا ما تنتهك التفضيلات البشرية العبورية. في تقييم الوكيل، في أي سيناريوهات قد تظهر التفضيلات غير المتعدية؟ كيف يؤثر هذا على موثوقية التصنيف؟
6. ★★ يميّز هذا الفصل بين Pass@k بوصفه سقفًا للقدرة وبين Pass consecutive@k بوصفه مقياسًا لموثوقية العمل. بالنسبة إلى وكيل لا تتجاوز نسبة نجاحه في التشغيل الواحد 60%، كيف تجمع بين كلفة الفشل وكلفة إعادة المحاولة والآثار الجانبية للمهمة لتقرر أي المقياسين تُبلغ عنه وما مقدار $k$ المناسب؟
7. ★★ يقترح هذا الفصل المنهج العلمي “الملاحظة → الافتراض → التجربة → التحقق من الصحة”. ومع ذلك، من الناحية العملية، فإن مساحة سلوك الوكيل واسعة، وقد يتطلب التحقق من صحة فرضية واحدة مئات من عمليات التقييم. كيف يمكن تعظيم المعلومات المكتسبة من التقييم في ظل ميزانية حسابية محدودة؟
8. ★ في تجربة AndroidWorld، رفعت شجرة العناصر الكاملة النجاح من 25% إلى 100%، لكنها رفعت استخدام الرموز إلى 2.498× من مجموعة الضبط؛ وحافظ التقليم على نجاح 100% مع خفض الرموز إلى 0.506×. كيف تصمم قواعد تلقائية تزيل عقد واجهة المستخدم الخالية من الدلالة من دون إسقاط معلومات لازمة لإمكانية الوصول أو التحقق من الحالة أو الإجراءات اللاحقة؟
9. ★★ تستخدم محاكاة المستخدم في τ-bench “الكشف التدريجي عن المعلومات” - ولا تقدم جميع المعلومات مرة واحدة، ولكنها تكشفها تدريجيًا بناءً على أسئلة الوكيل. كيف يؤثر هذا التصميم على نتائج التقييم؟ إذا كانت استراتيجية الكشف عن معلومات المستخدم المحاكى تختلف بشكل كبير عن المستخدمين الحقيقيين، فهل لا تزال استنتاجات التقييم موثوقة؟