المشروع الختامي — نقل أمر واحد عبر 8 نماذج
comparison rubric — تـscore 8 outputs
عندك 8 captures خام. محتاج تـscore-هم على الأبعاد اللي بتفرق فعلاً للـapp بتاعك. الإغراء هو إنك تقرا المخرجات وتعمل انطباع حدسي. قاوم ده. ابني rubric، سجّل كل output قبال الـrubric من غير ما تشوف اسم النموذج، وبعدين بصّ على الـscores المجمّعة.
5 أبعاد rubric إنت بتـscore عليهم فعلاً
التزام القيود
- سهل تـscore-ه blind
- بيمسك dialect quirks مباشرة
الأمانة (faithfulness)
- حاسم للـcompliance/legal
- بيمسك drift دقيق
تطابق النبرة
- محتاج أمثلة anchor
- scorer واحد لكل الصفوف
Format usability
- ميكانيكي للاختبار
- تكلفة مباشرة في pre-processing time
Cost per acceptable output
- بيربط اختيار النموذج بالميزانية
- بيكشف الـpatterns الرخيصة-المعطلة
الـ5 أبعاد للـscoring
5 أبعاد بتغطّي تقريباً كل production prompt. اختار الـ4 أو 5 الأقرب للمهمة بتاعتك تحديداً وعدّي الباقي.
1. التزام القيود. لو الـprompt بتاعك فيه قيود صارمة (word count، format، كلمات ممنوعة، عدد سطور)، الـoutput التزم بكل قيد؟ سجّل نقطة لكل قيد متبع، اجمعهم. ده البُعد الأكتر objective.
2. الأمانة. الـoutput ضاف facts، خفّف claims، قوّى claims، أو هلوس محتوى؟ شفت ده مقيّس مباشرة في module 2 درس 3 (ملخص شاي الأعشاب). سجّل 0-3: 3 = أمانة كاملة، 2 = drift خفيف، 1 = drift ملحوظ، 0 = محتوى مفبرك.
3. تطابق النبرة. الـoutput بيبان زي الـbrand بتاعك أو صوت الـapp؟ ده أكتر ذاتية. استخدم scoring 0-3 بـanchors صريحة: 3 = على الـvoice، 2 = محايد بس مقبول، 1 = بره الـvoice، 0 = محرج.
4. Format usability. الكود ورا يقدر يستهلك الـoutput من غير pre-processing؟ سجّل: 3 = بيتـparse على طول، 2 = محتاج regex أو شيلة بسيطة، 1 = محتاج إعادة كتابة structured، 0 = ما يتـparse-ش.
5. Cost-per-acceptable-output. ده الكبير. احسب: الـdollar cost لـcall واحدة مقسومة على احتمال إن الـoutput يبقى مقبول. نموذج بيكلّف $0.001 بس بيطلّع إجابة مقبولة 60% من الوقت فعلاً بيكلّف $0.0017 لكل إجابة مقبولة. نموذج بيكلّف $0.005 بس بيطلّع إجابة مقبولة 95% من الوقت فعلاً بيكلّف $0.0053. النموذج الأرخص-per-call ممكن يبقى أغلى في الممارسة.
إزاي تخلّي الـscoring أمين
3 قواعد:
-
سجّل blind. شيل model labels قبل الـscoring. استخدم column header زي "Output A, B, C..." واكشف أنهي نموذج طلّع أنهي بس بعد ما الـscores تتقفل. ده بيلغي الـbias ناحية النموذج اللي إنت متوقّع يكسب.
-
استخدم نفس الـscorer لكل الصفوف. بشر مختلفين هيـscore-وا أبعاد ذاتية بشكل مختلف. لو الـrubric محتاج subjective scoring، شخص واحد يعمله كله. لو تقدر تستخدم LLM كـscorer، أحسن — بس اختار نموذج مختلف عن اللي بتقيّمهم، ولا الـscorer هيبقى متحيّز ناحية لهجته.
-
سجّل على 20 input على الأقل، مش 1. input واحد ده anecdotal. 20 capture بيدّوك توزيع حقيقي. grid 8 نماذج × 20 input هي 160 cell، اللي هي كم ساعة شغل بس بتطلّع تقرير يقدر يدافع عن نفسه.
الـrubric مش إيه
الـrubric مش leaderboard للمجال. هو leaderboard للـprompt المحدد بتاعك. نموذج بيـscore قليل على الـrubric بتاعك ممكن يكون الأحسن في العالم في مهمة تانية. تقرير هاجر "للـprompts اللي الـapp بتاعنا بيبعتها، أهو اللي المفروض نستخدمه" — مش "أهو اللي البشرية المفروض تستخدمه".
الضيق ده هو قوة التقرير. مقارنة عامة "Claude vs GPT vs Gemini" مستحيل تطلّع منها توصية تنشحن. محدد "للـcustomer-reply prompt بتاعنا اللي بيتبعت 50,000 مرة في اليوم، أهو الـrouting" قابل للشحن يوم الجمعة.
التالي: بناء التقرير — structure بيـsurvive قراءة من القيادة. :::
سجّل الدخول للتقييم