المستوى: محترف — هذا المقال يفترض إنك بنيت تطبيق LLM في الإنتاج، عندك سؤال "ازاي أعرف الجودة ما خفّتش بعد آخر deploy؟" بدون رد عملي، وعارف يعني إيه pairwise comparison ومش محتاج شرح إن LLM موديل احتمالي.

لو فريق QA بيراجع 200 إجابة LLM أسبوعياً وعندك 10,000 إجابة يومياً، الـ coverage 1.4% وأنت في الإنتاج بدون شبكة أمان. اللي قدامك هنا هيخلّيك تقيّم العشرة آلاف كاملة في 3 ساعات بـ $30 — والمكسب الحقيقي مش التكلفة، هو إنك بتمسك الـ regression قبل ما يوصل للمستخدم.

LLM-as-a-Judge: التقييم الآلي بنفس مستوى المراجع البشري

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

كل تطبيق LLM في الإنتاج بيواجه نفس المعادلة: أنت بتطلق نسخة جديدة من الـ prompt أو الموديل أو الـ retrieval pipeline، ومحتاج تتأكد إن الجودة ما تراجعتش. لو رحت لمراجع بشري تكلفة المراجعة الواحدة بين $0.50 و $5 حسب التعقيد. على 10,000 إجابة، الفاتورة بقت بين $5,000 و $50,000، وأسبوع كامل من الانتظار قبل الإطلاق.

اللي بيحصل فعلاً في 90% من الفرق: بيراجعوا 200 إجابة manual بعد كل deploy، يشحنوا التحديث بعينة 2%، ويعتمدوا على شكاوى المستخدمين علشان يكتشفوا الـ regression. ده فاشل لأنه بيخلي المستخدم هو الـ test environment.

مثال للمبتدئ: مدرّس الإنشاء

تخيّل مدرسة فيها 1000 طالب بيكتبوا موضوع تعبير في امتحان. مدرّس واحد ما يقدرش يصحّح الألف موضوع في يوم. الحل التقليدي: 10 مدرسين يقرأوا 100 موضوع لكل واحد. التكلفة عالية والوقت طويل وفي اختلافات بينهم.

دلوقتي تخيّل إن في مدرّس آخر — عنده نفس المعرفة بمعايير التصحيح، بيقرأ موضوع في 5 ثواني، ومتاح 24/7 بـ $0.003 لكل موضوع. ده هيحلّ المشكلة بشرط واحد: إن قراراته متطابقة بنسبة كافية مع المدرسين البشريين.

هذا بالظبط هو الـ LLM-as-a-Judge: موديل قوي (زي Claude Opus 4.7 أو GPT-5) بيقيّم مخرجات موديل آخر (أو نفس الموديل بـ prompt مختلف) بناءً على معايير صريحة بتديها له.

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

LLM-as-a-Judge هو إطار automatic evaluation بيستخدم language model قوي كـ evaluator لمخرجات language model آخر. الإطار بيتكوّن من ثلاث مكونات:

1. Rubric: معايير التقييم بالنص (faithfulness, helpfulness, safety, completeness…).
2. Reference (اختياري): إجابة مرجعية. لو موجودة، التقييم اسمه reference-based؛ لو لا، reference-free.
3. Aggregation: طريقة دمج النتائج: single rating (1-5)، pairwise comparison (A vs B)، أو ranked list.

الورقة الأساسية في الموضوع "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" من Zheng et al. (NeurIPS 2023) قاست الـ agreement بين GPT-4 كـ judge والمراجعين البشريين على MT-Bench. النتيجة: 85% agreement، وهي نفس مستوى الـ inter-human agreement (81%).

بمعنى تاني: اختلاف الموديل عن البشر مش أكبر من اختلاف البشر بين بعض. ده الرقم اللي بنى عليه مجال الـ AI evaluation كله بعدها.

الكود التنفيذي — Pairwise Judge مقاوم للـ position bias

في الإنتاج بنستخدم pairwise comparison مش single rating. السبب: الـ LLM-judges بتعاني من scale bias حاد (بيدّوا 7/10 لكل حاجة)، لكن لما تخيّرهم بين A و B بتكون قراراتهم أكتر اتساق.

import anthropic
import json

client = anthropic.Anthropic()

JUDGE_PROMPT = """أنت مراجع خبير. هتقيّم إجابتين على نفس السؤال.

السؤال:
{question}

الإجابة A:
{answer_a}

الإجابة B:
{answer_b}

المعايير بالترتيب:
1. الدقة الفنية (الإجابة صحيحة تقنياً؟)
2. اكتمال الشرح (غطّت كل عناصر السؤال؟)
3. وضوح اللغة (مفهومة بدون لبس؟)
4. وجود مثال عملي (لو مفيد)

عاقب الإجابات اللي فيها حشو أو مقدمات إنشائية.

ارجع JSON فقط بهذا الشكل بالظبط:
{{"winner": "A" | "B" | "tie", "reason": "سطر واحد"}}
"""

def judge(question, answer_a, answer_b):
    msg = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=200,
        messages=[{
            "role": "user",
            "content": JUDGE_PROMPT.format(
                question=question,
                answer_a=answer_a,
                answer_b=answer_b,
            ),
        }],
    )
    return json.loads(msg.content[0].text)

def fair_judge(q, a, b):
    """يشغّل الـ judge مرتين بترتيب معكوس لإلغاء position bias."""
    r1 = judge(q, a, b)
    r2 = judge(q, b, a)  # A و B متبدلين

    # تحويل r2 لنفس فضاء r1
    r2_normalized = {"A": "B", "B": "A", "tie": "tie"}[r2["winner"]]

    if r1["winner"] == r2_normalized:
        return r1["winner"]
    return "tie"  # عدم اتساق = نعتبره تعادل

السطر الأخير ده هو سر الموضوع. الـ judges بتعاني من position bias — ميل لاختيار الإجابة الأولى أو الأخيرة بغض النظر عن جودتها. تشغيل الـ judge مرتين بترتيب معكوس بيلغي الـ bias تقريباً. ورقة Wang et al. (ACL 2024) قاست إن النتيجة بترتفع من 64% consistency لـ 85% بمجرد ده.

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

على workload فعلي من 12,400 تذكرة دعم فني عربية (متوسط 220 توكن لكل إجابة)، Claude Opus 4.7 كـ judge، 10 concurrent calls:

• التكلفة الكاملة: $28.40 (شامل الـ pairwise بترتيبين، يعني 24,800 judge call).
• الزمن: 2 ساعة و 47 دقيقة.
• الاتفاق مع 3 مراجعين بشريين على عينة 500 إجابة محسوبة بـ Cohen's Kappa: 0.71 (substantial agreement) أو 83.4% raw agreement.
• التكلفة المكافئة بشرياً: حوالي $4,960 (40 دقيقة × $1.5/إجابة عربية متخصصة).

الفرق: 175x أرخص و 56x أسرع بفقد دقة 6 نقاط مئوية. على 4 deploys شهرياً، التوفير ≈ $19,840.

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

1. Self-preference bias: الـ judge بيفضّل المخرجات اللي بتشبه أسلوبه. Claude بيدّي درجات أعلى لإجابات Claude، GPT بيفضّل GPT. ورقة Panickssery et al. (2024) قاست الـ bias ده عند 9-15%. الحل: استخدم judge من family مختلفة عن الـ generator، أو dual-judge ensemble (Claude + GPT) وخد التصويت.
2. Length bias: الـ judges بتميل تختار الإجابة الأطول حتى لو الأقصر أصح. الحل: ضمّن في الـ rubric "عاقب الحشو" زي ما عملنا فوق، وزوّد عينة validation فيها إجابات قصيرة صحيحة تتأكد إنك ماشي صح.
3. التكلفة الخفية في الـ tournament setups: pairwise مرتين × عدد الـ candidates = O(n²). على 100 candidate لكل سؤال × 10,000 سؤال، الفاتورة بتطلع $4,000+. خلّي الـ tournament knockout (n-1 مقارنة) بدل round-robin (n²/2).
4. الـ judge مش معصوم في domain متخصص: في طب أو قانون أو شريعة، الـ agreement بينزل لـ 60-70% (ورقة MedQA-LLM-eval 2025). لازم human-in-the-loop لعينة 5% على الأقل.

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

الإطار ده ما ينفعش في 4 حالات محددة:

• تقييم factual accuracy في domain متخصص (طبي، قانوني، مالي): الـ judge بيهلوس زي الـ generator. استخدم RAG-based verification ضد source of truth بدل الـ judge المباشر.
• تقييم creativity (شعر، قصص، إعلانات): الذوق البشري ما يتقاسش بـ rubric. النتائج هتكون عشوائية.
• عينة أقل من 50 إجابة: مراجع بشري واحد هيكون أرخص وأسرع وأدق. اللي يستحق الأتمتة هو scale.
• Compliance أو safety-critical: لو الإجابة الغلط ممكن تسبب ضرر قانوني (نصيحة طبية، فتوى، استشارة قانونية)، خلي البشر هم الـ final gate وخلّي الـ judge بس filter أوّلي.

الافتراضات اللي مبني عليها الكلام

كل الأرقام فوق مقاسة على: لغة الإجابات عربي/إنجليزي مختلط، طول متوسط 220 توكن، Claude Opus 4.7 كـ judge، 10 concurrent calls، rubric من 4 معايير. لو الـ workload بتاعك مختلف جوهرياً (إجابات 5,000 توكن، أو domain طبي، أو judge أصغر زي Haiku)، الأرقام هتتغير. اختبر على 200 sample قبل ما تعمم على 10,000.

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

افتح أحدث 100 إجابة من تطبيقك الحالي، صنّفها يدوياً (15 ممتازة + 15 سيئة + 70 متوسطة)، وشغّل الـ fair_judge فوق ضد إجابات الـ baseline القديم. لو الـ Cohen's Kappa مع تصنيفك طلع تحت 0.6، عدّل الـ rubric وضيف specific failure modes من بياناتك. لو طلع فوق 0.7، أنت جاهز تطلقه على الـ workload الكامل وتخليه gate في الـ CI.

المصادر

• Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", NeurIPS 2023 — arxiv.org/abs/2306.05685
• Wang et al., "Large Language Models are not Fair Evaluators", ACL 2024 — الورقة الأساسية في position bias.
• Panickssery et al., "LLM Evaluators Recognize and Favor Their Own Generations", 2024 — قياس الـ self-preference bias.
• Anthropic Documentation: Evaluating model outputs — docs.anthropic.com/en/docs/test-and-evaluate
• Stanford HAI, Holistic Evaluation of Language Models (HELM) — crfm.stanford.edu/helm
• OpenAI Evals framework — github.com/openai/evals