معمارية الأنظمة متعددة الوكلاء: أنماط عملية لوكلاء ذكاء اصطناعي تعمل فعلًا

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

هذا المقال عن المعمارية: كيف يُرتَّب الوكلاء، وكيف يتبادلون المعلومات، وأين يتدخل الإنسان. وإن كنت ما زلت تقرر ماذا تؤتمت، فابدأ بمقال ماذا تؤتمت أولًا.

ما هو النظام متعدد الوكلاء (وما ليس هو)

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

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

أربعة أنماط في معمارية الأنظمة متعددة الوكلاء

معظم الأنظمة التي رأيتها أو بنيتها مزيج من أربعة أشكال.

1. المنسّق والمتخصصون

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

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

2. سلسلة المراحل

يعمل الوكلاء بترتيب ثابت، وكل واحد يأخذ مخرجات السابق: بحث، ثم صياغة، ثم تحرير، ثم تنسيق. لا أحد يقرر الترتيب أثناء التشغيل لأنه جزء من التصميم.

السلسلة متوقعة، وسهلة التتبع، ويمكن قياس كل مرحلة فيها على حدة. استخدمها كلما كان سير العمل نفسه في كل مرة فعلًا. وكثير من مشاريع "الوكلاء المتعددين" كان الأفضل لها أن تكون سلسلة بسيطة.

3. وكلاء متوازيون

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

القاعدة هنا هي العزل. يجب ألا يكتب الوكلاء المتوازون في المكان نفسه. في سير عملي البرمجي، يعمل كل وكيل تنفيذ في git worktree خاص به، حتى تتقدم تذكرتان في الوقت نفسه دون تصادم.

4. المراجع أو الناقد

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

مثال عملي: سلسلة إنتاج فيديو مستقلة

VidForge نظامي الخاص الذي يحوّل موضوعًا إلى فيديو يوتيوب كامل مدته من 10 إلى 15 دقيقة. ويجمع الأنماط الأربعة:

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

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

الحالة المشتركة وتسليم العمل

طريقة تسليم الوكلاء العمل لبعضهم تحدد إن كان النظام قابلًا للتتبع والإصلاح.

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

متى يكون الوكيل الواحد أفضل

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

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

ابدأ بأبسط حل يعمل، وقِسه، ولا تقسّم إلا حيث يقوم وكيل واحد بأكثر مما يجب بوضوح.

أنماط الفشل التي يجب التصميم لها

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

أين يقف الإنسان

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

لنعمل معًا

أصمم الأنظمة متعددة الوكلاء وأبنيها من البداية إلى النهاية، من أدوار الوكلاء وطرق التسليم إلى البرمجيات الجاهزة للإنتاج والسجلات والنماذج المحلية حولها. اطّلع على VidForge وعلى دراسات الحالة الأخرى.

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