एंड-टू-एंड उत्पादन: पडताळणी, देखरेख आणि नीतिशास्त्र

नफा:

कल्पनेपासून उत्पादनापर्यंत LLM वैशिष्ट्य घेणाऱ्या एंड-टू-एंड आर्किटेक्चरची रचना करू शकते
सत्यापन अंमलबजावणी, मानवी मान्यता आणि ट्रॅकिंग (लॉगिंग/मेट्रिक्स) चे स्तर स्थापित करते
सीमा उत्पादन निर्णयांमध्ये नैतिकता आणि गोपनीयता तत्त्वांचे भाषांतर करतात

मागील दहा युनिट्समध्ये, आम्ही भाग एक एक करून शिकलो: विनंती रचना, टोकन अर्थशास्त्र, प्रवाह, सिस्टम प्रॉम्प्ट, मॉडेल निवड, कॅशे, बॅच, त्रुटी व्यवस्थापन, सुरक्षित की आणि ऑटोमेशन. या शेवटच्या युनिटमध्ये, आम्ही भाग एकत्र करतो आणि सर्वांगीण आर्किटेक्चरची स्थापना करतो ज्यामध्ये कल्पनापासून उत्पादनापर्यंत LLM वैशिष्ट्य आहे. उत्पादन "कार्यरत डेमो" पेक्षा वेगळे आहे: सत्यापन अनिवार्य आहे, आउटपुटचे परीक्षण केले जाणे आवश्यक आहे, सीमा आणि नैतिक तत्त्वे निर्णयांमध्ये अंतर्भूत करणे आवश्यक आहे. हे युनिट मॉड्यूलचे वाहक स्तंभ आहे; आधीचे सगळे इथे एकत्र येतात.

उत्पादन आर्किटेक्चरचे स्तर

ठोस एलएलएम पात्रतेमध्ये साधारणतः पाच स्तर असतात:

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

हे स्तर पाइपलाइन आहेत; प्रत्येकजण मागील आउटपुट तपासतो.

पडताळणी का आवश्यक आहे?

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

पडताळणी स्तर (प्रभावाने वाढते):

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

सावधगिरी: "मॉडेल खूप चांगले आहे, आणखी पडताळणीची गरज नाही" ही उत्पादनाची सर्वात धोकादायक चूक आहे. मॉडेल कितीही चांगले असले तरीही, पडताळणीचा स्तर हा उच्च-प्रभावी निर्णयांमध्ये एक सुरक्षितता जाळ आहे. एक चुकीचा स्वयंचलित निर्णय देखील वाचलेला सर्व वेळ काढून घेऊ शकतो.

मानवी-इन-द-लूप

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

निर्णयाचा परिणाम

दृष्टीकोन

कमी (लेबल सूचना, मसुदा)

पूर्ण ऑटोमेशन; त्रुटी स्वस्त आणि उलट करता येण्यासारखी आहे

मध्यम (राउटिंग, प्राधान्यक्रम)

ऑटोमेशन + सॅम्पलिंग नियंत्रण

उच्च (पैसा, करार, आरोग्य, हटवणे)

मानवी संमती अनिवार्य आहे; मॉडेल फक्त सुचवते

देखरेख: तुम्ही जे पाहत नाही ते तुम्ही व्यवस्थापित करू शकत नाही

उत्पादनामध्ये, आपण प्रत्येक कॉलचे निरीक्षण करणे आवश्यक आहे. निरीक्षणाशिवाय, तुम्ही किंमत, गुणवत्ता सुधारू शकत नाही किंवा समस्या लवकर पकडू शकत नाही. रेकॉर्ड करण्यासाठी मुख्य मेट्रिक्स:

वापर/खर्च: प्रति विनंती आणि एकूण टोकन, मॉडेल वितरण, दैनिक खर्च.
विलंब: सरासरी आणि सर्वात वाईट-केस प्रतिसाद वेळ.
त्रुटी दर: 429/500 दर, पुन्हा प्रयत्न, त्याग.
गुणवत्ता: पडताळणी स्तरावर नाकारलेला आउटपुट दर, मानवी मंजूरीनुसार सुधारणा दर, वापरकर्ता अभिप्राय.

टीप: निरीक्षण नोंदींवर संवेदनशील डेटा (वैयक्तिक माहिती, की) लिहू नका. गोपनीयतेच्या कार्यक्षेत्रातील लॉगचा विचार करा; आवश्यक असल्यास मास्क करून रेकॉर्ड करा (युनिट 9).

नैतिकता आणि सीमा

नैतिक जबाबदारी हा उत्पादन निर्णयाचा तांत्रिक अचूकतेइतकाच एक भाग आहे:

पारदर्शकता: वापरकर्त्याला हे माहित असले पाहिजे की ते कृत्रिम बुद्धिमत्ता किंवा मानवाशी बोलत आहेत.
निष्पक्षता आणि पूर्वाग्रह: मॉडेल ज्या डेटावर प्रशिक्षित आहे त्यावरून पूर्वाग्रह असू शकतो; उच्च-प्रभावी निर्णयांमध्ये (नोकरी, क्रेडिट) भेदभावपूर्ण परिणामांचे निरीक्षण करा.
उत्तरदायित्व: स्वयंचलित निर्णयामुळे नुकसान झाल्यास, आपण जबाबदार आहात; "मॉडेलने असे सांगितले" हा बचाव नाही.
मर्यादांची स्वीकृती: मॉडेल काही कार्ये विश्वसनीयपणे करू शकत नाही; त्यांना स्वयंचलित न करणे देखील एक डिझाइन निर्णय आहे.

कॉपी करण्यायोग्य टेम्पलेट्स

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

# सिस्टम प्रॉम्प्ट जे स्त्रोतावर अवलंबून राहण्यास भाग पाडते, फक्त प्रदान केलेल्या दस्तऐवजातील माहितीवर अवलंबून असते. कागदपत्रात नसलेली कोणतीही गोष्ट जोडू नका. दस्तऐवजात माहिती नसल्यास, "दस्तऐवजात आढळले नाही" असे लिहा. कधीही अंदाज लावू नका किंवा गोष्टी तयार करू नका.

# मानवी मंजूरी मर्यादा (निर्णय नियम) IF निर्णय_प्रकार [पैसा, करार, हटवा, आरोग्य] → मानवी मान्यता अनिवार्यIF मॉडेल_ट्रस्ट < उंबरठा किंवा प्रमाणीकरण "अनिश्चित" → मानवी मंजुरीसाठी सबमिट कराOTHER → स्वयं लागू + सॅम्पलिंग नियंत्रण

# ट्रेस लॉग टेम्प्लेट (संवेदनशील डेटा लिहिणे){ "वेळ":"...", "मॉडेल":"...", "इनपुट_टोकन":..., "आउटपुट_टोकन":..., "विलंब_एमएस":..., "स्टॉप_रिझन":"...", "ऑथेंटिकेशन":"पास केलेले|नाकारलेले|मानवी" /// } की वैयक्तिक डेटा लिहिलेला आहे: "/ NE_}...

कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट (उत्पादन विश्वसनीयता)

# कमजोर (कोणतीही पडताळणी नाही, स्रोत नाही, आपोआप लागू होते) या विनंतीचे मूल्यांकन करा, परतावा निर्णय घ्या आणि अर्ज करा.

# स्ट्राँग (स्रोत-आधारित, शिफारस व्युत्पन्न करते, मानवी मंजुरीसाठी सोडते) केवळ परतीच्या धोरण दस्तऐवजाच्या आधारावर या रिटर्न विनंतीचे मूल्यांकन करा. समर्थनासह निर्णयाची शिफारस करा परंतु अंमलबजावणी करू नका: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. पॉलिसी दस्तऐवजात स्पष्ट आधार नसल्यास, "अस्पष्ट" द्या. एक प्रतिनिधी अंतिम निर्णय मंजूर करेल.

शक्तिशाली आवृत्ती; हे निर्णयाचे श्रेय स्त्रोताला देते, मॉडेलला "कर्ते" ऐवजी "सूचक" म्हणून स्थान देते आणि उच्च-परिणामकारक पाऊल मानवी मंजुरीच्या मागे ठेवते. हे उत्पादन विश्वासार्हतेचे सार आहे.

तीन मिनी केसेस

केस 1 — सत्यापन स्तर जतन केलेला दिवस. फिनटेकमध्ये मॉडेलचे वर्गीकरण व्यवहाराचे वर्णन होते आणि स्वयंचलित लेखा रेकॉर्ड तयार केले जात होते. त्यांनी नियम प्रमाणीकरण जोडले: एकदा मॉडेलने चुकीची रक्कम आउटपुट केली (दस्तऐवजातील 1,250 ऐवजी 12,500), "रक्कम दस्तऐवजाशी जुळत नाही" या नियमाने आउटपुट नाकारले आणि रेकॉर्ड मानवाकडे पडला. कोणतेही सत्यापन नसल्यास, चुकीचे रेकॉर्ड शांतपणे सिस्टममध्ये प्रवेश करेल.

प्रकरण २ - पाळत ठेवून फरारी पकडले गेले. सास टीमने एक मॉनिटरिंग पॅनल स्थापन केले होते; एका सकाळी रोजचा खर्च तिप्पट झाला. लॉगमधून असे दिसून आले की क्लायंटने लूपमध्ये प्रवेश केला आणि हजारो वेळा समान विनंती पाठवली. त्यांनी कोटा आणि डुप्लिकेशन जोडले; काही तासांतच समस्या दूर झाली. ट्रॅकिंगशिवाय, महिन्याच्या शेवटी बिल आश्चर्यचकित होईल.

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

सामान्य चुका

प्रमाणीकरण वगळणे: "मॉडेल चांगले आहे" असे म्हणत आउटपुट आंधळेपणाने लागू करणे.
उच्च-प्रभावी निर्णय स्वयंचलित करणे: पैसा/आरोग्य/कायद्यामध्ये मानवी मान्यता आवश्यक आहे.
देखरेख नाही: किंमत आणि गुणवत्ता समस्या उशीरा शोधल्या जातात.
लॉगवर संवेदनशील डेटा लिहिणे: गोपनीयतेचे उल्लंघन; मास्क लावून सेव्ह करा.
स्त्रोतावर विसंबून राहण्याचा प्रयत्न करत नाही: मॉडेल दस्तऐवजात जे नाही ते बनवू शकते.
मर्यादेकडे दुर्लक्ष करणे: काही कार्ये स्वयंचलित न करणे हा योग्य निर्णय आहे; पारदर्शकता आणि जबाबदारी तुमची आहे.

सखोल: प्रकाशन व्यवस्थापन, रोलबॅक आणि वाढीव उपयोजन

उत्पादनात एलएलएम वैशिष्ट्य घेणे म्हणजे ते सेट करणे आणि त्याबद्दल विसरणे नाही; कालांतराने थेट प्रणालीमध्ये सुरक्षितपणे बदल करणे आहे. यात तीन खांब आहेत.

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

रोलबॅक. जर नवीन प्रॉम्प्ट किंवा मॉडेल लाइव्हमध्ये अपेक्षेपेक्षा वाईट वर्तन करत असेल, तर तुम्ही त्वरीत मागील, सुप्रसिद्ध आवृत्तीवर परत येऊ शकता. रोलबॅक योजनेशिवाय बदल म्हणजे थेट धोका स्वीकारणे. "मी काहीतरी बदलले, ते खराब झाले, मी परत जाऊ शकत नाही" ही सर्वात महाग उत्पादन परिस्थिती आहे.

हळूहळू रोलआउट. सर्व ट्रॅफिकमध्ये एकाच वेळी बदल लागू करण्याऐवजी, तुम्ही ते प्रथम एका लहान टक्केवारीत (उदा. 5%) रोल आउट करा आणि मेट्रिक्स (गुणवत्ता, किंमत, त्रुटी) मॉनिटर करा. ते चांगले असल्यास, आपण टक्केवारी वाढवा; जर ते खराब असेल, तर तुम्हाला ते फक्त एका लहान विभागावर परिणाम करून परत मिळेल. यामुळे जोखीम मोठ्या प्रमाणात मर्यादित होते.

या तीन पद्धती मागील सर्व युनिट्समधील तंत्रे एकत्र करतात: eval (युनिट 5) अगोदरच बदल घडवून आणतात, निरीक्षण (हे युनिट) प्रसारादरम्यान लवकर चेतावणी देते, सत्यापन स्तर कारवाई करण्यायोग्य होण्यापूर्वी चुकीचे आउटपुट पकडते. उत्पादन एकच योग्य सेटअप नाही; ही एक सतत शिस्त आहे जी मोजमाप करते, मॉनिटर करते आणि आत्मविश्वासाने बदलू शकते. ही शिस्त प्रस्थापित करण्यासाठी संपूर्ण मॉड्यूल तुमच्यासाठी आहे.

सारांशात

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

अर्ज कार्य

LLM वैशिष्ट्य एंड-टू-एंड डिझाइन करा. (1) तुमच्या विशिष्ट कार्यासाठी पाच स्तर (इनपुट, मॉडेल, सत्यापन, क्रिया, निरीक्षण) भरा. (२) कोणत्या निर्णयांना मानवी संमतीची आवश्यकता असेल या प्रभावाने चिन्हांकित करा. (३) किमान तीन प्रमाणीकरण तपासा (स्कीमा, नियम, स्रोत) लिहा. (४) तुम्ही कोणते मागोवा घ्याल आणि कोणते लॉग करणार नाही ते मुख्य मेट्रिक्स ठरवा. (५) तुम्ही या वैशिष्ट्यामध्ये स्वीकारता अशी मर्यादा आणि नैतिक तत्त्व लिहा.

चेकलिस्ट

मी उत्पादन पाइपलाइनचे पाच स्तर डिझाइन करू शकतो.
[] मी स्कीमा, नियम आणि स्रोत विरुद्ध आउटपुट प्रमाणित करू शकतो.
[ ] मी निर्णयाच्या प्रभावावर आधारित मानवी मंजूरी थ्रेशोल्ड सेट करू शकतो.
[ ] मी किंमत, त्रुटी आणि गुणवत्तेचे निरीक्षण करतो आणि लॉगमध्ये संवेदनशील डेटा न लिहिण्याचा सराव करतो.
मी नैतिकता, जबाबदारी आणि सीमांचे उत्पादन निर्णयांमध्ये रूपांतर करू शकतो.

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

1. LLM चॅट API मध्ये 'सिस्टम' भूमिका काय करते?

अ) मॉडेलला कायमस्वरूपी सूचना आणि वर्तनाचे नियम देतो जे संपूर्ण संभाषणात लागू होतात ✔
ब) वापरकर्त्याने लिहिलेला शेवटचा प्रश्न ठेवतो
सी) मॉडेलद्वारे उत्पादित प्रतिसाद संग्रहित करते
डी) API की एन्क्रिप्ट करते

वर्णन: प्रणालीची भूमिका मॉडेलला सतत सूचना, व्यक्तिमत्व आणि नियम देते जे संपूर्ण संभाषणात लागू होतात; हे एक उच्च-स्तरीय पुनर्निर्देशन आहे, वापरकर्ता संदेशांपेक्षा वेगळे.

2. प्रत्येक वेळी API विनंतीमध्ये संभाषण इतिहास (मागील संदेश) का पाठवला जातो?

अ) सर्व्हरने इतिहास हटवल्यामुळे बॅकअप घेणे आवश्यक आहे
ब) API कॉल स्टेटलेस आहेत; ✔ प्रत्येक विनंतीवर संदर्भ पाठविला जातो कारण मॉडेलला इतिहास आठवत नाही
क) फक्त इनव्हॉइसिंगसाठी आवश्यक, मॉडेलवर कोणताही परिणाम होत नाही
ड) प्रतिसाद कमी होऊ नये म्हणून इतिहास पाठवणे अनिवार्य आहे

स्पष्टीकरण: LLM API कॉल स्टेटलेस आहेत; मॉडेलला मागील फेऱ्या आठवत नाहीत, त्यामुळे संदर्भ जतन करण्याच्या प्रत्येक विनंतीवर सर्व संबंधित इतिहास पाठविला जातो.

3. LLM किंमतीमध्ये 'टोकन' म्हणजे काय?

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

वर्णन: टोकन हे सर्वात लहान युनिट आहे ज्यामध्ये मॉडेल मजकूरावर प्रक्रिया करते; हे सहसा शब्दाच्या तुकड्याशी संबंधित असते आणि टोकनच्या संख्येवर आधारित इनपुट आणि आउटपुट दोन्ही चार्ज केले जातात.

4. बहुतेक LLM प्रदात्यांकडे आउटपुट टोकन इनपुट टोकनपेक्षा अधिक महाग का आहेत?

अ) आउटपुट टोकन नेहमी इनपुटपेक्षा लांब असतात
ब) इनपुट टोकन विनामूल्य आहेत
क) आउटपुट टोकन इंटरनेटवर दोनदा पाठवले जातात
ड) युनिटची किंमत जास्त आहे कारण आउटपुट निर्मितीसाठी प्रत्येक टोकनसाठी अतिरिक्त गणना आवश्यक आहे ✔

वर्णन: प्रत्येक आउटपुट टोकनसाठी मॉडेलला चरण-दर-चरण निर्मिती (गणना) करणे आवश्यक आहे; ही उत्पादन किंमत एकाच वेळी इनपुटवर प्रक्रिया करण्यापेक्षा जास्त आहे, म्हणून आउटपुट युनिटची किंमत सहसा जास्त असते.

5. कोणत्या परिस्थितीत प्रवाह वापरणे सर्वात फायदेशीर आहे?

अ) लांब उत्तरांमध्ये; समजलेला विलंब कमी करते आणि कालबाह्य होण्यास प्रतिबंध करते ✔
ब) फक्त अगदी थोडक्यात, एका शब्दात उत्तरे
क) खर्च शून्यावर आणणे
ड) API की लपवण्यासाठी

वर्णन: दीर्घ प्रतिसादांमध्ये, प्रवाह प्रथम शब्द त्वरित दिसण्याद्वारे समजलेली विलंबता कमी करते आणि मोठ्या max_tokens मूल्यांवर HTTP कालबाह्य होण्यास प्रतिबंध करते.

6. आधुनिक मॉडेल्समध्ये 'प्रयत्न' पॅरामीटर वाढवल्याने सामान्यतः काय परिणाम होतो?

अ) उत्तर नेहमी लहान करा
ब) API की आपोआप फिरते
क) हे फक्त इनपुट टोकन किंमत कमी करते
ड) विचारांची खोली आणि टोकन खर्च वाढवते; हे गुणवत्ता सुधारू शकते, परंतु ते विलंबता आणि खर्च देखील वाढवते ✔

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

7. साध्या, उच्च-खंड वर्गीकरण कार्यासाठी सामान्यतः सर्वात किफायतशीर दृष्टीकोन कोणता आहे?

अ) नेहमी सर्वात महाग आणि सर्वात शक्तिशाली मॉडेल वापरा
ब) प्रत्येक विनंतीसाठी सर्व मॉडेल्सना एकाच वेळी कॉल करणे
क) सर्वात हलके/स्वस्त मॉडेल निवडणे जे कार्य पूर्ण करते ते थोड्या इव्हलने सत्यापित करून ✔
डी) कमाल_टोकन्स मूल्य अनावश्यकपणे खूप जास्त ठेवणे

स्पष्टीकरण: जर कार्य क्लिष्ट नसेल, तर सर्वात महाग आणि शक्तिशाली मॉडेल वापरण्याऐवजी ते कार्य सहजपणे पूर्ण करणारे जलद आणि स्वस्त मॉडेल निवडणे (उदा. हायकू वर्ग) खर्चात लक्षणीय घट करेल.

8. कोणत्या परिस्थितीत प्रॉम्प्ट कॅशिंग सर्वात जास्त खर्च कमी करते?

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

वर्णन: कॅशिंग एक उपसर्ग जुळणी आहे; मोठ्या, अपरिवर्तनीय संदर्भ (सिस्टम प्रॉम्प्ट, दस्तऐवज) अनेक विनंत्यांमध्ये पुन्हा वापरले जातात अशा प्रकरणांमध्ये, कॅशेमधून वाचन हा पूर्ण किमतीचा एक लहान अंश (~0.1x) असतो.

9. मी प्रॉम्प्ट कसे संपादित करावे जेणेकरून प्रॉम्प्ट कॅशे हिट होईल?

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

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

10. बॅच प्रोसेसिंग कोणत्या प्रकारच्या वर्कलोडसाठी सर्वात योग्य आहे?

अ) थेट चॅट जिथे वापरकर्त्याला स्क्रीनवर त्वरित प्रतिसादाची अपेक्षा असते
ब) फक्त एक छोटा प्रश्न
क) API की व्युत्पन्न करणे
ड) ज्या नोकऱ्या विलंब सहन करणाऱ्या आहेत, मोठ्या प्रमाणात आहेत आणि त्यांना त्वरित परिणामांची आवश्यकता नाही ✔

वर्णन: बॅच प्रोसेसिंग मोठ्या प्रमाणात नोकऱ्यांसाठी योग्य आहे ज्यांना त्वरित प्रतिसादाची आवश्यकता नसते आणि विलंब सहन करतात; परिणाम काही काळानंतर वितरित केले जातात, परंतु युनिटची किंमत सहसा कमी असते.

11. बॅचमधील निकाल कोणत्या विनंतीशी संबंधित आहेत हे आत्मविश्वासाने जुळण्यासाठी काय वापरले जाते?

अ) विनंत्यांची ऑर्डर (स्थिती) पाठवणे
ब) उत्तरांची लांबी
C) API कीचे शेवटचे 4 अंक
ड) प्रत्येक विनंतीला दिलेला एक अद्वितीय कस्टम_आयडी ✔

टिप्पणी: मोठ्या प्रमाणात परिणाम सबमिशन ऑर्डरपेक्षा वेगळ्या क्रमाने परत केले जाऊ शकतात; त्यामुळे प्रत्येक विनंतीला दिलेल्या अद्वितीय कस्टम_आयडीसह आयडीने परिणाम जुळवणे आवश्यक आहे, स्थान नाही.

12. तुम्हाला API कडून 429 (दर मर्यादा) त्रुटी प्राप्त झाल्यावर शिफारस केलेले वर्तन काय आहे?

अ) एकाच वेळी अनेक विनंत्या पाठवून जबरदस्ती करणे
ब) घातांकीय बॅकऑफसह पुन्हा प्रयत्न करणे, पुन्हा प्रयत्न-नंतर शीर्षलेख ✔
क) विनंती पूर्णपणे रद्द करा आणि त्रुटी वापरकर्त्याला क्रॅश म्हणून दाखवा
ड) API की बदलणे

स्पष्टीकरण: 429 ही पुन्हा प्रयत्न करण्यायोग्य त्रुटी आहे; योग्य दृष्टिकोन म्हणजे घातांकीय बॅकऑफसह पुन्हा प्रयत्न करणे, पुन्हा-प्रयत्नानंतर शीर्षलेखाचा आदर करणे. बहुतेक अधिकृत SDK हे आपोआप करतात.

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

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

स्पष्टीकरण: 429 (वेग मर्यादा), 500 (सर्व्हर त्रुटी) आणि 529 (ओव्हरलोड) या तात्पुरत्या त्रुटी आहेत आणि बॅक ऑफ करून पुन्हा प्रयत्न केला जाऊ शकतो. 400 आणि 401 सारख्या त्रुटी विनंती/ओळख समस्या आहेत; पुन्हा प्रयत्न करून ते सुटणार नाही.

14. API की व्यवस्थापित करण्याचा सुरक्षित मार्ग खालीलपैकी कोणता आहे?

अ) एन्व्हायर्नमेंट व्हेरिएबल/हिडन मॅनेजरमध्ये साठवणे, ते कोडमध्ये एम्बेड न करणे आणि नियमितपणे फिरवणे ✔
ब) की थेट सोर्स कोडमध्ये लिहा आणि रेपॉजिटरीमध्ये पाठवा
क) क्लायंट साइड (ब्राउझर) JavaScript मध्ये की टाकणे
डी) ईमेलद्वारे संपूर्ण टीमसोबत एकच की शेअर करणे

वर्णन: की कधीही सोर्स कोड किंवा रेपॉजिटरीमध्ये लिहिल्या जात नाहीत; हे पर्यावरण परिवर्तनीय किंवा लपविलेल्या व्यवस्थापन साधनामध्ये संग्रहित केले जाते, कमीतकमी विशेषाधिकारांसह दिले जाते आणि नियमितपणे फिरवले जाते.

15. गोपनीयतेच्या दृष्टीने ऑटोमेशन टूल (n8n, Zapier, Make) सह LLM एकत्रीकरणासाठी सर्वोत्तम दृष्टीकोन कोणता आहे?

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

वर्णन: ऑटोमेशनमध्ये प्रवेश करणारा डेटा तृतीय-पक्ष प्रणाली आणि मॉडेलमधून जातो म्हणून, संवेदनशील/वैयक्तिक डेटा कमी करणे, मुखवटा घातलेला आणि फक्त आवश्यक फील्ड पाठवणे आवश्यक आहे; API की देखील टूलमध्ये गुप्त क्रेडेन्शियल्स म्हणून संग्रहित केली जाते.

16. LLM आधारित उत्पादन वैशिष्ट्यामध्ये आउटपुटचे प्रमाणीकरण अनिवार्य का आहे?

अ) केवळ स्वरूपन आवश्यक आहे कारण मॉडेल कधीही चुका करत नाही
ब) कारण मॉडेल द्रवपदार्थ तयार करू शकते परंतु कधीकधी चुकीच्या पद्धतीने; स्कीमा/नियम यांचे संसाधन आणि मानवी संमतीने ऑडिट करणे आवश्यक आहे ✔
क) प्रमाणीकरण टाळावे कारण ते केवळ खर्च वाढवते
ड) पडताळणी फक्त टोकनची संख्या कमी करण्यासाठी आहे

वर्णन: एलएलएम अस्खलित परंतु काहीवेळा चुकीचे (विभ्रम) आउटपुट देऊ शकतात; त्यामुळे तो उच्च प्रभाव निर्णय बाहेर आला; त्याचे स्कीमा/नियम तपासणे, स्रोत प्रमाणीकरण आणि आवश्यक असेल तेव्हा मानवी मान्यता याद्वारे ऑडिट केले जावे.