الذكاء الاصطناعي الوكيل أم RAG أم سير العمل: كيف تختار

ما الفرق بين الذكاء الاصطناعي الوكيل وRAG وسير العمل؟

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

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

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

كيف نعرّف كل مقاربة تعريفًا دقيقًا؟

التعريفات الغامضة تنتج هندسة غامضة، وهذه التعريفات التي أستخدمها مع الفرق. المحور الحاسم هو الاستقلالية: من يختار المسار.

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

كيف نختار بين سير العمل وRAG والوكيل؟

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

ما القواعد التي أنصح بها للبداية؟

تنبع هذه القواعد من مبدأ واحد: كل درجة إضافية من الاستقلالية تمنحك مرونة وتكلّفك قابلية التوقع. لا تدفع هذا الثمن إلا إذا فرضته المشكلة، ولا تعتمد في قرارك على حماسة الفريق للتقنية الأحدث.

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

ماذا علّمتني منصة DILA عن RAG وسير العمل الوكيل؟

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

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

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

وهذا يفسّر لماذا أعتقد أن سؤال الاختيار بين المقاربات لا ينفصل عن سؤال المنصة: فحين تكون المكوّنات المشتركة جاهزة، يصبح الانتقال من مساعد RAG إلى تجربة وكيلة قرارًا قابلًا للقياس والتراجع، لا مغامرة تبدأ من الصفر.

متى يكون النظام متعدد الوكلاء مبرَّرًا؟ مثال NOVA

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

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

وتنبيه بشأن الحالة. NOVA وORBIT وFORGE مستودعات عامة في طور تجريبي، وأصف تصميمها لا ضمانًا للإنتاج. وما أستطيع تأكيده كحقيقة هو أن NOVA Suite يستخدمها 800 موظف في Devoteam.

كيف نكسب الاستقلالية عبر التقييم؟

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

في RAG استخدمت DILA أربعة مقاييس: الأمانة (faithfulness) وملاءمة الإجابة ودقة السياق واسترجاع السياق. وفي الوكلاء يصف الملف التعريفي لـ FORGE سيناريوهات وقواعد حتمية وقضاة من النماذج اللغوية ومراجعة بشرية وتجارب مقارنة بين خط أساس ومرشّح. والمبدأ واحد: يجب أن تعود الدرجة إلى معيار وإلى خطوة.

أدرج الحالات التي يجب أن يرفض فيها النظام أو يصعّد الأمر، لا الحالات التي ينبغي أن ينجح فيها فقط. وقِس الكلفة، لأن الاستقلالية تميل إلى زيادة استدعاءات النموذج. وفي DILA أدى تحسين خطوط المعالجة وإعادة الاستخدام إلى خفض كلفة الطلب الواحد إلى الذكاء الاصطناعي بنسبة 30%.

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

ماذا قسته وماذا رأيت؟

تأتي هذه الأرقام من دراسة حالة DILA وتخص مقاربة المنصة: مكوّنات قابلة لإعادة الاستخدام وتقييم وتنسيق خاضع للحوكمة. وهي ليست مقارنة بين سير العمل وRAG والوكلاء، وليست لديّ مقارنة كهذه لأقدّمها.