SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents
إن SWE-Pruner هو إطار عمل للتنقية التكيفية للسياق يستخدم مِشّاراً عصبياً مدركاً للمهام لتصفية الكود غير ذي الصلة ديناميكياً بناءً على أهداف الوكيل الصريحة، مما يقلل بشكل كبير من استخدام الرموز (tokens) والتكاليف مع الحفاظ على أداء وكيل البرمجة أو تحسينه عبر مختلف المعايلات.
المؤلفون الأصليون:Yuhang Wang, Yuling Shi, Mo Yang, Rongrui Zhang, Shilin He, Heng Lian, Yuting Chen, Siyu Ye, Kai Cai, Xiaodong Gu
تخيل أنك محقق يحاول حل قضية معقدة في مكتبة ضخمة يملؤها الغبار. هذه المكتبة هي في الواقع الكود المصدري لبرنامج حاسوبي، ومهمتك هي العثور على خطأ برمي (bug) محدد أو إضافة ميزة جديدة.
المشكلة: فخ "المعلومات الزائدة عن الحد" في الماضي، عندما كنت تسأل محقق ذكاء اصطناعي فائق الذكاء (وكيل LLM) لحل هذه الألغاز البرمجية، كنت تقدم له المكتبة بأكملها دفعة واحدة. كان الذكاء الاصطناعي يحاول قراءة كل كتاب، وكل صفحة، وكل حاشية سفلية للعثور على الخيط الذي يحتاه.
وقد تسبب هذا في مشكلتين كبيرتين:
الارتباك والارهاق: إن "عقل" الذكاء الاصطناعي (نافذة السياق الخاصة به) له حد معين. إذا أعطيته الكثير من النصوص، سيبدأ في نسيان بداية القصة أو يصاب بالارتباك بسبب التفاصيل غير ذات الصلة (مثل قراءة كتاب وصفات طعام بينما تبحث عن دليل تعليمات سيارة).
التكلفة العالية: كل كلمة يقرؤها ويكتبها الذكاء الاصطناعي تكلف مالاً ووقتاً. قراءة المكتبة بأكملها من أجل كل خيط بسيط كان يشبه الدفع مقابل قراءة الموسوعة بأكملها فقط للعثور على رقم هاتف واحد.
حاولت الحلول الموجودة معالجة ذلك عبر تلخيص الكتب أو حذف كلمات عشوائية لتوفير المساحة. لكن هذا كان يشبه محاولة تلخيص دليل تعليمات سيارة عبر حذف كلمة "محرك" أو "مكبح". لقد أدى ذلك إلى كسر المنطق، مما جعل الكود غير قابل للقراءة أو عديم الفائدة.
الحل: SWE-Pruner (أمين المكتبة الذكي) قدم مؤلفو هذه الورقة البحثية SWE-Pruner، والذي يعمل كأمين مكتبة ماهر للغاية وقابل للتكيف يقف بينك وبين المكتبة.
إليك كيف يعمل بكلمات بسيطة:
أنت تطرح سؤالاً محدداً: بدلاً من مجرد قول "اقرأ هذا الملف"، يتم تعليم وكيل الذكاء الاصطناعي طرح سؤال محدد أولاً، مثل "تلميح الهدف" (Goal Hint). على سبيل المثال: "أحتاج إلى العث ط الجزء من الكود الذي يعالج أخطاء تسجيل دخول المستخدم".
أمين المكتبة يلقي نظرة خاطفة: يقوم SWE-Pruner (وهو نموذج ذكاء اصطناعي صغير وسريع) بأخذ الملف الضخم والسؤال المحدد. هو لا يقرأ كل كلمة بعمق؛ بل "يتصفح" النص تماماً كما يفعل المبرمج البشري عند تصحيح الأخطاء (debugging). فهو يعرف بالضبط أي الأسطر ذات صلة بـ "أخطاء تسجيل الدخول" وأي الأسطر تتعلق بـ "إعدادات قاعدة البيانات" أو "سمات الألوان".
يقص الحشو: يقوم أمين المكتبة بقص الصفحات غير ذات الصلة ويقدم لوكيل الذكاء الاصطناعي الفقرات المحددة والمناسبة فقط. والأهم من ذلك، أنه يفعل ذلك سطراً بسطر. هو لا يقطع الجمل أو يزيل الكلمات المفتاحية عشوائياً؛ بل يحافظ على هيكل الكود سليماً، مثل الحفاظ على فقرة كاملة حتى لو قمت بإزالة الفقرة التي تسبقها.
النتيجة: يحصل وكيل الذكاء الاصطناعي على قطعة قصيرة، مركزة، ونظيفة من اللغز. يمكنه حل المشكلة بشكل أسرع، وارتكاب أخطاء أقل، وبتكلفة أقل بكثير.
التشبيه: "الإبرة في كومة القش" مقابل "المنخل"
الطريقة القديمة: تفرغ كومة القش بأكملها على الطاولة وتطلب من الذكاء الاصطنا_الأن يجد الإبرة. يتعب الذكاء الاصطناعي، ويرتبك، وينفق ثروة.
الضغط السيئ: تحاول تقليص حجم كومة القش عن طريق سحقها. الآن أصبحت الإبرة مدفونة في كومة صغيرة ومكسورة من القش، ولا يمكنك معرفة اتجاهها.
SWE-Pruner: تستخدم منخلاً (غربالاً) مشكلاً تماماً مثل شكل الإبرة. تهز كومة القش، ولا يسقط من خلال المنخل إلا الإبرة (والقليل من القش المتصل بها). أما بقية القش فيبقى خلف المنخل. الإبرة سليمة تماماً وجاهزة للاستخدام.
ما وجدوه اختبروا هذه الورقة في مهام برمجية واقعية (مثل إصلاح الأخطاء في GitHub).
التكلفة والسرعة: نجحوا في تقليل كمية النص التي كان على الذكاء الاصطناعي قراءتها بنسبة 23% إلى 54%. وهذا يعني أن الذكاء الاصطناعي حل المهام بشكل أسرع وأرخص.
قرارات أذكى: نظرًا لأن الذكاء الاصطناعي لم يكن مشتتًا بالكود غير ذي الصلة، فقد اتخذ قرارات أفضل. في بعض الاختبارات، ارتفع معدل النجاح في إصلاح الأخطاء قليلاً لأن الذكاء الاصطناعي استطاع التركيز بشكل أفضل.
عدم التلف: على عكس الطرق الأخرى التي كسرت قواعد الكود، حافظ SWE-Pruner على هيكل الكود مثالياً، بحيث ظل بإمكان الذكاء الاصطناعي فهم كيفية ترابط القطع معاً.
باختاً، يعلم SWE-Pruner وكلاء البرمجة التوقف عن قراءة الكتاب بأكمله والبدء في قراءة الفصول التي تهمهم فقط، مما يوفر الوقت والمال والطاقة الذهنية.
إليك ملخص تقني مفصل لورقة البحث بعنوان "SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents".
1. بيان المشكلة
أظهرت وكلاء النماذج اللغوية الكبيرة (LLM agents) إمكانات ملحوقة في مهام هندسة البرمجيات، بدءًا من فهم الكود وصولاً إلى التوليد الذاتي للرقع البرمجية (patches). ومع ذلك، فإن فعاليتها تعوقها بشدة مشكلة "جدار السياق" (Context Wall):
تراكم الرموز (Token Accumulation): مستودعات البرمجيات في العالم الحقيقي ضخمة للغاية. والوكلاء الذين يتنقلون في هذه المستودعات يراكمون سجلات تفاعل ومحتويات ملفات خام طويلة، مما يؤدي سريعًا إلى استنفاد نوافذ السياق حتى في النماذج ذات السياق الطويل.
التكلفة وزمن الاستجابة (Latency): يؤدي استيعاب كميات هائلة من الكود بشكل أعمى إلى تكاليف واجهة برمجة تطبيقات (API) باهظة وزمن استجابة مرتفع في عملية الاستدلال.
تشتت الانتباه (Attention Dilution): يُدخل السياق المفرط ضجيجًا، مما يسبب "تشتت الانتباه" والهلوسة، حيث يفقد النموذج تركيزه على التفاصيل التنفيذية الحرجة.
قصور الحلول الحالية: تعتمد طرق ضغط السياق الحالية (مثل LongLLMLingua وSelective-Context) على مقايقات ثابتة مثل الـ Perplexity (PPL) أو المعلومات الذاتية. هذه الطرق غير مرتبطة بالمهمة (task-agnostic) وغالبًا ما تعمل على مستوى الرمز (token level)، مما يؤدي إلى كسر البنية النحوية والمنطقية للكود، ويجعله غير قابل للاستخدام للبرمجة أو التجميع (compilation). كما أنها تفشل في التكيف مع الأهداف الديناميكية المتطورة للتفاعلات متعددة الخطوات للوكيل.
2. المنهجية: SWE-Pruner
يقترح المؤلفون SWE-Pruner، وهو إطار عمل لتقليم السياق ذاتي التكيف مصمم خصيصًا لوكلاء البرمجة. يعمل كبرمجية وسيطة (middleware) بين الوكيل والبيئة، حيث يعترض أوامر قراءة الملفات (مثل cat و grep) لتصفية السياق الخام قبل وصوله إلى النموذج اللغوي الكبير.
المكونات الأساسية
توليد تلميح الهدف (Goal Hint Generation):
بدلاً من الضغط الثابت، يتم توجيه الوكيل لتوليد "تلميح هدف" (Goal Hint) — وهو وصف باللغة الطبيعية لاحتياجه المعلوماتي الحالي (على سبيل-مثال: "ركز على منطق معالجة الأخطاء في وحدة Auth").
يتم تمرير هذا التلميح كمعامل اختياري (context_focus_question) إلى نظام التقليم، مما يتيح تصفية مرتبطة بالمهمة (task-aware).
البنية: نموذج بـ 0.6 مليار معلمة (parameter) يعتمد على Qwen3-Reranker-0.6B. وهو مصمم لضمان زمن استجابة منخفض وكفاءة عالية.
الآلية: يعامل الماسح عملية تقليم السياق كمسألة إعادة ترتيب (reranking). فبناءً على استعلام (تلميح الهدف) وسياق (محتوى الملف الخام)، يقوم بحساب درجات الصلة.
دقة على مستوى السطر (Line-Level Granularity): على عكس التقليم على مستوى الرمز، يقوم SWE-Pruner بتجميع درجات الرموز إلى مستوى السطر. هذا يضمن بقاء الهياكل النحوية (مثل تعريفات الدوال أو كتل الفئات/classes) سليمة، مما يمنع كسر الكود.
هدف التدريب: تم تدريب النموذج باستخدام فقدان الحقل العشوائي المشروط (Conditional Random Field - CRF) لنمذجة التبعيات التسلسلية بين قرارات "الاحتفاظ" و"التقليم"، مما يضمن احتفاظًا متماسكًا على مستوى السطر. كما يتضمن رأس إعادة ترتيب على مستوى المستند للحفاظ على الصلة الشاملة.
بناء بيانات التدريب:
نظرًا لعدم وجود مجموعة بيانات تحتوي على تسميات توضيحية لصلة المستوى السطري لوكلاء البرمجة، قام المؤلفون ببناء متن متعدد اللغات (polyglot corpus) مكون من 61 ألف عينة باستخدام نموذج المعلم والطالب (teacher-student paradigm).
قام نموذج معلم (Qwen3-Coder-30B) بتخليق استعلامات موجهة للمهام وأقنعة احتفاظ على مستوى السطر من مستودعات GitHub، تغطي تسع مهام وكيلة متميزة (مثل تصحيح الأخطاء، إعادة الهيكلة، إضافة الميزات).
استخدمت آلية "النموذج اللغوي كحكم" (LLM-as-a-Judge) لتصفية البيانات لضمان جودة التسميات التوضيحية.
سير عمل التكامل:
يتم دمج الإطار في حلقات الوكيل (مثل Mini SWE Agent و OpenHands). عندما يقرأ الوكيل ملفًا، يتم إرسال المخرج الخام إلى الماسح مع "تلميح الهدف". يعيد الماسح سياقًا مقلمًا (Pruned Context) يحتوي فقط على الأسطر ذات الصلة، والتي يعالجها الوكيل بعد ذلك.
3. المساهمات الرئيسية
إطار عمل للتقليم المرتبط بالمهمة: قدم نهجًا مبتكرًا يتكيف ديناميكيًا مع ضغط السياق بناءً على أهداف الاستدلال الخاصة بالوكيل، متجاوزًا الضغط الثابت القائم على المحتوى فقط.
الحفاظ على البنية على مستوى السطر: صمم ماسحًا عصبيًا خفيف الوزن يعمل على مستوى السطر، مما يحافظ على الصلاحية النحوية والبنية المنطقية، وهو أمر بالغ الأهمية لصحة الكود.
بنية فعالة: طور نموذجًا بـ 0.6 مليار معلمة يضيف زمن استجابة ضئيلاً جدًا (أقل من 100 مللي ثانية) بينما يحقق تقليلاً كبيرًا في عدد الرموز، مما يجعله عمليًا لتدفقات عمل الوكلاء في الوقت الفعلي.
خط إنتاج البيانات الاصطناعية: أنشأ خط إنتاج صارم لتوليد بيانات إشرافية عالية الجودة على مستوى السطر لتقليم الكود، مما عالج فجوة بيانات حرجة في هذا المجال.
4. النتائج التجريبية
قيم المؤلفون SWE-Pruner عبر أربعة اختبارات مرجعية: SWE-Bench Verified و SWE-QA (مهام الوكيل متعددة الخطوات)، و Long Code Completion و Long Code QA (مهام الخطوة الواحدة).
مهام الوكيل متعددة الخطوات (SWE-Bench Verified):
تقليل الرموز: حقق تخفيضًا بنسبة 23-38% في إجمالي استهلاك الرموز.
معدل النجاح: للمفاجأة، تحسن معدل النجاح بمقدار 1.2 إلى 1.4 نقطة مئوية (على سبيل المثال، من 70.6% إلى 72.0% مع Claude Sonnet 4.5).
الكفاءة: قلل من جولات التفاعل بنسبة 18-26%، مما يشير إلى أن الوكلاء يتخذون قرارات أكثر حسمًا بسياق أكثر تركيزًا.
التكلفة: خفض كبير في تكاليف واجهة برمجة التطبيقات (توفير يصل إلى ~36%).
مهام الخطوة الواحدة (Long Code QA/Completion):
نسبة الضغط: حقق ضغطًا يصل إلى 14.84 ضعفًا في Long Code QA تحت قيود صارمة، متفوقًا بمراحل على النماذج المرجعية مثل LLMLingua2 و RAG.
الأداء: حافظ على الدقة أو حسنها قليلاً (على سبيل المثال، دقة 58.71% عند ضغط 14.84 ضعفًا) مقارنة بالسياق الكامل، بينما عانت النماذج المرجعية القائمة على مستوى الرمز من تدهور حاد في الأداء تحت الضغط العالي.
الكفاءة وزمن الاستجابة:
يضيف الماسح (0.6B) عبئًا ضئيلاً (زمن استجابة لأول رمز أقل من 100 مللي ثانية)، والذي يتم تعويضه من خلال التخفيض الهائل في تكاليف فك تشفير النماذج اللغوية الكبيرة اللاحقة.
صحة شجرة الإعراب المجردة (AST Correctness): حافظ SWE-Pruner على صحة AST بنسبة 87.3% (الصلاحية النحوية)، متفوقًا بشكل كبير على الطرق القائمة على مستوى الرمز (التي انخفضت إلى ما يقرب من 0% أو أقل من 13%).
5. الأهمية
حل مشكلة جدار السياق: يوفر SWE-Pruner حلاً قابلاً للتوسع لمحدودية نافذة السياق لوكلاء البرمجة، مما يمكنهم من التنقل في قواعد الأكواد الكبيرة والمعقدة دون تكبد تكاليف باهظة أو فقدان التركيز.
تحول في النموذج (Paradigm Shift): ينقل إدارة السياق من الضغط الثابت إلى الاختيار الديناميكي الموجه بالهدف، محاكيًا الطريقة التي يقوم بها المطورون البشر بـ "تصفح" الكود بناءً على أهداف محددة لتصحيح الأخطاء أو إضافة الميزات.
الجدوى العملية: الإطار خفيف الوزن، ومستقل عن نوع النموذج (يعمل مع Claude، GLM، Qwen، إلخ)، ويتكامل بسلاسة كبرمجية وسيطة، مما يجعله قابلًا للتطبيق الفوري في البنية التحتية الحالية للوكلاء.
الجودة فوق الكمية: تثبت النتائج أن السياق الأقل هو الأفضل غالبًا لوكلاء البرمجة، بشرما إذا كان السياق المستبقى سليمًا بنيويًا وذا صلة دلالية بالمهمة الحالية. وهذا يتحدى الافتراض السائد بأن "السياق الأكثر هو الأفضل" في أبحاث النماذج اللغوية الكبيرة ذات السياق الطويل.