The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks
تقدم هذه الورقة مفهوم "دين التماسك" (coherence debt) لتوضيح أن نجاح وكلاء البرمجة على مستوى المستودعات يعتمد بشكل أساسي على التوافر الفوري للحقائق السياقية المطلوبة بدلاً من المسافة أو الذاكرة البارامترية للوكيل، مما يكشف أن الوكلاء غالباً ما يختلقون حلولاً عند فقدان الحقائق، وأن أطر التقييم الحالية قد تشخص الإخفاقات بشكل خاطئ عبر التركيز على عمليات القراءة بدلاً من اتساق المخرجات المولدة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم البرمجيات، نادراً ما يوجد سطر واحد من الكود في عزلة. فلتغيير رقم في ملف واحد، غالباً ما يحتاج المبرمج إلى معرفة كيفية استخدام هذا الرقم في ثلاثة ملفات أخرى، وما هي إعدادات التكوين التي تتحكم فيه، وأي الاختبارات يجب أن تنجح لإثبات أن التغيير آمن. هذا النسيج من الروابط هو ما يجعل إصلاح خطأ برمي أو ترقية نظام أمراً صعباً؛ فالإجابة الصحيحة تعتمد على حقائق مبعثرة عبر المشروع بأكته. لسنوات، حاول الباحثون بناء وكلاء ذكاء اصطناعي يمكنهم التنقل في هذه الشبكات المعقدة، ليعملوا كأنهم مبرمجون مبتدئون يمكنهم قراءة قاعدة بيانات كاملة، وفهم القواعد، وإجراء التعديلات الصحيحة. وكان الأمل هو أننا إذا منحنا هؤلاء الوكلاء معلومات كافية عن المشروع، فسوف ينجحون. لكن دراسة جديدة تشير إلى أن مجرد منح الوكيل مزيد من المعلومات ليس هو القصة بأكملها. التحدي الحقيقي ليس فقط في توفر الحقائق، بل في توفر الحقائق الصحيحة في اللحظة التي يحاول فيها الوكيل كتابة سطر جديد من الكود.
لقد وضع باحثون من عدة مؤسسات، بما في ذلك معهد ماكس بلانك لأنظمة البرمجيات وEPFL، هدفاً لاختبار كيفية تعامل هؤلاء الوكلاء مع تدفق المعلومات أثناء مهمة برمجة. لقد عاملوا المشروع كنظام حي حيث يجب على الوكيل باستمرار الاحتفاظ بـ "مجموعة عمل" من الحقائق في ذهنه: متطلبات الاختبار الحالية، أسماء الأدوات المستوردة، والقواعد التي تحدد كيفية سلوك البرنامج. وقد طرحوا سؤالاً بسيطاً ولكنه عميق: ماذا يحدث عندما تغيب حقيقة ضرورية عن رؤية الوكيل؟ هل يتوقف الوكيل ويطلب المساعدة، أم أنه يخمن؟ وهل يهم إذا كانت الحقيقة موجودة بجوار التعديل مباشرة أم مدفونة في قائمة طويلة من التعليمات السابقة؟
ولإيجاد الإجابة، أنشأ الفريق سلسلة من التجارب المنضبطة. قاموا ببناء مكتبات برمجية خيالية بقواعد محددة لم يسبق لأي ذكاء اصطناعي رؤيتها من قبل، مما ضمن عدم قدرة الوكلاء على الاعتماد على المعرفة المحفوظة. ثم مرروا الوكلاء عبر مهام هجرة، مثل تحديث مكتبة من إصدار إلى آخر، تحت ظروف مختلفة. في بعض الجولات، أُعطي الوكلاء وصف المهمة دون الوصول إلى الكود أو القواعد، مما أجبرهم على الاعتماد كلياً على ما تعلموه أثناء تدريبهم. وفي جولات أخرى، قدم الباحثون القواعد وملفات المصدر الدقيقة في البداية مباشرة. كما اختبروا ما سيحدث إذا أخفوا عمداً قطعاً معينة من المعلومات، مثل قيمة سرية مطلوبة لحساب نتيجة ما، لمعرفة رد فعل الوكلاء.
كانت النتائج صارخة وواضحة. فعندما حُرم الوكلاء من الوصول إلى الحقائق الضرورية، لم يتوقفوا ببساطة عن العمل أو يعترفوا بأنهم عالقون. بدلاً من ذلك، استمروا في العمل، وغالباً بثقة خطيرة. إذا كان الملف مفقوداً، فسيقوم الوكيل بابتكار ملف جديد. وإذا كانت القيمة غير معروفة، فسيخمن رقماً. لقد أنتج الوكلاء "عملاً خاطئاً" بدلاً من "العمل الغائب". لقد لفقوا ملفات وخمنوا قيماً، مما خلق كوداً يبدو مكتملاً ولكنه معطل جوهرياً. هذا السلوك يعني أن الأدوات القياسية المستخدمة لقياس نجاح الوكيل، والتي غالباً ما تتحقق فقط مما إذا كان الوكيل قد قرأ ملفاً ما، كانت مضللة. إذ يمكن للوكيل أن يقرأ ملفاً كتبه هو بنفسه، أو يقرأ ملفاً غير ذي صلة، وستعتبر الأدوات ذلك "قياماً بالعمل"، رغم أن الوكيل قد فاتته الحقيقة الحاسمة التي يحتاجها.
كما كشفت الدراسة أن موقع المعلومات لم يكن مهماً بقدر وجودها. اختبر الباحثون ما إذا كان هناك فرق فيما إذا تم وضع حقيقة مطلوبة في بداية قائمة طويلة من التعليمات مقابل وضعها بجوار المكان الذي يتم فيه التعديل مباشرة. ووجدوا أنه طالما كانت الحقيقة موجودة في رؤية الوكيل، فيمكن استخدامها بنفس الفعالية سواء كانت في بداية أو نهاية نافذة سياق ضخمة. لم تؤدِ المسافة إلى تدهور قدرة الوكيل على استخدام الحقيقة. ومع ذلك، إذا تم حجب الحقيقة تماماً، فإن الوكيل يفشل، بغض النظر عن كمية المعلومات الأخرى التي يمتلكها. كان الضرر خطياً: إخفاء حقيقة واحدة تسبب في فشل الوكيل في المهام المحددة التي تعتمد على تلك الحقيقة، لكنه لم يتسبب في سلسلة من الإخفاقات في أجزاء غير مرتبطة من الكود.
ولعل الاكتشاف الأكثر إثارة للدهشة يتعلق بقدرة الوكلاء على الاعتراف بأنهم متعثرون. وجد الباحثون أن ما إذا كان الوكيل سيقول "لا يمكنني المضي قدماً لأنني أفتقد ملفاً" يعتمد كلياً على نموذج الذكاء الاصطناعي المحدد المستخدم. فبعض النماذج، مثل نموذج يسمى Opus، أبلغت عن كونها متعثرة في كل تجربة عند فقدان ملف. بينما نماذج أخرى، مثل Codex، لم تبلغ أبداً عن تعثرها؛ بل قامت ببساطة بتلفيق الملف المفقود والاستمرار. يشير هذا إلى أن القدرة على إدراك فجوة في المعرفة ليست ميزة عالمية لوكلاء البرمجة، بل هي سمة خاصة بالنموذج نفسه. بالنسبة للأنظمة التي لا تعترف بأنها عالقة، فإن "دين التماسك" (coherence debt) — وهو الفجوة بين ما يحتاجه الوكيل وما يعرفه — يظل غير مرئي حتى يتم فحص الكود النهائي ويُكتشف أنه خاطئ.
اكتشف الباحثون أيضاً أن الطريقة التي تُنظم بها مهمة البرمجة هي الأكثر أهمية من حجم المعلومات الإجمالي. فعندما قسموا مهمة مترابطة بإحكام عبر عدة وكلاء، انخفض معدل النجاح لأن الوكلاء لم يتمكنوا من الحفاظ على اتساق الحقائق المشتركة. ولكن عندما قسموا مهاماً مستقلة، عمل الوكلاء بنفس الكفاءة. أكد هذا أن المشكلة ليست فقط في امتلاك ما يكفي من البيانات، بل في إبقاء الحقائق المحددة المرتبطة ببعضها متاحة في نفس الوقت. فإذا طُلب من الوكيل تغيير إعداد في ملف ما، فيجب أن يمتلك القيمة الحالية لذلك الإعداد والقاعدة التي توضح كيفية تفاعله مع الملفات الأخرى في رؤيته المباشرة.
أخيراً، بحثت الدراسة فيما يحدث عندما تكون المعلومات المتاحة للوكيل متناقضة. في بعض التجارب، قدم الباحثون وثيقة معيارية مكتوبة تقول شيئاً، بينما أظهر الكود الحالي في المشروع عكس ذلك. في كل حالة، اتبع الوكلاء المعيار المكتوب، حتى عندما كان المعيار يفرض طريقة أسوأ أو أكثر عرضة للخطأ في كتابة الكود. يشير هذا إلى أنه بالنسبة لوكلاء الذكاء الاصطناعي هؤلاء، فإن القاعدة المكتوبة تحمل سلطة أكبر من السلوك الفعلي للبرنامج الذي من المفترض أن تصفه. إذا كان المعيار قديماً، فسيقوم الوكيل بإعادة إنتاج القاعدة القديمة بأمانة، مما يجعل الوثيقة القديمة أكثر خطورة من عدم وجود وثيقة على الإطلاق.
إن تداعيات هذه النتائج كبيرة لكيفية بناء وتقييم أدوات برمجة الذكاء الاصطناعي. فقد تبين أن مجرد جعل نافذة السياق أكبر أو منح الوكيل ذاكرة أكثر لا يضمن النجاح. العامل الحاسم هو ضمان أن الحقائق المحددة التي يحتاجها الوكيل لإجراء تعديل موجودة ومتسقة في اللحظة التي يكتب فيها. فإذا فقد الوكيل حقيقة ما، فلن ينتظر؛ بل سيخمن. وإذا كانت الحقائق التي مُنحت له متناقضة، فسوف يتبع القاعدة المكتوبة، حتى لو كانت تلك القاعدة خاطئة. وتخلص الدراسة إلى أن أفضل طريقة لبناء هذه الأنظمة ليست فقط في تغذيتها بمزيد من البيانات، بل في تصميم البيئة بحيث تكون الحقائق الضرورية متاحة ومحدثة دائماً، وفحص مخرجات الوكيل بناءً على ما أنتجه بالفعل، بدلاً من افتراض أنه قرأ الأشياء الصحيحة. الوكلاء لا يفشلون لأنهم صغار جداً أو بطيئون جداً؛ بل يفشلون لأنهم متحمسون جداً لملء الفراغات عندما تكون الحقائق مفقودة.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.