بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
ثلاث إلى أربع تكرارات فقط — هذا هو الرقم الذي يفصل بين الاستفادة الحقيقية من حلقات الإصلاح التلقائي في أنظمة الكود البرمجي والتبذير الحسابي. هذا ما توصّل إليه بحث جديد نُشر على arXiv بتاريخ 6 يوليو 2026، ويُعيد من خلاله الباحثون تقييم واحدة من أكثر الأنماط شيوعاً في هندسة البرمجيات المعتمدة على النماذج اللغوية الكبيرة.
أعدّ الدراسة كلٌّ من Tobias Kiecker وEik Reichmann وHosung Kang وGabin An وLars Grunske، وتدور حول ما يُعرف بـ “repair loops” — أي حلقات التوليد والتحقق والإصلاح المتكررة التي باتت ركيزة في أنظمة LLM المستخدمة لتوليد الكود واختباره وترجمته. الفكرة بسيطة: يُولّد النموذج كوداً، تُشغّله أداة ما، يأتيها خطأ من المُصرِّف أو فشل في الاختبار، فتُعيد الطلب إلى النموذج كي يُصلحه — وهكذا دواليك. لكن كم مرة ينبغي إعادة المحاولة؟
المفاجأة في الإجابة ليست في الرقم بحد ذاته، بل في أن معظم الأنظمة تتجاوزه دون مبرر واضح. (وفقاً للبحث)، يتسم النمط الذي رصده الباحثون عبر مهام متعددة — توليد الكود، توليد الاختبارات، وترجمة الكود — بـ “العوائد المتناقصة”: التكرارات الثلاث أو الأربع الأولى تحقق الغالبية العظمى من المكاسب الممكنة، أما ما يليها فيُضيف تحسينات هامشية لا تُبرر التكلفة الحسابية ولا وقت التنفيذ الإضافي.
والأهم من الرقم نفسه هو ما يكشفه البحث عن طبيعة الأداء: سلوك الإصلاح لا يتحدد بالنموذج المُستخدم بقدر ما يتحدد بطريقة تصميم سير العمل وجودة التغذية الراجعة. بعبارة أخرى، نموذج متوسط مع تغذية راجعة مُصمَّمة بعناية يتفوق على نموذج أقوى يعمل ضمن workflow مُهمَل. هذه نتيجة ذات أثر عملي مباشر: المطوّرون الذين يبنون وكلاء برمجة أو خطوط تحقق تلقائية ينبغي أن يُخصصوا الجهد لتصميم آلية التغذية الراجعة بدلاً من الانشغال بانتقاء أفضل نموذج أو رفع سقف التكرارات.
البحث يُقدّم أيضاً نقداً منهجياً لطريقة إجراء التقييمات في هذا المجال. معظم الأعمال السابقة تعامل مع حد التكرار كمعطى ثابت — يُختار بشكل تعسفي ولا يُفصَح عنه بوضوح — مما يُشوّه نتائج الأداء ويجعل المقارنة بين الأنظمة المختلفة غير موثوقة. الباحثون يُطالبون بأن يُعامَل حد الإصلاح متغيراً تجريبياً صريحاً، لأنه يؤثر مباشرة على أربعة أبعاد متشابكة: نتائج التقييم، والتكلفة الحسابية، ووقت التشغيل، وقابلية إعادة الإنتاج.
ما يمنح هذه النتائج ثقلاً إضافياً هو أن الدراسة أُجريت عبر “نماذج منخفضة التكلفة معاصرة” — أي أنها لا تنطبق فقط على النماذج المتقدمة، بل تعكس واقع الأنظمة العملية التي يستخدمها معظم الفرق اليوم. كذلك غطّى الباحثون مهام متنوعة وسياقات متعددة، ما يُعزز موثوقية النمط المُكتشف ويبعده عن أن يكون نتيجة خاصة بحالة واحدة.
الدرس العملي للمطوّر الذي يُصمم نظام وكيل برمجي أو يُقيّم أداء LLM في مهام الكود: ثلاث تكرارات نقطة بداية منطقية، لا عشر. وكل تكرار إضافي يتجاوز الرابع يحتاج إلى مبرر قابل للقياس، وإلا فهو إهدار لموارد قد تذهب إلى تحسين التغذية الراجعة نفسها — حيث يقع التأثير الحقيقي.
