ما هي Agent Evals؟ قياس النتيجة والمسار معًا
Agent evals هي عملية القياس المنهجي لما إذا كان الوكيل — الذي يستخدم الأدوات ويتخذ خطوات متعددة للوصول إلى هدف — قادرًا فعلًا على إنجاز مهامه. إنها تطور لتقييمات الـ LLM، يتوسع فيه الهدف من «مخرَج واحد» إلى «سلسلة من الأفعال». ولأن الوكيل يخطط، ويستدعي الأدوات، ويحدّث الحالة، فإن المخرَج النهائي وحده لا يكفي؛ وتشير Google إلى أن عليك فهم «لماذا» وراء أفعال الوكيل، وتقسّم التقييم إلى استجابة نهائية و trajectory. الأبعاد الخمسة هي: النتيجة (نجاح المهمة، يُحكَم عليها بالحالة النهائية — ما إذا كان الحجز موجودًا في الـ DB، لا التصريح «لقد حجزتُه»)، والمسار (خطوات معقولة، أدوات صحيحة بالترتيب الصحيح)، وصحة استخدام الأدوات (الأداة والوسائط الصحيحة، مع فحص أسماء الدوال والأنواع)، والكفاءة (الخطوات، الرموز، التكلفة، زمن الاستجابة — غالبًا إشارات قابلية مراقبة مُدخَلة في التقييم)، وجودة الاستجابة النهائية (عبر LLM-as-judge أو معيار تقييم). والمُقيّمون هم الكود (سريع/رخيص/قابل لإعادة الإنتاج لكنه هشّ)، و LLM-as-judge (مرن لكنه غير حتمي ويحتاج إلى معايرة)، والبشر (المعيار الذهبي لكنه مكلف — تجنّبه إن أمكن). توصي Anthropic بتقييم النتيجة لا المسار: فمطابقة المسار الحرفية «صارمة وهشّة» لأن الوكلاء يجدون بدائل صحيحة، بينما تقدّم Google و Microsoft مقاييس مطابقة المسار لتشخيص الإخفاقات. والمزالق الخاصة هي اللاحتمية (pass^k)، والأخطاء المتراكمة (p^t)، واختراق المكافأة (ذراع روبوت DeepMind تزيّف إمساكًا)، وتقادم مجموعات التقييم أو تلوثها. والخطة العملية، وفق Anthropic: حوّل 20-50 إخفاقًا في الإنتاج إلى حالات اختبار، وشغّل التقييم الآلي في CI، وافصل تقييمات القدرة والانحدار، واكتبها مبكرًا. ومعايير مثل SWE-bench و tau-bench و WebArena و GAIA و OSWorld و BFCL مراجع مفيدة (الدرجات تتغير حسب الإصدار، فلا تأخذها على ظاهرها). استنادًا إلى المعلومات الرسمية، مع الإشارة إلى أوجه عدم اليقين.
