आपने छह महीने पहले LLM-संचालित सुविधा भेजी थी। लॉन्च से पहले इसका अच्छी तरह से परीक्षण किया गया। शुरुआत में यूजर्स खुश नजर आए। लेकिन हाल ही में, एआई गुणवत्ता के बारे में समर्थन टिकट तेजी से बढ़ रहे हैं। मॉडल प्रदाता ने पिछले महीने एक अपडेट जारी किया था जिसका आपने वास्तव में मूल्यांकन नहीं किया था। लॉन्च के बाद से आपका मूल्यांकन डेटासेट ताज़ा नहीं किया गया है। और सुविधा का निर्माण करने वाली टीम अन्य परियोजनाओं पर चली गई है, केवल तभी जाँच कर रही है जब कोई चीज़ इतनी बुरी तरह से टूट जाती है कि ध्यान आकर्षित करती है।
यह निरंतर मूल्यांकन के बिना LLM सुविधाओं के लिए डिफ़ॉल्ट प्रक्षेपवक्र है। मॉडल बदलता है, डेटा बदलता है, उपयोगकर्ता की अपेक्षाएं बदलती हैं, और किसी को भी गुणवत्ता में गिरावट का पता नहीं चलता जब तक कि यह एक वास्तविक समस्या नहीं बन जाती।
LLM मूल्यांकन रेट्रोस्पेक्टिव वह अभ्यास है जो इस धीमी गति से होने वाले क्षय को रोकता है। लॉन्च से पहले एक बार का परीक्षण चरण नहीं, बल्कि गुणवत्ता को मापने, विफलताओं को समझने और व्यवस्थित रूप से सुधार करने की आवर्ती आदत है।
क्यों LLM मूल्यांकन मौलिक रूप से भिन्न है
यदि आप पारंपरिक सॉफ़्टवेयर विकास से आते हैं, तो परीक्षण के बारे में आपकी प्रवृत्ति आपको LLMs से गुमराह करेगी। इसका कारण यह है:
आउटपुट गैर-नियतात्मक हैं। एक ही इनपुट हर बार अलग-अलग आउटपुट उत्पन्न कर सकता है। इसका मतलब है कि आप सरल "अपेक्षित आउटपुट वास्तविक आउटपुट के बराबर है" दावे के साथ परीक्षण नहीं कर सकते। आपको स्पेक्ट्रम पर आउटपुट गुणवत्ता का मूल्यांकन करने की आवश्यकता है, न कि बाइनरी पास/फेल के साथ।
शुद्धता व्यक्तिपरक है। कई LLM कार्यों के लिए, एक भी सही उत्तर नहीं है। एक अच्छा सारांश, एक उपयोगी ग्राहक सेवा प्रतिक्रिया, एक अच्छी तरह से लिखा गया ईमेल - इनमें निर्णय कॉल शामिल हैं जिन पर उचित लोग असहमत हैं। आपके मूल्यांकन ढांचे को इस व्यक्तिपरकता को स्पष्ट रूप से संभालने की आवश्यकता है।
गुणवत्ता चुपचाप ख़राब हो जाती है। पारंपरिक सॉफ़्टवेयर ज़ोर से टूटता है: त्रुटियाँ, क्रैश, विफल परीक्षण। LLM गुणवत्ता धीरे-धीरे कम हो जाती है: थोड़ा कम सटीक आउटपुट, सूक्ष्म रूप से भिन्न स्वर, मामूली रूप से कम प्रासंगिक प्रतिक्रियाएँ। जब तक कोई नोटिस करेगा, गुणवत्ता कई हफ्तों से गिर रही होगी।
मॉडल आपके नीचे बदलता है। यदि आप एपीआई-आधारित मॉडल (जो कि अधिकांश टीमें हैं) का उपयोग कर रहे हैं, तो मॉडल प्रदाता किसी भी समय मॉडल को अपडेट कर सकता है। ये अपडेट आमतौर पर समग्र रूप से चीजों में सुधार करते हैं, लेकिन वे आपके विशिष्ट उपयोग के मामले में व्यवहार को उस तरीके से बदल सकते हैं जिसकी आप अपेक्षा नहीं करते हैं।
इन अंतरों का मतलब है कि आपको निरंतर मूल्यांकन अभ्यास की आवश्यकता है, न कि परीक्षण-फिर-शिप दृष्टिकोण की।
क्या मापें
आपको हर चीज़ को मापने की ज़रूरत नहीं है। आपको उन चीज़ों को मापने की ज़रूरत है जो आपके विशिष्ट उपयोग के मामले के लिए महत्वपूर्ण हैं, और रुझानों को पहचानने के लिए उन्हें लगातार मापना होगा। यहां एक व्यावहारिक रूपरेखा है।
सटीकता और विश्वसनीयता
क्या मॉडल सही जानकारी देता है? तथ्यात्मक कार्यों के लिए यह आयाम सबसे अधिक मायने रखता है: प्रश्न उत्तर देना, सारांशीकरण, डेटा निष्कर्षण, विश्लेषण।
मूल्यांकन कैसे करें: हाल के उत्पादन आउटपुट का एक नमूना लें। तथ्यात्मक त्रुटियों, मतिभ्रम (प्रदान किए गए संदर्भ द्वारा समर्थित जानकारी नहीं), और चूक (महत्वपूर्ण जानकारी जो उपलब्ध थी लेकिन शामिल नहीं थी) के लिए एक मानव समीक्षक से प्रत्येक की जांच करवाएं।
क्या ट्रैक करें: प्रति नमूना तथ्यात्मक त्रुटियों की दर, और क्या वह दर ऊपर या नीचे की ओर रुझान में है। त्रुटियों की गंभीरता पर भी नज़र रखें - गलत वर्तनी वाला नाम गलत वित्तीय आंकड़े की तुलना में कम चिंताजनक है।
अनुदेश निम्नलिखित
क्या मॉडल वही करता है जो आपने उससे करने को कहा था? इसमें प्रारूप अनुपालन, बाधा पालन और कार्य पूर्णता शामिल है।
मूल्यांकन कैसे करें: कार्य का "सही" निष्पादन कैसा दिखता है, इसके लिए स्पष्ट मानदंड परिभाषित करें। क्या आउटपुट अनुरोधित प्रारूप से मेल खाता है? क्या यह लंबाई की बाधाओं का सम्मान करता है? क्या यह निर्धारित दायरे में रहता है? ये गुणवत्तापूर्ण निर्णयों की तुलना में अधिक वस्तुनिष्ठ रूप से मापने योग्य हैं।
क्या ट्रैक करें: सभी निर्देशों का पालन करने वाले आउटपुट का प्रतिशत। उल्लंघनों को वर्गीकृत करें - क्या वे प्रारूप संबंधी समस्याएं, बाधा उल्लंघन, या दायरा बहाव हैं? प्रत्येक एक अलग समाधान की ओर इशारा करता है।
उपयोगकर्ता-अनुमानित गुणवत्ता
क्या उपयोगकर्ताओं को आउटपुट उपयोगी, अच्छी तरह से लिखे गए और उपयोगी लगते हैं? यह मापने के लिए सबसे कठिन आयाम है लेकिन यकीनन सबसे महत्वपूर्ण है।
मूल्यांकन कैसे करें: दो दृष्टिकोण अच्छे से काम करते हैं। पहला, इन-प्रोडक्ट सिग्नल: अंगूठे ऊपर/नीचे, स्पष्ट रेटिंग, अनुवर्ती प्रश्न (यदि उपयोगकर्ता अनुवर्ती पूछता है, तो पहली प्रतिक्रिया पूरी नहीं हो सकती है)। दूसरा, आवधिक मानव मूल्यांकन: एक नमूना लें और उसे एक रूब्रिक पर रेट करें जो परिभाषित करता है कि आपकी सुविधा के लिए "अच्छा" का क्या अर्थ है।
क्या ट्रैक करें: समग्र संतुष्टि रुझान और विशिष्ट गुणवत्ता आयाम जहां उपयोगकर्ता असंतोष व्यक्त करते हैं।
सुरक्षा और संरेखण
क्या मॉडल ऐसे आउटपुट उत्पन्न करता है जो हानिकारक, पक्षपातपूर्ण या अनुचित हैं? यह आयाम टेबल स्टेक है - यहां विफलताओं का प्रभाव बहुत अधिक है।
मूल्यांकन कैसे करें: अपना सुरक्षा परीक्षण सूट नियमित रूप से चलाएं (सिर्फ लॉन्च के समय नहीं)। प्रतिकूल परीक्षण शामिल करें: हानिकारक आउटपुट को भड़काने के लिए डिज़ाइन किए गए इनपुट। अपनी सामग्री मॉडरेशन परत द्वारा चिह्नित किसी भी आउटपुट की समीक्षा करें।
क्या ट्रैक करें: सुरक्षा उल्लंघनों की दर, जिसमें फ़िल्टर द्वारा पकड़ी गई चूकें भी शामिल हैं। सभी मॉडल अपडेट में प्रतिकूल परीक्षण परिणामों को ट्रैक करें - एक मॉडल जो अपडेट से पहले सुरक्षित था वह बाद में सुरक्षित नहीं हो सकता है।
मूल्यांकन ⟦RETROC⟧
ताल
अधिकांश टीमों के लिए मासिक अच्छा काम करता है। अधिक बार यदि आप उच्च जोखिम वाले डोमेन (स्वास्थ्य सेवा, वित्त, कानूनी) में हैं या यदि आप संकेतों पर तेजी से काम कर रहे हैं। यदि आपकी सुविधा स्थिर और कम जोखिम वाली है तो कम बार - लेकिन त्रैमासिक से कम कभी नहीं।
तैयारी
रेट्रो⟧ उतना ही अच्छा है जितना डेटा आप इसमें लाते हैं। टीम में किसी को (इस भूमिका को घुमाएँ) तैयार करने की आवश्यकता है:
मीट्रिक डैशबोर्ड। पिछली अवधि की तुलना में वर्तमान अवधि के लिए आपके प्रमुख गुणवत्ता मीट्रिक। इस पर ध्यान केंद्रित रखें - अधिकतम 4-6 मीट्रिक, सीधे उपरोक्त आयामों से जुड़े।
मूल्यांकन नमूना परिणाम। अपना मूल्यांकन सूट चलाएं और परिणाम लाएं। यदि आप मानव मूल्यांकन कर रहे हैं, तो इसे बैठक से पहले पूरा करें, उसके दौरान नहीं।
विफलता के उदाहरण। इस अवधि के 5-10 सबसे खराब आउटपुट। पूरा संदर्भ शामिल करें: इनपुट, प्रॉम्प्ट, आउटपुट और यह खराब क्यों है। ये ठोस उदाहरण हैं जहां सबसे अधिक उत्पादक चर्चा होती है।
चेंजलॉग। कोई भी परिवर्तन जो गुणवत्ता को प्रभावित कर सकता है: त्वरित अपडेट, मॉडल संस्करण परिवर्तन, डेटा अपडेट, सुविधा परिवर्तन, उपयोग पैटर्न में बदलाव।
बैठक संरचना (60 मिनट)
मेट्रिक्स समीक्षा (10 मिनट)। क्या हम प्रत्येक आयाम पर सुधार कर रहे हैं, गिर रहे हैं या स्थिर हैं? क्या कोई मेट्रिक्स उस सीमा को पार कर गया है जिसकी हमें परवाह है? कोई अप्रत्याशित परिवर्तन जिसे हम समझा न सकें?
विफलता गहन-गोता (25 मिनट)। विफलता के उदाहरणों पर गौर करें। प्रत्येक के लिए, टीम को चर्चा करनी चाहिए:
- विशेष रूप से क्या गलत हुआ?
- क्या यह एक नया विफलता मोड है या जिसे हमने पहले देखा है?
- मूल कारण क्या है - संकेत, मॉडल, डेटा, या कुछ और?
- भविष्य में हम इसे स्वचालित रूप से कैसे पकड़ेंगे?
लक्ष्य मीटिंग में हर विफलता को ठीक करना नहीं है। यह पैटर्न को समझना और प्राथमिकता देना है।
मूल्यांकन प्रक्रिया समीक्षा (10 मिनट)। क्या हमारा मूल्यांकन वास्तव में सही चीजों को माप रहा है? क्या ऐसे विफलता मोड हैं जिन्हें हम नहीं पकड़ रहे हैं? क्या हमें अपने परीक्षण मामलों को अद्यतन करने की आवश्यकता है? क्या हमारे मूल्यांकन मानदंड अभी भी उपयोगकर्ताओं की परवाह के अनुरूप हैं?
यह मेटा-समीक्षा महत्वपूर्ण है। किसी भी अन्य चीज़ की तरह मूल्यांकन प्रक्रियाएँ भी पुरानी हो सकती हैं। यदि आपके सभी परीक्षण मामले छह महीने पहले के हैं और आपके उपयोगकर्ताओं की ज़रूरतें बदल गई हैं, तो आपका मूल्यांकन आपको सुरक्षा की झूठी भावना दे रहा है।
कार्रवाई आइटम (15 मिनट)। 2-3 विशिष्ट सुधार चुनें। ये आम तौर पर श्रेणियों में आते हैं:
- विशिष्ट विफलता पैटर्न को संबोधित करने के लिए शीघ्र परिवर्तन
- मूल्यांकन में सुधार (नए परीक्षण मामले, अद्यतन रूब्रिक्स, बेहतर स्वचालन)
- रेलिंग अपडेट (नए सुरक्षा फ़िल्टर, अतिरिक्त पोस्ट-प्रोसेसिंग जांच)
- जांच कार्य (एक अस्पष्टीकृत गुणवत्ता परिवर्तन की जांच करें, एक विशिष्ट विफलता मोड की रूपरेखा तैयार करें)
अपना मूल्यांकन स्टैक बनाना
शुरू करने के लिए आपको महंगे टूलींग की आवश्यकता नहीं है। यहां एक व्यावहारिक प्रगति है।
चरण 1: मैन्युअल मूल्यांकन (यहां प्रारंभ करें)
साप्ताहिक, नमूना 20-30 उत्पादन आउटपुट। टीम के दो सदस्यों को अपने गुणवत्ता रूब्रिक के आधार पर प्रत्येक को स्वतंत्र रूप से रेटिंग देने को कहें। उनकी रेटिंग की तुलना करें - यदि वे अक्सर असहमत होते हैं, तो आपका रूब्रिक अधिक विशिष्ट होना चाहिए। इन रेटिंग्स को एक स्प्रेडशीट में ट्रैक करें।
यह अस्वाभाविक लेकिन प्रभावी है। आप किसी भी स्वचालित मीट्रिक की तुलना में 30 वास्तविक आउटपुट पढ़ने से अपने मॉडल के व्यवहार के बारे में अधिक जानेंगे।
चरण 2: अर्ध-स्वचालित मूल्यांकन
एक मूल्यांकन डेटासेट बनाएं: इनपुट, अपेक्षित आउटपुट विशेषताओं (जरूरी नहीं कि सटीक आउटपुट), और गुणवत्ता एनोटेशन के साथ 100-200 उदाहरण। जब भी आप संकेत या मॉडल बदलें तो इसे स्वचालित रूप से चलाएँ। उत्पादन तक पहुंचने से पहले प्रतिगमन को पकड़ने के लिए परिणामों का उपयोग करें।
उन आयामों के लिए LLM-ए-जज मूल्यांकन जोड़ें जहां यह अच्छी तरह से काम करता है: प्रारूप अनुपालन, निर्देशों का पालन, बुनियादी तथ्यात्मक सत्यापन। उन आयामों के लिए मानव मूल्यांकन का उपयोग करें जहां यह नहीं है: सूक्ष्मता, सहायकता, टोन उपयुक्तता।
चरण 3: सतत निगरानी
उत्पादन ट्रैफ़िक पर स्वचालित गुणवत्ता जांच सेट करें। इन्हें हर चीज़ को पकड़ने की ज़रूरत नहीं है - गुणवत्ता में महत्वपूर्ण परिवर्तन होने पर आपको सचेत करने के लिए उन्हें पर्याप्त पकड़ने की ज़रूरत है। एक सरल दृष्टिकोण: बेतरतीब ढंग से उत्पादन प्रश्नों के एक छोटे प्रतिशत का नमूना लें, स्वचालित जांच चलाएं और यदि विफलता दर एक सीमा से अधिक हो तो सचेत करें।
यह आपके मानवीय मूल्यांकन को प्रतिस्थापित करने के बजाय पूरक करता है। स्वचालित निगरानी अचानक होने वाले परिवर्तनों को तेजी से पकड़ लेती है। मानव मूल्यांकन सूक्ष्म गुणवत्ता विचलन को पकड़ता है जो स्वचालित मेट्रिक्स चूक जाते हैं।
सामान्य मूल्यांकन गलतियाँ
केवल आसान उदाहरणों पर मूल्यांकन। यदि आपके मूल्यांकन डेटासेट में कठिन मामले शामिल नहीं हैं, तो आप सर्वोत्तम मामले के प्रदर्शन को माप रहे हैं, वास्तविक दुनिया के प्रदर्शन को नहीं। प्रतिकूल इनपुट, अस्पष्ट प्रश्न, डोमेन-विशिष्ट सामग्री और आपके वास्तविक उपयोगकर्ताओं द्वारा भेजे जाने वाले गंदे इनपुट के प्रकार शामिल करें।
एकमात्र उपाय के रूप में स्वचालित मेट्रिक्स का उपयोग करना। स्वचालित मेट्रिक्स (BLEU, ROUGE, BERTScore) रुझानों पर नज़र रखने के लिए उपयोगी हैं, लेकिन कई कार्यों के लिए मानव गुणवत्ता निर्णयों के साथ खराब संबंध रखते हैं। यदि आपके स्वचालित मेट्रिक्स कहते हैं कि गुणवत्ता ठीक है लेकिन उपयोगकर्ता शिकायत कर रहे हैं, तो उपयोगकर्ताओं पर भरोसा करें।
विभिन्न मूल्यांकन सेटों पर मॉडलों की तुलना करना। यदि आप मूल्यांकन कर रहे हैं कि मॉडल स्विच करना है या नहीं, तो दोनों के लिए बिल्कुल समान मूल्यांकन सेट का उपयोग करें। यदि आप उदाहरणों के एक सेट पर मॉडल ए और एक अलग सेट पर मॉडल बी का परीक्षण करते हैं, तो तुलना अर्थहीन है।
अंतर-रेटर समझौते पर नज़र नहीं रखना। यदि आपके मानव मूल्यांकनकर्ता 40% रेटिंग पर असहमत हैं, तो आपका मूल्यांकन डेटा शोर है। या तो अपने रूब्रिक में सुधार करें, अधिक प्रशिक्षण प्रदान करें, या स्वीकार करें कि कार्य स्वाभाविक रूप से व्यक्तिपरक है और उसके अनुसार अपने मेट्रिक्स डिज़ाइन करें।
बहुत कम मूल्यांकन करना। साप्ताहिक मॉडल परिवर्तनों के साथ मासिक मूल्यांकन का मतलब है कि आप हमेशा पुराने डेटा को देख रहे हैं। अपने मूल्यांकन ताल को अपने परिवर्तन ताल से मिलाएं।
मूल्यांकन को संस्कृति का हिस्सा बनाना
P1⟧ मूल्यांकन का सबसे कठिन हिस्सा कार्यप्रणाली नहीं है - यह अभ्यास को बनाए रखना है। मूल्यांकन अतिश्योक्ति जैसा लगता है, खासकर जब चीजें अच्छी चल रही हों। "सिर्फ इस महीने" छोड़ने का प्रलोभन वास्तविक है।
क्या मदद करता है: मूल्यांकन परिणामों को दृश्यमान बनाना। उन्हें टीम चैनलों में साझा करें. गुणवत्ता में सुधार का जश्न मनाएं. गुणवत्ता में गिरावट को उन घटनाओं के रूप में मानें जो जांच के योग्य हैं। जब मूल्यांकन से किसी समस्या का पता चलता है, इससे पहले कि उपयोगकर्ता उस पर ध्यान दें, तो उसे भी दृश्यमान बनाएं - यह चल रहे निवेश को उचित ठहराता है।
समय के साथ, मजबूत मूल्यांकन अभ्यास वाली टीमें अपने मॉडलों के बारे में बेहतर अंतर्ज्ञान विकसित करती हैं। वे विफलता के तरीकों की आशा करते हैं। वे अधिक आत्मविश्वास के साथ त्वरित परिवर्तन करते हैं। जब कोई समस्या घटित होती है तो वे उसे तेजी से पकड़ लेते हैं। ⟦रेट्रो⟧ वह तंत्र है जो इस संस्थागत ज्ञान का निर्माण करता है।
<घंटा/>NextRetro निःशुल्क आज़माएं - मीट्रिक समीक्षा, विफलता विश्लेषण और सुधार योजना के चरणों के साथ अपने मूल्यांकन रेट्रोस्पेक्टिव की संरचना करें।
<घंटा/>अंतिम अद्यतन: फरवरी 2026
पढ़ने का समय: 8 मिनट
