Automatic Prompt Engineer (APE) एका लँग्वेज मॉडेलला दिलेल्या कार्यासाठी सर्वोत्तम प्रॉम्प्ट लिहिण्यास, त्याची चाचणी घेण्यास आणि निवडण्यास सक्षम करते, ज्यामुळे एकेकाळी केवळ 'ट्रायल-अँड-एरर' (प्रयत्न आणि चूक) या कलेच्या स्वरूपात असलेले काम आता एक पुनरावृत्ती करण्यायोग्य डेटा-आधारित शोध बनले आहे.
प्रॉम्प्ट लेखन अडथळा (bottleneck) का बनले आहे
प्रॉम्प्ट इंजिनिअरिंग—म्हणजेच मॉडेलला काय करायचे आहे हे सांगण्यासाठी नेमके शब्द तयार करणे—हे बऱ्याच काळापासून अंतर्ज्ञान (intuition) आणि नशिबाचा मिलाफ राहिले आहे. तज्ज्ञ येथे एखादा शब्द बदलतात, तिथे एखादा शब्दसमूह (phrase) बदलतात, मॉडेल चालवतात आणि जेव्हा आउटपुट "योग्य वाटते" तेव्हा थांबतात. ही पद्धत वेळखाऊ आहे, इंजिनिअरच्या कल्पनाशक्तीवर अवलंबून आहे आणि कामगिरीवर मर्यादा आणते. प्रत्यक्ष वापरामध्ये (production) याचा अर्थ लांबच लांब प्रक्रिया, अस्थिर निकाल आणि लाँच झाल्यानंतर समोर येणारे छुपे खर्च असा होतो.
APE ची तीन-टप्प्यांची कार्यप्रणाली (workflow)
APE प्रॉम्प्ट निर्मितीकडे एक 'सर्च प्रॉब्लेम' (शोध समस्या) म्हणून पाहते. वापरकर्ता इनपुट-आउटपुटच्या काही उदाहरणांचा संच देतो. त्यानंतर सिस्टम तीन स्वयंचलित टप्पे राबवते:
- Propose (प्रस्तावित करणे) – मॉडेल उदाहरणांचे स्कॅनिंग करते आणि "विरुद्ध उत्तर द्या" किंवा "विरुद्धार्थी शब्द लिहा" यांसारख्या अनेक संभाव्य सूचनांचा संच तयार करते.
- Score (गुण देणे) – सिस्टम प्रत्येक संभाव्य सूचनेची चाचणी न पाहिलेल्या (unseen) उदाहरणांच्या वेगळ्या संचावर करते आणि किती उत्तरे अपेक्षित आउटपुटशी जुळतात याची गणना करते, ज्यामुळे अचूकतेचा (accuracy) एक आकडा मिळतो. या टप्प्यात मानवी हस्तक्षेपाची गरज नसते.
- Select (निवडणे) – ज्या सूचनेची अचूकता सर्वाधिक आहे, ती अंतिम प्रॉम्प्ट म्हणून निवडली जाते.
ही प्रक्रिया पुन्हा पुन्हा केली जाऊ शकते. जिंकलेला प्रॉम्प्ट नवीन 'सीड' (seed) बनतो आणि मॉडेल त्यातील विविध प्रकार सुचवते. अहवालानुसार, ८३% अचूकता देणाऱ्या एका सामान्य सूचनेचे रूपांतर अशा आवृत्तीत करण्यात आले, जिने टेस्ट सेटवर १००% अचूकता गाठली.
ही पद्धत मानवी प्रयत्नांपेक्षा अधिक प्रभावी का आहे
- व्याप्ती (Coverage) – एक LLM काही सेकंदात शब्दांच्या डझनभर पर्यायांची निर्मिती करू शकते, जे एखाद्या व्यक्तीला तपासणे शक्य नाही.
- वस्तुनिष्ठता (Objectivity) – निवड ही मोजता येण्याजोग्या अचूकतेवर अवलंबून असते, शब्द किती सुटसुटीत किंवा प्रभावी वाटतात यावर नाही. एखादी पुस्तकी शैलीतील सूचना, मॉडेलला अधिक चांगल्या प्रकारे समजणाऱ्या एखाद्या संक्षिप्त किंवा विचित्र वाटणाऱ्या पर्यायापेक्षा मागे पडू शकते.
कारण स्कोअरिंग मेट्रिक वापरकर्त्याकडून येते—सहसा 'एक्झॅक्ट-मॅच' (exact-match) तपासणी किंवा युनिट टेस्टद्वारे—त्यामुळे कोड जनरेशनपासून ते सेंटिमेंट अनालिसिसपर्यंत कोणत्याही गरजेनुसार ही सिस्टम ट्यून केली जाऊ शकते.
ऑटोमेशनची किंमत
याचा एकमेव तोटा म्हणजे 'कम्प्युट' (compute) खर्च. प्रत्येक संभाव्य सूचनेला स्कोअर करण्यासाठी मॉडेलला अनेकदा कॉल करावे लागतात, त्यामुळे डेव्हलपमेंट टप्प्यात API चा वापर लक्षणीय प्रमाणात होतो. APE या खर्चाकडे एकवेळच्या गुंतवणुकीसारखे पाहते: एकदा का सर्वोत्तम प्रॉम्प्ट ओळखला गेला की, तुम्ही तो कोणत्याही अतिरिक्त खर्चाशिवाय कायमस्वरूपी वापरू शकता.
दोन पूर्वअटींमुळे देखील याचा अवलंब मर्यादित आहे:
- लेबल केलेले नमुने (Labeled examples) – सिस्टमला इनपुट आणि अचूक आउटपुटचा एक प्रतिनिधी संच आवश्यक असतो.
- स्कोअरिंग फंक्शन (Scoring function) – वापरकर्त्याला त्यांच्या कार्यासाठी "योग्य" म्हणजे काय हे परिभाषित करावे लागते, मग ते स्ट्रिंग मॅच असो, न्यूमेरिक टॉलरन्स असो किंवा कस्टम व्हॅलिडेटर असो.
ही कल्पना कुठे अपयशी ठरू शकते
जर सुरुवातीचा उदाहरणांचा संच खूप लहान किंवा अपूर्ण असेल, तर निवडलेला प्रॉम्प्ट 'ओव्हरफिट' (overfit) होऊ शकतो आणि प्रत्यक्ष वापरामध्ये अपयशी ठरू शकतो.
पुढे काय पाहावे
हे टूल एक पर्याय देते: काही उदाहरणे द्या, मॉडेलला पुनरावृत्ती करू द्या आणि सिस्टमने सर्वाधिक रँक केलेला प्रॉम्प्ट मिळवा. मूळ घोषणेतील लिंकवर डेमो उपलब्ध आहे आणि टेलिग्रामवर एक लर्निंग कम्युनिटी एकत्र येते.
थोडक्यात सांगायचे तर: प्रॉम्प्ट इंजिनिअरिंगचे ऑटोमेशन म्हणजे केवळ अंदाज लावण्याऐवजी मोजता येण्याजोग्या कामगिरीवर भर देणे आहे, परंतु त्यासाठी सुरुवातीला डेटा, कम्प्युट आणि यशाची स्पष्ट व्याख्या आवश्यक आहे.