प्रोडक्शन AI API विफलताएं

जब रात के 2 बजे आपका AI फीचर खराब होता है, तो एरर मैसेज (error messages) शायद पूरी कहानी नहीं बताते। मैंने एक साल तक OpenAI और Anthropic इंटीग्रेशन चलाए हैं। मैंने सीखा है कि डिबगिंग के लिए विफलताओं को उनके अर्थ के आधार पर कैसे वर्गीकृत किया जाए।

रेट लिमिट्स (Rate Limits) को संभालना

OpenAI 429 एरर के अलग-अलग कारण होते हैं। यह जानने के लिए कि कैसे प्रतिक्रिया देनी है, आपको एरर कोड की जांच करनी चाहिए।

  • Requests-per-minute (RPM) लिमिट्स कुछ ही सेकंड में ठीक हो जाती हैं।
  • Tokens-per-minute (TPM) लिमिट्स 60 सेकंड में ठीक हो जाती हैं।
  • मंथली कोटा (Monthly quota) खत्म होने पर समस्या तब तक बनी रहती है जब तक आप क्रेडिट नहीं जोड़ते या बिलिंग साइकिल रीसेट नहीं हो जाती।

कोटा संबंधी समस्याओं के लिए exponential backoff का उपयोग न करें। इससे आपका समय बर्बाद होगा।

Anthropic 529 एरर का मतलब है कि प्रोवाइडर पर लोड बहुत अधिक है। इसे 503 एरर की तरह ही समझें। समस्या उनकी तरफ से है। थोड़ा रुकें (Back off) और अपनी टीम को सूचित करें।

400 एरर्स को संभालना

ये विफलताएं आमतौर पर आपकी गलती होती हैं। इन तीन पैटर्न्स पर ध्यान दें:

  • मॉडल वर्जन मिसमैच (Model version mismatches)। आपने एक जगह नाम अपडेट किया लेकिन अपने retry handler में नहीं।
  • कॉन्टेक्स्ट विंडो ओवरफ्लो (Context window overflow)। बातचीत का इतिहास बहुत बड़ा हो गया। ऐसा अक्सर खराब truncation logic के कारण होता है।
  • स्कीमा वैलिडेशन विफलताएं (Schema validation failures)। आपके JSON स्ट्रक्चर में अनसपोर्टेड टाइप्स या रिकर्सिव रेफरेंस हैं।

इन्हें ठीक करने के लिए, 400 एरर्स के लिए पूरे request payload को लॉग करें। पहले यूजर डेटा को हटा दें (Redact)। रिस्पॉन्स बॉडी आपको सटीक रूप से बताएगी कि कौन सा फील्ड फेल हुआ है।

टाइमआउट्स (Timeouts) को संभालना

टाइमआउट्स को ट्रैक करना मुश्किल होता है क्योंकि प्रोवाइडर को कुछ भी गलत नहीं दिखता।

  • कनेक्ट टाइमआउट (Connect timeout)। हैंडशेक फेल हो गया। यह प्रोवाइडर के brownouts या DNS समस्याओं के दौरान होता है। अपने outbound network की जांच करें।
  • रीड टाइमआउट (Read timeout)। मॉडल शुरू तो हुआ लेकिन पूरा नहीं हुआ। आपके ऐप को partial streaming outputs को संभालना चाहिए।
  • गेटवे टाइमआउट (504)। आपका प्रॉक्सी पहले टाइमआउट हो गया। रिक्वेस्ट अभी भी प्रोवाइडर पर चल रही हो सकती है। दोबारा कोशिश करने से पहले deduplication का उपयोग करें।

डिबग करने के लिए, अपने connect timeout को अपने read timeout से अलग करें। लेटेंसी (latency) कहाँ है, यह जानने के लिए time-to-first-token को लॉग करें।

प्रोवाइडर की समस्याओं को संभालना

  • 500 एरर अक्सर दो सेकंड के बाद एक बार फिर से कोशिश (retry) करने पर ठीक हो जाता है।
  • 503 एरर का मतलब है कि सर्विस खराब (degraded) है। यदि प्रोवाइडर स्टेटस पेज पर कोई घटना (incident) दिखाई देती है, तो circuit breaker का उपयोग करें।
  • हमेशा रिकॉर्ड करें कि कौन सा मॉडल वर्जन फेल हुआ। अलग-अलग मॉडल्स के reliability levels अलग-अलग होते हैं।

लॉग्स से सीधे Slack पर कूदना बंद करें। पहले प्रोवाइडर स्टेटस पेज चेक करें। यह आपको 20 मिनट की घबराहट से बचाएगा।

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

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi