الوحدة 9 — التقييم: المعايير المرجعيّة والأحكام البشريّة

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

MMLU وأمثالها

MMLU (Massive Multitask Language Understanding) هو أشهر معيار عامّ. 57 مجالًا (تاريخ، فيزياء، طبّ، قانون…) ومجموعة أسئلة اختيار متعدّد، كلّ سؤال بأربعة خيارات. تُقاس نسبة الأسئلة المُجابة بصحّة.

يبدو المقياس متينًا: مادّة واسعة، تقييم آلي، أرقام قابلة للمقارنة. المشاكل تبدأ بالتفاصيل.

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

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

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

الحلبات وElo

مقاربة مختلفة جوهريًا: Chatbot Arena من LMSYS. مقاربة بشريّة صرفة. للمستخدم مُطالبة، يُوجَّه إلى نموذجَين مجهولَين، يقارن، يصوّت أيّهما أفضل. تُحصى ملايين التصويتات، ويُحسَب نظام Elo لكلّ نموذج كما في الشطرنج.

المزيّة: يقيس التفضيل البشريّ الفعلي، وهو ما يعنينا في الإنتاج. لا يُلعَب بحفظ الأسئلة، لأنّها تولد من المستخدمين لحظيًا.

العيوب: البيانات مُنحازة نحو مستخدمين تقنيّين ناطقين بالإنجليزية بشكل غالب؛ الطلبات قصيرة عادةً؛ وطبيعة الإجابات المُقارَنة لا تُطابق دائمًا مهام إنتاجيّة (تحرير طويل، استخلاص، دعم عملاء بلغة معيّنة). الترتيب على Chatbot Arena مؤشّر مفيد، ليس حكمًا نهائيًا.

النموذج الحَكَم

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

def juger(question, reponse_a, reponse_b, tokenizer, modele):
    prompt = f"""أنت حَكَم. قارن ردَّين على سؤال العميل التالي وقُل أيّهما أفضل من ناحية: الصحّة، الوضوح، النبرة المهنيّة.

السؤال: {question}

الردّ أ: {reponse_a}
الردّ ب: {reponse_b}

أجب بصيغة JSON: {{"gagnant": "A" أو "B", "motif": "..."}}"""
    messages = [{"role": "user", "content": prompt}]
    entrees = tokenizer.apply_chat_template(messages, return_tensors="pt", add_generation_prompt=True)
    sortie = modele.generate(entrees.to(modele.device), max_new_tokens=200, do_sample=False)
    return tokenizer.decode(sortie[0, entrees.shape[1]:], skip_special_tokens=True)

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

النموذج الحَكَم يتوافق مع الحَكم البشري بنسبة 80 إلى 90 بالمائة على مهام محدّدة، وهو ما يجعله بديلًا معقولًا للتكرار التطويريّ، لا للحسم النهائي.

بناء جدول تقييم داخلي

هنا يكمن الجواب الحقيقي لمشروع الإنتاج. أفضل تقييم لمساعد الدعم يأتي من مساعد الدعم نفسه، مقاسًا على ما سيراه فعلًا.

خطوات البناء:

جمع طلبات حقيقية: ابدأ بتاريخ التذاكر (بعد إخفاء الهويّة). اختَر 200 إلى 500 طلبٍ يُمثِّل توزيع الحالات الفعلي.
تصنيف الطلبات: تقنية، إدارية، محتوى حسّاس، خارج نطاق، إلخ. سيسمح هذا بقياس الأداء حسب نوع الطلب، لا رقمًا مجمَّعًا.
إجابة مرجعيّة لكلّ حالة: يكتبها خبير دعم بشريّ. هذه الإجابة لن تكون فريدة، لكنّها ترسم الجودة المستهدَفة.
مقاييس متعدّدة: مطابقة دقيقة (نادرة)، ومطابقة دلاليّة (شعاعات تشابه)، وحكم النموذج الحَكَم، ومراجعة بشرية دورية على عيّنة.

import json
from sklearn.metrics.pairwise import cosine_similarity
from sentence_transformers import SentenceTransformer

encodeur = SentenceTransformer("intfloat/multilingual-e5-large")

def evaluer_lot(reponses_modele, reponses_reference):
    """يحسب مقياس تشابه شعاعي بسيط لتعقّب انحدارات."""
    v_m = encodeur.encode(reponses_modele, normalize_embeddings=True)
    v_r = encodeur.encode(reponses_reference, normalize_embeddings=True)
    similarites = (v_m * v_r).sum(axis=1)
    return {
        "moyenne": float(similarites.mean()),
        "en_dessous_de_0.7": int((similarites < 0.7).sum()),
    }

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

متى نُقيّم؟

الخطأ الشائع: تقييم مرّة قبل النشر ثمّ نسيان الأمر. الصحيح: تقييم مستمرّ.

تقييم قبل النشر: على كامل الجدول (200-500 حالة).
تقييم مستمرّ: تصويت المستخدم (إبهام لأعلى/أسفل) في الإنتاج، تجميع أسبوعي.
تقييم على الانحدار: قبل كلّ تحديث نموذج أو ضبط دقيق، إعادة الجدول كاملًا.
تقييم بشري دوري: عيّنة عشوائيّة من 20 حالة، مُراجعة يدويّة كلّ شهر.

تجنّب الأرقام العائمة

معيار عامّ (MMLU، HumanEval، BIG-Bench) يمنحك رقمًا مثيرًا في تقرير للإدارة، لكنّه لا يُخبر مطلقًا هل يعمل مساعد الدعم لعملائك. لا تعتمد قرارًا إنتاجيًا على هذه الأرقام. اعتمد جدولك أنت. ولا تتفوّق على الحكم البشريّ الدوري إلّا حين يُظهِر النموذج الحَكَم توافقًا موثّقًا مع البشر على مهمّتك تحديدًا.

في الخلاصة

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

الوحدة التالية: نُغلق الدائرة بحوسبة الكلفة الحقيقيّة لكلّ استعلام، ونختار — بأرقام — بين API خارجي واستضافة داخليّة، مع بنية توجيه ذكيّة.

MMLU وأمثالها​

الحلبات وElo​

النموذج الحَكَم​

بناء جدول تقييم داخلي​

متى نُقيّم؟​

في الخلاصة​