असली ऐप्लिकेशन के लिए प्रॉम्प्ट बनाते समय, एक अहम समझौता करना पड़ता है: कम शब्दों में ज़्यादा जानकारी देना. जब सभी फ़ैक्टर एक जैसे हों, तो कम शब्दों वाला प्रॉम्प्ट, ज़्यादा शब्दों वाले प्रॉम्प्ट की तुलना में ज़्यादा तेज़ी से काम करता है. साथ ही, यह सस्ता होता है और इसका रखरखाव करना भी आसान होता है. यह वेब एनवायरमेंट में खास तौर पर काम आता है, जहां लेटेन्सी और टोकन की सीमाएं मायने रखती हैं. हालांकि, अगर आपका प्रॉम्प्ट बहुत छोटा है, तो मॉडल के पास कॉन्टेक्स्ट, निर्देश या उदाहरण नहीं होंगे. इस वजह से, वह अच्छी क्वालिटी के नतीजे नहीं दे पाएगा.
इवैलुएशन-ड्रिवन डेवलपमेंट (ईडीडी) की मदद से, इस ट्रेड-ऑफ़ को व्यवस्थित तरीके से मॉनिटर और ऑप्टिमाइज़ किया जा सकता है. यह एक ऐसी प्रोसेस है जिसे बार-बार दोहराया जा सकता है और जिसकी जांच की जा सकती है. इससे छोटे और भरोसेमंद चरणों में आउटपुट को बेहतर बनाया जा सकता है, रिग्रेशन का पता लगाया जा सकता है, और समय के साथ मॉडल के व्यवहार को उपयोगकर्ता और प्रॉडक्ट की उम्मीदों के मुताबिक बनाया जा सकता है.
इसे टेस्ट-ड्रिवन डेवलपमेंट (टीडीडी) के तौर पर समझें. इसे एआई की अनिश्चितता के हिसाब से बनाया गया है. डिटरमिनिस्टिक यूनिट टेस्ट के उलट, एआई के आकलन को हार्ड-कोड नहीं किया जा सकता. ऐसा इसलिए, क्योंकि आउटपुट, सही फ़ॉर्मैट वाले और फ़ेल होने वाले, दोनों ही अनचाहे फ़ॉर्म में हो सकते हैं.
ईडीडी, प्रॉडक्ट को खोजने में भी आपकी मदद करता है. जैसे, लिखने से जुड़े टेस्ट से किसी सुविधा के काम करने के तरीके के बारे में साफ़ तौर पर पता चलता है. इसी तरह, आकलन के मानदंड तय करने और मॉडल के आउटपुट की समीक्षा करने से, आपको किसी काम के बारे में साफ़ तौर पर जानकारी न होने की समस्या का सामना करना पड़ता है. साथ ही, आपको धीरे-धीरे उस काम के बारे में ज़्यादा जानकारी और स्ट्रक्चर जोड़ना पड़ता है.
उपयोगकर्ताओं की ज़रूरतों को समझना, टोन और शब्दों का सही इस्तेमाल करना, और मॉडल को एक क्रिएटिव सहयोगी के तौर पर इस्तेमाल करना ज़रूरी है. इससे ऐसे बेहतर प्रॉम्प्ट और सुविधाएं बनाई जा सकती हैं जो उपयोगकर्ताओं की ज़रूरतों के मुताबिक हों.समस्या के बारे में जानकारी देना
अपनी समस्या को एपीआई अनुबंध की तरह फ़्रेम किया जा सकता है. इसमें इनपुट टाइप, आउटपुट फ़ॉर्मैट, और अन्य पाबंदियां शामिल होती हैं. उदाहरण के लिए:
- इनपुट टाइप: ब्लॉग पोस्ट का ड्राफ़्ट
- आउटपुट फ़ॉर्मैट: JSON फ़ॉर्मैट में कलेक्शन, जिसमें पोस्ट के तीन टाइटल शामिल हों
- पाबंदियां: 128 से कम वर्ण, दोस्ताना लहज़े में जवाब देना है
इसके बाद, उदाहरण के तौर पर इनपुट इकट्ठा करें. डेटा में विविधता लाने के लिए, आपको आदर्श उदाहरणों के साथ-साथ असली और गड़बड़ इनपुट भी शामिल करने होंगे. अलग-अलग वर्शन और मुश्किल मामलों के बारे में सोचें. जैसे, इमोजी वाली पोस्ट, नेस्ट किया गया स्ट्रक्चर, और बहुत सारे कोड स्निपेट.
बेसलाइन शुरू करना
अपना पहला प्रॉम्प्ट लिखें. ज़ीरो-शॉट से शुरुआत की जा सकती है. इसमें ये शामिल हैं:
- निर्देश हटाएं
- आउटपुट फ़ॉर्मैट
- इनपुट वैरिएबल के लिए प्लेसहोल्डर
आकलन और ऑप्टिमाइज़ेशन करते समय, आपको जटिलता बढ़ानी होती है. साथ ही, अन्य कॉम्पोनेंट और बेहतर प्रॉम्प्टिंग तकनीकों का इस्तेमाल करना होता है. सबसे पहले, हमें एक आकलन सिस्टम सेट अप करना होगा, ताकि ऑप्टिमाइज़ेशन के काम को सही दिशा में ले जाया जा सके.
इवैल्यूएशन सिस्टम बनाना
टीडीडी में, ज़रूरी शर्तें पता होने के बाद टेस्ट लिखना शुरू किया जाता है. जनरेटिव एआई के साथ, जांच करने के लिए कोई तय आउटपुट नहीं होते. इसलिए, आपको अपने आकलन लूप को तैयार करने में ज़्यादा मेहनत करनी होगी.
आपको बेहतर तरीके से आकलन करने के लिए, कई मेज़रमेंट टूल की ज़रूरत पड़ सकती है.
आकलन की मेट्रिक तय करना
इवैलुएशन मेट्रिक, डिटरमिनिस्टिक हो सकती हैं. उदाहरण के लिए, यह जांच की जा सकती है कि मॉडल, मान्य JSON फ़ाइल देता है या आइटम की सही संख्या दिखाता है.
हालांकि, आपको ज़्यादातर समय ऐसी मेट्रिक की पहचान करने और उन्हें बेहतर बनाने में लगाना चाहिए जो व्यक्तिपरक या गुणात्मक होती हैं. जैसे, आसानी से समझ आना, काम की होना, टोन या क्रिएटिविटी. ऐसा हो सकता है कि आपने सामान्य लक्ष्यों से शुरुआत की हो, लेकिन आपको जल्द ही ज़्यादा बारीकी से जुड़ी समस्याएं दिखें.
उदाहरण के लिए, मान लें कि आपका टाइटल जनरेटर कुछ वाक्यांशों या पैटर्न का बहुत ज़्यादा इस्तेमाल करता है. इससे, बार-बार एक जैसे और रोबोटिक नतीजे मिलते हैं. ऐसे में, आपको नई मेट्रिक तय करनी होंगी, ताकि अलग-अलग स्ट्रक्चर और कीवर्ड इस्तेमाल किए जा सकें. साथ ही, बार-बार इस्तेमाल किए जाने वाले स्ट्रक्चर या कीवर्ड को हतोत्साहित किया जा सके. समय के साथ, आपकी मुख्य मेट्रिक स्थिर हो जाएंगी और आपको उनमें हुए सुधारों का पता चल जाएगा.
इस प्रोसेस में, ऐसे विशेषज्ञों से मदद मिल सकती है जिन्हें आपके ऐप्लिकेशन के डोमेन में अच्छे की जानकारी हो. साथ ही, वे गड़बड़ी के छोटे-मोटे मोड का पता लगा सकें. उदाहरण के लिए, अगर आपको लिखने में मदद करने वाला कोई टूल बनाना है, तो कॉन्टेंट बनाने वाले व्यक्ति या एडिटर के साथ मिलकर काम करें. इससे यह पक्का किया जा सकेगा कि आपका आकलन, उनके नज़रिए के मुताबिक हो.
जज चुनें
आकलन के अलग-अलग मानदंडों के लिए, अलग-अलग परीक्षक होने चाहिए:
- कोड के आधार पर जांच करने की सुविधा, नियम के आधार पर तय किए गए आउटपुट के लिए बेहतर तरीके से काम करती है. उदाहरण के लिए, आपको ऐसे शब्दों के लिए टाइटल स्कैन करने पड़ सकते हैं जिनका इस्तेमाल नहीं करना है. इसके अलावा, वर्णों की संख्या की जांच करनी पड़ सकती है या JSON स्ट्रक्चर की पुष्टि करनी पड़ सकती है. ये तेज़ होते हैं और इन्हें दोहराया जा सकता है. साथ ही, ये बटन या फ़ॉर्म फ़ील्ड जैसे फ़िक्स्ड-आउटपुट वाले यूज़र इंटरफ़ेस (यूआई) एलिमेंट के लिए सबसे सही होते हैं.
- लोगों से मिले सुझाव, ज़्यादा व्यक्तिपरक क्वालिटी का आकलन करने के लिए ज़रूरी हैं. जैसे, टोन, स्पष्टता या काम का होना. खास तौर पर, शुरुआती दौर में मॉडल के आउटपुट की समीक्षा खुद (या डोमेन के विशेषज्ञों के साथ) करने से, मॉडल को तेज़ी से बेहतर बनाया जा सकता है. हालांकि, इस तरीके से बड़े पैमाने पर काम नहीं किया जा सकता. ऐप्लिकेशन लॉन्च करने के बाद, स्टार रेटिंग जैसे इन-ऐप्लिकेशन सिग्नल भी इकट्ठा किए जा सकते हैं. हालांकि, ये सिग्नल सटीक ऑप्टिमाइज़ेशन के लिए ज़रूरी बारीकियों से रहित होते हैं.
- LLM-as-judge की मदद से, किसी दूसरे एआई मॉडल का इस्तेमाल करके, विषय के हिसाब से तय किए गए मानदंडों का आकलन किया जा सकता है. इसके लिए, आउटपुट को स्कोर किया जाता है या उसकी आलोचना की जाती है. यह मैन्युअल तरीके से की जाने वाली समीक्षा की तुलना में ज़्यादा तेज़ है. हालांकि, इसमें कुछ कमियां भी हैं: अगर इसे सही तरीके से लागू नहीं किया जाता है, तो यह मॉडल के पूर्वाग्रहों और जानकारी की कमियों को बनाए रख सकता है.
ज़्यादा वीडियो बनाने के बजाय, अच्छे वीडियो बनाएं. क्लासिक मशीन लर्निंग और अनुमान लगाने वाले एआई में, डेटा एनोटेशन के लिए क्राउडसोर्सिंग का इस्तेमाल करना आम बात है. जनरेटिव एआई के लिए, क्राउडसोर्सिंग करने वाले एनोटेटर के पास अक्सर डोमेन के कॉन्टेक्स्ट की जानकारी नहीं होती. स्केल से ज़्यादा, कॉन्टेक्स्ट के हिसाब से उच्च क्वालिटी वाले आकलन का महत्व है.
आकलन करना और ऑप्टिमाइज़ करना
प्रॉम्प्ट को जितनी जल्दी टेस्ट और बेहतर बनाया जाएगा, उतनी ही जल्दी आपको ऐसा जवाब मिलेगा जो लोगों की उम्मीदों के मुताबिक हो. आपको लगातार ऑप्टिमाइज़ करने की आदत डालनी होगी. बेहतर बनाने की कोशिश करें, उसका आकलन करें, और कुछ और आज़माएँ.
प्रोडक्शन में आने के बाद, अपने उपयोगकर्ताओं और एआई सिस्टम के व्यवहार को मॉनिटर और उसका आकलन करते रहें. इसके बाद, इस डेटा का विश्लेषण करें और इसे ऑप्टिमाइज़ेशन के चरणों में बदलें.
अपने-आप चलने वाली मूल्यांकन पाइपलाइन सेट अप करना
ऑप्टिमाइज़ेशन के काम को आसान बनाने के लिए, आपको ऐसे ऑपरेशनल इन्फ़्रास्ट्रक्चर की ज़रूरत होती है जो परफ़ॉर्मेंस का आकलन अपने-आप करता हो, बदलावों को ट्रैक करता हो, और डेवलपमेंट को प्रोडक्शन से जोड़ता हो. इसे आम तौर पर LLMOps कहा जाता है. ऑटोमेशन में मदद करने वाले कई प्लैटफ़ॉर्म उपलब्ध हैं. हालांकि, तीसरे पक्ष के किसी समाधान का इस्तेमाल करने से पहले, आपको अपने हिसाब से वर्कफ़्लो डिज़ाइन करना चाहिए.
यहां कुछ मुख्य कॉम्पोनेंट दिए गए हैं:
- वर्शनिंग: वर्शन कंट्रोल में स्टोर प्रॉम्प्ट, आकलन मेट्रिक, और टेस्ट इनपुट सेव करें. इन्हें कोड के तौर पर इस्तेमाल करें, ताकि इन्हें फिर से बनाया जा सके और बदलाव के इतिहास की जानकारी साफ़ तौर पर मिल सके.
- बैच के हिसाब से अपने-आप होने वाले आकलन: हर प्रॉम्प्ट अपडेट पर आकलन करने और तुलना रिपोर्ट जनरेट करने के लिए, वर्कफ़्लो (जैसे, GitHub Actions) का इस्तेमाल करें.
- प्रॉम्प्ट के लिए सीआई/सीडी: ऑटोमेटेड जांच के साथ डिप्लॉयमेंट को गेट करें. जैसे, डेर्मिनिस्टिक टेस्ट, एलएलएम-एज़-जज स्कोर या गार्डरेल. साथ ही, क्वालिटी कम होने पर मर्ज करने की प्रोसेस को रोकें.
- प्रोडक्शन लॉगिंग और ऑब्ज़र्वेबिलिटी: इनपुट, आउटपुट, गड़बड़ियां, इंतज़ार का समय, और टोकन के इस्तेमाल की जानकारी कैप्चर करें. डेटा में बदलाव, अचानक दिखने वाले पैटर्न या गड़बड़ियों में बढ़ोतरी पर नज़र रखें.
- सुझाव/राय/शिकायत पाना: उपयोगकर्ता के सिग्नल (पसंद करना, फिर से लिखना, छोड़ना) इकट्ठा करें और बार-बार होने वाली समस्याओं को नए टेस्ट केस में बदलें.
- एक्सपेरिमेंट ट्रैकिंग: प्रॉम्प्ट वर्शन, मॉडल कॉन्फ़िगरेशन, और आकलन के नतीजों को ट्रैक करें.
छोटे और टारगेट किए गए बदलावों को दोहराना
प्रॉम्प्ट को बेहतर बनाने की सुविधा, आम तौर पर आपके प्रॉम्प्ट की भाषा को बेहतर बनाने से शुरू होती है. इसका मतलब है कि निर्देशों को ज़्यादा सटीक बनाना, मकसद को साफ़ तौर पर बताना या अस्पष्टता को दूर करना.
ध्यान रखें कि मॉडल में ज़रूरत से ज़्यादा फ़िटिंग न हो. मॉडल की समस्याओं को ठीक करने के लिए, बहुत कम नियमों को जोड़ना एक आम गलती है. उदाहरण के लिए, अगर आपका टाइटल जनरेटर ऐसे टाइटल जनरेट करता रहता है जो The Definitive Guide से शुरू होते हैं, तो इस वाक्यांश को साफ़ तौर पर इस्तेमाल करने से रोकना सही हो सकता है. इसके बजाय, समस्या को सामान्य बनाएं और ऊपर के लेवल के निर्देश को अडजस्ट करें. इसका मतलब यह हो सकता है कि आपने ओरिजनैलिटी, विविधता या किसी खास संपादकीय शैली पर ज़ोर दिया हो, ताकि मॉडल किसी एक अपवाद के बजाय, आपकी पसंद को समझ सके.
इसके अलावा, प्रॉम्प्ट देने के अलग-अलग तरीकों को आज़माकर और इन तरीकों को एक साथ इस्तेमाल करके भी बेहतर नतीजे पाए जा सकते हैं. कोई तकनीक चुनते समय, खुद से यह सवाल पूछें: क्या इस टास्क को समानता (कुछ उदाहरण), सिलसिलेवार तरीके से तर्क (चेन ऑफ़ थॉट) या बार-बार सुधार (सेल्फ़-रिफ़्लेक्शन) के ज़रिए सबसे अच्छी तरह से हल किया जा सकता है?
जब आपका सिस्टम प्रोडक्शन में जाता है, तो आपके ईडीडी फ़्लायव्हील की स्पीड कम नहीं होनी चाहिए. अगर कुछ हो, तो उसे तेज़ करना चाहिए. अगर आपका सिस्टम, उपयोगकर्ता के इनपुट को प्रोसेस और लॉग करता है, तो ये आपके लिए अहम जानकारी का सबसे अहम सोर्स होने चाहिए. अपनी मूल्यांकन सुइट में बार-बार होने वाले पैटर्न जोड़ें. साथ ही, लगातार सबसे अच्छे ऑप्टिमाइज़ेशन चरणों की पहचान करें और उन्हें लागू करें.
आपके लिए अहम जानकारी
आकलन के आधार पर प्रॉम्प्ट डेवलप करने से, आपको एआई की अनिश्चितता को व्यवस्थित तरीके से समझने में मदद मिलती है. अपनी समस्या को साफ़ तौर पर बताने, ज़रूरत के मुताबिक मूल्यांकन प्रणाली बनाने, और छोटे-छोटे सुधारों को बार-बार लागू करने से, आपको एक ऐसा फ़ीडबैक लूप बनाने में मदद मिलती है जिससे मॉडल के आउटपुट में लगातार सुधार होता है.
संसाधन
अगर आपको LLM-as-judge को लागू करना है, तो यहां कुछ लेख दिए गए हैं जिन्हें पढ़ने का सुझाव दिया जाता है:
- एलएलएम की क्षमता की तुलना, जवाब को छोटा करने की सुविधा से करना.
- एलएलएम को जज के तौर पर इस्तेमाल करने के बारे में, हमेल हुसैन की गाइड पढ़ें.
- यह पेपर पढ़ें: A Survey on LLM-as-a-Judge.
अगर आपको अपने प्रॉम्प्ट को और बेहतर बनाना है, तो कॉन्टेक्स्ट के हिसाब से डेवलपमेंट के बारे में ज़्यादा पढ़ें. यह काम, मशीन लर्निंग इंजीनियर सबसे अच्छी तरह से कर सकता है.
देखें कि आपको कितना समझ आया
इवैलुएशन-ड्रिवन डेवलपमेंट का मुख्य लक्ष्य क्या है?
क्लाइंट-साइड सिस्टम का आकलन करने के लिए, बड़े मॉडल का इस्तेमाल क्यों किया जाता है?
जज के तौर पर एलएलएम का इस्तेमाल करके आकलन करने में क्या समस्या आ सकती है?
सुझाई गई अपने-आप होने वाली समीक्षा की पाइपलाइन का हिस्सा कौनसी कॉम्पोनेंट है?
अपने आकलन सिस्टम के लिए जजों को चुनते समय, मैन्युअल तरीके से मिले सुझाव/राय देने या शिकायत करने की सुविधा का इस्तेमाल करने की मुख्य सीमा क्या है?