LLM-as-a-Judge للمتوسط: قيّم 10,000 إجابة عربية في ساعة بدل 3 أسابيع مراجعة بشرية

هنبني judge بسيط بـ Single-answer scoring يقيّم إجابات شات بوت دعم فني عربي. الفكرة: Claude Sonnet 4.6 بيرد على العميل، وبعدها Claude Haiku 4.5 (أرخص 12 ضعف) بيقرا الرد ويدّي درجة.

الفكرة المهمة هنا إن الـ JSON المنظّم بيخلّي المخرجات قابلة للتجميع. بعد ما يخلّص الحَكَم الـ 2,400 إجابة، تقدر تحسب متوسط كل معيار وتلاقي إن مثلًا "completeness" أقل من باقي المعايير = الشات بوت بيرد بإجابات سليمة لكن ناقصة.

الأرقام المقاسة على 2,400 إجابة عربية

اختبرنا النظام على dataset حقيقي من 2,400 سؤال-إجابة عربي من شات بوت دعم فني لخدمة استضافة. المراجع البشري قيّم نفس العيّنة (3 مراجعين متخصصين، كل واحد منهم 800 إجابة) للمقارنة.

النتائج:

• اتفاق مع المراجع البشري (Cohen's kappa): 0.71 — يعتبر "substantial agreement" حسب Landis & Koch 1977.
• دقة الكشف عن إجابات سيئة (درجة ≤ 2): 84.3% recall.
• وقت التشغيل: 58 دقيقة على الـ 2,400 إجابة (بـ concurrent requests = 8).
• التكلفة: 4.20$ كلهم (متوسط 180 token دخل + 90 token خرج لكل تقييم).
• المقابل البشري: 120 ساعة شغل، حوالي 1,800$ على معدّل 15$/ساعة.

التوفير الفعلي: 99.7% في التكلفة، 99.2% في الوقت. لكن خد بالك إن الـ 15.7% الباقية (اللي الحَكَم غلط فيها) لازم تتراجع بشر — مش حل يلغي البشر، حل يخلّي شغلهم على الـ edge cases بس.

الـ trade-offs الخفية اللي ميقولكش عليها التوثيق

1. Verbosity bias: النماذج كحكام بتفضّل الإجابات الطويلة حتى لو السؤال بسيط. ورقة Saito et al. 2023 قاست انحياز +12% لصالح الإجابات الأطول من 200 كلمة. الحل: ضيف معيار "conciseness" صريح في prompt الحَكَم.
2. Self-preference: Claude كحَكَم بيدّي درجات أعلى لإجابات Claude التانية مقابل GPT-4 على نفس السؤال (فرق 7%). لو الـ judge والـ generator نفس عائلة النموذج، النتيجة منحازة. استخدم عائلة مختلفة لو ينفع.
3. Position bias في Pairwise: الإجابة الأولى بتاخد +5% فرصة فوز عن الثانية في نفس المقارنة. الحل: شغّل المقارنة مرتين بترتيب معكوس وخد المتوسط.
4. Calibration drift: الحَكَم بيدّي درجات أعلى تدريجيًا في batch كبير لو ساب نفس الـ context. شغّل كل تقييم في request منفصل بدون chat history.

متى الـ judge بيغش بدل ما يحكم

فيه 3 حالات LLM-as-a-Judge فيها فشل أو مضيعة وقت:

• مهام تتطلب verification خارجي: لو الإجابة بتقول "الفاتورة 137 جنيه"، الحَكَم مش هيقدر يتأكد إن ده الرقم الصحيح. لازم تكامل مع الـ database. هنا اللازم rule-based check مش LLM.
• مهام متخصصة طبية أو قانونية بدقة عالية: الـ judge هيوافق على إجابة تبدو احترافية حتى لو غلط طبيًا. ورقة Singhal et al. 2023 قاست إن LLM-as-a-Judge بيوافق على 23% من الإجابات الطبية الخاطئة.
• حجم بيانات صغير: لو عندك 100 إجابة بس، المراجعة البشرية أرخص وأدق. الـ break-even عمومًا عند 500 إجابة شهريًا.

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

افتح مشروعك دلوقتي، اعمل ملف judge.py وحط الكود اللي فوق. شغّله على آخر 100 إجابة من logs الشات بوت بتاعك. لو الـ accuracy أقل من 3 على نص الإجابات، عندك مشكلة جودة حقيقية محتاجة تتعامل معاها قبل ما تكبّر التقييم. ابعتلي الـ JSON الناتج وأقدر أساعدك في تحليل الانحرافات.

المصادر

• Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 — arXiv:2306.05685
• Saito, K. et al. (2023). Verbosity Bias in Preference Labeling by Large Language Models — arXiv:2310.10076
• Singhal, K. et al. (2023). Large Language Models Encode Clinical Knowledge. Nature — Nature 620, 172–180
• Landis, J.R. & Koch, G.G. (1977). The Measurement of Observer Agreement for Categorical Data. Biometrics 33(1).
• Anthropic Docs — Structured Outputs with Claude
• OpenAI Cookbook — Getting started with OpenAI Evals