میں نے ایک واحد AI فراہم کنندہ پر بھروسہ کرنا کیوں چھوڑ دیا
میں نے ایک کمیونٹی فورم کے لیے ریئل ٹائم چیٹ بوٹ بنایا۔ میں نے سوچا تھا کہ صرف ایک API کا استعمال کافی ہوگا۔ میں غلط تھا۔
تین ہفتوں کے بعد، مصروف اوقات (peak hours) کے دوران مجھے 5xx error کا سامنا کرنا پڑا۔ میرا چیٹ بوٹ کام کرنا بند ہو گیا۔ صارفین مایوس تھے۔ مجھے احساس ہوا کہ میں پروڈکشن ایپس کے لیے صرف ایک فراہم کنندہ پر بھروسہ نہیں کر سکتا۔
میں نے GPT-4 استعمال کیا۔ یہ تب تک اچھا کام کرتا رہا جب تک کہ اچانک کام کرنا چھوڑ نہ دیا۔ مجھے ریٹ لمٹس (rate limits)، ٹائم آؤٹس (timeouts) اور مکمل ڈاؤن ٹائم کا سامنا کرنا پڑا۔ اعلیٰ ٹیرز (higher tiers) کے لیے ادائیگی کرنا مسئلے کو حل کرنے کے بجائے صرف اس کی علامات کو ٹھیک کرنے جیسا محسوس ہو رہا تھا۔
میں نے دوسرے فراہم کنندگان کو آزمایا، لیکن ان سب کے فارمیٹس اور auth میتھڈز مختلف تھے۔ میرا کوڈ switch-case اسٹیٹمنٹس کا ایک الجھا ہوا مجموعہ بن گیا۔ مجھے ایک ایسے سسٹم کی ضرورت تھی جو:
- فراہم کنندگان کے فرق کو چھپائے۔
- ناکامی کی صورت میں بیک اپ فراہم کنندہ پر سوئچ کر سکے۔
- جوابات کو کیش (cache) کر سکے۔
- وینڈر لاک ان (vendor lock-in) سے بچ سکے۔
میں نے تھرڈ پارٹی لائبریریز سے گریز کیا کیونکہ وہ بہت پیچیدہ تھیں اور آسانی سے خراب ہو جاتی تھیں۔ اس کے بجائے، میں نے ایک سادہ روٹر (router) بنایا۔
سب سے پہلے، میں نے تمام فراہم کنندگان کے لیے ایک مشترکہ انٹرفیس (interface) متعارف کرایا۔ ہر فراہم کنندہ ایک generate میتھڈ اور ہیلتھ چیک (health check) کو نافذ کرتا ہے۔
اس کے بعد، میں نے ایک router class بنائی۔ یہ ایک مخصوص ترتیب میں فراہم کنندگان کو آزماتی ہے۔ یہ exponential backoff اور ایک سادہ کیش (cache) کا استعمال کرتی ہے۔ اگر پہلا فراہم کنندہ ناکام ہو جائے تو سسٹم انتظار کرتا ہے اور اگلے فراہم کنندہ کو آزماتا ہے۔
اس سسٹم نے تین مختلف ڈاؤن ٹائمز کے دوران میرے ویک اینڈز بچائے۔ یہ میرے ایپ کو تب بھی چلتا رکھتا ہے جب کوئی بڑا فراہم کنندہ ڈاؤن ہو جائے۔
اگر آپ اسے بناتے ہیں، تو ان نکات کو ذہن میں رکھیں:
- پروڈکشن میں لوکل ڈکشنری کے بجائے کیشنگ کے لیے Redis استعمال کریں۔
- ہیلتھ چیک کامیابی کی ضمانت نہیں دیتے۔ ایک فراہم کنندہ چیک پاس کر سکتا ہے لیکن اصل درخواست (request) میں ناکام ہو سکتا ہے۔
- ریٹ لمٹس کو صحیح طریقے سے سنبھالنے کے لیے Retry-After ہیڈرز کو پارس (parse) کریں۔
- اخراجات کا حساب رکھنے کے لیے ٹوکن کے استعمال کی لاگنگ (logging) شامل کریں۔
- بہتر کارکردگی کے لیے asyncio استعمال کریں۔
اگر آپ کا پروجیکٹ چھوٹا ہے، تو اسے ضرورت سے زیادہ پیچیدہ (over-engineer) نہ بنائیں۔ اگر آپ کو اسٹریمنگ (streaming) کی ضرورت ہے، تو یہ پیٹرن لیٹنسی (latency) میں اضافہ کرتا ہے۔ اپنے پیمانے کے مطابق صحیح ٹول کا انتخاب کریں۔
آپ فراہم کنندہ کی معتبریت (reliability) کو کیسے سنبھالتے ہیں؟ کیا آپ ایک ہی فراہم کنندہ پر قائم رہتے ہیں یا ایک فال بیک لیئر (fallback layer) بناتے ہیں؟
Optional learning community: https://t.me/GyaanSetuAi