آپ ایک نئی ‘آن بورڈنگ اسکرین’ (onboarding screen) کے فیچر سے متعلق تجربے پر بطور تجزیہ کار کام کر رہے ہیں۔ پروڈکٹ لیڈ جمعہ تک اس بارے میں حتمی فیصلہ (منظوری یا عدم منظوری) چاہتا ہے؛ یہ فیصلہ 14 دن تک جاری رہنے والے اس A/B ٹیسٹ کی بنیاد پر ہوگا جو 240,000 اہل صارفین پر کیا گیا تھا (جنہیں 50/50 کے تناسب سے تقسیم کیا گیا تھا)۔ آپ کے پاس experiment_events جیسے ٹیبل میں ایونٹ کا ڈیٹا موجود ہے، جس میں ہر صارف کے لیے روزانہ کی بنیاد پر ایک قطار (row) ہے اور اس میں user_id، date، variant اور activated_7d جیسے نتائج شامل ہیں۔
یہاں AI آپ کے کام کی رفتار بڑھا سکتا ہے، لیکن یہ آپ کے فیصلے کی ذمہ داری نہیں لے سکتا۔ اگر فیچر کے نفاذ (rollout) سے صارفین کی برقراری (retention) متاثر ہوتی ہے—مثلاً کسی میٹرک کی غلط تعریف، کسی سیگمنٹ (گروپ) کے اخراج، یا کسی مفروضے کی خلاف ورزی کی وجہ سے—تو اس کے نتیجے میں ہونے والی ناکامی کی ذمہ داری آپ پر ہی عائد ہوگی۔ AI کو خلاصوں، کوڈ اور چیک لسٹس تیار کرنے والے ایک ذریعے کے طور پر دیکھیں، جنہیں آپ ڈیٹا اور اپنے تجربے کے ڈیزائن کی روشنی میں جانچتے اور تصدیق کرتے ہیں۔
اس عمل کے اہم حصوں کا جائزہ لیں۔
LLM (لارج لینگویج ماڈل) ایک ایسا ٹیکسٹ ماڈل ہے جو آپ کے فراہم کردہ ان پٹ (input) کی بنیاد پر ممکنہ اور معقول تسلسل تیار کرتا ہے۔ تجرباتی کام میں، اس کا مطلب یہ ہے کہ یہ تجزیاتی منصوبوں کا مسودہ تیار کر سکتا ہے، کوڈ لکھ سکتا ہے اور نتائج کا خلاصہ بیان کر سکتا ہے—یہ سب تب بھی ممکن ہے جب اس کی فراہم کردہ معلومات غلط ہوں لیکن انداز انتہائی پراعتماد ہو۔ پرامپٹ (prompt) سے مراد وہ ہدایات اور سیاق و سباق ہیں جو آپ ماڈل کو فراہم کرتے ہیں۔ اگر آپ کا پرامپٹ مبہم ہو، تو آپ ماڈل کو اس بات پر آمادہ کرتے ہیں کہ وہ خالی جگہوں کو شواہد کے بجائے اندازوں سے پُر کرے۔
جب ماڈل تجزیاتی کوڈ لکھتا ہے، تو اسے کوڈ جنریشن (code generation) کہا جاتا ہے۔ اس کے باوجود، آپ کو اسے چلانا (run کرنا)، اس کا جائزہ لینا اور اس بات کی تصدیق کرنی ہوتی ہے کہ یہ آپ کے ڈیزائن کے مطابق ہے۔ جب ماڈل کوئی ایسی تفصیل گھڑ لیتا ہے جس کی تائید آپ کے ڈیٹا سیٹ یا لاگز (logs) سے نہیں ہوتی، تو اسے ہیلوসিনیشن (hallucination) کہا جاتا ہے۔ A/B ٹیسٹنگ میں، ہیلوসিনیشن کی مثالوں میں فرضی سیمپل سائز (نمونے کے حجم)، بلا جواز سببی تعلق (causal language) کا دعویٰ، یا ٹیسٹ کا ایسا انتخاب شامل ہے جو خاموشی سے ڈیٹا کے نارمل (normal) ہونے کا مفروضہ قائم کر لیتا ہے۔
ٹول کا استعمال (Tool use) اس بات کی عکاسی کرتا ہے کہ ماڈل منظور شدہ ٹولز، جیسے کہ SQL رنر یا نوٹ بک کرنل، کو استعمال کر سکتا ہے۔ یہ پیمائش کی تصدیق نہیں کرتا، بلکہ صرف ہدایات پر عمل درآمد کرتا ہے۔ آپ کو خود اس بات کی تصدیق کرنی ہوتی ہے کہ چلائی گئی کیوری (query) تجربے کی آبادی (population) اور اخراج کے اصولوں (exclusion rules) سے مطابقت رکھتی ہے۔
آئیے دیکھتے ہیں کہ AI کا فراہم کردہ نتیجہ کس طرح چھوٹے مگر اہم طریقوں سے غلط ہو سکتا ہے۔
AI وہاں سب سے زیادہ مددگار ثابت ہوتا ہے جہاں کام منظم ہو اور تصدیق کا عمل واضح اور درست ہو۔ ‘انسٹرومینٹیشن QA’ (Instrumentation QA) اس کی ایک بہترین مثال ہے۔ آپ AI سے ایسی ممکنہ ‘کوئریز’ (queries) تیار کرنے کو کہہ سکتے ہیں جو ‘ویریئنٹ’ (variant) کی تفویض میں کمی، کسی مخصوص تاریخ پر ‘ایونٹ’ (event) کے ڈیٹا میں غیر متوقع کمی، یا ‘پلیٹ فارم’ (platform) کی تقسیم میں عدم توازن کی نشاندہی کر سکیں۔ آپ ان کوئریز کو چلا کر اور یہ تصدیق کر کے جانچ پڑتال کرتے ہیں کہ حاصل شدہ تعداد (counts) آپ کے ‘اسائنمنٹ ٹیبل’ (assignment table) سے مطابقت رکھتی ہے۔
‘میٹرک’ (metric) کی تعریفیں بھی ایک اہم پہلو ہیں۔ AI ‘activated_7d’ (7 دن کے اندر ایکٹیویشن) کے لیے میٹرک کی تفصیلات کا مسودہ تیار کر سکتا ہے اور ان چیزوں کی فہرست بنا سکتا ہے جنہیں اس میں شامل نہیں کرنا (exclusions)، لیکن تعریف کا حتمی فیصلہ آپ کرتے ہیں اور اس بات کی تصدیق کرتے ہیں کہ یہ کاروبار کی جانب سے ‘کامیابی’ کی تشریح سے ہم آہنگ ہے۔ اگر اسٹیک ہولڈر (stakeholder) کے نزدیک ایکٹیویشن کا مطلب ‘تیسرا مرحلہ مکمل کرنا’ ہے، لیکن آپ کا میٹرک ‘7 دن کے اندر کوئی بھی سیشن’ ہے، تو تجربے کا نتیجہ عملی طور پر غلط ہوگا، چاہے ‘p-value’ کم ہی کیوں نہ ہو۔
AI تجزیاتی رپورٹ یا بیانیے (analysis narrative) کا مسودہ بھی تیار کر سکتا ہے۔ بنیادی تخمینہ، اس کا ‘کانفیڈنس انٹرول’ (confidence interval)، اور فیصلے کے لیے اہم ‘سیگمنٹیشن’ (segmentation) کا حساب آپ خود لگاتے ہیں۔ AI پہلا مسودہ لکھتا ہے، لیکن حتمی رپورٹ میں موجود ہر دعوے کی ذمہ داری آپ کی ہوتی ہے۔
عام کاموں کو AI کی شمولیت کی مناسب سطحوں کے ساتھ منسلک کرنے (mapping) کی کوشش کریں۔