𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
मैंने एक कम्युनिटी फोरम के लिए एक रियल-टाइम चैटबॉट बनाया। मैंने केवल OpenAI API का उपयोग किया। यह सरल लग रहा था।
तीन सप्ताह बाद, पीक आवर्स (peak hours) के दौरान मुझे 5xx एरर का सामना करना पड़ा। मेरा चैटबॉट बंद हो गया। यूजर्स नाराज थे। मुझे एहसास हुआ कि मैं प्रोडक्शन ऐप्स के लिए केवल एक प्रोवाइडर पर भरोसा नहीं कर सकता।
मुझे एक सिंगल प्रोवाइडर के साथ कई समस्याओं का सामना करना पड़ा:
- रेट लिमिट्स (Rate limits)
- टाइमआउट्स (Timeouts)
- पूरी तरह से आउटेज (Complete outages)
मैंने अन्य प्रोवाइडर्स को आज़माया, लेकिन उन सभी के फॉर्मेट और ऑथेंटिकेशन मेथड्स अलग-अलग थे। मेरा कोड switch-case स्टेटमेंट्स का एक उलझा हुआ जाल बन गया।
मुझे एक ऐसे सिस्टम की आवश्यकता थी जो:
- विभिन्न प्रोवाइडर्स को स्टैंडर्डाइज़ (Standardize) कर सके
- एक के फेल होने पर ऑटोमैटिकली रिट्राय (Retry) कर सके
- रिस्पॉन्स को कैश (Cache) कर सके
- वेंडर लॉक-इन (Vendor lock-in) से बच सके
मैंने थर्ड-पार्टी लाइब्रेरीज़ से परहेज किया क्योंकि वे बहुत अधिक रिजिड (rigid) थीं। इसके बजाय, मैंने एक सरल डिज़ाइन का उपयोग करके एक कस्टम फॉलबैक सिस्टम (fallback system) बनाया।
सबसे पहले, मैंने सभी प्रोवाइडर्स के लिए एक कॉमन इंटरफ़ेस बनाया। इससे कोई भी AI मॉडल एक ही कोड के साथ काम कर सकता है।
इसके बाद, मैंने एक राउटर क्लास (router class) बनाई। यह क्लास क्रम के अनुसार प्रोवाइडर्स को आज़माती है। यह विफलताओं को संभालने के लिए एक्सपोनेंशियल बैकऑफ़ (exponential backoff) और सिंपल कैशिंग का उपयोग करती है।
यहाँ इसका लॉजिक दिया गया है:
- AI प्रोवाइडर्स के लिए एक एब्स्ट्रैक्ट बेस क्लास (abstract base class) डिफाइन करें।
- OpenAI और अन्य प्रोवाइडर्स के लिए विशिष्ट क्लासेस लागू करें।
- प्रोवाइडर्स की अपनी लिस्ट में लूप करने के लिए राउटर का उपयोग करें।
- यदि कोई प्रोवाइडर फेल हो जाता है, तो राउटर इंतज़ार करता है और अगले को आज़माता है।
इस सिस्टम ने हाल ही में हुए तीन आउटेज के दौरान मेरे प्रोजेक्ट को बचा लिया। यह पारदर्शी और सरल बना रहता है।
यदि आप AI के साथ कुछ बना रहे हैं, तो इन बातों को याद रखें:
- प्रोडक्शन में लोकल डिक्शनरी के बजाय कैशिंग के लिए Redis का उपयोग करें।
- अपने खर्चों की निगरानी के लिए कॉस्ट ट्रैकिंग (cost tracking) जोड़ें।
- तेज़ रिस्पॉन्स के लिए एसिंक्रोनस (asynchronous) सपोर्ट लागू करें।
- रेट लिमिट्स को बेहतर ढंग से संभालने के लिए "Retry-After" हेडर्स को पार्स (parse) करें।
यदि आपका प्रोजेक्ट छोटा है, तो ओवर-इंजीनियरिंग (over-engineer) न करें। लेकिन यदि आपकी सर्विस अपटाइम (uptime) पर निर्भर है, तो एक फॉलबैक ज़रूर बनाएं।
आप अपने प्रोजेक्ट्स में प्रोवाइडर की विश्वसनीयता (reliability) को कैसे संभालते हैं? क्या आप फॉलबैक लेयर का उपयोग करते हैं या किसी एक वेंडर पर निर्भर रहते हैं?