AISubHub/أخبار الذكاء الاصطناعي
الأبحاث

تحليل معمق · قراءة نحو 7 دقائق

دراسة Claude لإثبات خصائص 123 مكتبة تحدد ضمانات البرمجيات ولا تجعلها شاملة

تعلن Anthropic وTheorem عن براهين لـ239 نقطة دخول لاختبارات التشويش في 123 مكتبة، مع افتراضات صريحة عن الآلة وحدود لما تثبته النتائج.

نُشر هنا
تاريخ المصدر
تم التحقق من المصدر

في مقال بحثي نُشر في 22 أكتوبر، تعرض Anthropic عملاً مع Theorem يستخدم Claude لتوليد براهين برمجية تتحقق منها الآلة. والنتيجة المفيدة هي ضمان يخص برامج تنفيذية محددة ضمن نموذج معرّف، وليست شهادة بأن مكتبة كاملة أو جميع بيئات نشرها آمنة.

استمع إلى الأخبار

استمع إلى هذا المقال أو تابع تشغيل الأخبار.

دراسة Claude لإثبات خصائص 123 مكتبة تحدد ضمانات البرمجيات ولا تجعلها شاملة

جارٍ تجهيز القراءة…

صوت الجهاز

يتولى المتصفح أو الجهاز معالجة النطق. لا يرسل AISubHub النص إلى واجهة صوتية. تختلف الأصوات والتشغيل مع قفل الشاشة حسب الجهاز.

قد تتكرر عبارة قصيرة عند المتابعة.

لمحة سريعة

  • يقول الباحثون إنهم أثبتوا عدم الانهيار عند 239 نقطة دخول في 123 مكتبة ضمن OSS-Fuzz، بعد إصلاح الأخطاء المكتشفة عند الحاجة، لمدخلات أصغر من 64 MB وتحت الافتراضات المعلنة.
  • تتناول التجربة الرئيسية برامج RISC-V أحادية الخيط، مرتبطة ربطاً ساكناً مع musl، وسلوك Linux كما صيغ في النموذج. ولا تشمل تلقائياً عمليات النشر المعتادة على x86 أو ARM.
  • تقارن تجارب منفصلة على مهام صغيرة بين احتياجات النماذج من الرموز وبين مشاركة البراهين. نسب التوفير المعلنة تخص تلك التجارب، ولا تمثل ضماناً عاماً للسعر أو الأداء.

كل برهان يغطي نقطة دخول ضمن آلة محددة

من المهم تحديد وحدة التغطية. نقطة الدخول في OSS-Fuzz هي مسار اختبار يوفره المطور لإدخال البيانات إلى البرنامج وإظهار حالات الفشل. وتقول Anthropic إنها أنجزت خلال عدة أسابيع براهين لـ239 نقطة دخول من هذا النوع موزعة على 123 مكتبة. لا يعني ذلك التحقق الكامل من 239 مكتبة، ولا تغطية كل مسار ممكن داخل المكتبات الـ123. وقد أنتج المشروع نحو 180 مليون سطر من شيفرة براهين Rocq؛ وبلغ حجم البرهان المعتاد نحو 600,000 سطر، بينما كان وسيط عدد تعليمات RISC-V في الملفات الثنائية 18,000 تعليمة.

يتحدد الادعاء بقيود التنفيذ المُمثَّل في النموذج: مدخلات أصغر من 64 MB، وميزانية ذاكرة ثابتة، وخيط واحد، وبرنامج تنفيذي ساكن لـRISC-V مرتبط مع musl، واستجابات Linux وتخطيطات ذاكرة محددة. وهذه الشروط هي التي تعرّف العبارة الرياضية المراد إثباتها. وترى AISubHub أن معرفة إجمالي النطاق الذي تُقاس عليه التغطية وإعدادات البناء أنفع لتقييم النتيجة من الاكتفاء بالعدد اللافت لإجمالي أسطر البراهين.

تحويل اختبار التشويش إلى ادعاء تفحصه نواة تحقق صغيرة

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

لا يحق للنموذج أن يقرر بنفسه صحة برهانه. يفحص Rocq البرهان في ضوء العبارة المطلوب إثباتها. وبذلك ينتقل موضع الثقة إلى العبارة الدقيقة، ودلالات RISC-V وLinux، وأداة التحقق، بما في ذلك العتاد والبرمجيات التي تعتمد عليها. وهذا نطاق مراجعة أصغر من قراءة ملايين الأسطر المولدة، لكنه يظل اعتماداً حقيقياً. فصحة البرهان لا تثبت أن نموذجاً غير دقيق للآلة يصف نظام الإنتاج وصفاً أميناً.

لماذا قد تنتج محاولة إثبات فاشلة إصلاحاً مفيداً

بحسب الباحثين، كشفت محاولات الإثبات عن أخطاء، منها مشكلة في أداة لفك الضغط تتطلب مدخلاً منظماً على نحو غير معتاد بحجم يقارب 20 MB، وفشل في فك ترميز الصور يتطلب مدخلاً بحجم 64 MB وأكثر من 2 GB من الذاكرة. توضح هذه الأمثلة لماذا قد يفوت البحث الذي تهيمن عليه المدخلات الصغيرة سلوكاً ذا صلة. وهذه نتائج أبلغ عنها المصدر، وليست ثغرات أعادت AISubHub إنتاجها بشكل مستقل.

كان بإمكان خط العمل إصلاح البرنامج، وإعادة توليد مواصفته، ثم إثبات خصائص الناتج المعدل. ولا يجوز تقديم برهان هذا الناتج الجديد بوصفه برهاناً للإصدار الأصلي غير المعدل. وهناك أيضاً خطر الاختصار المخل: فقد يحذف وكيل سلوكاً مفيداً كي يصبح إثبات عدم الانهيار سهلاً. ويصف المؤلفون عقوبات على التعديلات، وحوافز لتوصيف المدخلات التي تغيّر سلوكها، وتدقيقاً للرقع. تعالج هذه الضوابط نمطاً من أنماط الفشل، لكنها لا تلغي الحاجة إلى مراجعة ما إذا كان الإصلاح يحافظ على السلوك المقصود.

توفير الرموز ناتج عن تجربتين مختلفتين

في مجموعة منفصلة تضم 36 مهمة تحقق صغيرة، يقول المقال إن Opus 5.5 يثبت نصف المهام باستخدام رموز أقل بنحو 40% مقارنة بـOpus 5. خُصصت لكل مهمة ثلاث محاولات مستقلة ينفذ كل منها وكيل واحد، بميزانية 5,000,000 رمز لكل محاولة. واحتسب الرسم المهمة عند اكتمال أول محاولة ناجحة. هذه مقارنة تخص مجموعة مهام وميزانية محددتين. ولا يحدد المقال جميع النماذج المستخدمة في العمل الأكبر على 123 مكتبة، لذا لا يصح إعادة وصف هذا العمل كله بأنه نتيجة لـOpus 5.5.

أتاحت تجربة مساحة العمل المشتركة للوكلاء إعادة استخدام براهين بعضهم بعضاً، وأعلنت عن استخدام رموز أقل بنسبة 17% مقارنة بالعمل المنعزل. ويُظهر رسمها الذي يتناول 36 برهاناً انخفاض استخدام الرموز في 30 من أصل 34 مقارنة اكتمل فيها العمل الفردي؛ أما الوكلاء المنعزلون فلم ينجزوا مهمتين. وتقدم إعادة استخدام براهين تهيئة بيئة التشغيل وأدوات كشف الأخطاء آلية ملموسة لهذا التوفير. ولا تعطي أي من النسبتين تكلفة عامة بالدولار، أو تحسناً مضموناً في الزمن المنقضي، أو فائدة للنشر قِيست بصورة مستقلة.

دراسات الحالة الأخرى تقيس أنواعاً مختلفة من الصحة

يصف المقال أيضاً تجربة على zlib باستخدام دلالات x86 ومواصفة مشتقة من RFC. وهذه دراسة حالة منفصلة، وليست دليلاً على أن نتائج RISC-V الواسعة تنطبق بالفعل على جميع برمجيات x86. كما جرى فحص مفسر مكتوب بلغة Rust لمجموعة فرعية كبيرة من Python، باستخدام Verus ومقارنته بدلالات CPython المُمثَّلة في نموذج، ثم مقارنته تجريبياً مع CPython على أكثر من 1.7 مليون برنامج مولد عشوائياً.

تخص نسبة تطابق السلوك المعلنة، البالغة 99.95%، تلك المقارنة التجريبية. وهي ليست برهاناً على التوافق مع كل برنامج Python. وهذا تمييز مهم: فالبرهان يثبت عبارة شكلية بعينها، بينما تصف نسبة الاختبار تجربة على عينة. ودمج هذه النتائج في درجة عامة واحدة لدقة النموذج يخفي اختلاف المواصفات والأدوات والحالات الحدية التي ما زالت قائمة.

المكسب الهندسي هو جعل حدود الضمان أوضح

يصرح المؤلفون بوجود فجوات. تفوّت AddressSanitizer بعض أخطاء الذاكرة؛ ولم يشمل المشروع كل نقطة دخول؛ وحتى تغطية جميع نقاط دخول اختبارات التشويش لن تغطي كل سلوك المكتبة أو الشيفرة غير القابلة للوصول. ويمكن للبرنامج المستدعي أن يسيء استخدام المكتبة خارج الافتراضات التي جرى التحقق منها. كما أن عمليات النشر الشائعة تستخدم الربط الديناميكي وglibc وx86 أو ARM، وهي تختلف عن التجربة الرئيسية. وحُجبت بعض البراهين كي لا تكشف أخطاء لم تُصلح بعد، وتظل خارطة الطريق الأوسع للمنظومة الواردة في المقال مجرد اقتراح.

تحليل AISubHub: تتمثل الخطوة العملية التالية في ربط كل ضمان مُعلن ببناء دقيق، ونقطة دخول للاختبار، وحد للمدخلات، ونموذج آلة موثوق، ثم إعادة تقييمه عند تغير هذه الشروط. ويمكن لهذا أن يكمّل الاختبارات والمراجعة، ولا يبرر إلغاءهما على مستوى المشروع كله. قرأنا المقال ورسومه الضرورية، لكننا لم نعد تشغيل البراهين، ولم ندقق الملحق الخارجي أو المستودعات المنشورة، ولم نتحقق من أمان الرقع أو نعد إنتاج توفير الرموز. وتظل النتائج والتوقعات المستقبلية منسوبة إلى الباحثين.

لماذا يهم

تحليل AISubHub: قد تجعل البراهين المولدة إثبات خاصية برمجية ضيقة قابلة للمراجعة وإعادة استخدامها أقل تكلفة. والناتج القابل للعمل به هو الأثر البرمجي المحدد والعبارة التي جرى التحقق منها مع افتراضاتهما، وليس ادعاءً عاماً بأن الذكاء الاصطناعي جعل البرمجيات خالية من الأخطاء.

القيود والتوافر

هذا تحليل للرواية التي نشرها الباحثون، وليس تدقيقاً أمنياً مستقلاً أو إعادة إنتاج للتجربة. وتظل حدود المدخلات والمعمارية والربط والذاكرة ونقاط الدخول في التجربة الرئيسية أساسية؛ ولم تُدقق محتويات الملحق الخارجي والمستودعات.

المصادر والأدلة

Anthropic Frontier Red Team / Theorem · Formal software verification

تاريخ المصدر: · تم التحقق من المصدر:

مقالات تحريرية بمساعدة الذكاء الاصطناعي تُراجع مقابل المصادر الأولية المذكورة. تُنسب ادعاءات الشركات إليها، والإدراج لا يعني التوصية.