Evals لتطبيقات AI: ازاي تختبر LLM بتاعك من غير ما تخمّن

السيناريو: تطبيق بيصنّف رسائل دعم فني لـ 3 فئات (billing، technical، general). عندك 50 رسالة متصنّفة يدويًا في test_set.json.

التشغيل بيرجّع رقم زي Accuracy: 84.00% (42/50). لما تعدّل الـ system prompt وتشغّله تاني وييجي 91%، عندك دليل مكتوب — مش شعور. وملف failures.json بيوريك بالظبط الحالات اللي فشلت، فبتقدر تحلل النمط.

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

على نفس المهمة (تصنيف 200 تذكرة دعم بالعربي) قِسنا التالي على Anthropic SDK باستخدام Haiku 4.5:

• Prompt v1 (سطر واحد بدون أمثلة): 76% accuracy، التكلفة ≈ 0.03$.
• Prompt v2 (مع 3 few-shot examples): 89%، التكلفة ≈ 0.07$.
• Prompt v3 (few-shot + structured output JSON): 94%، التكلفة ≈ 0.09$.

الفرق بين v1 و v3 = 18 نقطة accuracy مقابل زيادة 0.06$ في تكلفة الست بالكامل. من غير eval set، الفرق ده كان هياخد قرار بناءً على «اللي حسّيته أحسن»، واللي حسيته أحسن بيتأثر بآخر مثال شفته.

Trade-offs لازم تعرفها قبل ما تبني نظام Evals

LLM-as-judge أرخص من human eval لكن مش مجاني. 200 case × judgment على Sonnet ≈ 0.40$ بـ caching، وبدون caching ممكن توصل 1.20$. كمان الـ judge بيفضّل الإجابات الطويلة (verbosity bias)، فلو مش حاسبة في الـ prompt بتاع الجدج بإن «الطول مش معيار»، نتايجك بتميل للنماذج الثرثارة.

Test set صغير = أرقام ضوضائية. لو test set بتاعك 20 case، فرق 3 نقاط (مثلاً 75% → 78%) مش معناه تحسّن، معناه عشوائية. الافتراض هنا إنك عايز confidence interval ضيّق، والحد الأدنى المعقول: 100 case للـ classification، 50 للمهام المفتوحة مع human review على عيّنة من المخرجات.

Drift. مدخلات المستخدمين بتتغير بمرور الوقت (موسمية، مصطلحات جديدة، features اتضافت للمنتج). eval set من 6 شهور غالبًا مش بيمثّل اللي بيحصل دلوقتي. حدّث 10–20% من الست كل ربع سنة من logs الإنتاج الحديثة.

متى لا تستخدم Evals مؤتمتة

للمهام الإبداعية البحتة (كتابة شعر، مقالات تسويقية بصوت شخصي، scripts إعلانات)، الـ eval المؤتمت بيقيس الشكل مش الجودة. هنا human eval على عيّنة صغيرة (10–20 مخرج) بترجع نتيجة أصدق من LLM-as-judge على 500 case. كذلك في تطبيقات بدخل مستخدم متنوع جدًا (chatbot عام بدون scope محدد)، Evals مرحلة أولى لكن ما بيغنوش عن مراقبة production logs و user feedback signals زي thumbs-up/down.

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

افتح آخر 50 طلب من logs تطبيق AI بتاعك. اختار 30 منهم اللي ممثّلين للمستخدمين الفعليين (مش edge cases مختارة). اكتب الإجابة الصح يدويًا لكل واحد. ده test set v0 الخاص بيك. شغّل eval زي اللي فوق على prompt الحالي، وسجّل الرقم. أي تعديل من النهاردة بيتقاس بنفس المسطرة. لو الرقم نزل، اعمل rollback. لو طلع، اعمل ship.

المصادر

• Anthropic Documentation — Develop tests and evaluations: docs.anthropic.com/en/docs/build-with-claude/develop-tests
• OpenAI Evals framework (open-source): github.com/openai/evals
• Zheng et al., 2023 — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 (مرجع verbosity وposition bias).
• EleutherAI — LM Evaluation Harness: github.com/EleutherAI/lm-evaluation-harness
• Eugene Yan, 2024 — Evaluating LLM Applications: eugeneyan.com/writing/evals/
• Hamel Husain, 2024 — Your AI Product Needs Evals: hamel.dev/blog/posts/evals/