Groq عالجت خمس مراجعات في ثانيتين وOllama في 81 ثانية: ما الذي يخفيه الاختبار

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

نشر موقع Machine Learning Mastery مثالًا تعليميًا لهذه المقارنة. في تشغيل الكاتب عالج النموذج المحلي خمس مراجعات في 80,71 ثانية، بينما عالجها النموذج السحابي في 2,02 ثانية. الفارق يقارب أربعين ضعفًا. غير أن الاعتماد على هذه الأرقام لاختيار البنية التحتية لا يزال مبكرًا: فالتجربة تقارن بين نموذجين مختلفين، وظروف التشغيل المحلي غير موضحة بما يكفي.

كيف صُممت المقارنة

يبني الكاتب مصنّفين بالطريقتين fit() وpredict() المألوفتين لمستخدمي scikit-learn. الأول يستخدم Scikit-Ollama ونموذج Llama 3 محليًا. والثاني يعمل عبر Scikit-LLM ويرسل الطلبات إلى نموذج gpt-oss-20b من خلال واجهة Groq. يُمرَّر إلى كليهما الجمل الإنجليزية الخمس نفسها وفئتان متاحتان: إيجابية وسلبية.

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

في النتائج المعروضة صنّف النموذج المحلي أربع جمل من خمس بشكل صحيح، وصنّف النموذج السحابي الجمل الخمس كلها. أي دقة بلغت 80% و100%. ويشمل الزمن استدعاءَي fit() وpredict()، لذا تصف الثواني المذكورة كامل الدورة المقيسة، لا زمن استجابة طلب منفرد.

لماذا لا يوجد فائز بعد

المشكلة الرئيسية أن النموذج ومكان التنفيذ يتغيران معًا. لذلك لا تفصل التجربة أثر البنية التحتية عن الاختلافات بين Llama 3 وgpt-oss-20b. ودالة القياس المتطابقة تجعل الإجراء أكثر سهولة، لكنها وحدها لا تضمن قابلية المقارنة بين النظامين.

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

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

كما أن التكلفة لا تُقاس هنا أيضًا. فالدالة تطبع ببساطة السلسلة «$0» المُمرَّرة إليها. وفي التشغيل المحلي لا يراعي ذلك العتاد والكهرباء؛ وفي السحابي لا يوضح شروط الوصول المجاني وحدود الحمل. ويحتاج القول بخصوصية مطلقة إلى تحفظ كذلك: فالتشغيل في Google Colab، الذي تسمح به التعليمات، يجري أصلًا على بنية تحتية خارجية.

ما الذي يمكن أخذه إلى مشروعك

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

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

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