وكلاء LLM ليسوا سوى أنظمة موزّعة

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

إن بدا هذا مألوفاً، فهو كذلك فعلاً. يدرس باحثو الأنظمة الموزعة تنسيق العمليات المستقلة منذ 40 عاماً. وأنظمة وكلاء LLM المتعددة تعيد اكتشاف مشكلات حلّها مجتمع الأنظمة الموزعة (أو أثبت استحالة حلها) قبل عقود، انطلاقاً من الصفر. فهم هذه أوجه التشابه يوفر عليك إعادة اختراع الحلول، ويجنبك بناء أنظمة تفشل بطرق متوقعة ومفهومة جيداً.

ضريبة التنسيق

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

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

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

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

مشكلة الإجماع

عندما يعمل عدة وكلاء على المهمة نفسها، يحتاجون إلى الاتفاق على أمور. ما المتطلبات؟ ما النهج المناسب؟ هل هذا التنفيذ صحيح؟ في الأنظمة الموزعة تُعرف هذه بمشكلة الإجماع، وهي صعبة بشكل مثبت. تُظهر نتيجة FLP أن الإجماع الحتمي مستحيل في نظام غير متزامن حتى مع عملية معطوبة واحدة.

وكلاء LLM أسوأ من العمليات الموزعة التقليدية في الإجماع لأنهم غير حتميين. اسأل الوكيل نفسه السؤال نفسه مرتين وقد تحصل على إجابتين مختلفتين. قد يختلف وكيلان يراجعان الشيفرة نفسها حول صحتها. ووكيل 'المنسّق' المكلّف بحسم الخلاف قد يرمي عملة معدنية.

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

أنماط فشل مألوفة

تفشل أنظمة متعددة الوكلاء بطرق سيتعرف عليها مهندسو الأنظمة الموزعة فوراً.

• الأعطال المتتالية. ينتج الوكيل A مخرجات سيئة. يُنتج الوكيل B، معتمداً على مخرجات A، نتائج أسوأ. ثم يراجع الوكيل C عمل B فلا يلتقط الخطأ الأصلي لأنه ورث الافتراضات الخاطئة. هذا المكافئ في الأنظمة الموزعة لانتشار الأخطاء: مدخلات سيئة تنتج مخرجات سيئة، وتتضخم مع كل مرحلة.
• الجمود (Deadlock). ينتظر الوكيل A مخرجات الوكيل B ليتابع، وينتظر الوكيل B ملاحظات الوكيل A ليتابع. لا يتقدم أيٌّ منهما. عملياً يظهر هذا كحلقات لا نهائية يتبادل فيها الوكلاء العمل ذهاباً وإياباً دون أن يتقاربوا إلى نتيجة.
• الدماغ المنقسم (Split brain). يعمل وكيلان على مهمتين مترابطتين فيكوّن كل منهما تصوراً مختلفاً للمشكلة. يفترض أحدهما أن الـ API يعيد JSON، ويفترض الآخر أنه XML. مخرجاتهما صحيحة كلٌّ على حدة، لكنها غير متوافقة معاً.
• قطيع الأفيال (Thundering herd). ينشر وكيل المنسّق المهام على عدة وكلاء في الوقت نفسه. فيضربون الـ API نفسه، ويستنفدون حد المعدل (rate limit) نفسه، أو يحاولون تعديل الملف نفسه. تنافس على الموارد لم يكن وكيل واحد ليواجهه أبداً.

متى تفيد الأنظمة المتعددة الوكلاء فعلاً؟

يسري التشابه مع الأنظمة الموزعة في الاتجاهين. فللأنظمة الموزعة فوائد حقيقية لمشكلات محددة، والأنظمة متعددة الوكلاء كذلك، عندما تُستخدم لمشكلات تستفيد فعلاً من التجزئة.

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

وجهات نظر متنوعة. طلب مراجعة الشيفرة نفسها من ثلاثة وكلاء بموجّهات نظام (system prompts) مختلفة يمكن أن يكشف مشكلات تفوتها مراجعة واحدة. هذا نمط التكرار (Redundancy)، أشبه بوجود عدة مراجعين على طلب دمج (PR). الثمن ثلاثة أضعاف الحوسبة، لكن التغطية أوسع.

التخصص مع واجهات نظيفة. وكيل ترجمة يأخذ نصاً ويعيد نصاً مترجماً له واجهة نظيفة. ووكيل تلخيص يأخذ مستنداً ويعيد ملخصاً له واجهة نظيفة. تركيب هذين الوكيلين (ترجم ثم لخّص) يعمل جيداً لأن الواجهة بينهما بسيطة. المكافئ في الأنظمة الموزعة: الخدمات المصغرة ذات الـ APIs المحددة جيداً تعمل أفضل من الخدمات المصغرة ذات الواجهات المعقدة والثرثارة.

دروس من الأنظمة الموزعة

إن كنت تبني أنظمة وكلاء LLM متعددة، فعقود من حكمة الأنظمة الموزعة تنطبق عليك مباشرة.

1. فضّل عدداً أقل من الوكلاء الأقدر على كثير من المتخصصين. كما تتفوق البنية المونوليثية المصممة جيداً على بنية خدمات مصغرة مصممة بسوء، يتفوق وكيل واحد قادر مع موجّه جيد على فريق من الوكلاء الضيقي التخصص في معظم المهام. أضف وكلاء جدداً فقط بعد أن تثبت أن وكيلاً واحداً لا يستطيع تحمّل العبء.
2. حدّد واجهات واضحة بين الوكلاء. يجب أن تكون مدخلات كل وكيل ومخرجاته محددة بوضوح. عمليات التسليم الغامضة ('اكتشف ما وجده الباحث ونفّذه') تؤدي إلى فقدان السياق وسوء الفهم. عقود بيانات منظمة بين الوكلاء أفضل من النص الحر.
3. اجعل الوكلاء idempotent. إن فشل وكيل في منتصف العمل، يجب أن تتمكن من إعادة تشغيله بالمدخل نفسه والحصول على نتيجة صحيحة. يتطلب هذا وكلاء بلا حالة مخفية، ولا يُحدثون آثاراً جانبية قبل التأكد من صحة مخرجاتهم.
4. أضف قابلية الرصد (Observability). سجّل كل رسالة بين الوكلاء، وكل قرار، وكل فشل. عندما ينتج نظام متعدد الوكلاء مخرجات خاطئة، تحتاج إلى تتبّع الخطأ إلى الوكيل الذي اتخذ القرار الخاطئ ولماذا. بدون الرصد يصبح التصحيح تخميناً.
5. صمّم للفشل الجزئي. يمكن لأي وكيل أن يفشل، أو يُنتج مخرجات عديمة الفائدة، أو ينتهي وقته. يجب أن يتعامل النظام مع ذلك بسلاسة: بإعادة المحاولة، أو بالعودة إلى نهج أبسط، أو بطلب تدخل بشري. لا تفترض أبداً أن جميع الوكلاء سينجحون.

الحقيقة غير المريحة

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

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