इस लेख में
- अपने चैटबॉट का मूल्यांकन करना वैकल्पिक क्यों नहीं है
- शून्य कदम: तय करें कि आपके लिए "सफलता" का क्या मतलब है
- एक "गोल्डन डेटासेट" बनाएँ
- आप असल में क्या मापते हैं? मुख्य आयाम
- मूल्यांकन के तीन तरीक़े
- ऑफ़लाइन बनाम ऑनलाइन मूल्यांकन
- मूल्यांकन शुरू करने के लिए एक व्यावहारिक वर्कफ़्लो
- आम ग़लतियाँ जो मूल्यांकन को बेकार बना देती हैं
- मददगार टूल
- Origami की भूमिका
- स्रोत
अपने चैटबॉट का मूल्यांकन करना वैकल्पिक क्यों नहीं है
आज AI चैटबॉट लॉन्च करना आसान है; मुश्किल हिस्सा यह जानना है कि वह वास्तव में अच्छा है या नहीं। भाषा मॉडल स्वभाव से संभाव्य (probabilistic) होते हैं: एक ही सवाल के दो अलग-अलग जवाब मिल सकते हैं, और मुट्ठी भर प्रॉम्प्ट पर "मैंने आज़माया और ठीक लगा" का मतलब यह नहीं कि वह हज़ारों ग्राहकों के लिए तैयार है। मूल्यांकन एक सवाल का जवाब देने का व्यवस्थित तरीका है: क्या बॉट अपना काम सटीक, सुरक्षित और लगातार ढंग से करता है — लॉन्च से पहले भी और हर बदलाव के बाद भी?
नियम सीधा है: जिसे आप मापते नहीं, उसे सुधार नहीं सकते। मूल्यांकन प्रणाली के बिना हर प्रॉम्प्ट बदलाव या मॉडल अपग्रेड एक जुआ बन जाता है, जिसमें आपको पता नहीं होता कि आपने कुछ सुधारा या चुपचाप कुछ और बिगाड़ दिया।
शून्य कदम: तय करें कि आपके लिए "सफलता" का क्या मतलब है
किसी भी मेट्रिक से पहले इसका जवाब दें: बॉट को कौन-सा काम पूरा करना है? सपोर्ट बॉट तब सफल है जब वह समस्या हल करे या उसे सही जगह भेजे। सेल्स बॉट तब सफल है जब वह लीड को क्वालिफ़ाई करे और सही डेटा इकट्ठा करे। कर्मचारियों के लिए आंतरिक बॉट तब सफल है जब वह सटीक और आपकी नीतियों पर आधारित जवाब दे। मूल्यांकन को किसी बिज़नेस लक्ष्य से जोड़ें, इस अस्पष्ट एहसास से नहीं कि जवाब पढ़ने में अच्छा लगता है।
एक "गोल्डन डेटासेट" बनाएँ
किसी भी गंभीर मूल्यांकन की नींव उदाहरणों का एक तय सेट होता है जिस पर आप हर बार परीक्षण करते हैं। इसे तीन स्रोतों से इकट्ठा करें:
- असली चैट लॉग से असली सवाल (निजी डेटा हटाने के बाद)।
- एज केस: अस्पष्ट, अधूरे या दायरे से बाहर के सवाल, या अलग-अलग बोलियाँ।
- प्रतिकूल (adversarial) केस: बॉट को उसकी सीमाओं से आगे धकेलने या जानकारी लीक कराने की कोशिशें।
हज़ारों बेतरतीब उदाहरणों के बजाय 50–100 उदाहरणों से शुरुआत करें जो आपके सबसे महत्वपूर्ण परिदृश्यों को कवर करें। हर उदाहरण के लिए, जितना संभव हो, संदर्भ उत्तर या वह मानदंड तय करें जो किसी जवाब को सही बनाता है।
आप असल में क्या मापते हैं? मुख्य आयाम
"गुणवत्ता" एक धुंधला शब्द है, इसलिए इसे मापने योग्य आयामों में बाँटें:
- टास्क की सफलता: क्या उपयोगकर्ता ने वास्तव में अपना लक्ष्य हासिल किया? यह सबसे महत्वपूर्ण मेट्रिक है और बिज़नेस वैल्यू के सबसे क़रीब है।
- फ़ेथफ़ुलनेस (कोई हैलुसिनेशन नहीं): आपके स्रोतों पर आधारित सिस्टम (RAG) में, क्या जवाब केवल प्राप्त किए गए दस्तावेज़ों पर बना है, या बॉट ने कुछ गढ़ लिया?
- प्रासंगिकता: क्या जवाब वास्तव में उपयोगकर्ता के सवाल को संबोधित करता है, या सिर्फ़ विषय के इर्द-गिर्द घूमता है?
- रिट्रीवल की गुणवत्ता: RAG में, क्या सिस्टम ने आपके नॉलेज बेस से सही अंश निकाले? (कॉन्टेक्स्ट प्रिसिज़न और रिकॉल)। ज़्यादातर RAG विफलताएँ ख़राब रिट्रीवल से होती हैं, ख़ुद मॉडल से नहीं।
- सटीकता: क्या जवाब किसी ज्ञात संदर्भ से मेल खाता है?
- सुरक्षा और अनुपालन: क्या यह ख़तरनाक अनुरोधों को मना करता है? क्या यह निजी डेटा की रक्षा करता है? क्या यह ब्रांड के लहजे और नीतियों पर क़ायम रहता है? क्या यह जेलब्रेक की कोशिशों का विरोध करता है?
- लागत और लेटेंसी: एक बेहतरीन जवाब जिसमें 30 सेकंड लगें या जिसकी प्रति बातचीत लागत बहुत ज़्यादा हो, व्यावसायिक विफलता बन सकता है। टोकन और समय को हमेशा मापें।
मूल्यांकन के तीन तरीक़े
- मानवीय मूल्यांकन: गुणवत्ता का स्वर्ण मानक, लेकिन धीमा, महँगा और बड़े पैमाने पर करना कठिन। इसका इस्तेमाल अपना संदर्भ बनाने और स्वचालित तरीक़ों को कैलिब्रेट करने के लिए करें।
- LLM-as-a-judge: आप एक शक्तिशाली मॉडल से बॉट के जवाबों को एक स्पष्ट रूब्रिक के आधार पर, या दो जवाबों की तुलना करके स्कोर करवाते हैं। यह तेज़ और स्केलेबल है, और आज सबसे आम तरीक़ा है — बशर्ते आप इसे मानवीय निर्णय के साथ कैलिब्रेट करें और इसके पूर्वाग्रहों (जैसे लंबे जवाब को तरजीह देना) पर नज़र रखें।
- संदर्भ-आधारित स्वचालित मेट्रिक्स: जैसे बंद-उत्तर वाले सवालों के लिए एग्ज़ैक्ट मैच, या एम्बेडिंग के ज़रिए सिमैंटिक समानता। सस्ते और तुरंत, लेकिन खुले जवाबों के लिए सीमित।
व्यवहार में: तीनों को मिलाएँ। पहली सुरक्षा पंक्ति के रूप में तेज़ स्वचालित मेट्रिक्स, गुणात्मक आयामों के लिए एक LLM जज, और एक सैंपल की समय-समय पर मानवीय समीक्षा।
ऑफ़लाइन बनाम ऑनलाइन मूल्यांकन
दो पूरक प्रकार हैं, और आपको दोनों की ज़रूरत है:
- ऑफ़लाइन: आप हर बदलाव पर बॉट को अपने गोल्डन डेटासेट पर चलाते हैं, आदर्श रूप से एक CI/CD पाइपलाइन के अंदर, ताकि स्कोर गिरने पर कोई भी अपडेट प्रोडक्शन तक न पहुँचे। यह वह रिग्रेशन टेस्ट है जो आपको पहले से काम कर रही चीज़ों को तोड़ने से रोकता है।
- ऑनलाइन: असली उपयोगकर्ताओं पर — दो संस्करणों के बीच A/B टेस्टिंग, एक फ़ीडबैक बटन (👍/👎), और गार्डरेल मेट्रिक्स (इंसान को हैंडऑफ़ की दर, दोहराए गए सवाल, बातचीत बीच में छोड़ना)। प्रोडक्शन की लगातार निगरानी करें, क्योंकि असली उपयोगकर्ताओं का व्यवहार वह उजागर करता है जो कोई भी टेस्ट सेट नहीं कर सकता।
मूल्यांकन शुरू करने के लिए एक व्यावहारिक वर्कफ़्लो
- वे 3–5 आयाम तय करें जो आपके लिए वास्तव में मायने रखते हैं (जैसे टास्क की सफलता, फ़ेथफ़ुलनेस, सुरक्षा)।
- एक छोटा लेकिन प्रतिनिधि गोल्डन सेट बनाएँ (50–100 केस)।
- हर आयाम के लिए एक स्पष्ट स्कोरिंग रूब्रिक लिखें: किस पर 5 मिलता है और किस पर 1 मिलता है।
- रन को स्वचालित करें: एक स्क्रिप्ट जो बॉट को सेट पर चलाए और स्कोर निकाले (इंसान + LLM जज)।
- इसे डिप्लॉयमेंट पाइपलाइन में डालें: सीमा से नीचे का कोई भी स्कोर रिलीज़ को रोक देता है।
- एक प्रोडक्शन लूप जोड़ें: उपयोगकर्ताओं का फ़ीडबैक और विफल केस इकट्ठा करें, और उन्हें अपने गोल्डन सेट में जोड़ते रहें।
आम ग़लतियाँ जो मूल्यांकन को बेकार बना देती हैं
- सिर्फ़ हैप्पी पाथ का परीक्षण करना और एज व प्रतिकूल केस को नज़रअंदाज़ करना।
- ऐसा टेस्ट सेट जो बहुत छोटा हो या आपके असली उपयोगकर्ताओं का प्रतिनिधित्व न करता हो।
- LLM जज को मानवीय निर्णय के साथ कैलिब्रेट किए बिना उस पर निर्भर रहना।
- लागत और लेटेंसी को नज़रअंदाज़ करके केवल गुणवत्ता पर ध्यान देना।
- हर अपडेट के साथ इसे एक निरंतर प्रक्रिया बनाने के बजाय लॉन्च पर सिर्फ़ एक बार मूल्यांकन करना।
मूल्य बात करने वाला बॉट लॉन्च करने में नहीं है — बल्कि एक ऐसी प्रणाली रखने में है जो आपको संख्याओं में बताए कि हर बदलाव के बाद वह बेहतर हुआ या बदतर।
मददगार टूल
ऐसे ओपन-सोर्स और व्यावसायिक टूल मौजूद हैं जो मूल्यांकन पाइपलाइन बनाने का रास्ता छोटा करते हैं, जिनमें शामिल हैं: RAG सिस्टम के लिए Ragas और DeepEval; निगरानी और मूल्यांकन के लिए LangSmith, Braintrust और Arize Phoenix; और टेस्ट लिखने के लिए OpenAI Evals और promptfoo। वह टूल चुनें जो आपके स्टैक के अनुकूल हो, लेकिन याद रखें कि टूल से ज़्यादा कार्यप्रणाली मायने रखती है।
Origami की भूमिका
Origami एक टेक्नोलॉजी कंपनी है जो AI सिस्टम बनाती है और उन्हें सौंपने से पहले मापती है: हम आपके क्षेत्र के अनुरूप एक गोल्डन डेटासेट डिज़ाइन करते हैं, डिप्लॉयमेंट से जुड़ी एक स्वचालित मूल्यांकन पाइपलाइन बनाते हैं, और प्रोडक्शन निगरानी जोड़ते हैं जो रिग्रेशन को जल्दी पकड़ती है और लागत को नियंत्रण में रखती है। लक्ष्य ऐसा बॉट है जिसकी संख्याओं पर आप भरोसा कर सकें, सिर्फ़ एक डेमो नहीं।
स्रोत
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023): arxiv.org/abs/2306.05685
- RAG मूल्यांकन मेट्रिक्स (फ़ेथफ़ुलनेस, प्रासंगिकता, कॉन्टेक्स्ट गुणवत्ता) पर Ragas का दस्तावेज़ीकरण: docs.ragas.io
- LangSmith का मूल्यांकन दस्तावेज़ीकरण: docs.smith.langchain.com
- OpenAI Evals: github.com/openai/evals
- मूल्यांकन बनाने पर Anthropic का मार्गदर्शन: docs.anthropic.com
सामान्य प्रश्न
ऑफ़लाइन और ऑनलाइन मूल्यांकन में क्या अंतर है?
ऑफ़लाइन मूल्यांकन हर बदलाव पर बॉट को एक तय गोल्डन डेटासेट पर चलाता है, आदर्श रूप से आपकी CI पाइपलाइन में, ताकि रिलीज़ से पहले ही रिग्रेशन पकड़े जा सकें। ऑनलाइन मूल्यांकन असली उपयोगकर्ताओं पर A/B टेस्ट, फ़ीडबैक बटन और गार्डरेल मेट्रिक्स के ज़रिए होता है। आपको दोनों की ज़रूरत है: ऑफ़लाइन मूल्यांकन लॉन्च से पहले आपकी रक्षा करता है, जबकि ऑनलाइन मूल्यांकन वह उजागर करता है जो केवल असली उपयोग से सामने आता है।
मेरे टेस्ट सेट में कितने उदाहरण होने चाहिए?
हज़ारों बेतरतीब उदाहरणों के बजाय 50 से 100 सोच-समझकर चुने गए उदाहरणों से शुरुआत करें जो आपके सबसे महत्वपूर्ण और सबसे जोखिम भरे परिदृश्यों को कवर करें। एक छोटा, प्रतिनिधि और अच्छी तरह लेबल किया गया सेट एक बड़े और शोर भरे सेट से बेहतर होता है, और समय के साथ आप प्रोडक्शन की असली विफलताओं को जोड़कर इसे बढ़ाते जाते हैं।
क्या मैं किसी AI मॉडल पर ख़ुद का मूल्यांकन करने के लिए भरोसा कर सकता हूँ?
LLM-as-a-judge तेज़, स्केलेबल और व्यापक रूप से इस्तेमाल होता है, लेकिन इसमें पूर्वाग्रह होते हैं (जैसे लंबे उत्तरों को तरजीह देना) और इसे एक सैंपल पर मानवीय निर्णय के साथ कैलिब्रेट करना ज़रूरी है। इसे गुणात्मक आयामों के लिए इस्तेमाल करें, समय-समय पर मानवीय समीक्षा जारी रखें, और जाँचे बिना इसके स्कोर को कभी अंतिम सत्य न मानें।
मुझे किस मेट्रिक से शुरुआत करनी चाहिए?
टास्क की सफलता से, यानी उपयोगकर्ता ने वास्तव में अपना लक्ष्य हासिल किया या नहीं, क्योंकि यह बिज़नेस वैल्यू के सबसे क़रीब है। आपके दस्तावेज़ों पर आधारित सिस्टम (RAG) के लिए हैलुसिनेशन रोकने हेतु फ़ेथफ़ुलनेस जोड़ें, फिर सुरक्षा, लागत और लेटेंसी को शामिल करें।
मुझे कितनी बार दोबारा मूल्यांकन करना चाहिए?
हर अहम बदलाव पर (प्रॉम्प्ट में बदलाव, मॉडल अपग्रेड या नॉलेज बेस अपडेट) और प्रोडक्शन में लगातार। मूल्यांकन लॉन्च से पहले एक बार पार किया जाने वाला पड़ाव नहीं है; यह एक निरंतर प्रक्रिया है जो आपको बताती है कि हर बदलाव से फ़ायदा हुआ या नुक़सान।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








