نموذج جديد يدخل سباق البرمجة الوكيلة
كشفت شركة Cohere عن نموذجها الجديد North Mini Code بوصفه بديلاً مفتوح المصدر مخصصاً للبرمجة الوكيلة، في خطوة تستهدف فرق الهندسة التي تبني خطوط عمل تعتمد على وكلاء ذكاء اصطناعي داخل بيئات التطوير. ويأتي الإطلاق في وقت تتزايد فيه المنافسة بين النماذج التجارية والمفتوحة، خاصة مع ارتفاع الاهتمام بالتشغيل المحلي وتقليل الاعتماد على الخدمات المُدارة.
يمثل النموذج محاولة لتقديم خيار عملي يجمع بين الكفاءة والقدرة على العمل داخل البنية التحتية الداخلية للشركات. وبحسب البيانات المعلنة، يمكن تشغيله على بطاقة رسوميات واحدة من فئة H100، وهو ما يجعله مناسباً للفرق التي تريد الحفاظ على التحكم في البيانات والتكلفة معاً.
لكن هذا المسار لا يخلو من المقايضة. فالنموذج، رغم كونه أقل كلفة من حلول سحابية كثيرة، يولد عدداً كبيراً من الرموز النصية أثناء العمل، ما قد يرفع استهلاك الموارد في بيئات الإنتاج التي تعتمد على تشغيل كثيف ومستمر.
بنية MoE وسياق طويل للمهام المعقدة
North Mini Code هو نموذج مزيج خبراء sparse mixture-of-experts يضم 30 مليار معلمة إجمالاً، مع تفعيل 3 مليارات معلمة فقط لكل رمز يتم توليده. وتمنح هذه البنية النموذج قدرة على الموازنة بين الحجم الكلي والكلفة الفعلية أثناء الاستدلال، إذ يقترب في متطلبات التشغيل من نموذج أصغر بكثير من حيث العبء الحسابي.
ويعتمد النموذج على نافذة سياق تصل إلى 256 ألف رمز، إلى جانب حد توليد أقصى يبلغ 64 ألف رمز. هذه الأرقام مهمة في سياق البرمجة الوكيلة، لأنها تسمح للنموذج بالاحتفاظ بكم كبير من ملفات المشروع والملاحظات وسجل التفاعلات ضمن جلسة واحدة، وهو عنصر حاسم عند تحليل قواعد كود كبيرة أو مراجعة تغييرات متشعبة.
كما يتوافر النموذج عبر منصة Hugging Face تحت ترخيص Apache 2.0، ما يسهّل على المؤسسات والباحثين تنزيله وتجربته ودمجه ضمن أنظمتهم الخاصة دون الارتباط بنموذج مغلق أو عقود استخدام تقليدية.
مصمم للبرمجة الوكيلة لا للكتابة العامة
تقول Cohere إن North Mini Code لم يُشتق من نموذج عام ثم جرى تخصيصه لاحقاً، بل جرى بناؤه من الأساس ليؤدي مهام هندسة برمجية وكيلية. ويشمل ذلك تنسيق عمل وكلاء فرعيين، ورسم خرائط معمارية للأنظمة، ومراجعة الشيفرة، والتعامل مع أوامر الطرفية وأدوات سطر الأوامر.
ومن بين القدرات التي تبرزها الشركة أيضاً الدعم للتفكير المتداخل واستخدام الأدوات بشكل مدمج، وهي خصائص يُفترض أن تحسن الأداء في المهام متعددة الخطوات التي تحتاج إلى تحليل، ثم قرار، ثم تنفيذ، ثم مراجعة. وفي هذا النوع من المهام، لا يكون الاختبار مقتصراً على إنتاج شيفرة صحيحة فحسب، بل يشمل أيضاً كيفية التنقل بين الأدوات والملفات والأوامر بمرونة.
وتشير Cohere إلى أن النموذج تم تقييمه كذلك في بيئات طرفية حقيقية، بدلاً من الاعتماد فقط على اختبارات توليد كود اصطناعية. هذه النقطة تعكس تحولاً ملحوظاً في سوق أدوات البرمجة بالذكاء الاصطناعي، إذ باتت القدرة على العمل داخل سطر الأوامر وإدارة خطوات متعددة معياراً أكثر أهمية من مجرد كتابة مقاطع برمجية منفصلة.
طريقة التدريب وسبب الاهتمام بالأداء المحلي
أوضحت الشركة أن تدريب North Mini Code مرّ بمرحلتين من الضبط الخاضع للإشراف، أعقبهما تعلم معزز قائم على مكافآت قابلة للتحقق، عبر أكثر من 70 ألف مهمة يمكن التحقق من نتائجها، موزعة على نحو 5 آلاف مستودع برمجي، مع إزالة التكرارات مقارنةً بمقياس SWE-Bench.
كما أنها لم تكتفِ بإطار تقييم واحد، بل دربت النموذج عبر ثلاثة أطر مختلفة للمهام الوكيلة. ويشمل ذلك SWE-Agent الذي يستخدم واجهة سطر أوامر غنية بالأوامر، وMini-SWE-Agent الذي يعتمد أداة bash واحدة مع مخرجات خام، وOpenCode الذي يتعامل مع أدوات منفصلة تُرجع بيانات JSON منظمة. ووفق الشركة، أدت هذه المقاربة إلى تحسن في الأداء على OpenCode من دون التضحية بأداء SWE-Agent.
هذا الأسلوب يعكس توجهاً أوسع في سوق الذكاء الاصطناعي: لم يعد الحكم على النموذج مرتبطاً فقط بدقة الإجابات، بل أيضاً بقدرته على العمل داخل منصات وأطر مختلفة في العالم الحقيقي. بالنسبة لفرق الهندسة، يعني ذلك أن الاختيار بين النماذج لم يعد تقنياً بحتاً، بل أصبح مرتبطاً أيضاً بسلاسة الدمج مع الأدوات والبنية القائمة.
التكلفة والسرعة وحدودهما في بيئات الإنتاج
يدخل North Mini Code سوقاً مزدحماً يضم نماذج وأدوات مثل Mistral Devstral Small 2، وGitHub Copilot، وCursor، وClaude Code، إلى جانب نموذج Anthropic المعروف تجارياً في البرمجة. وفي هذا المشهد، تبرز مفاضلة واضحة بين الحلول السحابية المُدارة والحلول المحلية المفتوحة المصدر.
وتقول Cohere إن نموذجها حقق في اختبارات داخلية سرعة أعلى في إنتاج المخرجات مقارنةً بـ Devstral Small 2، مع زمن أقل بين الرموز في ظروف تشغيل متطابقة على العتاد نفسه. كما تشير إلى أن النموذج يتفوق على بعض النماذج المفتوحة التي تفوقه حجماً بعدة أضعاف في بعض المقاييس المنشورة.
غير أن بيانات من جهة مستقلة أظهرت جانباً آخر: النموذج حلّ في مرتبة متقدمة من حيث سرعة الإخراج، وسجل زمناً سريعاً جداً لأول رمز، لكنه في الوقت نفسه أنتج كمية كبيرة من الرموز للوصول إلى نتيجته النهائية في أحد التقييمات. وفي بيئات الإنتاج عالية الحجم، قد تتحول هذه الثرثرة النصية إلى كلفة إضافية ملموسة في الزمن والحوسبة.
لهذا السبب، لا يكفي تقييم النماذج البرمجية عبر الدقة أو ترتيب الأداء وحدهما. فالمؤسسات التي تبني خطوط عمل وكيلية تحتاج أيضاً إلى حساب إجمالي الرموز المستهلكة، وزمن الاستجابة، ومتطلبات العتاد، ومدى ملاءمة التشغيل المحلي لسياساتها الأمنية والتنظيمية.
ماذا يعني ذلك للمؤسسات التقنية
يرسل إطلاق North Mini Code رسالة واضحة إلى الشركات التي تستثمر في وكلاء البرمجة: النماذج المصممة خصيصاً للمهام الوكيلة أصبحت جزءاً أساسياً من المنافسة، ولم يعد كافياً الاعتماد على نموذج عام جرى تعديله لاحقاً. كما أن مسألة التحقق من المسارات والأدوات المستخدمة في التدريب باتت مؤشراً مهماً على نضج النموذج.
إلى جانب ذلك، يبرز عامل خفي غالباً ما تغفله المقارنات التسويقية، وهو عدد الرموز التي ينتجها النموذج لتحقيق نفس المهمة. فإذا كان النموذج ينجز المهمة بكفاءة عالية لكنه يستهلك مخرجات أكثر بكثير، فإن الفارق في الكلفة قد يتسع سريعاً عند الانتقال من التجربة إلى الاستخدام الواسع.
أما النقطة الثالثة فهي أن الاختيار بين نموذج محلي مفتوح المصدر ونموذج مُدار عبر السحابة لم يعد قراراً تقنياً فحسب، بل قراراً معمارياً يتعلق بالسيادة على البيانات، والتسعير، ومرونة النشر، ومتطلبات الامتثال. وفي هذا السياق، يقدم North Mini Code مثالاً على الاتجاه الذي تتجه إليه السوق: نماذج أصغر نسبياً، قابلة للتشغيل محلياً، ومصممة لمهام الوكلاء المتقدمة بدلاً من الاكتفاء بكتابة الشيفرة بشكل عام.