एक प्राथमिक लार्ज लैंग्वेज मॉडल का चुनाव करने में एक दोपहर लग सकती है। लेकिन जब वह विफल हो जाता है, तो उस स्थिति को संभालना ही असली इंजीनियरिंग का काम है।

अधिकांश टीमें 'हैप्पी पाथ' (आदर्श स्थिति) के लिए ऑप्टिमाइज़ करती हैं। वे साफ डेटासेट पर सटीकता का बेंचमार्क करती हैं, आदर्श इनपुट के खिलाफ प्रॉम्प्ट्स को रिफाइन करती हैं, और आत्मविश्वास के साथ उन्हें डिप्लॉय करती हैं। फिर प्रोडक्शन ट्रैफिक आता है। पीक आवर्स के दौरान मॉडल टाइमआउट होने लगता है, शुक्रवार की शामों को गलत तरीके से बना (malformed) JSON वापस करने लगता है, या प्राइसिंग अपडेट के बाद अचानक तीन गुना अधिक खर्च होने लगता है। आपका सावधानीपूर्वक डिज़ाइन किया गया AI फीचर एक बोझ बन जाता है क्योंकि किसी ने मॉडल के फेल होने की योजना नहीं बनाई थी।

किसी भी गंभीर मल्टी-मॉडल एप्लिकेशन में, फ़ालबैक नियम कोई बाद में सोचने वाली चीज़ नहीं हैं। वे मुख्य बुनियादी ढांचा (core infrastructure) हैं। जब प्राथमिक मॉडल लड़खड़ाता है, तो आपका सिस्टम कैसा व्यवहार करता है, यही तय करता है कि उपयोगकर्ता रुकेंगे या चले जाएंगे।

स्पष्ट विफलता संकेतों (Failure Signals) से शुरुआत करें

आप तब तक फ़ालबैक रणनीति नहीं बना सकते जब तक आप यह न जान लें कि आप वास्तव में किस चीज़ पर प्रतिक्रिया दे रहे हैं। हर आउटबाउंड मॉडल कॉल को इंस्ट्रुमेंट करने और विफलताओं को विशिष्ट, कार्रवाई योग्य संकेतों में वर्गीकृत करने से शुरुआत करें।

जब किसी प्रोवाइडर का एंडपॉइंट हैंग हो जाए, तो API टाइमआउट पर नज़र रखें। रेट लिमिट एरर — आमतौर पर HTTP 429s — पर नज़र रखें, जो तब आते हैं जब आपका ट्रैफिक अचानक बढ़ जाता है या आप मंथली कोटा पूरा कर लेते हैं। उस अमान्य JSON आउटपुट पर नज़र रखें जो आपके पार्सर पाइपलाइन को क्रैश कर देता है। उन खाली या अधूरे रिस्पॉन्स पर नज़र रखें जो HTTP लेयर पर तो सफल लगते हैं लेकिन उनमें कोई उपयोगी कंटेंट नहीं होता। हाई लेटेंसी पर नज़र रखें जो किसी भी हार्ड टाइमआउट से पहले चैट अनुभव को खराब कर देती है। कॉन्टेक्स्ट लेंथ ओवरफ्लो पर नज़र रखें जब यूजर इनपुट मॉडल की विंडो से बाहर बढ़ जाता है। और क्वालिटी रिग्रेशन पर नज़र रखें, जो सबसे सूक्ष्म विफलता है: मॉडल जवाब तो देता है, लेकिन प्रोवाइडर-साइड अपडेट के बाद उसके उत्तर भटकने लगते हैं, अस्पष्ट हो जाते हैं, या फॉर्मेटिंग निर्देशों को नज़रअंदाज़ करने लगते हैं।

इनमें से प्रत्येक संकेत को एक अलग प्रतिक्रिया ट्रिगर करनी चाहिए। टाइमआउट के लिए 'रिट्राय' (retry) उचित है। खराब JSON के लिए मॉडल बदलना उचित है। रेट लिमिट का मतलब हो सकता है कि आपको पूरी तरह से किसी अलग प्रोवाइडर का उपयोग करने की आवश्यकता है।

फ़ालबैक को वर्कफ़्लो के अनुसार चुनें

हर काम के लिए एक ही फ़ालबैक नियम का उपयोग करना आपदा का कारण बन सकता है। एक चैटबॉट और बैकग्राउंड डेटा एक्सट्रैक्शन जॉब की ज़रूरतें बिल्कुल अलग होती हैं। अपने फ़ालबैक को विशिष्ट वर्कफ़्लो के आधार पर डिज़ाइन करें।

चैटबॉट्स को गति और बातचीत के प्रवाह की आवश्यकता होती है। उपयोगकर्ता थोड़े सामान्य उत्तर को माफ कर देंगे, लेकिन वे पांच सेकंड के ठहराव को माफ नहीं करेंगे। यदि आपका प्राथमिक मॉडल धीमा हो जाता है, तो एक तेज़ बैकअप पर फ़ालबैक करें — अक्सर उसी मॉडल फैमिली का एक छोटा वेरिएंट, या किसी अन्य प्रोवाइडर का स्पीड-टियर ऑफरिंग। संवाद को जारी रखें।

RAG सिस्टम को सटीकता की आवश्यकता होती है। आपने रिट्रीवल (वेक्टर सर्च, रीरैंकिंग, शायद वेब क्रॉलिंग) की लागत पहले ही चुका दी है। यदि जेनरेटर दिए गए कॉन्टेक्स्ट का सम्मान करने में विफल रहता है, तो वह सारा काम बेकार चला जाता है। सटीक निर्देश पालन और लॉन्ग-कॉन्टेक्स्ट समझ के लिए जाने जाने वाले मॉडल पर फ़ालबैक करें, भले ही वह धीमा हो।

कोडिंग टूल्स को लॉजिक की आवश्यकता होती है। डेवलपर्स को अलंकारिक स्पष्टीकरण के बजाय सही सिंटैक्स और वैध API कॉल चाहिए होते हैं। यदि प्राथमिक मॉडल फंक्शंस को हैलुसिनेट करने लगता है या एज केसेस को छोड़ देता है, तो कोड पर फाइन-ट्यून किए गए मॉडल पर स्विच करें। कंपाइल-रेडी आउटपुट के बदले में अधिक लेटेंसी स्वीकार करें।

JSON एक्सट्रैक्शन को स्ट्रक्चर की आवश्यकता होती है। स्ट्रक्चर्ड जनरेशन नाजुक होता है। एक भी गायब ब्रैकेट या गलत तरीके से एस्केप किया गया कोट डाउनस्ट्रीम डेटाबेस राइट को खत्म कर देता है। यदि आपका प्राथमिक मॉडल स्कीमा के पालन में भटकता है, तो एक बार रिट्राय करें, फिर उच्च फॉर्मेटिंग विश्वसनीयता वाले मॉडल पर स्विच करें। अजीब बात यह है कि आज्ञाकारिता के लिए ट्यून किए गए छोटे मॉडल अक्सर इस विशिष्ट कार्य पर क्रिएटिव दिग्गजों से बेहतर प्रदर्शन करते हैं।

ऑटोमेशन और बैच जॉब्स को लागत नियंत्रण की आवश्यकता होती है। बैकग्राउंड क्लासिफायर, लॉग समराइज़र और नोटिफिकेशन जेनरेटर लगातार चलते रहते हैं। आपके प्राथमिक मॉडल पर कीमतों में उछाल एक प्रबंधनीय दैनिक बिल को बजट संकट में बदल सकता है। इन गैर-महत्वपूर्ण रास्तों के लिए एक सस्ता, स्थिर मॉडल स्टैंडबाय पर रखें। यदि आउटपुट की गुणवत्ता थोड़ी गिरती है, तो व्यावसायिक प्रभाव आमतौर पर न्यूनतम होता है।

स्विच करने से पहले अपनी सीमाओं को जानें

अंधाधुंध मॉडल बदलना नई समस्याएं पैदा करता है। यदि आप एक मजबूत मॉडल से कमजोर मॉडल पर जाते हैं, तो बैकअप सूक्ष्म प्रॉम्प्ट्स को गलत समझ सकता है और ऐसा कचरा (garbage) उत्पन्न कर सकता है जो डाउनस्ट्रीम त्रुटियों का कारण बनता है। यदि आप एक बड़े मॉडल पर जाते हैं, तो आप गुणवत्ता की समस्या को हल कर सकते हैं लेकिन कुछ ही घंटों में अपना बजट बिगाड़ सकते हैं।

किसी भी मॉडल को फ़ालबैक स्टेटस देने से पहले, छह कारकों के आधार पर उसका ऑडिट करें।

  • मॉडल की क्षमता (Model capability): क्या यह वास्तव में प्रॉम्प्ट प्रकार को संभाल सकता है, या यह अलग तरह से विफल होगा?
  • भाषा समर्थन (Language support): आपका बैकअप अंग्रेजी में माहिर हो सकता है लेकिन हिंदी, स्पेनिश या जापानी में भ्रमित (hallucinate) हो सकता है।
  • कॉन्टेक्स्ट विंडो का आकार (Context window size): यदि आपका इनपुट 50,000 टोकन है, तो 16,000-टोकन की सीमा वाला फॉलबैक डेटा को काट देगा और अर्थ को चुपचाप नष्ट कर देगा।
  • लेटेंसी (Latency): कुछ प्रदाता आपके क्षेत्र के लिए दूसरों की तुलना में लगातार तेज़ होते हैं।
  • प्रति अनुरोध लागत (Cost per request): एक सख्त सीमा निर्धारित करें। जानें कि पीक वॉल्यूम के दौरान फॉलबैक की लागत क्या होगी।
  • आउटपुट की विश्वसनीयता (Output reliability): क्या यह हर बार आउटपुट फॉर्मेट का पालन करेगा, या केवल मंगलवार को?

चार फॉलबैक पैटर्न जो प्रभावी हैं

हर विफलता के लिए एक ही समाधान पर्याप्त नहीं होता। फॉलबैक प्रकारों का एक टूलकिट बनाएं और उन्हें सोच-समझकर लागू करें।

रिट्राय फॉलबैक (Retry fallback)। क्षणिक नेटवर्क त्रुटियों और प्रदाता के संक्षिप्त आउटेज के लिए, 'एक्सपोनेंशियल बैकऑफ़' (exponential backoff) के साथ उसी मॉडल को फिर से प्रयास करें। खराब आउटपुट (malformed output) या कॉन्टेक्स्ट ओवरफ्लो होने पर रिट्राय न करें — एक ही खराब प्रॉम्प्ट को दो बार भेजने से शायद ही कभी मदद मिलती है।

समकक्ष फॉलबैक (Equivalent fallback)। जब आपका प्राथमिक प्रदाता डाउन हो या थ्रॉटल (throttled) हो, तो किसी अन्य प्रदाता के समान मॉडल पर स्विच करें। एक फ्रंटियर मॉडल से लगभग उसी श्रेणी के दूसरे मॉडल पर जाने के लिए आमतौर पर न्यूनतम प्रॉम्प्ट रीराइटिंग की आवश्यकता होती है और आउटपुट की गुणवत्ता बनी रहती है।

सस्ता फॉलबैक (Cheaper fallback)। गैर-महत्वपूर्ण कार्यों के लिए कम लागत वाले मॉडल को आरक्षित रखें। यदि सस्ता विकल्प संघर्ष करता है, तो कम मूल्य वाले काम पर प्रीमियम टोकन खर्च करने के बजाय फीचर को शालीनता से कम (degrade gracefully) कर दें।

अधिक शक्तिशाली फॉलबैक (Stronger fallback)। यह सुनने में उल्टा लग सकता है, लेकिन यह आवश्यक है। जब एक मिड-टियर मॉडल जटिल तर्क (reasoning), बहु-चरणीय गणित, या सूक्ष्म कानूनी विश्लेषण में लगातार विफल होता है, तो अधिक सक्षम मॉडल पर एस्केलेट करें। इसका उपयोग केवल उच्च-मूल्य वाले यूजर पाथ के लिए कम मात्रा में करें जहाँ सटीकता राजस्व या सुरक्षा की रक्षा करती है।

अपने आर्किटेक्चर में लॉजिक को शामिल करें

एप्लिकेशन कोड में दर्जनों try-catch ब्लॉक्स में फॉलबैक लॉजिक को न बिखेरें। राउटिंग को इंफ्रास्ट्रक्चर की तरह मानें। एक मिडलवेयर लेयर बनाएं जो टास्क प्रकारों को मॉडलों की क्रमबद्ध सूचियों (ordered lists) से मैप करे, जिसमें प्रत्येक का अपना टाइमआउट थ्रेशोल्ड, रिट्राय पॉलिसी और सर्किट ब्रेकर हो।

फॉलबैक इवेंट्स को 'फर्स्ट-क्लास मेट्रिक्स' के रूप में ट्रैक करें। एरर रेट आपको बताते हैं कि मॉडल कब डाउन है; फॉलबैक रेट आपको बताते हैं कि मॉडल काम के लिए गलत है। यदि आपका सिस्टम 30 या 40 प्रतिशत समय फॉलबैक करता है, तो इसका मतलब है कि आपका प्राथमिक मॉडल वर्कलोड के साथ सही ढंग से तालमेल नहीं बिठा पा रहा है। यह केवल एरर हैंडलिंग को ही नहीं, बल्कि अपने मॉडल चयन का पुनर्मूल्यांकन करने का संकेत है।

स्पष्ट बजट निर्धारित करें। फॉलबैक कभी भी 'ब्लैंक चेक' नहीं होना चाहिए। यदि लोड के दौरान आप किसी प्रीमियम मॉडल पर स्विच करते हैं, तो प्रति मिनट एस्केलेटेड अनुरोधों की संख्या सीमित करें। अपने वॉलेट की रक्षा उसी सख्ती से करें जैसे आप अपने अपटाइम की रक्षा करते हैं।

असली परीक्षा

आप डेमो के लिए निर्माण नहीं कर रहे हैं। आप मंगलवार दोपहर 3 बजे के लिए निर्माण कर रहे हैं, जब API सुस्त हो, उपयोगकर्ता प्रतीक्षा कर रहा हो, और फाइनेंस टीम अभी पूछ रही हो कि AI बिल दोगुना क्यों हो गया। एक परिपक्व फॉलबैक रणनीति उत्पाद को स्थिर रखती है, उपयोगकर्ता अनुभव को सुसंगत बनाए रखती है, और आपकी लागत को अनुमानित रखती है।

अपने प्राथमिक मॉडल का सावधानीपूर्वक चयन करें। लेकिन जब वह आपको निराश कर दे, तो क्या होगा, इसकी योजना बनाने में दोगुना समय बिताएं।

स्रोत: How to Design AI Model Fallback Rules for Multi-Model Apps

कम्युनिटी: GyaanSetu AI on Telegram