Anthropic تصف تقييمات evals لوكلاء الذكاء الاصطناعي: ثلاثة أنواع من المقيّمات وارتفاع SWE-bench من 40% إلى 80%

نشرت Anthropic دليلًا هندسيًا لتقييم وكلاء الذكاء الاصطناعي، وفكرته الأساسية عملية وبسيطة: من دون evals يبدأ الفريق، بعد أول إطلاق في بيئة الإنتاج، بإصلاح شيء فيكسر شيئًا آخر. يستدعي الوكيل الأدوات، ويغيّر حالة البيئة، ويتكيّف مع النتائج الوسيطة عبر خطوات كثيرة، ولذلك تتراكم الأخطاء. ويتطلب تقييم نظام كهذا الجمع بين عدة أساليب. وللتوضيح يورد المؤلفون أرقامًا: على SWE-bench Verified انتقلت النماذج من 40% إلى أكثر من 80% في عام واحد، فيما بنت Bolt نظام تقييم عاملًا في ثلاثة أشهر.

مما يتكوّن eval الوكيل

تبدأ Anthropic بالمصطلحات، لأن القطاع يستخدمها بمعانٍ متباينة. المهمة (task) هي اختبار واحد له مدخلات ومعايير نجاح. وتسمى كل محاولة trial، وتُشغَّل المحاولات عدة مرات لأن مخرجات النموذج تتغير من تشغيل إلى آخر. أما المقيّم (grader) فهو المنطق الذي يقيّم جانبًا محددًا من العمل، وقد يوجد في المهمة الواحدة أكثر من مقيّم. و Transcript هو السجل الكامل للمحاولة: الرسائل واستدعاءات الأدوات والاستدلالات. أما Outcome فهو الحالة النهائية للبيئة.

الفرق بين المفهومين الأخيرين جوهري. فقد يكتب وكيل الحجز «تم حجز رحلتك»، لكن المعتمد للاحتساب هو وجود السجل في قاعدة بيانات SQL فقط. وثمة توضيح آخر يخص ما يجري قياسه: عندما تقيّمون وكيلًا، فأنتم تقيّمون المزيج من النموذج والغلاف التشغيلي (harness)، لا النموذج وحده. وكمثال يورد المؤلفون حالة Opus 4.5 في اختبار τ2-bench. فقد وجد النموذج ثغرة في قواعد حجز الرحلة، و«أخفق» في المهمة وفق المعايير الشكلية، مع أنه ابتكر للمستخدم حلًا أفضل.

ثلاثة أنواع من المقيّمات

عادةً ما تُبنى evals الوكلاء من ثلاثة أنواع من الفحوص:

• مقيّمات قائمة على الشيفرة: فحوص السلاسل النصية وregex، واختبارات fail-to-pass، والتحليل الساكن، وفحص الحالة النهائية واستدعاءات الأدوات. وهي سريعة ورخيصة وقابلة لإعادة الإنتاج، لكنها هشة أمام الصيغ الصحيحة المختلفة للإجابة. • مقيّمات قائمة على النماذج: معايير تقييم (rubrics)، وتأكيدات بلغة طبيعية، ومقارنة زوجية، وإجماع عدة محكّمين. وهي مرنة وقابلة للتوسع، لكنها غير حتمية وأعلى كلفة وتتطلب معايرة بالرجوع إلى البشر. • مقيّمات بشرية: مراجعة الخبراء، والعمل الجماعي (crowdsourcing)، والفحص بالعينات، واختبارات A/B. وهي المعيار الذهبي للجودة، لكنها بطيئة ومكلفة.

قد تكون الدرجة النهائية للمهمة موزونة، أو ثنائية (يجب أن ينجح جميع المقيّمين)، أو هجينة. أما المفترق الثاني فهو capability-evals وregression-evals. يجب أن تبدأ الأولى بمعدل نجاح pass rate منخفض، وأن ترسم للفريق منحدرًا ينبغي تسلّقه. ويجب أن تنجح الثانية بنسبة تقارب 100% وأن تلتقط حالات التراجع. وحين تُستنفد قدرة مجموعة capability على التمييز، «تُنقل» مهامها إلى حزمة الانحدار.

وكلاء البرمجة والوكلاء الحواريون

تناسب وكلاء البرمجة بطبيعتها الفحوص الحتمية: تُشغَّل الشيفرة وتنجح الاختبارات. يمنح SWE-bench Verified الوكيل مسائل GitHub-issues من مستودعات Python الشهيرة، ولا يحتسب الحل إلا إذا أُصلحت الاختبارات التي كانت تفشل ولم تتعطل الاختبارات القائمة. ويفحص Terminal-Bench مهام تقنية شاملة من البداية إلى النهاية، مثل بناء نواة Linux من الشيفرة المصدرية أو تدريب نموذج ML. وإلى جانب الاختبارات تنصح Anthropic بتقييم transcript: عبر قواعد استدلالية لجودة الشيفرة ومعايير تقييم لسلوك الوكيل. وفي مثال YAML توضيحي لمهمة «إصلاح تجاوز المصادقة» جُمعت جميع أنواع الفحوص معًا، بما فيها الاختبارات وruff وmypy وbandit ومقاييس عدد الخطوات والرموز (tokens) وزمن الاستجابة. وفي الممارسة العملية، كما يشير المؤلفون، تكفي اختبارات الوحدة ومعيار تقييم LLM لجودة الشيفرة.

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

من أين نبدأ

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

وفيما يلي أمثلة من الممارسة. تطور Claude Code في البداية بالاعتماد على ملاحظات المستخدمين، ثم أضاف evals للإيجاز وتعديل الملفات، ثم evals لمسألة الإفراط في تعقيد الحلول. أما Descript فتقيّم الوكيل وفق ثلاثة معايير: لا تُفسد، افعل ما طُلب منك، افعله جيدًا. وانتقل الفريق من الفحص اليدوي إلى مقيّمات LLM مع معايرة بشرية دورية. وبدأت Bolt متأخرة، حين كان الوكيل قد صار قيد الاستخدام الواسع بالفعل.

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