येथे कोणताही जादूचा मंत्र नाही. कोणतीही गुप्त कमांड मोठ्या लँग्वेज मॉडेलला (LLM) भविष्यवेत्ता बनवू शकणार नाही, आणि कोणताही गुप्त प्रीफिक्स Claude ला तुमच्या व्यवसायाबद्दल तुमच्यापेक्षा अधिक चांगली समज देऊ शकणार नाही. प्रॉम्प्ट इंजिनिअरिंग म्हणजे कोणताही कोड क्रॅक करणे नव्हे. हे एका अत्यंत सक्षम सहकाऱ्याशी स्पष्टपणे संवाद साधण्याचे कौशल्य आहे, ज्याने इंटरनेटचा अफाट भाग वाचला आहे, परंतु तो तुम्हाला कधीही भेटलेला नाही, तुमचे कार्यालय पाहिलेले नाही किंवा तुमच्या उत्पादनाबद्दल ऐकलेले नाही. Claude कडे त्यांच्या पहिल्या दिवशीचा एक हुशार नवीन कर्मचारी म्हणून वागा. ते मदत करण्यास उत्सुक असतात, परंतु जर तुम्ही अस्पष्ट सूचना दिल्या, तर तुम्हाला अस्पष्ट निकालच मिळतील. कोणत्याही कार्यालयातील नियमाप्रमाणेच येथेही एक नियम लागू होतो: चुकीची माहिती दिली तर चुकीचेच निकाल मिळतील (garbage in, garbage out).

Claude कडे एका नवीन कर्मचाऱ्याप्रमाणे वागा

कल्पना करा की तुम्ही एका प्रतिभावान कंत्राटदाराला कामावर घेत आहात. तुम्ही पहिल्याच दिवशी त्यांच्याकडे जाऊन "वेबसाइट दुरुस्त करा," असे म्हणून निघून जाणार नाही. ती सूचना निरुपयोगी आहे. कोणते पेज? काय बिघडले आहे? प्रेक्षक कोण आहेत? यश म्हणजे काय? तरीही लोक दररोज AI साठी "वेबसाइट दुरुस्त करा" यासारख्या सूचना टाईप करतात आणि आउटपुट अपेक्षित नसल्यास आश्चर्य मानतात.

Claude ला तुमच्या विशिष्ट परिस्थितीबद्दल काहीही माहिती नाही असे गृहीत धरून सुरुवात करा. त्याला व्याकरण, कोडिंग पॅटर्न आणि इतिहास माहित आहे, परंतु जोपर्यंत तुम्ही स्पष्टपणे सांगत नाही, तोपर्यंत त्याला तुमच्या कंपनीची टोन (tone), तुमच्या ग्राहकांच्या समस्या किंवा तुमच्या कायदेशीर मर्यादा माहित नसतात. चांगले प्रॉम्प्टिंग म्हणजे केवळ चांगले व्यवस्थापन आहे. तुम्ही मर्यादा ठरवत आहात, प्रेक्षक निश्चित करत आहात आणि अपेक्षित निकाल स्पष्ट करत आहात. हे तुम्ही व्यवस्थित केले, तर मॉडेलचे विद्यमान ज्ञान अचानक उपयुक्त ठरते.

एका ठोस प्रॉम्प्टचे पाच भाग

प्रत्येक व्यावसायिक प्रॉम्प्टमध्ये पाच विशिष्ट घटक असणे आवश्यक आहे. प्रत्येक घटकासाठी तुम्हाला निबंध लिहिण्याची गरज नाही, परंतु 'एंटर' दाबण्यापूर्वी तुम्ही त्या सर्वांचा उल्लेख केला पाहिजे.

भूमिका (Role)
मॉडेलला सांगा की ते कोण आहे. यामुळे शब्दसंग्रह, दृष्टिकोन आणि प्राधान्य ठरते. "तुम्ही एक तांत्रिक संपादक आहात" हे काम करेल, परंतु "तुम्ही एक तांत्रिक संपादक आहात जो ब्लॉकचेनमध्ये नवीन असलेल्या फिनटेक डेव्हलपर्ससाठी API डॉक्युमेंटेशन सोपे करतो" हे अधिक प्रभावी ठरेल. पर्सोना (persona) जितका विशिष्ट असेल, तितके उत्तर अधिक अचूक असेल.

संदर्भ (Context)
परिस्थिती स्पष्ट करा. हे कोण वाचणार आहे? ध्येय काय आहे? रुग्णालयातील प्रशासकांसाठी लिहिलेला सायबर सुरक्षा विषयावरील ब्लॉग पोस्ट, किशोरवयीन गेमर्ससाठी लिहिलेल्या पोस्टपेक्षा पूर्णपणे वेगळी वाटली पाहिजे. संदर्भात जोखमीचाही (stakes) समावेश होतो. तुम्ही फक्त कल्पना सुचवत आहात की हा अंतिम मसुदा आहे जो थेट प्रसिद्ध केला जाणार आहे?

कार्य (Task)
अचूक क्रियापदे वापरा. "सुधारणे" (improve), "वाढवणे" (enhance) किंवा "अधिक चांगले करणे" (make better) यांसारखे संदिग्ध शब्द टाळा. त्यांचा काहीही अर्थ निघत नाही. त्याऐवजी असे लिहा: "ट्रान्सक्रिप्टचा सारांश २० शब्दांपेक्षा कमी असलेल्या तीन बुलेट पॉइंट्समध्ये लिहा." किंवा: "async/await वापरण्यासाठी हे फंक्शन रिफॅक्टर करा आणि टाइमआउटसाठी एरर हँडलिंग जोडा." कार्य ही तुमची आज्ञा आहे, त्यामुळे ती केवळ इच्छा न राहता एक स्पष्ट आदेश असावी.

स्वरूप (Format)
Claude लिहिण्यास सुरुवात करण्यापूर्वी उत्तराचे स्वरूप निश्चित करा. तुम्हाला क्रमांकांची यादी हवी आहे, markdown टेबल हवे आहे, वैध JSON हवे आहे, विषय ओळीसह ईमेल हवा आहे की कायदेशीर सारांश? जर तुम्हाला विशिष्ट कॉलम्ससह तुलनात्मक तक्ता हवा असेल, तर त्यांची नावे सांगा. जर तुम्हाला कमेंट्ससह कोड ब्लॉकमध्ये आउटपुट हवे असेल, तर तसे सांगा. फॉरमॅटिंगच्या सूचनांमुळे तुम्हाला स्ट्रक्चर्ड डेटा हवा असताना मजकुराचा मोठा ढिगारा मिळत नाही.

मर्यादा (Constraints)
काय टाळायचे आहे याची यादी करा. यामध्ये टोन, लांबी, निषिद्ध शब्द आणि टाळण्याचे विषय यांचा समावेश होतो. उदाहरणार्थ: "प्रतिसाद १५० शब्दांपेक्षा कमी ठेवा. संवादात्मक शैली वापरा. 'synergy' हा शब्द वापरू नका. $५०० पेक्षा जास्त बजेट लागतील असे उपाय सुचवणे टाळा." मर्यादा म्हणजे मार्गदर्शक भिंती (guardrails) आहेत. मॉडेल त्यांचे पालन व्यवस्थित करते, परंतु तुम्ही ते स्पष्टपणे सांगितल्यासच.

चांगल्या निकालांसाठी चार तंत्रे

एकदा तुम्ही मूलभूत गोष्टी शिकलात की, तुम्ही काही प्रगत पद्धती वापरून तुमचा दृष्टिकोन अधिक सुधारू शकता. यापैकी कोणत्याही पद्धतीसाठी विशेष प्रशिक्षणाची आवश्यकता नाही. या केवळ तुमच्या विचार करण्याची पद्धत अशी रचण्याचे मार्ग आहेत जेणेकरून मॉडेल तुमचे अनुसरण करू शकेल.

जटिल कामाचे टप्प्यांमध्ये विभाजन करा
एकाच वेळी सर्व काही मागू नका. जर तुम्हाला मार्केटिंग मोहीम हवी असेल, तर प्रेक्षक विश्लेषण (audience analysis) पासून सुरुवात करा. त्या आउटपुटचा आढावा घ्या, मग मेसेजिंगसाठी विचारा. त्यानंतर चॅनेल निवडीबद्दल विचारा. हा टप्प्याटप्प्याने केलेला दृष्टिकोन तुम्हाला सुरुवातीलाच त्रुटी शोधण्यास मदत करतो. तसेच, एकाच वेळी दहा परस्परविरोधी गरजा संतुलित करण्याचा प्रयत्न करताना मॉडेल गोंधळून जाण्यापासूनही हे वाचवते. कोडिंग कामांसाठी, प्रथम आर्किटेक्चर विचारा, त्यानंतर अंमलबजावणी (implementation) आणि शेवटी टेस्ट्स विचारा. प्रत्येक टप्पा मागील टप्प्यावर आधारित असतो आणि तुमचे नियंत्रण कायम राहते.

तर्क विचारण्यास सांगा (Ask for the reasoning)
Chain-of-thought प्रॉम्प्टिंग म्हणजे सोप्या भाषेत सांगायचे तर, अंतिम उत्तर देण्यापूर्वी Claude ला त्याचे तर्क (reasoning) स्पष्ट करायला सांगणे. 'तुमच्या तर्काचे टप्प्याटप्प्याने स्पष्टीकरण द्या आणि त्यानंतर तुमचा निष्कर्ष सांगा' यांसारखी वाक्ये तर्कशास्त्र (logic), गणित आणि कोडिंग डीबगिंगसाठी चमत्कारिक ठरतात. जेव्हा तुम्ही मॉडेलने उत्तर कसे शोधले हे पाहू शकता, तेव्हा मॉडेलने नेमकी कोणत्या वेळी एखादी आवश्यकता चुकीची समजली किंवा डेटासेटमधून चुकीची व्हॅल्यू घेतली, हे तुम्हाला लगेच समजते. हे एका 'ब्लॅक बॉक्स'ला तुम्ही तपासू (audit) शकण्यासारख्या गोष्टीमध्ये रूपांतरित करते.

माहिती वेगळी करण्यासाठी XML टॅग्स वापरा
जेव्हा प्रॉम्प्टमध्ये मजकुराचे मोठे भाग असतात, तेव्हा मॉडेल मूळ माहिती आणि सूचना यामध्ये गोंधळू शकते. वेगवेगळ्या विभागांना <context>, <task>, किंवा <example> सारख्या टॅगमध्ये गुंडाळा (wrap). उदाहरणार्थ:

आम्ही ४० कर्मचाऱ्यांची एक रिमोट-फर्स्ट SaaS कंपनी आहोत. Slack कडून Microsoft Teams कडे वळल्याची घोषणा करणारी कंपनी-व्यापी मेमो (memo) तयार करा. टोन उत्साही असावा पण तो अतिशयोक्तीपूर्ण (cringe) नसावा. २०० शब्दांच्या आत ठेवा.

ही रचना एखाद्या दस्तऐवजातील हेडर्सप्रमाणे काम करते. यामुळे मॉडेल तुमची पार्श्वभूमी माहिती चुकून कार्याचा भाग समजणार नाही आणि यामुळे मोठे प्रॉम्प्ट्स नंतर एडिट करणेही सोपे जाते.

फक्त सांगा नका, दाखवा (Show, do not just tell)
Few-shot प्रॉम्प्टिंग म्हणजे तुम्हाला हवा असलेला स्टाईल किंवा फॉरमॅट याची दोन ते चार उदाहरणे देणे. मॉडेल्स ही पॅटर्न-मॅचिंग इंजिन्स आहेत. ते सखोल वर्णनापेक्षा उदाहरणांमधून अधिक वेगाने शिकतात. जर तुम्हाला मीटिंग नोट्सचे 'ॲक्शन आयटम्स'मध्ये रूपांतर करायचे असेल, तर कच्च्या नोट्सची दोन उदाहरणे आणि त्यानंतर तुम्हाला अपेक्षित असलेले नेमके स्ट्रक्चर्ड आउटपुट पेस्ट करा. Claude नवीन इनपुटवर आश्चर्यकारक अचूकतेने तोच पॅटर्न मॅच करेल. फॉरमॅटचे दहा वाक्यांत वर्णन करण्यापेक्षा तीन स्पष्ट उदाहरणे दाखवणे सहसा अधिक प्रभावी ठरते.

एक तयार टेम्पलेट (A Ready-to-Use Template)

जर तुम्ही रिकाम्या प्रॉम्प्ट बॉक्सकडे पाहत बसला असाल, तर या सांगाड्याचा (skeleton) वापर करा. उत्तर लहान असले तरीही प्रत्येक कंसात माहिती भरा.

Role: [विशिष्ट भूमिका आणि संबंधित कौशल्य भरा] Context: [पार्श्वभूमी, प्रेक्षक आणि ध्येय भरा] Task: [एखाद्या प्रभावी क्रियापदाचा वापर करून नेमकी कृती लिहा] Format: [इच्छित रचना: यादी, तक्ता, निबंध, JSON, इत्यादी] Constraints: [टोन, लांबी, प्रतिबंधित शब्द किंवा टाळायचे विषय लिहा]

ते भरल्यानंतर कसे दिसते ते येथे पहा:

Role: तुम्ही एका B2B पेरोल स्टार्टअपमधील प्रॉडक्ट मार्केटिंग मॅनेजर आहात. Context: आम्ही मध्यम आकाराच्या कंपन्यांसाठी स्टेट टॅक्स फाइलिंग ऑटोमेट करणारे एक फीचर लाँच करत आहोत. आमचे प्रेक्षक हे HR डायरेक्टर्स आहेत जे कंप्लायन्सच्या कागदपत्रांमध्ये अडकलेले आहेत. त्यांचे ध्येय त्यांना डेमो बुक करण्यास प्रवृत्त करणे हे आहे. Task: मॅन्युअल फाइलिंगच्या त्रासाने सुरुवात होणारा आणि १५ मिनिटांच्या कॉलचे वेळापत्रक ठरवण्यासाठी सौम्य विनंती करून संपणारा १२० शब्दांचा ईमेल लिहा. Format: विषय (Subject line), दोन लहान परिच्छेद आणि कॉल-टू-ॲक्शन बटण लेबल. Constraints: 'synergy' किंवा 'bandwidth' सारखे तांत्रिक शब्द (jargon) वापरू नका. टोन व्यावसायिक पण आपुलकीचा असावा. उद्गारवाचक चिन्हांचा वापर करू नका.

या प्रॉम्प्टमुळे Claude ला आवश्यक असलेली सर्व माहिती मिळते. निकाल परिपूर्ण नसेल, पण तो शून्यापासून पुन्हा लिहिण्याऐवजी फक्त थोडे एडिट करून वापरण्याइतपत जवळचा असेल.

मुख्य निष्कर्ष (The Real Takeaway)

तुम्हाला प्रत्येक विनंतीसाठी पाच भागांचे मास्टरपीस तयार करण्याची गरज नाही. 'डाळीची चांगली रेसिपी काय आहे?' असे विचारण्यासाठी भूमिका किंवा XML टॅग्सची गरज नसते. पण जेव्हा आउटपुट महत्त्वाचे असते, जेव्हा कार्य गुंतागुंतीचे असते किंवा जेव्हा तुम्हाला सलग तीन चुकीची उत्तरे मिळतात, तेव्हा या चेकलिस्टचा वापर करा. बहुतेक अयशस्वी प्रॉम्प्ट्सचे कारण म्हणजे माणूस अजूनही मनात विचार करत असतो. तुम्हाला नक्की काय हवे आहे, ते कोणासाठी आहे आणि ते कसे दिसावे, हे ठरवण्यासाठी तीस सेकंद घ्या. हे विचार आधीच करा, म्हणजे तुम्हाला उत्तर सुधारण्यात (cleaning up) खूप कमी वेळ खर्च करावा लागेल. स्पष्ट सूचनांमुळे स्पष्ट निकाल मिळतात. बाकी सर्व फक्त गोंधळ (noise) आहे.