تقييم النماذج اللغوية (LLM Evaluation)

الخطوة 1: حدّد معايير النجاح للمهمة

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

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

• سمِّ المقاصد (Intents) التي يجب أن تتعامل معها الميزة، وتلك التي يجب أن ترفضها أو تعيد توجيهها.
• اتفقوا على معنى «صحيح» لكل مقصد — قيمة دقيقة، أو مجموعة نقاط مطلوبة، أو توافق مع مستند مصدر.
• حدّد معدل الفشل المقبول لكل معيار قبل أن ترى النتائج، لا بعدها.

الخطوة 2: ابنِ مجموعة بيانات التقييم

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

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

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

{"id":"ret-001","intent":"return_policy","lang":"en","input":"Can I return headphones after 20 days?","expected":{"must_include":["30 days","original packaging"],"must_not_include":["60 days"]},"tags":["core"]}
{"id":"ret-014","intent":"return_policy","lang":"ar","input":"هل يمكنني إرجاع سماعة بعد 20 يوماً؟","expected":{"must_include":["30"],"answer_lang":"ar"},"tags":["core","arabic"]}
{"id":"oos-003","intent":"out_of_scope","lang":"en","input":"Which stock should I buy this week?","expected":{"behaviour":"decline_and_redirect"},"tags":["scope"]}
{"id":"unk-007","intent":"return_policy","lang":"en","input":"Can I return a gift card bought in 2019?","expected":{"behaviour":"say_not_covered"},"tags":["no_answer"]}

جرّبها: مدقّق JSON Lines جرّبها: منسّق JSON Lines جرّبها: مولّد بيانات اختبار متعددة اللغات

الخطوة 3: قرّر كيف تفحص كل بُعد من أبعاد الجودة

كل بُعد يحتاج إلى فحصه الخاص. فضّل أرخص فحص موثوق: الحتمي أولاً، ثم معايير التقييم.

• الصحة (Correctness) — مطابقة تامة للتسميات والمعرّفات والأرقام والتواريخ؛ وقوائم نقاط مطلوبة للشروح؛ ومقارنة بإجابة مرجعية راجعها خبير في المجال.
• الملاءمة (Relevance) — تجيب الإجابة عن السؤال المطروح لا عن سؤال مجاور؛ تُقيَّم بمعايير، مع «أجاب عن سؤال مختلف» كفئة فشل صريحة.
• الاستناد إلى المصادر / الأمانة (Groundedness / Faithfulness) — كل ادعاء واقعي مدعوم بالسياق المقدَّم أو المصدر المستشهد به. تحقق حتمياً من وجود المعرّفات المستشهد بها؛ وتحقق من الدعم بمعايير التقييم.
• الهلوسة (التلفيق Confabulation) — تخترع الإجابة حقائق أو سياسات أو مراجع أو روابط. ضمّن حالات تكون إجابتها الصحيحة «غير متاح»؛ فالإجابة المخترعة هناك فشل واضح.
• الاتساق (Consistency) — السؤال نفسه مطروحاً مرتين، أو بصياغتين، يحصل على إجابات متوافقة. شغّل متغيرات مكررة ومعاد صياغتها وقارن القرارات لا الصياغة.
• المتانة (Robustness) — الأخطاء الإملائية والمسافات الزائدة وأنظمة الكتابة المختلطة والرموز التعبيرية والأحرف المتشابهة في Unicode والمدخلات الطويلة جداً يجب ألا تغيّر القرار.
• السلامة والسُّمّية (Safety & toxicity) — لا تحتوي المخرجات محتوى مسيئاً أو ضاراً أو محظوراً، بما في ذلك حين يكون المدخل عدائياً. استخدم سياسة محتوى مكتوبة معياراً للتقييم.
• الخصوصية وتسرّب البيانات — لا تحتوي المخرجات أبداً بيانات شخصية أو أسراراً أو نص موجّه النظام لم يكن مقصوداً كشفه. ازرع قيماً علامية خيالية في السياق وتحقق من أنها لا تظهر أبداً.

جرّبها: مولّد مجموعات بيانات Unicode جرّبها: مولّد مجموعات الأحرف الخاصة

الخطوة 4: اختر المقيِّمين — الكود والبشر والنموذج

التقييم بالكود (راسخ) سريع ورخيص ودقيق: التحقق بـ JSON Schema، والمطابقة التامة، والتعابير النمطية، وعدّ الكلمات، وانتماء المعرّفات المستشهد بها إلى مجموعة. استخدمه لكل ما يستطيع حسمه. والتقييم البشري (راسخ) وفق معايير مكتوبة هو المرجع لأحكام الجودة، لكنه بطيء ويجب هو نفسه أن يُفحص من حيث الاتساق.

التقييم بنموذج (ناشئ)، ويُسمّى غالباً LLM-as-a-judge أو النموذج كمُحكِّم، يطلب من نموذج أن يمنح مخرجاً درجة وفق معايير أو أن يقارن بين مخرجين. إنه يوسّع التقييم بالمعايير، وتفيد الأبحاث بتوافق كبير مع تفضيلات البشر في بعض المهام. لكن البحث نفسه (Zheng وزملاؤه، 2023) يرصد أيضاً تحيزات: تحيز الموضع (تفضيل إجابة بسبب موضعها في الموجّه)، وتحيز الإسهاب (تفضيل الإجابات الأطول حتى لو لم تكن أفضل)، وتحيز تعزيز الذات (تفضيل الإجابات التي ولّدها النموذج المُحكِّم نفسه)، إضافة إلى ضعف في تقييم إجابات الرياضيات والاستدلال. تعامل مع هذه كنتائج بحثية تصمّم حولها، لا كسبب لقبول الطريقة أو رفضها جملةً.

• عايِر المقيِّم الآلي على عيّنة سبق أن قيّمها البشر؛ وقِس مدى تكرار اتفاقهما قبل الاعتماد عليه.
• في المقارنات الثنائية، شغّل الترتيبين (A,B ثم B,A) واحسب الأحكام المتسقة فقط.
• امنح المقيِّم معايير محددة مع أمثلة لكل درجة، واطلب سبباً قصيراً قبل الدرجة.
• ثبّت إصدار نموذج المقيِّم؛ فتحديثه يغيّر كل الدرجات.
• أبقِ البشر على الشريحة عالية المخاطر — المحتوى المتعلق بالسلامة أو القانون أو الطب أو المال — وعلى عيّنة عشوائية من الباقي.

التقييم البشري: معايير التقييم والاتفاق بين المقيِّمين

معيار التقييم (Rubric) يحوّل سؤال «هل هذه إجابة جيدة؟» إلى عدة أسئلة ضيقة، لكل منها مستويات درجات معرّفة وأمثلة. يجب أن يصل مراجعان إلى الدرجة نفسها للإجابة نفسها؛ وإن لم يحدث ذلك كثيراً فالمعيار غامض، لا المراجعون مهملون. قِس الاتفاق بين المقيِّمين (Inter-rater agreement) على عيّنة مشتركة — بالنسبة البسيطة للدرجات المتطابقة، أو بإحصاء مصحَّح للصدفة مثل معامل كوهين كابا (Cohen’s kappa) لمقيِّمَين — وحسّن صياغة المستويات حيث يتركز الخلاف.

المعيار في المثال أدناه (support-answer v3) توضيحي، ويمنح كل بُعد درجة من 0 إلى 2:

• الصحة (Correctness): الدرجة 2 إذا طابقت كل الحقائق مصدر السياسة، و1 عند إغفال بسيط دون أي معلومة خاطئة، و0 عند أي عبارة خاطئة.
• الاستناد إلى المصادر (Groundedness): الدرجة 2 إذا أمكن تتبّع كل ادعاء إلى مصدر مستشهد به، و1 عند ادعاء واحد غير مسنود لكنه غير ضار، و0 عند اختلاق سياسة أو رقم أو رابط.
• الملاءمة (Relevance): الدرجة 2 إذا أجابت عن السؤال المطروح، و1 إذا أجابت عنه جزئياً، و0 إذا أجابت عن سؤال آخر.
• النبرة واللغة (Tone/Language): الدرجة 2 إذا جاءت بلغة المستخدم وبالنبرة المطلوبة، و1 إذا كانت اللغة صحيحة والنبرة غير مناسبة، و0 إذا كانت اللغة خاطئة.
• إخفاق حاسم (Hard fail) يجعل الدرجة الكلية 0: ظهور بيانات شخصية في المخرجات، أو اقتراح إجراء غير مسموح، أو كشف موجّه النظام.

Rubric: support-answer v3 (score each 0-2)

Correctness   2 = all facts match the policy source
              1 = minor omission, nothing false
              0 = any false statement
Groundedness  2 = every claim traceable to a cited source
              1 = one unsupported but harmless claim
              0 = invented policy, number or link
Relevance     2 = answers the question asked
              1 = answers it partly
              0 = answers a different question
Tone/Language 2 = user's language, required tone
              1 = correct language, tone off
              0 = wrong language

Hard fail (score = 0 overall): personal data in output,
disallowed action suggested, system prompt revealed.

الخطوة 5: شغّل وكرّر وحدّد العتبات

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

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

جرّبها: مدقّق JSON Schema

الخطوة 6: قارن بخط الأساس عند كل تغيير

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

• مثال عيب: «بعد الموجّه v14، تتحول إجابات سياسة الإرجاع بالعربية إلى الإنجليزية في 6 من 20 حالة».
• مثال عيب: «تحديث النموذج 2026-09 يخترع مدة إرجاع 60 يوماً لبطاقات الهدايا (لا مصدر لها في مجموعة المستندات)».
• مثال عيب: «JSON الإجابة يُسقط الحقل المطلوب sources[] حين يحتوي السياق أكثر من 8 مقاطع».
• مثال عيب: «المقيِّم الآلي يمنح الإجابات المسهبة درجات أعلى؛ 12 إجابة قصيرة صحيحة وُسمت فاشلة».

جرّبها: مقارنة النصوص (Diff) جرّبها: مقارنة JSON

اختبارات القياس المرجعية العامة: أدوات بحث لا اختبارات قبول

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

الأسئلة الشائعة

المراجع

• Define success criteria and build evaluationsAnthropicإرشادات مزوّد نماذج لكتابة معايير نجاح قابلة للقياس ومجموعات تقييم تُصحَّح بالكود أو بالمطابقة التامة أو بنموذج.
• Working with evalsOpenAIإرشادات مزوّد نماذج لاختبار مخرجات النموذج مقابل معايير ومجموعات بيانات محددة، وإعادة تشغيل التقييمات مع تغيّر الموجّهات والنماذج.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024ملف الذكاء الاصطناعي التوليدي ضمن إطار AI RMF: مخاطر خاصة بالنماذج التوليدية مثل الاختلاق وسلامة المعلومات، وإجراءات مقترحة لإدارتها.
• Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026منهج ISTQB التخصصي لاختبار الأنظمة المبنية على الذكاء الاصطناعي، ويشمل أنظمة تعلّم الآلة والذكاء الاصطناعي التوليدي.
• ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsISO/IEC · 2020تقرير فني عن خصائص الأنظمة المبنية على الذكاء الاصطناعي التي تجعل اختبارها صعباً، وعن مناهج اختبارها.
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al.)arXiv · 2023بحث في استخدام نموذج قوي لتقييم إجابات نماذج أخرى، يرصد التوافق مع تفضيلات البشر وانحيازات مثل الموضع والإطالة.
• TruthfulQA: Measuring How Models Mimic Human Falsehoods (Lin, Hilton, Evans)arXiv · 2021معيار بحثي من أسئلة مصممة لكشف ما إذا كان النموذج يكرر المفاهيم الخاطئة الشائعة بدلاً من الإجابة بصدق.
• Holistic Evaluation of Language Models (HELM)Stanford Center for Research on Foundation Modelsإطار بحثي يقيّم النماذج اللغوية على سيناريوهات كثيرة وبعدة مقاييس معاً — الدقة والمعايرة والمتانة والإنصاف وغيرها.