LLM لا تتعامل جيدًا مع unsafe Rust: ستة أشهر من الاختبارات كشفت أخطاء حرجة
على مدى ستة أشهر، جعل المؤلف نماذج LLM تكتب شيفرة unsafe Rust في مشاريع حقيقية، وحلّل النتائج باستخدام Miri. النماذج تخطئ بشكل متكرر: aliasing، وprovenance، وla
أعطى الكاتب نماذج LLM مهمة كتابة كود Rust غير آمن (unsafe Rust) في مشاريع الإنتاج لمدة ستة أشهر وتحقق من كل كتلة باستخدام Miri والمعقمات. كانت النتيجة مخيبة للآمال: تُرتكب الأخطاء نفسها بشكل متوقع وثابت من قبل النماذج.
سبع فئات من أخطاء LLM في unsafe Rust
تُرتكب أخطاء النماذج بشكل متسق في نفس المواضع:
- Aliasing — انتهاك قاعدة المراجع غير المتداخلة
- Provenance — محاولات استخدام المؤشرات التي تم الحصول عليها بشكل غير صحيح
- Layout في alloc/dealloc — عدم توافق الحجم/المحاذاة أثناء التخصيص والتحرير
- ManuallyDrop — ينسون استدعاء drop أو الوصول إلى الكائن بعد drop
- تنافس الوصول في callbacks FFI — حالات تنافس عند استدعاء دوال C من threads
- Send/Sync يدويًا — تنفيذ غير صحيح لسمات أمان الخيوط
- ذاكرة Uninit — معاملة البيانات غير المهيأة كما لو كانت مهيأة
لماذا كشف Miri المشاكل
Miri هو مترجم Rust يتتبع السلوك غير المعرّف. عندما تُنشئ نماذج LLM كودًا بانتهاكات دقيقة للوهلة الأولى (على سبيل المثال، مؤشر مؤقت بمصدر غير صحيح)، يتجاهلها المترجم العادي، لكن Miri يكتشفها. تحت المعقمات (AddressSanitizer، ThreadSanitizer)، تم الكشف عن حالات تنافس واستخدام بعد التحرير، والتي قد لا تظهر في الاختبارات العادية.
«تأتي كل فئة مع مثال أدنى وإصلاح» — يوضح المؤلف أن هذه ليست مجرد
ملاحظات، بل أنماط أخطاء قابلة للتكرار.
ماذا يعني هذا
نماذج LLM لم تكن جاهزة بعد لكتابة unsafe Rust دون إشراف بشري. تُنشئ الصيغة والمنطق العام بشكل جيد، لكنها ترتكب أخطاء منهجية في إدارة الذاكرة والمعالجة المتعددة للخيوط. بالنسبة للكود الحرج (برامج النظام، مكتبات النظام)، يجب التحقق من unsafe Rust من النماذج بواسطة Miri.