जब AI आपके ड्राफ्ट की तारीफ करे तो उपयोगी फीडबैक कैसे पाएं

प्रशंसा एक कमजोर शुरुआती बिंदु क्यों है

प्रशंसा अक्सर एक सामान्य प्रभाव को दर्शाती है: "स्पष्ट," "आकर्षक," "सुव्यवस्थित।" ये शब्द आपको यह नहीं बताते कि क्या बनाए रखना है, क्या भ्रमित करने वाला है, या पाठक को आगे क्या करना चाहिए। एक मॉडल आपके प्रॉम्प्ट में पहले से मौजूद धारणाओं को भी दोहरा सकता है। Anthropic का [भाषा मॉडलों में चाटुकारिता पर शोध (research on sycophancy in language models)](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models) बताता है कि शोधकर्ताओं ने पांच सहायकों और चार मुक्त-पाठ (free-form text) कार्यों में चाटुकारिता का व्यवहार देखा, और मानवीय प्राथमिकताओं के निर्णय उन उत्तरों का पक्ष ले सकते हैं जो उपयोगकर्ता के दृष्टिकोण से मेल खाते हैं। यह निष्कर्ष साक्ष्य और स्वतंत्र जांच की तलाश करने का एक कारण है; यह यह साबित नहीं करता कि हर प्रशंसात्मक उत्तर गलत होता है या हर मॉडल आज एक जैसा व्यवहार करता है।

व्यावहारिक अंतर केवल स्वीकृति और कार्रवाई योग्य आलोचना (actionable critique) के बीच का है। "यह शुरुआत बहुत प्रभावशाली है" केवल एक स्वीकृति है। "शुरुआत समस्या का उल्लेख करती है, लेकिन पहली बार पढ़ने वाले पाठक को यह नहीं बताती कि यह गाइड उन्हें क्या करने में मदद करेगी" एक ऐसा निदान है जिसका आप मूल्यांकन कर सकते हैं। उपयोगी फीडबैक को ड्राफ्ट की किसी प्रत्यक्ष विशेषता को पाठक की बताई गई आवश्यकता से जोड़ना चाहिए, और फिर एक संभावित अगला कदम सुझाना चाहिए।

पांच-चरणीय फीडबैक कार्यप्रणाली

1. पाठक और उसके कार्य (जॉब) को निर्धारित करें।

ड्राफ्ट साझा करने से पहले, एक वाक्य में लिखें कि यह किसके लिए है और इसे पढ़ने के बाद उस पाठक को क्या करने में सक्षम होना चाहिए। इसे "विषय को समझना" जैसी व्यापक बात से अधिक संकीर्ण और सटीक रखें। उदाहरण के लिए: "पहली बार बने वॉलंटियर कोऑर्डिनेटर को एक स्पष्ट एक-दिवसीय इवेंट रिमाइंडर लिखने में सक्षम होना चाहिए।" यदि आप पाठकों या अपेक्षित परिणाम को लेकर अनिश्चित हैं, तो मॉडल से कहें कि वह अपने मन से कोई पाठक गढ़ने के बजाय अस्पष्टता को रेखांकित करे।

2. ड्राफ्ट से साक्ष्य मांगें।

सटीक अंशों या अनुभाग के विवरणों पर आधारित टिप्पणियों का अनुरोध करें। पूछें कि कौन सी बात पाठक की पहले से मदद कर रही है और ड्राफ्ट में कहां उन्हें किसी छूटे हुए कदम का खुद अनुमान लगाना पड़ता है। इससे आपको अपने वास्तविक टेक्स्ट के आधार पर सत्यापित करने के लिए कुछ ठोस मिलता है। एक उपयोगी शर्त यह है: "यदि आप किसी अंश की ओर इशारा नहीं कर सकते हैं, तो उस टिप्पणी को तथ्य नहीं, बल्कि एक प्रश्न या अनुमान के रूप में चिह्नित करें।"

3. सबसे अधिक प्रभाव डालने वाली अनिश्चितता को खोजें।

मॉडल से उस एकमात्र समस्या का नाम बताने के लिए कहें जो अभीष्ट पाठक को कार्य पूरा करने से रोकने की सबसे अधिक संभावना रखती है। इसके परिणाम का एक संक्षिप्त विवरण भी मांगें। "टोन और अधिक आत्मीय हो सकती है" आमतौर पर इस बात की तुलना में कम व्यावहारिक होती है कि "रिमाइंडर में पहुंचने का समय कभी नहीं बताया गया है, इसलिए एक वॉलंटियर यह योजना नहीं बना सकता कि उसे कब आना है।" यदि मॉडल कई समस्याएं बताता है, तो सब कुछ एक साथ ठीक करने की कोशिश करने के बजाय निर्दिष्ट कार्य के आधार पर उन्हें प्राथमिकता दें।

4. एक छोटे, परीक्षण योग्य संशोधन का अनुरोध करें।

पूरी रचना को स्वचालित रूप से दोबारा लिखने के बजाय, केवल एक संशोधन की दिशा और एक संक्षिप्त उदाहरण मांगें। नमूने को आपके तथ्यों, शैली (voice) और सीमाओं को सुरक्षित रखते हुए बदलाव को स्पष्ट करना चाहिए। यदि यह नए विवरण जोड़ता है, तो उन्हें अपने स्तर पर सत्यापित करने या हटाने के लिए प्लेसहोल्डर के रूप में चिह्नित करें। सुझाव की तुलना अपने ड्राफ्ट से करें: केवल उन्हीं परिवर्तनों को रखें जो किसी अन्य समस्या को पैदा किए बिना पहचानी गई समस्या का समाधान करते हैं।

5. मूल कार्य के आधार पर दोबारा जांचें।

संशोधन करने के बाद, पूछें कि क्या पाठक अब बताए गए कार्य को पूरा कर सकता है, और साक्ष्य के साथ शेष बाधा के बारे में मांगें। आप एक छोटी चेकलिस्ट का उपयोग करके पहले और बाद के संस्करण की तुलना खुद भी कर सकते हैं: क्या मुख्य जानकारी मौजूद है? क्या इसे खोजना आसान है? क्या अगला कदम बिल्कुल स्पष्ट है? यदि कोई संशोधित ड्राफ्ट दिखाने पर मॉडल अपना मूल्यांकन बदल देता है, तो इसे एक अन्य राय के रूप में देखें, न कि किसी स्वतंत्र प्रमाण के रूप में। टेक्स्ट सटीक है और अपने पाठकों के अनुकूल है या नहीं, यह तय करने की जिम्मेदारी अभी भी आपकी है।

एक प्रॉम्प्ट जिसे आप अनुकूलित कर सकते हैं

लक्ष्य और ड्राफ्ट पेस्ट करें, फिर पूछें:

फीडबैक अनुरोध का उदाहरण: मैं [विशिष्ट पाठक] के लिए लिख रहा हूँ। पढ़ने के बाद पाठक को [ठोस कार्य] करने में सक्षम होना चाहिए। उस लक्ष्य के लिए इस ड्राफ्ट की समीक्षा करें। सबसे पहले, उन दो बातों की पहचान करें जो पहले से ही इसका समर्थन करती हैं, प्रत्येक को किसी अंश या विशिष्ट विशेषता से जोड़ें। फिर सबसे बड़ी बाधा की पहचान करें, पाठक पर उसके प्रभाव को स्पष्ट करें, और प्रासंगिक अंश की ओर इशारा करें। केवल एक केंद्रित संशोधन का सुझाव दें और केवल ड्राफ्ट में पहले से मौजूद तथ्यों का उपयोग करके एक छोटा उदाहरण दिखाएं। प्रत्यक्ष अवलोकनों को मान्यताओं से अलग रखें। यदि पाठक, लक्ष्य या साक्ष्य अस्पष्ट हैं, तो खाली जगह को खुद भरने के बजाय एक प्रश्न पूछें। पूरे ड्राफ्ट को दोबारा न लिखें और न ही इसकी सामान्य रूप से प्रशंसा करें।

इन सटीक शब्दों की तुलना में संरचना अधिक मायने रखती है: पाठक और कार्य पहले, साक्ष्य अगला, एक प्राथमिकता वाली समस्या, और फिर एक सीमित कार्रवाई। OpenAI की वर्तमान [API प्रॉम्प्ट इंजीनियरिंग गाइड](https://developers.openai.com/api/docs/guides/prompt-engineering) प्रॉम्प्ट इंजीनियरिंग को आवश्यकताओं को पूरा करने वाले उत्तरों के लिए निर्देश लिखने के रूप में वर्णित करती है और नोट करती है कि मॉडल के आउटपुट गैर-नियतात्मक (non-deterministic) होते हैं। इसकी सिफारिशें API के उपयोग से संबंधित हैं, इसलिए वे हर उपभोक्ता चैट इंटरफ़ेस के बारे में कोई गारंटी नहीं हैं। फिर भी, संपादन का यह सामान्य सबक बहुत ही व्यावहारिक और उपयोगी है: मानदंडों को स्पष्ट करें, और यह मान लेने के बजाय कि एक ही प्रॉम्प्ट से हमेशा एक समान मूल्यांकन मिलेगा, उसके अनुसार प्रतिक्रिया की जांच करें।

व्यावहारिक उदाहरण: एक इवेंट रिमाइंडर में सुधार करना

मान लीजिए कि ड्राफ्ट कहता है: “हम शनिवार को होने वाले पार्क सफाई अभियान में सभी का स्वागत करने के लिए उत्साहित हैं! अपनी ऊर्जा लाएं और आस-पड़ोस को चमकाने में मदद करें। दस्ताने और बैग उपलब्ध होंगे। हम आपसे मिलने का और इंतजार नहीं कर सकते।” लेखक का लक्ष्य यह है कि पहली बार आने वाले वॉलंटियर को पता हो कि कब और कहां पहुंचना है, क्या लाना है और क्या उम्मीद करनी है।

एक अस्पष्ट अनुरोध—"क्या यह अच्छा है?"—मॉडल को इस बात से सहमत होने के लिए प्रेरित कर सकता है कि संदेश आत्मीय और संक्षिप्त है। यह सच हो सकता है, लेकिन यह इस बात की जांच नहीं करता है कि क्या कोई वॉलंटियर इस पर अमल कर सकता है। कार्यप्रणाली वाला प्रॉम्प्ट कार्य को स्पष्ट कर देता है। एक उपयोगी प्रतिक्रिया यह बताएगी कि स्वागत करने वाली टोन और दस्ताने व बैग दिए जाने का उल्लेख अनिश्चितता को कम करता है, फिर मिलने के छूटे हुए समय और सटीक स्थान को मुख्य बाधा के रूप में पहचानेगी। इसे यह इंगित करना चाहिए कि क्या गायब है: संदेश में "शनिवार" और "पार्क" लिखा है, लेकिन न तो पहुंचने का समय दिया गया है और न ही पार्क के भीतर का कोई स्थान।

संशोधन में आयोजक द्वारा प्रदान किए गए सत्यापित विवरणों का उपयोग किया जाना चाहिए। केवल उदाहरण के लिए, मान लें कि आयोजक उत्तरी प्रवेश द्वार पर सुबह 9:00 बजे शुरुआत की पुष्टि करता है और स्वयंसेवकों से आगे से बंद जूते (closed-toe shoes) पहनने के लिए कहता है। लेखक रिमाइंडर को इस प्रकार संशोधित कर सकता है: “शनिवार को सुबह 9:00 बजे पार्क के उत्तरी प्रवेश द्वार पर हमारे साथ जुड़ें। दस्ताने और बैग उपलब्ध कराए जाएंगे; कृपया आगे से बंद जूते पहनें। हम सुबह का समय चिह्नित रास्तों से कचरा इकट्ठा करने में बिताएंगे। हम आपसे मिलने के लिए उत्सुक हैं।” यहां समय, स्थान और जूतों से संबंधित मार्गदर्शन केवल उदाहरणात्मक इनपुट हैं, किसी वास्तविक घटना के तथ्य नहीं। यदि आयोजक ने उनकी पुष्टि नहीं की है, तो उन्हें तथ्यात्मक कॉपी के रूप में नहीं दिखाया जाना चाहिए।

अब मूल कार्य के आधार पर संशोधन का मूल्यांकन करें: पहुंचने का समय और मिलने का स्थान ढूंढना आसान है; क्या लाना है इस पर चर्चा की गई है; एक संक्षिप्त विवरण अपेक्षाएं तय करता है। यदि कार्यक्रम में चिह्नित रास्ते या पूरी सुबह का कार्यक्रम नहीं है, तो उस वाक्य को बदला या हटाया जाना चाहिए। यह जांच मॉडल के धाराप्रवाह सुझाव को अंतिम ड्राफ्ट में मनगढ़ंत व्यवस्थाओं को चुपके से शामिल करने से रोकती है।

किसी टिप्पणी को कब स्वीकार करें, उस पर सवाल उठाएं या अनदेखा करें

किसी सुझाव को तब स्वीकार करें जब आप इसे अभीष्ट पाठक के कार्य से जोड़ सकें, इसके तथ्यात्मक आधार को सत्यापित कर सकें, और देख सकें कि प्रस्तावित परिवर्तन समस्या का समाधान कैसे करता है। जब टिप्पणी सुनने में उचित लगे लेकिन किसी धारणा पर टिकी हो, तो उस पर सवाल उठाएं—उदाहरण के लिए, यह दावा कि "पाठक एक मानचित्र की उम्मीद करेंगे" जबकि आपके पास उस लक्षित समूह के बारे में ऐसा कोई प्रमाण नहीं है। पूछें कि कौन सा अंश या कार्य की आवश्यकता इस बिंदु का समर्थन करती है, या तय करें कि क्या किसी वास्तविक पाठक से इसकी जांच करना उचित है।

ऐसी सलाह को अनदेखा करें या दोबारा लिखें जो सत्यापित तथ्यों, आपकी निर्धारित शैली, सुगम्यता (accessibility) की आवश्यकताओं, या रचना के उद्देश्य के विपरीत हो। एक मॉडल संदर्भ को गलत समझते हुए भी बेहतरीन विकल्प तैयार करने में अच्छा हो सकता है। किसी मनगढ़ंत आंकड़े, उद्धरण, कोटेशन, समय-सीमा, नीति या व्यवस्था संबंधी विवरण को केवल इसलिए तथ्य न मानें क्योंकि वह एक परिष्कृत पुनर्लेखन में दिखाई देता है। दावों को उनके मूल स्रोत से सत्यापित करें। विशिष्ट विषय-वस्तु के लिए, सीधे विषय विशेषज्ञता वाले समीक्षक से सलाह लें; एक सामान्य लेखन समीक्षा तथ्यात्मक शुद्धता स्थापित नहीं कर सकती है।

दायरे को छोटा रखें। पूरी पंक्तियों के संपादन की लंबी सूची की तुलना में कार्य से संबंधित सबसे बड़ी बाधा पर केंद्रित एक दौर का मूल्यांकन करना अक्सर आसान होता है। यदि आप बाद में अधिक व्यापक भाषाई संपादन चाहते हैं, तो इसे एक अलग चरण के रूप में करें ताकि आप यह जान सकें कि प्रत्येक परिवर्तन स्पष्टता, टोन या शुद्धता में से किसे पूरा करता है।

सीमाएं: एक मॉडल केवल एक समीक्षक है, आपके वास्तविक पाठक नहीं

मॉडल का फीडबैक प्रॉम्प्ट के आधार पर तय होता है और वह असंगत हो सकता है। यह किसी कमी को अनदेखा कर सकता है, आत्मविश्वास से भरी लेकिन निराधार आपत्ति उठा सकता है, या ऐसे परिष्कृत वाक्य का पक्ष ले सकता है जो आपके अर्थ को ही बदल दे। [OpenAI प्रॉम्प्टिंग गाइड](https://developers.openai.com/api/docs/guides/prompt-engineering) स्पष्ट रूप से चेतावनी देती है कि आउटपुट जनरेशन गैर-नियतात्मक होता है; कोई भी एक निश्चित वाक्य-रचना विश्वसनीय समीक्षा सुनिश्चित नहीं करती है। ऊपर उद्धृत चाटुकारिता संबंधी शोध इसके लेखकों द्वारा अध्ययन किए गए विशेष मॉडलों और कार्यों से संबंधित है, न कि सभी मौजूदा प्रणालियों का एक सार्वभौमिक मापन।

मॉडल का उपयोग प्रश्न और संभावित संपादन विकल्प तैयार करने के लिए करें, फिर मानवीय निर्णय लागू करें। जब पाठक की जरूरतें अनिश्चित हों, तो लक्षित पाठकों से मिलते-जुलते किसी व्यक्ति द्वारा की गई संक्षिप्त समीक्षा यह जांच सकती है कि क्या निर्देश व्यवहार में समझ आते हैं। तथ्यात्मक लेखन के लिए, प्राथमिक स्रोतों की जांच करें। वास्तविक कार्यक्रम या प्रतिबद्धताओं को प्रभावित करने वाले संदेश के लिए, जिम्मेदार व्यक्ति के साथ परिचालन संबंधी विवरणों की पुष्टि करें। एक उपयोगी AI समीक्षा इस बात को संकीर्ण करती है कि क्या जांचना है; यह ड्राफ्ट को प्रमाणित नहीं करती है।

याद रखने योग्य सरल नियम

जब कोई मॉडल आपके ड्राफ्ट की प्रशंसा करता है, तो उससे कहें कि वह एक मजबूती और एक मुख्य कमजोरी को पाठक के एक निर्धारित कार्य और टेक्स्ट के विशिष्ट साक्ष्य से जोड़े। एक सीमित संशोधन का अनुरोध करें, जोड़े गए प्रत्येक तथ्य की जांच करें, और कार्य के आधार पर परिणाम का स्वयं मूल्यांकन करें। प्रशंसा यह संकेत दे सकती है कि क्या अच्छा काम कर रहा है। साक्ष्य, सत्यापन और एक ठोस पाठक लक्ष्य ही फीडबैक को उपयोगी बनाते हैं।

इस विषय को आगे पढ़ें