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