GitHub HydraFusion: توجيه المساعد الذكي متعدد النماذج 2026

مشروع HydraFusion هو معاينة بحثية لـ GitHub Copilot تقوم بتوجيه أمر برمجي واحد عبر نماذج متعددة أثناء التشغيل — سواء كان ذلك للصياغة، أو النقد، أو التصعيد حسب الحاجة. أعلنت GitHub عن ذلك في 1 سبتمبر 2026 ونشرت بيانات القياس الخاصة بها في 4 سبتمبر، حيث أفادت بخفض التكاليف في جميع الاختبارات الثلاثة التي أجرتها وتحقيق مكسب في الجودة في اختبار واحد.¹²

ملخص

وصفت GitHub التقرير بأنه "مشروع HydraFusion: جودة رائدة عبر تنسيق النماذج المتعددة."¹ والجدول الموجود تحت هذا العنوان أكثر إثارة للاهتمام من العنوان نفسه.

عبر Terminal-Bench 2.1 و DeepSWE واختبار داخلي يسمى CheckpointBench، خفض HydraFusion التكلفة التقديرية في كل مرة — بنسبة 67% و 36% و 65% مقارنة بـ Claude Opus 5 كمرجع أساسي. أما جودة المهام التي تم التحقق منها فقد ارتفعت في اختبار واحد (+4.9 نقطة) و انخفضت قليلاً في الاختبارين الآخرين (−1.5 و −0.1).¹

هذه نتيجة جيدة. إنها نتيجة تتعلق بالتكلفة، وليست نتيجة تتعلق بالقدرات، وأرقام GitHub نفسها تؤكد ذلك.

هناك ثلاث تفاصيل لم تذكرها التغطية الإعلامية: الاختبار الذي تفوق فيه HydraFusion كان قد تم استبداله مرتين بالفعل من قبل مطوريه قبل الإعلان؛ والجدول المنشور يوضح الفروقات بدلاً من الدرجات المطلقة؛ والموجه (router) له سجل توثيقي يعود من وضع Auto الحالي في Copilot وصولاً إلى ورقة بحثية من Microsoft.

ما ستتعلمه

• ما الذي قدمته GitHub فعلياً، والأوامر الثلاثة لتفعيله
• كيف تختلف أنماط Single و Cascade و Critique، وأيها يحقق توفير التكلفة
• ماذا يقول جدول القياس مقابل ما يقوله عنوان الإعلان
• لماذا كان الاختبار الذي تفوق فيه HydraFusion قد استُبدل مرتين من قبل مطوريه
• ورقة arXiv التي سُمي HydraFusion تيمناً بها، وسجل الإصدارات الذي نشرته GitHub للربط بينهما
• كيف يختلف هذا عن اختيار النموذج التلقائي (Auto) الحالي في Copilot — بكلمات GitHub نفسها
• لماذا تظهر أرقام LangChain و OpenRouter نفس الفجوة في الشكل
• ما الذي يجب التحقق منه قبل توجيه ميزانية الفريق نحو موجه (router)

ما الذي قدمته GitHub

أعلنت GitHub عن مشروع HydraFusion في منتدى مجتمع Copilot في 1 سبتمبر 2026، ثم نشرت التقرير الهندسي وجدول القياس في 4 سبتمبر.¹²

المشروع متاح في جميع خطط GitHub Copilot من خلال /experimental في GitHub Copilot CLI. هناك ثلاثة أوامر لتفعيله: /update لتثبيت أحدث إصدار من CLI، ثم /experimental on، ثم /model واختيار HydraFusion (Research Preview).¹

Copilot CLI هو الواجهة الوحيدة المتاحة. ملف سجل التغييرات الخاص بـ GitHub بتاريخ 10 سبتمبر يضع HydraFusion بدقة تحت Copilot CLI — "مشروع HydraFusion متاح الآن في /experimental" — ولا يذكر أي شيء عن العملاء الآخرين.³ ويذكر خيط الإعلانات أن تطبيق Copilot و VS Code "يستهدفان شهر سبتمبر كمتابعة سريعة"، ولكن لم يتوفر فيهما حتى 12 سبتمبر: حيث صدر VS Code 1.137 في 9 سبتمبر بدونه، والكلمة الرسمية الوحيدة منذ ذلك الحين كانت رداً في 10 سبتمبر في الخيط من موظف في Microsoft يجيب نيابة عن الفريق، يخبر مستخدماً يسأل عن VS Code Insiders "نعم، نحن نعمل على ذلك" — دون تحديد تاريخ.²³

نظام الفوترة بسيط في صياغته ومن السهل الاستهانة به. تقول الأسئلة الشائعة لـ GitHub: "لا توجد رسوم منفصلة لـ HydraFusion. أنت تدفع مقابل النماذج المكونة التي يقوم بتشغيلها، لذا فإن تكلفة الدورة الواحدة هي مجموع مراحلها."²

ملاحظة الفوترة هذه تستحق قراءة ثانية. الموجه (router) الذي يقوم بـ (مسودة-نقد-مراجعة) لمهمة ما يقوم بفوترة ثلاث مكالمات للنماذج، بينما تقوم جلسة النموذج الواحد بفوترة مكالمة واحدة. أرقام تكلفة GitHub هي صافي ذلك، ولكنها متوسطات عبر مجموعة اختبارات قياسية — وليست وعداً بشأن طلبك القادم. الفرق التي تتبع بالفعل الإنفاق بموجب نظام فوترة AI Credits الخاص بـ Copilot سترغب في رؤية تفصيلية لكل جلسة قبل تحويل فريق كامل إلى هذا النظام.

المعاينة محدودة عمداً. تقول GitHub إن مهام البرمجة ذات الدورة الأولى والطلب الواحد هي "أفضل مكان للبدء"، مع التركيز التالي على الأداء القوي في الدورات المتعددة.¹ إذا كان سير عملك عبارة عن جلسة تكرارية طويلة، فإن هذه المعاينة ليست موجهة إليك بعد.

أنماط التنفيذ الثلاثة

يتعامل HydraFusion مع اختيار سير العمل كمسألة تحسين، حيث يقوم بتقييم كل طلب بناءً على إشارات القدرة على الاستنتاج، وتوليد الكود، وتصحيح الأخطاء، واستخدام الأدوات، ثم يختار سير العمل الأقل تعقيداً والمتوقع أن يتجاوز معيار الجودة.¹

هناك ثلاثة أنماط:

جدول: أنماط التنفيذ الثلاثة لـ HydraFusion. المصدر: GitHub، 4 سبتمبر 2026.¹

نمط Cascade هو المكان الذي تكمن فيه قصة التكلفة، والتوفير يأتي من كيفية تقسيم حركة البيانات بدلاً من تحسن أي نموذج. النموذج الرخيص يعمل في كل طلب Cascade؛ أما النموذج المكلف فيعمل فقط عندما ترفض البوابة المسودة. وقد أبرزت VentureBeat نفس القراءة، مقتبسة تحليل مطور للنتائج المنشورة: "أنت تدفع للنموذج الرخيص في كل طلب cascade."⁴

النقد ليس أمراً جديداً على Copilot. فهو يتبع نفس نمط المراجعة الخاص بـ Rubber Duck، وهو وكيل النقد المدمج في CLI، والمتاح بشكل عام منذ 2 يونيو 2026. تصف وثائق GitHub هذا الأمر بأنه "ميزة تصميم أساسية" حيث أن Rubber Duck "يعمل عمداً على نموذج AI مختلف عن النموذج الذي يدير جلستك"، وبذلك يكون الناقد "أقل عرضة لمشاركة نفس النقاط العمياء، أو الانحيازات، أو أنماط الفشل الخاصة بالنموذج الذي أنتج العمل".⁵

وتحيط بهذه الأنماط خمسة مبادئ تشغيلية حددتها GitHub: محاسبة كاملة للتكاليف عبر كل مرحلة، تنفيذ محدود بمهل زمنية صريحة، مراجعة معزولة لا يمكنها الوصول إلى المستودع (repository)، تطبيق آمن من الفشل لا يطبق أي تصحيح (patch) عندما يفشل سير العمل في التحقق، وتوجيه مُتحقق منه يؤكد ربط النماذج وتوفرها قبل بدء التنفيذ.¹

قاعدة الأمان من الفشل هي الأهم بالنسبة لنظافة المستودع. لأن تطبيق تصحيح جزئي متعدد النماذج سيكون أسوأ من عدم تطبيق أي تصحيح على الإطلاق.

هناك مقايضة في سهولة الاستخدام تم الكشف عنها بصراحة. يعرض HydraFusion مراحل سير العمل ولكنه يحتفظ بالمسودات الوسيطة حتى يعيد نتيجة واحدة متماسكة، لأن تلك المسودات قد يتم تنقيحها أو التخلص منها. وبحسب صياغة GitHub: "الانتظار دون رؤية كافية هو مقايضة حقيقية للمطورين".¹

ما يقوله جدول القياس المرجعي في الواقع

قامت GitHub بتقييم سياسات HydraFusion الثابتة عبر ثلاثة اختبارات قياسية للبرمجة الوكيلية، باستخدام Claude Opus 5 و GPT-5.6 Sol كخطوط أساس للمقارنة، مع ضبط جميع النماذج على نفس مستوى الاستدلال المتوسط.¹

شملت محاسبة التكاليف كل مرحلة تم استدعاؤها — المسودة، النقد، التنقيح، التصعيد، إعادة المحاولة، والبديل. وتعني "جودة المهام المتحقق منها" نسبة المهام التي تم تأكيد الإجابة عليها بشكل صحيح.¹

الجدول: جودة وتكلفة HydraFusion عبر ثلاثة اختبارات وكيلية، بالنسبة لـ Opus 5. المصدر: GitHub، 4 سبتمبر 2026.¹

إذا قرأت العمودين بشكل منفصل، ستكون الصورة واضحة. انخفضت التكلفة في ثلاث حالات من أصل ثلاث. وارتفعت الجودة في حالة واحدة من أصل ثلاث. تلخص GitHub الصفوف الثلاثة معاً بأنها "طابقت أو تجاوزت خط الأساس لـ Opus 5 الذي تم تقييمه"، وهي قراءة منصفة لفجوة 0.1 نقطة في CheckpointBench وقراءة متساهلة لفجوة 1.5 نقطة في DeepSWE.¹

أما VentureBeat فقد حسبت الأمر بدقة أكبر، ووضعت ذلك في عنوانها الرئيسي: خفض في التكاليف في كل اختبار مرجعي، وتطابق في الجودة في اختبار واحد.⁴

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

يعتبر CheckpointBench متكافئاً فعلياً. فجوة قدرها 0.1 نقطة مع تكلفة أقل بنسبة 65% هي نتيجة قوية، وCheckpointBench هو الاختبار الأقرب للاستخدام الحقيقي: مجموعة اختبار داخلية متعددة الأدوار تم تنسيقها من جلسات Copilot حقيقية، كل منها مرتبط بمستودع عام وcommit غير قابل للتغيير بحيث يتم إعادة تشغيل العمليات بشكل متطابق. يذكر GitHub أنه "يعكس بدقة جلسات الوكلاء في بيئة الإنتاج".¹

يعد DeepSWE الأكثر تطلباً من بين الاختبارات المرجعية العامة، والفجوة هناك حقيقية. صياغة GitHub نفسها هي أن DeepSWE يساهم بـ "مهام أكثر تطلباً على مستوى المستودع" في التقييم.¹ أصدرته Datacurve في 26 مايو 2026: 113 مهمة أصلية طويلة المدى عبر 91 مستودعاً في TypeScript و Go و Python و JavaScript و Rust، مع كتابة كل حل مرجعي من الصفر بدلاً من نسخه أو تكييفه من pull request أو commit أو patch عام موجود.⁶ خسارة 1.5 نقطة هناك مع خفض التكلفة بنسبة 36% هي مقايضة مبررة، وليست تعادلاً.

الجدول نسبي وليس مطلقاً. كل رقم منشور يتم التعبير عنه مقابل خط الأساس Opus 5. يذكر GitHub نموذج GPT-5.6 Sol كخط أساس ثانٍ للمقارنة، لكن الجدول يذكر النتائج فقط مقابل Opus 5.¹ يمكنك محاولة استنتاج قيمة مطلقة — حيث تدرج لوحة المتصدرين v1.1 لـ DeepSWE نموذج Claude Opus 5 بنسبة 74% ±4%، مما يضع HydraFusion بالقرب من 72.5% — لكن هذه الحسابات لا تصمد أمام التفاصيل. يحافظ DeepSWE على ثبات بيئة التشغيل (harness)، حيث يقوم بتشغيل كل نموذج على mini-swe-agent، ويذكر أفضل تكوين لكل نموذج عبر مستويات الجهد؛ نسبة 74% لـ Opus 5 هي نتيجة تشغيله بجهد [max]. أما GitHub فقد تم تشغيله داخل بيئة التشغيل الخاصة به، وبمستوى استدلال متوسط. وكما كتبنا سابقاً عن بيئات تشغيل الاختبارات المرجعية، فإن الهيكل المحيط بالنموذج يؤثر في الدرجات بقدر ما يؤثر النموذج نفسه.¹⁶

هناك سطر آخر من نفس القسم ينتمي هنا: "تظهر النتائج أدناه أفضل تكوين مضبوط لـ HydraFusion".¹ الفروقات المنشورة تمثل أفضل حالة، وليس المتوسط.

أكثر تأييد قابل للاقتباس هو أيضاً الأكثر تحديداً: "حتى الآن، قدرة الاستدلال وحل المهام [لـ HydraFusion] تعادل أو تتفوق على Opus"، هذا ما نُقل عن مهندس برمجيات رئيسي في Microsoft — داخلياً، وبدون ذكر اسمه.¹

الاختبار المرجعي الذي تفوق فيه تم استبداله مرتين

Terminal-Bench 2.1 هو الاختبار المرجعي الوحيد الذي تفوق فيه HydraFusion على Opus 5. وهو أيضاً الأقدم من بين الاختبارين العامين — حيث أن CheckpointBench داخلي وغير مؤرخ. (يكتب GitHub الاسم "TerminalBench 2.1"؛ بينما يكتبه المسؤولون عن الصيانة Terminal-Bench.)

أصدر فريق Terminal-Bench الإصدار 2.1 في 6 مايو 2026. وقد احتفظ بمجموعة الـ 89 مهمة من الإصدار 2.0 وقام بإصلاح 28 من تلك المهام، ومعالجة التبعيات الخارجية التي تغيرت، وميزانيات الموارد التي كانت ضيقة جداً بحيث لا تسمح للحلول الصحيحة بالانتهاء، والحالات التي لم تتطابق فيها التعليمات مع الاختبارات. بعد الإصلاحات، لم تكن هناك أي مهمة في المجموعة غير محلولة. يتم استضافة الاختبار المرجعي من قبل Stanford و Harbor ومعهد Laude، بقيادة Kelly Buchanan في إصدار 2.1.⁷

ثم تطور الأمر. تم إطلاق Terminal-Bench 3.0 في 30 يوليو 2026، وTerminal-Bench 4.0 في 28 أغسطس 2026 — حيث قام الإصدار الأخير بمعايرة موارد المهام وإزالة المهام المشبعة. وتدرج لوحة المتصدرين الخاصة بـ Snorkel AI الإصدار 2.1 الآن كنسخة مؤرشفة (Archived)، وتصف الإصدار 3.0 في صفحته الخاصة بأنه "خلف أكثر صعوبة وتنوعاً في المجالات لـ Terminal-Bench 2.1".⁷⁸⁹

عند ترتيب التواريخ، نجد أن الفجوة محددة. كان Terminal-Bench 3.0 قد صدر منذ ما يقرب من أربعة أسابيع بحلول 25 أغسطس، وهي النقطة التي يقول فيها GitHub إن سلسلة تشغيل Terminal-Bench 2.1 وصلت إلى أقوى تكويناتها المسجلة. أما الإصدار 4.0 فقد صدر في 28 أغسطس. ونشر GitHub تقريره في 4 سبتمبر.¹⁸⁹

هناك سؤال حول الإصدار في DeepSWE أيضاً. أطلقت Datacurve إصدار DeepSWE v1.1 في 14 يونيو 2026 — نفس الـ 113 مهمة، ولكن تم تقييمها في حاوية (container) معزولة عن الرقعة البرمجية المعتمدة، مع إصلاح انزياح التبعيات وإزالة الاختبارات غير المستقرة. ولا يذكر منشور GitHub أي إصدار تم تقييمه.⁶

لا يتجاهل GitHub نقطة التشبع. حيث يقول منشوره أن "التشبع النسبي لـ Terminal-Bench 2.1 يجعل التحقق الأوسع نطاقاً أمراً مهماً"، وهذا هو بالضبط سبب إدراج DeepSWE.¹ كما أن سجل التطوير كان صريحاً في جوانب أخرى أيضاً: فبين 11 أغسطس و25 أغسطس، أدى فشلان تشغيليان في أدوات التقييم إلى إنتاج عمليات تشغيل غير صالحة، تم استبعادها وتصحيحها.¹

ومع ذلك، فإن الرقم الرئيسي يأتي من معيار قياس (benchmark) كان مطوروه قد استبدلوه مرتين بحلول يوم النشر. (لا تزال لوحة متصدرين 2.1 متاحة على tbench.ai؛ وكلمة "مؤرشفة" هي تسمية Snorkel لنسختها الخاصة، وليست عملية إزالة من قبل فريق Terminal-Bench).⁷

الورقة البحثية الكامنة وراء المنتج

الاسم ليس مجرد زينة. يعتمد HydraFusion على HyDRA — وهي بنية توجيه ديناميكية هجينة (Hybrid Dynamic Routing Architecture) — وهي ورقة بحثية عن التوجيه من Microsoft تم تقديمها إلى arXiv في 16 مايو 2026 وتمت مراجعتها في 12 يونيو.⁴¹⁰

ويظهر هذا التسلسل في قائمة المؤلفين. مؤلفو HyDRA هم Aashna Garg وSiddharth Singha Roy وJinu Jang وFederico Brancasi وShengyu Fu. وثلاثة منهم — Garg وRoy وFu — يظهرون في فريق HydraFusion التابع لـ GitHub.¹¹⁰

كما تتطابق البصمة التقنية أيضاً. يستخدم HyDRA مشفر ModernBERT مع أربعة رؤوس sigmoid مستقلة تقوم بتقييم كل استعلام بناءً على الاستنتاج، وتوليد الكود، وتصحيح الأخطاء، واستخدام الأدوات، ثم يطبق مطابقة العجز (shortfall matching) لاختيار أرخص نموذج يتجاوز ملفه الشخصي المتطلبات المتوقعة.¹⁰

هذه الأبعاد الأربعة هي نفسها "إشارات القدرة" التي تقول GitHub أن HydraFusion يستخدمها لاختيار نمط التنفيذ.¹ وتظهر نفس الأبعاد الأربعة للمرة الثالثة، بكلمات مختلفة، في سجل تغييرات 1 يوليو الخاص بـ Auto model selection: حيث يقوم Copilot بـ "تقييم مهمتك عبر عدة أبعاد مثل الاستنتاج، وتعقيد توليد الكود، وصعوبة تشخيص الأخطاء، واحتياجات تنسيق الأدوات" لاختيار النموذج.¹¹

تاريخ الإصدارات ليس مجرد تكهنات أيضًا. فقد أوضح الإعلان المجتمعي لـ GitHub الأمر في سطر واحد، مع وجود رابط تشعبي لـ HyDRA يؤدي إلى ملف PDF على arXiv:

"التطور: Auto V1 (يناير 2026، اختيار لكل طلب مدرك للسعة/SKU) ← Auto V2 المعروف بـ HyDRA (مايو 2026، توجيه بناءً على درجة القصد) ← HydraFusion (أغسطس 2026، تنسيق لكل دورة وسير عمل مدرك للتخزين المؤقت)."²

هذا يقول شيئاً أكثر تحديداً من "HydraFusion هو HyDRA". إن HyDRA هو Auto — وتحديداً Auto V2، وفقاً لتسمية GitHub نفسها، وهو متاح منذ مايو دون أن يتم تسويقه بهذا الاسم. ويتطابق ادعاء النشر في الورقة البحثية: حيث يعمل HyDRA في وضع auto الخاص بـ VS Code Chat في Copilot.¹⁰ أما HydraFusion فهو الجيل الذي يليه، وما تنسبه GitHub إليه هو التنسيق لكل دورة وسير العمل المدرك للتخزين المؤقت — وهو قرار ثانٍ مضاف فوق القرار الأول.

ما لا ينص عليه أي مصدر صراحة هو أن HydraFusion يشغل مصنف HyDRA داخلياً. الأدلة الظرفية قوية — مؤلفون مشتركون، محاور تقييم متطابقة، وتسلسل مباشر موثق — لكن الورقة تصف أداة لاختيار النموذج بينما يختار HydraFusion سير عمل، لذا تعامل مع عبارة "الورقة هي عقل التوجيه" كقراءة مرجحة بدلاً من كونها بنية مؤكدة.

هناك رقمان من الورقة البحثية يستحقان النقل.

يعمل المتنبئ بـ متوسط زمن استجابة لاستنتاج CPU يبلغ 86 مللي ثانية في بيئة الإنتاج وهو منفصل تماماً عن كتالوج النماذج — فإضافة نموذج أو إزالته هي مجرد تغيير في الإعدادات دون الحاجة لإعادة تدريب.¹⁰ إذا ورث HydraFusion هذه الخاصية، فإن ذلك سيجعل وعد GitHub بدمج نماذج جديدة في المجموعة مع تقدم التكنولوجيا أمراً واقعياً وليس مجرد طموح.¹

وفي اختبار SWE-Bench Verified مع مجموعة مكونة من خمسة نماذج، يمتد حد HyDRA القابل للضبط عبر ثلاثة أنظمة: حيث تفوقت "أعلى جودة" على خط الأساس الذي يستخدم Claude-Sonnet-4.6 دائماً (75.4% مقابل 74.2% في نسبة الحل) مع توفير في التكلفة بنسبة 12.9%؛ وتطابقت "الجودة المتساوية" مع Sonnet مع توفير بنسبة 54.1%، وهو تحسن بمقدار 6 أضعاف مقارنة بموجه Microsoft الثنائي الداخلي السابق الذي حقق 9.1%؛ ووصل "الإعداد القوي" إلى توفير بنسبة 72.5% مقابل تراجع في الجودة بمقدار 3.2 نقطة.¹⁰

هذا السطر الأخير هو التعميم الصادق للفئة بأكملها. التوجيه يمنحك مفتاح تحكم بين التكلفة والجودة. ومكان ضبطك لهذا المفتاح هو ما يحدد أي من هذين الرقمين يمكنك التفاخر به.

وهذا يفسر أيضاً عدم تماثل يبدو غريباً: تقول الورقة أن HyDRA متاح لـ جميع المستخدمين في وضع auto الخاص بـ VS Code Chat في Copilot، بينما HydraFusion هو معاينة تجريبية في CLI فقط.¹¹⁰² المصنف هو بنية تحتية للإنتاج. أما جيل التنسيق الذي يليه فهو الجزء الذي لا يزال قيد الاختبار.

HydraFusion مقابل Auto model selection

كان لدى Copilot بالفعل موجه (router). وصل الاختيار التلقائي للنموذج (Auto model selection) إلى التوفر العام في Copilot CLI في 17 أبريل 2026، ثم انتقل إلى وكيل Copilot السحابي في 14 مايو، وبحلول 1 يوليو كان يقوم بالتوجيه بناءً على نوع المهمة بالإضافة إلى الاستخدام وحالة النموذج.¹²¹³¹¹ تواريخ CLI هذه تسير جنبًا إلى جنب مع سجل الإصدارات أعلاه وليس ضده: خط Auto V1/V2 الخاص بـ GitHub يتتبع محرك التوجيه، بينما يتتبع سجل التغييرات أي واجهة حصلت عليه ومتى.²

إذًا ما الجديد؟ رسم ماريو رودريغيز، مدير المنتج الرئيسي في GitHub، الخط الفاصل لـ VentureBeat:

"أود أن أقول إن التوجيه إلى النموذج الصحيح أصبح بسرعة أمرًا بديهيًا، ولكن وجه الاختلاف في HydraFusion هو أنه يعالج 'ما هي أفضل طريقة لحل هذه المهمة' بدلاً من 'أي نموذج يجب أن يتولى هذه المهمة؟'"⁴

وعن كيفية تعايشهما معًا: "من الناحية العملية، Auto يتعلق باختيار النموذج بذكاء، بينما HydraFusion يتعلق بتنسيق سير العمل (workflow orchestration)." وأضاف أن GitHub تراهما مكملين لبعضهما البعض وتقوم "بتقييم إمكانية دمج HydraFusion في Auto."⁴

وتقول الأسئلة الشائعة الخاصة بـ GitHub الشيء نفسه بعبارات أبسط: "كل من Auto و HydraFusion يمثلان توجيهًا ذكيًا للنماذج، ونتوقع أن يندمجا في تجربة واحدة بمرور الوقت. ما زلنا نقيم كيف سيكون شكل ذلك."²

التمييز حقيقي. Auto يختار نموذجًا واحدًا لكل طلب. أما HydraFusion فيقرر عدد استدعاءات النماذج التي يحتاجها الطلب وما هو الدور الذي يلعبه كل منها. أحدهما هو "اختيار"؛ والآخر هو "تكوين".

ملاحظة الاندماج هي الجزء الذي يجب تذكره. إذا تم دمج HydraFusion في Auto، فإن تنسيق سير العمل سيتوقف عن كونه تجربة اختيارية ويصبح المسار الافتراضي لأي شخص لا يقوم بتغيير القائمة المنسدلة للنماذج.

بقية سوق التوجيه تعاني من نفس الفجوة

هذه ليست مشكلة خاصة بـ GitHub. فقد لاحظت VentureBeat الملاحظة نفسها بشأن سوق التوجيه ككل، وجاء إطلاقان آخران هذا الصيف بأرقام تكشف عن نفسها.⁴

أعلنت NVIDIA عن NeMo Switchyard في 11 أغسطس 2026 جنبًا إلى جنب مع Nemotron 3.5 Lightning. وقامت LangChain باختباره في نفس اليوم — 145 مهمة وكيلة متعددة الخطوات — ووجدت أن التوجيه خفض التكلفة بنسبة 74% مقارنة بمرجع Claude Opus 4.8، بينما انخفضت الدقة من 86.0% إلى 80.0%. 7% فقط من الاستدعاءات ذهبت إلى النموذج الرائد (frontier model)، وهذه الاستدعاءات شكلت 68.4% من الفاتورة. لقد غطينا ما أظهره هذا الاختبار فعليًا في أغسطس.¹⁴

وكان صياغة LangChain نفسها أبسط بشكل ملحوظ من صياغة المورد: "التوجيه هو مقايضة. تكلفة أقل بنسبة 74% مقابل انخفاض في الدقة بنحو ست نقاط."¹⁴

أطلقت OpenRouter موجه Auto مُعاد بناؤه في 10 أغسطس 2026، واصفةً اختيار النموذج المدفوع بإنفاق السوق بأنه يتفوق على موجهها القديم "عبر مجموعة واسعة من المهام ومستويات التكلفة."¹⁵

جدول البيانات الخاص به، عند مستوى التكلفة الافتراضي، أكثر تضارباً من تلك الجملة. فقد سجل الموجه (router) الجديد نتيجة أقل من الموجه القديم في MMLU Pro (85.2% مقابل 86.6%) و τ³-bench Banking (20.6% مقابل 21.0%)، وتساوى معه في SWE-Atlas QnA (30.4% لكليهما)، وتفوق بوضوح في WideSearch و DSQA. أما عند أقصى مستوى للتكلفة، فقد تفوق في جميع الاختبارات الخمسة — رغم أنه يكلف أكثر من الموجه القديم في أربعة منها.¹⁵

ثلاث شركات، ثلاثة إطلاقات، ونمط واحد: عمود التكلفة واضح ولا لبس فيه، بينما عمود الجودة منقسم. هذا الاتساق في حد ذاته يعطي مؤشراً هاماً. التوجيه (Routing) يوفر المال بشكل موثوق، أما مسألة الحفاظ على الجودة فتعتمد كلياً على مكان وضع "البوابة".

ما الذي يغيره هذا بالنسبة للفرق

لم تعد الجودة هي المحور الوحيد الذي يتم ضبط هذه المنتجات بناءً عليه — وهو تحول أشارت إليه VentureBeat أيضاً — و GitHub صريحة بشأن ذلك: سياسات التوجيه المرشحة لـ HydraFusion تم إنشاؤها بواسطة beam search وقِيست مقابل خط أساس ثابت "من حيث الجودة، والتكلفة، وأنماط الفشل".¹⁴ التكلفة هنا هدف أساسي في عملية التحسين، وليست مجرد تأثير جانبي لها.

هناك أربعة أمور تستحق الحسم قبل أن توجه ميزانية فريقك عبر أي من هذه الأنظمة.

حدد الرقم الذي تشتريه. تحتوي هذه الأنظمة على "مؤشر" للتكلفة مقابل الجودة بداخلها، سواء أظهرت واجهة المستخدم ذلك أم لا. ورقة HyDRA تجعل هذه المقايضة صريحة من خلال ثلاثة أنظمة عتبات منشورة. أما HydraFusion فلا يوفر تحكماً مماثلاً، ويبدو أن هذا أمر متعمد. وعندما سُئل في سلسلة الإعلانات عن "درجة حرارة التكلفة/الجودة"، أجاب موظف في Microsoft بأنها "بعد حقيقي" يفكر فيه الفريق، لكنه رد بأن HydraFusion "مستعد بالفعل وبشكل متعمد لإنفاق المزيد عندما يزيد ذلك من احتمالية الوصول للإجابة الصحيحة" وأن هذا السلوك "يجب أن يكون مدمجاً بالفعل". وبخصوص اختيار النموذج تحديداً، تقول الأسئلة الشائعة في GitHub "ليس اليوم"، وتصف "مزيجاً منسقاً" من النماذج ترفض نشره عمداً، وتختم بـ: "نعلم أن بعض الفرق تحتاج إلى تحكم أكبر هنا ونحن نبحث في الأمر".¹⁰² اعرف أين تقع نقطتك على هذا المنحنى — واعلم أنك لا تستطيع تحريكها اليوم.

راقب الإنفاق لكل جلسة، وليس لكل طلب. الموجه الذي يقوم بالمسودة، والنقد، والمراجعة يستهلك عدة استدعاءات للنماذج مقابل مطالبة (prompt) واحدة. متوسطات الاختبارات المرجعية لن تخبرك بتكلفة أسوأ جلسة لديك. إن التوجه نحو سقوف الإنفاق على مستوى الجلسة موجود تحديداً لأن محاسبة "لكل طلب" لم تعد تصف أعباء عمل الوكلاء (agents).

طابق النسخة التجريبية مع سير عملك. تم ضبط HydraFusion للمهام ذات المطالبة الواحدة والدورة الأولى، ولا يدعي حتى الآن أداءً قوياً في المهام متعددة الدورات.¹ الجلسات التكرارية الطويلة هي الحالة الشائعة لمعظم الفرق، وهي الحالة التي تقول GitHub إنها ستأتي لاحقاً.

اقرأ جدول الاختبارات المرجعية قبل قراءة الإعلان. في جميع الحالات الثلاث المذكورة أعلاه، كانت النتائج المختلطة متاحة للعلن فوراً — حيث وضعتها GitHub و OpenRouter في منشوراتهما، ونشرت LangChain أرقام Switchyard في اليوم الذي أعلنت فيه NVIDIA عنها. الجملة التسويقية والجدول يقولان أشياء مختلفة قليلاً في كل مرة. اقرأ الجدول أولاً.

الخلاصة

تنسيق وقت التشغيل (Runtime orchestration) هو رهان مثير للاهتمام حقاً. يقول GitHub ذلك بوضوح: "الانتقال من اختيار أفضل نموذج إلى بناء أفضل طريقة لحل كل مهمة بشكل ديناميكي".¹

الهندسة المحيطة بهذا الأمر دقيقة — سياقات مراجعة معزولة، تنفيذ محدود، محاسبة كاملة للتكاليف متعددة المراحل، وعدم تطبيق أي إصلاح عند فشل سير العمل في التحقق.¹ هذه هي التفاصيل التي تفصل بين العرض البحثي وبين شيء يمكنك توجيهه نحو مستودع أكواد (repository).

لكن الأرقام خلف هذا الادعاء تشير إلى التكلفة ثلاث مرات والجودة مرة واحدة. ظهرت ثلاثة جداول توجيه (routing tables) في غضون خمسة وعشرين يوماً — OpenRouter في 10 أغسطس، وSwitchyard في 11 أغسطس، وHydraFusion في 4 سبتمبر — والثلاثة يقرؤون بنفس الطريقة. الفئة تتقارب نحو قدرة حقيقية — وهي إنفاق أقل على المهام التي لا تحتاج إلى نموذج متطور (frontier model) — ونحو لغة تسويقية تصفها بأنها شيء أكبر قليلاً من ذلك.

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

المراجع