जब FastAPI बैकएंड मॉडल के आउटपुट को अधिकारिक मान लेता है, तो एक सपोर्ट चैट पैसे के लेन-देन वाले काम में बदल सकती है।
इस कोर्स में दिखाए जा रहे फेलियर (गड़बड़ी) में, एक कॉलर ऐप POST /v1/chat पर एक सामान्य दिखने वाला मैसेज भेजता है, FastAPI सर्विस उस टेक्स्ट को मॉडल प्रोवाइडर को भेजती है, और मॉडल एक टूल इंस्ट्रक्शन देता है जो रिफंड रिक्वेस्ट जैसा दिखता है।
बैकएंड मॉडल के सुझाव देते ही टूल कॉल को एक्जीक्यूट कर देता है, बिना यह जांचे कि एंड यूज़र को वह काम करने की अनुमति है या नहीं, और बिना मॉडल आउटपुट को अविश्वसनीय टेक्स्ट माने।
इस फेलियर के लिए किसी खास चीज़ की ज़रूरत नहीं है। बैकएंड वही करता है जिसके लिए उसे बनाया गया था, लेकिन यह सबसे महत्वपूर्ण स्टेप, यानी टूल एक्शन, एक ऐसी स्ट्रिंग के आधार पर चलाता है जो ट्रस्ट बाउंड्री के बाहर से आई है।
जब कोई ऐसा एक्शन हो जाता है जिसे बदला नहीं जा सकता, तो बाद में कोई फ़िल्टर उसके साइड इफ़ेक्ट को ठीक नहीं कर सकता, इसलिए हमें यह तय करना होगा कि पहला असरदार स्टॉप कहाँ होना चाहिए।
वही रिक्वेस्ट कई बाउंड्रीज़ को पार करती है जहाँ अविश्वसनीय टेक्स्ट खर्च या साइड इफ़ेक्ट में बदल जाता है, और कोर्स उसी एक रास्ते पर टिका रहता है ताकि हर कंट्रोल एक खास जगह पर हो।
कॉलर के सही व्यवहार करने पर भी तीन जगहों से अविश्वसनीय टेक्स्ट आता है। कॉलर का मैसेज HTTP रिक्वेस्ट में आता है, रिट्रीव किए गए डॉक्यूमेंट बैकएंड के अपने डेटा स्टोर से आते हैं, और टूल के नतीजे दूसरे सिस्टम से आते हैं जो गलत या नुकसानदेह हो सकते हैं।
दो जगहों पर पैसे और डेटा खर्च हो सकते हैं। मॉडल प्रोवाइडर कॉल टोकन और लागत का इस्तेमाल करता है, और टूल एक्जीक्यूशन उन असली रिसोर्स को पढ़ या बदल सकता है जो शायद यूज़र के न हों।
सिर्फ़ FastAPI सर्विस में उन खर्च वाली जगहों के आस-पास सर्वर-साइड चेक ही भरोसेमंद एनफोर्समेंट पॉइंट हैं। कोर्स ऑथेंटिकेशन, टेनेंट बाइंडिंग, कोटा, इनपुट और आउटपुट फ़िल्टर, टूल ऑथराइजेशन, सैंडबॉक्सिंग और ऑडिट लॉगिंग को स्पष्ट गेट के तौर पर बनाता है, और प्रॉम्प्ट की भाषा इनमें से किसी को भी लागू नहीं करती क्योंकि सिस्टम प्रॉम्प्ट पढ़ने लायक होता है और मॉडल सिर्फ़ टेक्स्ट को फॉलो करता है।
नीचे दिया गया डायग्राम उस सिंगल रिक्वेस्ट पाथ पर हर अविश्वसनीय इनपुट और हर एनफोर्समेंट पॉइंट को दिखाता है जिसे हम आगे बढ़ाते रहते हैं। आइए यह पता करें कि टेक्स्ट कहाँ अधिकार बन जाता है और हम कहाँ मना कर सकते हैं।
यह डायग्राम एक नियम को स्पष्ट करता है। टेक्स्ट ले जाने वाला हर तीर अविश्वसनीय होता है, और केवल हमारी सर्विस के बॉक्स ही अनुरोध को अस्वीकार, सीमित, मान्य, अधिकृत और रिकॉर्ड कर सकते हैं।
एक सुरक्षित API कॉन्ट्रैक्ट के लिए एक जैसे रिफ्यूजल कोड की आवश्यकता होती है, क्योंकि जब कोई गेट अनुरोध को अस्वीकार करता है, तो क्लाइंट और ऑन-कॉल डिबगिंग दोनों ही अनुमानित परिणामों पर निर्भर करते हैं।
हम रिफ्यूजल मैप को एक बार बताते हैं और फिर उसका दोबारा उपयोग करते हैं, और हर रिफ्यूजल को हमेशा उस बाउंड्री से जोड़ते हैं जो उसे लागू करती है, न कि मॉडल से।
401 Unauthorized गायब, अमान्य, रद्द या समझौता किए गए कॉलर क्रेडेंशियल को अस्वीकार करता है, और सर्विस कोटा खर्च करने या प्रोवाइडर को कॉल करने से पहले इसे लौटा देती है।403 Forbidden प्रमाणित कॉलर को उसके अनुमत दायरे के बाहर अस्वीकार करता है, जिसमें अस्वीकृत या समाप्त हो चुकी अनुमति शामिल है, और यह किसी ब्लॉक किए गए डेस्टिनेशन पर टूल फ़ेच को भी अस्वीकार करता है जिससे कभी संपर्क नहीं किया गया।422 Unprocessable Content (RFC 9110) उस मॉडल आउटपुट को अस्वीकार करता है जो स्कीमा वैलिडेशन में विफल रहता है, क्योंकि बिना मान्य आउटपुट केवल टेक्स्ट होता है जब तक कि सर्वर यह साबित न कर दे कि यह टूल कॉन्ट्रैक्ट से मेल खाता है।429 Too Many Requests (साथ में Retry-After) समाप्त हो चुकी दर सीमा या कोटा को अस्वीकार करता है, और काउंटर को साझा किया जाना चाहिए ताकि रेप्लिका चुपचाप सीमा को न बढ़ाएं।503 Service Unavailable तब अस्वीकार करता है जब कोटा काउंटर स्टोर डाउन हो या ओपन सर्किट ब्रेकर लागू करने से रोके, क्योंकि सर्विस सुरक्षित रूप से यह तय नहीं कर सकती कि खर्च की अनुमति है या नहीं।504 Gateway Timeout तब अस्वीकार करता है जब प्रोवाइडर कॉल सर्विस टाइमआउट से अधिक हो जाती है, क्योंकि हैंगिंग कॉल असीमित खपत होती हैं।कोर्स को ठोस बनाए रखने के लिए, हम एक रनिंग आर्टिफैक्ट बनाते हैं और उसे चरण-दर-चरण मजबूत करते हैं। यह आर्टिफैक्ट एक टेनेंट-अवेयर POST /v1/chat रूट है जो ठीक एक टूल को कॉल कर सकता है, और बाद का हर लेसन उस पथ पर एक गेट जोड़ता है।
शुरुआती विफलता में, कॉलर वैध भी हो सकता है, जिसका अर्थ है कि प्रमाणीकरण सफल हो सकता है जबकि अनुरोध अभी भी एक अनधिकृत टूल क्रिया को प्रेरित करता है।
यदि सर्विस टूल कॉल को निष्पादित करने के बाद मॉडल आउटपुट को मान्य करने की प्रतीक्षा करती है, तो स्कीमा वैलिडेशन अभी भी खराब रूप से बने पेलोड को अस्वीकार कर सकता है, लेकिन स्कीमा वैलिडेशन उस सही दिखने वाली क्रिया को उलट नहीं सकता है जिसकी अनुमति कभी नहीं दी जानी चाहिए थी।
महत्वपूर्ण निर्णय यह है कि टूल का कोई ऐसा एक्शन, जिसे बदला न जा सके, उसके शुरू होने से पहले किस चरण में उसे रोका जा सकता है। सबसे पहले किस चरण में खराबी का पता चलता है और प्रक्रिया रुकती है—ऑथेंटिकेशन, टूल ऑथराइजेशन, या आउटपुट वैलिडेशन?