إيفان نيكتين، الرئيس التنفيذي والشريك المؤسس لـ Fortytwo – سلسلة مقابلات

إيفان نيكتين هو الرئيس التنفيذي والشريك المؤسس لـ Fortytwo، حيث يطوّر تقنية للاستدلال بالسرب تجمع عدة نماذج للذكاء الاصطناعي كي تستدل وتقيّم عمل بعضها بعضًا. وتشمل خبرته الألعاب والذكاء الاصطناعي الحواري والذكاء الاصطناعي التوليدي والأنظمة التفاعلية في Temporal وSensorium. شارك في تأسيس Temporal عام 2011 مع فلاد لارين، الذي يشغل الآن منصب الشريك المؤسس والمدير التقني في Fortytwo، واكتسب خبرة في تطوير مجموعات متغيرة من الوكلاء والأنظمة التي تجمع نماذج متخصصة.

تطوّر Fortytwo بنية تحتية للذكاء الاصطناعي تتيح للنماذج التعاون أثناء الاستدلال. ويستخدم Fortytwo Engine وحدة Swarm Decoder لتوجيه عملية استدلال مشتركة أثناء سيرها، بهدف تحسين الدقة وتقليل توليد الرموز غير الضرورية في المهام الطويلة. وتوفر الشركة واجهة برمجة تطبيقات للمطورين من خلال Fortytwo Engine، وخيار النشر محليًا من خلال Fortytwo Harbor.

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

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

مع ظهور نماذج المحوّلات، توسعنا إلى مجال الذكاء الاصطناعي الحواري، وطوّرنا منصة لشخصيات تعمل بالذكاء الاصطناعي وتستطيع خوض محادثات مفتوحة وغير معدّة مسبقًا، مع ذاكرة وسمات شخصية. حدث ذلك قبل ChatGPT ببضع سنوات، وكانت نوافذ السياق في النماذج التي عملنا عليها لا تتجاوز 512 إلى 1,024 رمزًا. ولم يكن من الوارد أن نتوقع من نموذج لغوي واحد في تلك المرحلة المبكرة تلبية كل متطلبات هذه التجربة المختلفة على نحو موثوق. لذلك اضطررنا إلى بناء مسار عمل مخصص يضم نماذج متخصصة، لكل منها مسؤولية أضيق، إلى جانب آلية لدمج إسهاماتها. وأصبح ترتيب الإجابات واختيارها ضروريين لإنجاح التجربة برمتها. وقد علّمنا ذلك أن الجمع بين نماذج محدودة القدرات ضمن نظام محكم التصميم يمكن أن يتيح قدرات كبيرة.

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

يستخدم Fortytwo Engine عدة نماذج مفتوحة الأوزان لتوجيه عملية استدلال واحدة، وللتحقق بعضها من بعض أثناء توليد الإجابة. كيف يختلف هذا النهج عن أنظمة الوكلاء المتعددين التقليدية، أو تجميع النماذج، أو مجرد تشغيل عدة نماذج ثم اختيار أفضل إجابة بعد ذلك؟

يكمن الفارق الأساسي في أن الاستدلال بالسرب مدمج مباشرة في محرك الاستدلال الذي طورناه. ونطلق عليه اسم Swarm Decoder: إذ يوجّه عدة مشاركين من النماذج باستمرار مسار استدلال واحدًا أثناء توليده. ويجري التقييم والتوجيه ضمن هذه العملية، ما يسمح للنماذج بالتأثير في مسارها قبل اكتمال الإجابة.

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

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

أشرتَ إلى انحراف النماذج أثناء المهام طويلة الأمد بوصفه مشكلة رئيسية. ما الذي يسبب هذا الانحراف فعليًا، وكيف يظهر في التطبيقات العملية مثل هندسة البرمجيات والبحث أو وكلاء الذكاء الاصطناعي المستقلين؟

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

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

يمكننا قياس ذلك بالأرقام. شغّلنا Qwen 3.8 27B على 450 مهمة من DeepSWE، وهي مهام حقيقية في هندسة البرمجيات تستخدم الأدوات ضمن سياقات طويلة، مرةً بمفرده ومرةً عبر Fortytwo Engine. عند تشغيله بمفرده، بلغ متوسط استهلاك النموذج 16.3 مليون رمز لكل تشغيل، بإجمالي 7.4 مليار. أما عبر Engine، فبلغ متوسط استهلاك النموذج نفسه 12.3 مليون رمز لكل تشغيل، بإجمالي 5.6 مليار، أي أقل بنسبة 24.7%، كما حلّ عددًا أكبر من المهام: 47.8% مقابل 42.2%. لم يتغير شيء في النموذج. والرموز الأربعة ملايين لكل تشغيل التي لم تعد تُستهلك كانت ناتجة عن الانحراف: إعادة القراءة والمحاولات المتكررة والعودة إلى خطوات سابقة، وهي أمور يضطر النموذج الواحد إلى القيام بها لأن لا أحد يرصد انحرافاته أثناء وقوعها. أما السرب فيرصدها، فلا يضطر أبدًا إلى تحمل كلفتها.

كان Fortytwo يتيح سابقًا للنماذج تقييم إجابات بعضها بعضًا بعد إتمامها، بينما تسمح البنية الحالية لها بالتأثير في عملية الاستدلال أثناء توليدها. ما الذي تعلمتموه من النهج السابق، ولماذا يكون التوجيه الفوري أكثر فاعلية؟

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

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

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

في اختباراتكم باستخدام Qwen 3.8 27B، أفاد Fortytwo باستهلاك رموز أقل بنسبة 24.7% عبر 450 تشغيلًا لمهام DeepSWE، مع تحسين النتائج في ستة اختبارات معيارية. ما الذي يحدث داخل السرب ويتيح له تحسين الأداء وخفض استهلاك الرموز في الوقت نفسه؟

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

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

يتزايد قلق مطوري الذكاء الاصطناعي بشأن تكاليف الاستدلال، مع إنشاء نماذج الاستدلال سلاسل أطول من الرموز. هل تعتقد أن تحسين كفاءة عملية الاستدلال نفسها قد يصبح في نهاية المطاف بأهمية جعل النماذج الفردية أصغر أو أسرع أو أقل تكلفة؟

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

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

يتوافق Fortytwo Engine مع OpenAI API، مع تشغيله نماذج مفتوحة الأوزان. ما مدى أهمية التوافق مع حزم تطوير الذكاء الاصطناعي الحالية، وما مدى سهولة نقل المطورين تطبيقًا من واجهة برمجة تقليدية تعتمد على نموذج واحد إلى بنية سرب؟

التوافق أساسي. فمنظومة الوكلاء، بما فيها وكلاء البرمجة وبيئات تشغيلهم وأطر العمل وأدوات التقييم، مبنية على بنية OpenAI API. لذلك، لا يتطلب الانتقال بالنسبة إلى المطورين الذين يستخدمون Fortytwo Engine سوى ما يشبه الانتقال من مزود استدلال إلى آخر: ففي التطبيقات أو الوكلاء أو بيئات التشغيل أو الخدمات المتوافقة، يكفي عادةً تغيير الإعدادات مرة واحدة: عنوان نقطة النهاية ومفتاح API واختيار النموذج.

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

شكرًا على هذه المقابلة الرائعة. على القراء الراغبين في استكشاف الاستدلال بالسرب وكيف يمكن لتقييم الأقران أن يحسن كفاءة الاستدلال زيارة Fortytwo.