أصدرت Mistral Leanstral 1.5 في 2 يوليو 2026 كمتخصص تحقق رسمي برخصة Apache-2.0.
اقرأ النتائج داخل مجالها
تقدم Mistral النموذج لعمل البراهين الرسمية. نتيجة PutnamBench المنشورة، 587 مسألة محلولة من 672، ونتائج FATE تخص هذا المجال تحديداً. قد تفيد فريقاً يعمل على Lean، لكنها لا تخبرك شيئاً موثوقاً عن كتابة التسويق أو دعم العملاء.
حجم النموذج لا يحدد العتاد وحده
تذكر Mistral بنية تضم 119B معاملاً إجمالياً و6B نشطة. هذا مهم للتخطيط، لكن متطلبات التشغيل تتغير مع التكميم وخادم الاستدلال وحجم الدفعة وطول السياق والكمون المطلوب.
فتح الأوزان لا يغني عن التقييم
ترخيص Apache-2.0 وإتاحة API مجانية يجعلان النموذج جذاباً للتجربة. لكن، اختبره على مجموعة براهين من عملك، واستخدم مدققاً آلياً للمخرجات، وأضف أمثلة مضادة ومراجعة بشرية.
| الحقل | المعلومة الموثقة |
|---|---|
| التخصص | التحقق الرسمي من البراهين |
| البنية | 119B إجمالي / 6B نشطة |
| الترخيص | Apache-2.0 |
| نتائج المزوّد | PutnamBench 587/672؛ FATE-H 87؛ FATE-X 34 |
التقييم الجيد ينتهي عند المدقق
ابنِ الاختبار على مخرجات يستطيع فريقك التحقق منها، لا على رأي نموذج حَكَم. اختر نظريات مقبولة في مستودعك، وأخفِ البرهان، ثم سجّل هل قبله Lean من دون تعديل يدوي. أضف مقدمات خاطئة عمداً ومسائل ناقصة الصياغة؛ المسار الآمن يرفضها أو يصعّدها بدلاً من اختلاق برهان.
| شريحة الاختبار | ما الذي تسجله؟ | شرط النجاح |
|---|---|---|
| نظرية معروفة | قبول البرهان والمحاولات والزمن | يقبله المدقق بلا تعديلات مخفية |
| صياغة قريبة من الخطأ | مثال مضاد أو رفض واضح | لا يقدم برهاناً غير صالح على أنه مكتمل |
| مهمة من المستودع | الاستيرادات والأسلوب وقابلية الصيانة | ينسجم مع المشروع ويجتاز المراجعة |
| تشغيل الموارد | العتاد والتكميم والكمون | يلائم سقف التشغيل لدى الفريق |
قرار النشر ما زال يملك حقولاً مفتوحة
يوضح الإصدار حجم النموذج وعدد المعاملات النشطة والرخصة وإتاحة API مجانية ونتائج البرهان، لكنه لا يقدم وصفة تشغيل إنتاجية. قبل الاستضافة الذاتية، ثبّت نسخة الأوزان والدقة ومحرك الاستدلال والتزامن والذاكرة وإصدار Lean المستخدم في التقييم. وقبل الاعتماد على التجربة المستضافة، راجع الاحتفاظ بالبيانات وحدود الطلبات وملاءمة الشروط للمستودع.
من يناسبه وضعه في القائمة القصيرة؟
فريق طرق رسمية يملك مجموعة Lean مُصانة ومدققاً آلياً يملك حلقة القياس المناسبة. أما فريق برمجيات عام يريد محادثة أو كتابة أو إكمال شيفرة واسعاً فلا يملك سبباً كافياً. أقوى حجة لتجربة Leanstral ليست الدرجة وحدها، بل أن مخرجاته قابلة للفحص بالأداة التي كُتب العمل من أجلها.
ماذا يحتوي تقرير تقييم يمكن الدفاع عنه؟
انشر نسخة المجموعة وأدوات Lean وسياسة الأوامر وحد المحاولات والوقت وتعريف المسألة المحلولة. افصل بين برهان قُبل من المحاولة الأولى وآخر أصلحه مهندس؛ الرقم الثاني يقيس تعاوناً لا إنجازاً مستقلاً. واحتفظ بالمخرجات المرفوضة ورسائل المدقق حتى يظهر هل كان الفشل رياضياً أم نحوياً أم بسبب استيراد ناقص.
ضع إعداد التشغيل بجانب النتيجة. التجربة عبر API المجانية ليست التجربة نفسها على أوزان مكممة مستضافة ذاتياً. سجّل نسخة الأوزان والدقة والعتاد والتزامن والزمن الفعلي. وإذا عرضت رقم المزوّد للسياق، فسمه رقماً منشوراً من المزوّد ولا تدمجه مع نسبة نجاحك الداخلية.
اختم التقرير بموضع الإنسان في الحلقة: اختيار المقدمات أو مراجعة التكتيكات أو اعتماد تغييرات المستودع أو معالجة فشل المدقق. هذه الحدود أفيد من ترتيب عام؛ فهي توضح ما أزاله النموذج من سير العمل وما بقي مسؤولية مهندس البرهان.