LLM پر مبنی AI فنکشنز کے لیے کازل انفرنس اب نظریاتی نہیں ہے۔ Airbnb، Netflix، Lyft، اور Uber نے انجینئرنگ کے تفصیلی بلاگ پوسٹس شائع کیے ہیں جس میں یہ وضاحت کی گئی ہے کہ وہ صارف کے رویے پر مصنوعات کی تبدیلیوں کے اصل اثرات کی پیمائش کیسے کرتے ہیں۔
وہ جن تکنیکوں کا نام دیتے ہیں (فرق میں فرق، رجعت کا وقفہ، ڈبل مضبوط تخمینہ، وغیرہ) معیاری ٹولز ہیں۔
دلچسپ بات یہ ہے کہ یہ ٹیمیں کس طرح بڑے پیمانے پر ایسا کرنے میں کامیاب ہوئیں۔ یعنی، جہاں طریقے پیداوار میں ناکام ہوئے، ہم نے قابل اعتماد تخمینے بنانے کے لیے ہر طریقہ کے ارد گرد کیا بنایا، اور ہم نے اعداد کو اصل مصنوعات کے فیصلوں سے کیسے جوڑا۔
اگر آپ LLM فنکشن بنا رہے ہیں اور ریفرل ریٹس اور سیشن کی لمبائی کی بنیاد پر پروڈکٹ کے فیصلے کر رہے ہیں، تو یہ پوسٹ پیمائش کے بارے میں آپ کے سوچنے کے انداز کو بدل دے گی۔
زیادہ تر ٹیمیں اب بھی 30 دن کی A/B ٹیسٹنگ اور پسند کی شرحوں کے ذریعے خصوصیت کے اثرات کی پیمائش کرتی ہیں۔ یہ نقطہ نظر اس وقت تک کام کرتا ہے جب تک کہ آپ کو یہ جاننے کی ضرورت نہ ہو کہ میٹرک کسی خصوصیت کی وجہ سے منتقل ہوا یا اسی ہفتے میں پیش آنے والے درجن بھر دیگر مسائل کی وجہ سے۔
نیچے دی گئی چار ٹیموں کو اس مسئلے کا سامنا کرنا پڑا اس سے پہلے کہ زیادہ تر ٹیموں نے LLM بھی بنایا ہو، اور ان کے قائم کردہ پیٹرن آپ سے وہی غلطی کرنے سے پہلے سمجھنے کے قابل ہیں۔ میں نے دیکھا ہے کہ ٹیمیں ایک خصوصیت جاری کرنے میں ہفتے گزارتی ہیں اور پھر اس بحث میں مزید کئی ہفتے گزارتی ہیں کہ آیا نمبر حقیقی ہیں۔ یہ قابل گریز ہے۔
ان تنظیموں کے لیے، وجہ کی پیمائش کوئی سوچا سمجھا نہیں ہے، بلکہ مصنوعات کے تجربات کا ایک بنیادی عنصر ہے جو براہ راست تعیناتی فن تعمیر میں ضم ہوتا ہے۔ اس مضمون میں پیش کردہ ترکیب AI مصنوعات کے ساتھ تجربہ کرنے کے لیے ایک جامع ٹول کٹ کی تفصیلات فراہم کرتی ہے جہاں روایتی A/B ٹیسٹنگ آپ کے تعیناتی ماڈل سے مطابقت نہیں رکھتی۔
چاہے عالمی ماڈل ٹرانزیشن کا انتظام ہو، حد پر مبنی روٹنگ، مرحلہ وار رول آؤٹ، یا مشاہداتی آپٹ ان ڈیٹا، ہر منظر نامے کے لیے ایک مخصوص طریقہ کار کی ضرورت ہوتی ہے۔ اس ٹول کٹ کو استعمال کرنے میں ناکامی کا نتیجہ ابہام سے زیادہ ہے۔ اس کا مطلب یہ ہے کہ مبہم اعداد و شمار کی بنیاد پر پروڈکٹ کے فیصلے کرنا، جو بالکل بھی پیمائش نہ کرنے سے کہیں زیادہ نقصان دہ ہے۔
انڈیکس
اس مضمون کے تمام کوڈ بلاکس درج ذیل ساتھی نوٹ بک میں آخر سے آخر تک چلائے جاتے ہیں۔ product-experimentation-causal-inference-genai-llm/tree/main/13_case_studies/. نوٹ بک: case_studies_demo.ipynb.
شرطیں
آپ کو درج ذیل کی ضرورت ہوگی:
-
Python 3.11 یا اس سے زیادہ
-
پانڈوں کے ساتھ آرام، اسکِٹ لرن، اور بنیادی رجعت
-
causal inference کے طریقوں کے بارے میں پہلے پڑھنے کی ضرورت نہیں ہے۔ ہر کیس اسٹڈی ٹیکنالوجی ان لائن کی وضاحت کرتا ہے۔
اس مضمون کے لیے پیکج انسٹال کریں۔
pip install numpy pandas scikit-learn scipy matplotlib
ساتھی ریپوزٹری کو کلون کریں اور ایک مشترکہ ڈیٹاسیٹ بنائیں۔
git clone https://github.com/RudrenduPaul/product-experimentation-causal-inference-genai-llm.git
cd product-experimentation-causal-inference-genai-llm
python data/generate_data.py --seed 42 --n-users 50000 --out data/synthetic_llm_logs.csv
اس مضمون کے چاروں کیس اسٹڈی کوڈ بلاکس اپنی فائلوں کو استعمال کرتے ہوئے لوڈ کرتے ہیں: pd.read_csv("data/synthetic_llm_logs.csv"). ڈیٹاسیٹ میں 50,000 قطاریں اور 16 کالم ہیں جن میں صارف ID، سیشن کا رویہ، اور ماڈل میٹا ڈیٹا ہے۔ user_id, session_minutes, task_completed, model_used, latency_msاور query_complexityخاص طور پر
پیداوار AI کی پیمائش کرنا اس سے کہیں زیادہ مشکل کیوں ہے۔
AI صلاحیتوں کے اثرات کی پیمائش کرنے کے بارے میں معیاری کہانی کچھ یوں ہے: A/B ٹیسٹ چلائیں اور رپورٹ لفٹ کریں۔ اگر پی ویلیو 0.05 سے کم ہے تو اسے بھیج دیا جائے گا۔ لیکن یہ کہانی تین جگہوں پر مختلف ہے۔
سب سے پہلے، رینڈمائزیشن ہمیشہ ممکن نہیں ہے. انٹرپرائز SaaS پروڈکٹس A/B ٹیسٹنگ میں فرض کیے گئے انفرادی صارف کوائن فلپس کو نظرانداز کرتے ہوئے AI خصوصیات کو ترتیب وار کام کی جگہ پر لاتے ہیں۔ کنزیومر پروڈکٹس فیچرز کو ریجن، کوہورٹ یا پلیٹ فارم کے لحاظ سے بتدریج رول آؤٹ کرتے ہیں۔ حفاظت سے متعلق حساس خصوصیات صارفین کے سب سیٹ کو فراہم کی جاتی ہیں جن کا رسک پروفائل حد سے گزرتا ہے۔
اگر رینڈمائزیشن نہیں ہوتی ہے، تو آپ کی A/B ٹیسٹنگ منطق ناکام ہو جائے گی۔ آپ غیر بے ترتیب ڈیٹا پر ایک ہی تجزیہ نہیں چلا سکتے اور تخمینوں کے معنی خیز ہونے کی توقع نہیں کر سکتے۔ کنفاؤنڈرز جو خصلت کے وصول کنندہ اور ان کا برتاؤ دونوں کے ساتھ منسلک ہوتے ہیں وہ اکثر کسی بھی گتانک کی طرفداری کرتے ہیں جس کا ہم اس خاصیت کو چپٹا کرنے کے لیے حساب کرتے ہیں۔
دوسرا، قلیل مدتی اشارے ہمیشہ طویل مدتی قدر کی پیش گوئی نہیں کرتے۔ ایک فوری تبدیلی جو آج آپ کی پسند کی درجہ بندی میں 8 پوائنٹس کا اضافہ کرتی ہے وہ AI معاونین پر صارف کے انحصار کو بڑھا سکتی ہے اور تین ماہ کے لیے منحرف ہو سکتی ہے۔ ماڈل روٹنگ کی تبدیلیاں جو اس ہفتے کام کی تکمیل کو بہتر کرتی ہیں، اگلی سہ ماہی میں نئی استفسارات کی تعیناتیوں کے سامنے آنے کے بعد تنزلی کا شکار ہو سکتی ہیں۔
ابتدائی طور پر، یہ فرض کیا گیا تھا کہ قلیل مدتی پراکسیز طویل مدتی رجحانات کو قابل اعتماد طریقے سے ظاہر کریں گی، لیکن وہ مسلسل ایسا کرنے میں ناکام رہے۔ قلیل مدتی A/B ٹیسٹنگ کی حد یہ ہے کہ یہ فوری میٹرکس میں تبدیلیوں پر توجہ مرکوز کرتا ہے اور یہ پہچاننے میں ناکام رہتا ہے کہ آخر کار سب سے اہم کیا ہے: نیچے دھارے میں صارف کے رویے میں تبدیلیاں۔
آخر میں، مشاہداتی اعداد و شمار ناگزیر ہیں. A/B ٹیسٹنگ پروڈکٹ کے فیصلوں کی ایک تنگ رینج کو حل کرتی ہے۔ روٹنگ تھریشولڈ تبدیلیاں چھ ماہ قبل جاری کی گئیں، Q3 میں ماڈل ونٹیج سویپ، یا وہ صارفین جنہوں نے گیٹ بند ہونے سے پہلے ایجنٹ موڈ کا انتخاب کیا: ان میں سے کوئی بھی حقیقت کے بعد تجربات کے طور پر نہیں چلایا جا سکتا۔
ایسے سسٹمز کے لیے جن کے لیے پیچھے مڑ کر دیکھنے کی ضرورت ہوتی ہے، یا ایسے فیصلوں کو روٹ کرنا جو اخلاقی طور پر تصادفی طور پر نہیں کیے جا سکتے، ہم کسی متبادل تجرباتی ڈیزائن کے بغیر مشاہداتی لاگز کے ساتھ کام کرتے ہیں۔
مشاہداتی کازل انفرنس ایک متبادل نہیں ہے۔ یہ ایک بنیادی قابلیت ہے، اور جو ٹیمیں اسے اختیاری سمجھتی ہیں وہ مشکل راستہ تلاش کرتی ہیں جب اسٹیک ہولڈرز پوچھتے ہیں کہ پچھلی سہ ماہی کے لانچ نمبروں کی جانچ پڑتال کیوں نہیں ہوتی ہے۔
نیچے دی گئی چار ٹیموں میں سے ہر ایک نے ایک ایسا نظام بنایا ہے جو ان تینوں میں سے ایک یا زیادہ مسائل کو حل کرتا ہے۔
کیس اسٹڈی 1: Airbnb کا فیوچر ویلیو فریم ورک
قلیل مدتی A/B ٹیسٹنگ رویے میں اہم تبدیلیوں سے محروم ہے۔
جیسا کہ جینی چن نے Airbnb ٹیکنالوجی بلاگ پوسٹ میں وضاحت کی ہے کہ "Airbnb مستقبل کی قدر کو معیاری بنانے کے لیے کس طرح پیمائش کرتا ہے،” Airbnb کی انجینئرنگ ٹیم کو اپنے تجرباتی انفراسٹرکچر کے ساتھ ایک بنیادی مسئلہ کا سامنا کرنا پڑا۔ معیاری A/B ٹیسٹنگ تجربہ کی مدت کے اختتام پر نتائج کی پیمائش کرتی ہے (عام طور پر 14 سے 30 دن)۔
مارکیٹ پلیس کی خصوصیات کے لیے جو مہینوں یا سالوں میں صارف کے رویے کو متاثر کرتی ہیں، وہ وقت بہت کم ہے۔ 30 دن کی بکنگ میں اضافہ کرنے کی اہلیت ایک ایسی کارروائی کو تیز کر سکتی ہے جسے صارفین بہرحال، ڈرائیونگ ڈیمانڈ، یا حقیقی معنوں میں نئی طویل مدتی مصروفیت کا اضافہ کر رہے ہوں گے۔ 30 دن کا میٹرک اس کے علاوہ نہیں بتا سکتا۔
اس کا LLM ورژن ثانوی انحصار کا مسئلہ ہے۔ ایک فوری دوبارہ ڈیزائن جو AI اسسٹنٹ کو دبلا پتلا اور زیادہ پر اعتماد بناتا ہے عام طور پر فوری طور پر درجہ بندیوں اور کام کی تکمیل کی شرحوں کی طرح بڑھ جاتا ہے۔ صارفین پراعتماد اور براہ راست جوابات کو ترجیح دیتے ہیں۔ تاہم، اگر دوبارہ ڈیزائن کرنے سے صارفین کو آزادانہ طور پر اپنے جوابات کی تصدیق کرنے کا امکان کم ہو جاتا ہے، تو اس سے ہم آہنگی اور طویل مدتی اعتماد کی قیمت پر قلیل مدتی تجربہ بہتر ہو سکتا ہے۔
اسسٹنٹ نے دو بار پُراعتماد غلط جواب دیا، لہٰذا جب تک صارف باہر نکلنا شروع ہوا، فوری تبدیلی میں کافی وقت لگا اور ایگزٹ سگنل سے کوئی واضح کنکشن نہیں تھا۔ میں نے دیکھا ہے کہ یہ خلاء ٹیموں کو مہینوں کے تشخیصی کام کرنے کے لیے لیڈ کرتے ہیں تاکہ موسمی رویے کی وجہ سے ماڈل اپڈیٹس میں فوری تبدیلیوں کو دور کیا جا سکے۔
فریم ورک
طویل مدتی نتائج کا انتظار کرنے کی ضرورت نہیں ہے۔ پچھلے گروہوں سے، ہمیں یہ معلوم کرنے کی ضرورت ہے کہ کون سے قلیل مدتی سگنلز قابل اعتماد طور پر طویل مدتی برقرار رکھنے اور واپسی کی پیش گوئی کرتے ہیں۔ Airbnb کا حل قلیل مدتی سگنلز کو متوقع طویل مدتی قدر میں تبدیل کرنے کے لیے تاریخی رشتوں پر سیکھے گئے پیش گوئی کرنے والے ماڈلز کا استعمال کرتا ہے۔
اس تناظر میں، میٹرک ایک "مستقبل کی قدر” کا سکور ہے جو موجودہ مصروفیت کے نمونوں کی بنیاد پر طویل مدتی بکنگ میں صارف کے تعاون کا تخمینہ لگاتا ہے۔ ایک بار جب آپ کے پاس وہ ماڈل ہو جائے تو، آپ 30-دن کے اشارے کو متعدد ان پٹ میں سے ایک کے طور پر استعمال کرتے ہوئے، مستقبل کی قیمت پر اس کے متوقع اثرات کی بنیاد پر کسی بھی تجربے کا اندازہ کر سکتے ہیں۔ تجرباتی مدت کو مختصر رکھا جاتا ہے اور تشخیص کے افق کو اس حد تک بڑھا دیا جاتا ہے جہاں تک پیشین گوئی کرنے والا ماڈل پہنچ سکتا ہے۔
حوالہ کے نفاذ میں DiD قدم کے لیے ایک شناختی مفروضے کی ضرورت ہوتی ہے: متوازی پری پروسیسنگ کا رجحان۔ فیچر ریلیز ہونے سے پہلے دونوں کوہورٹس کا ایک ہی طرز عمل پر ہونا ضروری ہے۔ اگر Wave 1 کے صارفین خصوصیت سے قطع نظر پہلے سے ہی زیادہ برقرار رکھنے کی شرح کی طرف رجحان کر رہے ہیں، تو DiD کا تخمینہ لہروں کے درمیان موجودہ فرق کے ساتھ خصوصیت کے اثرات کو ملاتا ہے۔ زیادہ تر ٹیمیں فرض کرتی ہیں کہ وہ تصدیق کو چھوڑ دیتی ہیں کیونکہ انہیں مدت سے پہلے رجحانات کی منصوبہ بندی کرنے کی ضرورت ہوتی ہے۔ اس میں 20 منٹ لگتے ہیں اور اس وقت تک غیر ضروری محسوس ہوتا ہے جب تک کہ نتائج کا کوئی مطلب نہ ہو۔
LLM ٹیم کے لیے، آپ کو دو مساویوں کی ضرورت ہوگی: سب سے پہلے، آپ کو طویل مدتی صارف کی قدر (ہفتہ 7 برقرار رکھنے کی شرح اور واپسی کی شرح) کے اہم اشاریوں کی ضرورت ہے۔ دوسرا، آپ کو تاریخی اعداد و شمار کی ضرورت ہے جو ان کلیدی میٹرکس کو طویل مدتی نتائج سے جوڑتا ہے جن کی آپ اصل میں پرواہ کرتے ہیں (آمدنی اور صارف کی زندگی بھر)۔ کنیکٹیویٹی ماڈلز کو ایک بار تاریخی آبادیوں پر تربیت دی جاتی ہے اور پھر نئے تجربات پر لاگو کیا جاتا ہے۔
حوالہ کا نفاذ
ذیل کا کوڈ ساختی پیٹرن کو ظاہر کرتا ہے۔ قلیل مدتی سگنلز سے، ہم ہر صارف کے لیے مستقبل کی ویلیو پراکسیوں کی گنتی کرتے ہیں اور پھر فوری طور پر کام کی تکمیل کے سگنلز کو تبدیل کرنے کے لیے انہیں DiD یا IPW تجزیہ کے نتائج کے طور پر استعمال کرتے ہیں۔
import pandas as pd
import numpy as np
from sklearn.linear_model import LinearRegression
# Synthetic LLM telemetry with retention signal
df = pd.read_csv("data/synthetic_llm_logs.csv")
# Step 1: Train the future-value proxy model on a historical cohort.
# In production this model is trained on users old enough that
# their long-term outcome (e.g., 90-day retained revenue) is known.
historical = df[df.signup_week < 10].copy()
feature_cols = ["task_completed", "thumbs_up", "session_minutes"]
X_hist = historical[feature_cols].fillna(0)
y_hist = historical["retained_7d"].values # 7-day retention as long-term proxy
fv_model = LinearRegression().fit(X_hist, y_hist)
# R² computed on training data; use a holdout cohort in production
print("Future-value model R²:", round(fv_model.score(X_hist, y_hist), 3))
# Step 2: Score all users with the future-value proxy.
X_all = df[feature_cols].fillna(0)
df["future_value_score"] = fv_model.predict(X_all)
# Step 3: Compare future_value_score by wave (this is the real experiment outcome).
print("nMean future-value score by wave:")
print(df.groupby("wave").future_value_score.mean().round(4))
# Step 4: The DiD effect on future value (rather than on task_completed).
# This is where you would plug future_value_score into your DiD regression.
analysis = df[df.signup_week < 30].copy()
analysis["post"] = (analysis.signup_week >= 20).astype(int)
analysis["treated"] = (analysis.wave == 1).astype(int)
cells = analysis.groupby(["treated", "post"]).future_value_score.mean()
did_fv = (
(cells.loc[(1, 1)] - cells.loc[(1, 0)])
- (cells.loc[(0, 1)] - cells.loc[(0, 0)])
)
print(f"nDiD effect on future-value score: {did_fv:+.4f}")
متوقع پیداوار:
Future-value model R²: 0.024
Mean future-value score by wave:
wave
1 0.6325
2 0.6271
Name: future_value_score, dtype: float64
DiD effect on future-value score: +0.0059
یہاں کیا ہو رہا ہے: ہم ایک ہلکے وزنی لکیری ماڈل کو تاریخی گروہوں پر تربیت دیتے ہیں جہاں طویل مدتی نتائج پہلے سے ہی معلوم ہوتے ہیں، اور مستقبل کی قدر کے لیے پراکسی کے طور پر قابل مشاہدہ قلیل مدتی اشاروں کو 7 دن کے برقرار رکھنے کی شرحوں پر نقشہ بناتے ہیں۔
ہم ہر صارف کو اسکور کرنے کے لیے اس ماڈل کا استعمال کرتے ہیں، اور پھر معیاری DiD کے نتیجے میں مستقبل کے ویلیو سکور کا استعمال کرتے ہیں۔ اگرچہ 7 دن کی برقراری ایک نامکمل پراکسی ہے، لیکن پائیدار قیمت کے ساتھ اس کا تاریخی ارتباط اسی شرح سے زیادہ ہمیں اپنے تجزیہ میں قلیل مدتی مصروفیت کو وزن دینے پر مجبور کرتا ہے۔
0.024 کی کم R² قدر جان بوجھ کر ہے کیونکہ یہ فوری سیشن کے ڈیٹا کو 7 دن کی برقراری سے منسلک کرنے میں موجود شور کو نمایاں کرتا ہے۔ پیداواری نظاموں کو مثالی طور پر اعلیٰ پیشین گوئی کی طاقت کے ساتھ سگنلز کا فائدہ اٹھانا چاہیے، جیسے کہ نظر ثانی کی شرح یا استفسار کی گہرائی، لیکن اس سے بھی کم درست کنیکٹوٹی ماڈل اب بھی قدر فراہم کر سکتے ہیں۔
بنیادی مقصد قطعی درستگی حاصل کرنے کے بجائے درست انشانکن سمت قائم کرنا ہے۔
ایک طویل مدتی قدر کی بچت کے تجربے کے لیے آلات جو ہفتہ 2 میں اچھا لگتا ہے اور مہینے 4 میں ناکام ہو جاتا ہے۔
Airbnb فریم ورک پیمائش کے دائرہ کار کے مسئلے کا براہ راست جواب ہے۔ 30 دن یا 14 دن کے ٹائم فریم میں AI صلاحیتوں کا جائزہ لیتے وقت، ہم ان خصوصیات کو انعام دیتے ہیں جو صارفین کو تیزی سے منتقل کرتی ہیں، قطع نظر اس کے کہ وہ کہاں منتقل ہو رہے ہیں۔
طویل مدتی قدر کے اہم اشاریوں کا اندازہ لگانے کے لیے طویل تجربات کی ضرورت نہیں ہے۔ یہ ایک امیر پیمائش ماڈل کی ضرورت ہے. اس خصوصیت کو بنانے والی ٹیمیں کم تجربات کرتی ہیں جو ہفتہ 2 میں بہت اچھے لگتے ہیں لیکن مہینے 4 میں مایوس ہوتے ہیں۔
اگر کنیکٹیویٹی ماڈل پہلے سے ہی آپ کے انفراسٹرکچر کا حصہ نہیں ہے، تو تشخیصی ڈیش بورڈ کو بڑھانے کے بجائے اسے تیار کرنا آپ کی اولین ترجیح ہونی چاہیے۔
کیس اسٹڈی 2: Netflix کی نیم تجرباتی درجہ بندی
تعیناتی کا ڈھانچہ طریقہ کار کا تعین کرتا ہے۔
Netflix تکنیکی بلاگ پوسٹ "Netflix Quasi-Experiment کے کلیدی چیلنجز” پروڈکٹ ٹیموں میں کارآمد نتائج پر سب سے مفید مضامین میں سے ایک ہے۔ کلیدی شراکت درجہ بندی ہے۔ ہر تعیناتی کے منظر نامے میں ایک متعلقہ وجہ کا طریقہ ہوتا ہے، اور پوسٹ متعلقہ شناختی مفروضوں اور ناکامی کے طریقوں کی نشاندہی کرتی ہے۔
یہ فریمنگ اہم ہے کیونکہ زیادہ تر ٹیمیں اپنی تعیناتی کے ڈھانچے کی بنیاد پر کوئی طریقہ منتخب نہیں کرتی ہیں۔ وہ اس چیز کا انتخاب کرتے ہیں جو وہ پہلے سے جانتے ہیں، جو اکثر فٹ نہیں ہوتا ہے۔
شکل 1: تعیناتی فن تعمیر ایک قابل اعتماد شناختی حکمت عملی کا تعین کرتا ہے۔ تھریشولڈ روٹنگ سسٹمز کو RDDs کی ضرورت ہوتی ہے، جبکہ آپٹ ان تجزیہ کے لیے رجحان کے طریقوں کی ضرورت ہوتی ہے۔ مختص کرنے کا طریقہ کار انتخاب کو آگے بڑھاتا ہے تاکہ ٹیم کا ترجیحی تخمینہ لگانے والا دوسرے نمبر پر آجائے۔
Netflix کی درجہ بندی میں چار منظرناموں کا احاطہ کیا گیا ہے جو LLM ٹیموں کو درپیش حالات سے بالکل مطابقت رکھتے ہیں۔
مرحلہ وار رول آؤٹ (ان کا منظر نامہ: بتدریج مارکیٹ میں داخلہ) اختلافات میں فرق کے نقشے Cohort B سے پہلے ورک پلیس Cohort A کو AI صلاحیتیں فراہم کرنا وقت کے ساتھ ساتھ قدرتی پروسیسنگ اور کنٹرول گروپ ہوگا۔ شناخت کی حکمت عملی مشترکہ وقت کے رجحان کو نتیجے میں پائے جانے والے اختلافات سے گھٹا دیتی ہے۔
ایک اہم مفروضہ یہ ہے کہ دونوں گروہوں میں متوازی پری علاج کے رجحانات ہیں۔ اگر ایک گروہ علاج شروع ہونے سے پہلے ہی ایک رجحان دکھا رہا ہے، تو یہ طریقہ اسے حقیقی اثر سے ممتاز نہیں کر سکتا۔
حد پر مبنی روٹنگ (ان کا منظر نامہ: جغرافیائی سکور ڈویژن) رجعت کے وقفے کا نقشہ۔ ایک بار جب مسلسل اسکور اس بات کا تعین کرتا ہے کہ صارف کون سا ماڈل یا خصوصیت حاصل کرتا ہے، تو صارف اس حد کے بالکل نیچے اور بالکل اوپر پروسیسنگ کے علاوہ ہر طرح سے ایک جیسے ہوتے ہیں۔
کٹ آف میں چھلانگ مقامی اوسط علاج کے اثر (دیر) کی نشاندہی کرتی ہے۔ یعنی، حد کے قریب صارفین کے لیے صرف کازل اثر اس حد سے باہر کے تمام صارفین کے لیے علاج کے اوسط اثر کی نمائندگی کرتا ہے۔ ایک اہم مفروضہ یہ ہے کہ صارفین اسکور کو درست طریقے سے جوڑ نہیں سکتے۔
کل آبادی میں اضافہ (ان کا منظر نامہ: پلیٹ فارم وسیع پالیسی میں تبدیلی) مصنوعی کنٹرول ڈیزائن کے نقشے بناتے ہیں۔ اگر تمام صارفین ایک ساتھ نیا ماڈل وصول کرتے ہیں اور کوئی ہولڈ آؤٹ گروپس نہیں ہیں، تو ہم تاریخی یا مصنوعی جوابی حقائق کا ایک وزنی مجموعہ بناتے ہیں تاکہ یہ اندازہ لگایا جا سکے کہ اپ گریڈ کے بغیر کیا ہوتا۔
ایک اہم مفروضہ یہ ہے کہ مصنوعی کنٹرول گروپ علاج سے پہلے کی مدت سے اچھی طرح مماثل ہے۔ آپ کی ماہواری سے پہلے ناقص فٹ ہونا کوئی معمولی تکلیف نہیں ہے۔ اس سے پورے جوابی حقائق کو باطل کر دیا جاتا ہے۔
مماثل موازنہ (ان کا منظر نامہ: آپٹ ان فیچر کو اپنانا) رجحان سکور کے طریقہ کار پر نقشہ بناتا ہے۔ جب صارف خود ساختہ AI خصوصیات کو منتخب کرتا ہے، تو موازنہ گروپوں کا دوبارہ وزن کیا جاتا ہے یا مشاہدے کے قابل تخمینی بے ترتیب تفویض سے دوبارہ ملایا جاتا ہے۔
ایک اہم مفروضہ یہ ہے کہ تمام متعلقہ الجھنے والے عوامل کا مشاہدہ کیا جاتا ہے۔ اگر آپ جن صارفین کو منتخب کرتے ہیں وہ ان طریقوں سے طاقت استعمال کرنے والے ہوتے ہیں جن کی آپ نے پیمائش نہیں کی ہے، تو آپ کا کنفاؤنڈر ایڈجسٹمنٹ نامکمل ہو گا اور آپ کے اندازے ان طریقوں سے متعصب ہوں گے جن کا حقیقت کے بعد پتہ لگانا مشکل ہے۔
درجہ بندی طریقہ انتخاب کو ایک منظم تفتیش بناتی ہے۔ یعنی، ہمیں ایک ایسا طریقہ ملتا ہے جو تقسیم کے ڈھانچے کو بیان کرتا ہے اور جس کے مفروضوں کو سیٹ اپ سب سے زیادہ قابل اطمینان طور پر مطمئن کرتا ہے۔
میں نے ٹیموں کو اس قدم کو چھوڑتے ہوئے دیکھا ہے اور ڈیٹا پر DiD چلانے میں دو ہفتے گزارے ہیں جو واضح طور پر ایک حد روٹنگ کا مسئلہ تھا۔ تخمینوں میں 40 فیصد کا فرق تھا۔ دونوں غلط نہیں ہیں۔ وہ مختلف سوالوں کے جواب دے رہے تھے۔
حوالہ کا نفاذ
ذیل کا کوڈ درجہ بندی کو فیصلہ سازی کی تقریب کے طور پر نافذ کرتا ہے۔ تعیناتی کے منظر نامے کی تفصیل کے پیش نظر، یہ مناسب طریقے اور کلیدی مفروضوں کو پرنٹ کرتا ہے۔
TAXONOMY = {
"staged_rollout": {
"method": "Difference-in-Differences (DiD)",
"assumption": "Parallel pre-treatment trends between treated and control cohorts",
"check": "Plot weekly means by cohort before treatment starts; "
"run pre-trend placebo regression",
"failure_mode": "Non-parallel pre-trends, time-varying confounders, "
"staggered adoption without Callaway-Sant'Anna correction",
},
"threshold_routing": {
"method": "Regression Discontinuity Design (RDD)",
"assumption": "Users cannot precisely manipulate their score across the cutoff",
"check": "McCrary density test; bandwidth sensitivity; "
"quadratic spec robustness",
"failure_mode": "Score manipulation, other policies firing at same cutoff, "
"extrapolation bias away from the cutoff",
},
"full_population_upgrade": {
"method": "Synthetic Control",
"assumption": "Pre-treatment fit between actual and synthetic counterfactual is good",
"check": "In-time placebo tests; in-space placebo tests; "
"plot pre-period fit",
"failure_mode": "Poor pre-period fit, interference between donor units, "
"post-treatment structural breaks",
},
"opt_in_feature": {
"method": "Propensity Score Methods (IPW / Matching)",
"assumption": "All confounders that drive opt-in and affect outcome are observed",
"check": "Standardized mean difference before and after weighting; "
"propensity overlap histogram",
"failure_mode": "Unmeasured confounders, positivity violations, "
"propensity model misspecification",
},
}
def select_method(scenario: str) -> None:
if scenario not in TAXONOMY:
valid = ", ".join(TAXONOMY.keys())
print(f"Unknown scenario. Valid options: {valid}")
return
entry = TAXONOMY[scenario]
print(f"Scenario: {scenario}")
print(f"Method: {entry['method']}")
print(f"Assumption: {entry['assumption']}")
print(f"Key checks: {entry['check']}")
print(f"Failure modes: {entry['failure_mode']}")
# Example: staged AI feature rollout across enterprise workspaces
select_method("staged_rollout")
print()
# Example: confidence-threshold routing between model tiers
select_method("threshold_routing")
متوقع پیداوار:
Scenario: staged_rollout
Method: Difference-in-Differences (DiD)
Assumption: Parallel pre-treatment trends between treated and control cohorts
Key checks: Plot weekly means by cohort before treatment starts; run pre-trend placebo regression
Failure modes: Non-parallel pre-trends, time-varying confounders, staggered adoption without Callaway-Sant'Anna correction
Scenario: threshold_routing
Method: Regression Discontinuity Design (RDD)
Assumption: Users cannot precisely manipulate their score across the cutoff
Key checks: McCrary density test; bandwidth sensitivity; quadratic spec robustness
Failure modes: Score manipulation, other policies firing at same cutoff, extrapolation bias away from the cutoff
ہر تعیناتی کے منظر نامے میں ناکامی کے طریقے ہوتے ہیں جو طریقہ کار، کلیدی شناخت کے مفروضوں، اور تشخیص اور تجزیہ کو باطل کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ مفروضے برقرار ہیں۔
یہ فنکشن ایک فیصلہ امداد ہے جو طریقہ انتخاب کے مرحلے کو واضح کرتا ہے، لہذا ٹیم ریگریشن کوڈ کی ایک لائن لکھنے سے پہلے شناختی حکمت عملی پر متفق ہوتی ہے۔ اس طرح کے اتفاق رائے کے بغیر، آپ کو اکثر درمیانی تجزیہ ملتا ہے کہ ٹیم میں شامل دو افراد ایک ہی ڈیٹا پر واضح طور پر مختلف کازل ماڈل چلا رہے ہیں۔
اگر آپ غلط طریقہ کا انتخاب کرتے ہیں، تو کلینر ڈیٹا آپ کو محفوظ نہیں کرے گا۔
زیادہ تر ٹیمیں اس وجہ کا انتخاب کرتی ہیں جو وہ سب سے بہتر جانتے ہیں۔ یہ ایک ناقص ہوورسٹک ہے، اور Netflix درجہ بندی بالکل اسی کو شارٹ کٹ کرنے کے لیے موجود ہے۔
ڈی آئی ڈی کا تجربہ رکھنے والی ایل ایل ایم ٹیمیں ڈی آئی ڈی تک پہنچتی ہیں یہاں تک کہ جب تھریشولڈ روٹنگ سسٹم چلاتے ہیں جہاں آر ڈی ڈی واضح جوابات فراہم کرتا ہے اور اوسط اندازوں کے بجائے قابل دفاع مقامی علاج کے اثرات کا تخمینہ فراہم کرتا ہے۔
درجہ بندی اہم اصولوں پر روشنی ڈالتی ہے۔ انتخاب کا طریقہ ٹیم کی واقفیت سے نہیں بلکہ خود مختص کرنے کے طریقہ کار سے طے ہوتا ہے۔ اگر مختص کرنے کا طریقہ کار کٹ آف سکور ہے، تو RDD کوشش کرنے کا پہلا ٹول ہے، قطع نظر اس کے کہ ٹیم پہلے سے جانتی ہے کہ اسے کیسے نافذ کرنا ہے۔
یہ غلط ہونا صرف شور مچانے والے تخمینے ہی پیدا نہیں کرتا ہے۔ یہ ساختی طور پر غلط ڈیٹا بناتا ہے جسے کلینر ڈیٹا کے ساتھ تبدیل نہیں کیا جا سکتا۔
کیس اسٹڈی 3: Lyft کی ڈبل پاور کی تصدیق
کیوں سنگل ماڈل اپروچ پروڈکشن میں ناکام ہو جاتے ہیں۔
لیفٹ انجینئرنگ بلاگ پر شیما ناصری کی پوسٹ "ٹرسٹ ان دی ناقابل اعتماد: دوگنا مضبوط ماڈلز کے لیے توثیق اور تشخیص” کا آغاز حقیقی دنیا کے مشاہدات سے ہوتا ہے۔ زیادہ تر حقیقی دنیا کے پروڈکشن کازل تجزیوں میں، کم از کم ایک ڈسٹربنس ماڈل میں تصریح کی خرابی ہوتی ہے۔
جب آپ مشاہداتی کازل تجزیہ چلاتے ہیں، تو آپ تقریباً ہمیشہ دو ماڈلز کو فٹ کرتے ہیں: ایک پروپینسیٹی ماڈل (کوویریٹس کے ذریعے علاج کی پیش گوئی کرنا) اور ایک نتیجہ کا ماڈل (علاج اور کوویریٹس کے ذریعے نتائج کی پیش گوئی کرنا)۔
دونوں ماڈل نامعلوم حقیقی افعال کے قریب ہیں۔ اگر یا تو کسی غیر واضح طریقے سے غلط ہے تو، وجہ کا تخمینہ متعصب ہے، اور اکیلے معیاری آؤٹ پٹ آپ کو یہ نہیں بتائے گا۔
دوگنا مضبوط تخمینہ، خاص طور پر Augmented Inverse Probability Weighting Estimator (AIPW)، اس کا جواب ہے۔ AIPW رجحان وزن اور ریگریشن ایڈجسٹمنٹ کو یکجا کرتا ہے۔ اگر رجحان یا نتائج کا نمونہ درست طریقے سے بیان کیا گیا ہے، تو AIPW کے تخمینے ایک جیسے ہوں گے۔ ایک اچھی طرح سے مخصوص ماڈل کافی ہے۔
یعنی، AIPW غیر ناپید الجھنے والے عوامل کے خلاف تحفظ فراہم نہیں کرتا ہے اور پھر بھی غیر الجھاؤ کی ضرورت ہے۔ اس کا مطلب یہ ہے کہ تمام عوامل جو علاج کی تفویض اور نتائج کو متاثر کرتے ہیں ان کا مشاہدہ اور ماڈل میں شامل ہونا ضروری ہے۔ اگر آپ کے ڈیٹا میں کوئی اہم الجھنے والے عوامل نہیں ہیں، تو AIPW آپ کو نہیں بچا سکتا۔
ناصری کا مراسلہ خود اندازہ لگانے والے سے بالاتر ہے۔ جو چیز واقعی اہم ہے وہ تشخیصی ٹول کٹ ہے جسے ہم مشاہداتی تجزیوں کو چلانے سے پہلے درست کرنے کے لیے بیان کرتے ہیں۔
ایک صاف بے ترتیب تجربہ توازن کے لیے چیک کرتا ہے اور طاقت کا حساب کرتا ہے۔ مشاہداتی مطالعات میں، ہمیں زیادہ محنت کرنی پڑتی ہے کیونکہ ڈیزائن میں بے ترتیب ہونے کی ضمانت نہیں ہے۔ میں نے ٹیموں کو اس تشخیصی مرحلے کو چھوڑتے ہوئے دیکھا ہے اور یہ بتانے میں ہفتے گزارے ہیں کہ ان کے کارآمد تخمینے دو کے عنصر سے کیوں بند تھے۔
فیصلے کرنے سے پہلے Lyft کی پروڈکشن ڈائیگنسٹکس ماڈل کی غلطیوں کو پکڑ لیتی ہے۔
پائپ لائن چار چیک چلاتی ہے:
1. وزن کی تقسیم کی جانچ کریں۔
پروپینسٹی ماڈل کو فٹ کرنے کے بعد، ہم IPW وزن کی تقسیم کا منصوبہ بناتے ہیں۔ مثال کے طور پر، 20 یا 30 سے زیادہ وزن اس بات کی علامت ہے کہ کچھ صارفین کا رجحان صفر کے قریب ہوتا ہے، جو سومی مفروضے کی خلاف ورزی کرتا ہے۔ ہر یونٹ میں پروسیسنگ اور کنٹرول تفویض دونوں کے لیے غیر صفر امکان ہونا چاہیے۔
ان صارفین کے پاس تقابلی جوابی حقائق کی کمی ہے، اور ان کا تجزیہ اس وقت کمزور ہو جاتا ہے جب ایک محاوراتی مشاہدہ کارآمد نتائج پر حاوی ہو جاتا ہے۔ اس چیک کو چھوڑنا یہ ہے کہ غیر معمولی رویے کے ساتھ ایک پاور صارف کس طرح ATE کو 15 فیصد پوائنٹس سے کم کر سکتا ہے۔
2. حد کو تراشنا
زیادہ سے زیادہ وزن مقرر کریں۔ مشاہدات جن کا وزن ٹرم کی حد سے زیادہ ہے ان کا وزن حد سے کم ہوتا ہے۔ عام انتخاب وزن کی تقسیم کا 95واں یا 99واں فیصد ہے۔
تراشنا فرق میں بڑی کمی کے لیے تھوڑی مقدار میں تعصب کا کاروبار کرتا ہے، جو کہ معمولی ماڈل کی غلط تصریح کے تحت بھی تخمینے کو مزید مستحکم بناتا ہے۔ اگر آپ چھوٹا نہیں کرتے ہیں تو، آپ کے ڈیٹا میں سب سے عجیب کیس ہیڈ لائن نمبر ہوگا۔
3. Covariate بیلنس پلاٹ
پروپینسٹی ماڈل میں تمام کوویریٹس کے لیے وزن کرنے سے پہلے اور بعد میں معیاری اوسط فرق کو پلاٹ کریں۔ ہدف |SMD| ہے۔ وزن کے بعد <0.1۔
ایک کوویریٹ جو وزن کے بعد بھی اس حد سے تجاوز کرتا ہے اس بات کی نشاندہی کرتا ہے کہ رجحان ماڈل علاج کی تفویض پر کوویریٹ کے اثر سے محروم ہے۔ یہ "لیکن ہم نے سب کچھ ایڈجسٹ کیا” بلائنڈ اسپاٹ چیک ہے۔
4. پلیسبو نتائج کی جانچ
ایسے نتائج کا انتخاب کریں جو علاج کی وجہ سے ثابت نہ ہوں، مثال کے طور پر علاج کے موجود ہونے سے پہلے علاج سے پہلے کے میٹرکس، اور ان پر پوری AIPW پائپ لائن چلائیں۔
اگر آپ کی پائپ لائن کا پلیسبو کے نتائج پر خاصا اثر پڑتا ہے، تو آپ کو کوئی مسئلہ ہے جیسے ناپید کنفاؤنڈرز، غلط بیان کردہ رجحان ماڈل، یا ڈیٹا کا لیک ہونا۔ پلیسبو کی ناکامی ایک واضح نشانی ہے کہ آپ کا پرکھ ناقابل اعتبار ہے، اور یہ وہ ہے جسے آپ پروڈکٹ لانچ کرنے سے پہلے حاصل کر سکتے ہیں۔
حوالہ کا نفاذ
ذیل کا کوڈ وزن کی تقسیم کی جانچ پڑتال اور تراشنے کے اقدامات کو ظاہر کرتا ہے جن کا اطلاق کازل تخمینہ پر بھروسہ کرنے سے پہلے Lyft کی پائپ لائن پر ہوتا ہے۔
import pandas as pd
import numpy as np
import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
from sklearn.linear_model import LogisticRegression
df = pd.read_csv("data/synthetic_llm_logs.csv")
# Estimate propensity for opt-in to agent mode
X = pd.get_dummies(
df[["engagement_tier", "query_confidence"]], drop_first=True
).astype(float)
y = df["opt_in_agent_mode"]
ps_model = LogisticRegression(max_iter=1000).fit(X, y)
df["propensity"] = ps_model.predict_proba(X)[:, 1]
# ATE weights: 1/P(treat) for treated, 1/(1-P) for control
df["ipw"] = np.where(
df.opt_in_agent_mode == 1,
1 / df.propensity,
1 / (1 - df.propensity),
)
# Diagnostic 1: weight distribution
print("IPW weight percentiles:")
for p in [50, 75, 90, 95, 99]:
print(f" {p}th pct: {np.percentile(df.ipw, p):.2f}")
fig, ax = plt.subplots(figsize=(8, 4))
ax.hist(df.ipw, bins=60, edgecolor="none", alpha=0.7)
ax.axvline(np.percentile(df.ipw, 99), color="red", linestyle="--",
label="99th pct (trim threshold)")
ax.set_xlabel("IPW weight")
ax.set_ylabel("Count")
ax.set_title("Weight distribution: check for extreme values")
ax.legend()
plt.tight_layout()
plt.savefig("weight_distribution.png", dpi=140)
print("Saved weight_distribution.png")
# Diagnostic 2: trim extreme weights at 99th percentile
trim_threshold = np.percentile(df.ipw, 99)
df["ipw_trimmed"] = df.ipw.clip(upper=trim_threshold)
# Compare ATE before and after trimming
def weighted_ate(data):
t = data[data.opt_in_agent_mode == 1]
c = data[data.opt_in_agent_mode == 0]
return (
(t.task_completed * t.ipw_trimmed).sum() / t.ipw_trimmed.sum()
- (c.task_completed * c.ipw_trimmed).sum() / c.ipw_trimmed.sum()
)
# Untrimmed ATE using ipw column
df["ipw_trimmed_orig"] = df["ipw"].copy() # backup before overwrite
ate_untrimmed = (
(df[df.opt_in_agent_mode==1].task_completed * df[df.opt_in_agent_mode==1].ipw).sum()
/ df[df.opt_in_agent_mode==1].ipw.sum()
- (df[df.opt_in_agent_mode==0].task_completed * df[df.opt_in_agent_mode==0].ipw).sum()
/ df[df.opt_in_agent_mode==0].ipw.sum()
)
ate_trimmed = weighted_ate(df)
print(f"nATE (untrimmed): {ate_untrimmed:+.4f}")
print(f"ATE (trimmed): {ate_trimmed:+.4f}")
print(f"Trim threshold: {trim_threshold:.2f}")
متوقع پیداوار:
IPW weight percentiles:
50th pct: 1.52
75th pct: 1.57
90th pct: 2.88
95th pct: 8.14
99th pct: 8.58
Saved weight_distribution.png
ATE (untrimmed): +0.0851
ATE (trimmed): +0.0852
Trim threshold: 8.58
شکل 2: 50,000 صارف مصنوعی ڈیٹاسیٹ کے لیے IPW وزن کی تقسیم۔ زیادہ تر وزن 1.0 اور 3.0 کے درمیان ہیں۔ 500 مشاہدات 8.58 کی 99ویں پرسنٹائل ٹرم کی حد سے زیادہ ہیں۔ تراشنا ATE کو 0.0001 تک بدل دیتا ہے، اس بات کو یقینی بناتا ہے کہ انتہائی وزن کا اس تخمینہ پر نہ ہونے کے برابر اثر پڑتا ہے۔ شکل 1 میں تصوراتی نقشے کے برعکس، یہ تشخیصی مشترکہ ڈیٹا سیٹ میں براہ راست حقیقی ڈیٹا پر چلتا ہے۔
یہاں کیا ہو رہا ہے: ایک پروپینسیٹی ماڈل فٹ کریں، ATE وزن کی گنتی کریں، اور پھر وزن کا ہسٹوگرام تیار کریں تاکہ یہ معلوم ہو سکے کہ آیا ایسے صارفین ہیں جن کا وزن زیادہ ہے جو اندازوں پر غالب ہے۔
99ویں پرسنٹائل لائن بصری ٹرم کی حد ہے۔ ٹرم لگائیں اور غیر تراشے ہوئے ATE کا تراشے ہوئے ATE سے موازنہ کریں۔ اگر قریب ہو تو، انتہائی وزن کا نتائج پر کم سے کم اثر پڑتا ہے۔ اگر وہ ایک دوسرے سے دور ہیں، تو آپ کے پاس اثر انگیز مشاہدات کے چھوٹے جھرمٹ ہوں گے اور کٹے ہوئے تخمینے زیادہ قابل اعتماد ہوں گے۔
2 گھنٹے کی تشخیص انجینئرنگ کی غلط کوششوں کے 1/4 کو روکتی ہے۔
مشاہدے کے نوشتہ جات سے کسی AI خصوصیت کے کازل اثر کی پیمائش کرتے وقت، ہم تقریباً ہمیشہ ایسی صورت حال میں ختم ہوتے ہیں جہاں پروپینسیٹی ماڈل اور نتیجہ کا ماڈل دونوں ہی غلطی کا شکار ہوتے ہیں۔ AIPW ڈھانچہ ان میں سے کسی ایک کے غلط ہونے سے بچاتا ہے۔ Lyft Diagnostic Toolkit آپ کو بتاتا ہے کہ ہر ماڈل پر اپنے اندازوں پر کارروائی کرنے سے پہلے کتنا بوجھ ہے۔
وزن کا ٹیسٹ اور پلیسبو ٹیسٹ چلانے سے وجہ کے تجزیہ میں تقریباً 2 گھنٹے کا اضافہ ہو سکتا ہے۔ وہ دو گھنٹے اس قسم کے پراعتماد لیکن غلط نتائج کو روک سکتے ہیں جو انجینئرنگ ٹیموں کو ایک چوتھائی تک غلط خصوصیت کا پیچھا کرنے پر مجبور کرتے ہیں، اور میں نے ایسا ہوتا دیکھا ہے۔ تشخیص کو چھوڑنے کی قیمت خلاصہ نہیں ہے۔ چھ انجینئرز کام کر رہے ہیں جو نتیجہ کی پیمائش کی وجہ نہیں ہے۔
کیس اسٹڈی 4: Uber کی Causal Prediction پائپ لائن
ضم ہونے کا سبب اور پیشین گوئیاں
causal analysis کے معیاری نتائج پوائنٹ تخمینے اور اعتماد کے وقفے ہیں۔ AI فیچر نے کام کی تکمیل کی شرح میں 6 فیصد پوائنٹس، 95% CI اضافہ کیا۔ [3.8, 8.2]. وہ نمبر پیچھے مڑ کر سوال کا جواب دیتا ہے۔ کیا ہوا؟
مصنوعات کے فیصلے منتظر ہیں۔ اگر آپ اپنے ماڈل کی روٹنگ کی حد کو 0.85 سے 0.90 تک بڑھانے پر غور کر رہے ہیں، تو آپ جاننا چاہیں گے کہ آنے والی سہ ماہیوں میں لاگت کے معیار کی تجارت کیسی نظر آئے گی۔ یہ ایک پیشین گوئی ہے جو ہم نے پچھلے مہینے کے تجربے سے سیکھی ہے۔
Uber انجینئرنگ بلاگ پر Totte Harinen اور Bonnie Li کی پوسٹ، "Using Causal Inference to Improve the Uber User Experience،” بیان کرتی ہے کہ Uber کس طرح پروڈکشن کے فیصلوں پر causal inference کا اطلاق کرتا ہے، جس سے مستقبل کے منظر نامے کے ماڈلز میں causal effect تخمینوں کو سرایت کرنے کی بنیاد فراہم کی جاتی ہے۔
ساختی اقدام پیشین گوئی کے پیرامیٹرز کے طور پر کارآمد تخمینوں کا علاج کرنا ہے۔ لاگت اور کوالٹی کا الگ الگ تخمینہ لگانا اور ان کے درمیان ایک مستحکم رشتہ فرض کرنا وجہ کے پیرامیٹرز کو غیر متعین کر دیتا ہے۔ ساختی اقدام لاگت کے معیار کی تجارت پر روٹنگ تھریشولڈ کے کازل اثر کو براہ راست ماڈل بنانا ہے اور پھر استفسار کے حجم، استفسار کی تقسیم، اور ماڈل کی صلاحیتوں کے بارے میں مختلف مفروضوں کی بنیاد پر اس کے پیرامیٹرز کی پیش گوئی کرنا ہے۔
یہ ایل ایل ایم سسٹمز کے لیے خاص طور پر اہم ہے کیونکہ روٹنگ کے فیصلوں اور اخراجات کے درمیان تعلق نان لائنر اور ڈسٹری بیوشن پر منحصر ہے۔ موجودہ استفسار کے حجم پر، لاگت سے موثر روٹنگ کی حد کو حجم کے 3x کے طور پر درجہ بندی کیا جا سکتا ہے۔ Q1 میں روٹنگ کو بہتر بنانے والے ماڈل کو Q3 میں ایک سستا ماڈل سے تبدیل کیا جا سکتا ہے، جس سے قیمت کے معیار کے Pareto فرنٹیئر کو مکمل طور پر تبدیل کیا جا سکتا ہے۔ پیشین گوئیوں میں کارآمد تخمینوں کو شامل کرنے سے ساختی تبدیلیاں ان کے آنے سے پہلے نظر آتی ہیں۔
حوالہ کا نفاذ
روٹنگ کی حد کے قریب مقامی موازنہ دو شناختی مفروضوں پر مبنی ہے۔ سب سے پہلے، انجینئرز اور صارفین اسے درستگی کے ساتھ نہیں چلا سکتے۔ query_confidence 0.85 کٹ آف کے ایک طرف کلسٹرز۔ تفویض بے ترتیب اور دہلیز کے ارد گرد ایک تنگ رینج کے اندر ہونا چاہیے۔
دوسرا، ممکنہ نتیجہ کا فنکشن کٹ آف میں مسلسل ہونا چاہیے، اس لیے 0.85 پر مشاہدہ کیا گیا جمپ روٹنگ اسائنمنٹ کی وجہ سے ہے نہ کہ اسی سکور کی سطح پر چلنے والی دیگر پالیسیوں کی وجہ سے۔
نیچے کا کوڈ پیٹرن کو ظاہر کرتا ہے۔ ہم لاگت اور معیار پر روٹنگ کی حد کو تبدیل کرنے کے کارگر اثر کا اندازہ لگاتے ہیں، اور پھر مستقبل کے حجم کے مختلف منظرناموں پر اثرات کی پیشین گوئی کرتے ہیں۔
import pandas as pd
import numpy as np
df = pd.read_csv("data/synthetic_llm_logs.csv")
# Step 1: Estimate causal effect of premium routing on quality and cost
# (Using RDD logic: compare users near the routing threshold)
cutoff = 0.85
bw = 0.10
near = df[
(df.query_confidence > cutoff - bw)
& (df.query_confidence < cutoff + bw)
].copy()
# Low-confidence queries route to premium model (below-threshold queries need stronger handling)
near["routed_premium"] = (near.query_confidence < cutoff).astype(int)
# Causal effects from the local comparison near the threshold
quality_effect = (
near[near.routed_premium == 1].task_completed.mean()
- near[near.routed_premium == 0].task_completed.mean()
)
cost_effect = (
near[near.routed_premium == 1].cost_usd.mean()
- near[near.routed_premium == 0].cost_usd.mean()
)
print(f"Estimated quality effect of premium routing: {quality_effect:+.4f}")
print(f"Estimated cost effect of premium routing: {cost_effect:+.4f}")
# Step 2: Embed into forward-looking scenarios
# Suppose we're evaluating: what if we raise threshold from 0.85 to 0.90?
# Queries with confidence 0.85 to 0.90 would shift from premium to cheap routing.
threshold_change_users = df[
(df.query_confidence >= 0.85) & (df.query_confidence < 0.90)
]
n_shifted = len(threshold_change_users)
print(f"nQueries that would shift at threshold 0.85 to 0.90: {n_shifted}")
# Volume scenarios (monthly queries)
monthly_query_volume = [500_000, 1_000_000, 2_000_000]
shifted_fraction = n_shifted / len(df) # fraction of total traffic shifted
print("nForward-looking scenario: raise threshold from 0.85 to 0.90")
print(f"{'Monthly volume':>20} {'Quality change':>16} {'Cost change ($/mo)':>20}")
for vol in monthly_query_volume:
n_affected = vol * shifted_fraction
delta_quality = quality_effect * n_affected / vol # rate change in overall quality
delta_cost = -cost_effect * n_affected # negative: saving cost by de-premiuming
print(f"{vol:>20,.0f} {delta_quality:>+16.4f} {delta_cost:>+20,.0f}")
متوقع پیداوار:
Estimated quality effect of premium routing: +0.0613
Estimated cost effect of premium routing: +0.0080
Queries that would shift at threshold 0.85 to 0.90: 5415
Forward-looking scenario: raise threshold from 0.85 to 0.90
Monthly volume Quality change Cost change ($/mo)
500,000 +0.0066 -436
1,000,000 +0.0066 -871
2,000,000 +0.0066 -1,742
یہ ہے کیا ہو رہا ہے: ہم روٹنگ کی حد کے قریب مقامی موازنہ کا استعمال کرتے ہوئے معیار (ٹاسک کی تکمیل) اور لاگت پر پریمیم روٹنگ کے کارگر اثر کا اندازہ لگاتے ہیں۔ اس کے بعد ہم سوالات کے فیصد کی نشاندہی کرتے ہیں جن کے لیے روٹنگ اسائنمنٹس تبدیل ہو جاتی ہیں جب حد 0.85 سے 0.90 تک منتقل ہو جاتی ہے۔
آخر میں، ہم مختلف ماہانہ استفسار کے حجم کے منظرناموں میں معیار اور لاگت پر ان تبدیلیوں کے اثرات کا اندازہ لگاتے ہیں۔ آؤٹ پٹ ایک منظر نامے کی میز ہے جسے پروڈکٹ یا فنانس ٹیم براہ راست پڑھ سکتی ہے۔ حد کو بڑھانے سے موجودہ حجم پر تقریباً $X فی مہینہ کی بچت ہوتی ہے اور کام کی تکمیل میں تقریباً Y فیصد پوائنٹس کی لاگت آتی ہے۔
صلاحیت کی منصوبہ بندی میں کارآمد پیش گوئی
روٹنگ اور انفراسٹرکچر کے فیصلوں کے لیے کارآمد پیشین گوئی کے نمونے سب سے زیادہ کارآمد ہوتے ہیں جہاں لاگت اور معیار کے اثرات دونوں اہم ہوتے ہیں اور ٹریفک کے حجم سے پہلے انتخاب کرنا چاہیے جو ابھی تک نہیں پہنچی ہیں۔ حجم کے منظرناموں میں کازل انفرنسز کو چلانا سابقہ نتائج کو قابل عمل پیشین گوئیوں میں بدل دیتا ہے۔
اگر آپ اس قدم کو چھوڑ دیتے ہیں، تو آپ کے کارآمد تخمینے تجزیہ دستاویز میں دفن ہو جائیں گے اور صلاحیت کی منصوبہ بندی اور قیمتوں کے فیصلوں سے منسلک نہیں ہوں گے۔ میں نے اسی وجہ سے مفید تجزیوں کو پڑھے بغیر دیکھا ہے۔ یہ پیمائش کی ٹیم کو ان پٹ پیدا کرنے کی اجازت دیتا ہے جو اصل میں پروڈکٹ کے چلنے کے طریقہ سے متعلق ہے۔
ان چار ٹیموں میں کیا مشترک ہے۔
اگرچہ ان چاروں ٹیموں نے مختلف طریقے بنائے، لیکن وہ ایک ہی آپریٹنگ اصولوں پر اکٹھے ہوئے۔
ایک ایسا طریقہ منتخب کریں جو آپ کی تعیناتی کے ڈھانچے کے مطابق ہو۔
ہم مختص کرنے کے طریقہ کار سے شروع کرتے ہیں (علاج کیسے مختص کیا گیا تھا؟) اور شناخت کی حکمت عملی پر پیچھے کی طرف کام کرتے ہیں۔ Airbnb نے قلیل مدتی A/B ٹیسٹنگ پاس کی ہے کیونکہ یہ خصوصیت 30 دنوں سے زیادہ طویل مدتی قدر کو متاثر کرتی ہے۔ Netflix اپنے تھریشولڈ روٹنگ سسٹم کے لیے RDD استعمال کرتا ہے۔ اس کی وجہ یہ ہے کہ کٹ آف ایک قدرتی شناخت کی حکمت عملی ہے۔
آپ کے سسٹم کے ڈیزائن پر منحصر ہے، اس بات کو یقینی بنانے کے لیے ایک تکنیک کا انتخاب کریں کہ آپ کسی خاص شناختی حکمت عملی پر بھروسہ کر سکتے ہیں۔ جو ٹیم بہتر طور پر جانتی ہے اس کے مطابق شناخت کی غلطیاں کیسے ہوتی ہیں، اور یہ غلطیاں خود اعلان نہیں کرتیں۔
تخمینہ لگانے والے کی تعمیر سے پہلے تشخیص کی تعمیر
تخمینہ کی اطلاع دینے سے پہلے گھر کا معائنہ کریں۔ Airbnb تاریخی گروہوں کے خلاف اپنے سرکردہ اشارے ماڈل کی توثیق کرتا ہے۔ لیفٹ مشاہداتی تخمینے چلانے سے پہلے وزن کی تقسیم اور پلیسبو ٹیسٹ چلاتا ہے۔
تشخیصی پرت کے بغیر رپورٹ کیے گئے تخمینے ناقابلِ دفاع تخمینے ہیں۔ یہ امتیاز اس وقت اہم ہوتا ہے جب آپ کی پروڈکٹ ٹیم سہ ماہی جائزوں میں آپ کے نمبروں کو چیلنج کرتی ہے۔
مصنوعات کے مخصوص فیصلوں کے لیے تمام کارآمد نتائج کو ڈیزائن کریں۔
Airbnb فیچر کی پیشکش کے فیصلوں کو مطلع کرنے کے لیے طویل مدتی قدر کا تخمینہ لگاتا ہے۔ Netflix لانچ کے فیصلے کرنے کے لیے نیم تجربات کرتا ہے۔
کوئی بھی تجزیہ جو آپ کے مخصوص پروڈکٹ کے انتخاب کو بہتر نہیں کرتا ہے وہ چلانے کے قابل نہیں ہے۔ یہ تجزیہ کاروں کا وقت خرچ کرتا ہے، رپورٹنگ بیک لاگ میں غلط سگنل پیدا کرتا ہے، اور وقت کے ساتھ ساتھ آپ کی پیمائش کی صلاحیتوں پر اسٹیک ہولڈر کے اعتماد کو ختم کرتا ہے۔
تمام حوالوں کے ساتھ دستاویز کی ناکامی کا موڈ
ہر تکنیک کے پاس ان طریقوں کی ایک نامزد فہرست ہوتی ہے جس میں اس کی خلاف ورزی کی جا سکتی ہے: DiD میں غیر متوازی رجحانات، RDD میں کٹ آف ہیرا پھیری، رجحان کے طریقوں میں ناپید الجھنے والے عوامل، پوری آبادی کو اپ گریڈ کرنے کے لیے موزوں ناقص مصنوعی کنٹرول، وغیرہ۔
لیبل شدہ ناکامی کی شرائط کے ساتھ ایک اقتباس بھیجیں۔ ایک شکی سامعین کے لیے تجزیے کی ساکھ خود اعتمادی کے وقفوں سے نہیں، بلکہ ان مخصوص مفروضوں کے بارے میں شفاف ہونے سے ہوتی ہے جنہیں تخمینہ کے ناکام ہونے کے لیے باطل کرنا ضروری ہے۔
اسے اپنے LLM اسٹیک پر کیسے لاگو کریں۔
ایل ایل ایم کی زیادہ تر ٹیمیں پختہ وجہ پائپ لائن کے ساتھ شروع نہیں ہوتی ہیں۔ نیچے دیئے گئے اقدامات کو اثر کے لحاظ سے ترتیب دیا گیا ہے۔
1. ضرورت سے پہلے ڈیٹا کی پیمائش کریں۔
کسی بھی مشاہداتی وجہ تجزیہ کی سب سے بڑی حد یہ ہے کہ ضروری ڈیٹا اکٹھا نہیں کیا جاتا۔ مرحلہ وار رول آؤٹ میں ڈی ڈی کو چلانے کے لیے دونوں آبادیوں کے لیے ڈیٹا کو پری پروسیسنگ کی ضرورت ہوتی ہے۔
آپٹ ان خصوصیات پر AIPW کو چلانے کے لیے covariates کے ایک بھرپور سیٹ کی ضرورت ہوتی ہے جو آپٹ ان کی پیش گوئی کرتے ہیں۔
سیشن کی لمبائی، استفسار کی پیچیدگی، 7 دن کی واپسی کی شرح، اور ماڈل روٹنگ کے فیصلے سمیت ان تجزیوں کے لیے آج ہی اپنے سسٹم کو 6 ماہ میں چلانا چاہتے ہیں۔ اگرچہ سامان سستا ہے، لیکن سابقہ ڈیٹا اکٹھا کرنا ممکن نہیں ہے۔
2. تقسیم کے طریقہ کار کی درجہ بندی
Netflix درجہ بندی کو ان تمام AI خصوصیات پر لاگو کریں جو فی الحال آپ کی مصنوعات میں چل رہی ہیں۔ ہر خصوصیت کے لیے، درج ذیل سوالات پوچھیں: علاج کیسے تفویض کیا گیا؟ یہ مختص کرنے کا طریقہ کار کن وجوہات کی حمایت کرتا ہے؟
آپ کے کلیدی مفروضے کیا ہیں، اور کیا آپ کے پاس ان کی تصدیق کے لیے ڈیٹا موجود ہے؟ پریکٹس سے پتہ چلتا ہے کہ عام طور پر زیادہ تر خصوصیات کو ایسے ٹولز کے استعمال سے ماپا جاتا ہے جو مختص کرنے کے طریقہ کار سے میل نہیں کھاتے ہیں۔ اختلاف علمی نہیں ہے۔ اس کا مطلب ہے کہ آپ نہیں جانتے کہ یہ فیچر کام کرے گا یا نہیں۔
3. تشخیصی سے بھرپور کازل تجزیہ چلائیں۔
ایک خصوصیت چنیں، بیلنس چیک اور پلیسبو ٹیسٹ چلائیں، تفصیلات کے انتخاب کے لیے تناؤ کی حساسیت کی جانچ کریں، اور نتائج لکھیں۔ تمام چیکوں کو ایک بار چلانے سے مستقبل کے تجزیہ کے لیے ایک نمونہ قائم ہوتا ہے۔
مزید برآں، اس خصوصیت کے لیے عام طور پر ایک تکلیف دہ نتیجہ ہوتا ہے جس کے بارے میں آپ کو زیادہ اعتماد ہے۔ میں نے یہ تین الگ الگ ٹیموں میں ہوتے دیکھا ہے۔ ایک خصوصیت جو "بظاہر کام کرتی ہے” ایک مبہم موازنہ گروپ بنتی ہے۔
4. قلیل مدتی اور طویل مدتی میٹرکس کو الگ کریں۔
Airbnb کی مثال پر عمل کریں اور طویل مدتی قدر کے کم از کم ایک سرکردہ اشارے کی نشاندہی کریں جس کی پیمائش 30 دن کے تجرباتی عرصے میں کی جا سکتی ہے۔ 7 دن کی برقراری، 3 ہفتے کی واپسی کے استفسار کی شرح، یا اضافے کی شرح کی رفتار سبھی امیدوار ہیں۔
ہر تجربے کے خلاصے میں فوری منگنی میٹرکس کے ساتھ اس کی اطلاع دیں۔ اس کے بغیر، آپ اپنی پراکسی کو بہتر بناتے ہیں اور اگلی سہ ماہی میں برقرار رکھنے کی شرحوں میں فرق تلاش کرتے ہیں۔
5. مستقبل پر مبنی causal رشتہ کا تخمینہ
جب آپ ایک وجہ کا تخمینہ بناتے ہیں، تو آپ ایک لائن شامل کرتے ہیں: "موجودہ حجم کے 3 گنا سے بھی کم، اس اثر کا مطلب ہے X۔” ترجمہ کا یہ مرحلہ اینالیٹکس کو انفراسٹرکچر اور پروڈکٹ پلانز سے جوڑتا ہے اور تجزیات کو پڑھنے والے کو تبدیل کرتا ہے۔
جب پیداوار کازل پائپ لائن میں خلل پڑتا ہے۔
پروڈکشن کازل پائپ لائن کئی ممکنہ جگہوں پر ٹوٹ جاتی ہے۔
تنظیمی ناکامی
سب سے پہلے، کوئی بھی پیمائش کے ڈیزائن کا مالک نہیں ہے۔ زیادہ تر ٹیموں میں، ڈیٹا سائنسدان خصوصیات کے جاری ہونے کے بعد تجزیات لکھتے ہیں۔ چونکہ یہ معیاری ورک فلو ہے، آپ ہمیشہ ایسے ڈیٹا پر سابقہ تجزیے کرتے رہیں گے جو وجہ کی شناخت کے لیے نہیں بنائے گئے ہیں۔
حل فیچر ریلیز سے پہلے پیمائش کے ڈیزائن کا جائزہ ہے۔ کنٹرول گروپ کون ہے، پچھلی مدت کتنی ہے، کلیدی مفروضے کیا ہیں، اور کون سی تشخیص ان کو غلط ثابت کرے گی؟ 30 منٹ کا جائزہ عام قسم کے تجزیوں سے گریز کرتا ہے جن کی مرمت نہیں کی جا سکتی۔
دوسرا، نتیجہ خیز نتائج فیصلہ سازوں کو نہیں بتائے جاتے ہیں۔ اچھے کارنامے جو کہ پروڈکٹ کے فیصلوں کو مطلع نہیں کرتے ہیں ناکام تجزیہ ہوتے ہیں چاہے اعداد و شمار درست ہوں۔ بہتر طریقہ کار اس مسئلے کو حل نہیں کر سکتا۔ کازل پائپ لائنوں کو سخت رپورٹنگ کے ساتھ ساتھ فاسٹ ٹریک رپورٹنگ کی ضرورت ہوتی ہے۔
تکنیکی ناکامی
سب سے پہلے، پیمائش کے فرق کو حقیقت کے بعد دریافت کیا جاتا ہے۔ سب سے عام تکنیکی ناکامی غیر ریکارڈ شدہ کوواریٹس کی ضرورت ہے۔ تجربہ ختم ہونے کے تین ہفتے بعد، جب آپ بیلنس چیک کرنے یا رجحان کا ماڈل چلانے کی کوشش کرتے ہیں تو آپ کو فرق نظر آتا ہے۔
اوپر دیے گئے آلات کے ابتدائی اصول اس مسئلے کو حل کرتے ہیں، لیکن انہیں ایونٹ لاگنگ کو ترجیح دینے کے لیے بنیادی ڈھانچے کی ٹیم سے خریداری کی ضرورت ہوتی ہے جو براہ راست پروڈکٹ ڈیش بورڈ فراہم کرنے کی طرح کازل تجزیہ فراہم کرتا ہے۔ یہ خریدنا خود لاگ ان کرنے سے زیادہ مشکل ہے۔
دوسرا، مصنوعی ڈیٹاسیٹ میں علاج کا رساو ہے۔ مصنوعی یا اندرونی ڈیٹا پر کازل طریقوں کی جانچ کرنے والی ٹیموں کے لیے، کوئی بھی طریقہ نادانستہ طور پر ان کازل اثرات کو لاگو کرکے کام کرتا دکھائی دے سکتا ہے جن کا وہ ڈیٹا بنانے کے عمل کے دوران اندازہ لگانے کی کوشش کر رہے ہیں۔
تخلیق ونڈو کے باہر بیرونی ہولڈ آؤٹ ڈیٹا یا کوہورٹس پر تجزیہ کی توثیق کریں۔ یہ یاد کرنا آسان ہے کیونکہ مصنوعی ڈیٹا صاف نظر آتا ہے۔ اعداد و شمار کی ایک قطار کے اندر ساختی آلودگی ٹھیک ٹھیک اور پتہ لگانا مشکل ہو سکتا ہے۔
تشریح میں ناکامی
سب سے پہلے، یہ لیٹ اور ATE کو یکجا کرتا ہے۔ RDD مقامی اوسط علاج کے اثر (LATE) کا تخمینہ لگاتا ہے، یعنی حد کے قریب کسی خاص صارف کے لیے کٹ آف اثر۔ رجحان سے مماثل تخمینہ ATT: علاج کرنے والے صارفین پر اثرات۔ پوری آبادی کے لیے ATE ایک مختلف نقطہ نظر کی ضرورت ہے۔
جب ایک وزیر اعظم پوچھتا ہے "اس خصوصیت کا کیا اثر ہے؟” ان کا مطلب عام طور پر ATE ہے۔ اگر اختلافات کا محاسبہ کیے بغیر وجہ کے تجزیہ میں تاخیر ہوتی ہے، تو تخمینے ان فیصلوں پر لاگو کیے جائیں گے جن کی حمایت کے لیے وہ ڈیزائن نہیں کیے گئے تھے، اور نتیجے میں آنے والے پروڈکٹ کے انتخاب ان طریقوں سے غلط ہوں گے جن کا تجزیہ تک واپس نہیں لایا جا سکتا۔
دوسرا، یہ ایک خارجی جواز کا مفروضہ ہے جو نہیں رکھتا۔ پچھلی سہ ماہی کی صارف کی آبادی کے سبب کے تخمینے اگلی سہ ماہی تک عام نہیں ہوسکتے ہیں، خاص طور پر اگر ہم نئے حصوں میں پھیل جائیں یا بین الاقوامی منڈیوں میں داخل ہوں۔
چونکہ یہ خصوصیت ہلکے سے مصروف صارفین کے لیے رول آؤٹ ہوتی ہے، یہ پاور صارفین کے لیے متوقع اثر ہے جو جلد انتخاب کرتے ہیں۔ اس آبادی کو دستاویز کریں جس پر آپ کا تخمینہ لاگو ہوتا ہے۔ اس آبادی سے باہر درخواست دینے کی کوشش کرتے وقت واضح طور پر جھنڈا لگائیں۔
تیسرا، رپورٹنگ کی درستگی یقین سے بالاتر ہے۔ مبہم ہونے کے بقایا خطرے کے ساتھ مشاہداتی مطالعات سے رپورٹ کردہ دو اعشاریہ کی درستگی کے ساتھ کازل تخمینے تجزیہ کے وارنٹ سے زیادہ یقین کا اظہار کرتے ہیں۔
پوائنٹ کے تخمینے، ان کے اعتماد کے وقفوں کے ساتھ، ان مفروضوں پر جن پر وہ انحصار کرتے ہیں، اور وزنی تجارت کے بارے میں یہ سب ایک خلاصے میں رپورٹ کیے گئے ہیں جسے فیصلہ ساز حقیقت میں دیکھ سکتے ہیں۔ تجزیہ اس وقت تک مکمل نہیں ہوتا جب تک کہ تجزیہ کرنے والے غیر یقینی صورتحال کو نہ دیکھیں۔
بوٹسٹریپ اعتماد کا وقفہ
مشاہداتی تجزیوں سے نقطہ تخمینہ نمونے لینے کی غیر یقینی صورتحال سے مشروط ہیں۔ نیچے دیا گیا بوٹسٹریپ (500 تکرار، بیج = 7) اس مضمون میں تین عددی تخمینوں کے لیے 95% اعتماد کے وقفے فراہم کرتا ہے: مستقبل کے ویلیو اسکورز پر Airbnb DiD کا اثر، Lyft IPW ATE، اور Uber RDD کوالٹی اثر۔
import pandas as pd
import numpy as np
from sklearn.linear_model import LinearRegression, LogisticRegression
rng = np.random.default_rng(7)
df = pd.read_csv("data/synthetic_llm_logs.csv")
n_boot = 500
# Bootstrap 1: DiD on future-value score (Airbnb)
historical = df[df.signup_week < 10].copy()
feature_cols = ["task_completed", "thumbs_up", "session_minutes"]
fv_model = LinearRegression().fit(historical[feature_cols].fillna(0), historical["retained_7d"].values)
df["future_value_score"] = fv_model.predict(df[feature_cols].fillna(0))
analysis = df[df.signup_week < 30].copy()
analysis["post"] = (analysis.signup_week >= 20).astype(int)
analysis["treated"] = (analysis.wave == 1).astype(int)
did_boots = []
for _ in range(n_boot):
s = analysis.sample(frac=1, replace=True, random_state=rng.integers(1e9))
c = s.groupby(["treated", "post"]).future_value_score.mean()
try:
did_boots.append((c.loc[(1, 1)] - c.loc[(1, 0)]) - (c.loc[(0, 1)] - c.loc[(0, 0)]))
except KeyError:
pass
ci_did = np.percentile(did_boots, [2.5, 97.5])
print(f"DiD future-value 95% CI: [{ci_did[0]:+.4f}, {ci_did[1]:+.4f}]")
# Bootstrap 2: IPW ATE trimmed (Lyft)
X = pd.get_dummies(df[["engagement_tier", "query_confidence"]], drop_first=True).astype(float)
ps_model = LogisticRegression(max_iter=1000).fit(X, df["opt_in_agent_mode"])
df["propensity"] = ps_model.predict_proba(X)[:, 1]
df["ipw"] = np.where(df.opt_in_agent_mode == 1, 1 / df.propensity, 1 / (1 - df.propensity))
trim_thr = np.percentile(df.ipw, 99)
df["ipw_trimmed"] = df.ipw.clip(upper=trim_thr)
ate_boots = []
for _ in range(n_boot):
s = df.sample(frac=1, replace=True, random_state=rng.integers(1e9))
t = s[s.opt_in_agent_mode == 1]
c = s[s.opt_in_agent_mode == 0]
ate_boots.append(
(t.task_completed * t.ipw_trimmed).sum() / t.ipw_trimmed.sum()
- (c.task_completed * c.ipw_trimmed).sum() / c.ipw_trimmed.sum()
)
ci_ate = np.percentile(ate_boots, [2.5, 97.5])
print(f"IPW ATE trimmed 95% CI: [{ci_ate[0]:+.4f}, {ci_ate[1]:+.4f}]")
# Bootstrap 3: RDD quality effect near routing cutoff (Uber)
cutoff = 0.85
bw = 0.10
near = df[(df.query_confidence > cutoff - bw) & (df.query_confidence < cutoff + bw)].copy()
near["routed_premium"] = (near.query_confidence < cutoff).astype(int)
qe_boots = []
for _ in range(n_boot):
s = near.sample(frac=1, replace=True, random_state=rng.integers(1e9))
qe_boots.append(
s[s.routed_premium == 1].task_completed.mean()
- s[s.routed_premium == 0].task_completed.mean()
)
ci_qe = np.percentile(qe_boots, [2.5, 97.5])
print(f"RDD quality effect 95% CI: [{ci_qe[0]:+.4f}, {ci_qe[1]:+.4f}]")
متوقع پیداوار:
DiD future-value 95% CI: [+0.0023, +0.0093]
IPW ATE trimmed 95% CI: [+0.0727, +0.0966]
RDD quality effect 95% CI: [+0.0490, +0.0748]
یہاں کیا ہو رہا ہے: تین الگ الگ بوٹسٹریپ لوپس ہر ایک مشترکہ بیج کا استعمال کرتے ہوئے تجزیہ ڈیٹاسیٹ کو 500 بار دوبارہ نمونہ دیتے ہیں۔
DiD بوٹسٹریپ پورے تجزیہ کار کو دوبارہ نمونہ بناتا ہے اور 2x2 سیل کے ذرائع کا دوبارہ حساب کرتا ہے۔ وقفہ [+0.0023, +0.0093] ہم تصدیق کرتے ہیں کہ مستقبل کی قدر کا اثر شماریاتی اعتبار سے صفر سے ممتاز ہے۔
IPW ATE بوٹسٹریپ تمام 50,000 صارفین کو دوبارہ نمونے دیتا ہے اور ہر قرعہ اندازی کو ری ویٹ کرتا ہے۔ وقفہ [+0.0727, +0.0966] زمینی سچائی +0.08 آپٹ ان اثرات کا احاطہ کرتا ہے اور 0 کو خارج کرتا ہے۔
RDD بوٹسٹریپ صرف ان صارفین کو دوبارہ نمونے دیتا ہے جو 0.85 کٹ آف کے ارد گرد بینڈوڈتھ ونڈو کے اندر ہیں۔ وقفہ [+0.0490, +0.0748] اس بات کو یقینی بناتا ہے کہ مقامی معیار کا اثر غیر صفر ہے۔
تینوں وقفے قابل عمل ہونے کے لیے کافی تنگ ہیں اور مشاہداتی تخمینوں میں غیر یقینی کی عکاسی کرنے کے لیے کافی وسیع ہیں۔ اگر آپ ان وقفوں میں سے کسی ایک کے بغیر پوائنٹ کے تخمینے کی اطلاع دیتے ہیں، تو آپ اسٹیک ہولڈرز کے جذب کردہ خطرے کو کم کر رہے ہیں۔
نوٹ بک چلانے کے بعد، مندرجہ ذیل خصوصیات کو آلہ بنانے کی کوشش کریں:
اس مضمون کی ساتھی نوٹ بک github.com/RudrenduPaul/product-experimentation-causal-inference-genai-llm/tree/main/13_case_studies/ پر ہے۔ ریپوزٹری کو کلون کریں، اوپر دی گئی شرط کا استعمال کرتے ہوئے ایک مصنوعی ڈیٹاسیٹ بنائیں، اور اسے چلائیں۔ case_studies_demo.ipynb ہم اس مضمون سے تمام کوڈ بلاکس کو دوبارہ پیش کرتے ہیں، بشمول چار کیس اسٹڈی کے نفاذ اور بوٹسٹریپ کی توثیق۔ اس میں فیصلہ سازی کا فنکشن بھی شامل ہے جو Netflix درجہ بندی کو مزید مکمل طریقہ انتخاب گائیڈ میں پھیلاتا ہے۔
چار کیس اسٹڈیز کے لیے اصل مواد براہ راست ہر ٹیم کے انجینئرنگ بلاگ پر پایا جا سکتا ہے۔
-
جینی چن کی فیوچر ویلیو پوسٹ آن ہے (ایئر بی این بی ٹیکنالوجی بلاگ)۔
-
نیم تجرباتی درجہ بندی (Netflix Technology Blog) پر مل سکتی ہے۔
-
ناصری کی دوگنا طاقتور توثیق (Lyft Engineering) پر دستیاب ہے۔
-
(Uber انجینئرنگ) میں Harinen اور Li کا causal inference کا جائزہ ہے۔
یہ اصل پڑھنے کے قابل ہے۔ یہ پیداواری نظام کو تفصیل سے بیان کرتا ہے جسے خلاصہ میں مکمل طور پر نہیں لیا جاسکتا۔
وہ ٹیمیں جو قابل اعتماد طریقے سے AI اثرات کی پیمائش کرتی ہیں ایک مشق کا اشتراک کرتی ہیں: مختص کرنے کے طریقہ کار سے مماثل طریقے، تخمینوں پر بھروسہ کرنے سے پہلے تشخیص کو چلانا، اور فیصلے کی کھڑکی بند ہونے سے پہلے نتیجہ خیز نتائج کو فیصلوں سے جوڑنا۔
رکاوٹ تقریبا ہمیشہ آلہ ہے. وہ ڈیٹا جس پر یہ تجزیہ انحصار کرتا ہے اس خصوصیت کے جاری ہونے سے پہلے موجود ہونا چاہیے۔ یہ وہ خلا ہے جسے اوپر والا فریم ورک پُر نہیں کر سکتا، اور یہی وجہ ہے کہ ٹولز کے ابتدائی مراحل پہلے آتے ہیں۔