ज़्यादातर प्रॉम्प्ट इंजीनियरिंग का फ़ोकस सही जवाब और सभी ज़रूरी निर्देश देने पर होता है. लेकिन प्रोडक्शन में सबसे बड़ा फायदा तब मिलता है, जब बातचीत को ही डिज़ाइन का मुख्य हिस्सा माना जाए.
किसी स्थिति में क्या करना है, यह बताने वाले नियम मॉडल को फ़ैसला लेना सिखाते हैं. इससे उसे ऐसी स्क्रिप्ट नहीं मिलती, जिससे वह बाहर न निकल पाए. प्रॉम्प्ट में किसी बात की जगह भी एक तरह का निर्देश है. शुरुआत में पहचान, बीच में व्यवहार का तरीका और आखिर में सख्त नियम रखें. जो बात सबसे ज़्यादा ज़रूरी हो, उसे शुरुआत और आखिर दोनों जगह रखें.
जिस अंदाज़ में जवाब चाहिए, उसी अंदाज़ में प्रॉम्प्ट लिखना, सिर्फ़ उस अंदाज़ के बारे में बताने से कहीं ज़्यादा असरदार है.
सबसे बेहतर बातचीत वही एजेंट करते हैं जिनके प्रॉम्प्ट में बातचीत के अलग-अलग मौकों को अलग तरह से संभाला जाता है. हर मौके के लिए जवाब का सही तरीका होता है, लेकिन एजेंट के कहने का अंदाज़ पूरे समय एक जैसा रहता है.
कुछ मामलों में सोचने वाले एजेंट और बोलने वाले एजेंट अलग रखने से जवाब ज़्यादा साफ़ और बातचीत से जुड़े रहते हैं. इससे एजेंट की अपनी रीज़निंग भी जवाब में आने से रुकती है.
हमने पहले भाषा विज्ञान और कॉग्निटिव साइकोलॉजी से मिली सीख के आधार पर प्रॉम्प्टिंग का एक नया तरीका बताया था. हमने बताया था कि एजेंट के लिए ऐसा साफ़ और तय दायरा बनाना ज़रूरी है, जिसमें वह काम कर सके. इस दायरे में यह भी शामिल होना चाहिए कि कस्टमर-फ़ेसिंग AI में बातचीत को कैसे आगे बढ़ाना है.
अब हम देखेंगे कि इन बातों को प्रोडक्शन में इस्तेमाल करने के दौरान हमारे प्रॉम्प्ट में किस तरह बदलाव आए हैं.
लाइव कस्टमर-फ़ेसिंग सिस्टम में सैकड़ों बार प्रॉम्प्ट बदलने के बाद हमें सबसे बड़ा फ़ायदा ज़्यादा निर्देश जोड़ने, ढेर सारे उदाहरण देने या प्रॉम्प्ट इंजीनियरिंग के आम तरीकों को अपनाने से नहीं मिला. फ़ायदा तब मिला जब हमने बातचीत को ही इस काम का सबसे अहम हिस्सा माना.
लगातार आज़माने और टेस्ट करने से कुछ असरदार तरीके सामने आए. हम प्रॉम्प्ट में बदलाव करते और देखते कि बातचीत कहाँ सही रही और कहाँ नहीं. फिर हम यह पता लगाते कि गलती की वजह गाइडेंस, प्रॉम्प्ट की बनावट या भाषा का सही इस्तेमाल न होना तो नहीं था. इससे कुछ ऐसे तरीके सामने आए जिन्हें बार-बार इस्तेमाल किया जा सकता है. इनसे एजेंट को बातचीत में अपनी भूमिका बेहतर समझने, अगला कदम सही तरीके से तय करने और अलग-अलग कॉन्टेक्स्ट में अपना अंदाज़ एक जैसा बनाए रखने में मदद मिलती है.
आगे दिए गए पाँच तरीके कोई ऐसा नियम नहीं हैं जो हर जगह काम करें. न ही इसका मतलब है कि प्रॉम्प्टिंग की सारी समस्याएँ हल हो गई हैं. ये पाँच ऐसे तरीके हैं जो प्रोडक्शन में काम के साबित हुए, जब हमारा मकसद सिर्फ़ सही जवाब पाना नहीं, बल्कि ऐसी बातचीत करना था जो साफ़, सहज और एक जैसी लगे और ब्रांड की आवाज़ को बनाए रखे.
एजेंटिक सिस्टम बनाने के कई तरीके हैं, लेकिन मल्टी-एजेंट वाले ऑर्केस्ट्रेटेड वर्कफ़्लोज़ अब भी काफ़ी इस्तेमाल होते हैं. ऐसे सिस्टम में हमें सबसे लगातार फ़ायदा तब मिला जब हमने सोचने वाले एजेंट और बात करने वाले एजेंट अलग रखे.
यूज़र की मंशा समझना, रिक्वेस्ट को कैटेगरी में रखना, ज़रूरी जानकारी निकालना और टूल्स का इस्तेमाल करना बैक-ऑफ़-हाउस का काम है. कस्टमर को जवाब देना फ़्रंट-ऑफ़-हाउस का काम है. जब एक ही एजेंट एक ही समय में दोनों काम करता है, तो उसकी अपनी रीज़निंग और लॉजिक जवाब में दिखाई दे सकता है. जवाब ज़रूरत से ज़्यादा सावधानी वाला, लंबा या काम करने के तरीके के हिसाब से बना हुआ लग सकता है, जबकि उसे यूज़र की ज़रूरत के हिसाब से होना चाहिए.
यह एक छोटा सा नियम काफ़ी काम करता है. इससे जवाब असली बातचीत से जुड़े रहते हैं, कॉन्टेक्स्ट फिर से शुरू नहीं होता और हमें वह मिलता है जिसे हम "डेलिवरिंग द डेल्टा" कहते हैं. यानी एजेंट सिर्फ़ उतनी ही नई बात जोड़ता है, जितनी यूज़र को सच में आगे बढ़ाने के लिए ज़रूरी है.
जवाब किस तरह का होना चाहिए, यह तय करना भी मायने रखता है. हमने पाया कि बोलने वाले एजेंट से कुछ भी लिखने से पहले जवाब का तरीका चुनने को कहने पर बातचीत की सबसे आम गलती काफ़ी कम हुई — जैसे, जवाब देना, कुछ साफ़ करना, बात को दूसरे तरीके से आगे बढ़ाना या थोड़ी देर रुकना — समस्या खराब भाषा नहीं थी, बल्कि पूरा जवाब ही गलत था.
यह भी ध्यान देने वाली बात है कि सही सेटअप में नए फ़्रंटियर मॉडल इस तरीके की ज़रूरत पर सवाल उठा रहे हैं. फिर भी, कई बिल्डर्स अलग-अलग वजहों से छोटे या पुराने मॉडल इस्तेमाल करते हैं. ऐसे मामलों में हम ज़रूर सुझाते हैं कि बैक-ऑफ़-हाउस और फ़्रंट-ऑफ़-हाउस के काम अलग रखें.
रीज़निंग न करने वाले मॉडल्स के लिए फ़्यू-शॉट उदाहरण देना काम करता है, क्योंकि वे साफ़ होते हैं, जल्दी दिए जा सकते हैं और मॉडल उन्हें अच्छी तरह समझते हैं. समस्या यह है कि मॉडल उन्हीं उदाहरणों पर ज़्यादा निर्भर होने लगता है. एक उदाहरण देने पर मॉडल उसके शब्दों, लय और ढाँचे को पकड़ लेता है. फिर हालात बदलने पर भी वह उसी तरह के जवाब बार-बार देने लगता है.
आपने अनजाने में आपने मॉडल के लिए एक ऐसी स्क्रिप्ट बना दी है, जिससे वह बाहर नहीं निकल पाता.
इसके बजाय इम्प्लीमेंटेशन इंटेंशंस या अनुभव पर आधारित नियमों पर काम करना ज़्यादा टिकाऊ तरीका हैं. हर अलग सिनारियो*,* में मॉडल को क्या कहना है, इसका उदाहरण देने के बजाय हम एक आसान नियम देते हैं: अगर X हो, तो Y करें.
मुख्य अंतर यह है कि हम हर उदाहरण के ज़रिए X और Y की सीमा को धीरे-धीरे छोटा और सख़्त नहीं करते. इसके बजाय, एक ऐसा साफ़ नियम बनाते हैं जो दोनों की सीमा तय कर देता है. इससे उदाहरण देने की ज़रूरत ही नहीं रहती. इस तरह एजेंट किसी तय टेम्पलेट की नकल करने के बजाय असली बातचीत में आने वाले अलग-अलग तरह के सवालों के हिसाब से जवाब दे सकता है.
असल में, ये उदाहरणों से ज़्यादा ऐसे आसान नियम होते हैं, जिन्हें एजेंट सीधे अपना सकता है:
अगर कोई ज़रूरी जानकारी नहीं है, तो एक सवाल पूछें और जानकारी लें.
अगर जवाब देने के लिए जानकारी काफ़ी नहीं है, तो यह साफ़ तौर पर बताएँ और अगला सबसे अच्छा कदम सुझाएँ.
अगर रिक्वेस्ट किसी गार्डरेल की वजह से रुकती है, तो थोड़े शब्दों में मना करें और बिना ज़्यादा बात किए दूसरा रास्ता बताएँ.
यह बहुत शानदार तरीका नहीं लगता, लेकिन कुछ तैयार जवाबों की लंबी लिस्ट से कहीं ज़्यादा भरोसेमंद है. क्योंकि इससे मॉडल को यह सीखने में मदद मिलती है कि फ़ैसला कैसे करना है, न कि क्या दोहराना है.
प्रॉम्प्ट में कोई बात कहाँ लिखी गई है, इससे यह तय होता है कि मॉडल उसे कितनी अहमियत देगा. हमने अलग-अलग मॉडल्स और डिप्लॉयमेंट्स में यह पैटर्न बार-बार देखा है. प्रॉम्प्ट की शुरुआत और अंत की बातें मॉडल के लिए ज़्यादा अहम होती हैं. बीच का हिस्सा बारीक बातों के लिए है और बारीक बातें वहीं होनी चाहिए.
हम इसी हिसाब से अपने प्रॉम्प्ट तैयार करते हैं. सबसे ऊपर एजेंट की भूमिका और उसकी पहचान रखते हैं, ताकि शुरुआत में ही यह साफ़ हो जाए कि एजेंट क्या है. बीच में काम करने का तरीका रखते हैं: बातचीत कैसे आगे बढ़ सकती है, जवाब देने में कौन से आसान नियम काम आएँगे और एजेंट को किन तरह के सवालों को संभालना होगा. सबसे नीचे सख्त नियम और ऐसी बातें रखते हैं जिनमें कोई बदलाव नहीं होना चाहिए, ताकि वे सबसे आखिर में भी एजेंट के लिए साफ़ रहें.
जो बात सच में बहुत ज़रूरी है, उसे हम दोनों जगह लिखते हैं. उदाहरण के लिए, पंक्चुएशन या फ़ॉर्मैटिंग का कोई सख्त नियम अगर लंबे प्रॉम्प्ट के बीच में सिर्फ़ एक बार लिखा हो, तो वह छूट सकता है. उसे आखिर में दोबारा लिखने पर वह ज़्यादा मज़बूती से बना रहता है.
हाल की जानकारी में सबसे ज़्यादा अहम है स्ट्रक्चर्ड आउटपुट, जिसका इस्तेमाल करने पर वह आपके प्रॉम्प्ट का सबसे आखिरी निर्देश होता है. स्ट्रक्चर्ड आउटपुट में दिए गए डिस्क्रिप्शन फ़ील्ड भी जवाब पर असर डालते हैं. वे प्रॉम्प्ट के बाकी हिस्सों के मुकाबले आउटपुट के लिए ज़्यादा साफ़ नियम तय करते हैं.
हमने यह भी सीखा है कि कुछ कहने के लहज़े के लिए फ़्यू-शॉट उदाहरण देना सही तरीका नहीं है. यह हमारे कस्टमर से बातें करने वाले एजेंट्स में किए गए सबसे असरदार बदलावों में से एक रहा है.
इसके बजाय, हम पूरा प्रॉम्प्ट उसी अंदाज़ में लिखते हैं, जैसा हम आउटपुट में चाहते हैं. अंदाज़ कैसा होना चाहिए, यह सिर्फ़ बताने के बजाय हम शुरुआत से आखिर तक पूरा प्रॉम्प्ट उसी भाषा और अंदाज़ में लिखते हैं. यानी प्रॉम्प्ट ही अपने-आप में एक उदाहरण बन जाता है. हम इसे "एंटी-स्क्रिप्टनेस" कहते हैं. इसमें मॉडल प्रॉम्प्ट की भाषा और अंदाज़ से सीखता है, लेकिन उसी तरह के दूसरे शब्द और वाक्य भी इस्तेमाल कर सकता है.
इसी तरह हम प्रॉम्प्ट का अंदाज़ वही रखते हुए भाषा में बदलाव लाते हैं. यह हमारी उस सोच का हिस्सा है जिसमें हम हर एजेंट के काम में बातचीत को सबसे अहम रखते हैं. इसके लिए हमें अलग-अलग साफ़-साफ़ निर्देश देने में ज़्यादा जगह नहीं लगानी पड़ती, और हम ऐसे निर्देश कम से कम रखने की कोशिश करते हैं.
अगर हम बोलने के लहज़े के लिए उदाहरण देते भी हैं, तो वे ज़्यादातर "क्या नहीं करना है" दिखाते हैं. जैसे: "एम डैश कभी न इस्तेमाल करें. घिसे-पिटे वाक्य न लिखें. पॉलिसी की लंबी लिस्ट न दें. जहाँ एक वाक्य से बात पूरी हो सकती है, वहाँ ज़्यादा न समझाएँ." ऐसे नेगेटिव नियम ज़्यादा साफ़ और कम रोकने वाले होते हैं, क्योंकि वे उन गलतियों को सीधे बताते हैं जिनकी तरफ़ मॉडल आसानी से जा सकता है.
यहाँ फ़ॉर्मैटिंग भी मायने रखती है और जवाब का अंदाज़ तय करती है. बुलेट पॉइंट्स, हेडर्स और ब्रैकेट में दिए गए टेक्स्ट से भरा प्रॉम्प्ट मॉडल को ज़्यादा सधा हुआ और मशीनी जवाब देने की तरफ़ ले जाता है. अगर जवाब बातचीत जैसा लगना चाहिए, तो इनपुट भी किसी छोटे स्पेसिफ़िकेशन डॉक्यूमेंट जैसा नहीं दिखना चाहिए.
ज़्यादातर प्रॉम्प्टिंग लहज़े की वजह से आखिर में पर्सनैलिटी तक ही सीमित रह जाती है. एजेंट का अंदाज़ कैसा होना चाहिए, यह बताने के लिए कुछ शब्द दे दिए जाते हैं. गर्मजोशी भरे. प्रोफ़ेशनल. दोस्ताना, लेकिन छोटे और सीधे. ये शब्द गलत नहीं हैं, लेकिन बातचीत में वह अंदाज़ कैसा लगेगा, यह असल में रजिस्टर तय करता है. यानी अलग-अलग मौकों पर वही अंदाज़ कैसे बदलेगा.
जब किसी सवाल का जवाब तैयार हो रहा हो, तब इंतज़ार के लिए कहने वाला मैसेज अंतिम जवाब जैसा नहीं लगना चाहिए. गार्डरेल वाला जवाब भी छोटी-मोटी बातचीत जैसा नहीं होना चाहिए. जो कस्टमर परेशान है, उससे उसी तरह मज़ाकिया या हँसमुख अंदाज़ में बात नहीं करनी चाहिए जैसे किसी ऐसे कस्टमर से जो बस यूँ ही चीज़ें देख रहा हो.
यही ब्रांड की आवाज़ और बातचीत के डिज़ाइन के बीच का अंतर है. ब्रांड की आवाज़ अक्सर यह बताती है कि अंदाज़ कैसा होना चाहिए, जबकि बातचीत का डिज़ाइन तय करता है कि अलग-अलग मौकों पर वही अंदाज़ कैसे बदलेगा. इसे सही तरीके से करने का मतलब सिर्फ़ AI के जवाबों के लिए कॉपी लिखना नहीं है. हमें यह भी तय करना होता है कि बातचीत के दौरान कुछ कहने का अंदाज़ कैसे बदलेगा.
आपने देखा होगा कि इनमें से कोई भी तरीका तकनीकी रूप से बहुत जटिल नहीं है. और यही बात कुछ हद तक इसका मकसद भी है. एजेंटिक सिस्टम का आर्किटेक्चर ज़रूरी है, लेकिन बातचीत की क्वालिटी के लिए प्रॉम्प्ट को डिज़ाइन और बेहतर करने में काफ़ी समय देना पड़ता है.
सिर्फ़ तकनीकी डिज़ाइन से काम करने वाले AI और सच में बातचीत करने वाले AI के बीच का अंतर खत्म नहीं होता. इसके लिए यह समझना ज़रूरी है कि लोग बातचीत में भाषा का इस्तेमाल कैसे करते हैं और बातचीत कैसे आगे बढ़ती है. साथ ही, एजेंट के काम में बातचीत को सबसे अहम जगह देनी होती है.
AI प्रोडक्ट की टीमें, इंजीनियर्स और एक्सपीरियंस डिज़ाइनर्स को कस्टमर से बातें करने वाले AI में बातचीत के डिज़ाइन को भी उतनी ही गंभीरता से लेना चाहिए जितनी तकनीकी क्वालिटी को. दूसरी तरफ़ बैठे लोगों के लिए कोई मॉडल, मल्टी-एजेंट कोलैबोरेशन या टूल कॉल मायने नहीं रखता — उनके लिए सिर्फ़ बातचीत मायने रखती है. बातचीत या तो सही लगती है या नहीं. वह भरोसा बढ़ाती है या कम करती है.
आखिर में, किसी को सिस्टम का आर्किटेक्चर दिखाई नहीं देता. वे सिर्फ़ बातचीत का अनुभव करते हैं.
बातचीत ही प्रोडक्ट है.