शुरू से अंत तक उत्पादन: सत्यापन, निगरानी और नैतिकता

लाभ:

एंड-टू-एंड आर्किटेक्चर डिज़ाइन कर सकते हैं जो एलएलएम सुविधा को विचार से उत्पादन तक ले जाता है
सत्यापन प्रवर्तन, मानव अनुमोदन और ट्रैकिंग (लॉगिंग/मेट्रिक्स) की परतें स्थापित करता है
सीमाएँ नैतिकता और गोपनीयता सिद्धांतों को उत्पादन निर्णयों में अनुवादित करती हैं

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

उत्पादन वास्तुकला की परतें

एक ठोस एलएलएम योग्यता में लगभग पाँच परतें होती हैं:

इनपुट परत: डेटा एकत्र करें, उसे साफ करें, संवेदनशील क्षेत्रों को छिपाएं, केवल वही प्रसारित करें जो आवश्यक है।
मॉडल परत: सही मॉडल (यूनिट 5) का चयन करें, सिस्टम प्रॉम्प्ट और पैरामीटर (यूनिट 4), कैश (यूनिट 6) सेट करें।
सत्यापन परत: यदि आवश्यक हो तो स्कीमा/नियम, स्रोत और मानव अनुमोदन के विरुद्ध आउटपुट की जांच करें।
कार्रवाई परत: मान्य आउटपुट के साथ कार्रवाई करें; उच्च प्रभाव वाले कार्यों को कैप्चर करें.
निगरानी परत: प्रत्येक कॉल, लागत, त्रुटि और गुणवत्ता को रिकॉर्ड करें और मापें।

ये परतें एक पाइपलाइन हैं; प्रत्येक पिछले वाले के आउटपुट की जाँच करता है।

सत्यापन क्यों आवश्यक है?

एलएलएम धाराप्रवाह लेकिन कभी-कभी गलत आउटपुट दे सकते हैं। इसे मतिभ्रम कहा जाता है: मॉडल ऐसी जानकारी गढ़ सकता है जो सच प्रतीत होती है लेकिन सच नहीं है। चैट गेम में यह सहनीय है; उत्पादन प्रणाली (चालान, स्वास्थ्य, कानूनी, वित्त) में बर्दाश्त नहीं किया जा सकता। तो यह आँख बंद करके अविश्वसनीय निकला; पुष्टि हो गई है.

सत्यापन परतें (प्रभाव से बढ़ रही हैं):

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

सावधानी: "मॉडल बहुत अच्छा है, किसी और सत्यापन की आवश्यकता नहीं है" सबसे खतरनाक उत्पादन भ्रांति है। कोई फर्क नहीं पड़ता कि मॉडल कितना अच्छा है, सत्यापन परत उच्च प्रभाव वाले निर्णयों में एक सुरक्षा जाल है। यहां तक कि एक गलत स्वचालित निर्णय भी सारा बचा हुआ समय छीन सकता है।

मानव-इन-लूप

जरूरी नहीं कि हर निर्णय पूरी तरह स्वचालित हो. ह्यूमन-इन-द-लूप दृष्टिकोण में, मॉडल काम को गति देता है और मानव इसे मंजूरी देता है। सही संतुलन निर्णय के प्रभाव और उस कार्य पर मॉडल की विश्वसनीयता पर निर्भर करता है।

फैसले का असर

दृष्टिकोण

निम्न (लेबल सुझाव, ड्राफ्ट)

पूर्ण स्वचालन; त्रुटि सस्ती और प्रतिवर्ती है

माध्यम (रूटिंग, प्राथमिकता निर्धारण)

स्वचालन + नमूनाकरण नियंत्रण

उच्च (धन, अनुबंध, स्वास्थ्य, विलोपन)

मानवीय सहमति अनिवार्य है; मॉडल केवल सुझाव देता है

निगरानी: आप जो नहीं देखते उसे प्रबंधित नहीं कर सकते

उत्पादन में, आपको प्रत्येक कॉल की निगरानी करनी होगी। निगरानी के बिना, आप लागत, गुणवत्ता में सुधार नहीं कर सकते, या किसी समस्या को जल्दी नहीं पकड़ सकते। रिकॉर्ड करने के लिए मुख्य मेट्रिक्स:

उपयोग/लागत: प्रति अनुरोध और कुल टोकन, मॉडल वितरण, दैनिक खर्च।
विलंबता: औसत और सबसे खराब स्थिति में प्रतिक्रिया समय।
त्रुटि दर: 429/500 दरें, पुनः प्रयास, परित्याग।
गुणवत्ता: सत्यापन स्तर पर अस्वीकृत आउटपुट दर, मानव अनुमोदन पर सुधार दर, उपयोगकर्ता प्रतिक्रिया।

टिप: मॉनिटरिंग लॉग में संवेदनशील डेटा (व्यक्तिगत जानकारी, कुंजियाँ) न लिखें। गोपनीयता के दायरे में लॉग पर विचार करें; यदि आवश्यक हो तो मास्क लगाकर रिकॉर्ड करें (इकाई 9)।

नैतिकता और सीमाएँ

तकनीकी सटीकता के साथ-साथ नैतिक जिम्मेदारी भी उत्पादन निर्णय का एक हिस्सा है:

पारदर्शिता: उपयोगकर्ता को पता होना चाहिए कि वे कृत्रिम बुद्धि से बात कर रहे हैं या इंसान से।
निष्पक्षता और पूर्वाग्रह: मॉडल उस डेटा से पूर्वाग्रह ले सकता है जिस पर उसे प्रशिक्षित किया गया है; उच्च प्रभाव वाले निर्णयों (नियुक्ति, क्रेडिट) में भेदभावपूर्ण परिणामों की निगरानी करें।
दायित्व: यदि किसी स्वचालित निर्णय से नुकसान होता है, तो आप जिम्मेदार हैं; "मॉडल ने ऐसा कहा" कोई बचाव नहीं है।
सीमाओं की स्वीकृति: मॉडल कुछ कार्यों को विश्वसनीय रूप से नहीं कर सकता है; उन्हें स्वचालित न करना भी एक डिज़ाइन निर्णय है।

कॉपी करने योग्य टेम्पलेट

# सत्यापन चेकलिस्ट (आउटपुट जनरेशन के बाद)1) क्या स्कीमा वैध है? (संरचित आउटपुट सत्यापन)2) क्या मान समझ में आते हैं? (नियम जांच: सीमा, दिनांक, एनम)3) क्या दावा स्रोत पर आधारित है? (यदि दस्तावेज़ में नहीं है तो अस्वीकार करें)4) क्या प्रभाव अधिक है? → मानव अनुमोदन के लिए भेजें5) यदि सभी पारित हो गए → कार्रवाई की अनुमति दें, सहेजें

# सिस्टम प्रॉम्प्ट जो प्रदान किए गए दस्तावेज़ में केवल स्रोत पर निर्भर होने के लिए बाध्य करता है। ऐसा कुछ भी न जोड़ें जो दस्तावेज़ में न हो. यदि कोई जानकारी दस्तावेज़ में नहीं है, तो "दस्तावेज़ में नहीं मिला" लिखें। कभी भी अनुमान न लगाएं या बातें न बनाएं।

# मानव अनुमोदन सीमा (निर्णय नियम) यदि निर्णय_प्रकार [धन, अनुबंध, हटाएं, स्वास्थ्य] में → मानव अनुमोदन अनिवार्य यदि मॉडल_विश्वास < सीमा या सत्यापन "अनिश्चित" → मानव अनुमोदन के लिए सबमिट करें अन्य → स्वत: लागू + नमूना नियंत्रण

# ट्रेस लॉग टेम्प्लेट (संवेदनशील डेटा लिखना)

कमजोर संकेत / मजबूत संकेत (उत्पादन विश्वसनीयता)

# कमजोर (कोई सत्यापन नहीं, कोई स्रोत नहीं, स्वचालित रूप से लागू होता है) इस अनुरोध का मूल्यांकन करें, धन वापसी का निर्णय लें और आवेदन करें।

# मजबूत (स्रोत-आधारित, सिफारिश उत्पन्न करता है, मानव अनुमोदन के लिए छोड़ देता है) केवल रिटर्न पॉलिसी दस्तावेज़ के आधार पर इस रिटर्न अनुरोध का मूल्यांकन करें। औचित्य के साथ निर्णय की अनुशंसा करें लेकिन कार्यान्वयन न करें: {"सिफारिश":"अनुमोदन|अस्वीकार","कारण":"...","नीति_खंड":"..."}। यदि नीति दस्तावेज़ में कोई स्पष्ट आधार नहीं है, तो "अस्पष्ट" दें। एक प्रतिनिधि अंतिम निर्णय को मंजूरी देगा.

शक्तिशाली संस्करण; यह निर्णय का श्रेय स्रोत को देता है, मॉडल को "कर्ता" के बजाय "सुझावकर्ता" के रूप में रखता है, और मानव अनुमोदन के पीछे उच्च प्रभाव वाला कदम रखता है। यह उत्पादन विश्वसनीयता का सार है.

तीन मिनी मामले

केस 1 - जिस दिन सत्यापन परत सहेजी गई। एक फिनटेक के पास लेन-देन विवरणों को वर्गीकृत करने और स्वचालित लेखांकन रिकॉर्ड बनाने का मॉडल था। उन्होंने नियम सत्यापन जोड़ा: एक बार जब मॉडल गलत तरीके से राशि आउटपुट करता है (दस्तावेज़ में 1,250 के बजाय 12,500), तो "राशि दस्तावेज़ से मेल नहीं खाती" नियम ने आउटपुट को अस्वीकार कर दिया और रिकॉर्ड मानव के पास आ गया। यदि कोई सत्यापन नहीं होता, तो गलत रिकॉर्ड चुपचाप सिस्टम में प्रवेश कर जाता।

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

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

सामान्य गलतियाँ

सत्यापन को छोड़ना: "मॉडल अच्छा है" कहते हुए, आँख बंद करके आउटपुट लागू करना।
उच्च प्रभाव वाले निर्णय को स्वचालित करना: धन/स्वास्थ्य/कानून में मानवीय अनुमोदन आवश्यक है।
निगरानी नहीं करना: लागत और गुणवत्ता संबंधी समस्याओं का पता देर से चलता है।
लॉग में संवेदनशील डेटा लिखना: गोपनीयता का उल्लंघन; इसे मास्क करके बचाएं.
स्रोत पर भरोसा करने की कोशिश नहीं करना: मॉडल वह बना सकता है जो दस्तावेज़ में नहीं है।
सीमाओं की अनदेखी: कुछ कार्यों को स्वचालित न करना सही निर्णय है; पारदर्शिता और जिम्मेदारी आपकी है.

गहरा: रिलीज़ प्रबंधन, रोलबैक, और वृद्धिशील परिनियोजन

एलएलएम सुविधा को उत्पादन में लेना इसे स्थापित करने और इसके बारे में भूलने के बारे में नहीं है; समय के साथ एक लाइव सिस्टम को सुरक्षित रूप से संशोधित करना है। इसके तीन स्तंभ हैं.

संस्करणीकरण. आपका सिस्टम प्रॉम्प्ट, मॉडल चयन और सत्यापन नियम समय के साथ बदलते हैं। संस्करण में प्रत्येक महत्वपूर्ण परिवर्तन करें और रिकॉर्ड करें कि कौन सा संस्करण लाइव है। यदि एक दिन गुणवत्ता गिर जाती है, "हमने क्या बदला?" आपको कुछ ही मिनटों में प्रश्न का उत्तर देने में सक्षम होना चाहिए। संस्करणहीन प्रणाली में, प्रतिगमन का मूल कारण ढूंढने में कई दिन लग जाते हैं।

रोलबैक. यदि कोई नया प्रॉम्प्ट या मॉडल लाइव में अपेक्षा से अधिक खराब व्यवहार करता है, तो आपको तुरंत पिछले, प्रसिद्ध संस्करण पर वापस लौटने में सक्षम होना चाहिए। रोलबैक योजना के बिना परिवर्तन आँख बंद करके जोखिम स्वीकार करना है। "मैंने कुछ बदल दिया, यह खराब हो गया, मैं वापस नहीं जा सकता" सबसे महंगा उत्पादन परिदृश्य है।

क्रमिक रोलआउट. एक ही बार में सभी ट्रैफ़िक में बदलाव लागू करने के बजाय, आप इसे पहले एक छोटे प्रतिशत (जैसे 5%) में रोल आउट करें और मेट्रिक्स (गुणवत्ता, लागत, त्रुटियां) की निगरानी करें। यदि यह अच्छा है, तो आप प्रतिशत बढ़ा देते हैं; यदि यह ख़राब है, तो केवल एक छोटा सा हिस्सा प्रभावित होने पर आप इसे वापस पा लेंगे। इससे जोखिम काफी हद तक सीमित हो जाता है।

ये तीन प्रथाएं पिछली सभी इकाइयों की तकनीकों को जोड़ती हैं: eval (इकाई 5) उपाय पहले से बदलते हैं, निगरानी (यह इकाई) प्रसार के दौरान प्रारंभिक चेतावनी देती है, सत्यापन परत कार्रवाई योग्य होने से पहले गलत आउटपुट पकड़ती है। उत्पादन एक भी सही सेटअप नहीं है; यह एक सतत अनुशासन है जो मापता है, निगरानी करता है और आत्मविश्वास के साथ बदल सकता है। इस अनुशासन को स्थापित करने के लिए पूरा मॉड्यूल आपके लिए है।

संक्षेप में

उत्पादन एक कामकाजी डेमो से कहीं अधिक है: यह इनपुट, मॉडल, सत्यापन, कार्रवाई और निगरानी परतों की एक पाइपलाइन है। सत्यापन के बिना आउटपुट अविश्वसनीय है; उच्च प्रभाव वाले निर्णय मानवीय अनुमोदन से जुड़े होते हैं; प्रत्येक कॉल की लागत, त्रुटियों और गुणवत्ता की निगरानी की जाती है। नैतिकता, पारदर्शिता, पूर्वाग्रह नियंत्रण, जवाबदेही और सीमाओं की स्वीकृति तकनीकी निर्णयों का अभिन्न अंग हैं। इस मॉड्यूल में सीखा गया प्रत्येक भाग इस समग्र डिज़ाइन में एक साथ आता है।

आवेदन कार्य

एलएलएम सुविधा को शुरू से अंत तक डिज़ाइन करें। (1) अपने विशिष्ट कार्य के लिए पाँच परतें (इनपुट, मॉडल, सत्यापन, कार्रवाई, निगरानी) भरें। (2) प्रभाव के आधार पर चिह्नित करें कि किन निर्णयों के लिए मानवीय अनुमोदन की आवश्यकता होगी। (3) कम से कम तीन सत्यापन जाँचें (स्कीमा, नियम, स्रोत) लिखें। (4) उन प्रमुख मेट्रिक्स को निर्धारित करें जिन्हें आप ट्रैक करेंगे और जिन्हें आप लॉग नहीं करेंगे। (5) इस फीचर में एक सीमा और एक नैतिक सिद्धांत लिखें जिसे आप स्वीकार करते हैं।

चेकलिस्ट

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

मॉड्यूल परीक्षा

1. एलएलएम चैट एपीआई में 'सिस्टम' की भूमिका क्या होती है?

ए) मॉडल को स्थायी निर्देश और व्यवहार के नियम देता है जो पूरी बातचीत पर लागू होते हैं ✔
बी) उपयोगकर्ता द्वारा लिखा गया अंतिम प्रश्न रखता है
सी) मॉडल द्वारा उत्पादित प्रतिक्रिया को संग्रहीत करता है
डी) एपीआई कुंजी को एन्क्रिप्ट करता है

विवरण: सिस्टम भूमिका मॉडल को लगातार निर्देश, व्यक्तित्व और नियम देती है जो संपूर्ण वार्तालाप पर लागू होते हैं; यह एक उच्च-स्तरीय रीडायरेक्ट है, जो उपयोगकर्ता संदेशों से अलग है।

2. एपीआई अनुरोध में हर बार बातचीत का इतिहास (पिछले संदेश) दोबारा क्यों भेजा जाता है?

A) बैकअप लेना जरूरी है क्योंकि सर्वर हिस्ट्री डिलीट कर देता है
बी) एपीआई कॉल स्टेटलेस हैं; ✔ प्रत्येक अनुरोध पर संदर्भ पुनः भेजा जाता है क्योंकि मॉडल को इतिहास याद नहीं रहता है
सी) केवल चालान के लिए आवश्यक है, मॉडल पर कोई प्रभाव नहीं पड़ता है
डी) प्रतिक्रिया को धीमा करने से बचने के लिए इतिहास भेजना अनिवार्य है

स्पष्टीकरण: एलएलएम एपीआई कॉल स्टेटलेस हैं; मॉडल पिछले राउंड को याद नहीं रखता है, इसलिए संदर्भ को संरक्षित करने के प्रत्येक अनुरोध पर सभी प्रासंगिक इतिहास को फिर से दर्ज किया जाता है।

3. एलएलएम मूल्य निर्धारण में 'टोकन' क्या है?

ए) एपीआई में लॉग इन करने के लिए वन-टाइम पासवर्ड का उपयोग किया जाता है
बी) प्रत्येक अनुरोध पर एक निश्चित शुल्क का भुगतान किया जाता है
सी) सबसे छोटी इकाई जिसमें मॉडल पाठ को संसाधित करता है; आमतौर पर शब्द भाग ✔ से मेल खाता है
डी) एक इकाई जो केवल आउटपुट की लंबाई मापती है

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

4. अधिकांश एलएलएम प्रदाताओं में आउटपुट टोकन इनपुट टोकन से अधिक महंगे क्यों हैं?

ए) आउटपुट टोकन हमेशा इनपुट से अधिक लंबे होते हैं
बी) इनपुट टोकन निःशुल्क हैं
सी) आउटपुट टोकन इंटरनेट पर दो बार भेजे जाते हैं
डी) इकाई लागत अधिक है क्योंकि आउटपुट उत्पादन के लिए प्रत्येक टोकन के लिए अतिरिक्त गणना की आवश्यकता होती है

विवरण: प्रत्येक आउटपुट टोकन के लिए मॉडल को चरण-दर-चरण पीढ़ी (गणना) करने की आवश्यकता होती है; यह उत्पादन लागत सभी इनपुट को एक साथ संसाधित करने की तुलना में अधिक है, इसलिए आउटपुट इकाई की कीमत आमतौर पर अधिक होती है।

5. किस स्थिति में स्ट्रीमिंग का उपयोग करना सबसे अधिक फायदेमंद है?

ए) लंबे उत्तरों में; अनुमानित देरी को कम करता है और टाइमआउट को रोकता है ✔
बी) केवल बहुत संक्षिप्त, एक शब्द में उत्तर
C) लागत को शून्य तक कम करना
डी) एपीआई कुंजी को छिपाने के लिए

विवरण: लंबी प्रतिक्रियाओं में, स्ट्रीमिंग पहले शब्दों को तुरंत प्रदर्शित करके कथित विलंबता को कम करती है और बड़े max_tokens मानों पर HTTP टाइमआउट को रोकती है।

6. आधुनिक मॉडलों में 'प्रयास' पैरामीटर बढ़ाने से आम तौर पर क्या प्रभाव पड़ता है?

ए) उत्तर को हमेशा छोटा करें
बी) एपीआई कुंजी को स्वचालित रूप से घुमाता है
सी) यह केवल इनपुट टोकन मूल्य को कम करता है
डी) सोच की गहराई और सांकेतिक खर्च बढ़ाता है; इससे गुणवत्ता में सुधार हो सकता है, लेकिन इससे विलंबता और लागत भी बढ़ जाती है

विवरण: प्रयास पैरामीटर यह समायोजित करता है कि मॉडल किसी कार्य के बारे में कितनी गहराई से सोचेगा और कितने टोकन खर्च करेगा; अपग्रेड करने से गुणवत्ता में सुधार हो सकता है, लेकिन इससे विलंबता और लागत भी बढ़ जाती है। सरल कार्यों के लिए कम प्रयास ही पर्याप्त है।

7. एक सरल, उच्च मात्रा वाले वर्गीकरण कार्य के लिए आम तौर पर सबसे अधिक लागत प्रभावी दृष्टिकोण क्या है?

ए) हमेशा सबसे महंगा और सबसे शक्तिशाली मॉडल का उपयोग करें
बी) प्रत्येक अनुरोध के लिए एक ही समय में सभी मॉडलों को कॉल करना
सी) सबसे हल्के/सस्ते मॉडल का चयन करना जो कार्य को थोड़े से मूल्यांकन के साथ सत्यापित करके पूरा करता है ✔
डी) max_tokens मान को अनावश्यक रूप से बहुत अधिक रखना

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

8. किस परिदृश्य में शीघ्र कैशिंग से लागत सबसे अधिक कम हो जाती है?

ए) जब एक बड़े और निश्चित संदर्भ का उपयोग कई अनुरोधों में बार-बार किया जाता है ✔
बी) जब प्रत्येक अनुरोध के साथ एक पूरी तरह से अलग पाठ भेजा जाता है
सी) जब केवल एक ही अनुरोध किया जाता है
डी) आउटपुट टोकन को कम करने के लिए

विवरण: कैशिंग एक उपसर्ग मिलान है; ऐसे मामलों में जहां एक बड़े, अपरिवर्तनीय संदर्भ (सिस्टम प्रॉम्प्ट, दस्तावेज़) को कई अनुरोधों में पुन: उपयोग किया जाता है, कैश से रीडिंग पूरी कीमत का एक छोटा सा अंश (~ 0.1x) है।

9. मुझे प्रॉम्प्ट को कैसे संपादित करना चाहिए ताकि प्रॉम्प्ट कैश हिट हो जाए?

ए) शुरुआत में परिवर्तनीय सामग्री और अंत में निश्चित सामग्री रखना
बी) प्रत्येक अनुरोध के लिए सिस्टम प्रॉम्प्ट में वर्तमान दिनांक और समय एम्बेड करें
सी) शुरुआत में निश्चित सामग्री (सिस्टम प्रॉम्प्ट, दस्तावेज़) और अंत में परिवर्तनीय सामग्री डालना ✔
डी) प्रत्येक अनुरोध के साथ टूल सूची का क्रम बदलना

स्पष्टीकरण: चूंकि कैश एक उपसर्ग मिलान है, इसलिए निश्चित/अपरिवर्तनीय सामग्री (सिस्टम प्रॉम्प्ट, दस्तावेज़) प्रारंभ की जाती है; परिवर्तनीय सामग्री (तिथि, उपयोगकर्ता प्रश्न, अनुरोध आईडी) को अंत में रखा गया है। शुरुआत में बदला गया एक भी बाइट भी कैश को अमान्य कर देगा।

10. किस प्रकार के कार्यभार के लिए बैच प्रोसेसिंग सबसे उपयुक्त है?

ए) लाइव चैट जहां उपयोगकर्ता स्क्रीन पर तत्काल प्रतिक्रिया की उम्मीद करता है
बी) बस एक छोटा सा प्रश्न
सी) एपीआई कुंजी उत्पन्न करना
डी) नौकरियां जो देरी सहनीय हैं, बड़ी मात्रा में हैं और तत्काल परिणाम की आवश्यकता नहीं है ✔

विवरण: बैच प्रसंस्करण बड़ी मात्रा में नौकरियों के लिए उपयुक्त है जिन्हें तत्काल प्रतिक्रिया की आवश्यकता नहीं होती है और देरी के प्रति सहनशील होते हैं; परिणाम कुछ समय बाद आते हैं, लेकिन इकाई लागत आमतौर पर कम होती है।

11. किसी बैच में परिणाम किस अनुरोध से संबंधित हैं इसका आत्मविश्वासपूर्वक मिलान करने के लिए किसका उपयोग किया जाता है?

ए) अनुरोधों का क्रम (स्थिति) भेजना
बी) उत्तरों की लंबाई
सी) एपीआई कुंजी के अंतिम 4 अंक
डी) प्रत्येक अनुरोध के लिए एक अद्वितीय कस्टम_आईडी दी गई ✔

टिप्पणी: थोक परिणाम सबमिशन ऑर्डर से भिन्न क्रम में लौटाए जा सकते हैं; इसलिए प्रत्येक अनुरोध के लिए दिए गए एक अद्वितीय कस्टम_आईडी के साथ, स्थान के बजाय आईडी के आधार पर परिणामों का मिलान करना आवश्यक है।

12. जब आपको एपीआई से 429 (दर सीमा) त्रुटि प्राप्त होती है तो अनुशंसित व्यवहार क्या है?

A) एक ही समय में कई अधिक अनुरोध भेजकर मजबूर करना
बी) पुन: प्रयास के बाद शीर्षक ✔ का पालन करते हुए, घातीय बैकऑफ़ के साथ फिर से प्रयास करना
सी) अनुरोध को पूरी तरह से रद्द करें और उपयोगकर्ता को त्रुटि को क्रैश के रूप में दिखाएं
डी) एपीआई कुंजी बदलना

स्पष्टीकरण: 429 एक पुनः प्रयास योग्य त्रुटि है; सही दृष्टिकोण पुन: प्रयास के बाद हेडर का सम्मान करते हुए, घातीय बैकऑफ़ के साथ पुनः प्रयास करना है। अधिकांश आधिकारिक एसडीके यह स्वचालित रूप से करते हैं।

13. निम्नलिखित में से कौन से HTTP त्रुटि कोड को आम तौर पर पुनः प्रयास योग्य माना जाता है?

ए) 400 (अमान्य अनुरोध)
बी) 401 (प्रमाणीकरण त्रुटि)
सी) 529 (सर्वर ओवरलोडेड) ✔
डी) 404 (नहीं मिला)

स्पष्टीकरण: 429 (गति सीमा), 500 (सर्वर त्रुटि) और 529 (अधिभार) अस्थायी त्रुटियाँ हैं और इन्हें बैक ऑफ करके पुनः प्रयास किया जा सकता है। 400 और 401 जैसी त्रुटियाँ अनुरोध/पहचान संबंधी समस्याएँ हैं; दोबारा कोशिश करने से इसका समाधान नहीं निकलेगा.

14. एपीआई कुंजियों को प्रबंधित करने का सुरक्षित तरीका निम्नलिखित में से कौन सा है?

ए) पर्यावरण चर/छिपे हुए प्रबंधक में भंडारण करना, इसे कोड में एम्बेड न करना और नियमित रूप से घुमाना ✔
बी) कुंजी को सीधे स्रोत कोड में लिखें और इसे रिपॉजिटरी में भेजें
सी) क्लाइंट साइड (ब्राउज़र) जावास्क्रिप्ट में कुंजी डालना
डी) ईमेल के माध्यम से पूरी टीम के साथ एक ही कुंजी साझा करना

विवरण: कुंजियाँ कभी भी स्रोत कोड या रिपॉजिटरी में नहीं लिखी जातीं; इसे एक पर्यावरण चर या छिपे हुए प्रबंधन उपकरण में संग्रहीत किया जाता है, जिसे न्यूनतम विशेषाधिकार दिए जाते हैं, और नियमित रूप से घुमाया जाता है।

15. गोपनीयता के संदर्भ में ऑटोमेशन टूल (n8n, जैपियर, मेक) के साथ एलएलएम एकीकरण का सबसे अच्छा तरीका क्या है?

ए) सभी कच्चे डेटा को मॉडल में भेजना, भले ही यह आवश्यक न हो
बी) प्रवाह चरण के अंदर सादे पाठ में एपीआई कुंजी लिखना
सी) संवेदनशील डेटा को छोटा करना और छुपाना और कुंजी को गुप्त क्रेडेंशियल के रूप में संग्रहीत करना ✔
डी) व्यक्तिगत डेटा को प्रवाह इतिहास में स्थायी रूप से रखना

विवरण: चूंकि स्वचालन में प्रवेश करने वाला डेटा तीसरे पक्ष के सिस्टम और मॉडल से होकर गुजरता है, इसलिए संवेदनशील/व्यक्तिगत डेटा को कम से कम किया जाना चाहिए, छिपाया जाना चाहिए और केवल आवश्यक फ़ील्ड भेजे जाने चाहिए; एपीआई कुंजी को टूल के भीतर गुप्त क्रेडेंशियल के रूप में भी संग्रहीत किया जाता है।

16. एलएलएम आधारित उत्पादन सुविधा में आउटपुट का सत्यापन अनिवार्य क्यों है?

ए) केवल फ़ॉर्मेटिंग की आवश्यकता होती है क्योंकि मॉडल कभी गलती नहीं करता है
बी) क्योंकि मॉडल तरल रूप से उत्पादन कर सकता है लेकिन कभी-कभी गलत तरीके से; स्कीम/नियम का संसाधन और मानव अनुमोदन के साथ ऑडिट किया जाना चाहिए ✔
सी) सत्यापन से बचना चाहिए क्योंकि इससे केवल लागत बढ़ती है
डी) सत्यापन केवल टोकन की संख्या को कम करने के लिए है

विवरण: एलएलएम धाराप्रवाह लेकिन कभी-कभी गलत (मतिभ्रमपूर्ण) आउटपुट उत्पन्न कर सकते हैं; इसलिए यह उच्च प्रभाव वाले निर्णयों में सामने आया; आवश्यकता पड़ने पर स्कीमा/नियमों की जांच, स्रोत सत्यापन और मानव अनुमोदन द्वारा इसका ऑडिट किया जाना चाहिए।