النماذج اللغوية الكبيرة· الدرس 5 من 7
- 1إزاي الـ LLM بيشتغل من جوه8 دقيقة
- 2الـ Context Window — ذاكرة الموديل المؤقتة7 دقيقة
- 3الـ Temperature والـ Sampling — التحكّم في العشوائية7 دقيقة
- 4رسائل الـ System والـ User — مين بيتكلّم7 دقيقة
- 5اختيار الموديل — الأكبر مش دايمًا الأحسن8 دقيقة
- 6اللي الـ LLM ما بيعرفش يعمله7 دقيقة
- 7التكلفة والزمن — فاتورتك بتتحسب إزاي7 دقيقة
اختيار الموديل — الأكبر مش دايمًا الأحسن
في سطر واحد · اختيار الموديل مقايضة بين الذكاء والتكلفة والسرعة — والموديل الصح هو أرخص واحد بيعدّي مهمّتك.
استخدام أقوى موديل لكل حاجة بيحرق فلوسك ويبطّئ منتجك من غير فايدة حقيقية في مهام بسيطة.
زي اختيار عربية: مش هتاخد شاحنة عشان تجيب رغيف عيش. المهمة هي اللي بتحدّد الحجم، مش العكس.
زي التوظيف: مش هتجيب مهندس سينيور بمرتّب ضخم عشان يعمل ريسِت لباسورد. بتوظّف على قد المهمة، وبتطلّع فوق بس لما الشغل يستاهل.
تصنيف رسالة «شكوى/استفسار» موديل صغير رخيص بيعمله ممتاز؛ كتابة تقرير معقّد أو reasoning متعدّد الخطوات محتاج موديل أقوى. جرّب الأصغر الأول واطلع لفوق لو وقع.
كل مزوّد بيقدّم «سلّم» موديلات: صغير سريع رخيص → متوسط → كبير غالي، وأحيانًا reasoning models بتاخد وقت تفكير إضافي للمسائل الصعبة. الفرق العملي بينهم بيظهر في 4 محاور: جودة الـ reasoning المتعدد الخطوات، التكلفة لكل مليون token، زمن الاستجابة، وحجم الـ context window. المنهج السليم عكس الغريزة: ابدأ بالأرخص اللي ممكن يعدّي، وجهّز مجموعة اختبار صغيرة (evals) من أمثلة حقيقية لمهمّتك، وقيس. الموديل اللي بيعدّي اختباراتك بأقل تكلفة هو «الصح» — مش الأعلى في الـ benchmarks العامة. وفي المنتجات الناضجة بتلاقي routing: مهام بسيطة رايحة للصغير، والمعقّدة بس هي اللي بتتصعّد للكبير.
🧪 جرّب بنفسك — نفس المهمة على موديلين: اختار مهمة حقيقية من شغلك (مثلًا: تصنيف 20 رسالة عملاء لـ«شكوى/استفسار/طلب»). حضّر الـ 20 مثال بإجاباتهم الصح، وشغّلهم على أصغر موديل عند المزوّد وعلى أكبر واحد. احسب لكل موديل: نسبة الصح، متوسط زمن الرد، والتكلفة التقريبية لو المهمة دي بتتكرر مليون مرة في الشهر. المفاجأة المعتادة: في التصنيف البسيط الفرق في الجودة صفر تقريبًا، وفرق الفاتورة مهول.
- الاختيار بالـ benchmarks العامة بدل مهمّتك. موديل متفوّق في اختبارات الرياضيات ممكن يبقى عادي جدًا في تلخيص عربي لمجالك — مفيش بديل عن eval على بياناتك.
- البدء بالأغلى «للاحتياط» وعدم الرجوع. الفرق بين موديل صغير وكبير ممكن يوصل 20–60 ضعف في السعر — على مليون طلب شهريًا دي فاتورة بتبني أو تكسر المنتج.
- نسيان الـ latency. موديل أقوى بيبقى أبطأ غالبًا؛ في تجربة تفاعلية، ثانيتين إضافيتين ممكن يبقوا أسوأ من إجابة أقل لمعانًا.
اعمل خطوة اختيار واعية (بـ eval صغير) في أي feature هيتنده فيها الموديل بحجم كبير أو بشكل متكرّر: التوفير بيتضاعف مع الحجم. وارجع للقرار كل كام شهر — السوق بيتحرّك بسرعة، وموديل النهارده الصغير بيعمل شغل الكبير بتاع السنة اللي فاتت.
متضيّعش أسبوع تحسين اختيار الموديل لـ feature بتتنده 100 مرة في اليوم — فرق التكلفة هناك مليمات، وأي موديل متوسط هيكفي. وفي مرحلة الـ prototype، ابدأ بموديل قوي عشان تثبت إن الفكرة أصلًا شغّالة، وبعدين نزّل السلّم — التحسين المبكر هنا بيخلط «الفكرة مش نافعة» بـ«الموديل ضعيف».