ملخص تقني: ضغط مخططات الأدوات يُمكّن نظام RAG الوكيل (Agentic RAG) في ظل ميزانيات السياق المقيدة

بيان المشكلة

تواجه أنظمة التوليد المعزز بالاسترجاع الوكيل (Agentic RAG) صراعاً حرجاً في الموارد: نافذة السياق المطلوبة لعملية التوليد المعزز بالاسترجاع تُستهلك من قِبل تعريفات الأدوات اللازمة لعمل الوكيل. في بيئات الإنتاج، غالباً ما تتطلب الوكلاء ما بين 20 إلى 100+ تعريف للأدوات، والتي تُمثل عادةً ككائنات JSON Schema مطولة. تستهلك هذه المخططات ما بين 300 إلى 500 توكن (Token) لكل أداة. وبناءً على ذلك، عند ميزانيات سياق متواضعة (مثل 8K توكن) مع وجود 28 أداة فقط، يتجاوز كتلة المخطط وحدها (~11,000 توكن) نافذة السياق بالكامل. هذا "التجاوز السياقي" (Context Overflow) لا يترك أي ميزانية لقطع الاسترجاع (Retrieval Chunks)، أو المطالبات النظامية (System Prompts)، أو تاريخ المحادثة، مما يجعل نظام RAG غير فعال.

تركز الأبحاث الحالية حول ضغط المطالبات (Prompt Compression) بشكل أساسي على اللغة الطبيعية، وتفشل في معالجة الثوابت الهيكلية (النحو، أنواع المعاملات، القيم المحددة/Enums) المطلوبة للتعريفات القابلة للقراءة آلياً للأدوات. علاوة على ذلك، لم يقم العمل السابق بتقييم الموازنة بين حجم المخطط وأداء الاسترجاع في سير عمل الوكلاء بشكل منهجي.

المنهجية

يقدم المؤلفون أول دراسة منضبطة لضغط مخططات الأدوات في نظام Agentic RAG، باستخدام تصميم تجريبي صارم:

• المعيار المرجعي (Benchmark): معيار "NovaTech-28" المصمم خصيصاً والذي يضم 28 تعريف أداة (قاعدة بيانات، استرجاع مستندات، حسابات، اتصالات) و100 سؤال عبر خمس فئات (خطوة واحدة، خطوات متعددة، يتطلب أداة، إلخ). تتكون مجموعة الاسترجاع من 40 قطعة (كل قطعة 350 توكن).
• تقنية الضغط: تستخدم الدراسة تقنية TSCG (مولد ضغط مخططات الأدوات)، وهي طريقة ضغط حتمية قائمة على القواعد تحافظ على بناء JSON Schema وتحقق وفراً في التوكنات بنسبة 44-50%.
• نطاق التجربة:
  • النماذج: 14 نموذجاً تتراوح معلماتها بين 1.5B إلى 32B (محلي) بالإضافة إلى نموذج واجهة برمجة تطبيقات رائد (Claude Sonnet 4).
  • ميزانيات السياق: ثلاثة مستويات: 8K، 16K، و32K توكن.
  • النطاق: 6,566 استدعاءً منضبطاً لواجهة برمجة التطبيقات (API calls).
  • التصميم: مقارنات زوجية (نفس الأسئلة، نفس النماذج) تختلف فقط في تنسيق المخطط (JSON مقابل TSCG) وما ينتج عن ذلك من تخصيص لميزانية السياق.
• المقاييس: تشمل المقاييس الأساسية المطابقة التامة (Exact Match - EM) ودرجة F1 للتوكن (Token F1). وتشمل المقاييس الثانوية دقة اختيار الأداة وكشف تجاوز السياق. يتم تقييم الأهمية الإحصائية عبر اختبارات Wilcoxon signed-rank وفترات الثقة لأسلوب Bootstrap.
• التحقق: التحقق الخارجي على HotpotQA (50 سؤالاً متعدد الخطوات) واختبارات التوسع للنماذج الرائدة حتى 800 أداة باستخدام نافذة سياق 200K.

النتائج الرئيسية

1. التمكين الثنائي عند الميزانيات المقيدة (8K)

عند ميزانية سياق 8K مع 28 أداة، تتسبب مخططات JSON غير المضغوطة في تجاوز سياقي بنسبة 100%، مما يؤدي إلى نتائج تقترب من الصفر في درجة المطابقة التامة (EM) (بمتوسط 2.6%).

• أثر الضغط: يؤدي تطبيق ضغط TSCG إلى تقليل توكنات المخطط بنسبة ~50%، مما يوفر مساحة كافية لاستيعاب قطعة استرجاع واحدة على الأقل.
• رفع الأداء: يؤدي استعادة الوظائف هذا إلى زيادة هائلة في متوسط المطابقة التمة (EM) بمقدار +20.5 نقطة مئوية (pp) عبر جميع النماذج الثمانية المختبرة عند 8K. النماذج التي أظهرت "تمكيناً كاملاً" شهدت متوسط زيادة قدره +24.7 نقطة مئوية.
• الآلية: يُعزى هذا المكسب إلى تحويل النظام من حالة الفشل التام ($k=0$ من القطع) إلى حالة وظيفية ($k \ge 1$ من القطع)، مما يلتقط الجزء الأكثر انحداراً في منحنى استغلال السياق.

2. الآثار المدفوعة بالميزانية مقابل الآثار الجوهرية للتنسيق

• ميزانية 16K: كلا التنسيقين يتناسبان دون تجاوز. يسمح TSCG بحوالي 26 قطعة مقارنة بـ 9 قطع لـ JSON. رغم الزيادة بمقدار 3 أضعاف في سياق الاسترجاع، فإن الفرق في الدقة ضئيل (متوسط $\Delta$EM = -1 pp). وهذا يؤكد أن مكاسب الـ 8K ناتجة بحت عن إعادة تخصيص الميزانية، وليس بسبب تفوق جوهري في التنسيق المضغوط.
• ميزانية 32K: كلا التنسيقين يستوعبان الـ 40 قطعة براحة. أظهرت أربعة من أصل خمسة نماذج أن $\Delta$EM $\le$ 1 pp، مما يؤكد أنه عندما تُزال قيود الميزانية، ليس للتنسيق المضغوط أي تأثير معنوي على الدقة.

3. التحقق الخارجي والتوسع

• HotpotQA: في مجموعة بيانات مستقلة، مكن TSCG من تحقيق زيادة في EM بمقدار +48 نقطة مئوية عند سياق 8K، حيث فشلت مخططات JSON تماماً.
• التوسع للنماذج الرائدة: كشفت الاختبارات باستخدام Claude Sonnet 4 عند سياق 200K أن مخططات JSON تتجاوز الحد عند حوالي 494 أداة، مما يسبب فشلاً تاماً للنظام. بينما ظلت مخططات TSCG تعمل بما يتجاوز 800 أداة، مما وسع النطاق التشغيلي بنسبة 63%.

4. أنماط الفشل والتحليل

• تمييع المشتتات (Distractor Dilution): في النماذج الصغيرة ($\le$8B بارامتر) عند 16K، أدى توفير المزيد من القطع عبر TSCG أحياناً إلى تقليل الدقة. يعزو المؤلفون ذلك إلى "تمييع المشتتات"، حيث تُثقل سعة الانتباه المحدودة بسياق غير ذي صلة، وهو ما يعيد صدى ظاهرة "الضياع في المنتصف" (Lost in the Middle).
• نموذج استغلال السياق: قام المؤلفون بملاءمة نموذج وصفي $C(k) = C_{max}(1 - e^{-\lambda k}) + C_0$، يوضح أن المكسب الهامشي من أول قطعة استرجاع هو الأكبر، مع تناقص العوائد بعد ذلك. وهذا يفسر لماذا يحقق استعادة قطعة واحدة فقط عند 8K مكاسب غير متناسبة في الدقة.

الأهمية والادعاءات

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

• التمكين الفئوي: المساهمة الأساسية هي اكتشاف تأثير "التمكين الثنائي". بدون الضغط، يكون نظام Agentic RAG عند 8K معطلاً بشكل أساسي (أداء يقترب من الصفر)؛ ومع الضغط، يصبح وظيفياً. هذا فرق فئوي بين نظام لا يمكنه العمل ونظام يمكن تحسينه بشكل تكراري.
• الأمانة دون فقدان (Lossless Fidelity): تثبت الدراسة أن ضغط TSCG لا يسبب فقداناً في الدقة من الناحية العملية؛ فعندما تكون ميزانيات السياق كافية (32K)، تعطي المخططات المضغوطة وغير المضغوطة دقة متطابقة، مما يثبت أن الضغط لا يدخل عيوباً في الدقة.
• ضرورة التوسع: مع نمو عدد الأدوات في بيئات الإنتاج (مثل عمليات نشر MCP)، يصبح ضغط المخططات ضرورة عملية لمنع تجاوز السياق، مما يمدد عدد الأدوات القابل للتشغيل بأكثر من 60% حتى في نوافذ السياق الكبيرة.

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