प्राथमिक लार्ज लँग्वेज मॉडेल निवडण्यासाठी कदाचित एक दुपार लागू शकते. पण जेव्हा ते अपयशी ठरते, तेव्हा काय करायचे याचे व्यवस्थापन करणे हे खरे इंजिनिअरिंगचे काम आहे.

बहुतेक टीम्स 'हॅपी पाथ' (happy path) साठी ऑप्टिमाइझ करतात. त्या स्वच्छ डेटासेटवर अचूकतेची चाचणी घेतात, आदर्श इनपुट्ससाठी प्रॉम्प्ट्स सुधारतात आणि आत्मविश्वासाने मॉडेल तैनात करतात. मग जेव्हा प्रोडक्शन ट्रॅफिक येते, तेव्हा परिस्थिती बदलते. पीक अवर्समध्ये मॉडेल टाइमआउट होऊ लागते, शुक्रवारी संध्याकाळी चुकीचे (malformed) JSON पाठवते, किंवा किंमत अपडेट झाल्यानंतर अचानक तिप्पट खर्च करू लागते. तुमचे काळजीपूर्वक डिझाइन केलेले AI फीचर ओझे बनू शकते कारण मॉडेल कधीतरी बिघडेल, याचा कोणीही विचार केलेला नसतो.

कोणत्याही गंभीर मल्टी-मॉडेल ॲप्लिकेशनमध्ये, फॉलबॅक नियम हे नंतरचा विचार नसून ते मुख्य पायाभूत सुविधा (core infrastructure) आहेत. जेव्हा प्राथमिक मॉडेल अडखळते, तेव्हा तुमची सिस्टीम कशी वागते, यावर वापरकर्ते तुमच्यासोबत राहतील की निघून जातील हे अवलंबून असते.

स्पष्ट फेल्युअर सिग्नल्सपासून (Failure Signals) सुरुवात करा

तुम्ही नक्की कशावर प्रतिक्रिया देत आहात हे माहित असल्याशिवाय तुम्ही फॉलबॅक स्ट्रॅटेजी तयार करू शकत नाही. प्रत्येक आउटबाउंड मॉडेल कॉलचे ट्रॅकिंग सुरू करून आणि अपयशांचे विशिष्ट, कृती करण्यायोग्य सिग्नल्समध्ये वर्गीकरण करून सुरुवात करा.

जेव्हा एखाद्या प्रोव्हायडरचा एंडपॉइंट हँग होतो, तेव्हा API टाइमआउटकडे लक्ष द्या. रेट लिमिट एरर्सकडे (सहसा HTTP 429s) लक्ष द्या — जे सहसा ट्रॅफिक वाढल्यावर किंवा मासिक कोटा संपल्यावर येतात. तुमच्या पार्सर पाइपलाइनला क्रॅश करणाऱ्या अयोग्य JSON आउटपुटकडे लक्ष द्या. HTTP लेयरवर यशस्वी वाटणारे पण ज्यामध्ये कोणतेही उपयुक्त कंटेंट नसलेले रिकामे किंवा अपूर्ण प्रतिसाद तपासा. कोणताही हार्ड टाइमआउट येण्यापूर्वी चॅटचा अनुभव खराब करणाऱ्या हाय लॅटन्सीकडे लक्ष द्या. युजर इनपुट मॉडेलच्या विंडोपेक्षा वाढल्यास होणाऱ्या कॉन्टेक्स्ट लेंथ ओव्हरफ्लोकडे लक्ष द्या. आणि सर्वात सूक्ष्म अपयश म्हणजे 'क्वालिटी रिग्रेशन'कडे लक्ष द्या: मॉडेल प्रतिसाद देते, पण प्रोव्हायडरच्या बाजूने अपडेट झाल्यानंतर त्याची उत्तरे भरकटतात, अस्पष्ट होतात किंवा फॉरमॅटिंग सूचनांकडे दुर्लक्ष करतात.

यातील प्रत्येक सिग्नलमुळे वेगळी प्रतिक्रिया दिली पाहिजे. टाइमआउटसाठी 'रिट्राय' (retry) करणे योग्य आहे. चुकीच्या JSON साठी मॉडेल बदलणे योग्य आहे. रेट लिमिटचा अर्थ असा असू शकतो की तुम्हाला पूर्णपणे वेगळ्या प्रोव्हायडरचा वापर करण्याची गरज आहे.

फॉलबॅक वर्कफ्लोनुसार जुळवा

प्रत्येक कामासाठी एकच फॉलबॅक नियम वापरणे ही आपत्ती ডেকে आणण्यासारखे आहे. चॅटबॉट आणि बॅकग्राउंड डेटा एक्सट्रॅक्शन जॉबच्या गरजा पूर्णपणे भिन्न असतात. तुमच्या फॉलबॅकची रचना विशिष्ट वर्कफ्लोनुसार करा.

चॅटबॉट्सना वेग आणि संवादाचा ओघ हवा असतो. वापरकर्ते थोडे सामान्य उत्तर स्वीकारतील, पण पाच सेकंदाचा विलंब ते सहन करणार नाहीत. जर तुमचे प्राथमिक मॉडेल मंदावले, तर जलद बॅकअप मॉडेलवर (fallback) जा — सहसा त्याच मॉडेल फॅमिलीमधील एखादे लहान व्हेरिएंट किंवा दुसऱ्या प्रोव्हायडरचे स्पीड-टियर मॉडेल. संवाद सुरू ठेवा.

RAG सिस्टिम्सना अचूकता हवी असते. तुम्ही आधीच रिट्रिव्हलसाठी (retrieval) खर्च केला आहे — वेक्टर सर्च, रँकिंग, कदाचित वेब क्रॉलिंग. जर जनरेटरने दिलेल्या कॉन्टेक्स्टचा आदर केला नाही, तर तो सर्व प्रयत्न वाया जातील. जरी ते मॉडेल संथ असले तरी, अचूक सूचनांचे पालन आणि लाँग-कॉन्टेक्स्ट समजण्यासाठी ओळखल्या जाणाऱ्या मॉडेलवर फॉलबॅक करा.

कोडिंग टूल्सना लॉजिक हवे असते. डेव्हलपर्सना अलंकारिक स्पष्टीकरणापेक्षा अचूक सिंटॅक्स आणि वैध API कॉल्स हवे असतात. जर प्राथमिक मॉडेल फंक्शन्समध्ये चुका (hallucinating) करू लागले किंवा एज केसेस सोडवायला विसरले, तर कोडवर विशेष प्रशिक्षण (fine-tuned) घेतलेल्या मॉडेलवर स्विच करा. कंपाईल-रेडी आउटपुटसाठी थोड्या जास्त लॅटन्सीचा स्वीकार करा.

JSON एक्सट्रॅक्शनला स्ट्रक्चर हवे असते. स्ट्रक्चर्ड जनरेशन हे नाजूक असते. एक गहाळ कंस (bracket) किंवा चुकीचे एस्केप केलेले कोट डेटाबेसमध्ये लिहिताना अडथळा आणू शकतात. जर तुमचे प्राथमिक मॉडेल स्कीमा पाळण्यात चुकले, तर एकदा पुन्हा प्रयत्न करा आणि नंतर उच्च फॉरमॅटिंग विश्वासार्हता असलेल्या मॉडेलवर स्विच करा. आश्चर्य म्हणजे, आज्ञाधारकतेसाठी ट्यून केलेली लहान मॉडेल्स अनेकदा या विशिष्ट कामात मोठ्या मॉडेल्सपेक्षा चांगली कामगिरी करतात.

ऑटोमेशन आणि बॅच जॉब्सना खर्च नियंत्रणाची गरज असते. बॅकग्राउंड क्लासिफायर्स, लॉग समरायझर्स आणि नोटिफिकेशन जनरेटर्स सतत चालतात. तुमच्या प्राथमिक मॉडेलच्या किमतीत झालेली वाढ दैनंदिन बिल व्यवस्थापित करण्याऐवजी बजेट संकट निर्माण करू शकते. या नॉन-क्रिटिकल कामांसाठी स्वस्त आणि स्थिर मॉडेल तयार ठेवा. जर आउटपुटची गुणवत्ता थोडी कमी झाली, तर त्याचा व्यवसायावर होणारा परिणाम सहसा नगण्य असतो.

स्विच करण्यापूर्वी तुमच्या मर्यादा जाणून घ्या

मॉडेल्स अंधाधुंदपणे बदलणे नवीन समस्या निर्माण करू शकते. जर तुम्ही एका शक्तिशाली मॉडेलवरून कमकुवत मॉडेलवर गेलात, तर बॅकअप मॉडेल सूक्ष्म प्रॉम्प्ट्स समजून घेण्यास असमर्थ ठरू शकते आणि चुकीचा डेटा तयार करू शकते, ज्यामुळे पुढील प्रक्रियेत चुका होऊ शकतात. जर तुम्ही मोठ्या मॉडेलकडे वळलात, तर तुम्ही गुणवत्तेची समस्या सोडवू शकता पण काही तासांतच तुमचे बजेट कोलमडू शकते.

कोणत्याही मॉडेलला फॉलबॅक स्टेटस देण्यापूर्वी, सहा घटकांच्या आधारे त्याचे ऑडिट करा.

  • मॉडेलची क्षमता: ते खरोखर प्रॉम्प्टचा प्रकार हाताळू शकते का, की ते वेगळ्या पद्धतीने अपयशी ठरेल?
  • भाषा समर्थन: तुमचे बॅकअप मॉडेल इंग्रजीमध्ये उत्तम कामगिरी करू शकते परंतु हिंदी, स्पॅनिश किंवा जपानीमध्ये चुकीची माहिती (hallucinate) देऊ शकते.
  • कॉन्टेक्स्ट विंडोचा आकार: जर तुमचा इनपुट ५०,००० टोकन्सचा असेल, तर १६,०००-टोकन मर्यादा असलेले फॉलबॅक माहिती कापून टाकेल आणि त्याचा अर्थ नष्ट करेल.
  • लॅटन्सी (Latency): तुमच्या प्रदेशासाठी काही प्रदाते (providers) इतरांच्या तुलनेत सातत्याने वेगवान असतात.
  • प्रति विनंती खर्च: एक निश्चित मर्यादा (ceiling) ठरवा. पीक व्हॉल्यूममध्ये फॉलबॅकचा किती खर्च येईल हे जाणून घ्या.
  • आउटपुटची विश्वासार्हता: ते प्रत्येक वेळी आउटपुट फॉरमॅटचे पालन करेल का, की फक्त मंगळवारीच?

प्रभावी चार फॉलबॅक पॅटर्न (Fallback Patterns)

प्रत्येक अपयशासाठी एकच उपाय पुरेसा नसतो. फॉलबॅक प्रकारांचा एक टूलकिट तयार करा आणि त्यांचा जाणीवपूर्वक वापर करा.

Retry fallback. तात्पुरत्या नेटवर्क त्रुटी आणि प्रदात्यांच्या अल्पकालीन खंडित सेवांसाठी, exponential backoff वापरून त्याच मॉडेलला पुन्हा प्रयत्न (retry) करा. चुकीच्या फॉरमॅटमधील आउटपुट किंवा कॉन्टेक्स्ट ओव्हरफ्लोसाठी पुन्हा प्रयत्न करू नका — एकच चुकीचा प्रॉम्प्ट दोनदा पाठवल्याने फारसा फायदा होत नाही.

Equivalent fallback. जेव्हा तुमचा प्राथमिक प्रदाता (provider) उपलब्ध नसेल किंवा मर्यादित असेल, तेव्हा दुसऱ्या प्रदात्याच्या समान मॉडेलवर स्विच करा. एका frontier model कडून साधारणपणे त्याच वर्गातील दुसऱ्या मॉडेलकडे वळण्यासाठी सहसा प्रॉम्प्टमध्ये खूप कमी बदल करावे लागतात आणि आउटपुटची गुणवत्ताही टिकून राहते.

Cheaper fallback. कमी महत्त्वाच्या कामांसाठी कमी खर्चाचे मॉडेल राखून ठेवा. जर स्वस्त पर्याय संघर्ष करत असेल, तर कमी मूल्याच्या कामासाठी प्रीमियम टोकन्स खर्च करण्याऐवजी त्या फीचरची कार्यक्षमता हळूहळू कमी करा (degrade gracefully).

Stronger fallback. हे ऐकायला उलट वाटू शकते, पण ते आवश्यक आहे. जेव्हा एखादे मिड-टियर मॉडेल जटिल तर्क (reasoning), बहु-स्तरीय गणित किंवा सूक्ष्म कायदेशीर विश्लेषणात वारंवार अडकते, तेव्हा अधिक सक्षम मॉडेलकडे वळा. जिथे अचूकता महसूल किंवा सुरक्षितता जपते, अशा उच्च-मूल्य असलेल्या युजर पाथसाठी याचा मर्यादित वापर करा.

तुमच्या आर्किटेक्चरमध्ये लॉजिक समाविष्ट करा

ॲप्लिकेशन कोडमधील डझनभर try-catch ब्लॉक्समध्ये फॉलबॅक लॉजिक विखुरले जाऊ देऊ नका. राउटिंगला इन्फ्रास्ट्रक्चरप्रमाणे हाताळा. एक मिडलवेअर लेयर तयार करा जो टास्कच्या प्रकारांना मॉडेल्सच्या क्रमिक सूचीशी (ordered lists) जोडेल, ज्यामध्ये प्रत्येक मॉडेलसाठी स्वतःची टाइमआउट मर्यादा, रीट्राय पॉलिसी आणि सर्किट ब्रेकर असेल.

फॉलबॅक इव्हेंट्सना 'first-class metrics' म्हणून ट्रॅक करा. एरर रेट तुम्हाला मॉडेल कधी डाऊन आहे हे सांगतो; फॉलबॅक रेट तुम्हाला मॉडेल कामासाठी चुकीचे कधी आहे हे सांगतो. जर तुमची सिस्टम ३० किंवा ४० टक्के वेळा फॉलबॅक करत असेल, तर तुमचे प्राथमिक मॉडेल वर्कलोडशी योग्यरित्या सुसंगत नाही. हे केवळ तुमच्या एरर हँडलिंगचे नाही, तर मॉडेल निवडीचे पुनर्मूल्यांकन करण्याचे संकेत आहेत.

स्पष्ट बजेट निश्चित करा. फॉलबॅक म्हणजे कधीही 'ब्लँक चेक' नसावा. जर लोड असताना तुम्ही प्रीमियम मॉडेलकडे वळत असाल, तर प्रति मिनिट वाढवलेल्या विनंतींची (escalated requests) संख्या मर्यादित करा. तुमच्या अपटाइमप्रमाणेच तुमच्या खिशाचेही तितक्याच काटेकोरपणे संरक्षण करा.

खरी परीक्षा

तुम्ही केवळ डेमोसाठी बनवत नाही आहात. तुम्ही मंगळवारी दुपारी ३ वाजेसाठी तयारी करत आहात, जेव्हा API मंद असतो, युजर वाट पाहत असतो आणि फायनान्स टीम नुकतेच विचारते की AI बिल दुप्पट का झाले. एक प्रगल्भ फॉलबॅक स्ट्रॅटेजी उत्पादन स्थिर ठेवते, युजर एक्सपिरियन्स सुसंगत ठेवते आणि तुमचे खर्च अंदाजित ठेवण्यास मदत करते.

तुमचे प्राथमिक मॉडेल काळजीपूर्वक निवडा. परंतु, जेव्हा ते तुम्हाला निराश करते, तेव्हा काय होईल याचे नियोजन करण्यासाठी दुप्पट वेळ खर्च करा.

Source: How to Design AI Model Fallback Rules for Multi-Model Apps

Community: GyaanSetu AI on Telegram