أمازون ويب سيرفسز تعرض كيفية بناء وكلاء الذكاء الاصطناعي على SageMaker واختبار النماذج عبر MLflow

في 27 أبريل 2026، نشرت AWS تفصيلاً عملياً لكيفية تشغيل وكلاء الذكاء الاصطناعي على بنيتها التحتية المُدارة الخاصة بها، وليس فقط على الخدمات المُدارة بالكامل. أظهرت الشركة مزيجاً من Strands Agents SDK و SageMaker AI و Serverless MLflow، حيث يمكن تجميع الوكيل بسرعة، ونشره على نقطة نهاية، ومراقبة سلوكه في الإنتاج ومقارنة عدة متغيرات نموذجية دون تغيير البنية العامة. بالنسبة للفرق التي تعطي الأولوية للتحكم والتكاليف المتوقعة ومتطلبات الأمان، يبدو هذا كمحاولة لتحويل أنظمة الوكلاء من طبقة تجريبية إلى عملية MLOps عادية.

في صميم النهج يوجد Strands Agents SDK، وهو إطار عمل مفتوح المصدر لبناء وكلاء من نموذج وفي النص ومجموعة من الأدوات. في مثال AWS، يعرض أولاً سيناريو أساسي مع نموذج في Bedrock، ثم ينقل نفس الفكرة إلى النماذج التي تعمل في SageMaker AI. النقطة الأساسية هي أن Strands يمكنها العمل مع نقاط نهاية الاستدلال SageMaker كمزود نموذج إذا كانت تدعم واجهة برمجية للتطبيقات لإكمال الدردشة المتوافقة مع OpenAI. يستخدم العرض نسختين من Qwen3 من SageMaker JumpStart — 4B و 8B. يتم نشر الأول كنقطة النهاية الأساسية، وبعدها يحصل الوكيل على الوصول إلى أدوات مثل طلبات HTTP وآلة حاسبة، ويمكنه تنفيذ المهام النموذجية فوق البنية التحتية للنموذج الخاصة به.

لماذا تنقل منطق الوكيل إلى SageMaker إذا كانت هناك واجهات برمجية جاهزة في السوق؟ AWS تراهن على أربع حجج. الأولى — التحكم في البنية التحتية: يمكنك اختيار الحالات والإعدادات والقواعد بدقة للكمون والاتفاقية مستوى الخدمة المطلوبة. الثانية — المرونة مع النماذج: بالإضافة إلى foundation models الجاهزة، يمكنك استخدام المتغيرات المخصصة أو المعدّلة، وكذلك نماذج مفتوحة المصدر. الثالثة — اقتصاديات أكثر قابلية للتنبؤ للأحمال الكبيرة من خلال نقاط النهاية المخصصة وضبط الموارد الدقيق. الرابعة — إطار عمل enterprise مناسب حول الوكلاء: التتبع والإصدار واختبارات A/B والتدقيق، التي تكون مطلوبة ليس في العروض التوضيحية بل في الإنتاج.

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

الجزء الأكثر عملية من المادة هو اختبار A/B بين متغيرات النموذج. يوضح AWS كيفية إرفاق نسختين من الإنتاج بنفس نقطة النهاية، في المثال Qwen3 4B و Qwen3 8B، وتقسيم حركة المرور بينهما بنسبة 50/50 في البداية. بعد ذلك، يمكنك مقارنة الإجابات في البث المباشر أو إنشاء وكيلين منفصلين، كل منهما ينظر إلى متغيره الهدف الخاص.

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

الخلاصة بسيطة: AWS لا تبيع مجرد SDK وكيل آخر، بل خطة هندسية يصبح فيها الوكيل مكوناً منتجاً مُدار. إذا كانت الشركات بحاجة إلى نماذجها الخاصة وحدودها الخاصة وتدقيق إجراءات الوكيل والنشر الحذر للإصدارات الجديدة، فإن مزيج Strands و SageMaker و MLflow يعالج هذا السيناريو بكثير أقرب إلى واقع المؤسسات من العديد من أكوام الديمو السريعة. بالنسبة للسوق، هذا إشارة أخرى على أن الحضور التالي في الذكاء الاصطناعي لم يعد يتعلق فقط بجودة النموذج، بل بجودة البنية التحتية من حوله.