صرت أجمّد مدخلات الـbenchmark وقواعد التقييم قبل الاستدلال. السجل يربط كل سؤال بالـprompt الفعلي والخرج والـparser والدرجة. هذي طريقة لإعادة التجربة، وما فيها نتيجة دقة جديدة هنا.
أي نموذج استخدمنا؟ إيش كان الـ 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 بيقيّمها، وأي ملفات تثبت إن ما تغير شيء بصمت.
بدون المسار هذا يبقى عندنا رقم، بس يصير أصعب نعرف بالضبط إيش قاس وكيف نعيده.