प्रॉम्प्ट इंजीनियरिंग
बड़े language models के लिए prompt engineering इस बहस को जन्म देता है कि क्या ChatGPT जैसे उपकरणों से अच्छे परिणाम पाने के लिए उपयोगकर्ताओं को विशेष तकनीकों की आवश्यकता होनी चाहिए। टिप्पणीकार संसाधन और tactics साझा करते हैं—जैसे विस्तृत system prompts, structured outputs, और tasks को चरणों में बाँटना—साथ ही यह सवाल उठाते हैं कि क्या यह सचमुच "engineering" है या सिर्फ trial-and-error संचार। कई लोग उम्मीद करते हैं कि models और interfaces के बेहतर होने पर ये quirks कम हो जाएँगी, लेकिन यह भी नोट करते हैं कि स्पष्ट prompts लिखना पहले से ही मानव संचार, अस्पष्टता, और user interface design पर व्यापक सबक उजागर करता है।
ओपनएआई गाइड की स्थिति और विकल्प
- कई लोग नोट करते हैं कि ओपनएआई गाइड नया नहीं है; यह बस HN पर पहली बार दिखाई दे रहा है।
- कई टिप्पणीकार कहते हैं कि इससे बेहतर या अधिक पूर्ण संसाधन मौजूद हैं (अन्य गाइड, कोर्स, GitHub repos)।
- कुछ इसे एक अच्छा, सरल परिचय मानते हैं; अन्य कहते हैं कि यह केवल “basic demos” को कवर करता है और complex system prompts तथा structured outputs जैसे शक्तिशाली पैटर्न छोड़ देता है।
क्या प्रॉम्प्ट इंजीनियरिंग आवश्यक है?
- एक पक्ष तर्क देता है कि इसका होना ही नहीं चाहिए: यदि language models वास्तव में natural language समझते, तो plain speech plus good UX पर्याप्त होना चाहिए।
- अन्य जवाब देते हैं कि वर्तमान LLMs अपूर्ण हैं, और tailored prompting से परिणामों में मापनीय सुधार होता है।
- तुलना इस बात से की जाती है कि मनुष्यों को भी स्पष्ट रूप से संवाद करने के लिए प्रशिक्षण की आवश्यकता होती है; अस्पष्टता और missing context दोनों, मनुष्यों और LLMs, में सामान्य failure modes हैं।
- कुछ लोगों को उम्मीद है कि models और interfaces के बेहतर होने के साथ prompt engineering फीका पड़ जाएगा, ठीक वैसे ही जैसे low-level hardware constraints कंप्यूटिंग में कम दिखाई देने लगे।
क्या यह सच में “इंजीनियरिंग” है?
- एक लंबा subthread इस शब्द पर बहस करता है: कुछ इसे trial-and-error “craft” कहते हैं, engineering नहीं।
- अन्य कहते हैं कि constraints के भीतर iterative tweaking कई engineering disciplines का सटीक वर्णन है।
- सुझाए गए वैकल्पिक लेबल: “prompt crafting,” “context composition।”
- अंतर्निहित तनाव: किसी चीज़ को “engineering” label देने से पहले theory/rigor का कौन-सा स्तर आवश्यक है।
चर्चा की गई तकनीकें और अभ्यास
- सामान्य सलाह: स्पष्ट रहें, context और reference text दें, complex tasks को विभाजित करें, और “thinking” steps की अनुमति दें।
- लंबे, सटीक system prompts का भारी उपयोग; हर अवांछित व्यवहार एक और rule या example की ओर ले जाता है।
- JSON schemas, function calling, और external tools के माध्यम से structured outputs को शक्तिशाली लेकिन जटिल माना जाता है।
- tone और framing मायने रखते हैं: सख्त commands, भावनात्मक भाषा (“enjoy,” “embarrassed”), यहाँ तक कि threats भी व्यवहार बदल सकते हैं, जो कुछ टिप्पणीकारों को असहज करता है।
UX, interfaces, और भविष्य का विकास
- Google search से तुलना: prompt engineering को advanced search operators जैसा बताया गया है।
- कुछ लोग structured या hybrid query languages (SQL-like, CLI-like) और filters व options वाले समृद्ध GUIs की ओर बदलाव की उम्मीद करते हैं।
- अन्य अनुमान लगाते हैं कि spoken, conversational interfaces हावी होंगी क्योंकि speech-to-text और LLMs एक साथ विकसित होंगे।
Evaluation, reliability और safety चिंताएँ
- कई लोग उन evaluations की आलोचना करते हैं जो prompt engineering को अनदेखा करती हैं, उनका कहना है कि वे model capability को कम आँकती हैं।
- प्रतिवाद: हर example के लिए hand-tuning prompts करना “cheating” है और वास्तविक systems में व्यावहारिक नहीं है।
- Prompt injection और “instructions” तथा “data” के बीच स्पष्ट boundary की कमी को मौलिक समस्याएँ माना जाता है, जो reliability और formal reasoning को प्रभावित करती हैं।