GitHub تضيف HydraFusion إلى قائمة نماذج Copilot، وهو موزِّع يختار بين ثلاثة مسارات وليس نموذجًا

أضافت GitHub في 30 سبتمبر 2026 خيارًا جديدًا اسمه HydraFusion إلى قائمة اختيار النماذج في Copilot، داخل VS Code وتطبيق Copilot. يظهر الخيار في القائمة كأي نموذج آخر، لكنه لا يجيب بنفسه، بل يوزع الطلب.

يقرأ HydraFusion الطلب ثم يقرر تنفيذه عبر واحد من ثلاثة مسارات:

• Single: نموذج واحد يحل المهمة.
• Cascade: نموذج أرخص يكتب مسودة، ثم تقرر بوابة جودة قبولها أو رفعها إلى نموذج أقوى.
• Critique: نموذج يكتب، ونموذج آخر من عائلة مختلفة يراجع المسودة دون أن يعدلها، ثم يعدّل النموذج الأول مرة واحدة.

والفكرة أن اختيار المسار يصبح مسألة optimization، أي موازنة بين الجودة والتكلفة تُحسب لكل طلب، لا تفضيلًا ثابتًا يحدده المستخدم.

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

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

ويبقى السؤال المفتوح لمن يبني مسار Cascade بنفسه هو الأساس الذي تُبنى عليه بوابة الجودة: هل هو ثقة النموذج في إجابته، أم اختبار يُشغَّل فعلًا على الكود؟