مقال على Open Athena: ثلثا بيئات تدريب نموذج MiMo البرمجية كانت تحتوي على الحل نفسه

نشر David Hall على موقع Open Athena في 15 أكتوبر 2026 مقالًا بعنوان «There is no posttraining data commons»، أي لا يوجد مخزون مشترك لبيانات التدريب اللاحق، وقد انتشر على Hacker News في 3 نوفمبر.

وتقوم فكرة المقال على فرق بين مرحلتين. فالتدريب الأساسي للنموذج يتغذى على نصوص موجودة أصلًا، مثل Common Crawl وويكيبيديا. أما التدريب اللاحق فيتغذى على مهام، وكل مهمة تحتاج إلى بيئة وهدف وأدوات وحَكَم يقرر هل نجح النموذج أم لا. وهذا النوع من البيانات لا يوجد جاهزًا، بل يجب أن يصنعه أحد.

ويسوق المقال أرقامًا توضح صعوبة هذه الصناعة. فاختبار SWE-bench الأصلي بدأ من أكثر من 90 ألف pull request من 12 مستودعًا، ولم يصلح منها للتحول إلى مهمة إلا واحد من كل 8، أي 11,407. ثم تبين أن نحو 80% منها لا يمكن تشغيله، فبقيت 2,294 مهمة.

وفي نسخة SWE-bench Verified، استعانت OpenAI بـ 93 مطورًا بلغة Python لمراجعة 1,699 مهمة، فوُضعت علامة على أكثر من ثلثيها، وبقيت 500.

وفي تدقيق على نموذج MiMo من Xiaomi، وُجد أن ثلثي بيئات البرمجة البالغة 2,698 بيئة ما زالت تحتوي على الإصلاح المرجعي، أي الحل نفسه، متاحًا عبر سجل git.

ولهذا أثر مباشر على الفرق التي تختار النماذج أو تدربها. فالرقم الذي يُقارن به بين نموذجين لا يقيس دائمًا ما يُفترض أنه يقيسه. والفريق الذي يجري fine-tuning على مهام عامة منشورة قد يكون يدرب النموذج على نسخ الحل لا على الوصول إليه. ويجعل ذلك بناء مجموعات تقييم خاصة، أو ما يسمى evals، جزءًا من عمل الفريق نفسه لا خطوة يمكن استعارتها جاهزة.