أظهرت AWS كيفية بناء محرك ذكاء اصطناعي لاختبارات A/B على Amazon Bedrock و DynamoDB

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

كيف يتغير اختبار A/B

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

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

كيف يعمل المعمار

تقترح AWS بناء محرك كهذا على أربعة مكونات رئيسية. يتعامل Amazon Bedrock مع منطق LLM، بينما يدير Amazon ECS الخدمة الموزعة التي تقبل الطلبات من التطبيق، وتخزن Amazon DynamoDB حالة التجارب والنتائج، وتعمل Model Context Protocol كطبقة لنقل الأدوات والسياق المنظم إلى النموذج.

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

• Amazon Bedrock — يحلل السياق ويقترح متغير عرض
• Amazon ECS — يشغل خدمة التنسيق و API للتجارب
• Amazon DynamoDB — يخزن التكوينات والتعيينات والمقاييس
• MCP — يصف النماذج والبيانات والإجراءات المتاحة
• التطبيق — يرسل سياق المستخدم ويستقبل قراراً

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

أين تكمن الفوائد والمخاطر

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

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

ما الذي يعنيه هذا

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