تطوير وكلاء الذكاء الاصطناعي في الإمارات: دليل المؤسّسات

ما هو وكيل الذكاء الاصطناعي، وما الفرق بينه وبين روبوت المحادثة؟

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

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

والآلية التي تتيح ذلك هي استخدام الأدوات (tool use)، أو ما يُسمّى أحياناً استدعاء الدوال (function calling) [3]. فالنموذج اللغوي لا ينفّذ الشيفرة بنفسه، بل يعرّف المطوّر مجموعة من الأدوات، لكل منها اسم، ووصف يقرؤه النموذج ليقرّر هل يستخدمها، ومخطّط منظّم للمدخلات (input schema). وحين يقرّر النموذج أن ثمّة إجراءً مطلوباً، يولّد استدعاءً منظّماً للأداة، فتتلقّاه طبقة التنسيق (orchestration)، وتشغّل الدالة التي يشير إليها (استعلام قاعدة بيانات، أو استدعاء API، أو عملية حسابية)، ثم تعيد النتيجة إلى سياق النموذج. وعندها يقرّر النموذج خطوته التالية.

متى يكون وكيل الذكاء الاصطناعي خياراً مجدياً للمؤسّسات في الإمارات؟

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

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

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

ما المكوّنات الخمسة الأساسية لوكيل ذكاء اصطناعي في بيئة الإنتاج؟

يتكوّن كل وكيل يعمل في بيئة الإنتاج من المكوّنات الخمسة نفسها. وقد يختلف وزن كل مكوّن من مهمة إلى أخرى، لكن لا يمكن الاستغناء عن أي منها.

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

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

وتعمل الذاكرة على ثلاث طبقات. فالذاكرة قصيرة المدى هي نافذة السياق (context window)، أي كل ما يراه النموذج في اللحظة الحالية، من وصف المهمة ومخرجات الأدوات وأي سجلّ من الجلسة الجارية. والذاكرة طويلة المدى قاعدة بيانات متّجهات (vector database) تبقى محفوظة بين الجلسات، تُحوَّل فيها المعارف ذات الصلة إلى تمثيلات متّجهية (embeddings) وتُخزَّن، ثم تُسترجع عند الاستعلام وتُضاف إلى السياق، وهذا هو نمط RAG نفسه على مستوى الوكيل [2]. أما ذاكرة الأحداث (episodic memory) فسجلّ لعمليات التشغيل السابقة يرجع إليه الوكيل عند الحاجة، وهي مفيدة للوكلاء الذين يتعيّن أن يختلف سلوكهم بحسب ما جرى في جلسة سابقة.

وطبقة التنسيق هي التي تتحكّم في تسلسل التنفيذ، ويمكن تمثيل سير عمل الوكيل على هيئة مخطّط موجَّه (directed graph)، عُقَده استدعاءات النموذج وتنفيذ الأدوات، وحوافّه تدفّق التحكّم (control flow) بينها. وفي هذه الطبقة أيضاً تُنفَّذ آليات المقاطعة (interrupts) ونقاط حفظ الحالة (checkpoints)، وهي ما يتيح تدقيق عمل الوكيل وإيقافه مؤقّتاً في أثناء التنفيذ.

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

كيف تصمّمون وكيل ذكاء اصطناعي لبيئة خاضعة للتنظيم في الإمارات؟

تفرض البيئة التنظيمية في الإمارات أربعة قيود على التصميم يجب معالجتها قبل أن يتعامل الوكيل مع البيانات الفعلية في بيئة الإنتاج.

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

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

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

ورابعها التصميم على مبدأ التوقّف الآمن (fail-closed). فالوكيل الذي يبلغ حالة لم يُصمَّم للتعامل معها ينبغي أن يتوقّف ويصعّد الأمر إلى إنسان، لا أن يحاول تدارك الموقف بالتخمين. أما المضيّ في التنفيذ رغم الشكّ (fail-open)، أي اتّخاذ إجراء قد يكون خاطئاً في ظل عدم اليقين، فهو الأعلى خطراً من السلوكين في الخدمات المالية والرعاية الصحية وأي بيئة خاضعة للتنظيم. لذلك نجعل التوقّف الآمن السلوك الافتراضي في كل وكيل نطوّره للبيئات الخاضعة للتنظيم في الإمارات، ويجب تحديد مسار التصعيد واختباره قبل الإطلاق.

ما خطوات تطوير وكيل الذكاء الاصطناعي، وبأيّ ترتيب؟

يمرّ تطوير أي وكيل بخمس خطوات، والترتيب بينها مهمّ.

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

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

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

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

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

كم يكلّف تشغيل وكيل الذكاء الاصطناعي، وكيف تتحكّمون في هذه التكلفة؟

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

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

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

متى لا ينبغي لكم تطوير وكيل ذكاء اصطناعي؟

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

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

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

يندرج هذا المقال ضمن عملنا في تطوير وكلاء الذكاء الاصطناعي، ويعكس منهجية التخطيط التي تقوم عليها طريقة عملنا.

اقرؤوا أيضاً: تطوير تطبيقات التقنية المالية في الإمارات: دليل عملي للامتثال.

أبرز النقاط

• وكيل الذكاء الاصطناعي ليس روبوت محادثة: فهو يعتمد في الاستدلال على نموذج لغوي، فيخطّط وينفّذ إجراءات متعدّدة الخطوات ويتكيّف حين تتغيّر النتائج، وهي قدرات تتجاوز بكثير ما يستطيعه روبوت محادثة يسير وفق نصّ معدّ سلفاً [1].
• يحتاج كل وكيل في بيئة الإنتاج إلى خمسة مكوّنات: نموذج لغوي كبير أساساً له، ومجموعة أدوات محدّدة النطاق، وطبقة ذاكرة (تشمل RAG للاسترجاع طويل المدى [2])، وآلية تنسيق، ونقاط اعتماد بشري قبل أي إجراء لا رجعة فيه.
• إقامة البيانات في الإمارات والامتثال لقانون PDPL (المرسوم بقانون اتحادي رقم 45 لسنة 2021) قيدان على التصميم منذ البداية، لا مسألتان تُعالجان لاحقاً: فالبيانات الشخصية التي تدخل نافذة سياق الوكيل يجب أن تخضع للحوكمة بالدقّة نفسها التي تُطبَّق في أي نظام معالجة آخر.
• التوقّف الآمن (fail-closed) هو السلوك الافتراضي الصحيح للوكلاء في البيئات الخاضعة للتنظيم في الإمارات: فحين لا يتيقّن الوكيل، يصعّد الأمر إلى إنسان بدل أن يتصرّف.
• حدود المهمة المكتوبة والمتّفق عليها قبل كتابة أي شيفرة هي أوثق ما يُستدلّ به على ما إذا كان الوكيل سيحقّق قيمة فعلية أو سيتصرّف على نحو غير متوقّع في بيئة الإنتاج.

المصادر

1. Intelligent agent - Wikipedia (en.wikipedia.org)
2. Retrieval-augmented generation - Wikipedia (en.wikipedia.org)
3. Large language model - Wikipedia (en.wikipedia.org)