ملخص تقني: تحسين مساحة العمل (Workspace Optimization)

بيان المشكلة

تواجه الوكلاء الحديثون المبنيون على النماذج اللغوية الكبيرة (LLMs) في الطليعة عائقاً حرجاً: لا يمكنهم تكييف أوزانهم الداخلية أثناء "الحلقة" (episode). فعملية الضبط الدقيق (Fine-tuning) بطيئة جداً للتكيف عبر الإنترنت في حلقة واحدة، وفي العديد من سيناريوهات النشر (مثل النماذج القائمة على واجهة برمجة التطبيقات API أو التتبعات الحساسة للخصوصية)، يكون الوصول إلى الأوزان غير متاح. نتيجة لذلك، يظل النموذج ثابتاً، ومع ذلك يجب على الوكيل أن يتعلم حل مهام معقدة متعددة الخطوات حيث تكون الأهداف والقواعد مخفية داخل البيئة.

يحدد البحث فجوة في نماذج التعلم الوكيل القياسية. يعتمد التعلم المعزز التقليدي (RL) على تحديث السياسة أو دالة القيمة (فضاء الأوزان) بناءً على إشارات الخسارة. ومع ذلك، عندما تكون الأوزان مجمدة، يصبح "الحالة القابلة للتدريب" غير محددة. يجادل المؤلفون بأن مساحة عمل الوكيل — وهي الركيزة الخارجية المهيكلة التي يقرأ منها، ويكتب فيها، ويختبر من خلالها — يجب أن تكون هي موضوع التكيف. وهذا أمر وثيق الصلة باختبارات مثل ARC-AGI-3، حيث يجب على الوكلاء اكتشاف آليات اللعبة، والأهداف، والديناميكيات من خلال التفاعل ضمن ميزانية إجراءات صارمة، دون بيانات سابقة (offline data) أو القدرة على الرجوع عن الخطوات.

المنهجية: تحسين مساحة العمل (Workspace Optimization)

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

• القطع البرمجية (Artifacts) بدلاً من البارامترات.
• الأدلة (Evidence) بدلاً من بيانات التدريب.
• الأمثلة المضادة (Counterexamples) بدلاً من دوال الخسارة.
• التغذية الراجعة النصية (Textual feedback) بدلاً من التدرجات (gradients).

الحالة القابلة للتدريب

يتم نمذجة الوكيل كزوج $(M, H)$، حيث $M$ هو نموذج لغوي مجمد و $H$ هو "حامل" (harness) يوفر أدوات وبيئة تجريبية (sandbox). تتكون مساحة العمل $W_t$ عند الخطوة $t$ من:

1. البرامج ($P_t$): قطع برمجية قابلة لإعادة الاستخدام والتنفيذ (مثل: محللات الملاحظات، محاكيات الديناميكيات، الاستراتيجيات).
2. السجلات ($L_t$): الملخصات، والفرضيات، والمرشحين المستبعدين، والأسئلة غير المحلولة.
3. بيانات التتبع ($D_t$): مجموعة بيانات "إلحاق فقط" (append-only) للملاحظات، والإجراءات، والمكافآت، والأمثلة المضادة.

تعمل حلقة التعلم كما يلي:

1. الإجراء والتنبؤ: يقرأ الوكيل $W_t$ و $D_t$ لاختيار الإجراء $a_t$. ويلتزم بتنبؤ (على سبيل المثال: "التحرك لليسار سيؤدي إلى الحالة $z_{t+1}$").
2. التقييم: عند تلقي الملاحظة التالية $o_{t+1}$، يقوم "الحامل" بمقارنة التنبؤ بالواقع.
3. التغذية الراجعة والتوجيه: إذا فشل التنبؤ، فإن الخطأ ليس قيمة عددية للخسارة، بل هو مثال مضاد يتم توجيهه إلى القطعة البرمجية (الواجهة) المسؤولة عن الفشل. هذا يحل مشكلة "تخصيص الائتمان" (credit assignment) من خلال معالجة أي قطعة برمجية يجب تعديلها بدلاً من مقدار التحديث المطلوب في الوزن.
4. الإصلاح والرجوع (Regression): يقوم الدور المسؤول بتعديل القطعة البرمجية الخاصة به (مثل تصحيح دالة Python). ومن المهم أن يحافظ "الحامل" على مجموعة اختبار الرجوع ($R_t$) من الانتقالات السابقة. يتم إعادة تشغيل التصحيح الجديد مقابل هذه المجموعة لضمان عدم كسر الحالات التي تم حلها سابقاً قبل قبوله.

بنية DREAMTEAM

يُجسد المؤلفون هذا الإطار في DREAMTEAM، وهو حامل متعدد الوكلاء لـ ARC-AGI-3. يقوم النظام بتفكيك الوكيل إلى ستة أدوار، يمتلك كل منها "سطحاً" (فتحة نوعية) محدداً في مساحة العمل:

• المراقب (Observer): يحلل الملاحظات الخام إلى حالة مهيكلة ($z_t$) ويمتلك منطق العرض (rendering logic).
• المحاكي (Simulator): يتتبع الحالة المخفية ($h_t$) ويمتلك نموذج الديناميكيات (التنبؤ بالحالات التالية).
• المستكشف الاستقرائي (Inductive Explorer - IE): يدير مكتبة من الاستراتيجيات والأهداف الفرعية القابلة لإعادة الاستخدام.
• المستكشف الاستنتاجي (Transductive Explorer - TE): يقترح عمليات استقصاء لجمع المعلومات عندما يكون نموذج العالم غير ناضج.
• الناقد (Critic): يدقق في القطع البرمجية، ويوجه حالات الفشل إلى مالكيها، ويرصد حالات التراجع (regressions).

3. قائد الفريق (Team Leader - TL): يفصل في المقترحات ويعتمد الإجراء النهائي.

يستخدم النظام حلقة "الالتزام ثم التنبؤ الرجعي" (commit-then-retrodict). يلتزم المحاكي ببرنامج ديناميكيات؛ وإذا تعارضت الملاحظة التالية مع التنبؤ، يقوم المحاكي بتصحيح الكود. يضمن الناقد أن التصحيحات متسقة مع الأدلة السابقة عبر مجموعة اختبار الرجوع. في بداية اللعبة، يفضل النظام عمليات الاستقصاء (TE) لتقليل عدم اليقين؛ ومع استقرار نموذج العالم، ينتقل التحكم إلى التخطيط القائم على النموذج (IE/TL).

المساهمات الرئيسية

1. إطار تحسين مساحة العمل: صياغة رسمية لتكييف الوكلاء ذوي النماذج المجمدة عن طريق تحرير مساحة عمل من القطع البرمجية النوعية. يعيد هذا الإطار صياغة تخصيص الائتمان كقرار تحديد عنوان (أي قطعة برمجية يجب تعديلها) بدلاً من تحديث التدرج.
2. DREAMTEAM: تنفيذ متعدد الوكلاء لهذا الإطار، يتميز ببنية مستوحاة من DreamerV3 حيث تمتلك الأدوار مسؤولية الملاحظة، والديناميكيات، والاستراتيجية، والاستقصاء، والنقد، والتحكيم.
3. أداء فعال ومتقدم: في مجموعة ARC-AGI-3 العامة المكونة من 25 لعبة، حقق DREAMTEAM نسبة 38.4% RHAE (كفاءة إجراءات الإنسان النسبية)، متفوقاً على خط الأساس المطابق للبروتوكول البالغ 36%. والجدير بالذكر أنه حقق ذلك باستخدام 31% أقل من إجراءات البيئة لكل لعبة (444 مقابل 643).

النتائج

• الأداء: بمتوسط حسابي عبر تشغيلين مستقلين، وصل DREAMTEAM إلى 38.4% RHAE في مجموعة ARC-AGI-3 العامة، مقارنة بـ 36.08% لخط الأساس Agentica SDK من Symbolica.
• الكفاءة: تطلب النظام عدداً أقل بكثير من الإجراءات لحل المستويات. في المستويات التي تم حلها بنجاح، بلغ متوسط DREAMTEAM 54.1 إجراءً لكل مستوى مقابل 100.1 لخط الأساس.
• ميزانية الإجراءات: يظل النظام متقدماً على المرجع البشري المطابق للميزانية خلال أول ~5 ساعات من تشغيل مدته 24 ساعة، رغم أن الإنسان يتفوق في النهاية بسبب قدرات النقل عبر المستويات (cross-level transfer) الأقوى التي يعيد النظام بناءها عند كل انتقال.

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

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

يؤكد المؤلفون أن نتائجهم مقيدة بميزانيات الوقت والتكلفة بدلاً من حدود ذكاء النظام. ويشيرون إلى أن المنهجية مصممة للإعدادات التفاعلية حيث يكون النموذج ثابتاً ويجب أن يحدث التعلم من خلال مساحة العمل. لا يدعي البحث حل جميع تحديات ARC-AGI-3 أو التعميم على جميع المجالات التفاعلية دون مزيد من البحث، ولكنه يضع مساراً قابلاً للتطبيق لـ "التكيف في وقت الاختبار" (test-time adaptation) يتجنب الحاجة إلى تحديثات الأوزان أو بيانات التدريب خارج الخط (offline).

يتميز العمل عن طرق التكيف السابقة في وقت الاختبار (مثل بنوك الحالات أو الكود ذاتي الكتابة) باستخدام قطع برمجية مسماة ونوعية لتوجيه الفشل، مما يتجنب مشكلة تحديد المسؤول عن الفشل، وعبر فرض فحوصات الرجوع لضمان الاتساق مع الأدلة التاريخية.