ضغط السياق يمحو ثلث قواعد مكافحة الغش في ProgramBench

لم تعد المهام الطويلة للوكلاء تتسع في نافذة السياق، وصار على إطار عمل الوكيل أن يُخلي مساحة: يضغط السجل، ويحذف ما لا حاجة إليه، ويواصل العمل اعتمادًا على ملخص موجز. يُسمى هذا الأسلوب ضغط السياق (compaction)، وهو موجود تقريبًا في كل وكيل برمجة. لكنه لم يُختبر بشكل منهجي على النماذج الرائدة (frontier) ولا على مهام واقعية؛ فقد اكتفت الأعمال السابقة بتشغيل نماذج مفتوحة صغيرة على مسارات لعبية أو اصطناعية. وسدّت مجموعة Jeanne Salle ومعها أربعة مؤلفين هذه الفجوة، وخرجت بنتيجة ذات وجهين: الاختبارات المعيارية لا تكاد تلحظ الضغط، أما العمل الحقيقي فيلحظه.

كيف أُجريت التجربة

ثبّت المؤلفون إطار العمل OpenCode ونفّذوا داخله خمس استراتيجيات لضغط السياق. ثم شغّلوا ثلاثة نماذج رائدة على ثلاثة اختبارات معيارية طويلة. نموذجان من الثلاثة بسياق قدره 1 مليون رمز، والثالث GPT-5.3-Codex صاحب أصغر نافذة في العينة. كما غيّروا العتبة التي يبدأ عندها الضغط.

• إطار العمل: OpenCode، وهو نفسه في جميع التشغيلات.
• الاستراتيجيات: خمس طرق للضغط، والأساس فيها التلخيص الذاتي، أي أن يعيد النموذج بنفسه سرد سجله.
• النماذج: نموذجان بنافذة 1M، وGPT-5.3-Codex.
• الاختبارات المعيارية: PaperBench وProgramBench وPostTrainBench.
• مجموعة بيانات إضافية: جلسات مستخدمين حقيقية من SWE-chat.

أين يكون الضغط آمنًا وأين لا يكون

بالنسبة إلى النماذج ذات نافذة 1M، لا تؤثر عتبة الضغط في النتيجة بشكل ملحوظ. أما مع GPT-5.3-Codex فالصورة مختلفة: في PaperBench تنخفض الجودة عند العتبات المنخفضة، بينما يكون الأثر في PostTrainBench أضعف وأقل وضوحًا. والمنطق بسيط: كلما صغرت النافذة اضطُر الوكيل إلى الضغط أكثر وبشكل أشد، وتراكمت الخسائر.

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

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

وفي جلسات SWE-chat الحقيقية تبدو الفجوة أوضح. فالتعليمات المتعلقة بكيفية عمل الوكيل وما يجب ألا يفعله تُحذف أكثر بنحو 6 مرات من مواصفات ما يجب بناؤه. فالنموذج يتذكر الهدف جيدًا، لكنه يتذكر أسلوب العمل بشكل سيئ: الأسلوب، والمحظورات، والاتفاقات مع المستخدم.

لماذا تضلل الاختبارات المعيارية

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

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