AWS تعرض كيفية تقييم وكلاء الذكاء الاصطناعي بثلاثة أوضاع: من التصحيح إلى الإنتاج

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

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

حدّد أولاً ما يُعدّ عملاً منجزاً

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

لنعد إلى الاسترداد. هنا تفيد ثلاثة فحوص مستقلة. يقيّم GoalSuccessRate تحقق الهدف عبر الجلسة كاملة. ويساعد ConversationCompleteness من DeepEval على ملاحظة السؤال المنسي عن الاشتراك. ويتحقق PIILeakage مما إذا كان الوكيل قد كشف بيانات شخصية. والاسترداد الناجح في حد ذاته لا يقول شيئاً عن النتيجتين الأخريين.

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

مجموعة فحوص واحدة لثلاثة أوضاع

تتوفر في AgentCore مُقيِّمات مدمجة من AWS، وفحوص مُدارة من DeepEval وAutoEval، إضافة إلى خيارات مخصصة. تغطي المدمجة جودة الإجابات وإنجاز المهام والعمل مع الأدوات وسلوكيات أخرى. وفي الوضع المُدار للفحوص الخارجية تستضيف الخدمة الشيفرة وتختار نموذج التقييم وتنفّذ الطلبات على بنيتها التحتية. أما الخيارات المخصصة فتتيح تغيير النموذج والتعليمات ومعايير التقييم.

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

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

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

أين تنتهي فائدة التقييم الآلي

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

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

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