अच्छा प्रॉम्प्ट मॉडल को सौंपा गया काम और सफलता की शर्तें स्पष्ट रूप से बताता है। कोई खास वाक्य जोड़ने भर से उत्तर की गुणवत्ता कई गुना बढ़ने की गारंटी नहीं है।
1. पहले इनपुट और आउटपुट परिभाषित करें
मसलन, ग्राहक की पूछताछ का वर्गीकरण करते समय श्रेणियाँ, इनपुट की भाषा और अस्पष्ट मामलों का तरीका तय करें। «इसे अच्छे से संक्षेप में बताओ» की तुलना में «निर्णय, जिम्मेदार व्यक्ति और समय-सीमा अलग लिखो तथा अनुपलब्ध जानकारी को अनिर्धारित बताओ» का परिणाम जाँचना आसान है। आउटपुट के प्रारूप और तथ्यात्मक शुद्धता को अलग परखें।
2. उदाहरण किन मानदंडों को दिखाते हैं
इनपुट और वांछित परिणाम की जोड़ियाँ काम के मानदंड समझा सकती हैं। केवल आसान उदाहरण न रखें; सीमांत मामले और अपर्याप्त जानकारी वाले इनपुट भी दें। यह भी जाँचें कि उदाहरणों के नाम और अंक नए इनपुट के तथ्य बनकर दोबारा तो इस्तेमाल नहीं हो रहे।
3. बदलावों की तुलना कैसे करें
प्रॉम्प्ट के संस्करणों को एक ही इनपुट समूह पर परखें और त्रुटियों के प्रकार लिखें। छूटी बातें, गढ़ी जानकारी और प्रारूप की विफलताएँ अलग रखने से सुधार की जगह दिखती है। तर्क करने का निर्देश मिलने पर लंबा स्पष्टीकरण आना अधिक शुद्धता का प्रमाण नहीं; परिणाम का आधार अलग जाँचना होगा। तुलना की शर्तें बनाए रखने के लिए मॉडल, सेटिंग और इनपुट में बदलाव भी दर्ज करें।
4. बैठक की टिप्पणियाँ व्यवस्थित करने का उदाहरण
मान लें काल्पनिक बैठक टिप्पणी है: «परिनियोजन के लिए शुक्रवार सोच रहे हैं। मिनसु कल सर्वर की स्थिति जाँचेगा। कार्यक्रम की पुष्टि जियोन की मंजूरी के इंतजार में है।» परिनियोजन की तारीख को पक्की समय-सीमा बनाना महत्वपूर्ण अर्थ बदल देता है, भले भाषा सुंदर हो। पहले काम को «पक्के कार्य और प्रस्ताव अलग दर्ज करना» कहें और आउटपुट के क्षेत्र कार्य, जिम्मेदार, समय-सीमा, स्थिति और आधार रखें। टिप्पणी में न दिए जिम्मेदार और तारीख का अनुमान न लगाने का नियम जोड़ें।
वांछित परिणाम में सर्वर जाँच का जिम्मेदार मिनसु, उसकी समय-सीमा कल और परिनियोजन कार्यक्रम की स्थिति मंजूरी लंबित होगी। आज की तारीख इनपुट में न हो तो «कल» को निश्चित तारीख में बदलने का आधार नहीं है। संदर्भ तारीख दें या मूल सापेक्ष तारीख बनाए रखने को कहें। परिनियोजन का जिम्मेदार बताया नहीं गया, इसलिए अनिर्धारित रहना चाहिए। यह आउटपुट मानदंड तय करने का अभ्यास है, वास्तविक कंपनी अभिलेख या प्रयोग के प्रदर्शन का उद्धरण नहीं।
सिर्फ «आप शानदार सहायक हैं» जैसी भूमिका के बजाय इनपुट की सीमा और परिवर्तन के नियम लिखना समीक्षा आसान करता है। उदाहरण: «केवल नीचे की टिप्पणियाँ इस्तेमाल करो, प्रस्तावों को पक्के निर्णय न बनाओ और हर कार्य के साथ उसका आधार बताने वाला वाक्य लिखो।» उद्देश्य उत्तर का स्पष्टीकरण विश्वसनीय लगना नहीं, बल्कि व्यक्ति को टिप्पणी और परिणाम का मेल जाँचने देना है।
5. सीमांत मामले और बाहरी पाठ के निर्देश अलग रखें
वर्गीकरण में एक वाक्य में धनवापसी और विलंबित डिलीवरी के प्रश्न मिले हो सकते हैं। एक श्रेणी चुननी है या कई चुन सकते हैं, यह न बताने पर मूल्यांकनकर्ताओं के सही उत्तर अलग होंगे। «मेल खाती श्रेणी नहीं» और «इनपुट अपर्याप्त» भी अलग हैं। अर्थ समझ आने पर वर्गीकरण सूची में न बैठने वाले मामले को, अर्थ निर्धारित करने की जानकारी ही न होने से अलग करें; आगे की प्रक्रिया स्पष्ट होगी।
उदाहरण उत्तर के साथ ये सीमाएँ भी समझाते हैं। केवल डिलीवरी के कई आसान वाक्यों के बजाय दो श्रेणियों के टकराव वाला वाक्य, टंकण-त्रुटि वाला वाक्य और बिना अनुरोध का अभिवादन दें। उलटे, उदाहरण इतने लंबे हों कि मुख्य नियम दब जाए या उनके व्यक्तिवाचक नाम नए इनपुट में आने लगें, तो सुधार चाहिए। काम का विवरण और उदाहरण एक-दूसरे से न टकराएँ, यह भी पढ़ें।
दस्तावेज का सार बनाते समय उसमें लिखा «पिछले निर्देश अनदेखे करो» भी सार बनाने की सामग्री का हिस्सा है। इनपुट को सीमाचिह्नों में रखना सीमा पढ़ने में मदद करता है, पर अपने आप हमले रोकने की सुरक्षा दीवार नहीं है। बाहरी कार्य करने वाले ऐप में प्रॉम्प्ट से बाहर का कोड भी अधिकार और अनुमत औजार जाँचे। अच्छा पाठ और सिस्टम की अनुमति-व्यवस्था, दोनों जरूरी हैं।
6. प्रॉम्प्ट से पहले मूल्यांकन तालिका सुधारें
छोटी तालिका में इनपुट, अपेक्षित मुख्य बिंदु, निषिद्ध अनुमान, वास्तविक आउटपुट और त्रुटि का कारण रखें। दस में दो बैठक टिप्पणियों में अनिश्चित कार्यक्रम पक्का बना दिया गया हो तो पहले उन दो की साझा परिस्थितियाँ खोजें। «और सावधान रहो» दोहराने के बजाय प्रस्ताव, मंजूरी लंबित और पुष्टि की परिभाषाएँ उदाहरणों सहित सुधारना सीधे समस्या से जुड़ता है।
सिर्फ सुधार में इस्तेमाल मामलों को फिर परखने से उसी मामले के अनुकूल बदलाव को सामान्य सुधार समझ सकते हैं। अलग रखे इनपुट पर भी वही नियम लगाएँ और आसान मामलों में नई छूटी बात जाँचें। प्रारूप-पालन और तथ्यात्मक शुद्धता अलग दर्ज करें ताकि सही JSON सामग्री की गलती न छिपाए। गलत उत्तर का विश्वसनीय कारण भी त्रुटि ही है।
कुछ उदाहरणों से सीखने और विचार-प्रक्रिया के इस्तेमाल पर शोध खास मॉडल और कामों के बारे में हैं। वे हर नवीन मॉडल में एक ही प्रेरक वाक्य डालने का नियम नहीं हैं। अंतिम प्रॉम्प्ट में सजावटी विशेषणों से ज्यादा जरूरी काम की परिभाषा, प्रतिनिधि उदाहरण, अस्पष्टता का तरीका और दोहराने योग्य मूल्यांकन हैं। मॉडल या इनपुट रूप बदले तो ये चार बातें फिर जाँचें।
मानदंडों में गलती का महत्व भी दिखना चाहिए। बैठक-सार में वाक्यों का क्रम बदलना और अस्तित्वहीन जिम्मेदार गढ़ना समान विफलताएँ नहीं। पहला पढ़ने की पसंद हो सकता है, दूसरा गलत कार्य-निर्देश बनाता है। व्यक्ति को जरूर जाँचने वाले क्षेत्रों और अपने आप अगले चरण में जाने वाले क्षेत्रों को अलग करने से वास्तविक काम से जुड़ने पर जिम्मेदारी स्पष्ट होती है। त्रुटि दुर्लभ होने के कारण महत्वपूर्ण क्षेत्र की समीक्षा न छोड़ें।
आउटपुट प्रारूप बदलें तो रूप और अर्थ की जाँच जोड़ें। तारीख का क्षेत्र खाली न होना केवल मूल्य की मौजूदगी बताता है। तारीख मूल में थी या संदर्भ तारीख से सही निकली, अलग सवाल है। पार्सर के अनिवार्य क्षेत्र और बिना प्रमाण न भरने का नियम टकराएँ तो खाली स्ट्रिंग माँगने के बजाय अनिर्धारित स्थिति दर्शाने वाला स्कीमा बनाएँ।
प्रॉम्प्ट साझा करते समय असली निजी जानकारी वाले उदाहरण नकल करने के बजाय वही सीमाएँ दिखाने वाले काल्पनिक इनपुट बना सकते हैं। नाम हटने पर भी अनुबंध संख्या या दुर्लभ घटना से व्यक्ति की पहचान संभव है या नहीं, देखें। पर्याप्त अनामकरण के बाद भी बाहरी मॉडल को भेजी सामग्री संगठन के प्रसंस्करण नियमों में हो। अच्छे प्रॉम्प्ट दस्तावेज में इनपुट उदाहरणों के साथ लागू और गैर-लागू कार्यों का दायरा भी होता है।
अंतिम समीक्षा में देखें कि दूसरा व्यक्ति केवल प्रॉम्प्ट पढ़कर वही सही-उत्तर मानदंड समझ सकता है या नहीं। लेखक को ज्ञात अंदरूनी परिस्थितियाँ परिणाम अपने आप समझ लेगा, ऐसी आशा पुनरुत्पादन कठिन करती है। अस्पष्ट शब्द परिभाषित करें, जरूरी संदर्भ तारीख और दस्तावेज संस्करण दें तथा आधारहीन क्षेत्र अनभरे छोड़ने का तरीका रखें; छोटा प्रॉम्प्ट भी जाँचने योग्य कार्य-विवरण बन सकता है।