أنت المحلل المسؤول عن تجربة ميزة تتعلق بشاشة جديدة لتهيئة المستخدمين (onboarding screen). يطلب منك مدير المنتج اتخاذ قرار بالمضي قدماً أو التوقف بحلول يوم الجمعة، وذلك بناءً على نتائج اختبار “A/B” استمر لمدة 14 يوماً وشمل 240,000 مستخدم مؤهل، تم تقسيمهم بالتساوي (بنسبة 50/50). تتوفر لديك بيانات الأحداث في جدول (مثل experiment_events) يحتوي على سجل واحد لكل مستخدم يومياً، وتتضمن مفاتيح تعريفية مثل user_id (معرف المستخدم) وdate (التاريخ) وvariant (نوع المتغير/النسخة)، بالإضافة إلى مؤشرات النتائج مثل activated_7d (التفعيل خلال 7 أيام).
يمكن للذكاء الاصطناعي تسريع سير عملك في هذه الحالة، لكنه لا يملك سلطة اتخاذ القرار نيابة عنك؛ فأنت المسؤول عن أي فشل لاحق إذا أدى طرح الميزة إلى تراجع معدل الاحتفاظ بالمستخدمين نتيجة لخطأ في تعريف مقياس ما، أو استبعاد فئة معينة، أو مخالفة لأحد الافتراضات. لذا، تعامل مع الذكاء الاصطناعي كأداة لتوليد مسودات الملخصات والأكواد البرمجية وقوائم التحقق، التي يتعين عليك مراجعتها ومطابقتها مع البيانات وتصميم التجربة الخاص بك.
استكشف المراحل الرئيسية لهذه العملية.
يُعد النموذج اللغوي الكبير (LLM) نموذجاً نصياً يولد تكملات منطقية للنصوص بناءً على المدخلات التي تقدمها. وفي سياق العمل على التجارب، يعني هذا قدرة النموذج على صياغة خطط التحليل، وكتابة الأكواد البرمجية، وتلخيص النتائج، حتى وإن كان مخطئاً؛ إذ غالباً ما يقدم معلوماته بأسلوب يوحي بالثقة التامة. أما المطالبة (Prompt) فهي مجموعة التعليمات والسياق التي تزود بها النموذج؛ فإذا كانت مطالبتك غامضة، فإنك تدفع النموذج لملء الفجوات بالتخمينات بدلاً من الاعتماد على الأدلة.
عندما يكتب النموذج كود التحليل، فإننا نطلق على ذلك توليد الكود (Code Generation). ومع ذلك، يظل لزاماً عليك تشغيل الكود وفحصه والتحقق من توافقه مع تصميم تجربتك. وعندما يختلق النموذج تفاصيل لا تدعمها مجموعة البيانات أو سجلات العمليات لديك، فإن ذلك يُعرف بـ الهلوسة (Hallucination). وفي اختبارات “أ/ب” (A/B testing)، تظهر هذه الهلوسة في صور متعددة، مثل اختلاق أحجام للعينات، أو استخدام لغة تشير إلى علاقة سببية دون مبرر، أو اختيار اختبار يفترض ضمنياً (ودون تصريح) التوزيع الطبيعي للبيانات.
يشير مصطلح استخدام الأدوات (Tool use) إلى قدرة النموذج على استدعاء أدوات معتمدة، مثل محرك تنفيذ استعلامات SQL أو نواة بيئة البرمجة التفاعلية (Notebook kernel). ورغم ذلك، لا يقوم النموذج بالتحقق من صحة القياسات، بل يكتفي بتنفيذ التعليمات؛ لذا يقع على عاتقك التأكد من أن الاستعلام المُنفَّذ يتوافق مع مجتمع التجربة وقواعد الاستبعاد المحددة.
تعرّف على الكيفية التي قد تؤدي بها مخرجات الذكاء الاصطناعي إلى أخطاء تبدو بسيطة ولكنها ذات عواقب وخيمة.
يُقدم الذكاء الاصطناعي أكبر قدر من المساعدة في المهام التي تتسم بالهيكلية الواضحة وإمكانية التحقق الدقيق؛ وتُعد عملية ضمان جودة أدوات التتبع (Instrumentation QA) مثالاً جيداً على ذلك. إذ يمكنك تكليف الذكاء الاصطناعي بإنشاء استعلامات (queries) للتحقق من حالات غياب تعيين “المتغير” (variant)، أو الانخفاض غير المتوقع في عدد الأحداث (events) في “تاريخ” محدد، أو عدم التوازن في توزيع “المنصة” (platform). وتتم عملية التحقق من خلال تشغيل هذه الاستعلامات والتأكد من مطابقة الأعداد المستخرجة مع جدول التعيينات الخاص بك.
تُعد صياغة تعريفات المقاييس مجالاً آخر يمكن الاستفادة فيه من الذكاء الاصطناعي؛ حيث يمكنه إعداد مسودة لمواصفات مقياس مثل activated_7d (التنشيط خلال 7 أيام) وتحديد الاستثناءات المطلوبة، إلا أنك تظل صاحب القرار النهائي بشأن التعريف وتتأكد من توافقه مع مفهوم النجاح لدى الجهة المعنية بالعمل. فعلى سبيل المثال، إذا كان صاحب المصلحة يرى أن “التنشيط” يعني إتمام الخطوة الثالثة، بينما يعتمد مقياسك على رصد أي جلسة استخدام خلال 7 أيام، فإن نتيجة التجربة ستكون خاطئة من الناحية التشغيلية حتى وإن كانت القيمة الاحتمالية (p-value) صغيرة.
كما يمكن للذكاء الاصطناعي صياغة السرد التحليلي للنتائج؛ ومع ذلك، تظل أنت المسؤول عن حساب التقدير الأولي، وفترة الثقة (confidence interval)، وتقسيم البيانات (segmentation) ذي الصلة باتخاذ القرار. يقوم الذكاء الاصطناعي بكتابة المسودة الأولى، بينما تتحمل أنت المسؤولية الكاملة عن كل ادعاء أو استنتاج يرد في النسخة النهائية.
حاول ربط المهام الشائعة بمستويات مشاركة الذكاء الاصطناعي المناسبة لها.