Saiga Llama 3 8B على 10 جيجابايت VRAM: كيف حققت Habr دقة 93٪ في حرب وسلام

تم نشر تحليل عملي على Habr AI حول تشغيل Saiga Llama 3 8B على بطاقة RTX 3080 محلية بسعة 10GB من الذاكرة لتلخيص المجلدين الأول والثاني من "الحرب والسلام". أظهرت التجربة أن المشكلة الرئيسية مع نماذج اللغة الكبيرة المحلية في مثل هذه المهمة ليست فقط الذاكرة المحدودة، بل أيضاً الهلوسات على مستوى الحقائق والأسماء والتسلسل الزمني.

التشغيل على 10GB

قام المؤلف ببناء خط معالجة حول IlyaGusev/saiga_llama3_8b مع تكميم 4 بت وقام بتشغيل النموذج على بطاقة RTX 3080 محلية بسعة 10GB من الذاكرة. لم يكن بالإمكان وضع النص الكامل للمجلدين في الذاكرة، لذا اضطر المؤلف إلى تقسيم الرواية حسب الفصول وتحديد حجم كل مقطع. بعد عدة محاولات، أصبح الحل الفعلي حوالي 7500 حرف لكل قطعة: فقد أقل كان يعني فقدان الكثير من السياق، بينما زيادة الحجم كانت تزيد من خطر الأعطال والامتلاء الزائد للذاكرة.

استخدم المؤلف مكتبات transformers و bitsandbytes، وتحقق من دقة الملخصات عبر Gemini. واجه المؤلف بعض الآثار الجانبية غير المتوقعة: قامت Qwen2.5-7B-Instruct مرة واحدة بإنتاج قطعة طويلة من رمز Python مع توصيات المكتبات بدلاً من الملخص.

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

من أين جاءت الهلوسات

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

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

أظهرت فحوصات اللوغاريتمات أن المحفز يمكنه فعلاً أن يغير بشكل جذري اختيار الرمز التالي.

"لا تقتل الأبطال! نيكولاي روستوف ينجو في شينجرابن".

ما الذي ساعد فعلاً

في النسخة العاملة من خط المعالجة، أصبحت القواعد مباشرة جداً: التحقق من الألقاب مع قاعدة بيانات الشخصيات، عدم اختلاق خطوط رومانسية، تذكر أن الحدث يدور في سنة 1805، والكتابة بصراحة إذا انقطع المقطع قبل الخاتمة. بالموازاة، قلل المؤلف معاملات التوليد - درجة الحرارة 0.1، و top_p 0.85، و repetition_penalty 1.15. كانت الفكرة بسيطة: إبداع أقل، إغراء أقل لاستكمال تولستوي بنفسك. وكلما كانت الإجابة أكثر استقراراً.

• تكميم 4 بت بدلاً من التحميل بالحجم الكامل
• تقسيم النص حسب الفصول مع حد يبلغ حوالي 7500 حرف
• محفز نظامي صارم مع قاعدة بيانات الشخصيات
• درجة حرارة منخفضة و top_p محدود
• معالجة لاحقة للأخطاء النادرة في الألقاب

لم تجعل مجموعة التدابير هذه النظام خالياً من الأخطاء، لكنها قللت بشكل كبير من عدد الهلوسات الحرجة. أعطت التقييم النهائي عبر Gemini 3 Flash دقة واقعية متوسطة حوالي 93%، مع بقاء معظم الفصول في نطاق 90-98%. بقيت الأخطاء الأكثر لفتاً للانتباه على مستوى الرموز والمورفيمات: في مكان واحد ظهر "بيير بيزدارفسكي"، وهو مزيج من اللقب بيزوخوف والكلمة "بلا موهبة". يعتقد المؤلف أن مثل هذه الأعطال النادرة من الأسهل اكتشافها في المعالجة اللاحقة بدلاً من تعقيد المحفز أكثر.

ماذا يعني هذا

تُظهر هذه الحالة شيئاً مهماً لنماذج اللغة الكبيرة المحلية: حتى على بطاقة رسومات للمستهلك، يمكنك بناء خط معالجة مفيد للنصوص الطويلة، لكن النجاح يعتمد ليس فقط على النموذج وكمية الذاكرة. غالباً ما تقرر التعليمات الصارمة والتحكم في التوليد والمعالجة اللاحقة - أي الهندسة حول نموذج اللغة، وليس زر سحري واحد "اقرأ الكتاب من أجلي".