پروڈکشن AI API کی ناکامیاں

جب آپ کا AI فیچر رات کے 2 بجے خراب ہوتا ہے تو ایرر میسجز (error messages) شاذ و نادر ہی پوری کہانی بتاتے ہیں۔ میں نے ایک سال تک OpenAI اور Anthropic کے انٹیگریشنز چلائے ہیں۔ میں نے ناکامیوں کو ڈیبگنگ (debugging) کے لحاظ سے گروپس میں تقسیم کرنا سیکھا ہے۔

ریٹ لمٹس (Rate Limits) کو سنبھالنا

OpenAI کے 429 ایررز کی مختلف وجوہات ہوتی ہیں۔ آپ کو یہ جاننے کے لیے کہ کیسے ردعمل دینا ہے، ایرر کوڈ چیک کرنا چاہیے۔

  • فی منٹ درخواستوں (RPM) کی حد سیکنڈوں میں بحال ہو جاتی ہے۔
  • فی منٹ ٹوکنز (TPM) کی حد 60 سیکنڈ میں بحال ہو جاتی ہے۔
  • ماہانہ کوٹہ ختم ہو جانا تب تک خراب رہتا ہے جب تک آپ کریڈٹ شامل نہ کریں یا بلنگ سائیکل ری سیٹ نہ ہو۔

کوٹہ کے مسائل کے لیے exponential backoff استعمال نہ کریں۔ یہ آپ کا وقت ضائع کرے گا۔

Anthropic کے 529 ایررز کا مطلب ہے کہ فراہم کنندہ (provider) پر بوجھ زیادہ ہے۔ اسے 503 ایرر کی طرح سمجھیں۔ مسئلہ ان کی طرف سے ہے۔ تھوڑی دیر کے لیے رک جائیں اور اپنی ٹیم کو الرٹ کریں۔

400 ایررز کو سنبھالنا

یہ ناکامیاں عام طور پر آپ کی غلطی ہوتی ہیں۔ ان تین پیٹرنز پر نظر رکھیں:

  • ماڈل ورژن کا فرق (Model version mismatches)۔ آپ نے ایک جگہ نام اپ ڈیٹ کیا لیکن اپنے ری ٹرائی ہینڈلر (retry handler) میں نہیں۔
  • کانٹیکسٹ ونڈو کا اوور فلو (Context window overflow)۔ بات چیت کی ہسٹری بہت بڑی ہو گئی۔ یہ اکثر ناقص ٹرنکیشن لاجک (truncation logic) کی وجہ سے ہوتا ہے۔
  • اسکیمہ ویلیڈیشن کی ناکامی (Schema validation failures)۔ آپ کے JSON ڈھانچے میں غیر معاون اقسام (unsupported types) یا ریکرسو ریفرنسز (recursive references) ہیں۔

انہیں ٹھیک کرنے کے لیے، 400 ایررز کے لیے مکمل ریکوئسٹ پے لوڈ (request payload) کو لاگ کریں۔ پہلے صارف کا ڈیٹا چھپا (redact) دیں۔ رسپانس باڈی آپ کو بالکل بتاتی ہے کہ کون سا فیلڈ فیل ہوا ہے۔

ٹائم آؤٹ (Timeouts) کو سنبھالنا

ٹائم آؤٹ کو ٹریک کرنا مشکل ہے کیونکہ فراہم کنندہ کو کچھ بھی غلط نظر نہیں آتا۔

  • کنیکٹ ٹائم آؤٹ (Connect timeout)۔ ہینڈ شیک (handshake) فیل ہو گیا۔ یہ فراہم کنندہ کے ڈاؤن ہونے یا DNS کے مسائل کے دوران ہوتا ہے۔ اپنا آؤٹ باؤنڈ نیٹ ورک چیک کریں۔
  • ریڈ ٹائم آؤٹ (Read timeout)۔ ماڈل شروع تو ہوا لیکن مکمل نہ ہو سکا۔ آپ کی ایپ کو جزوی اسٹریمنگ آؤٹ پٹس (partial streaming outputs) کو سنبھالنا چاہیے۔
  • گیٹ وے ٹائم آؤٹ (504)۔ آپ کا پراکسی پہلے ٹائم آؤٹ ہو گیا۔ ریکوئسٹ شاید اب بھی فراہم کنندہ کے پاس چل رہی ہو۔ ری ٹرائی کرنے سے پہلے ڈی ڈپلیکیشن (deduplication) کا استعمال کریں۔

ڈیبگ کرنے کے لیے، اپنے کنیکٹ ٹائم آؤٹ کو اپنے ریڈ ٹائم آؤٹ سے الگ کریں۔ لیٹنسی (latency) کہاں ہے، یہ جاننے کے لیے time-to-first-token کو لاگ کریں۔

فراہم کنندہ (Provider) کے مسائل کو سنبھالنا

  • 500 ایرر اکثر دو سیکنڈ بعد ایک ری ٹرائی کے ساتھ حل ہو جاتا ہے۔
  • 503 ایرر کا مطلب ہے کہ سروس کمزور ہو گئی ہے۔ اگر فراہم کنندہ کا اسٹیٹس پیج کسی واقعے (incident) کی نشاندہی کرتا ہے، تو سرکٹ بریکر (circuit breaker) استعمال کریں۔
  • ہمیشہ ریکارڈ کریں کہ کون سا ماڈل ورژن فیل ہوا۔ مختلف ماڈلز کی بھروسہ مندی کے لیول مختلف ہوتے ہیں۔

لاگز سے سیدھا Slack پر جانا بند کریں۔ پہلے فراہم کنندہ کا اسٹیٹس پیج چیک کریں۔ یہ آپ کو 20 منٹ کی گھبراہٹ سے بچاتا ہے۔

Source: https://dev.to/void_stitch/production-ai-api-failures-by-category-what-429s-529s-and-timeouts-are-actually-telling-you-5bo1

Optional learning community: https://t.me/GyaanSetuAi