إذا كان فريقك يستخدم نظاماً للذكاء الاصطناعي في مهمة متكررة، مثل تصنيف تذاكر الدعم أو استخراج البيانات من المستندات أو تلخيص الاجتماعات، فقد لا تكون المراجعات اليدوية المتقطعة كافية وحدها لاكتشاف تراجع الجودة. هذه توصية هذا المقال: أنشئ مجموعة تقييم مُصدَرة (versioned evaluation set) تمثل العمل الفعلي، وشغّلها بطريقة متسقة عند مقارنة التغييرات. يصف Anthropic التقييم بأنه مدخلات مقترنة بمنطق للتقدير، ويميّز بين المهام والتجارب والمقيّمين والنصوص الكاملة أو مسارات التنفيذ، ولا سيما في سير العمل متعدد الخطوات وفق شرح Anthropic للتقييمات.
ابدأ بنواة صغيرة من العمل الحقيقي
ابدأ بنحو 20 إلى 50 مهمة بسيطة مأخوذة من العمل الحقيقي، مع إعطاء اهتمام خاص للإخفاقات السابقة، ثم وسّع المجموعة مع ظهور أنماط إخفاق جديدة بحسب توصية Anthropic بشأن نقطة البداية. لا يعني ذلك أن هذا الحجم معيار كافٍ لكل مهمة أو مجال؛ بل هو نقطة انطلاق عملية يمكن للفريق تعديلها.
قبل جمع الأمثلة، طبّق ضوابط حماية البيانات. قلّل البيانات إلى ما تحتاجه التقييمات، وأزل أو نقّح المعلومات الشخصية، وحدد صلاحيات الوصول، وضع سياسة للاحتفاظ والحذف، وراجع متطلبات الخصوصية أو الامتثال عند حفظ النصوص الكاملة أو استدعاءات الأدوات. وينبغي ألا يُفهم التنقيح وحده على أنه ضمان لإخفاء الهوية بالكامل؛ إذ يحذّر دليل Google People + AI Guidebook من هذا القيد في إرشاداته حول جمع البيانات وتقييمها.
اطلب من خبير في المجال المساعدة في تعريف النتيجة المرغوبة قبل وضع الملصقات. يقدّم OpenAI سير عمل يتضمن تحديد النجاح وقياس الأداء وتحسين النظام، مع دور لخبراء المجال في تحديد النتائج المطلوبة في عرضه لسير عمل التقييم. اجمع بعد ذلك أمثلة مقبولة وغير مقبولة، وسجّل سبب الحكم بدلاً من الاكتفاء بدرجة عامة.
ما الذي يجب أن يحتويه كل اختبار؟
المخطط التالي اقتراح تحريري مركب، لا مخططاً معيارياً من مصدر واحد. وهو يستفيد من الدعوة إلى توثيق مجموعات الاختبار والمقاييس والأدوات وطرائق التقييم، ومن التركيز على البيانات الممثلة وصيانتها وخلافات المعلّقين، ومن التمييز بين المدخلات ومنطق التقدير ومسارات التنفيذ كما يوضح NIST، وكما يوضح دليل Google، وكما يوضح Anthropic.
| الحقل | الغرض المقترح |
|---|---|
| case_id | معرّف ثابت للحالة. |
| task_version | نسخة تعريف المهمة التي كانت قيد التقييم. |
| input وcontext | المدخل والسياق اللازمان لإعادة الاختبار. |
| expected_behavior | السلوك المتوقع أو خصائص الناتج المقبول. |
| reference_answer_or_assertions | إجابة مرجعية أو ادعاءات يمكن فحصها. |
| risk_tags وslice_tags | وسوم المخاطر وشرائح التحليل، مثل اللغة أو نوع المهمة. |
| grader_type وgrader_rubric | نوع المقيّم وقواعد الحكم التي يستخدمها. |
| provenance | مصدر الحالة وطريقة جمعها ووضع ملصقاتها. |
هذه الحقول ليست مواصفة منشورة ملزمة؛ إنها قالب عملي تقترحه هذه المقالة. احتفظ أيضاً بإصدار البيانات، وقواعد وضع الملصقات، ونسخة المقيّم، والقيود المعروفة. توصي NIST بتوثيق مجموعات الاختبار والمقاييس والأدوات وطرائق التقييم، وبإشراك خبراء المجال أو مقيّمين مستقلين، وباختبار النظام قبل النشر وأثناء التشغيل ضمن قسم القياس في AI RMF.
استخدم مقيّماً مناسباً لنوع النجاح
للمتطلبات الحتمية، استخدم فحوصاً قابلة للبرمجة، مثل المطابقة الدقيقة، والتحقق من البنية، وفحوص regex، واختبارات الوحدة، أو التحقق من النتيجة. هذه أمثلة تنفيذية مقترحة في هذا المقال، وليست ادعاءً بأن مصدراً معيناً يفرض كل فحص منها.
أما الصلة والنبرة والاكتمال والاستناد إلى الحقائق، فقد تناسبها قاعدة تقييم وصفية (rubric) مع مقيّم نموذجي، على أن يراجع الفريق عينة من أحكامه دورياً. ويصف Anthropic الجمع بين المقيّمين البرمجيين والنموذجيين والبشريين في تقييمات الوكلاء في شرحه لأنواع المقيّمين. لا تعامل درجة المقيّم النموذجي كحقيقة نهائية؛ سجّل حالات الخلاف، واستخدم مراجعة بشرية لتحديث القاعدة عند الحاجة. كما يشدد دليل Google على توثيق خلافات المعلّقين وصيانة مجموعة البيانات والاختبار المستمر في ظروف العالم الحقيقي في فصل جمع البيانات والتقييم.
إذا كانت المهمة وكيلية أو متعددة الخطوات، فاحفظ النص الكامل للمحادثة، واستدعاءات الأدوات، والإجراءات الوسيطة، والحالة النهائية، لا الإجابة النهائية فقط بحسب تمييز Anthropic للمسارات الكاملة. وعندما تكون المخرجات متغيرة، شغّل تجارب متعددة وسجّل معدل النجاح؛ فالتجربة الواحدة قد لا تصف هذا التغير.
حلّل النتائج على شرائح
لا تكتفِ بدرجة إجمالية. اعرض معدلات النجاح حسب اللغة، وشريحة العملاء، وطول المدخل، والصعوبة، والغموض، ونوع المهمة، وحالات الحافة المعروفة. هذه الشرائح اقتراح تحليلي من المقالة، ويمكن للفريق إضافة شرائح مرتبطة بالمخاطر أو الاستخدام الفعلي. الهدف هو معرفة أين يحدث التراجع، لا إنتاج رقم واحد يخفيه.
يمكن للفريق، كإجراء تحريري اختياري لتقليل فرط الملاءمة، الاحتفاظ بمجموعة صغيرة لا تُستخدم في تطوير المطالبات أو النظام. لا ينسب هذا الاقتراح إلى Anthropic في هذه المقالة. استخدمها لاحقاً كفحص مستقل ضمن سياسة الفريق، مع توثيق من يملك حق الوصول إليها وكيف تُحدّث.
اجعل التقييم جزءاً من دورة الإصدار
كقاعدة إصدار عملية، شغّل المجموعة بعد التغييرات المهمة التي قد تؤثر في السلوك—مثل تغييرات المطالبة أو النموذج أو الاسترجاع أو الأدوات—وفق سياسة فريقك، ثم قارن بالنسخة السابقة. هذه قاعدة تشغيلية مقترحة، وليست متطلباً عاماً من OpenAI. يدعم Evals API لدى OpenAI مصادر بيانات للتقييم، ومقيّمين قابلين للتهيئة، وتشغيلات متكررة للمقارنة عبر نماذج أو معاملات وفق مرجع OpenAI للـ Evals API.
حدّد عتبات إصدار قبل اعتماد التغيير، وقرّر ما الذي يستدعي التحقيق في تراجع أو منع الإصدار. هذه عتبات وتصميمات تشغيلية مقترحة، وليست حدوداً عامة صالحة لكل فريق. بعد الإطلاق، أضف الإخفاقات المؤكدة وملاحظات المستخدمين إلى المجموعة، وراقب تغير البيانات ومتطلبات العمل. ينسجم ذلك مع التركيز على صيانة البيانات والاختبار المستمر في ظروف العالم الحقيقي في دليل Google، ومع توصية NIST بالقياس قبل النشر وأثناء التشغيل في AI RMF.
قائمة تنفيذ مختصرة لفريق صغير
- عيّن خبيراً في المجال لتعريف النجاح.
- اجمع 20–50 حالة من العمل الحقيقي، وابدأ بالإخفاقات المعروفة.
- قلّل البيانات الحساسة ونقّحها وحدد الوصول والاحتفاظ والحذف.
- وثّق السلوك المتوقع ومعايير القبول لكل حالة.
- أضف وسوم المخاطر والشرائح ومصدر كل حالة.
- افصل الفحوص الحتمية عن الأحكام الوصفية.
- راجع عينة من قرارات المقيّم النموذجي بشرياً.
- احفظ المسار الكامل في المهام متعددة الخطوات.
- اعرض النتائج حسب الشرائح، لا بالمتوسط الإجمالي فقط.
- قارن النسخ، وحقق في التراجعات، وأضف إخفاقات الإنتاج المؤكدة.
بهذا الأسلوب تصبح مجموعة التقييم سجلّاً متراكماً لاختبارات الانحدار، مع بقاء المخطط والعتبات ووتيرة التشغيل قرارات تحريرية وتشغيلية يحددها فريقك بحسب المهمة والمخاطر.