लाभ:
- अन्त-देखि-अन्त वास्तुकला डिजाइन गर्न सक्छ जुन विचार देखि उत्पादन सम्म LLM सुविधा लिन्छ
- प्रमाणीकरण प्रवर्तन, मानव अनुमोदन, र ट्र्याकिङ (लगिङ/मेट्रिक्स) को तहहरू स्थापना गर्दछ।
- सीमाहरू उत्पादन निर्णयहरूमा नैतिकता र गोपनीयता सिद्धान्तहरू अनुवाद गर्छन्
अघिल्लो दस एकाइहरूमा, हामीले भागहरू एक-एक गरेर सिक्यौं: अनुरोध संरचना, टोकन अर्थशास्त्र, प्रवाह, प्रणाली प्रम्प्ट, मोडेल चयन, क्यास, ब्याच, त्रुटि व्यवस्थापन, सुरक्षित कुञ्जी र स्वचालन। यो अन्तिम एकाईमा, हामी भागहरू संयोजन गर्छौं र समग्र वास्तुकला स्थापना गर्छौं जसले विचारदेखि उत्पादनसम्म LLM सुविधा बोक्छ। उत्पादन "कार्यकारी डेमो" भन्दा फरक छ: प्रमाणीकरण अनिवार्य छ, आउटपुट अनुगमन गरिनु पर्छ, सीमा र नैतिक सिद्धान्तहरू निर्णयहरूमा सम्मिलित हुनुपर्छ। यो एकाइ मोड्युलको वाहक स्तम्भ हो; पहिलेका सबै यहाँ एकसाथ आउँछन्।
उत्पादन वास्तुकला को तहहरू
एक ठोस LLM योग्यतामा लगभग पाँच तहहरू हुन्छन्:
- इनपुट तह: डाटा सङ्कलन गर्नुहोस्, यसलाई सफा गर्नुहोस्, संवेदनशील क्षेत्रहरू मास्क गर्नुहोस्, आवश्यक मात्र प्रसारण गर्नुहोस्।
- मोडेल तह: सही मोडेल चयन गर्नुहोस् (एकाइ 5), प्रणाली प्रम्प्ट र प्यारामिटरहरू (एकाइ 4), क्यास (एकाइ 6) सेट गर्नुहोस्।
- प्रमाणीकरण तह: स्किमा/नियम, स्रोत, र आवश्यक भएमा मानव अनुमोदन विरुद्ध आउटपुट जाँच गर्नुहोस्।
- कार्य तह: मान्य आउटपुट संग कार्य प्रदर्शन; उच्च प्रभाव कार्यहरू क्याप्चर गर्नुहोस्।
- अनुगमन तह: रेकर्ड गर्नुहोस् र प्रत्येक कल, लागत, त्रुटि र गुणस्तर मापन गर्नुहोस्।
यी तहहरू पाइपलाइन हुन्; प्रत्येकले अघिल्लोको आउटपुट जाँच गर्दछ।
प्रमाणीकरण किन आवश्यक छ?
LLM ले धाराप्रवाह तर कहिलेकाहीँ गलत आउटपुट उत्पादन गर्न सक्छ। यसलाई भ्रम भनिन्छ: मोडेलले जानकारी बनाउन सक्छ जुन सत्य देखिन्छ तर होइन। एक च्याट खेल मा यो सहन योग्य छ; उत्पादन प्रणाली (बीज, स्वास्थ्य, कानूनी, वित्त) मा सहन सकिँदैन। त्यसोभए यो बाहिरियो, अन्धाधुन्ध रूपमा अविश्वसनीय; पुष्टि हुन्छ।
प्रमाणीकरण तहहरू (प्रभाव द्वारा बढ्दै):
- ढाँचा/स्कीमा प्रमाणीकरण: के आउटपुट अपेक्षित JSON स्कीमा अनुरूप छ? (संरचित आउटपुटले ठूलो मात्रामा यसको ग्यारेन्टी गर्दछ।)
- नियम/तर्क प्रमाणिकरण: के मानहरू व्यावहारिक छन्? (के रकम ऋणात्मक छ, भविष्यमा मिति छ, वर्ग मान्य छ?)
- स्रोत प्रमाणिकरण: के दावी प्रदान गरिएको कागजातमा आधारित छ? के मोडेलले कागजातमा नभएको कुरा भन्छ?
- मानव अनुमोदन: एक विशेषज्ञले उच्च प्रभाव वा अस्पष्ट निर्णयहरूको समीक्षा गर्दछ।
सावधानी: "मोडल धेरै राम्रो छ, कुनै थप प्रमाणीकरण आवश्यक छैन" सबैभन्दा खतरनाक उत्पादन भ्रम हो। मोडेल जतिसुकै राम्रो किन नहोस्, प्रमाणीकरण तह उच्च प्रभाव पार्ने निर्णयहरूमा सुरक्षा जाल हो। एक गलत स्वचालित निर्णयले पनि बचत गरिएको सबै समय लिन सक्छ।
मानव-इन-द-लूप
हरेक निर्णय पूर्ण रूपमा स्वचालित हुनुपर्छ भन्ने छैन। मानव-इन-द-लूप दृष्टिकोणमा, मोडेलले कामलाई गति दिन्छ र मानवले यसलाई अनुमोदन गर्दछ। सही सन्तुलन निर्णयको प्रभाव र त्यो कार्यमा मोडेलको विश्वसनीयतामा निर्भर गर्दछ।
निर्णयको प्रभाव
दृष्टिकोण
कम (लेबल सुझाव, मस्यौदा)
पूर्ण स्वचालन; त्रुटि सस्तो र उल्टाउन मिल्छ
मध्यम (मार्ग, प्राथमिकता)
स्वचालन + नमूना नियन्त्रण
उच्च (पैसा, अनुबंध, स्वास्थ्य, मेटाउने)
मानव सहमति अनिवार्य छ; मोडेलले मात्र सुझाव दिन्छ
अनुगमन: तपाईंले नदेखेको कुरा व्यवस्थापन गर्न सक्नुहुन्न
उत्पादन मा, तपाईंले प्रत्येक कल निगरानी गर्नुपर्छ। अनुगमन बिना, तपाईं लागत, गुणस्तर सुधार गर्न सक्नुहुन्न, वा समस्या छिट्टै समात्न सक्नुहुन्न। रेकर्ड गर्न प्रमुख मेट्रिक्स:
- उपयोग/लागत: प्रति अनुरोध र कुल टोकन, मोडेल वितरण, दैनिक खर्च।
- विलम्बता: औसत र सबैभन्दा खराब-केस प्रतिक्रिया समय।
- त्रुटि दर: 429/500 दरहरू, पुन: प्रयासहरू, परित्यागहरू।
- गुणस्तर: प्रमाणीकरण तहमा अस्वीकृत आउटपुट दर, मानव अनुमोदनमा सुधार दर, प्रयोगकर्ता प्रतिक्रिया।
सुझाव: अनुगमन लगहरूमा संवेदनशील डाटा (व्यक्तिगत जानकारी, कुञ्जीहरू) नलेख्नुहोस्। गोपनीयताको दायरा भित्र लगहरू विचार गर्नुहोस्; आवश्यक भएमा मास्क गरेर रेकर्ड गर्नुहोस् (एकाइ 9)।
नैतिकता र सीमाहरू
नैतिक जिम्मेवारी प्राविधिक शुद्धता जत्तिकै उत्पादन निर्णयको एक भाग हो:
- पारदर्शिता: प्रयोगकर्तालाई थाहा हुनुपर्छ कि तिनीहरू कृत्रिम बुद्धिमत्ता वा मानवसँग कुरा गर्दैछन्।
- निष्पक्षता र पूर्वाग्रह: मोडेलले प्रशिक्षित डेटाबाट पूर्वाग्रह लिन सक्छ; उच्च प्रभावकारी निर्णयहरू (भर्ती, क्रेडिट) मा भेदभावपूर्ण परिणामहरू निगरानी गर्नुहोस्।
- दायित्व: यदि स्वचालित निर्णयले हानि पुर्याउँछ भने, तपाईं जिम्मेवार हुनुहुन्छ; "मोडलले त्यसो भन्यो" प्रतिरक्षा होइन।
- सीमाहरूको स्वीकृति: मोडेलले केही कार्यहरू विश्वसनीय रूपमा गर्न सक्दैन; तिनीहरूलाई स्वचालित नगर्नु पनि एक डिजाइन निर्णय हो।
प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू
# प्रमाणीकरण चेकलिस्ट (आउटपुट जेनरेशन पछि) 1) के स्कीमा मान्य छ? (संरचित आउटपुट प्रमाणीकरण) 2) के मानहरू अर्थ बनाउँछन्? (नियम जाँच: दायरा, मिति, enum) 3) के दावी स्रोतमा आधारित छ? (कागजातमा नभएको खण्डमा अस्वीकार गर्नुहोस्) ४) प्रभाव उच्च छ? → मानव स्वीकृतिको लागि पठाउनुहोस् 5) यदि सबै पारित भए → कार्यलाई अनुमति दिनुहोस्, बचत गर्नुहोस्
# प्रणाली प्रम्प्ट जसले स्रोतमा भर पर्न बाध्य पार्छ, केवल प्रदान गरिएको कागजातमा जानकारीमा निर्भर गर्दछ। कागजातमा नभएको कुनै पनि कुरा थप नगर्नुहोस्। यदि कुनै जानकारी कागजातमा छैन भने, "कागजातमा फेला परेन" लेख्नुहोस्। कहिल्यै अनुमान नगर्नुहोस् वा चीजहरू बनाउनुहोस्।
# मानव अनुमोदन थ्रेसहोल्ड (निर्णय नियम) IF [पैसा, सम्झौता, मेटाउनुहोस्, स्वास्थ्य] मा निर्णय_प्रकार
# ट्रेस लग टेम्प्लेट (संवेदनशील डेटा लेख्दै) { "समय":"...", "मोडल":"...", "इनपुट_टोकन":..., "आउटपुट_टोकन":..., "ढिलाइ_एमएस":..., "रोक्नुहोस्_कारण":"...", "प्रमाणीकरण":"पास गरिएको | अस्वीकार गरिएको | मानव" // NE_कुञ्जी लेखिएको छ।
कमजोर प्रम्प्ट / बलियो प्रम्प्ट (उत्पादन विश्वसनीयता)
# कमजोर (कुनै प्रमाणीकरण छैन, कुनै स्रोत छैन, स्वचालित रूपमा लागू हुन्छ) यो अनुरोध मूल्याङ्कन गर्नुहोस्, फिर्ता निर्णय गर्नुहोस् र लागू गर्नुहोस्।
# स्ट्रङ्ग (स्रोतमा आधारित, सिफारिस उत्पन्न गर्दछ, मानव अनुमोदनमा छोड्छ) फिर्ता नीति कागजातमा आधारित यो फिर्ता अनुरोधको मूल्याङ्कन गर्नुहोस्। औचित्य सहित निर्णय सिफारिस गर्नुहोस् तर कार्यान्वयन नगर्नुहोस्: {"recommendation":"अनुमोदन| अस्वीकार","कारण":"...","policy_clause":"..."}।नीति कागजातमा कुनै स्पष्ट आधार छैन भने, "अस्पष्ट" दिनुहोस्। एक प्रतिनिधिले अन्तिम निर्णय अनुमोदन गर्नेछ।
शक्तिशाली संस्करण; यसले स्रोतलाई निर्णयको श्रेय दिन्छ, मोडेललाई "कर्त्ता" को सट्टा "सुझावकर्ता" को रूपमा राख्छ र मानव अनुमोदन पछि उच्च प्रभावकारी कदम राख्छ। यो उत्पादन विश्वसनीयता को सार हो।
तीन मिनी केसहरू
केस १ — प्रमाणीकरण तह सुरक्षित भएको दिन। एक fintech ले मोडेल वर्गीकृत लेनदेन विवरण र स्वचालित लेखा रेकर्ड सिर्जना गरिरहेको थियो। तिनीहरूले नियम प्रमाणीकरण थपे: एकपटक मोडेलले रकम गलत रूपमा आउटपुट गरे (कागजातमा 1,250 को सट्टा 12,500), "रकम कागजातसँग मेल खाँदैन" नियमले आउटपुटलाई अस्वीकार गर्यो र रेकर्ड मानवमा खस्यो। यदि त्यहाँ कुनै प्रमाणीकरण थिएन भने, गलत रेकर्ड चुपचाप प्रणालीमा प्रवेश गर्नेछ।
केस 2 - फरार व्यक्ति निगरानी द्वारा पक्राउ। SaaS टोलीले अनुगमन प्यानल बनाएको थियो; एक बिहान दैनिक लागत तीन गुणा बढ्यो। यो लगहरूबाट देखियो कि ग्राहकले लुपमा प्रवेश गर्यो र हजारौं पटक उही अनुरोध पठाएको थियो। तिनीहरूले कोटा र डुप्लिकेशन थपे; घण्टामै समस्या समाधान भयो । ट्र्याकिङ बिना, बिल महिनाको अन्त्यमा एक आश्चर्य हुनेछ।
केस 3 - सीमा स्वीकार गर्दै। एक स्वास्थ्य सेवा स्टार्टअपले स्वचालित रूपमा निदान सिफारिस गर्ने र बिरामीलाई देखाउने योजना बनाइरहेको थियो। नैतिकता र दायित्व समीक्षामा, तिनीहरूले निर्णय गरे कि यो अफ-सीमा थियो: मोडेलले केवल एक चिकित्सकलाई सारांश र सम्भावित बिन्दुहरू प्रदान गर्दछ, चिकित्सकले निदान गर्दछ। कामलाई स्वचालित नगर्नु पनि परिपक्व डिजाइन निर्णय हो।
सामान्य गल्तीहरू
- प्रमाणीकरण छाड्दै: "मोडल राम्रो छ" भन्दै अन्धाधुन्ध रूपमा आउटपुट लागू गर्दै।
- स्वचालित उच्च प्रभाव निर्णय: मानव अनुमोदन पैसा / स्वास्थ्य / कानून मा आवश्यक छ।
- अनुगमन छैन: लागत र गुणस्तर समस्याहरू ढिलो पत्ता लगाइन्छ।
- लगहरूमा संवेदनशील डेटा लेख्दै: गोपनीयता उल्लङ्घन; यसलाई मास्क गरेर बचत गर्नुहोस्।
- स्रोतमा भर पर्न खोजिरहेको छैन: मोडेलले कागजातमा नभएको कुरा बनाउन सक्छ।
- सीमाहरू बेवास्ता गर्दै: केही कार्यहरू स्वचालित नगर्नु सही निर्णय हो; पारदर्शिता र जिम्मेवारी तपाईको हो।
गहिरो: रिलीज व्यवस्थापन, रोलब्याक, र वृद्धिशील तैनाती
उत्पादनमा LLM सुविधा लिनु भनेको यसलाई सेटअप गर्ने र बिर्सनुको बारेमा होइन; समयसँगै प्रत्यक्ष प्रणालीलाई सुरक्षित रूपमा परिमार्जन गर्नु हो। यसमा तीनवटा स्तम्भ छन्।
संस्करण। तपाईंको प्रणाली प्रम्प्ट, मोडेल चयन, र प्रमाणीकरण नियमहरू समयसँगै परिवर्तन हुन्छन्। संस्करण प्रत्येक महत्त्वपूर्ण परिवर्तन र रेकर्ड गर्नुहोस् कुन संस्करण लाइभ छ। यदि एक दिन गुणस्तर घट्यो भने, "हामी के परिवर्तन भयो?" तपाईंले मिनेट भित्र प्रश्नको जवाफ दिन सक्षम हुनुपर्छ। संस्करणविहीन प्रणालीमा, प्रतिगमनको मूल कारण पत्ता लगाउन दिन लाग्छ।
रोलब्याक। यदि कुनै नयाँ प्रम्प्ट वा मोडेलले लाइभमा अपेक्षा गरेभन्दा खराब व्यवहार गर्छ भने, तपाइँ छिटो अघिल्लो, प्रसिद्ध संस्करणमा फर्कन सक्षम हुनुपर्दछ। रोलब्याक योजना बिनाको परिवर्तनले प्रत्यक्ष जोखिमलाई अन्धाधुन्ध स्वीकार गर्नु हो। "मैले केहि परिवर्तन गरें, यो खराब भयो, म फर्किन सक्दिन" सबैभन्दा महँगो उत्पादन परिदृश्य हो।
क्रमिक रोलआउट। एकैचोटि सबै ट्राफिकमा परिवर्तन लागू गर्नुको सट्टा, तपाईंले यसलाई सानो प्रतिशत (जस्तै 5%) मा रोल आउट गर्नुहोस् र मेट्रिक्स (गुणवत्ता, लागत, त्रुटिहरू) को निगरानी गर्नुहोस्। यदि यो राम्रो छ भने, तपाइँ प्रतिशत बढाउनुहुन्छ; यदि यो नराम्रो छ भने, तपाईंले यसलाई प्रभावित सानो खण्डमा मात्र फिर्ता पाउनुहुनेछ। यसले जोखिमलाई धेरै सीमित गर्दछ।
यी तीन अभ्यासहरूले सबै अघिल्लो एकाइहरूबाट प्रविधिहरू संयोजन गर्दछ: eval (एकाइ 5) मापनहरू अग्रिम रूपमा परिवर्तन, निगरानी (यो एकाइ) प्रसारको समयमा प्रारम्भिक चेतावनी दिन्छ, प्रमाणिकरण तहले कार्ययोग्य हुनु अघि त्रुटिपूर्ण आउटपुटहरू समात्छ। उत्पादन एकल सही सेटअप होइन; यो एक निरन्तर अनुशासन हो जसले मापन, निगरानी र आत्मविश्वासका साथ परिवर्तन गर्न सक्छ। सम्पूर्ण मोड्युल यो अनुशासन स्थापित गर्न को लागी हो।
संक्षेपमा
उत्पादन एक काम गर्ने डेमो भन्दा बढि छ: यो इनपुट, मोडेल, प्रमाणिकरण, कार्य र अनुगमन तहहरूको पाइपलाइन हो। प्रमाणीकरण बिना आउटपुट अविश्वसनीय छ; उच्च प्रभावकारी निर्णयहरू मानव अनुमोदनसँग सम्बन्धित छन्; प्रत्येक कल लागत, त्रुटि र गुणस्तरको लागि निगरानी गरिन्छ। नैतिकता, पारदर्शिता, पूर्वाग्रह नियन्त्रण, जवाफदेहिता र सीमाहरूको स्वीकृति प्राविधिक निर्णयहरूको अभिन्न अंग हो। यस मोड्युलमा सिकेका हरेक टुक्राहरू यस समग्र डिजाइनमा सँगै आउँछन्।
आवेदन कार्य
एउटा LLM सुविधा अन्त-देखि-अन्त डिजाइन गर्नुहोस्। (१) तपाईको विशेष कार्यको लागि पाँच तहहरू (इनपुट, मोडेल, प्रमाणीकरण, कार्य, अनुगमन) भर्नुहोस्। (२) कुन निर्णयहरूलाई मानवीय स्वीकृति चाहिन्छ प्रभावद्वारा चिन्ह लगाउनुहोस्। (3) कम्तिमा तीन प्रमाणीकरण जाँचहरू (स्कीमा, नियम, स्रोत) लेख्नुहोस्। (४) तपाईंले ट्र्याक गर्नुहुने कुञ्जी मेट्रिकहरू र तपाईंले लग नगर्ने कुराहरू निर्धारण गर्नुहोस्। (५) तपाईंले यो सुविधामा स्वीकार गर्नुभएको सीमा र नैतिक सिद्धान्त लेख्नुहोस्।
चेकलिस्ट
- [] म उत्पादन पाइपलाइनको पाँच तह डिजाइन गर्न सक्छु।
- [] म स्कीमा, नियम र स्रोत विरुद्ध आउटपुट मान्य गर्न सक्छु।
- [ ] म निर्णयको प्रभावको आधारमा मानवीय स्वीकृति थ्रेसहोल्ड सेट गर्न सक्छु।
- [] म लागत, त्रुटि र गुणस्तर अनुगमन गर्छु र लगहरूमा संवेदनशील डाटा नलेख्ने अभ्यास गर्छु।
- म नैतिकता, जिम्मेवारी र सीमाहरूलाई उत्पादन निर्णयहरूमा रूपान्तरण गर्न सक्छु।
मोड्युल परीक्षा
1. LLM च्याट API मा 'प्रणाली' भूमिकाले के गर्छ?
- A) मोडेललाई स्थायी निर्देशन र व्यवहारका नियमहरू दिन्छ जुन सम्पूर्ण कुराकानीमा लागू हुन्छ ✔
- ख) प्रयोगकर्ताले लेखेको अन्तिम प्रश्न राख्छ
- C) मोडेल द्वारा उत्पादित प्रतिक्रिया भण्डारण गर्दछ
- D) API कुञ्जी इन्क्रिप्ट गर्दछ
विवरण: प्रणाली भूमिकाले मोडेललाई निरन्तर निर्देशनहरू, व्यक्तित्व, र नियमहरू दिन्छ जुन सम्पूर्ण कुराकानीमा लागू हुन्छ; यो एक उच्च-स्तर रिडिरेक्ट हो, प्रयोगकर्ता सन्देशहरूबाट अलग।
2. किन कुराकानी इतिहास (अघिल्लो सन्देशहरू) प्रत्येक पटक एपीआई अनुरोधमा फेरि पठाइन्छ?
- क) सर्भरले ईतिहास मेटाउँदा ब्याकअप गर्न आवश्यक छ
- B) API कलहरू राज्यविहीन छन्; ✔ प्रत्येक अनुरोधमा सन्दर्भ पुन: पठाइन्छ किनभने मोडेलले इतिहास सम्झँदैन
- C) बीजकको लागि मात्र आवश्यक, मोडेलमा कुनै प्रभाव छैन
- घ) प्रतिक्रिया सुस्त हुनबाट जोगिन इतिहास पठाउनु अनिवार्य छ
स्पष्टीकरण: LLM API कलहरू राज्यविहीन छन्; मोडेलले अघिल्लो राउन्डहरू याद गर्दैन, त्यसैले सन्दर्भ सुरक्षित गर्नका लागि प्रत्येक अनुरोधमा सबै सान्दर्भिक इतिहास पुन: पठाइन्छ।
LLM मूल्य निर्धारणमा 'टोकन' के हो?
- ए) API मा लग इन गर्न एक पटकको पासवर्ड प्रयोग गरियो
- ख) प्रत्येक अनुरोधमा एक निश्चित शुल्क भुक्तान गरियो
- C) सबैभन्दा सानो एकाइ जसमा मोडेलले पाठलाई प्रशोधन गर्छ; सामान्यतया शब्द भाग संग मेल खान्छ ✔
- D) उत्पादनको लम्बाइ मात्र मापन गर्ने एकाइ
विवरण: टोकन सबैभन्दा सानो एकाइ हो जसमा मोडेलले पाठ प्रशोधन गर्छ; यो सामान्यतया शब्दको टुक्रासँग मेल खान्छ, र टोकनहरूको संख्यामा आधारित इनपुट र आउटपुट दुवै चार्ज गरिन्छ।
4. किन धेरै LLM प्रदायकहरूमा इनपुट टोकनहरू भन्दा आउटपुट टोकनहरू महँगो छन्?
- A) आउटपुट टोकनहरू सधैं इनपुट भन्दा लामो हुन्छन्
- B) इनपुट टोकनहरू निःशुल्क छन्
- C) आउटपुट टोकनहरू इन्टरनेटमा दुई पटक पठाइन्छ
- D) एकाइ लागत उच्च छ किनभने उत्पादन उत्पादन प्रत्येक टोकन को लागि अतिरिक्त गणना आवश्यक छ ✔
विवरण: प्रत्येक आउटपुट टोकनहरूलाई चरण-दर-चरण उत्पादन (गणना) गर्न मोडेल आवश्यक छ; यो उत्पादन लागत एकैचोटि सबै इनपुट प्रशोधन भन्दा बढी छ, त्यसैले उत्पादन एकाइ मूल्य सामान्यतया उच्च छ।
5. कुन अवस्थामा स्ट्रिमिङ प्रयोग गर्नु सबैभन्दा लाभदायक छ?
- क) लामो उत्तरहरूमा; कथित ढिलाइ कम गर्दछ र टाइमआउट रोक्छ ✔
- ख) केवल धेरै छोटो, एक शब्दमा जवाफ
- ग) लागत शून्यमा घटाउन
- D) API कुञ्जी लुकाउन
विवरण: लामो प्रतिक्रियाहरूमा, स्ट्रिमिङले पहिलो शब्दहरू तुरुन्तै देखा परेर कथित विलम्बता कम गर्छ र ठूला max_tokens मानहरूमा HTTP टाइमआउटहरू रोक्छ।
6. आधुनिक मोडेलहरूमा 'प्रयास' प्यारामिटर बढाउँदा सामान्यतया के असर गर्छ?
- क) उत्तर सधैं छोटो पार्नुहोस्
- B) स्वचालित रूपमा API कुञ्जी घुमाउँछ
- C) यसले इनपुट टोकन मूल्य मात्र घटाउँछ
- D) सोचको गहिराइ र टोकन खर्च बढाउँछ; यसले गुणस्तर सुधार गर्न सक्छ, तर यसले विलम्बता र लागत पनि बढाउँछ ✔
विवरण: प्रयास प्यारामिटरले मोडेलले कार्यको बारेमा कति गहिरो सोच्ने छ र कति टोकनहरू खर्च गर्नेछ समायोजन गर्दछ; स्तरवृद्धिले गुणस्तर सुधार गर्न सक्छ, तर यसले विलम्बता र लागत पनि बढाउँछ। साधारण कार्यहरूको लागि, कम प्रयास पर्याप्त छ।
7. साधारण, उच्च मात्रा वर्गीकरण कार्यको लागि सामान्यतया सबैभन्दा लागत-प्रभावी दृष्टिकोण के हो?
- A) सधैं सबैभन्दा महँगो र सबैभन्दा शक्तिशाली मोडेल प्रयोग गर्नुहोस्
- B) प्रत्येक अनुरोधको लागि एकै समयमा सबै मोडेलहरू कल गर्दै
- ग) हल्का/सस्तो मोडेल छनोट गर्ने जसले कार्यलाई थोरै इभलसँग प्रमाणित गरेर पूरा गर्छ ✔
- D) max_tokens को मान अनावश्यक रूपमा धेरै उच्च राख्नु
स्पष्टीकरण: यदि कार्य जटिल छैन भने, सबैभन्दा महँगो र शक्तिशाली मोडेल प्रयोग गर्नुको सट्टा सजिलैसँग कार्य (जस्तै हाइकु क्लास) पूरा गर्ने छिटो र सस्तो मोडेल छनोट गर्नाले लागतमा उल्लेखनीय कमी आउनेछ।
8. कुन परिदृश्यमा प्रम्प्ट क्यासिङले सबैभन्दा बढी लागत घटाउँछ?
- A) जब धेरै अनुरोधहरूमा ठूलो र निश्चित सन्दर्भ बारम्बार प्रयोग गरिन्छ ✔
- ख) जब प्रत्येक अनुरोधको साथ पूर्ण रूपमा फरक पाठ पठाइन्छ
- ग) जब एक मात्र अनुरोध गरिन्छ
- D) आउटपुट टोकनहरू कम गर्न
विवरण: क्यासिङ एक उपसर्ग मिलान हो; ठूला, अपरिवर्तनीय सन्दर्भ (प्रणाली प्रम्प्ट, कागजातहरू) धेरै अनुरोधहरूमा पुन: प्रयोग भएको अवस्थामा, क्यासबाट पढ्नु पूर्ण मूल्यको सानो अंश (~ ०.१x) हो।
9. मैले प्रम्प्टलाई कसरी सम्पादन गर्नुपर्छ ताकि प्रम्प्ट क्यास हिट हुन्छ?
- क) सुरुमा चर सामग्री र अन्त्यमा निश्चित सामग्री राख्ने
- B) प्रत्येक अनुरोधको लागि प्रणाली प्रम्प्टमा हालको मिति र समय इम्बेड गर्नुहोस्
- ग) निश्चित सामग्री (प्रणाली प्रम्प्ट, कागजातहरू) सुरुमा र चर सामग्री अन्तमा राख्ने ✔
- D) प्रत्येक अनुरोध संग उपकरण सूची को क्रम परिवर्तन
स्पष्टीकरण: क्यास उपसर्ग मिल्ने भएकोले, निश्चित/अपरिवर्तनीय सामग्री (प्रणाली प्रम्प्ट, कागजातहरू) प्रारम्भ गरिएको छ; चर सामग्री (मिति, प्रयोगकर्ता प्रश्न, अनुरोध ID) अन्त्यमा राखिएको छ। सुरुमा परिवर्तन भएको एक बाइटले पनि क्यासलाई अमान्य बनाउनेछ।
10. कुन प्रकारको कार्यभारको लागि ब्याच प्रशोधन सबैभन्दा उपयुक्त छ?
- A) लाइभ च्याट जहाँ प्रयोगकर्ताले स्क्रिनमा तत्काल प्रतिक्रियाको अपेक्षा गर्दछ
- ख) केवल एउटा छोटो प्रश्न
- C) API कुञ्जी उत्पन्न गर्दै
- D) ढिलाइ सहन सक्ने, ठूलो मात्रा र तत्काल नतिजा आवश्यक नहुने कामहरू ✔
विवरण: ब्याच प्रशोधन कार्यहरूको ठूलो मात्राको लागि उपयुक्त छ जसलाई तत्काल प्रतिक्रियाको आवश्यकता पर्दैन र ढिलाइ सहनशील हुन्छ; परिणामहरू केही समय पछि डेलिभर हुन्छन्, तर एकाइ लागत सामान्यतया कम छ।
11. एक ब्याचमा कुन नतिजाको अनुरोधलाई विश्वस्तताका साथ मिलाउन के प्रयोग गरिन्छ?
- क) अनुरोधहरूको आदेश (स्थिति) पठाउँदै
- ख) उत्तरहरूको लम्बाइ
- C) API कुञ्जीको अन्तिम ४ अंकहरू
- D) प्रत्येक अनुरोधमा दिइएको एउटा अद्वितीय custom_id ✔
टिप्पणी: बल्क नतिजाहरू सबमिशन अर्डर भन्दा फरक क्रममा फर्काउन सकिन्छ; त्यसैले प्रत्येक अनुरोधमा दिइएको एक अद्वितीय custom_id संग ID द्वारा नतिजाहरू मिलाउन आवश्यक छ, स्थान होइन।
12. तपाईंले API बाट 429 (दर सीमा) त्रुटि प्राप्त गर्दा सिफारिस गरिएको व्यवहार के हो?
- क) एकै समयमा धेरै अनुरोधहरू पठाएर जबरजस्ती
- B) घातीय ब्याकअफको साथ पुन: प्रयास गर्दै, हेडिङ पछि पुन: प्रयास गर्नुहोस् ✔
- C) अनुरोधलाई पूर्ण रूपमा रद्द गर्नुहोस् र प्रयोगकर्तालाई क्र्यासको रूपमा त्रुटि देखाउनुहोस्
- D) API कुञ्जी परिवर्तन गर्दै
स्पष्टीकरण: 429 पुन: प्रयास गर्न मिल्ने त्रुटि हो; सही दृष्टिकोण भनेको पुन: प्रयास पछि हेडरलाई सम्मान गर्दै घातांकीय ब्याकअफको साथ पुन: प्रयास गर्नु हो। धेरैजसो आधिकारिक SDK ले यो स्वतः गर्छ।
13. निम्न मध्ये कुन HTTP त्रुटि कोडहरू सामान्यतया पुन: प्रयासयोग्य मानिन्छ?
- A) 400 (अमान्य अनुरोध)
- B) 401 (प्रमाणीकरण त्रुटि)
- C) 529 (सर्भर ओभरलोड गरिएको) ✔
- D) 404 (फेला परेन)
स्पष्टीकरण: ४२९ (गति सीमा), ५०० (सर्भर त्रुटि) र ५२९ (ओभरलोड) अस्थायी त्रुटिहरू हुन् र ब्याक अफ गरेर पुन: प्रयास गर्न सकिन्छ। 400 र 401 जस्ता त्रुटिहरू अनुरोध/पहिचान मुद्दाहरू हुन्; फेरि प्रयास गर्दा समाधान हुँदैन।
14. API कुञ्जीहरू व्यवस्थापन गर्न निम्न मध्ये कुन सुरक्षित तरिका हो?
- क) वातावरणीय चर/लुकेका प्रबन्धकमा भण्डारण गर्दै, कोडमा इम्बेड नगर्ने र नियमित रूपमा घुमाउने ✔
- ख) कुञ्जी सिधै स्रोत कोडमा लेख्नुहोस् र भण्डारमा पठाउनुहोस्
- C) क्लाइन्ट साइड (ब्राउजर) जाभास्क्रिप्टमा कुञ्जी राख्दै
- D) इमेल मार्फत सम्पूर्ण टोलीसँग एकल कुञ्जी साझेदारी गर्दै
विवरण: कुञ्जीहरू स्रोत कोड वा भण्डारमा कहिल्यै लेखिएका छैनन्; यसलाई वातावरणीय चर वा लुकेको व्यवस्थापन उपकरणमा भण्डारण गरिन्छ, न्यूनतम विशेषाधिकारहरू प्रदान गरिन्छ, र नियमित रूपमा घुमाइन्छ।
15. गोपनीयताको सन्दर्भमा स्वचालन उपकरण (n8n, Zapier, Make) सँग LLM एकीकरणको लागि उत्तम दृष्टिकोण के हो?
- A) मोडेलमा सबै कच्चा डाटा पठाउँदै, यो आवश्यक नभए पनि
- ख) प्रवाह चरण भित्र सादा पाठमा API कुञ्जी लेख्दै
- C) संवेदनशील डाटालाई न्यूनतम र मास्किङ गर्ने र गोप्य प्रमाणहरूको रूपमा कुञ्जी भण्डारण गर्ने ✔
- D) प्रवाह इतिहासमा स्थायी रूपमा व्यक्तिगत डेटा राख्ने
विवरण: डेटा प्रविष्ट गर्ने स्वचालन तेस्रो-पक्ष प्रणालीहरू र मोडेलहरू मार्फत जान्छ, संवेदनशील/व्यक्तिगत डेटालाई न्यूनतम, मास्क र केवल आवश्यक क्षेत्रहरू पठाउन आवश्यक छ; API कुञ्जी पनि उपकरण भित्र गोप्य प्रमाणहरूको रूपमा भण्डारण गरिएको छ।
16. LLM आधारित उत्पादन सुविधामा आउटपुटको प्रमाणीकरण किन अनिवार्य छ?
- A) केवल ढाँचा आवश्यक छ किनभने मोडेलले कहिल्यै गल्ती गर्दैन
- B) किनभने मोडेलले तरल रूपमा तर कहिलेकाहीँ गलत रूपमा उत्पादन गर्न सक्छ; योजना/नियम स्रोत र मानव स्वीकृति संग लेखा परीक्षा हुनुपर्छ ✔
- ग) प्रमाणीकरणबाट बच्नु पर्छ किनभने यसले लागत मात्र बढाउँछ
- D) प्रमाणीकरण टोकनहरूको संख्या घटाउन मात्र हो
विवरण: LLMs ले धाराप्रवाह तर कहिलेकाहीँ गलत (आभासपूर्ण) आउटपुट उत्पादन गर्न सक्छ; त्यसैले यो उच्च प्रभाव निर्णय मा बाहिर आयो; यो स्किमा/नियम जाँच, स्रोत प्रमाणीकरण, र आवश्यक हुँदा मानव अनुमोदन द्वारा लेखा परीक्षा हुनुपर्छ।