التقييم والاختبار للوكلاء الذكاء الاصطناعي

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

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

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

لماذا لا يكفي الاختبار التقليدي

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

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

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

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

بناء مجموعات السيناريوهات الذهبية، وليس مجرد حالات عرض توضيحي

أساس التقييم السليم هو مجموعة السيناريوهات الذهبية (golden scenario set): مجموعة من السيناريوهات التمثيلية التي تُستخدم بشكل متكرر لاختبار الوكيل قبل الإصدار وبعد التغييرات. هذه ليست مجرد قائمة بأسئلة العرض التوضيحي. يجب أن تعكس المجموعة الذهبية واقع العمليات.

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

ثانيًا، الحالات الحدية (edge cases): أدرج حالات نادرة ولكنها مهمة، مثل البيانات غير المكتملة، أو المستندات المتعارضة، أو المدخلات الغامضة، أو مجموعات الظروف التي تجعل الوكيل عرضة للخطأ. غالبًا في هذه الحالات يفشل الوكيل عند دخوله مرحلة الإنتاج.

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

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

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

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

أبعاد التقييم: الصحة، والسلامة، والموثوقية، والملاءمة التجارية

لتجنب غموض التقييم، تحتاج الشركات إلى فصل أبعاد التقييم. الأبعاد الأربعة التالية هي الأكثر فائدة للمؤسسات.

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

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

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

يقيم الملاءمة التجارية (Business Fitness) ما إذا كان الوكيل مناسبًا لنموذج التشغيل الحقيقي. يمكن أن يكون الوكيل صحيحًا من الناحية الفنية، وآمنًا من حيث السياسة، ومتسقًا إلى حد ما، لكنه يظل غير مناسب إذا لم يتوافق مع العمليات التجارية. يقيم الملاءمة التجارية ما إذا كان مستوى التصعيد معقولاً، وما إذا كان مخرج الوكيل يساعد المراجع حقًا، وما إذا كان وقت الدورة قد تحسن، وما إذا كانت إعادة العمل قد انخفضت، وما إذا كان الوكيل متوافقًا مع إجراءات التشغيل القياسية (SOP)، وقائمة انتظار الموافقة، وسعة الفريق. قد يكون وكيل استرداد الأموال دقيقًا، ولكن إذا ظل 80% من الحالات تخضع للمشرف بسبب تصميم حد أعلى متحفظ للغاية، فإن ملاءمته التجارية منخفضة. المشكلة ليست في النموذج وحده، بل في تصميم نموذج التشغيل.

يجب الجمع بين التقييم الآلي والمراجعة البشرية

تحتاج الشركات إلى تقييم آلي للسرعة، لكن لا ينبغي أن تتوقف عنده.

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

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

بدأت العديد من الفرق في استخدام نموذج آخر لتقييم جودة مخرجات الوكيل. يمكن أن يكون هذا مفيدًا للفرز الأولي، أو تجميع الأخطاء، أو التسجيل التقريبي. ولكن بالنسبة للمجالات الحرجة، لا ينبغي أن يكون تقييم LLM-as-judge هو الأساس الوحيد للموافقة النهائية. السبب بسيط: يمكن أن يكون متحيزًا تجاه الأسلوب اللغوي، وليس صحة الأعمال؛ يمكن أن يفشل في فهم السياسات الداخلية؛ وهو لا يتحمل المساءلة التشغيلية. النمط الأكثر صحة هو التقييم الآلي للانحدار السريع، وتقييم LLM-as-judge للمساعدة في الفرز أو تحديد أولويات المراجعة، ومراجعة الخبراء البشريين للموافقة النهائية على المجالات الهامة، ومراقبة الإنتاج للتحقق من صحة الأداء الحقيقي بعد التشغيل المباشر.

اختبار استدعاءات الأدوات: حيث تظهر المخاطر الحقيقية غالبًا

في الأنظمة العاملة بالوكلاء، استدعاء الأداة (tool call) هو النقطة التي يبدأ فيها الوكيل بلمس واقع المؤسسة. لهذا السبب، يجب أن يكون اختبار استخدام الأداة أكثر انضباطًا بكثير من مجرد التأكد من إمكانية استدعاء API.

يجب اختبار كل أداة مهمة في عدة ظروف: بيئة محاكاة (mock environment) للتحقق من التدفق الأساسي، ومعاملة في بيئة اختبارية (sandbox transaction) لرؤية التأثير من البداية إلى النهاية دون لمس الإنتاج، وفشل الإذن (permission failure) للتأكد من أن الوكيل يتفاعل بأمان عند رفض الوصول، وانتهاء المهلة (timeout) لمعرفة ما إذا كان الوكيل يعيد المحاولة أو يتراجع أو يصعد بشكل صحيح، واستجابة مشوهة (malformed response) لاختبار المتانة تجاه استجابات API غير الكاملة.

في مشتريات ERP، إذا فشل API لبيانات المورد الرئيسية، لا ينبغي للوكيل تخمين حالة المورد. يجب أن يتوقف أو يصعد. في CRM لخدمة العملاء، إذا كانت بيانات الاستحقاق غير كاملة، لا ينبغي للوكيل أن يعد بتعويض. في عمليات تقنية المعلومات، إذا أعادت أداة دليل الإجراءات نتيجة غامضة، يجب على الوكيل الامتناع عن الإجراءات اللاحقة.

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

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

بوابات الإصدار: ليس كل الوكلاء مسموحًا لهم بدخول الإنتاج بنفس المعايير

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

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

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

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

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

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