𝗔𝗜 𝗠𝗼𝗱𝗲𝗹 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿 𝗗𝗿𝗶𝗹𝗹𝘀: 𝗞𝗲𝗲𝗽 𝗔𝗴𝗲𝗻𝘁𝘀 𝗨𝘀𝗲𝗳𝘂𝗹 𝗪𝗵𝗲𝗻 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 𝗕𝗿𝗲𝗮𝗸
एक मॉडल फ़ॉलबैक जो केवल एक डायग्राम में काम करता है, वह रेजिलिएंस (resilience) नहीं है। यह केवल बेहतर ब्रांडिंग के साथ बनाया गया एक प्लान है।
यदि आपका प्रोडक्ट AI एजेंट्स का उपयोग करता है, तो एक धीमा प्रोवाइडर या रेट-लिमिट स्पाइक यूजर एक्सपीरियंस को खराब कर सकता है। असली खतरा पूरी तरह से आउटेज (outage) होना नहीं है। असली खतरा एक आधा-काम करने वाला फ़ॉलबैक है। ऐसा तब होता है जब एक बैकअप मॉडल बिना यूजर को बताए चुपचाप डेटा फॉर्मेट बदल देता है, टूल स्टेट (tool state) को हटा देता है, या साइटेशन (citations) को छोड़ देता है।
प्रोडक्शन ट्रैफिक आपको कठिन तरीके से सीखने पर मजबूर करे, उससे पहले आपको व्यावहारिक फेलओवर ड्रिल्स (failover drills) चलानी चाहिए।
लक्ष्य हर मॉडल को एक-दूसरे की जगह इस्तेमाल करने योग्य बनाना नहीं है। लक्ष्य यह है कि जब प्राइमरी मॉडल फेल हो जाए, तो वर्कफ़्लो सुरक्षित और सटीक बना रहे।
अधिकांश टीमें एक सरल चेन का उपयोग करती हैं: पहले प्राइमरी मॉडल को आज़माएं, फिर बैकअप, और फिर एरर दिखाएं। यह AI सिस्टम की वास्तविक समस्याओं को नज़रअंदाज़ कर देता है। AI सूक्ष्म तरीकों से विफल होता है:
• एक बैकअप मॉडल अलग-अलग फील्ड अर्थों के साथ JSON वापस करता है। • एक सस्ता मॉडल आपकी टूल नीतियों (tool policies) को नज़रअंदाज़ कर देता है। • एक प्रोवाइडर बहुत धीरे टोकन स्ट्रीम करता है। • एक फ़ॉलबैक मॉडल में समान फंक्शन-कॉलिंग फॉर्मेट नहीं होता है। • एजेंट बार-बार कोशिश करता है और यूजर का बजट खत्म कर देता है।
AI मॉडल फेलओवर ड्रिल एक नियोजित टेस्ट है। आप जानबूझकर एक मॉडल पाथ को तोड़ते हैं यह देखने के लिए कि क्या प्रोडक्ट सुरक्षित रहता है।
एक अच्छा ड्रिल चेक करता है:
- क्या वर्कफ़्लो चलता रहता है?
- क्या यह स्कीमा और टूल स्टेट को सुरक्षित रखता है?
- क्या यह कॉस्ट और लेटेंसी बजट के भीतर रहता है?
- क्या यह अगली बार के लिए एक रिग्रेशन टेस्ट बनाता है?
हर प्रॉम्प्ट को कई प्रोवाइडर्स के साथ काम करने लायक बनाने से शुरुआत न करें। उन वर्कफ़्लो से शुरुआत करें जहाँ विफलता भरोसे को खत्म कर देती है।
हाई-प्रायोरिटी वर्कफ़्लो:
- कस्टमर-फेसिंग चैट
- रिपोर्ट जनरेशन
- टूल कॉल करने वाले एजेंट वर्कफ़्लो
- साइटेशन के साथ RAG उत्तर
- स्ट्रक्चर्ड फील्ड्स में डेटा एक्सट्रैक्शन
सबसे अच्छा डिज़ाइन एक कॉन्ट्रैक्ट से शुरू होता है, न कि मॉडल नामों की सूची से। एक फ़ॉलबैक कॉन्ट्रैक्ट यह परिभाषित करता है कि सभी प्रोवाइडर्स में क्या चीज़ समान रहनी चाहिए। एक सपोर्ट एजेंट के लिए, इसमें शामिल हो सकते हैं:
- इनपुट और आउटपुट शेप्स
- कॉन्फिडेंस लेवल और साइटेशन
- टूल परमिशन और बचा हुआ बजट
- क्वालिटी गेट्स और वैलिडेशन रूल्स
कभी-कभी सही फ़ॉलबैक कोई दूसरा मॉडल नहीं होता है। यह हो सकता है:
- यूजर से कन्फर्मेशन मांगना
- आंशिक परिणाम (partial result) वापस करना
- कार्य को बाद के लिए कतार (queue) में डालना
- वर्कफ़्लो को ह्यूमन रिव्यू के लिए भेजना
हर विफलता को दूसरा मॉडल आज़माने का कारण न मानें। त्रुटियों (errors) और फॉर्मेट को सामान्य करने के लिए एक model adapter का उपयोग करें। इससे आपके drills आसान हो जाते हैं क्योंकि आप अपने मुख्य logic को बदले बिना विफलताओं को simulate कर सकते हैं।
शुरुआत करने के लिए ये तीन drills चलाएं:
- The Timeout Drill: प्राइमरी मॉडल को sleep मोड में जाने के लिए मजबूर करें। सत्यापित करें कि fallback आपके latency budget के भीतर होता है।
- The Rate Limit Drill: 429 error उत्पन्न करें। सत्यापित करें कि आपका सिस्टम backoff का उपयोग करता है और tenant budget की रक्षा करता है।
- The Schema Drill: मॉडल को invalid JSON वापस करने के लिए मजबूर करें। सत्यापित करें कि आपका सिस्टम output को validate करता है या workflow को सुरक्षित रूप से रोकता है।
उपयोगकर्ताओं को आपके provider विवरण जानने की आवश्यकता नहीं है। उन्हें ईमानदार व्यवहार की आवश्यकता है।
खराब संदेश: कुछ गलत हो गया। अच्छा संदेश: मैं अभी भी मदद कर सकता हूँ, लेकिन लाइव एक्शन अस्थायी रूप से सीमित हैं। मैं आपकी समीक्षा के लिए अगला कदम तैयार कर सकता हूँ।
स्पष्ट सीमाओं के माध्यम से विश्वास बनाएं, न कि यह दिखावा करके कि सब कुछ ठीक है।
Optional learning community: https://t.me/GyaanSetuAi