पुन: उत्पादनशीलता र अन्त-देखि-अन्त परियोजना: सबै कुरा संयोजन

लाभ:

• चार स्तम्भहरू (बीउ फिक्सेसन, डाटा संस्करण, मिडिया फ्रिजिङ, प्रयोग अनुगमन) संग प्रजनन योग्यता सुनिश्चित गर्ने क्षमता र एउटै रन दोहोर्याउँदा समान परिणाम उत्पादन
• मोड्युलका सबै स्टपहरू (मेट्रिक्स, डाटा, मोडेल, LLM कम्पोनेन्टहरू, eval, निष्पक्षता, सुरक्षा, वितरण, अनुगमन) अन्त्य-देखि-अन्त श्रृंखलामा संयोजन गर्ने क्षमता।
• प्रत्येक स्टपमा महत्वपूर्ण निर्णय मानवसँग रहन्छ भनेर प्रमाणित गर्ने क्षमता र परियोजनालाई लेखापरीक्षण योग्य तरिकामा दस्तावेज गर्ने क्षमता

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

किन प्रजनन गर्न गाह्रो छ

साधारण सफ्टवेयरमा, एउटै कोडले उही आउटपुट दिन्छ। ML मा त्यहाँ धेरै चरहरू छन् जसले परिणाम निर्धारण गर्दछ:

• अनियमितता: डाटा फेरबदल, वजन प्रारम्भिकरण, डाटा विभाजन - सबै अनियमितता मा निर्भर गर्दछ।
• डाटा: एउटै कोड फरक डाटा संस्करण संग फरक मोडेल उत्पादन गर्दछ।
• वातावरण: पुस्तकालय संस्करणहरू, हार्डवेयर (CPU/GPU), अपरेटिङ सिस्टमले पनि परिणाम परिवर्तन गर्न सक्छ।
• लुकेको केस: एक सुरक्षित नगरिएको हाइपरपेरामिटर, एक म्यानुअल प्रिप्रोसेसिङ चरण, एक अपरिचित चयन।

प्रजनन योग्यता "पाउनु राम्रो" होइन तर एक वैज्ञानिक र इन्जिनियरिङ अनिवार्य छ। पुन: उत्पादन गर्न नसकिने परिणाम एक दावी हो जुन प्रमाणित हुन सक्दैन।

प्रजनन क्षमता को चार स्तम्भ

1. अनियमितता ठीक गर्नुहोस्। सबै अनियमित बीजहरू एकै ठाउँमा सेट गर्नुहोस्: डाटा विभाजन, मोडेल प्रारम्भिकरण, डाटा शफलिङ। स्थिर बीउ "उही नतिजा जब तपाइँ उही रन दोहोर्याउनुहोस्" ग्यारेन्टीको आधार हो।

2. डाटा संस्करण। रेकर्ड गर्नुहोस् कुन डाटा संस्करण प्रत्येक प्रयोग संग प्रदर्शन गरिएको थियो (एकाइ 2 मा डाटा संस्करण)। "नवीनतम डाटा" अस्पष्ट छ; "डेटा संस्करण v3, hash abc123" सही छ।

3. माध्यम फ्रिज गर्नुहोस्। सबै निर्भरताहरूलाई तिनीहरूको सटीक संस्करणहरूमा पिन गर्नुहोस् (जस्तै सटीक संस्करणहरू जस्तै numpy==1.26.4 in requirements.txt, वा कन्टेनर छवि)। "नवीनतम संस्करण" ले एक दिन सबै कुरा तोड्नेछ।

4. सबै कुरा ट्र्याक गर्नुहोस् (प्रयोग ट्र्याकिङ)। प्रत्येक प्रयोगको लागि स्वचालित रूपमा बचत गर्नुहोस्: कोड संस्करण (git कमिट), डाटा संस्करण, सबै हाइपरपेरामिटरहरू, मेट्रिक्स र आउटपुट संरचनाहरू। प्रयोग ट्र्याकिङ उपकरणहरू जस्तै MLflow, Weights & Biases ले यो व्यवस्थित रूपमा गर्छ। दर्ता बिना, प्रश्न "कुन सेटिङ उत्तम थियो" अनुत्तरित रहन्छ।

सावधानी: "म पछि सम्झनेछु" सबैभन्दा महँगो भ्रम हो। दुई हप्ता पछि तपाईले कुन बीउ, कुन डाटा, कुन हाइपरपेरामिटर प्रयोग गर्नुभयो याद गर्नुहुने छैन। स्वचालित ट्र्याकिङले मेमोरीमा निर्भरता हटाउँछ।

कमजोर दृष्टिकोण / बलियो दृष्टिकोण

कमजोर: "मैले सबै भन्दा राम्रो मोडेल फेला पारे, यो नोटबुकमा छ, मलाई लाग्छ कि यसको स्कोर 89% थियो।"

सशक्त: "प्रयोग ट्र्याकिङ उपकरणमा #147 चलाउनुहोस्: git कमिट a3f9c, डेटा संस्करण v3 (hash abc123), बीज 42, सबै हाइपरप्यामिटरहरू दर्ता, परीक्षण PR-AUC 0.887। जब मैले फेरि उही आदेश चलाउँछु, मैले बिस्तारै उही नतिजा पाउँछु। मोडेल रजिस्ट्रीमा यो रनमा निर्भर गर्दछ।"

भिन्नता: बलियो दृष्टिकोणमा नतिजा मेमोरीमा आधारित छैन, तर निश्चित र निगरानी गरिएको श्रृंखलामा। सबैले हरेक पटक समान परिणाम दिन सक्छन्।

अन्त-देखि-अन्त परियोजना: मोड्युलको संयोजन

अब सम्पूर्ण मोड्युललाई एकल परियोजना प्रवाहमा जोडौं। एक वास्तविक ML प्रणाली यी स्टपहरू मार्फत जान्छ, र प्रत्येक स्टप अघिल्लो एकमा निर्माण हुन्छ:

1. समस्या परिभाषा: हामी के समाधान गर्दैछौं, सफलता कसरी मापन गर्ने (एकाइ 3: सही मेट्रिक, व्यापार सन्दर्भ)। मेट्रिक र थ्रेसहोल्ड सुरु देखि स्पष्ट छ।
2. डाटा पाइपलाइन: सङ्कलन, प्रमाणीकरण, सफाई, चुहावट-मुक्त विभाजन, संस्करण (एकाइ 2)।
3. मोडेल विकास: प्रशिक्षण, आधारभूत तुलना, क्रस-प्रमाणीकरण, कडा बीज (एकाइ 3 + यो एकाइ)।
4. LLM कम्पोनेन्टहरू (लागू भएमा): RAG (इकाई ४) र/वा एजेन्टहरू (एकाइ ५); आवश्यक भएमा फाइन-ट्यूनिंग (इकाई 6)।
5. मूल्याङ्कन: किनारा र सुरक्षा केसहरू भएको इभल क्लस्टर, LLM प्रणालीहरूमा बहु-तह इभल (इकाई 8)।
6. न्याय र नैतिकता लेखापरीक्षण: उपसमूह विश्लेषण, मोडेल कार्ड, व्याख्या योग्यता (एकाइ 10)।
7. सुरक्षा अडिट: प्रम्प्ट इंजेक्शन, गोपनीयता, आपूर्ति श्रृंखला (एकाइ 9)।
8. वितरण: प्याकेजिङ, क्रमिक वितरण, रोलब्याक, मोडेल रजिस्ट्री (एकाइ 7)।
9. निगरानी: तीन-तह निगरानी, ​​बहाव अलार्म (इकाई 8)।
10. पुन: उत्पादनशीलता: बीउ, डाटा संस्करण, मिडिया र सम्पूर्ण श्रृंखला (यो एकाइ) मा प्रयोग ट्र्याकिङ।

यस प्रवाहमा, AI प्रत्येक स्टपमा एक एक्सेलेटर र ब्लुप्रिन्ट जनरेटर हो; तर मेट्रिक चयन, डाटा निर्णय, निष्पक्षता प्राथमिकता, तैनाती थ्रेसहोल्ड, र रिलीज अनुमोदन - महत्वपूर्ण निर्णयहरू मानवसँग रहन्छन्। यो मोड्युल को सार हो।

कागजात: भविष्यले तपाईंलाई धन्यवाद दिनेछ

राम्रो एमएल परियोजना आफैं कागजात गर्दछ। कम्तिमा, निम्न लेख्नु पर्छ: समस्या र सफलता मापदण्ड, डाटा स्रोत र संस्करण, मोडेल चयन र औचित्य, मूल्याङ्कन परिणाम (उपसमूह सहित), ज्ञात सीमा र जोखिम, तैनाती र पुन: प्राप्ति प्रक्रिया, अनुगमन योजना। यो कागजात व्यक्तिको सबैभन्दा राम्रो मित्र हो (सायद यो तपाईं हुनुहुन्छ) जो छ महिना पछि परियोजनामा ​​​​फर्किन्छ।

तीन मिनी केसहरू

केस १ - हराएको नतिजा। एक इन्जिनियरले उत्कृष्ट मोडेललाई तालिम दिए, तर उसले बीउ ठीक गरेन र डेटा संस्करण बचत गरेन। जब उसले काम छोड्यो, कसैले त्यो नतिजा पुन: उत्पादन गर्न सकेन; मोडेल "ब्ल्याक बक्स लिजेन्ड" बन्यो र अन्ततः स्क्र्याचबाट बनाइएको थियो। हप्ताहरू बर्बाद भयो। पाठ: एक गैर-पुनरुत्पादन परिणाम एक अस्तित्वहीन परिणाम हो।

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

केस ३ - निगरानीको शक्ति। एउटा टोलीले प्रत्येक प्रयोगलाई स्वचालित रूपमा निगरानी गर्यो। तीन महिना पछि, नियामक लेखा परीक्षणको क्रममा, तिनीहरूले प्रश्नको जवाफ दिए "कुन डाटा, कुन सेटिङहरूसँग, कुन समूहमा यसले कस्तो प्रदर्शन प्राप्त गर्यो?" मिनेट भित्र पूर्ण रेकर्डिङ संग। निरीक्षण सहज रूपमा भयो। पाठ: अनुगमन एक अनुपालन उपकरण हो, केवल एक ईन्जिनियरिङ् होइन।

प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू

यस ML परियोजनाको लागि पुन: उत्पादनशीलता जाँच गर्नुहोस्।- के सबै अनियमितता बीजहरू निश्चित छन् (विभाजन, प्रारम्भिक, फेरबदल)?- के डाटा संस्करण गरिएको छ?- के निर्भरताहरू सही संस्करणहरूमा स्थिर छन्?- के प्रत्येक प्रयोग (कोड कमिट, डाटा, हाइपरपेरामिटर, मेट्रिक) ट्र्याक गरिएको छ? प्रत्येक छुटेको स्तम्भको लागि यसलाई कसरी ठीक गर्ने भन्ने बारे ठोस चरणहरू लेख्नुहोस्। परियोजना संरचना: [विवरण]

यो अन्त-देखि-अन्त ML परियोजनाको लागि योजना कंकाल उत्पादन गर्नुहोस्। समस्या: [विवरण] निम्न स्टपहरू कभर गर्नुहोस् र प्रत्येक स्टपमा मानव निर्णय भएको ठाउँमा चिन्ह लगाउनुहोस्: समस्या/मेट्रिक, पाइपलाइन, मोडेल, (RAG/एजेन्ट/फाइन-ट्यून?), इभाल, निष्पक्षता, सुरक्षा, वितरण, अनुगमन, पुन: उत्पादनशीलता। प्रत्येक स्टपको लागि मुख्य जोखिम र प्रमाणीकरण चरण लेख्नुहोस्।

यस परियोजनाको लागि प्राविधिक कागजात टेम्प्लेट उत्पादन गर्नुहोस्। खण्डहरू: समस्या+सफलता मापदण्ड, डाटा (स्रोत+संस्करण), मोडेल छनोट+औचित्य, मूल्याङ्कन (उपसमूहहरू सहित), ज्ञात सीमाहरू+जोखिमहरू, तैनाती+रोलब्याक, निगरानी योजना। प्रश्नको रूपमा प्रत्येक खण्डको लागि भरिने क्षेत्रहरू दिनुहोस्।

मेरो प्रयोग निगरानी सेटअप जाँच गर्नुहोस्: के यो प्रत्येक रनमा स्वत: बचत गरिएको छ: git कमिट, डाटा संस्करण/ह्यास, सबै हाइपरपेरामिटरहरू, सबै मेट्रिक्स, वातावरण (पुस्तकालय संस्करणहरू)? के म उही नतिजा पाउँछु जब म उही रन दोहोर्याउँछु? सेटअप: [विवरण]। त्रुटिहरू सूचीबद्ध गर्नुहोस् र सुधार गर्नुहोस्।

पुन: उत्पादन क्षमता स्तम्भ तालिका

स्तम्भ

के निश्चित छ

वाहन उदाहरण

अनियमितता

सबै बीउ

बीज सेटिङ

डाटा

डाटा संस्करण/ह्यास

DVC

वातावरण

पुस्तकालय संस्करणहरू

आवश्यकता पिन, डकर

अनुगमन

कोड+डेटा+सेटिङ+मेट्रिक

MLflow, W&B

सामान्य गल्तीहरू

• बीउ ठीक गर्दैन। परिणाम दोहोर्याउन सकिँदैन।
• डाटा संस्करण बचत गर्दैन। "के डाटा संग?" अनुत्तरित रहन्छ।
• जमेको लत होइन। अपडेटले चुपचाप सबै कुरा तोड्नेछ।
• प्रयोगहरूलाई मेमोरीमा छोड्दै। दुई साता बितिसक्दा पनि केही याद छैन ।
• महत्वपूर्ण निर्णयहरू कृत्रिम बुद्धिमत्तामा छोड्दै। मेट्रिक्स, न्याय, र वितरण निर्णयहरू जनतामा रहनुपर्छ।
• कागजातहरू स्थगित गर्दै। भविष्यको टोली (र तपाईं) मूल्य तिर्नुहोस्।

संक्षेपमा

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

आवेदन कार्य

चार प्रजननता स्तम्भहरू विरुद्ध ML परियोजना जाँच गर्नुहोस्: के बीउ अपरिवर्तनीय छ, के डाटा संस्करण गरिएको छ, के वातावरण स्थिर छ, के प्रयोगहरू ट्र्याक गरिएको छ? कुनै पनि छुटेको स्तम्भहरू ठीक गर्नुहोस् र प्रमाणित गर्नुहोस् कि तपाइँ एउटै रन दुई पटक चलाउन सक्नुहुन्छ र समान परिणाम प्राप्त गर्नुहोस्। त्यसपछि एक पृष्ठमा परियोजनाको अन्त्य-देखि-अन्त प्रवाह (१० स्टपहरू) आउटपुट गर्नुहोस् र प्रत्येक स्टपमा "मानव निर्णय कहाँ छ" चिन्ह लगाउनुहोस्। अन्तमा, छोटो प्राविधिक दस्तावेज मस्यौदा लेख्नुहोस्।

चेकलिस्ट

• [ ] सबै अनियमितता बीज निश्चित।
• [] डाटा संस्करण/ह्यास प्रत्येक प्रयोगको साथ रेकर्ड गरिएको छ।
• [ ] निर्भरताहरू फर्म संस्करणहरू (पिन / कन्टेनर) मा स्थिर छन्।
• [] प्रत्येक प्रयोग स्वचालित रूपमा अनुगमन गरिन्छ (कोड+डेटा+सेटिङ+मेट्रिक)।
• [ ] जब म उही रन दोहोर्याउँछु, म उही नतिजा पाउँछु।
• [ ] मैले प्रमाणित र दस्तावेजीकरण गरें कि अन्तिम-देखि-अन्त प्रवाहमा महत्वपूर्ण निर्णयहरू मानवहरूद्वारा गरिन्छन्।

मोड्युल परीक्षा

1. एक ML इन्जिनियरको रूपमा, कार्यप्रवाहमा कृत्रिम बुद्धिमत्ताको स्थिति निर्धारण गर्दा उत्तम दृष्टिकोण के हो?

• A) AI कम जोखिम व्यवसायहरूमा एक गतिवर्धक हो; मेट्रिक्स, डाटा, र उत्पादन जस्ता महत्वपूर्ण निर्णयहरू मान्य रहन्छन् र मानवलाई छोडिन्छ ✔
• B) जबसम्म AI आउटपुटहरू राम्रो देखिन्छन्, त्यहाँ प्रमाणीकरणको आवश्यकता पर्दैन
• C) मोडेललाई उत्पादनमा कृत्रिम बुद्धिमत्तामा राख्ने निर्णय छोड्दा समय बचत हुन्छ।
• D) आर्टिफिसियल इन्टेलिजेन्स पाठ लेख्नको लागि मात्र उपयोगी छ, यसको डाटा र मोडेल कार्यसँग कुनै सरोकार छैन

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

2. किन स्कीमा प्रमाणीकरण डाटा पाइपलाइनको सुरुमा राखिएको छ?

• A) किनभने यसले सीधा मोडेलको शुद्धता बढाउँछ
• B) किनभने यसले डाटा संस्करणलाई अनावश्यक बनाउँछ
• C) किनभने यसले भ्रष्ट डाटालाई सबभन्दा चाँडो र सस्तो बिन्दुमा समात्छ र अर्को चरणहरूमा चुहावट हुनबाट रोक्छ ✔
• D) किनभने यसले लेबलिङको आवश्यकतालाई हटाउँछ

स्पष्टीकरण: पहिलेको भ्रष्ट डाटा समातियो, यसलाई ठीक गर्न सस्तो छ। स्कीमा प्रमाणीकरणले लाइनको सुरुमा अपेक्षित प्रकार र दायराभन्दा बाहिरको डाटा अस्वीकार गरेर प्रशिक्षण वा उत्पादनमा मौनतापूर्वक भ्रष्ट डेटा लीक हुनबाट रोक्छ (जस्तै एकाइ परिवर्तनको साथ 100x मूल्य सर्ने); उत्पादनमा समातिएको एउटै त्रुटि धेरै गुणा महँगो छ।

3. समय (समय शृङ्खला) समावेश भएको समस्यामा डेटालाई प्रशिक्षण र परीक्षणमा विभाजन गर्दा सही दृष्टिकोण के हो?

• A) अनियमित विभाजन प्रयोग गर्दै किनभने यो सधैं राम्रो तरिका हो
• ख) टेम्पोरल स्प्लिटिङ् प्रयोग गर्दै: विगतको तालिम र भविष्यमा परीक्षण गरेर चुहावट रोक्न ✔
• C) प्रशिक्षण र परीक्षण दुवै रूपमा सबै डेटा प्रयोग गर्दै
• D) प्रशिक्षण भन्दा पहिले मापन मापदण्डहरूमा परीक्षण डेटा समावेश गर्दै

स्पष्टीकरण: समय श्रृंखलामा अनियमित विभाजनले मोडेललाई 'भविष्य-देख्ने' फाइदा दिन्छ जुन उत्पादनमा कहिल्यै हुनेछैन र कृत्रिम रूपमा मेट्रिक्स (टेम्पोरल लीकेज) फुलाउँछ। सही एक अस्थायी विभाजन हो: अतीत संग ट्रेन, भविष्य मा परीक्षण। यसले वास्तविक कार्यसम्पादनलाई मापन गर्दछ जसले यसलाई उत्पादनमा राख्छ।

4. 1.5% को सकारात्मक वर्ग दर संग धोखाधडी पत्ता लगाउने मोडेलमा किन सटीकता भ्रामक छ?

• A) किनभने असन्तुलित डाटामा शुद्धता सधैं कम हुन्छ
• B) किनभने शुद्धता केवल प्रतिगमन समस्याहरूमा प्रयोग गर्न सकिन्छ
• C) किनभने शुद्धता गणनाको लागि धेरै प्रशोधन शक्ति चाहिन्छ
• D) बहुसंख्यक वर्गको भविष्यवाणी गर्ने एउटा सानो मोडेल पनि धेरै सही हुन सक्छ, यसरी वास्तविक सफलता लुकाउन सक्छ ✔

स्पष्टीकरण: असन्तुलित डाटामा, 'कल एथिंग नेगेटिभ' भन्ने आधारभूत मोडेलले पनि ९८.५% शुद्धता पाउँछ तर एउटा पनि ठगीलाई समात्दैन। तसर्थ, असन्तुलित वर्गीकरणमा, सटीकताको सट्टा परिशुद्धता, सम्झना, F1 वा PR-AUC प्रयोग गरिन्छ, र प्रत्येक मेट्रिकलाई आधार मोडेल अनुसार व्याख्या गरिन्छ।

5. मोडेलको मेट्रिकको बारेमा कुरा गर्दा आधारभूत तुलना किन आवश्यक छ?

• क) आधार मोडेल सधैं वास्तविक मोडेल भन्दा राम्रो छ
• B) किनभने यो स्पष्ट छ कि मेट्रिक अर्थपूर्ण छ वा होइन जब साधारण आधार रेखा मोडेलको तुलनामा ✔
• C) किनभने आधार मोडेलले क्रस-प्रमाणीकरणलाई अनावश्यक बनाउँछ
• D) आधारभूत मोडेल कानुनी रूपमा प्रत्येक रिपोर्टमा आवश्यक भएको कारण

स्पष्टीकरण: मेट्रिक आफैमा राम्रो वा खराब हुँदैन; यो आधारभूत मोडेल अनुसार राम्रो वा खराब छ। '८५% सही' वाक्यको अर्थ आधार मोडेलले पहिले नै ८४% पाएको खण्डमा लगभग बेकार हुन्छ, र ५०% पाएमा पूर्ण हुन्छ। तुलना एंकर बिना, मेट्रिक अर्थहीन छ।

6. सबैभन्दा महत्त्वपूर्ण सुरक्षा तत्व कुन हो जुन RAG (Retrieval-Augmented Generation) प्रणालीको उत्पादन प्रम्प्टमा समावेश गर्नुपर्छ?

• क) दिइएको स्रोतमा मात्र भर पर्न निर्देशन, स्रोत नभएको खण्डमा 'मलाई थाहा छैन' भन्न र स्रोत उद्धृत गर्न ✔
• ख) मोडेललाई सकेसम्म लामो र सृजनात्मक उत्तरहरू उत्पादन गर्न भन्नु
• ग) मोडेलले स्रोतहरू भन्दा आफ्नै शैक्षिक ज्ञानलाई प्राथमिकता दिन्छ
• D) आदेशको रूपमा ल्याइएको कागजातहरूमा सबै निर्देशनहरू लागू गर्नुहोस्

स्पष्टीकरण: RAG को एकल सबैभन्दा महत्त्वपूर्ण निर्देशन भनेको दिइएको स्रोतमा मात्र भर पर्न मोडेललाई भन्नु हो, र यदि जानकारी स्रोतमा छैन भने, 'मलाई थाहा छैन' भन्नुहोस् र यसलाई बिना स्रोत उद्धृत गर्नुहोस्। यो ट्रायड बिना, मोडेलले सन्दर्भलाई बेवास्ता गर्न सक्छ र भ्रम उत्पन्न गर्न सक्छ, र जवाफ अप्रमाणित हुन्छ।

7. एक RAG प्रणालीले गलत जवाफ दिन्छ। निदान सुरु गर्न सबैभन्दा राम्रो ठाउँ कहाँ छ?

• A) पहिले फेच मापन गर्दै (Recall@K): के सही टुक्रा आइपुग्छ? ✔
• B) तुरुन्तै ठूलो संग मोडेल बदल्नुहोस्
• C) प्रम्प्ट अनियमित रूपमा परिवर्तन गर्नुहोस् र प्रयास जारी राख्नुहोस्
• D) सबै कागजातहरू मोडेलमा फाइन-ट्यूनिंगको साथ इम्बेड गर्दै

स्पष्टीकरण: RAG को सबैभन्दा कमजोर लिङ्क सामान्यतया ल्याउँछ, उत्पादन होइन। यदि सही भाग कहिल्यै ल्याइएको छैन भने, मोडेलले त्यो जानकारी उत्पादन गर्न सक्दैन, चाहे जतिसुकै प्रम्प्ट सुधार गरियो। तसर्थ, पहिले Recall@K मापन गरिन्छ कि सही भाग आएको छ कि छैन; यदि फेच राम्रो छ भने, उत्पादन र प्रोम्प्ट जाँच गरिन्छ।

8. एजेन्टलाई उपकरण दिंदा मानवीय स्वीकृति पछि के कार्यहरू राख्नुपर्छ?

• क) कुनै पनि; एजेन्टले प्रत्येक कार्यलाई स्वायत्त रूपमा गर्न सक्षम हुनुपर्छ
• B) केवल उल्टाउन मिल्ने कार्यहरू जस्तै डेटा पढ्ने र खोज्ने
• C) अपरिवर्तनीय वा उच्च प्रभाव कार्यहरू जस्तै पैसा स्थानान्तरण, मेटाउने, पठाउने ✔
• D) गणना मात्र समावेश गर्ने कार्यहरू

विवरण: कार्यहरू जोखिम स्तर द्वारा विभाजित छन्। पुन: प्राप्त गर्न सकिने कार्यहरू जस्तै पढ्ने, खोज्ने, गणना गर्ने, र ड्राफ्टहरू उत्पन्न गर्ने जस्ता कामहरू स्वायत्त रूपमा गर्न सकिन्छ; यद्यपि, अपरिवर्तनीय वा उच्च प्रभावकारी कार्यहरू जस्तै पैसा स्थानान्तरण, इमेल पठाउने, डाटा मेटाउने, अर्डर राख्ने आदिलाई मानव स्वीकृति चाहिन्छ। प्रत्येक अपरिवर्तनीय कार्य सहमतिको अधीनमा हुनुपर्छ।

9. अप्रत्यक्ष प्रम्प्ट इन्जेक्सनको जोखिम विरुद्ध उत्तम डिजाइन दृष्टिकोण के हो?

• A) प्रणाली प्रम्प्टमा 'खराब निर्देशनहरू बेवास्ता गर्नुहोस्' एउटै वाक्य थप्न पर्याप्त छ
• B) बाह्य सामग्रीमा भएका निर्देशनहरूमा भर परेर मोडेललाई थप अधिकार दिनुहोस्
• ग) सुई रोक्न नसकिने भएकाले कुनै पनि सावधानी नलिने
• D) बाह्य सामग्रीलाई अविश्वसनीय डेटाको रूपमा अलग गर्ने र न्यूनतम प्राधिकरण, स्वीकृति, र आउटपुट नियन्त्रणको साथ स्तरित सुरक्षाहरू स्थापना गर्ने ✔

विवरण: एजेन्ट वा RAG द्वारा प्रशोधन गरिएको बाह्य सामग्री, जस्तै वेब पृष्ठ, कागजात, इमेल, आदि, अविश्वसनीय डेटा हो र गोप्य निर्देशनहरू समावेश हुन सक्छ। सही दृष्टिकोण स्तरित रक्षा हो: बाह्य सामग्रीलाई स्पष्ट सीमांककहरूको साथ 'डेटा, आदेश होइन' को रूपमा पृथक गर्ने, न्यूनतम प्राधिकरण लागू गर्ने, अपरिवर्तनीय कार्यहरूलाई मानव अनुमोदनमा बाँध्ने, र आउटपुटको लेखा परीक्षण। निर्देशनको एक लाइन पर्याप्त छैन।

10. फाइन-ट्युनिङ वा RAG बाट समस्या समाधान गर्ने भन्ने निर्णय गर्दा मुख्य भिन्नता के हो?

• A) सूचना समस्याहरू RAG बाट राम्रोसँग समाधान गरिन्छ, व्यवहार/ढाँचा समस्याहरू राम्रोसँग फाइन-ट्युनिङद्वारा समाधान गरिन्छ ✔
• ख) हरेक समस्यालाई सधैं फाइन ट्युनिङ गरेर समाधान गर्नुपर्छ
• C) RAG कोड उत्पादनको लागि मात्र प्रयोग गरिन्छ, फाइन-ट्युनिङ अनुवादको लागि मात्र प्रयोग गरिन्छ
• D) फाइन ट्युनिङ सधैं सस्तो र RAG भन्दा छिटो अपडेट गर्न सकिन्छ

स्पष्टीकरण: मोडेल नयाँ जानकारी सिकाउनमा फाइन-ट्यूनिङ कमजोर र जोखिमपूर्ण छ; तर शिक्षण व्यवहार, ढाँचा, स्वर र शैलीमा शक्तिशाली छ। 'मोडल कम्पनीलाई हाम्रो डाटा थाहा छैन' एक सूचना समस्या हो र RAG को हो। 'मोडललाई सधैं हाम्रो कडा ढाँचामा आउटपुट गर्न दिनुहोस्' एक व्यवहारिक समस्या हो र राम्रो-ट्युनिङको लागि उम्मेद्वार हो। थप रूपमा, फाइन-ट्युनिङ अघि प्रम्प्ट र केही-सटहरू उपभोग गर्नुपर्छ।

11. उत्पादनमा नयाँ मोडल राख्दा सुरक्षित परिनियोजनको लागि कुन अनिवार्य छ?

• A) यदि मोडेल परीक्षणमा राम्रो छ भने, यसलाई सीधा 100% ट्राफिकमा खोल्नुहोस्
• ख) तैनाती पछि अनुगमन स्थापना नगर्ने
• C) चरणबद्ध तैनाती (छाया/क्यानरी) र पूर्व-परीक्षण रोलब्याक योजना ✔
• घ) मूल्याङ्कन थ्रेसहोल्ड पूरा नभए पनि मोडेल प्रकाशित गर्ने

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

१२. एमएल मोडेल कसरी उत्पादनमा 'चुपचाप' असफल हुन सक्छ र यसलाई समात्ने उपाय के हो?

• A) मोडेल पतन हुन्छ; सर्भर लगहरूले यो देखाउँछन्
• ख) गल्ती नगरी गलत भविष्यवाणीहरू उत्पादन गरेर; ✔ यसले परिचालन, इनपुट र आउटपुट स्तरित अनुगमन क्याप्चर गर्दछ
• C) मोडेल कहिल्यै चुपचाप असफल हुन सक्दैन, सधैं अलार्म
• D) विलम्बताको अनुगमन मात्र कुनै पनि गिरावट समात्न पर्याप्त छ

स्पष्टीकरण: मोडेल क्र्यास वा त्रुटिहरू बिना गलत भविष्यवाणीहरू उत्पादन गरेर मात्र असफल हुन सक्छ; यसको मुख्य कारण डाटा बहाव र अवधारणा बहाव हो। केवल परिचालन मेट्रिक्स (विलम्बता, त्रुटि दर) को निगरानी पर्याप्त छैन; इनपुट वितरण र आउटपुट/पूर्वानुमान वितरणको पनि अनुगमन गरिनुपर्छ। यदि वास्तविक परिणाम ढिलो भयो भने इनपुट बहावले प्रारम्भिक चेतावनी दिन्छ।

13. LLM प्रणालीको मूल्याङ्कन गर्न LLM-जज-जज प्रयोग गर्दा कुन सिद्धान्त आवश्यक छ?

• क) LLM-रेफरी सधैं सही छ, मानव प्रमाणीकरण अनावश्यक छ
• ख) रेफ्रीले जवाफको लम्बाइको आधारमा मात्र निर्णय गर्नुपर्छ।
• ग) रेफरीहरू प्रयोग गर्दा नियमहरूमा आधारित नियन्त्रणहरू र मानव मूल्याङ्कनलाई पूर्ण रूपमा खारेज गर्नुपर्छ
• D) न्यायाधीश स्कोरहरू मानव-लेबल गरिएको नमूनाको साथ क्यालिब्रेट गरिनु पर्छ र उनीहरूलाई विश्वास गर्न सक्नु अघि तिनीहरूको पूर्वाग्रह मापन गर्नुपर्छ ✔

विवरण: LLM-रेफरी पनि एक मोडेल हो; यो hallucinatory, पक्षपाती (लामो, विश्वस्त जवाफहरूको पक्षमा), र असंगत हुन सक्छ। त्यसकारण, रेफरी स्कोरहरू मानव लेबल गरिएको नमूनाको साथ क्यालिब्रेट गरिनु पर्छ र उत्पादन निर्णय गर्नु अघि तिनीहरूको व्यवस्थित पूर्वाग्रह मापन गरिनु पर्छ। एक अप्रमाणित रेफरीले गलत विश्वास दिन्छ।

14. मोडेल पूर्वाग्रहको मूल्याङ्कन गर्दा समग्र शुद्धतालाई किन अपर्याप्त छ?

• A) समग्र शुद्धता पर्याप्त छ किनभने यसले सधैं खराब समूहको प्रदर्शनलाई प्रतिबिम्बित गर्दछ
• B) समग्र शुद्धता मात्र अपर्याप्त छ किनकि यसले उपसमूहहरू बीचको व्यवस्थित भिन्नता (लुकेको भेदभाव) लाई अस्पष्ट गर्न सक्छ ✔
• C) किनभने शुद्धता एक मेट्रिक हो जसको पूर्वाग्रहसँग कुनै सम्बन्ध छैन
• D) पूर्वाग्रह केवल मोडेलबाट आउँछ र डेटासँग कुनै सरोकार छैन।

स्पष्टीकरण: समग्र शुद्धताले उपसमूहहरू बीचको व्यवस्थित भिन्नताहरूलाई अस्पष्ट पार्न सक्छ। उदाहरणका लागि, समग्र शुद्धता ८८% हुँदा, रिकॉल एउटा समूहमा ९१% र अर्को समूहमा ६७% हुन सक्छ; मोडेलले व्यवस्थित रूपमा त्यो समूहलाई मिस गर्छ। तसर्थ, उपसमूह (जनसांख्यिकी/खण्ड) को आधारमा मोडेलको मूल्याङ्कन गरिनुपर्छ र न्यायको कुन परिभाषालाई प्राथमिकता दिने भन्ने सरोकारवालाहरूसँग निर्णय गर्नुपर्छ।

15. ML नतिजा पुन: उत्पादन गर्नको लागि कुन चार कुराहरू एकैसाथ तय गर्नुपर्छ?

• A) मोडेलको नाम, साइज, मूल्य र रिलीज मिति मात्र
• B) केवल GPU ब्रान्ड र इन्टरनेट गति
• सी) मोडेलको अन्तिम शुद्धता स्कोर मात्र; बाँकी मेमोरीमा राख्न सकिन्छ
• D) अनियमितता बीज, डाटा संस्करण, वातावरण (निर्भरता संस्करणहरू) र प्रयोग ट्र्याकिङ ✔

विवरण: प्रजनन योग्यता चार स्तम्भहरू मार्फत प्राप्त गरिन्छ: अनियमितता बीज फिक्सिङ, डाटा संस्करण (संस्करण/ह्यास), वातावरण फ्रिजिङ (सही पुस्तकालय संस्करणहरू/कन्टेनर), र प्रत्येक प्रयोग ट्र्याकिङ (कोड कमिट, डाटा, हाइपरपेरामिटर, मेट्रिक)। यो श्रृंखला बिना यो समान परिणाम पुन: उत्पादन गर्न सम्भव छैन; एक गैर-पुनरुत्पादन योग्य परिणाम एक दावी हो जुन प्रमाणित हुन सक्दैन।