क्या आपके साथ कभी ऐसा हुआ है कि कोई प्रॉम्प्ट अच्छा काम कर रहा हो और फिर अचानक काम करना बंद कर दे?
क्या आप कभी नतीजे सुधारने के लिए अपने सिस्टम प्रॉम्प्ट में लगातार बदलाव करते रहे हैं, लेकिन कुछ भी कारगर नहीं हुआ?
सिस्टम प्रॉम्प्ट लर्निंग ठीक वही हो सकती है जिसकी आपको आवश्यकता है.
सिस्टम प्रॉम्प्ट लर्निंग (SPL) एआई समुदाय में रुचि का एक उभरता क्षेत्र है और मई में आंद्रेज कारपैथी ने X पर इसे व्यापक रूप से लोकप्रिय बनाया.
सिस्टम प्रॉम्प्ट लर्निंग उन अनम्य और नाज़ुक एआई प्रणालियों की सीमाओं को दूर करती है जो स्थिर सिस्टम प्रॉम्प्ट या जटिल फ़ाइन-ट्यूनिंग व्यवस्थाओं पर निर्भर हैं. यह एआई प्रणालियों में निरंतर सीखने को संभव बनाने का एक और तरीका देती है.
विस्तार में जाने से पहले, आइए प्रॉम्प्ट से जुड़ी कुछ बुनियादी बातें संक्षेप में समझें.
एजेंट या कस्टम मॉडल बनाते समय हमें सबसे पहले दो प्रमुख घटक तैयार करने होते हैं:
एक सिस्टम प्रॉम्प्ट
एक उपयोगकर्ता प्रॉम्प्ट
सिस्टम प्रॉम्प्ट किसी मॉडल के व्यवहार के बुनियादी नियम तय करते हैं. कस्टम एआई समाधानों के लिए लिखे जाने पर वे अक्सर कुछ इस तरह शुरू होते हैं:
“आप एक बुद्धिमान सहायक हैं. आपकी भूमिका <कार्य यहाँ डालें> को पूरा करना है.
आपको (A), (B) या (C) नहीं करना चाहिए.”
इसके विपरीत, उपयोगकर्ता प्रॉम्प्ट में आम तौर पर उपयोगकर्ता का प्रश्न और समय क्षेत्र तथा प्राथमिकताओं जैसी अन्य प्रासंगिक जानकारी होती है. उपयोगकर्ता प्रॉम्प्ट कुछ ऐसा हो सकता है:
मैं पुर्तगाल की राजधानी में हूँ. क्या आप आज रात करने के लिए कुछ गतिविधियाँ सुझा सकते हैं?
प्रमुख एआई प्रयोगशालाओं के नए मॉडल जारी होने के बाद सिस्टम प्रॉम्प्ट का लीक होना आम हो गया है, क्योंकि उपयोगकर्ता चैटबॉट को जेलब्रेक करके उनके मूल निर्देश उजागर कर देते हैं. अब एक लोकप्रिय GitHub रिपॉज़िटरी इनमें से कई सिस्टम प्रॉम्प्ट एक ही स्थान पर संकलित करती है. वे उस “खास नुस्खे” को उजागर करते हैं जिसे एआई प्रयोगशालाओं ने उपयुक्त मॉडल व्यवहार को बढ़ावा देने के लिए समय के साथ विकसित किया है. उदाहरण के लिए, हाल में लीक हुए GPT-5 सिस्टम प्रॉम्प्ट (जो ChatGPT में उजागर हुआ) में लगभग 6,000 शब्द हैं. इससे पता चलता है कि प्रणाली के व्यवहार को आकार देने के लिए कितना ज्ञान और मार्गदर्शन समाहित करना पड़ता है.
इन विस्तृत सिस्टम प्रॉम्प्ट में आम तौर पर कई प्रमुख क्षेत्र शामिल होते हैं, जैसे:
खोज संबंधी निर्देश
टूल की परिभाषाएँ
उपयोगकर्ता की प्राथमिकताएँ
उद्धरण संबंधी निर्देश
ज्ञात समस्याओं के त्वरित समाधान
व्यवहार में, कस्टम एआई प्रणालियों के डेवलपर अपने अनुप्रयोगों की जाँच और सुधार करते समय सिस्टम प्रॉम्प्ट में बार-बार मैन्युअल बदलाव करते हैं. इस सुधार प्रक्रिया का मार्गदर्शन मुख्यतः मूल्यांकनों से होता है.
मॉडल के व्यवहार को निर्देशित करने के अन्य तरीकों में शामिल हैं:
प्रॉम्प्ट इंजीनियरिंग, जिसमें पुनर्प्राप्ति-संवर्धित सृजन (RAG) भी शामिल है और जो मॉडल को दी जाने वाली सामग्री नियंत्रित करती है
फ़ाइन-ट्यूनिंग (मॉडल के अंतर्निहित भारों को सीधे बदलना)
अगर मॉडल के व्यवहार को प्रभावित करने का कोई और तरीका हो तो? ऐसी प्रणाली की कल्पना करें जो पहले तैयार किए गए विचारों, योजनाओं और रणनीतियों से सीखकर अपने सिस्टम प्रॉम्प्ट को गतिशील रूप से सुधारती हो. यह अपने आउटपुट का आकलन करने के लिए उपयोगकर्ता की प्रतिक्रिया और LLM-निर्णायक मूल्यांकन, दोनों का उपयोग कर सकती है.
ऐसी लगातार बनी रहने वाली व्यावसायिक चुनौती पर विचार करें जिसे आप एजेंट-आधारित प्रणाली से स्वचालित करना चाहते हैं. प्रभावी समाधानों के लिए सामान्य कार्यप्रवाह स्वचालन से आगे की रीज़निंग क्षमताएँ आवश्यक हैं. ऐसे मामलों में अपनी एआई प्रणाली में योजना बनाने वाला घटक शामिल करना आवश्यक हो जाता है. इससे प्रणाली कार्य के अनुसार कई एजेंट के साथ अलग-अलग तरीकों से काम कर सकती है. अलग-अलग चरणों में उपकार्य पूरे करने के लिए अन्य एजेंट तक पहुँचने या टूल का उपयोग करने के निर्देश शामिल हो सकते हैं.
ध्यान दें: एजेंट का टूल कोई भी बाहरी फ़ंक्शन, API या संसाधन होता है जिसे एआई एजेंट केवल पाठ से आगे बढ़कर वास्तविक कार्रवाई करने के लिए बुला सकता है.
आप मॉडल के सिस्टम प्रॉम्प्ट में मनुष्य द्वारा अपनाए जाने वाले तार्किक चरणों वाली योजना को शुरुआती आधार के रूप में शामिल कर सकते हैं. हालाँकि, LLM को आम तौर पर टूल के उपयोग, आउटपुट के प्रारूप और संबंधित आवश्यकताओं पर अधिक विशिष्ट मार्गदर्शन चाहिए होता है. कभी-कभी सर्वोत्तम रणनीति स्पष्ट नहीं होती या आप ऐसी समस्या हल कर रहे होते हैं जिसका दोबारा आकलन नहीं किया गया, क्योंकि उसे पहले ही हल मान लिया गया था. यहीं सिस्टम प्रॉम्प्ट लर्निंग (SPL) काम आती है.
SPL पहले बनाई गई रणनीतियाँ शामिल करके सिस्टम प्रॉम्प्ट को बार-बार सुधारती है. नई समस्याएँ सामने आने पर प्रणाली धीरे-धीरे ज्ञान संचित करती है और अधिक सुदृढ़ बनती जाती है. इसे अपने क्षेत्र की समस्याएँ हल करने की मार्गदर्शिका बनाने जैसा समझें.
SPL उपयोगकर्ता की प्रतिक्रिया से मिली समझ को धीरे-धीरे सिस्टम प्रॉम्प्ट में शामिल करती है. प्रणाली के परिपक्व होने पर आपको बार-बार आने वाली ऐसी समस्याएँ मिल सकती हैं जिन्हें अधिक सामान्य और उच्च-स्तरीय सिद्धांतों में बदला जा सकता है.
आइए चरण-दर-चरण समझें कि यह प्रक्रिया कैसे काम करती है:
उपयोगकर्ता के प्रश्न से शुरुआत करें और प्रणाली से कोई विशिष्ट कार्य करने को कहें.
यदि आपकी प्रणाली केवल एक समस्या हल करती है, तो आप पिछले प्रयासों की सर्वाधिक अंक वाली रणनीतियाँ चुनकर “लालची” तरीका अपना सकते हैं. इसके बजाय, आप ऐसे वितरण से नमूने लेकर खोज को बढ़ावा दे सकते हैं जो ऊँची रेटिंग वाली रणनीतियों को प्राथमिकता दे, लेकिन कभी-कभी कम रेटिंग वाली रणनीतियाँ भी शामिल करे. जब आप रणनीतियाँ एकत्र करना शुरू ही कर रहे हों, तब यह विशेष रूप से उपयोगी है.
विविध समस्याएँ हल करने के लिए बनी प्रणालियों में प्रासंगिक तरीके पहचानने हेतु वर्गीकरण परत जोड़ने या एम्बेडिंग और कोसाइन समानता का उपयोग करने पर विचार करें. आम तौर पर RAG में भी इन्हीं तकनीकों का उपयोग होता है. इससे आप विशिष्ट समस्या के अनुकूल रणनीतियाँ चुन सकते हैं, जैसे कोडिंग कार्यों के लिए तैयार रणनीतियाँ.
ध्यान दें: एम्बेडिंग का कोसाइन समानता के साथ उपयोग हमें यह मापने देता है कि दो जानकारियाँ कितनी निकटता से संबंधित हैं. इससे दस्तावेज़ों, प्रश्नों या विचारों का मिलान आसान होता है, भले ही उनके शब्द बिल्कुल अलग हों.
कोडिंग समस्याएँ हल करने वाले सरल रणनीति संग्रह का शुरुआती उदाहरण.
ध्यान दें: यहाँ दिखाई गई “आरंभिक रणनीतियाँ” केवल उदाहरण हैं. वास्तविक कोडिंग स्थितियों में हम इन्हें और सुधारेंगे. विशिष्ट व्यावसायिक समस्याओं के लिए समय के साथ अतिरिक्त जानकारी एकत्र करनी होगी.
Generation_id (उल्टा क्रम) | विषय | अंक | Strategy_text | व्याख्या |
|---|---|---|---|---|
4 | कोडिंग | 1 | समस्या, बाधाओं और असामान्य स्थितियों को समझें. उचित डेटा संरचनाओं के साथ एल्गोरिदम तैयार करें. उदाहरणों और अपरिवर्तनीय नियमों पर योजना की पुष्टि करें. साफ़ और पढ़ने योग्य कोड लिखें. पुनर्गठन, अनुकूलन और अंतिम प्रारूपण से इसे सुधारें. टूल का उपयोग: टूल का उपयोग करते समय संक्षेप में बताएँ कि इसकी आवश्यकता क्यों पड़ी. | नीचे दी गई तीन रणनीतियों के सबसे प्रभावी तत्वों को शामिल करके मिलाता है. |
3 | कोडिंग | 1 | समस्या, बाधाओं और असामान्य स्थितियों को समझें. उचित डेटा संरचनाओं के साथ एल्गोरिदम तैयार करें. उदाहरणों और अपरिवर्तनीय नियमों पर योजना की पुष्टि करें. साफ़ और पढ़ने योग्य कोड लिखें. पुनर्गठन, अनुकूलन और अंतिम प्रारूपण से इसे सुधारें. | यह अधिक संतुलित रणनीति है, लेकिन इसमें टूल के उपयोग का कोई मार्गदर्शन नहीं है. |
2 | कोडिंग | -1 | समस्या, बाधाओं और असामान्य स्थितियों को समझें. उचित डेटा के साथ एल्गोरिदम तैयार करें. साफ़ और पढ़ने योग्य कोड लिखें. टूल का उपयोग: टूल तक पहुँचते समय इसका संक्षिप्त सारांश दें कि आपने उस टूल का उपयोग क्यों किया. | टूल के उपयोग का उल्लेख करने वाली बेहतर रणनीति, लेकिन इसमें अब भी सुधार हो सकता है. |
1 | कोडिंग | -1 | समस्या पर सरसरी नज़र डालें. समस्या हल करें. न्यूनतम परीक्षण बनाएँ. जो भी चल जाए, उसे जमा कर दें. | परीक्षणों का उल्लेख करती है, लेकिन कुल मिलाकर यह कमज़ोर रणनीति है. |
3. N का नमूना लेने के बाद उन्हें सिस्टम प्रॉम्प्ट में शामिल करें. इससे योजना निर्माण पहले मिले विशेषज्ञों के सुझावों पर आधारित होता है और मॉडल को बहुत कम मार्गदर्शन के साथ योजनाएँ बनाने के लिए नहीं छोड़ा जाता. मॉडल को नमूना रणनीतियों की हूबहू नकल करने के बजाय “कुछ हटकर सोचने” और आवश्यकता पड़ने पर चरण जोड़ने के लिए प्रोत्साहित करें.
4. गतिशील रूप से बनाए गए अपने सिस्टम प्रॉम्प्ट से उपयोगकर्ता के अनुरोध को पूरा करने के लिए नई रणनीति तैयार करें. इस प्रक्रिया से ऐसे अतिरिक्त कार्य बनने चाहिए जो अंतिम आउटपुट को बेहतर बनाएँ. लक्ष्य रचनात्मकता है: पिछली रणनीतियों के सबसे प्रभावी तत्व मिलाएँ, एक जैसे चरणों को समेकित करें और जहाँ आवश्यक हो वहाँ उपयोगी नए चरण जोड़ें.
ध्यान दें: याद रखें कि तापमान एक ऐसा पैरामीटर है जिसे अधिक विविध और कम नियतात्मक आउटपुट के लिए समायोजित किया जा सकता है. रचनात्मकता की आवश्यकता होने पर यह उपयोगी है. तापमान शून्य से अधिक होने पर बनाई गई हर योजना अलग हो सकती है.
5. मॉडल का आउटपुट मिलने के बाद, मानव मूल्यांकनकर्ता या LLM निर्णायक की मदद से उन विशिष्ट मानदंडों के आधार पर उसका मूल्यांकन करें जो आपकी समस्या के अच्छे समाधान को परिभाषित करते हैं. पहले बताए गए पुर्तगाल की गतिविधियों वाले उदाहरण के मूल्यांकन मानदंडों में ये शामिल हो सकते हैं:
संक्षिप्तता (उत्तर केवल एक वाक्य तक सीमित हो)
सुझाई गई गतिविधि की प्रासंगिकता
स्थान की सटीकता
6. इस मूल्यांकन के आधार पर किसी अन्य मॉडल की मदद से रणनीति सुधारें. वैकल्पिक प्रतिक्रिया चक्र में मानवीय सुझाव शामिल करके सहयोगात्मक सुधार संभव किए जा सकते हैं. संस्करणों और बदलावों पर नज़र रखने के लिए सुधारी गई रणनीति को उपयुक्त मेटाडेटा के साथ अपने डेटाबेस में सहेजें.
तो इतनी मेहनत क्यों की जाए? आप आउटपुट की मैन्युअल समीक्षा करके सिस्टम प्रॉम्प्ट को उसके अनुसार समायोजित कर सकते हैं. हालाँकि, शक्तिशाली रीज़निंग मॉडल आउटपुट के संदर्भ और मानवीय प्रतिक्रिया, दोनों की मदद से रणनीतियाँ सुधार सकते हैं. मनुष्य सरल तरीकों की खामियाँ आसानी से पहचान सकते हैं, लेकिन व्यापक समस्याएँ हल करने वाली जटिल प्रणालियों में उन्हें पहचानना कठिन और थकाऊ हो जाता है.
LLM को अक्सर वह संदर्भगत ज्ञान जुटाने के लिए विस्तृत निर्देश और अतिरिक्त चरण चाहिए होते हैं जिसे मनुष्य स्वाभाविक रूप से किसी समस्या में साथ लाते हैं. व्यापक समस्याओं को हल करने के लिए प्रणाली का विस्तार होने पर आवश्यक कार्यों की संख्या तेज़ी से बढ़ सकती है. उदाहरण के लिए, कोडिंग समस्याएँ हल करने वाले मनुष्य आसपास के कोडबेस को सहज रूप से समझ सकते हैं, जबकि LLM को पहले कई फ़ाइलें “पढ़नी” पड़ सकती हैं.
यह कब उपयोगी है: मान लें कि आप ग्राहक सहायता टीम चलाते हैं और एक एआई एजेंट टिकटों की प्राथमिक छँटाई करता है. समय के साथ SPL वर्गीकरण का ऐसा तरीका खोज सकती है जिस पर आपकी टीम ने विचार न किया हो, जिससे उच्च स्तर पर भेजे जाने वाले मामलों की दर घट सकती है.
यह कब उपयोगी नहीं है: यदि अनुपालन आवश्यकताओं या नियमों ने पहले ही वित्तीय रिपोर्टिंग जैसे आपके कार्यप्रवाह तय कर दिए हैं, तो SPL बहुत कम लाभ दे सकती है क्योंकि वहाँ रचनात्मकता उपयोगी होने के बजाय जोखिम बन जाती है.
यह कब उपयोगी है: शोध-प्रधान भूमिकाओं में, जैसे बाज़ार आसूचना या उत्पाद रणनीति, आप एआई की योजनाएँ सुधारकर, उसके आउटपुट को समृद्ध बनाकर और इन सुधारों को भविष्य के उपयोग में शामिल करके उसके साथ सहयोग कर सकते हैं. हर संवाद प्रणाली की प्रभावशीलता बढ़ाता है.
यह कब उपयोगी नहीं है: यदि आपकी टीम एआई का उपयोग मुख्यतः ऐसे सरल कार्यप्रवाहों के लिए करती है जिनमें मानवीय योगदान बहुत कम है, जैसे चालान संसाधन, तो सहयोग का अतिरिक्त बोझ लाभ से अधिक हो सकता है.
यह कब उपयोगी है: मान लें कि आप किसी नए क्षेत्र में विस्तार करते हैं और एआई को अचानक स्थानीय कर संबंधी प्रश्न सँभालने पड़ते हैं. SPL नए नियमों और व्यावहारिक उपायों के सामने आते ही उन्हें शीघ्रता से समाहित करने देती है, जिससे बार-बार होने वाली गलतियाँ रुकती हैं.
यह कब उपयोगी नहीं है: यदि आपका परिवेश स्थिर है, जैसे बैठक की प्रतिलिपियों को मानकीकृत सारांशों में बदलना, तो निरंतर अनुकूलन से बहुत कम लाभ मिलता है.
सैद्धांतिक रूप से यह सब आशाजनक लगता है, लेकिन SPL लागू करने में वास्तविक चुनौतियाँ आती हैं. इनमें से कुछ प्रमुख चुनौतियों पर नीचे चर्चा की गई है:
रणनीति बनाने के शुरुआती चरणों में प्रगति अक्सर रुक जाती है: नए आउटपुट पिछले आउटपुट पर आगे नहीं बढ़ते और गति धीमी हो जाती है. आमतौर पर इसके दो मुख्य कारण होते हैं:
समाधान: उपलब्ध समस्त व्यावसायिक ज्ञान पहले ही समाहित कर दें, ताकि प्रणाली के पास उपयोग करने के लिए पर्याप्त गहराई हो.
समाधान: ऐसी सूक्ष्म मूल्यांकन-सारणी बनाएँ जो उत्तर की सटीकता, स्पष्टता और प्रासंगिकता जैसे कई पहलुओं को अंक दे, और इन संकेतों के अनुसार नमूना-चयन समायोजित करें.
यदि आपकी प्रणाली सैकड़ों रणनीतियाँ बनाती है, लेकिन अच्छी और खराब रणनीतियों में अंतर करने के लिए बहुत कम प्रतिक्रिया मिलती है, तो नमूना-चयन शीघ्र ही कठिन हो जाता है. इसका उत्तर है छँटाई.
अपने रणनीति संग्रह को सुधारते समय इन बातों पर विचार करें:
उपयोग-अवधि: तय समय-सीमा या सृजन की निर्धारित संख्या पार करने पर रणनीतियों को हटा दें.
अंक: लगातार खराब प्रदर्शन करने वाली रणनीतियों को हटाने के लिए अपनी मूल्यांकन-सारणी का उपयोग करें. इसे उपयोग-अवधि के साथ जोड़ने से सुनिश्चित होता है कि आप केवल उन्हीं तरीकों को रख रहे हैं जो समय के साथ अपनी उपयोगिता सिद्ध करते हैं.
LLM द्वारा निर्णय: समय-समय पर रणनीतियों का आकलन करके ऐसी रणनीतियाँ पहचानें जो अब कोई अनूठी जानकारी नहीं देतीं, क्योंकि उनके उपयोगी तत्व संभवतः नए संस्करणों में पहले ही समाहित हो चुके हैं.
समाधान: अपने रणनीति डेटाबेस को एक जीवंत प्रणाली मानें और उसकी नियमित छँटाई करें, ताकि केवल प्रासंगिक और उच्च-मूल्य वाला ज्ञान ही बना रहे.
सिस्टम प्रॉम्प्ट लर्निंग अभी शुरुआती अवस्था में है, लेकिन इसकी संभावनाएँ अपार हैं. केवल स्थिर प्रॉम्प्ट या अंतहीन फ़ाइन-ट्यूनिंग पर निर्भर व्यवसायों को जानी-पहचानी सीमाओं का सामना करना पड़ेगा: नाज़ुक प्रणालियाँ, बढ़ती लागत और व्यर्थ प्रयास. SPL समय के साथ बेहतर होने वाली और अलग-अलग तात्कालिक सुधारों के बजाय उच्च-स्तरीय सिद्धांत समाहित करने वाली प्रणालियाँ बनाकर इस चक्र से बाहर निकलने का रास्ता देती है.
SPL अभी उभर रही है, लेकिन इसकी दिशा स्पष्ट है: जो प्रणालियाँ स्वयं से सीख सकती हैं, वे ऐसा न कर सकने वाली प्रणालियों से आगे निकल जाएँगी. अब प्रयोग करने, छोटे स्तर से शुरू करने, सीख दर्ज करने और हर संवाद के साथ बेहतर होने वाली एआई प्रणालियों की नींव बनाने का समय है.