LLM-as-a-Judge للمحترف: قيّم 10,000 إجابة AI بـ $30 بدل $5,000

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

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

السطر الأخير ده هو سر الموضوع. الـ 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