AI एजंट्सना त्यांची टूल्स पुन्हा चालवण्याची स्पष्ट परवानगी दिल्यास ते कमालीची सुधारणा करतात, असे लेखकाने शोधून काढले आहे – शब्दांमधील एका साध्या बदलामुळे दुरुस्तीचा यशस्वी दर ०.१६ वरून १.०० पर्यंत वाढला. "ॲक्शन-लायसन्सिंग" (action-licensing) असे नाव देण्यात आलेले हे परिणाम दर्शवतात की, एजंटला केवळ ध्येय पुन्हा सांगण्यापेक्षा, त्याने स्वतःच्या कामाची पडताळणी करावी असे सुचवणे अधिक प्रभावी ठरू शकते.
ही सुधारणा का महत्त्वाची आहे
बाह्य टूल्स (databases, calculators, APIs) वापरू शकणारे AI असिस्टंट्स बिझनेस वर्कफ्लोसाठी अधिकाधिक वापरले जात आहेत. जेव्हा हे एजंट्स चूक करतात, तेव्हा ती चूक अनेकदा शांतपणे पसरते, ज्यामुळे स्पष्ट त्रुटीचे संकेत न देता चुकीची उत्तरे मिळतात. संपूर्ण प्रॉम्प्ट पुन्हा न लिहिता हस्तक्षेप करण्याचा एक विश्वसनीय मार्ग डेव्हलपर्सचा वेळ वाचवू शकतो आणि प्रोडक्शन सिस्टममधील महागड्या चुका टाळू शकतो.
त्रुटी कशा प्रकारे दिसून येतात
लेखकाने दोन सामान्य, कमी दृश्यमान त्रुटींचे नमुने पाहिले:
Skipped Lookup (लूकअप वगळणे) – एजंटला माहिती मिळवावी लागते हे माहित असते (उदा. ID मधून मॅनेजरचे नाव मिळवणे), परंतु लूकअप टूल वापरण्याऐवजी तो थेट उत्तर तयार करतो. वरवर पाहता हे उत्तर पटण्यासारखे वाटते, परंतु त्यामागे तथ्यात्मक आधार नसतो.
Validated Nonsense (प्रमाणित निरर्थकता) – एजंट टूलला चुकीची किंवा अयोग्य माहिती देतो. टूल कोणतीही त्रुटी न दाखवता निकाल देते आणि एजंट त्या निकालाला पुष्टी मानतो, ज्यामुळे तो स्वतःच्याच चुकीचे समर्थन करतो.
दोन्ही पद्धतींमुळे वापरकर्त्याला आत्मविश्वासाने दिलेले पण चुकीचे उत्तर मिळते आणि डेव्हलपर्स ज्या लूप किंवा प्रतिसाद नसण्याच्या खुणांकडे लक्ष देतात, त्याही यात दिसून येत नाहीत.
प्रयोग
विविध प्रॉम्प्ट्स दुरुस्तीवर कसा परिणाम करतात हे मोजण्यासाठी, लेखकाने कडक ग्राउंड-ट्रुथ उत्तरांसह (कोणत्याही LLM-आधारित ग्रेडिंगशिवाय) एक नियंत्रित चाचणी आयोजित केली. दोन प्रकारचे प्रोत्साहन (nudges) यांची तुलना करण्यात आली:
Goal-only nudge (केवळ ध्येय सांगणे) – “उत्तर मॅनेजरचे नाव असणे आवश्यक आहे.” सुधारण्याचा दर (Recovery rate): ०.१६.
Action-licensing nudge (ॲक्शन-लायसन्सिंग प्रोत्साहन) – “उत्तर मॅनेजरचे नाव असणे आवश्यक आहे. पडताळणी करण्यासाठी टूल्स वापरा.” सुधारण्याचा दर (Recovery rate): १.०० (सर्व अयशस्वी रन दुरुस्त करण्यात आले).
यातील एकमेव फरक म्हणजे टूल पुन्हा कार्यान्वित करण्याची स्पष्ट परवानगी. दुसऱ्या प्रॉम्प्टमुळे एजंटला समजले की तो मागे जाऊ शकतो, गहाळ डेटा मिळवू शकतो आणि आपला आधीचा अंदाज बदलू शकतो. या परवानगीमुळे बहुतांश निष्प्रभावी ठरणाऱ्या प्रोत्साहनाचे रूपांतर चाचणी केलेल्या प्रकरणांसाठी खात्रीशीर उपायात झाले.
या आकड्यांचा अर्थ काय होतो
०.१६ वरून १.०० पर्यंत झालेली वाढ असे सुचवते की, दुरुस्तीमधील अडथळा एजंटची ध्येयाची समज नसून, कृती करण्याचे त्याचे कथित स्वातंत्र्य होते. जेव्हा प्रॉम्प्ट मॉडेलला सांगतो की "तुम्ही पुन्हा प्रयत्न करू शकता," तेव्हा ते परिस्थितीला डेड-एंड (dead-end) न मानता एक नवीन उप-कार्य (sub-task) म्हणून पाहते, ज्यामुळे टूल-कॉल चेन पुन्हा सुरू होऊ शकते.
केवळ प्रॉम्प्टिंगद्वारे मिळणाऱ्या सुधारणांच्या मर्यादा
या प्रयोगामुळे अशा परिस्थितींवरही प्रकाश पडला जिथे केवळ प्रॉम्प्टिंगमुळे एजंटला वाचवता येत नाही:
जर एखादे डाउनस्ट्रीम टूल शांतपणे चुकीचे इनपुट स्वीकारते आणि मूल्य परत करते, तर एजंटला त्याची माहिती चुकीची आहे असा कोणताही संकेत मिळत नाही. कितीही शब्दांची फेररचना केली तरी तो दोष शोधू शकणार नाही; टूलने स्वतः इनपुट व्हॅलिडेशन लागू करणे किंवा त्रुटी दर्शवणे आवश्यक आहे.
जे एजंट्स टूल्स वापरण्यातच अडखळतात, त्यांना "टूल्स वापरा" या सूचनेचा कधीही फायदा होणार नाही, कारण त्यांच्याकडे मूलभूत क्षमताच नसते. अशा मॉडेल्सवर दुरुस्तीची चाचणी घेतल्यास प्रॉम्प्टची परिणामकारकता आणि मॉडेलची मूलभूत टूल-कॉलिंग क्षमता यामध्ये गोंधळ होऊ शकतो.
डेव्हलपर्ससाठी व्यावहारिक उपाय
परवानगी द्या (Grant permission) – जेव्हा तुम्ही हस्तक्षेप करता, तेव्हा एजंटला स्पष्टपणे सांगा की तो टूल कॉल पुन्हा करू शकतो किंवा पुन्हा गणना (recompute) करू शकतो. केवळ अपेक्षित परिणाम पुन्हा सांगणे अनेकदा एजंटला त्याच्या मूळ, चुकीच्या मार्गावर अडकवून ठेवते.
टूल्स सुरक्षित करा (Guard the tools) – एजंट वापरत असलेल्या टूल्समध्ये इनपुट चेक आणि स्पष्ट एरर मेसेज समाविष्ट करा. यामुळे "validated nonsense" पुढे जाण्यापासून रोखता येईल.
लवकर शोधून काढा (Detect early) – चूक जितक्या लवकर लक्षात येईल, तितके 'री-एक्झिक्यूशन प्रॉम्प्ट' यशस्वी होणे सोपे जाते. अपेक्षित आणि प्रत्यक्ष टूल वापरामध्ये असणारी तफावत शोधून ठेवल्यास योग्य वेळी दुरुस्तीचा प्रॉम्प्ट सक्रिय करता येईल.
मॉडेलच्या क्षमतांची पडताळणी करा (Validate model capabilities) – प्रॉम्प्ट-आधारित दुरुस्तीवर अवलंबून राहण्यापूर्वी, मॉडेल प्रथम टूल्स विश्वसनीयपणे कॉल करू शकते की नाही याची खात्री करा. अन्यथा, तुम्ही एका कमकुवत पायावर प्रॉम्प्टची परिणामकारकता मोजत असाल.
थोडक्यात सांगायचे तर: AI एजंटला त्याचे काम पुन्हा करण्याची स्पष्ट परवानगी दिल्यास, अर्धवट दुरुस्तीचे रूपांतर पूर्ण सुधारणेमध्ये होऊ शकते. प्रॉम्प्ट डिझाइनर्सनी "पडताळणीसाठी टूल्स वापरा" याला केवळ एक ऐच्छिक गोष्ट न मानता एक 'सुरक्षा व्हॉल्व्ह' (safety valve) म्हणून पाहिले पाहिजे.