ایک انفرادی ڈویلپر کے تین Claude ماڈلز کے ساتھ کیے گئے تجربے نے ماہانہ API اخراجات میں 35% کی کمی کی اور اوسط ٹاسک لیٹنسی (latency) کو 42 سیکنڈ سے کم کر کے 27 سیکنڈ کر دیا۔ سادہ اور کم ابہام (low-ambiguity) والے کاموں کو سستے Haiku ماڈل کو، معمول کے کاموں کو Sonnet کو، اور بھاری بھرکم Opus کو اہم اور پیچیدہ مسائل کے لیے مخصوص کر کے، مصنف نے یہ ثابت کیا کہ "ہر چیز کے لیے بہترین ماڈل" کا استعمال ایک مہنگا طریقہ ہے۔
روٹنگ کیوں اہم تھی
مصنف ایک خود مختار کوڈنگ ایجنٹ چلاتا ہے جسے ڈویلپمنٹ کے کاموں کا مسلسل سلسلہ ملتا رہتا ہے—جیسے کہ lint fixes، فیچر کا اضافہ، سیکیورٹی ریویوز، اور گہری ڈیبگنگ سیشنز۔ مہینوں تک یہ ایجنٹ ہر درخواست Claude کے سب سے زیادہ قابل ماڈل Opus کو بھیجتا رہا، یہ سمجھتے ہوئے کہ اعلیٰ معیار ہمیشہ قیمت پر فوقیت رکھے گا۔ Opus فی ٹوکن (token) ایک زیادہ قیمت لیتا ہے، جس کی وجہ سے بل مسلسل بڑھتا گیا۔
جب مصنف نے درجہ بندی شدہ روٹنگ اسکیم (tiered routing scheme) متعارف کرائی، تو اخراجات اصل سطح کے 65% تک گر گئے اور کل کاموں میں Opus کا استعمال کم ہو کر صرف 11% رہ گیا۔
تین درجوں والا نظام کیسے کام کرتا ہے
روٹنگ کا منطق (logic) ابہام (ambiguity) پر منحصر ہے، نہ کہ اس بات پر کہ ایک ٹاسک میں کوڈ کی کتنی لائنیں شامل ہیں۔ مصنف نے تین کیٹیگریز (buckets) متعارف کرائیں:
- Haiku – کم ابہام والے، یقینی (deterministic) کام۔ مثال کے طور پر: lint وارننگز کو ٹھیک کرنا، ویری ایبلز کا نام بدلنا، لاگ فائلوں کا خلاصہ کرنا۔ درست جواب عام طور پر کوڈ یا متن کی ایک ہی لائن ہوتا ہے۔
- Sonnet – ڈیفالٹ ورک ہارس (workhorse)۔ یہ فیچر کی تکمیل، معمول کے بگ فکسز، اور معیاری ریفیکٹرنگ (refactors) کو سنبھالتا ہے جہاں مسئلہ واضح ہو لیکن حل میں کئی مراحل شامل ہوں۔
- Opus – اہم اور زیادہ ابہام والے کام۔ آرکیٹیکچر کے فیصلے، سیکیورٹی آڈٹ، پیچیدہ ڈیبگنگ سیشنز، یا کوئی بھی ایسا کام جہاں درست راستہ غیر واضح ہو اور ایک غلطی پورے پائپ لائن کو خراب کر سکتی ہو۔
ایک اسٹیٹک لک اپ ٹیبل (static lookup table) ان اصولوں کی بنیاد پر ہر آنے والی درخواست کو مناسب ماڈل کے ساتھ جوڑتا ہے۔ مصنف نے ایک "اسمارٹ" ماڈل آزمانے کی کوشش کی جو فوری طور پر درجے کا فیصلہ کرتا، لیکن اضافی ٹوکن کے استعمال نے تمام بچت کو ختم کر دیا۔ سادہ اسٹیٹک اصولوں نے تقریباً 80% کام کو کور کیا اور سسٹم کو سستا اور قابلِ پیش گوئی رکھا۔
ایسکلیشن سیفٹی نیٹ
سستے ماڈلز سے بھی غلطیاں ہو سکتی ہیں۔ Haiku یا Sonnet کے کسی غلط جواب سے بلڈ (build) کو خراب ہونے سے بچانے کے لیے، سسٹم دو ناکامیوں کے بعد درخواست کو اگلے درجے (tier) پر بھیج دیتا ہے۔ یہ سیفٹی نیٹ غلطیوں کو جلد پکڑ لیتا ہے اور انسانی مداخلت کے بغیر پائپ لائن کو ہموار طریقے سے چلنے میں مدد دیتا ہے۔
اعداد و شمار جو خود بولتے ہیں
چار ہفتوں تک درجہ بندی شدہ روٹر چلانے کے بعد، مصنف نے درج ذیل تبدیلیاں نوٹ کیں:
- API اخراجات اصل لاگت کے 65% تک گر گئے (35% کی کمی)۔
- اوسط ٹرن اراؤنڈ ٹائم (turnaround time) 42 سیکنڈ سے کم ہو کر 27 سیکنڈ رہ گیا۔
- Opus کا استعمال ہر درخواست کو سنبھالنے کے بجائے کل کاموں کے صرف 11% تک محدود ہو گیا۔
یہ اعداد و شمار ظاہر کرتے ہیں کہ زیادہ تر ڈویلپمنٹ کے کام کو معیار میں نمایاں کمی کے بغیر سستے ماڈلز کے سپرد کیا جا سکتا ہے، جبکہ مشکل ترین مسائل اب بھی Opus کے بڑے کانٹیکسٹ ونڈو (context window) سے فائدہ اٹھا سکتے ہیں۔
دیگر ڈویلپرز کے لیے اسباق
- کم سے آغاز کریں، زیادہ سے نہیں۔ روزانہ کے زیادہ تر کوڈنگ کے کاموں کے لیے سب سے طاقتور ماڈل کی ضرورت نہیں ہوتی۔ مبہم کاموں کے لیے Sonnet کو ڈیفالٹ بنانے سے Haiku کے ذریعے ہر کام کرنے کے مقابلے میں زیادہ پیسے بچے ۔
- مشکل کو ناپیں، سائز کو نہیں۔ ایک لائن کا race-condition فکس کرنا پوری فائل کی ریفیکٹرنگ سے زیادہ مشکل ہو سکتا ہے۔ روٹنگ اس بنیاد پر کریں کہ حل کتنا مبہم ہے، نہ کہ اس بنیاد پر کہ کتنی لائنیں تبدیل کی گئی ہیں۔
- ایسکلیشن ریٹ پر نظر رکھیں۔ ایسکلیشنز (escalations) کی بڑھتی ہوئی تعداد اس بات کا اشارہ ہے کہ اسٹیٹک اصول اب کام کے بوجھ کے مطابق نہیں رہے۔ سستے ماڈلز کی وجہ سے پائپ لائن میں مزید ناکامیاں شروع ہونے سے پہلے کیٹیگریز (buckets) کو ایڈجسٹ کریں۔
مشکل ترین مسائل کے لیے مہنگے ترین ماڈل کو مخصوص کرنا اور باقی کام سستے ماڈلز پر چھوڑنا، AI کی مدد سے ہونے والی ڈویلپمنٹ کو تیز اور سستا رکھتا ہے۔ اصل فائدہ ایک منظم روٹنگ حکمت عملی میں ہے جو صحیح کام کے لیے صحیح ٹول کا انتخاب کرتی ہے۔