Flag Soft: اختبار «تحدّي دالي» ساعد في اختيار نموذج LLM من حيث الجودة والسرعة والتكلفة

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

نشأت الفكرة من مهمة هندسية يومية بسيطة. فحين يحتاج المرء إلى اختيار نموذج لمشروعه الخاص، يتحول السؤال المجرد «ما أفضل نموذج LLM؟» سريعًا إلى مجموعة من القيود التطبيقية. فأحد النماذج يكتب بإقناع لكنه يجيب ببطء شديد. وآخر يلتزم بالميزانية لكنه يفقد الخيط في التعليمات الطويلة. وثالث يجتاز الاختبارات بثبات، غير أن سعره النهائي يجعله غير صالح لمنتج واسع الانتشار. وفي هذه النقطة بالتحديد وُلد الاختبار محلي الصنع، الذي تبيّن لاحقًا أنه مفيد لا للتجربة الشخصية فحسب، بل لقرارات المنتجات في شركة Flag Soft أيضًا.

يقوم «تحدّي دالي» على منطق بسيط لكنه سليم. فإذا كان النموذج سيُدمج في منتج، فلا ينبغي تقييمه بانطباع عابر من محادثة واحدة، بل بمجموعة مهام موحّدة. والجودة في هذا النهج لا تعني «أعجبتني الإجابة أم لا»، بل قدرة النموذج على الحفاظ على المعنى، واتباع التعليمات، وعدم إغفال التفاصيل، وتقديم نتيجة يمكن استخدامها دون تعديل يدوي طويل. أما السرعة فلا تقل أهمية: ففي الأداة الداخلية يمكن تحمّل بضع ثوانٍ إضافية، لكن في الخدمة الموجّهة للمستخدمين يضرّ كل تأخير بمعدل الاحتفاظ بالمستخدمين وبالتحويل. والتكلفة هي المعيار الثالث الذي لا غنى عنه، لأن النموذج القوي قد يغدو باهظ الثمن عند التوسع إلى آلاف الطلبات.

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

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

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

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