ایک تحقیقی ٹیم نے یہ فیصلہ کرنے کے لیے ایک راؤٹر بنایا کہ آیا ایک سستا لینگویج ماڈل کوڈنگ کی درخواست کو سنبھال سکتا ہے یا نہیں، جس کا مقصد انفرنس (inference) کے اخراجات کو کم کرنا تھا، لیکن راؤٹر "never-escalate" کے بنیادی معیار (baseline) کو شکست دینے میں ناکام رہا۔ یہ ناکامی ظاہر کرتی ہے کہ کیوں درستگی پر مبنی پیمانے (accuracy-centric metrics) کیسکیڈز (cascades) کو گمراہ کرتے ہیں اور ان اشاروں (signals) کی طرف اشارہ کرتی ہے جو اصل میں مشکل کو درست طور پر ظاہر کرتے ہیں۔
راؤٹر کیوں اہم تھا
ماڈل کیسکیڈز ہر درخواست کو اس سب سے چھوٹے ماڈل کو بھیجتے ہیں جو اسے درست طریقے سے جواب دے سکے۔ اگر راؤٹر ایک سادہ پرامپٹ کو سستے ماڈل کو بھیجتا ہے، تو سسٹم بڑے ماڈل کے لیے درکار مہنگے کمپیوٹ (compute) کو چھوڑ دیتا ہے۔ ٹیم نے 539 حقیقی کوڈنگ ٹاسک—428 آسان اور 111 مشکل—پر ایک راؤٹر کو تربیت دی، اس امید کے ساتھ کہ یہ سیکھ لے گا کہ کب سستا ماڈل کافی ہوگا۔
وہ اعداد و شمار جو ناکام رہے
- Held-out AUC (ROC کرو کے نیچے کا رقبہ): 0.594
- 5-fold کراس ویلیڈیشن رینج: 0.55 – 0.57
- بہترین تھریش ہولڈ (threshold): "never escalate" کی پالیسی سے مطابقت رکھتا ہے
Held-out AUC 0.594 تھا اور کراس ویلیڈیشن 0.55 سے 0.57 کے درمیان رہی، جس کا مطلب ہے کہ کلاسیفائر بمشکل آسان اور مشکل کیسز کے درمیان فرق کر پاتا ہے۔ جب بہترین تھریش ہولڈ ایسی پالیسی کو دوبارہ پیدا کرتا ہے جو کبھی بھی مہنگے ماڈل کا استعمال نہیں کرتی، تو راؤٹر کوئی قدر (value) پیدا نہیں کرتا۔ یہ فیصلہ ساز کے بجائے ایک مستقل پیش گوئی کرنے والے (constant predictor) کی طرح کام کرتا ہے۔
تجربات نے کن چیزوں کا جائزہ لیا
محققین نے فیچر سیٹس (feature sets) کے تین مجموعوں کا موازنہ کیا:
| فیچر سیٹ | AUC |
|---|---|
| 11 سادہ سطحی فیچرز (مثلاً، ٹوکن کی تعداد، کلیدی الفاظ کی موجودگی) | 0.610 |
| 1024-ڈائمنشنل پرامپٹ ایمبیڈنگ (سیمنٹک ویکٹر) | 0.552 |
| دونوں کا مجموعہ | 0.609 |
حیرت انگیز طور پر، ہلکے پھلکے سطحی فیچرز نے ہائی ڈائمنشنل سیمنٹک ایمبیڈنگ سے بہتر کارکردگی دکھائی۔ ایمبیڈنگ نے پرامپٹ کے موضوع کو تو پکڑا لیکن اس کی اصل مشکل کو نہیں۔ سستے ماڈل کے ڈرافٹ کو راؤٹر کو فراہم کرنے سے AUC بڑھ کر 0.640 ہو گیا، جو یہ ظاہر کرتا ہے کہ جن اشاروں کا ظہور جنریشن (generation) کے دوران ہوتا ہے وہ صرف پرامپٹ میں موجود اشاروں کے مقابلے میں زیادہ معلوماتی ہوتے ہیں۔
دو بنیادی غلطیاں
1. درستگی (Accuracy) غلط پیمانہ ہے
ایک راؤٹر کو محض درستگی کی پیش گوئی کرنے کے بجائے، ایک سادہ پالیسی کے مقابلے میں لاگت اور درستگی کے توازن (cost-accuracy trade-off) کو بہتر بنانا چاہیے۔ اگر یہ "never escalate" سے بہتر کارکردگی نہیں دکھا سکتا، تو خام درستگی کے باوجود یہ لاگت میں کوئی فائدہ نہیں دیتا۔ AUC جیسے روایتی پیمانے کیسکیڈ کے معاشی پہلو کو نظر انداز کرتے ہیں۔
2. "Always escalate" آخری حد نہیں ہے
تجربے میں یہ فرض کیا گیا کہ مہنگا ماڈل ناقابلِ خطا ہے، اور "ہمیشہ بڑے ماڈل کا استعمال کریں" کو بالائی حد (upper bound) سمجھا گیا۔ حقیقت میں، بڑا ماڈل کبھی کبھی ان جوابات کو خراب کر دیتا تھا جو سستا ماڈل درست طریقے سے دے رہا تھا۔ ایک بہترین راؤٹر جو یہ جانتا ہو کہ کب سستے ماڈل کے ساتھ رہنا ہے، وہ منتخب کردہ لاگت کے پیمانے میں "always escalate" کے معیار کو تقریباً 4.2 پوائنٹس سے پیچھے چھوڑ سکتا ہے۔ یہ فرق ظاہر کرتا ہے کہ مہنگے ماڈل کی کارکردگی کی حد مفروضے سے کم ہے۔
بہتر روٹنگ اشاروں کی ڈیزائننگ
نتائج تین عملی سمتوں کی تجویز دیتے ہیں:
- جنریشن کے وقت کے اشارے شامل کریں۔ سستے ماڈل کے درمیانی آؤٹ پٹ (اس کے ڈرافٹ) کو راؤٹر کو فراہم کرنے سے وہ مشکل پکڑی جا سکتی ہے جو صرف پرامپٹ میں چھپی رہتی ہے۔
- ٹاسک کے مخصوص سطحی فیچرز کو ترجیح دیں۔ سادہ پیمانے—جیسے لمبائی، مخصوص آپریٹرز کی موجودگی، یا کوڈ اسٹائل کے نشانات—عام سیمنٹک ایمبیڈنگز کے مقابلے میں زیادہ پیش گوئی کرنے والے ہو سکتے ہیں۔
- لاگت سے آگاہ پیمانوں کے ساتھ کامیابی کی پیمائش کریں۔ خالص درستگی یا AUC کے بجائے، اس بات کا جائزہ لیں کہ مطلوبہ معیار برقرار رکھتے ہوئے کتنی مہنگی کالز سے بچا گیا۔
حاصلِ کلام: ایسا راؤٹر جو صرف درستگی کے لیے کام کرتا ہے وہ لاگت میں بچت کی ضمانت نہیں دے سکتا؛ مؤثر روٹنگ کے لیے جنریشن کے وقت کے شواہد اور لاگت سے آگاہ جائزے کی ضرورت ہوتی ہے۔