GitHub تشرح كيف خفّضت كلفة Copilot من دون التضحية بجودة مهام البرمجة

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

في تدوينة نشرها إريك كريستنسن وناباليس كليسيوس في 2 سبتمبر 2026، شرحت GitHub أربع تغييرات قالت إنها طُورت من خلال اختبارات غير متصلة بالإنترنت باستخدام معايير لتقييم مهام البرمجة الوكيلة، ثم تحققت منها عبر تجارب مضبوطة مع المستخدمين قبل إطلاقها. وتستخدم عدة منتجات من Copilot، بينها تطبيق GitHub Copilot ومراجعة الشيفرة، البنية الأساسية نفسها، بينما جاءت الأمثلة الواردة في التدوينة من GitHub Copilot CLI.

لماذا لا تكفي الاستجابة الأقصر؟

اختبرت GitHub تأثير أداة RTK، أو Rust Token Killer، التي تختصر مخرجات shell قبل عرضها على الوكيل. وفي إعدادات الاختبار المستخدمة، أدى حذف بعض النصوص المهمة إلى إعادة فتح المخرجات الأصلية أو إعادة تشغيل الأوامر. ونتيجة لذلك، انخفض حجم استجابة الأداة محلياً، لكن المهمة احتاجت في المتوسط إلى رموز أكثر ووقت أطول.

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

ضغط انتقائي للمخرجات

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

اعتمدت النسخة التي أُطلقت سياسة من ثلاث نقاط:

• إبقاء المخرجات الشبيهة بالشيفرة والنتائج الاعتباطية دون تغيير، بما في ذلك أوامر مثل cat وgit diff وgit show والبرامج النصية الاعتباطية.
• إعادة تنظيم نتائج البحث، مثل نتائج grep وقوائم الملفات، من دون حذف أي نتيجة.
• ضغط مخرجات التثبيت والبناء والاختبار والتقدم فقط عندما يكون الوفر كبيراً.

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

إزالة التنسيق غير الضروري

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

أدى التغيير إلى خفض كلفة استدلال النموذج بنحو 5% في معايير مهام البرمجة الوكيلة غير المتصلة، مع بقاء معدلات النجاح ضمن التباين المتوقع وعدم زيادة أخطاء التحرير. وفي تجربة إلكترونية مع مستخدمي Copilot CLI، انخفضت الكلفة اليومية المتوسطة للاستدلال لكل مستخدم بنحو 3%، من دون تراجع جوهري في مؤشرات الجودة أو الرضا التي قاستها GitHub.

اختصار التعليمات من دون تغيير السلوك

تراكمت تعليمات أداة task عبر أوصاف الأدوات والمخططات وتعريفات الوكلاء وتعليمات النظام. استخدمت GitHub حلقة لتحسين التعليمات آلياً، فقلصت النص بنحو النصف، ثم اختبرت السلوكيات التي أرادت الحفاظ عليها.

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

خفضت الصيغة النهائية نحو 1300 رمز من تعليمات أداة المهام في كل جولة، بما يعادل انخفاضاً يقارب 1.8% في إجمالي رموز التعليمات لكل جلسة و2.9% في الكلفة المطَبَّعة لكل ساعة نشاط، مع عدم رصد تراجع في الجودة ضمن التقييمات المقاسة.

إلغاء جولات الاسترجاع غير الضرورية

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

في المثال الذي يجمع أمر shell ووكيلاً فرعياً، كان استكمال العمل يتطلب سابقاً أربع استدعاءات للنموذج: استدعاءين لطلب النتائج واستدعاءين لمعالجتها. بعد التغيير، تصل النتيجتان معاً في استدعاء واحد للمعالجة. وقد خفض ذلك متوسط الاستخدام المرتبط بالرموز، كما تقيسه وحدات AI Credits، بنحو 2.3%.

ما الذي يتغير عملياً؟

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

في المقابل، لا يمكن تعميم كل نتيجة خارج بيئة الاختبار. فقد أدى تضييق تعليمات أدوات الملفات، رغم نجاحه في مراجعة الشيفرة، إلى زيادة الكلفة في تجربة Copilot CLI، ولذلك لم تُطلقه GitHub. كما أن ضغط git diff أُزيل بعد أن أظهرت المعايير أن الوكلاء يعيدون فتح المخرج الأصلي لاستعادة المعلومات المحذوفة.

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