إن إجراء اختبارات القياس (Benchmarking) لنموذج ما على لوحات الصدارة العامة يخبرك بمدى براعته في التعامل مع المعلومات العامة والاختبارات المعيارية. لكنه لا يخبرك تقريبًا بأي شيء عن كيفية استنتاجه المنطقي للمشكلات المعقدة والمقيدة التي تواجهها أنظمة الإنتاج الخاصة بك فعليًا. قبل إطلاق أي نموذج لغوي كبير للمستخدمين، فأنت بحاجة إلى إطار اختبار (harness) يضع الأنماط المعرفية المحددة التي يتطلبها تطبيقك تحت الضغط. اختبارات القياس الخاصة بالاستنتاج المنطقي (Reasoning benchmarks) هي المكان الذي تميز فيه النماذج نفسها عن برامج الدردشة الآلية (chatbots).

يقدم هذا الدليل خطوات بناء اختبار قياس استنتاجي مركز من الصفر. ستتمكن من مقارنة ثلاث بنيات مختلفة: DeepSeek R1 671B MoE، وLlama 3.3 70B، وQwen 3 32B. وبدلاً من تجميع مجموعات من وحدات معالجة الرسومات (GPU clusters)، ستشغل النماذج الثلاثة عبر Oxlo.ai. وللتقييم، ستستخدم Kimi K2.6 كحكم لتقييم المخرجات بناءً على وضوح الاستنتاج، والصحة، وجودة الكود.

لماذا يفشل الاستنتاج المنطقي أولاً

نادرًا ما تظهر إخفاقات الإنتاج في شكل أخطاء نحوية أو رفض للإجابة. بل تظهر في شكل أخطاء منطقية دقيقة. قد يولد النموذج نصًا واثقًا بينما يسيء فهم قيد معين، أو يتخطى خطوة، أو يغير متغيرًا بصمت في منتصف العملية. غالبًا ما تعطي اختبارات القياس العامة الأولوية للشمول على حساب العمق، لذا يمكن للنموذج أن يحصل على درجة جيدة دون أن يحل أي مشكلة توافقية (combinatorial problem) صعبة.

إن اختبار القياس المستهدف يضع الأمر في نصابه. فهو يمنح كل نموذج نفس مهمة التحسين المقيدة، ويتطلب سلسلة تفكير (chain of thought) قابلة للتتبع، ويقيس ما إذا كان الحل المولد يلبي القواعد فعليًا. إذا لم يتمكن النموذج من الاستنتاج باستمرار عبر الرياضيات المتقطعة (discrete math)، فلن يتمكن أيضًا من التعامل بشكل موثوق مع تخصيص المخزون، أو محرك الجدولة، أو موجه الموارد الخاص بك.

النماذج والمنصة

يستخدم DeepSeek R1 671B MoE تصميم "خليط من الخبراء" (mixture-of-experts). يتم تفعيل جزء بسيط فقط من معلماته البالغ عددها 671 مليار لكل رمز (token) معين، مما يغير منحنى التكلفة مقابل الأداء، وأحيانًا يغير طبيعة استنتاجه. أما Llama 3.3 70B فهو نموذج كثيف (dense model)، بينما يأتي Qwen 3 32B بمقياس أصغر مع قدرات قوية في البرمجة وتعدد اللغات. مقارنة هذه النماذج الثلاثة ستخبرك ما إذا كانت جودة الاستنتاج تتبع إجمالي عدد المعلمات، أو عدد المعلمات النشطة، أو منهجية التدريب.

تستضيف Oxlo.ai هذه النماذج خلف واجهة برمجة تطبيقات (API) موحدة. لن تضطر إلى إدارة البنية التحتية للاستدلال (inference infrastructure) أو الصراع مع اتفاقيات مزودين منفصلين. تستخدم المنصة أيضًا تسعيرًا لكل طلب بدلاً من التسعير لكل رمز (per-token). فمطالبة النظام (system prompt) المكونة من ألفي كلمة تكلف تمامًا مثل مطالبة موجزة من سطر واحد. هذا التفصيل أهم مما يبدو؛ فهو يعني أنه يمكنك كتابة تعليمات شاملة، وتضمين متطلبات تنسيق مفصلة، وإدراج أمثلة قليلة (few-shot examples) دون مراقبة تضخم تكاليف رموز الإدخال. أنت تدفع مقابل الاستدعاء، وليس مقابل الإطناب.

ستحتاج إلى Python 3.10 أو أحدث، ومكتبة OpenAI Python، ومفتاح API من Oxlo.ai.

الخطوة 1: الاتصال بنقطة النهاية (Endpoint)

نظرًا لأن Oxlo.ai توفر واجهة برمجة تطبيقات متوافقة مع OpenAI، فإن التكامل عملية مباشرة. قم بتوجيه OpenAI SDK إلى عنوان URL الأساسي لـ Oxlo، وأدخل مفتاح API الخاص بك، وتحقق من الاتصال بطلب خفيف الوزن إلى DeepSeek R1. لا تتجاهل اختبار السلامة (sanity check). تأكد من زمن الاستجابة (latency)، وتأكد من التعرف على معرف النموذج، وتأكد من أن بيئتك يمكنها بث (stream) أو تخزين تنسيق الاستجابة الذي تنوي حفظه. بمجرد نجاح عملية المصافحة (handshake)، سيكون لديك عميل واحد يمكنه مخاطبة النماذج الثلاثة عن طريق تغيير سلسلة نصية واحدة فقط.

الخطوة 2: تصميم المهمة

اختر مشكلة تتطلب منطقًا خطوة بخطوة ولها إجابة قابلة للقياس بشكل موضوعي. تعمل مشكلة "تعبئة الصناديق" (Bin-packing) بشكل استثنائي جيد. فهي من فئة المسائل الصعبة (NP-hard)، مما يعني أن الاستدلالات الجشعة (greedy heuristics) تفشل بطرق يمكن التنبؤ بها، وهي تجبر النموذج على تتبع قيود متعددة في وقت واحد. يجب أن تتناسب العناصر ذات الأحجام المختلفة داخل صناديق ذات سعة ثابتة دون تجاوز الحدود.

صغ المطالبة (prompt) بحيث يتعين على النموذج القيام بأمرين: وصف عملية الاستنتاج الخاصة به، ثم تقديم كود Python يعمل ويحل الحالة المعطاة. استخدم مطالبة نظام (system prompt) تطلب من النموذج صراحةً إظهار سلسلة تفكيره (chain-of-thought) قبل كتابة أي كود. هذا مهم بشكل خاص لنموذج DeepSeek R1، المحسن لآثار الاستنتاج الطويلة. أنت تريد أن ترى ما إذا كان النموذج يفكر من خلال فحوصات السعة أم أنه مجرد مطابقة للأنماط بناءً على بيانات التدريب. المهمة الجيدة هي التي تكون "عدائية" (adversarial) بما يكفي لتفشل معها الاستجابات النمطية.

الخطوة 3: تشغيل اختبار القياس

قم بتغذية نفس الأمر (prompt) لكل من DeepSeek R1 و Llama 3.3 70B و Qwen 3 32B. التقط استجابات النص الكاملة، وليس فقط كتل الكود النهائية. قم بتخزينها مع الطوابع الزمنية ومعرفات النماذج. بما أن Oxlo.ai تفرض رسومًا لكل طلب، فلست بحاجة إلى اختصار أمرك أو حذف التعليمات التوضيحية لتوفير المال. يمكنك تحمل الدقة. يتيح لك هذا الاستقرار تكرار تصميم الأوامر دون قلق بشأن التكلفة، مما يؤدي إلى تجارب أكثر نظافة ونتائج أكثر قابلية للتكرار.

قم بتشغيل كل نموذج عدة مرات إذا كانت ميزانيتك تسمح بذلك. يمكن أن تختلف نماذج الاستنتاج عبر التوليدات العشوائية (stochastic generations)، وأنت تريد أن تعرف ما إذا كانت الدرجة العالية تمثل كفاءة ثابتة أم مجرد عينة محظوظة.

الخطوة 4: التقييم باستخدام حكم LLM

التقييم اليدوي لا يمكن توسيعه، لكن القواعد الرقمية وحدها تفتقر إلى الدقة. الحل الوسط هو استخدام حكم LLM. هنا، ستستخدم Kimi K2.6. قم بتزويده بالمشكلة الأصلية، والقاعدة (rubric)، وكل استجابة مرشحة. اطلب منه تقييم ثلاثة أبعاد محددة:

  • وضوح الاستنتاج: هل يشرح المنطق فعليًا، أم يكتفي بالحديث العام دون تفصيل؟
  • الصحة: هل يلبي الحل المقترح جميع القيود المذكورة؟
  • جودة الكود: هل لغة Python نظيفة، وقابلة للتشغيل، وخالية من الأخطاء الواضحة؟

وجه الحكم لإرجاع الدرجات بتنسيق JSON. المخرجات المهيكلة تجعل من السهل جدًا مقارنة النتائج، ورسم الاتجاهات، وتغذية عمليات الأتمتة اللاحقة. حافظ على صرامة أمر الحكم. إذا أعطيته تعليمات غامضة مثل "قيم الإجابة"، فستحصل على نتائج غامضة. بدلاً من ذلك، حدد ما الذي يعتبر حلاً صحيحًا لمسألة تعبئة الصناديق (bin-packing). يجب عدم تجاوز السعات. يجب تعيين كل عنصر. يجب أن يكون الكود صالحًا من الناحية النحوية. كلما كانت معاييرك أكثر ملموسة، أصبحت درجاتك أكثر موثوقية.

قم دائمًا بفحص الحكم بشكل عشوائي. إذا كان Kimi K2.6 يبالغ باستمرار في تقييم نموذج واحد بسبب اللمسات السطحية، فإن معيارك (benchmark) معطل. طبقة تدقيق بشري صغيرة تمنع تقييم "المدخلات السيئة تؤدي لمخرجات سيئة" (garbage-in-garbage-out).

الخطوة 5: بناء التقرير

قم بتجميع درجات JSON وربطها بمقتطفات من مخرجات النماذج الخام. ضع كل شيء في ملف واحد موجود في مستودعك (repository). عندما تقوم بتحديث إصدار نموذج أو تعديل الأمر، سيوضح الفرق (diff) في طلب السحب (pull request) الخاص بك بالضبط كيف تغير السلوك. يصبح المعيار الذي تتم صيانته جيدًا بمثابة وثائق حية. فهو يبرر سبب استخدام خط الإنتاج الخاص بك لنموذج واحد دون غيره، ويكشف عن التراجعات الصامتة قبل أن تصل إلى المستخدمين.

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

أتمتة خط الأنابيب (Pipeline)

المعيار الذي يعيش فقط على جهاز الكمبيوتر المحمول الخاص بك سيُنسى في غضون أسبوع. انقله إلى وظيفة CI ليلية. كل ليلة، يتم تشغيل إطار العمل، واستعلام إصدارات النماذج الحالية على Oxlo.ai، وتشغيل مهمة تعبئة الصناديق، وتقييم المخرجات، وإرسال النتائج. إذا تسبب تحديث النموذج في انخفاض قدره عشر نقاط في الصحة، فستعرف ذلك قبل مستخدميك.

بمجرد استقرار إطار العمل الأساسي، قم بتوسيع نطاقه. اختبر متغيرات السياق الطويل (long-context) عن طريق حشو الأمر بوثائق غير ذات صلة، ثم وضع سؤال تعبئة الصناديق في النهاية. نوافذ السياق الكبيرة لا فائدة منها إذا انهار الاستنتاج تحت وطأة الضجيج. انظر أي النماذج تحافظ على الانضباط المنطقي عندما تكون الإشارة مدفونة وسط عشرة آلاف رمز (token) من التشتيت.

الخلاصة الحقيقية

تقيس لوحات الصدارة العامة المعرفة العامة. أما تطبيقك فيقيس شيئًا أضيق وأصعب. إن وجود إطار عمل بسيط وقابل للتكرار يجبر النماذج على الاستنتاج من خلال التحسين المقيد (constrained optimization)، ويقيمها بمعايير ثابتة، ويؤرشف النتائج في git، سيعطيك رؤية أكثر قابلية للتنفيذ من أي درجة إجمالية. ابنِ المعيار الذي يناسب مشكلتك، وقم بتشغيله عبر البنيات التي تهمك، واترك النتائج تملي عليك خيار الإنتاج.

المصدر: DeepSeek R1 Model Architecture and Benchmarks

المجتمع: GyaanSetu AI on Telegram