दृष्टिकोण
प्रॉम्प्ट लेखन एक शिक्षण डिज़ाइन कौशल बनता जा रहा है
उपयोगी प्रॉम्प्ट डिज़ाइन ब्रीफ को स्पष्ट बनाते हैं: प्रदर्शन समस्या, शिक्षार्थी संदर्भ, सीमाएँ, और साक्ष्य जो आपको परिणाम का मूल्यांकन करने में मदद करेगा।
AI से कठिन ग्राहकों को संभालने पर एक पाठ्यक्रम बनाने के लिए कहें, और आपने पहले ही कई डिज़ाइन निर्णय ले लिए हैं।
आपने तय किया है कि पाठ्यक्रम की आवश्यकता है। आपने तय किया है कि समस्या कुछ ऐसा है जिसे लोग अपने तरीके से सीख सकते हैं। आपने तय किया है कि "कठिन ग्राहकों को संभालना" काम को स्पष्ट रूप से वर्णित करता है ताकि इसके चारों ओर निर्माण किया जा सके।
शायद वे निर्णय सही हैं। लेकिन प्रॉम्प्ट हमें उन पर विश्वास करने का ज्यादा कारण नहीं देता।
मुझे लगता है कि यहीं प्रॉम्प्टिंग के बारे में बातचीत लर्निंग डिज़ाइनरों के लिए दिलचस्प हो जाती है। उपयोगी कौशल यह है कि हम यह समझा सकें कि हम क्या सुधारने की कोशिश कर रहे हैं, काम करने वाले लोगों के बारे में हमें क्या पता है, और एक उपयोगी प्रतिक्रिया को पूरा करने के लिए क्या आवश्यक होगा।
एक प्रॉम्प्ट उन निर्णयों को स्पष्ट बनाता है। यदि हम देखने का समय निकालें, तो यह उनकी अनुपस्थिति को भी स्पष्ट कर सकता है।
प्रॉम्प्ट ब्रीफ को उजागर करता है
एक उपयोगी प्रॉम्प्ट एक डिज़ाइन ब्रीफ है जिसे आप प्रश्न पूछ सकते हैं।
यही कारण है कि मैं प्रॉम्प्ट लेखन को लर्निंग डिज़ाइन का हिस्सा बनते हुए देखता हूँ। यह हमें समस्या को परिभाषित करने, सीमाएँ निर्धारित करने, और यह तय करने का एक और स्थान देता है कि क्या अच्छा माना जाता है।
बेहतर शब्दावली एक कमजोर निर्णय को ठीक नहीं कर सकती
हर निराशाजनक AI प्रतिक्रिया को एक शब्दावली समस्या के रूप में देखने का एक प्रलोभन है। एक भूमिका जोड़ें। अधिक विवरण मांगें। स्वर बदलें। इसे अधिक आकर्षक बनाने के लिए कहें। एक लंबा प्रॉम्प्ट आजमाएं।
कभी-कभी वे परिवर्तन मदद करते हैं। लेकिन वे हमें एक ऐसे प्रश्न के उत्तर को पॉलिश करते रहने के लिए भी रख सकते हैं जिसे हमें फिर से विचार करना चाहिए था।
"एक विशेषज्ञ instructional designer के रूप में कार्य करें और एक आकर्षक पांच मिनट का पाठ्यक्रम बनाएं" अभी भी एक पाठ्यक्रम के साथ शुरू होता है। "वयस्क सीखने के सिद्धांतों का उपयोग करें" उस निर्णय को स्पष्ट नहीं करता है जिसे किसी को काम पर लेना चाहिए। "इसे इंटरैक्टिव बनाएं" हमें यह नहीं बताता कि इंटरैक्शन को किसी को क्या अभ्यास करने देना चाहिए।
आप एक अस्पष्ट ब्रीफ से आकर्षक ड्राफ्ट प्राप्त कर सकते हैं। यही समस्या का एक हिस्सा है। एक पूर्ण दिखने वाला उत्तर अधूरे विचारों को पहचानना और भी कठिन बना सकता है।
बेहतर संस्करण मांगने से पहले, पूछें कि आपने मॉडल को क्या अनुमान लगाने के लिए छोड़ा। दर्शक कौन हैं? वे क्या करने के लिए संघर्ष कर रहे हैं? उस व्याख्या का समर्थन करने वाला क्या प्रमाण है? कौन सी जानकारी गायब है? कौन से निर्णय पहले से सहमति में हैं, और कौन से अभी भी खुले हैं?
यदि आप उन सवालों का उत्तर नहीं दे सकते, तो शायद प्रॉम्प्ट में एक और विशेषण इसे हल नहीं करेगा।
इसे वह संदर्भ दें जो डिज़ाइन को बदलता है
"फ्रंटलाइन कर्मचारी" एक दर्शक लेबल है। यह अर्थपूर्ण अभ्यास डिजाइन करने के लिए पर्याप्त संदर्भ नहीं है।
एक नया कर्मचारी जो पहली बार किसी प्रक्रिया को सीख रहा है, उसे एक अनुभवी कर्मचारी से कुछ अलग चाहिए जो प्रक्रिया को जानता है लेकिन ग्राहक बातचीत के दौरान वर्तमान नीति नहीं ढूंढ पा रहा है। दोनों एक ही प्रशिक्षण अनुरोध में दिखाई दे सकते हैं।
उपयोगी विवरण वे हैं जो आपके डिज़ाइन निर्णयों को बदलते हैं: पूर्व अनुभव, उपलब्ध उपकरण, कार्य की स्थिति, समय का दबाव, पहुंच की आवश्यकताएँ, भाषा, और गलती के परिणाम।
सीमाएँ भी उतनी ही महत्वपूर्ण हैं। कार्यों के बीच उपयोग किया जाने वाला मोबाइल अनुभव एक संचालित कार्यशाला से अलग आवश्यकताएँ रखता है। एक निर्णय जो स्मृति से लिया जाना चाहिए, उसे एक खोज योग्य संदर्भ द्वारा समर्थित निर्णय से अलग तैयारी की आवश्यकता होती है।
मैं मॉडल को यह भी बताऊंगा कि उसे क्या नहीं बनाना चाहिए। यदि एक रिफंड नियम प्रदान नहीं किया गया है, तो इसे गायब नियम को चिह्नित करना चाहिए। यदि प्रदर्शन अंतर का कारण अनिश्चित है, तो इसे उस अनिश्चितता को बनाए रखना चाहिए न कि किसी हितधारक की राय को एक निष्कर्ष में बदलना चाहिए।
इसका मतलब यह नहीं है कि आप अपने पास मौजूद हर दस्तावेज़ को एक चैट में चिपका दें। निर्णय से संबंधित सामग्री का चयन करें, उस जानकारी का उपयोग करें जिसे आप साझा करने के लिए अधिकृत हैं, और समझाएं कि कौन से स्रोत उत्तर को नियंत्रित करते हैं।
एक उपयोगी सीमा
"दस्तावेजित तथ्यों, कार्यशील धारणाओं और अनुत्तरित प्रश्नों को अलग करें। नीतियाँ, शिक्षार्थी डेटा, या प्रभाव के प्रमाण न बनाएं।"
वही अनुरोध, एक अलग डिज़ाइन कार्य
यहाँ एक काल्पनिक उदाहरण है। एक ग्राहक सहायता प्रबंधक रिफ्रेशर प्रशिक्षण के लिए पूछता है क्योंकि एजेंट बहुत अधिक रिफंड अनुरोधों को बढ़ा रहे हैं।
त्वरित प्रॉम्प्ट हो सकता है:
"रिफंड अनुरोधों को संभालने पर पांच मिनट का माइक्रोलर्निंग कोर्स बनाएं। तीन ज्ञान जांचें शामिल करें और इसे आकर्षक बनाएं।"
वह प्रॉम्प्ट AI को एक उत्पादन कार्य देता है। यह नहीं पूछता कि क्या कार्य समझ में आता है।
अब कल्पना करें कि नमूना मामलों की समीक्षा से पता चलता है कि एजेंट मूल नीति को समझा सकते हैं, लेकिन जब कोई अपवाद लागू होता है तो हिचकिचाते हैं। उनके पास कॉल के दौरान नीति संदर्भ उपलब्ध है। कुछ मामलों में यह भी दिखाता है कि अपवाद मार्गदर्शन स्पष्ट नहीं है।
यह डिज़ाइन कार्य को बदलता है। हमें निर्णय अभ्यास, एक स्पष्ट संदर्भ, और नीति स्पष्टीकरण की आवश्यकता हो सकती है इससे पहले कि हमें मूल बातें पर रिफ्रेशर की आवश्यकता हो।
एक अधिक उपयोगी प्रॉम्प्ट होगा:
निर्णय के चारों ओर निर्मित एक प्रॉम्प्ट
"मुझे अनुभवी ग्राहक सहायता एजेंटों के बीच अनावश्यक रिफंड बढ़ाने को कम करने के लिए एक अनुरोध की जांच करने में मदद करें।
इस काल्पनिक मामले में, नमूना मामलों की समीक्षा से पता चलता है कि एजेंट मूल रिफंड नीति को जानते हैं लेकिन अपवादों के आसपास हिचकिचाते हैं। वे कॉल के दौरान नीति तक पहुँच सकते हैं। कुछ अपवाद मार्गदर्शन अस्पष्ट हो सकता है। हमने यह स्थापित नहीं किया है कि प्रत्येक कारक वृद्धि में कितना योगदान देता है।
प्रशिक्षण का मसौदा तैयार करने से पहले, संभावित अभ्यास आवश्यकताओं को नीति या संदर्भ समस्याओं से अलग करें। उन प्रश्नों की पहचान करें जिनका हमें उत्तर चाहिए और जो प्रमाण हमें प्रतिक्रिया चुनने में मदद करेगा।
यदि निर्णय अभ्यास उचित है, तो तीन छोटे मामलों का खाका तैयार करें जिनमें एजेंटों को यह चुनना होगा कि वे हल करें, संदर्भ परामर्श करें, या बढ़ाएँ। प्रत्येक मामला एक अलग सीमा का परीक्षण करना चाहिए। समझाएं कि प्रत्येक मामला हमें क्या अवलोकन करने देगा।
उन नीति विवरणों के लिए प्लेसहोल्डर का उपयोग करें जो मैंने प्रदान नहीं किए हैं। रिफंड नियम न बनाएं। किसी भी मामले को चिह्नित करें जिसे नीति निर्णय के बिना नहीं आंका जा सकता। पहले एक निदान तालिका लौटाएं, उसके बाद एक अस्थायी अभ्यास खाका।"
दूसरा प्रॉम्प्ट आउटपुट का वर्णन करने से अधिक करता है। यह यह परिभाषित करता है कि क्या ज्ञात है, क्या अनिश्चित है, और हमें कौन से निर्णय लेने की आवश्यकता है।
यह एक उत्तर की अनुमति भी देता है जिसकी हमें उम्मीद नहीं थी: गतिविधि बनाने से पहले नीति को स्पष्ट करें।
यही डिज़ाइन कार्य है।
उत्तर पढ़ने से पहले मानदंड लिखें
एक प्रॉम्प्ट में डालने के लिए सबसे उपयोगी चीजों में से एक यह है कि आप परिणाम का मूल्यांकन कैसे करेंगे, इसका स्पष्टीकरण।
यदि आप किसी परिदृश्य के लिए पूछ रहे हैं, तो "वास्तविक" को एक परिभाषा की आवश्यकता है। क्या शिक्षार्थी को वास्तविक कार्यप्रवाह में होने वाले निर्णय का सामना करना पड़ता है? क्या उनके पास वास्तव में होने वाली जानकारी है? क्या कमजोर विकल्प चुनने का कोई विश्वसनीय कारण है? क्या फीडबैक एक परिणाम को स्पष्ट करता है या केवल एक स्कोर की घोषणा करता है?
ये प्रश्न आपको यह देखने के लिए कुछ देते हैं कि लेखन कितना विश्वसनीय लगता है।
रिफंड उदाहरण के लिए, मैं यह जांचूंगा कि क्या प्रत्येक मामला एक विशिष्ट निर्णय सीमा का परीक्षण करता है, क्या सही प्रतिक्रिया अनुमोदित नीति का पालन करती है, और क्या फीडबैक बताता है कि परामर्श या वृद्धि कब उपयुक्त है। मैं यह भी जांचूंगा कि परिदृश्य किसी एजेंट को उस अस्पष्टता के लिए दंडित नहीं करता है जिसे संगठन ने हल करने में विफलता दिखाई है।
आप AI से उन मानदंडों के खिलाफ अपने मसौदे की समीक्षा करने के लिए कह सकते हैं। यह समस्याओं को उजागर कर सकता है। यह स्वतंत्र मान्यता नहीं है, और यह यह स्थापित नहीं करता है कि नीति सही है या कि अभ्यास प्रदर्शन में सुधार करेगा।
आपको अभी भी स्रोतों की जांच करने, उन लोगों को शामिल करने की आवश्यकता है जो काम को जानते हैं, और जहां संभव हो, लक्षित उपयोगकर्ताओं के साथ अनुभव को आजमाना है।
मॉडल आपको एक मानक लागू करने में मदद कर सकता है। आप यह तय करने के लिए जिम्मेदार रहते हैं कि क्या कार्य उस पर खरा उतरता है।
संरचना का पुन: उपयोग करें, निर्णयों पर दोबारा गौर करें
मुझे पुन: प्रयोज्य संरचनाएँ पसंद हैं। वे हमें फिर से शुरू करने से बचाते हैं और हमें उन प्रश्नों को पूछने की याद दिलाते हैं जिन्हें हम अन्यथा छोड़ सकते हैं।
लेकिन एक सहेजा गया प्रॉम्प्ट आज के प्रोजेक्ट में कल की धारणाओं को भी ले जा सकता है। एक टेम्पलेट जो हमेशा पाठ्यक्रम की रूपरेखा के लिए पूछता है, चुपचाप हर समस्या को पाठ्यक्रम समस्या की तरह दिखाता है।
संरचना जिसे मैं पुन: उपयोग करना चाहूंगा, वह एक संक्षिप्त डिज़ाइन ब्रीफ है:
- प्रदर्शन: किसी को क्या करना, निर्णय लेना या पुनः प्राप्त करना है?
- साक्ष्य: हमें वर्तमान समस्या के बारे में क्या पता है, और क्या अभी भी एक धारण है?
- संदर्भ: कौन काम कर रहा है, किस स्थिति में, और किन उपकरणों या समर्थन के साथ?
- सीमाएँ: कौन से आवश्यकताएँ प्रतिक्रिया का सम्मान करना चाहिए? कौन से स्रोत इसे नियंत्रित करते हैं?
- डिज़ाइन कार्य: क्या हम निदान कर रहे हैं, प्रतिक्रियाओं की तुलना कर रहे हैं, अभ्यास का मसौदा तैयार कर रहे हैं, या मौजूदा समाधान की समीक्षा कर रहे हैं?
- गुणवत्ता मानदंड: क्या चीज़ परिणाम को इस स्थिति के लिए उपयोगी, सटीक और उपयुक्त बनाएगी?
- अनिश्चितता: क्या चीज़ों को झंडा उठाना चाहिए, प्रश्न करना चाहिए, या अनुमान लगाने के बजाय अनसुलझा छोड़ देना चाहिए?
आपको हर छोटे अनुरोध को एक विशाल प्रॉम्प्ट में नहीं बदलना चाहिए। कार्य के लिए संक्षिप्त को मिलाएं। एक वाक्य को फिर से लिखने के लिए प्रदर्शन समस्या के लिए प्रतिक्रिया की सिफारिश करने की तुलना में कम संदर्भ की आवश्यकता होती है।
बड़े प्रोजेक्ट के लिए, चरणों में काम करें। अनुरोध की जांच करें, साक्ष्य की समीक्षा करें, संभावित प्रतिक्रियाओं की तुलना करें, फिर उस भाग का मसौदा तैयार करें जिसके लिए आपके पास डिज़ाइन करने के लिए पर्याप्त जानकारी है। सहमत निर्णयों को आगे बढ़ाएं और जब नया साक्ष्य तस्वीर को बदलता है तो उन्हें फिर से देखें।
लक्ष्य यह है कि तर्क को समीक्षा के लिए उपलब्ध रखा जाए, बजाय इसके कि इसे एक परिष्कृत अंतिम आउटपुट के अंदर दफन कर दिया जाए।
काम का मूल्यांकन चैट विंडो के परे करें
एक मजबूत प्रॉम्प्ट अधिक प्रासंगिक मसौदा उत्पन्न कर सकता है। इसका मतलब यह नहीं है कि हमने सीखने में सुधार किया है।
मसौदा अभी भी काम के संपर्क में जीवित रहना चाहिए। क्या लोग स्थिति को समझ सकते हैं? क्या वे जब उन्हें आवश्यकता हो तो समर्थन का उपयोग कर सकते हैं? क्या अभ्यास उन निर्णयों को उजागर करता है जो हमारे लिए महत्वपूर्ण हैं? क्या फीडबैक उन्हें सुधारने में मदद करता है?
हमारे काल्पनिक रिफंड उदाहरण में, कम वृद्धि अपने आप में पर्याप्त नहीं होगी। एजेंट उन अनुरोधों को मंजूरी देकर वृद्धि को कम कर सकते हैं जिन्हें उन्हें संदर्भित करना चाहिए था। हमें निर्णयों की उपयुक्तता के साथ-साथ वृद्धि दर की भी जांच करनी होगी।
यह एक और डिज़ाइन निर्णय है जिसे प्रॉम्प्ट हमारे लिए तय नहीं कर सकता। हम तय करते हैं कि कौन सा साक्ष्य महत्वपूर्ण है और हम कौन से व्यापारिक समझौतों को स्वीकार करेंगे।
मैं प्रॉम्प्ट लेखन को करियर की गारंटी के रूप में नहीं देखता। यह किसी को अद्वितीय नहीं बनाता, और चतुर प्रॉम्प्ट का संग्रह सीखने या लोगों के काम को समझने का विकल्प नहीं है।
मैं इसे एक व्यावहारिक कौशल के रूप में देखता हूँ जो हमारे विचारों को निरीक्षणीय बनाता है। यह हमें इरादे को व्यक्त करने, अनिश्चितता को नामित करने, और उत्तर मांगने से पहले मानक को परिभाषित करने के लिए मजबूर करता है।
इसे अगले प्रॉम्प्ट के साथ आजमाएं जिसे आप उपयोग करने वाले थे। हर निर्णय को रेखांकित करें जो आपने पहले ही लिया है। हर विवरण को गोल करें जिसे मॉडल को अनुमान लगाना होगा। फिर पूछें कि क्या उन निर्णयों का समर्थन किया गया है।
आपको एक बेहतर प्रॉम्प्ट की आवश्यकता हो सकती है। आपको एक बेहतर संक्षिप्त की आवश्यकता हो सकती है। आपको एक प्रश्न के साथ हितधारक के पास वापस जाने की आवश्यकता हो सकती है जिसे आपने पूछने के लिए नहीं सोचा था।
प्रॉम्प्ट लेखन तब सीखने के डिज़ाइन में अपनी जगह अर्जित करता है जब यह हमें यह तय करने में मदद करता है कि लोगों को क्या आवश्यकता है।
Learning Rewired Lab™
प्रतिक्रिया उत्पन्न करने से पहले संक्षिप्त को मजबूत करें।
The Lab एक संपूर्ण पेशेवर कार्यक्षेत्र है जो एक शिक्षण अनुरोध को एक ठोस प्रदर्शन समाधान में बदलता है। अनुरोध को चुनौती दें, प्रणाली की जांच करें, प्रतिक्रिया डिज़ाइन करें, और एक जुड़े हुए प्रोजेक्ट में सबूत की योजना बनाएं।
अनुरोध को चुनौती दें, प्रणाली की जांच करें, और उत्पादन शुरू होने से पहले प्रदर्शन के लिए डिज़ाइन करें।
- एक जुड़े हुए प्रोजेक्ट रिकॉर्ड
- अनुरोध और प्रदर्शन निदान
- उत्पाद-उन्मुख शिक्षण उपकरण
- AI-सहायता प्राप्त डिज़ाइन कार्यप्रवाह
- व्यावहारिक कार्यस्थल अनुप्रयोग