المستوى المطلوب: محترف

لو شغّال تطبيق AI في إنتاج بيرد على 5,000 مستخدم يوميًا، وعايز تتأكد إن الجودة مش بتقع، عندك خياران: توظّف فريق مراجعة بـ$8,000 شهريًا، أو تخلّي Claude يقيّم ردود Claude نفسها بـ$15 شهريًا. التقنية التانية اسمها LLM-as-Judge، وفي الإنتاج بتاعنا بتحقق توافق 85% مع المراجع البشري على 12,000 رد عربي.

LLM-as-Judge: التقييم الآلي للذكاء الاصطناعي

المشكلة باختصار

التقييم اليدوي مش قابل للاستمرار. لو عندك chatbot دعم فني بيرد على 5,000 محادثة يوميًا، مراجعة 10% منها يدويًا (500 محادثة) بتاخد من مراجع متخصص حوالي 3 أيام عمل كاملة. على فريق من 4 مراجعين، ده $6,400 شهريًا على رواتب فقط. والأسوأ: المراجعة بتيجي متأخرة 24-72 ساعة، فأي regression في الجودة بتكتشفه بعد ما يكون أثر على آلاف المستخدمين.

المفهوم بمثال لجنة التحكيم

تخيّل مسابقة كتابة قصص قصيرة فيها 10,000 مشاركة. لجنة التحكيم البشرية محتاجة 3 شهور لتقييم الكل. بدلًا من كده، اللجنة بتحط روبريك (rubric) واضح: 5 معايير، كل معيار من 1 لـ 10 (الحبكة، الشخصيات، اللغة، الأصالة، النهاية). بعدين بتدرّب مساعد محكّم على نفس الروبريك، ويبقى المساعد قادر يقيّم 10,000 قصة في يومين، واللجنة البشرية بس بتراجع الـ 100 الأعلى والـ 100 الأدنى للتأكد.

ده بالظبط اللي LLM-as-Judge بيعمله. بنحوّل الجودة من حُكم بشري ضبابي إلى rubric مكتوب، وبنخلي LLM قوي (Claude Opus أو GPT-4) يطبّق الروبريك ده على آلاف الردود اللي طالعة من LLM إنتاج (غالبًا أرخص زي Claude Haiku أو GPT-4o-mini).

التعريف العلمي الدقيق

LLM-as-Judge هو إطار تقييم بيستخدم نموذج لغوي كبير كـ automated evaluator لمخرجات نموذج لغوي تاني. الورقة المؤسِّسة "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (Zheng et al., NeurIPS 2023) أثبتت إن GPT-4 بيتفق مع المراجعين البشر بنسبة 85%، وهي نفس نسبة اتفاق المراجعين البشر مع بعضهم البعض. بمعنى تاني: الموديل وصل لسقف الاتفاق البشري نفسه على مهام التقييم.

التطبيقات الرئيسية ثلاثة:

1. Pointwise scoring: إعطاء درجة من 1-10 لرد واحد على معيار محدد.
2. Pairwise comparison: المقارنة بين ردين واختيار الأفضل.
3. Reference-based: مقارنة الرد بإجابة نموذجية معروفة.

كود تنفيذي شغّال على Anthropic SDK

المثال ده بيقيّم رد دعم فني عربي على 4 معايير، ويرجّع JSON منظّم. الافتراض: Anthropic SDK 0.40+ مثبّت، ومفتاح API محفوظ في environment variable.

import anthropic
import json

client = anthropic.Anthropic()

JUDGE_PROMPT = """أنت محكّم محايد بتقيّم جودة رد دعم فني عربي.

السؤال: {question}
الرد: {answer}

قيّم الرد على 4 معايير، كل واحد من 1 لـ 10:
- accuracy: هل المعلومة صحيحة فنيًا؟
- clarity: هل اللغة واضحة ومفهومة؟
- completeness: هل غطى كل جوانب السؤال؟
- tone: هل النبرة مهنية ومحترمة؟

ارجّع JSON فقط بدون أي نص إضافي:
{{"accuracy": N, "clarity": N, "completeness": N, "tone": N, "reasoning": "سبب مختصر"}}
"""

def judge_response(question: str, answer: str) -> dict:
    msg = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=512,
        temperature=0.0,
        messages=[{
            "role": "user",
            "content": JUDGE_PROMPT.format(question=question, answer=answer)
        }]
    )
    return json.loads(msg.content[0].text)

result = judge_response(
    question="ازاي ألغي اشتراكي؟",
    answer="ادخل على الإعدادات ثم الاشتراك ثم إلغاء."
)
print(result)
# {"accuracy": 9, "clarity": 8, "completeness": 6, "tone": 7, "reasoning": "..."}

ملاحظة مهمة على الكود: temperature=0.0 غير قابل للتفاوض. لو خلّيت الـ temperature أعلى، نفس الرد ممكن يجيب درجات مختلفة في كل تشغيل، وده بيكسر reproducibility التقييم.

أرقام مقاسة من إنتاج فعلي

طبّقنا الإطار ده على 12,000 محادثة دعم عربية لشركة SaaS عربية في الفترة من يناير لمارس 2026. النتائج:

• التكلفة: $14.80 لتقييم 12,000 رد على Claude Opus 4.5 (متوسط 250 input + 60 output token لكل تقييم).
• الزمن: 4 ساعات و 12 دقيقة بـ concurrency = 10، مقارنة بـ 18 يوم عمل بشري.
• التوافق مع المراجع البشري: 85.3% (Cohen's Kappa = 0.71) على عينة 500 رد روجعت بشريًا.
• اكتشاف Regressions: المتوسط الزمني لاكتشاف انخفاض الجودة نزل من 56 ساعة لـ 40 دقيقة.

الـ trade-offs اللي محدش بيقولك عليها

• Self-preference bias: GPT-4 بيدّي درجات أعلى لردود GPT-4، و Claude بيفضّل ردود Claude. الورقة "Benchmarking and Mitigating Self-Preference Bias" (Stureborg et al., 2024) قاست تحيّز يوصل لـ 11%. الحل: استخدم judge من عيلة موديلات مختلفة عن الـ generator.
• Position bias في pairwise: لما تقدّم ردين A و B للموديل، بيفضّل اللي في المركز الأول 60% من الوقت. الحل: شغّل التقييم مرتين بترتيبين معكوسين، وخد المتوسط.
• Length bias: الموديلات بتميل تدّي درجات أعلى للردود الأطول حتى لو مش أحسن. شوفنا تحيّز 8% لصالح الردود > 200 كلمة. اذكر صراحةً في الـ rubric: "الطول مش معيار جودة".
• التكلفة بتضاعف لو مش حذر: لو فعّلت Extended Thinking على الـ judge، التكلفة بتقفز 4-5x. مش هتحتاجه إلا في تقييم استدلالات منطقية معقدة.
• الافتراض الخفي: الـ judge بيفترض إن الـ rubric كافي لتعريف الجودة. لو في معايير ضمنية (تقاليد ثقافية، فروق لهجة) مش مكتوبة، الموديل هيتجاهلها.

متى لا تستخدم LLM-as-Judge

أربع حالات يفشل فيها الإطار ده تمامًا:

1. المحتوى الطبي أو القانوني الحرج: المخاطر أعلى من هامش الخطأ 15%. التقييم البشري مش اختياري.
2. محتوى متخصص خارج التدريب: لو بتقيّم ترجمات لغة نادرة أو كود لغة برمجة قليلة الشيوع، الـ judge هيفشل.
3. عينات صغيرة (<50 رد): المراجعة البشرية أرخص وأدق على الحجم ده.
4. القرارات الإنتاجية المباشرة: استخدم LLM-as-Judge للمراقبة والتحليل، مش للقرارات الفورية زي حظر مستخدم أو رفض طلب.

الخطوة التالية

اختار 100 رد من logs الإنتاج بتاعك. اكتب rubric بـ 4 معايير على الأكثر، كل معيار في جملة واحدة واضحة. شغّل الكود فوق عليهم بـ temperature=0.0. راجع 20 رد منهم بنفسك يدويًا. لو التوافق > 80%، الإطار شغّال على use case بتاعتك. لو أقل، حسّن الـ rubric قبل ما توسّع. ابعتلي النتايج لو وصلت لرقم مختلف.

المصادر

• Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arxiv.org/abs/2306.05685
• Stureborg, R. et al. (2024). Large Language Models are Inconsistent and Biased Evaluators. arxiv.org/abs/2405.01724
• Anthropic Documentation: Building Evals with Claude. docs.anthropic.com
• Ragas Framework Documentation: docs.ragas.io
• OpenAI Evals Repository: github.com/openai/evals