كيف نقيس، بأي عينة، وما حدود ما نقيسه. وفي الأسفل: كيف تستشهد بالمشروع.
كل تشغيلة في المعيار تُقيَّم على هذه الأبعاد الأربعة، من ١ إلى ٥ لكل بُعد، إلا حيث ورد استثناء. الأبعاد والاستثناءات تُقرأ من data/rubric.json.
مقيّم بشري واحد يسجّل كل تشغيلة يدويًا مقابل هذه الأبعاد، لا حكم انطباعي عام على «جودة» الإجابة. لا يوجد بعد قياس لثبات التقييم بين مقيّمين متعددين — انظر القيود المعروفة أدناه.
الحجم الحالي فعليًا، لا هدف مفترض:
حين تُنشر النتائج، نهدف لتغطية عدة نطاقات استخدام بعدد كافٍ من الطلبات لكل نطاق ليعكس التباين الطبيعي في الأداء — لا حالة اختبار واحدة تُعمَّم على النموذج كله. كل رقم عيّنة فعلي (لا مستهدف) يظهر في هذه الصفحة تلقائيًا من data/prompts.json وdata/runs.json فور نشره.
مجموعة الطلبات الثابتة (v0، سبعة طلبات، كل منها يستهدف نمط عطل مختلف) موثّقة كاملة في data/prompts_v0.md — النص الكامل، المرجع، أنماط العطل المتوقعة، وبروتوكول التسجيل.
٢٬٠٠٩ جملة متوازية من FLORES+ (dev + devtest، ترخيص CC BY-SA 4.0) بالإنجليزية والفصحى وست لهجات. لكل مقسّم، النسبة = مجموع رموز الجمل العربية ÷ مجموع رموز الجمل الإنجليزية نفسها، من غير الرموز الخاصة، مع فترة ثقة ٩٥٪ بإعادة المعاينة على الجمل (٢٬٠٠٠ إعادة). «رموز لكل كلمة» تُسجَّل كمرجع فقط. السكربت scripts/token_tax.py، والنتيجة الكاملة في ضريبة الرموز.
في الحاسبة: التكلفة المحلية شهريًا = إهلاك ميزانية العتاد (على فترة قابلة للتعديل) + تكلفة الكهرباء الفعلية (استهلاك جهازك بالواط × ساعات التشغيل الفعلية × سعر الكهرباء الذي تُدخله) + تكلفة الصيانة (ساعاتك × تكلفة الساعة). تكلفة الواجهة البرمجية شهريًا = حجم الكلمات × نسبة الرموز للمقسّم المختار (من data/tokenizers.json) × السعر الذي تُدخله. حجم التعادل هو حجم الكلمات الذي تتساوى عنده التكلفتان، بافتراض أن التكلفة المحلية شبه ثابتة بصرف النظر عن الحجم ضمن طاقة الجهاز.
لا نفترض جهازًا عامًا ولا سعرًا عامًا للواجهة البرمجية — كلاهما يتغيّر باستمرار، فهما مدخلان منك مباشرة، لا رقمان مدمجان في الأداة.
هذه قيود حقيقية في بناء المشروع كما هو الآن، لا تحفّظ عام:
الصيغة أدناه تُبنى تلقائيًا من رقم الإصدار الحالي وعنوان هذه الصفحة وتاريخ اليوم.
عربي
English