Automatic Prompt Engineer (APE) एक भाषा मॉडल (language model) को किसी दिए गए कार्य के लिए सबसे अच्छा प्रॉम्प्ट लिखने, परीक्षण करने और चुनने की अनुमति देता है, जिससे जो कभी 'ट्रायल-एंड-एरर' (trial-and-error) की एक कला थी, वह एक दोहराने योग्य डेटा-संचालित खोज (data-driven search) में बदल जाती है।
प्रॉम्प्ट लेखन एक बाधा (bottleneck) क्यों बन गया है
प्रॉम्प्ट इंजीनियरिंग—सटीक शब्दों को तैयार करना जो मॉडल को बताते हैं कि क्या करना है—लंबे समय से अंतर्ज्ञान (intuition) और भाग्य का मिश्रण रहा है। विशेषज्ञ यहाँ एक शब्द बदलते हैं, वहाँ एक वाक्यांश बदलते हैं, मॉडल चलाते हैं, और तब रुकते हैं जब आउटपुट "सही लगता है।" यह दृष्टिकोण लंबा खिंचता है, इंजीनियर की कल्पना पर निर्भर करता है, और प्रदर्शन को सीमित कर देता है। प्रोडक्शन में इसका अर्थ है लंबे चक्र, अस्थिर परिणाम और छिपी हुई लागतें जो लॉन्च के बाद ही सामने आती हैं।
APE का तीन-चरणीय वर्कफ़्लो (workflow)
APE प्रॉम्प्ट निर्माण को एक खोज समस्या (search problem) के रूप में देखता है। उपयोगकर्ता इनपुट-आउटपुट उदाहरणों का एक छोटा सेट प्रदान करता है। फिर सिस्टम तीन स्वचालित चरणों को चलाता है:
- Propose (प्रस्तावित करना) – मॉडल उदाहरणों को स्कैन करता है और उम्मीदवार निर्देशों (candidate instructions) का एक समूह देता है, जैसे कि "विपरीत लौटाएं" या "विलोम लिखें।"
- Score (स्कोर करना) – सिस्टम प्रत्येक उम्मीदवार को अनदेखे उदाहरणों के एक अलग सेट पर चलाता है और गिनता है कि कितने उत्तर अपेक्षित आउटपुट से मेल खाते हैं, जिससे एक रॉ सटीकता (raw accuracy) संख्या प्राप्त होती है। इस चरण में मानवीय निर्णय का कोई हस्तक्षेप नहीं होता है।
- Select (चुनना) – उच्चतम सटीकता वाला निर्देश अंतिम प्रॉम्प्ट बन जाता है।
यह लूप दोहराया जा सकता है। जीतने वाला प्रॉम्प्ट नया सीड (seed) बन जाता है, और मॉडल विभिन्न बदलावों का सुझाव देता है। रिपोर्ट किए गए रन में, एक सामान्य निर्देश जिसने 83% स्कोर किया था, उसे एक ऐसे संस्करण में परिष्कृत किया गया जिसने टेस्ट सेट पर 100% स्कोर किया।
क्या चीज़ इस दृष्टिकोण को मानवीय क्षमता से बेहतर बनाती है
- Coverage (कवरेज) – एक LLM सेकंडों में वाक्यांशों के दर्जनों विकल्प तैयार कर देता है, जो एक व्यक्ति द्वारा परीक्षण किए जा सकने वाले विकल्पों से कहीं अधिक है।
- Objectivity (वस्तुनिष्ठता) – चयन मापने योग्य सटीकता पर निर्भर करता है, न कि इस पर कि शब्द कितने परिष्कृत लगते हैं। एक पाठ्यपुस्तक-शैली का निर्देश अभी भी एक संक्षिप्त, अजीब लगने वाले संस्करण से हार सकता है जिसे मॉडल बेहतर समझता है।
क्योंकि स्कोरिंग मेट्रिक उपयोगकर्ता से आता है—आमतौर पर एक सटीक-मिलान (exact-match) जांच या यूनिट टेस्ट—सिस्टम को कोड जनरेशन से लेकर सेंटीमेंट एनालिसिस तक किसी भी डाउनस्ट्रीम आवश्यकता के लिए ट्यून किया जा सकता है।
ऑटोमेशन की कीमत
इसका ट्रेड-ऑफ (trade-off) कंप्यूट है। प्रत्येक उम्मीदवार को स्कोर करने के लिए कई मॉडल कॉल करने पड़ते हैं, इसलिए विकास चरण में API का काफी उपयोग होता है। APE उस खर्च को एक बार के निवेश के रूप में देखता है: एक बार इष्टतम (optimal) प्रॉम्प्ट की पहचान हो जाने के बाद, आप बिना किसी अतिरिक्त लागत के इसे हमेशा के लिए पुन: उपयोग कर सकते हैं।
दो पूर्वशर्तें भी इसके अपनाने को सीमित करती हैं:
- Labeled examples (लेबल किए गए उदाहरण) – सिस्टम को इनपुट और सही आउटपुट के एक प्रतिनिधि सेट की आवश्यकता होती है।
- Scoring function (स्कोरिंग फ़ंक्शन) – उपयोगकर्ताओं को यह परिभाषित करना होगा कि उनके कार्य के लिए "सही" का क्या अर्थ है, चाहे वह सटीक स्ट्रिंग मैच हो, एक संख्यात्मक सहनशीलता (numeric tolerance) हो, या एक कस्टम वैलिडेटर हो।
कहाँ यह विचार विफल हो सकता है
यदि प्रारंभिक उदाहरण सेट बहुत छोटा या गैर-प्रतिनिधि है, तो चुना गया प्रॉम्प्ट ओवरफिट (overfit) हो सकता है और वास्तविक दुनिया के उपयोग में विफल हो सकता है।
आगे क्या देखें
यह टूल एक विकल्प प्रदान करता है: कुछ उदाहरण दें, मॉडल को दोहराने दें, और एक ऐसा प्रॉम्प्ट प्राप्त करें जिसे सिस्टम अपने प्रयासों में सबसे ऊपर रखता है। डेमो मूल घोषणा में दिए गए लिंक पर उपलब्ध है, और टेलीग्राम पर एक लर्निंग कम्युनिटी जुड़ी हुई है।
Takeaway: प्रॉम्प्ट इंजीनियरिंग को ऑटोमेट करना अनुमान (guesswork) की जगह मापने योग्य प्रदर्शन (measurable performance) लाता है, लेकिन इसके लिए अग्रिम डेटा, कंप्यूट और सफलता की स्पष्ट परिभाषा की आवश्यकता होती है।