मूल्यांकन और निगरानी: यह जानना कि मॉडल वास्तव में उत्पादन में क्या करता है

लाभ:

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

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

क्यों उत्पादन मॉडल चुपचाप ख़राब हो रहा है?

एक बग क्रैश हो जाता है, लॉग प्रिंट हो जाता है, अलार्म बंद हो जाता है। दूसरी ओर, एक एमएल मॉडल त्रुटि उत्पन्न किए बिना गलत हो सकता है। पतन के तीन मुख्य कारण:

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

अनुरेखण इन मूक विकृतियों को श्रव्य बना रहा है।

क्या देखें: तीन परतें

अच्छी निगरानी में तीन परतें शामिल होती हैं:

1. परिचालन मेट्रिक्स: विलंबता, त्रुटि दर, अनुरोध मात्रा, संसाधन उपयोग। "क्या सिस्टम खड़ा है?"
2. डेटा/इनपुट मेट्रिक्स: क्या इनपुट वितरण प्रशिक्षण के समान है? क्या लुप्त मूल्य दर में वृद्धि हुई है? क्या नई श्रेणियाँ आ गई हैं? "क्या मॉडल परिचित डेटा देख रहा है?"
3. मॉडल/आउटपुट मेट्रिक्स: पूर्वानुमान वितरण लॉग? क्या आत्मविश्वास स्कोर गिरा है? और यदि संभव हो तो जमीनी सच्चाई की तुलना में सटीकता कितनी है? "क्या मॉडल अभी भी सटीक है?"

तीसरी परत सबसे मूल्यवान लेकिन सबसे कठिन है; क्योंकि वास्तविक परिणाम आमतौर पर देरी से आता है (यह महीनों के बाद स्पष्ट हो जाता है कि ऋण चुकाया जाएगा या नहीं)।

युक्ति: यदि वास्तविक परिणाम में देरी हो रही है, तो पहले इनपुट और पूर्वानुमान वितरण की निगरानी करें। इनपुट वितरण में बदलाव सटीकता में गिरावट का एक प्रारंभिक संकेत है और वास्तविक परिणाम की प्रतीक्षा किए बिना अलार्म बजा सकता है।

एलएलएम प्रणालियों का मूल्यांकन: विशेष चुनौती

शास्त्रीय एमएल में, "सही उत्तर" स्पष्ट है (कक्षा 0 या 1)। दूसरी ओर, एलएलएम परिणाम ओपन-एंडेड है: एक ही प्रश्न के कई सही उत्तर हो सकते हैं, "शुद्धता" एक संख्या में फिट नहीं होती है। एलएलएम मूल्यांकन दृष्टिकोण:

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

व्यवहार में इन्हें एक साथ उपयोग किया जाता है: प्रत्येक आउटपुट पर सस्ते नियम की जांच, बड़े नमूने पर एलएलएम-जज, छोटे लेकिन कठोर नमूने पर मानव मूल्यांकन।

कमजोर दृष्टिकोण/मजबूत दृष्टिकोण

कमजोर: "एलएलएम-मैंने रेफरी से पूछा, हमारे 92% उत्तर अच्छे थे। प्रणाली बहुत अच्छी है।"

गुक्लु: "हमने पहले 100 प्रिंटआउट पर मानव-लेबल लगाया। हमने उन्हीं 100 प्रिंटआउट पर एलएलएम-जज चलाया और मानव-जज समझौते को मापा - 85% समझौता, स्वीकार्य। हमने दस्तावेजीकरण किया कि कहां न्यायाधीश ने व्यवस्थित रूप से गलत किया (लंबे उत्तरों को गलत तरीके से अच्छा खोजने की प्रवृत्ति) और उसके संकेत को ठीक किया। केवल तभी हमने न्यायाधीश के स्कोर पर भरोसा किया।"

अंतर: मजबूत दृष्टिकोण रेफरी को मानव एंकर के साथ सत्यापित करता है, आँख बंद करके नहीं। एक असत्यापित एलएलएम-रेफरी अच्छा दिखने वाला लेकिन झूठा आत्मविश्वास देता है।

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

मूल्यांकन सेट: सावधानीपूर्वक डिज़ाइन किया गया

एक अच्छा eval सेट वास्तविक उपयोग और कठिन मामलों की विविधता का प्रतिनिधित्व करता है। केवल आसान उदाहरणों से भरा एक मूल्यांकन आपको झूठे आत्मविश्वास में छोड़ देगा। इसे eval क्लस्टर में रखना सुनिश्चित करें:

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

ईवल क्लस्टर समय के साथ बढ़ता है: उत्पादन में आपके द्वारा पकड़ा गया प्रत्येक नया बग अगले मूल्यांकन के लिए एक परीक्षण मामला बन जाता है।

अलार्म और हस्तक्षेप

अलार्म के बिना निगरानी अधूरी रहती है। प्रत्येक महत्वपूर्ण मीट्रिक के लिए एक सीमा और एक प्रतिक्रिया योजना होनी चाहिए: "यदि इनपुट बहाव X से अधिक है तो इंजीनियर को सूचित करें", "यदि त्रुटि दर Y से अधिक है तो ऑटो रोल बैक"। अलार्म को सार्थक रखें - बहुत सारे झूठे अलार्म टीम को असंवेदनशील बनाते हैं और उन्हें वास्तविक अलार्म से वंचित कर देते हैं।

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

केस 1 - प्रारंभिक चेतावनी। मांग पूर्वानुमान मॉडल की वास्तविक सटीकता सप्ताह के अंत में ही स्पष्ट हुई। टीम इनपुट वितरण की निगरानी कर रही थी और मंगलवार को एक नई उत्पाद श्रेणी में अचानक वृद्धि देखी - कुछ ऐसा जो मॉडल ने कभी नहीं देखा था। उन्होंने सटीकता में गिरावट की प्रतीक्षा किए बिना मॉडल को अपडेट किया। इनपुट मॉनिटरिंग ने दिन बचाए।

केस 2 - असत्यापित रेफरी। एलएलएम-समीक्षक के आधार पर एक टीम ने बताया "हमारी गुणवत्ता उत्कृष्ट है"। जब ग्राहकों की शिकायतें बढ़ीं, तो मानव निगरानी शुरू की गई: रेफरी ने आत्मविश्वासपूर्ण लेकिन गलत उत्तरों को "अच्छा" माना। एक बार जब रेफरी को मानव टैग के साथ कैलिब्रेट किया गया, तो वास्तविक गुणवत्ता का पता चला और वह बहुत कम थी। सबक: रेफरी की पुष्टि किए बिना उस पर भरोसा न करें।

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

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

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

इस एलएलएम प्रणाली के लिए एक मूल्यांकन (eval) रणनीति का प्रस्ताव करें। कार्य: [विवरण] परतें निर्धारित करें: - प्रत्येक आउटपुट पर कौन से नियम-आधारित जांच चलनी चाहिए? - एलएलएम-मध्यस्थ को किस मानदंड का मूल्यांकन करना चाहिए और उन्हें कैसे मान्य किया जाना चाहिए (मानव एंकर)? - मानव मूल्यांकन किस नमूने में किया जाना चाहिए? किनारे और सुरक्षा मामलों की सूची बनाएं जिन्हें मुझे eval सेट में रखना चाहिए।

इस एलएलएम-रेफरी प्रॉम्प्ट की जाँच करें: - क्या मूल्यांकन मानदंड स्पष्ट या व्यक्तिपरक है? - क्या इसमें लंबाई/आत्मविश्वास पूर्वाग्रह की संभावना है? - मैं रेफरी को मानव टैग के साथ कैसे कैलिब्रेट कर सकता हूँ? रेफरी प्रॉम्प्ट: [संकेत]

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

ख़राबी कारण तालिका

विकृति

लक्षण

जल्दी पता लगाने का तरीका

डेटा बहाव

इनपुट वितरण परिवर्तन

इनपुट वितरण निगरानी

अवधारणा परिवर्तन

धार्मिकता चुपचाप गिर जाती है

भविष्यवाणी + वास्तविक तुलना

अपस्ट्रीम त्रुटि

फ़ील्ड रिक्त हो जाती हैं/प्रारूप बदल जाता है

स्कीमा सत्यापन + लापता दर

मॉडल असंगति

आउटपुट वितरण बदलाव

आउटपुट वितरण निगरानी

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

• मॉनिटरिंग स्थापित नहीं करना. मॉडल चुपचाप टूट जाता है, कोई उसे नहीं देखता।
• केवल परिचालन मेट्रिक्स को ट्रैक करें। सिस्टम चालू है, लेकिन पूर्वानुमान गलत हो सकते हैं।
• रेफरी की पुष्टि के बिना एलएलएम का उपयोग करना। यह झूठा आत्मविश्वास देता है.
• आसान उदाहरणों के साथ मूल्यांकन करें। यह वास्तविक कठिनाई का संकेत नहीं देता.
• eval में पिछली त्रुटियों को शामिल नहीं किया जा रहा है। वही त्रुटि पुनः लौट आती है।
• तेज़ अलार्म. टीम असंवेदनशील हो जाती है और वास्तविक अलार्म से चूक जाती है।

संक्षेप में

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

आवेदन कार्य

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

चेकलिस्ट

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