AWS تكشف عن خمسة أنماط لتقييم وكلاء الذكاء الاصطناعي المتقدمين

نشرت AWS وLangSmith دليلًا مفصلًا لتقييم وكلاء الذكاء الاصطناعي المتقدمين (deep agents)، وهي أنظمة مستقلة تحل المهام متعددة الخطوات بنفسها، فتستنتج وتتخذ القرارات خلال سير العمل.

خمسة معايير للتقييم

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

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

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

الاختبار دون اتصال والمراقبة المباشرة

وصفت AWS نهجًا من مستويين: رقابة قبل الإطلاق ورقابة بعده.

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

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

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

وكيل text-to-SQL كمثال متكامل

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

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

نُشر الوكيل على Amazon Bedrock، وهي خدمة سحابية مُدارة للعمل مع النماذج اللغوية الكبيرة. تتولى Bedrock توسيع البنية التحتية، والتحمّل ضد الأعطال، والامتثال لمعايير الأمان. يركّز المطوّر على منطق الوكيل، بينما تضمن Bedrock الموثوقية والأداء.

ماذا يعني ذلك

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

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