غالباً نتكلم عن قابلية إعادة إنتاج الـ benchmark بعد ما ينتهي inference.
أي نموذج استخدمنا؟ وش كان الـ seed؟ وش إعدادات التوليد؟ وكم كانت النتيجة؟
كل هالتفاصيل مهمة، لكنها مو كفاية.
عشان نقدر نعيد إنتاج نتيجة benchmark، لازم نقدر نعيد إنتاج واجهة التقييم نفسها. يعني ما نثبت النموذج والنتيجة فقط؛ نثبت الأسئلة نفسها، وقالب الـ prompt، والـ prompts النهائية، والـ parser، وقواعد scoring، والـ metadata اللي تربطهم كلهم.
هذا يصير أهم لما تكون الواجهة نفسها جزء من التجربة.
إذا تغيير صيغة الـ prompt يغير النتيجة، فالقالب مو تفصيل تنسيق؛ هو شرط تجريبي. وإذا تغيير الـ parser يغير accuracy، فهو مو تفصيل برمجي؛ هو جزء من طريقة القياس. وإذا تغيير عينة الأسئلة يغير الخلاصة، فالـ item manifest مو ملف للراحة؛ هو جزء من النتيجة.
في عملي على مراجعة الـ Arabic benchmarks، صار لكل تشغيل مسار ملفات ثابت قبل ما يبدأ inference:
الهدف بسيط: أي رقم أعرضه لازم أقدر أرجع منه إلى التجربة المحددة اللي أنتجته.
مو dataset مشابه تقريباً. مو prompt قريب منه. ومو نسخة مولّدة من جديد يفترض إنها مكافئة.
نفس صفوف الأسئلة، ونفس المدخلات النهائية، ونفس قواعد الـ parser، ونفس ملفات الـ scoring.
سهل نتعامل مع قالب الـ prompt كأنه مساعد تنسيق صغير. لكنه مو كذا.
في تقييم benchmark، القالب يحدد وش يشوف النموذج فعلياً. تغييرات صغيرة ممكن تغير قابلية تحليل الجواب، أو تفضيلاته، أو ثباته بين صيغ يفترض إنها متكافئة.
عشان كذا، كل قالب في المراجعة صار معه:
وكل صف rendered prompt يحمل رقم القالب، والـ checksum، ونسخة الـ renderer اللي أنتجته. كذا أقدر أتتبع الاتجاهين: من النتيجة إلى القالب المحدد، ومن القالب إلى كل الـ prompts والإجابات اللي أنتجها.
نفس خرج النموذج ممكن يأخذ نتيجة مختلفة حسب الـ parser. مثلاً، exact parser ممكن يرفض:
The answer is A.بينما permissive parser يقدر يستخرج A.
هذولا مو نفس القياس.
الـ exact parser يقيس الالتزام بصيغة الجواب. والـ permissive parser يقيس هل نقدر نستخرج جواب واضح من النص. الاثنين مفيدين، لكن كل واحد يجاوب سؤال مختلف. عرض النتيجة بدون اسم نظام الـ parser يصعّب تفسيرها.
في المراجعة أعرض الاثنين:
strict_exact: الالتزام الحرفي بالصيغة،permissive_extract: سلوك الإجابة القابل للاستخراج.الفصل بينهم يمنع خلط فشل الـ parsing بفشل المهمة. وهو نفس الفرق اللي ظهر في مراجعة موضع الإجابة في ArabicMMLU: ضبط قابلية التحليل وضّح القياس، لكنه ما ألغى حساسية الـ prompt وموضع الخيار.
نتيجة الـ benchmark مو دالة في النموذج فقط. هي دالة في:
إذا تغير أي واحد منها، ممكن تتغير النتيجة.
لذلك سؤال قابلية إعادة الإنتاج مو بس: هل يقدر شخص يعيد تشغيل السكربت؟ السؤال هو: هل يقدر يعيد بناء نفس التجربة اللي أنتجت الرقم؟
وهذا يشمل الملفات المملة. خصوصاً الملفات المملة.
الـ manifest. والـ template checksum. وملف الإجابات JSONL. ووضع الـ parser. وتقرير التحقق.
هذي الأشياء تمنع نتيجة الـ benchmark من إنها تصير رقم وراءه قصة محد يقدر يتحقق منها. وهذا نفس السبب اللي يخليني أحط الملفات الثابتة والقابلة للتتبع في قلب Atlas: مسار الملفات ما يخلي التفسير صحيح تلقائياً، لكنه يخلي الطريق له قابل للفحص.
تقييم الـ Arabic benchmarks يضيف أماكن أكثر ممكن تأثر فيها الواجهة على القياس.
هذا مو معناه إن الـ Arabic benchmarks خربانة. معناه إن نتائجها تحتاج معها معلومات عن مصدرها وثباتها.
الـ aggregate accuracy ما زالت مفيدة. بس مو كفاية لوحدها.
قابلية إعادة الإنتاج تبدأ قبل الاستدلال.
قبل ما يجاوب النموذج على أي شيء، المفروض التقييم يعرف أي أسئلة يستخدم، وأي قوالب تبنيها، وأي تغييرات تنطبق عليها، وأي parser بيقيّمها، وأي ملفات تثبت إن ما تغير شيء بصمت.
نتيجة benchmark بدون هذا المسار تظل رقم. بس تصير رقم أصعب بكثير إنك تثق فيه.