ماذا تعني «خفيفة» هنا؟
نحسن نظام التشغيل كاملاً، بدلاً من تقديم رقم عتاد واحد بلا سياق.لا ينشر الـAPI العام مواصفات GPU أو RAM أو quantization أو مزوداً ثابتاً. العتاد متغير نشر؛ الوعد العام هو سلوك الخدمة المقاس ومنهج القياس القابل لإعادة الإنتاج أدناه.
لماذا يهم ذلك؟
أكبر نشر ليس تلقائياً أفضل نشر. في سير عمل عربي مركز، المقياس المفيد هو الجودة لكل مخرج مقبول: جودة تصمد أمام المراجعة، مقسومة على الوقت والرموز والتكلفة التشغيلية اللازمة لإنتاجها. هذا الإطار يتجنب خطأين شائعين:- مقارنة عدد المعلمات مع تجاهل زمن الاستجابة والإعادات وهدر المخرجات ووقت التحرير البشري.
- الإعلان عن بصمة عتاد صغيرة من دون توضيح التزامن وطول السياق وإعداد الجودة والمنطقة ومعدل الإخفاق الذي تدعمه.
ملف النشر: ما الذي نقيسه؟
قبل وصف ملف نشر بأنه «مواصفات قليلة»، نوثق العناصر التالية مع النتيجة. بهذا يصبح الادعاء قابلاً للتدقيق بين البيئات.مقارنة مسؤولة
يجب مقارنة مبيان بنموذج Frontier على نفس حمل العمل العربي المحجوز، لا بادعاء أن أحدهما أفضل في كل شيء. قد يتفوق نموذج Frontier في الاتساع أو تعدد الوسائط أو الاستدلال المفتوح الصعب. وقد يكون مبيان الأنسب تشغيلياً عندما تكون المصطلحات العربية والعمل التجاري المنظم والتكامل المستقر ومسار التشغيل المتحكم فيه عوامل حاسمة. تُثبّت الـprompt والسياق وسقف المخرج ودرجة الحرارة والأدوات وسياسة الإعادة والمنطقة وrubric التقييم. راجع منهجية Benchmark لعقد التقرير الكامل.قائمة المشغّل
- ابدأ بحمل عربي محجوز يمثل الاستخدام الحقيقي، لا prompts عرض تجريبي.
- شغّل baseline بالتزامن وحدود السياق المقصودة.
- التقط الزمن والاعتمادية والجودة معاً؛ لا تحسن واحداً منها في عزلة.
- صنّف كل إخفاق: timeout أو قيد مفقود أو عربية ضعيفة أو مهمة غير مدعومة أو خطأ أداة أو خطأ واقعي.
- قارن المخرجات المقبولة، لا عدد الرموز الخام أو رقم leaderboard واحداً.
- انشر manifest مؤرخاً للنشر قبل تحويل نتيجة كفاءة داخلية إلى رقم علني.