एजंटची कामगिरी सुधारू पाहणारे बहुतेक AI चमू त्याच उपायांकडे वळतात: मोठ्या कॉन्टेक्स्ट विंडो, अधिक कागदपत्रे आणि अधिक चतुर प्रॉम्प्ट. हा लेख सांगतो की ही प्रवृत्तीच पूर्णपणे चुकीची आहे. उणीव अधिक माहितीची नाही. ती नियंत्रणाची आहे. प्रात्यक्षिकात चालणारा एजंट आणि उत्पादनात चालणारा एजंट यांतील फरक सुयोग्य नियंत्रण स्तरामुळे निर्माण होतो.
AI एजंटला मोठी स्मृती, अधिक कागदपत्रे किंवा मोठी कॉन्टेक्स्ट विंडो दिल्याने तो अधिक हुशार होत नाही; तो केवळ अधिक संथ आणि खर्चिक होतो. सर्व काही एकाच वेळी वापरण्याऐवजी नेमके काय आणि कधी आवश्यक आहे ते निवडायला एजंटला शिकवल्याने खरी सुधारणा होते.
विश्वासार्हता मॉडेलमधून नव्हे, आवर्तनातून येते. प्रात्यक्षिकात प्रभाव पाडणारा एजंट आणि उत्पादनात टिकणारा एजंट यांतील फरक AI च्या गुणवत्तेत नसतो; प्रणाली स्वतःचे काम तपासते का, यात तो असतो. प्रत्येक टप्प्यावर नियोजन, कृती, निरीक्षण आणि पडताळणी करणारे एजंट आत्मविश्वासाने चुका करण्याऐवजी स्वतःच्या चुका पकडतात.
आजचे बहुतेक AI एजंट मुळात काही अतिरिक्त टप्पे असलेले संभाषण-सहाय्यक आहेत. आपण योग्य मार्गावर आहोत का, कधी थांबायचे किंवा वेगळा मार्ग कधी वापरायचा हे जाणण्याची यंत्रणाच त्यांच्याकडे नसते. स्पष्ट यश-निकष, संरचित स्थिती आणि प्रमाणीकरण तपासण्या असलेला योग्य नियंत्रण स्तर जोडल्यानेच एजंटसदृश वस्तूचे प्रत्यक्षात विश्वास ठेवता येईल अशा प्रणालीत रूपांतर होते.
काल दुपारच्या जेवणात तुम्ही काय खाल्ले?
बहुधा “काल + दुपारचे जेवण” सापडेपर्यंत तुम्ही आयुष्यातील प्रत्येक आठवण पुन्हा अनुभवली नसेल. या संकल्पना जिथे साठल्या आहेत, त्या अनुभवाच्या भागाकडे तुम्ही थेट वळलात. एजंट तयार करण्यासाठी हे उपयुक्त मानसिक प्रतिमान आहे:
प्रचंड कॉन्टेक्स्ट विंडो म्हणजे स्मृती नव्हे.
मिळवलेल्या कागदपत्रांचा ढीग म्हणजे आकलन नव्हे.
लांबलचक चेन-ऑफ-थॉट म्हणजे विश्वासार्हता नव्हे.
हे सर्व घटक आहेत. पण एजंटला खऱ्या एजंटसारखे भासवणारी गोष्ट तीच आहे, जिच्यामुळे तुमचा मेंदू आयुष्याच्या संपूर्ण इतिहासावर अंधाधुंद प्रक्रिया करत नाही: नियंत्रण.
अलीकडील मोठ्या भाषा मॉडेलसाठी एजंटिक रीझनिंग या सर्वेक्षणाने निर्मितीदरम्यान आपल्यापैकी अनेकांना जाणवलेल्या बदलाचा उत्कृष्ट सारांश दिला आणि त्याला नावही दिले: मॉडेलच्या आतील रीझनिंगकडून परस्परसंवादाद्वारे होणाऱ्या रीझनिंगकडे वाटचाल. ही पोस्ट त्या संशोधन निबंधाचा सारांश नाही. हा बदल व्यावहारिक प्रणाली रचनेत उतरवण्याचा हा प्रयत्न आहे:
एजंटना साधनांसह संभाषण-सहाय्यकांसारखे तयार केल्यास, त्याच प्रकारची अपयशे मिळत राहतील; फक्त चुका अधिक महाग असतील.
काही काळ “मॉडेल अधिक हुशार करण्याची” आपली नेहमीची कार्यपद्धती मुळात अशी होती: अधिक चांगले प्रॉम्प्ट, चेन-ऑफ-थॉट, स्व-सुसंगतता किंवा नमुना-आधारित सुधारणा आणि कदाचित थोडा शोध.
ReAct हा निर्णायक टप्पा होता, कारण त्याने “विचार → कृती → निरीक्षण” ही प्रक्रिया स्वाभाविक केली. पण यातील गर्भित मर्यादा लक्षात घ्या: यातील बरेच काही शेवटी “अधिक टोकनसह वन-शॉट अनुमान” ठरते. सर्वेक्षणाची मांडणी अधिक नेमकी आहे: एजंटिक रीझनिंगमध्ये चाचणीवेळेतील परस्परसंवाद वाढवण्यावर भर आहे. म्हणजे अनुमानाचे अशा पुनरावर्ती प्रक्रियेत रूपांतर करणे, जिथे मॉडेल, स्मृती आणि पर्यावरण सतत आवर्तनात राहतात.
प्रात्यक्षिकात प्रभावी पण प्रत्यक्ष कार्यप्रवाहात नाजूक वाटणारे एजंट तुम्ही तयार केले किंवा वापरले असतील, तर हे तुमच्यासाठी आहे.
मी वारंवार पाहिलेली, आणि स्वतःही अनेकदा तयार केलेली, एक पद्धत सांगतो:
एक चांगले गप्पांचे मॉडेल घ्या
काही साधने जोडा. उदा., शोध, DB क्वेरी किंवा कदाचित कोडची अंमलबजावणी
RAG जोडा
“तुम्ही स्वायत्त एजंट आहात” असा प्रणाली प्रॉम्प्ट जोडा
ते थांबेपर्यंत किंवा कालमर्यादा संपेपर्यंत सर्व काही while-loop मध्ये चालवा
अभिनंदन, तुमच्याकडे एजंटसदृश वस्तू तयार झाली आहे. पण ती ठरावीक प्रकारे अपयशी ठरते:
संदर्भाचा फुगवटा: प्रत्येक निरीक्षण जोडले जाते आणि प्रॉम्प्ट पुरातत्त्वीय थरांसारखे बनतात.
साधनांची अंदाधुंद हाताळणी: “चुकीचे साधन, पण पूर्ण आत्मविश्वासाने” हा अपयशाचा डीफॉल्ट प्रकार बनतो.
थांबण्याच्या अटी नाहीत: थांबायला हवे का याचा विचार न करता शक्य आहे म्हणून ते सुरूच राहते.
ग्राउंडिंगची शिस्त नाही: सक्तीने तपासायला लावल्याशिवाय आपली चूक झाली हे त्याला समजत नाही.
मेमरी = गप्पांचा इतिहास: म्हणजे मुळात नोंदी लिहून त्याला शिकणे म्हणणे.
म्हणूनच “एजंट” प्रात्यक्षिकांमध्ये जादुई, पण उत्पादनात अस्ताव्यस्त वाटतात. एजंटिक प्रणाली उत्पादनात आणण्याचा आमचा अनुभवही हेच दाखवतो: मॉडेलऐवजी संपूर्ण प्रणालीचे मूल्यमापन सुरू केल्यावर अपयशाच्या प्रकारांत दिशादर्शन, साधनांची शिस्त, संदर्भाची छाटणी आणि मूल्यमापनाची रचना यांचाही समावेश होतो; केवळ “मॉडेलने योग्य उत्तर दिले का” एवढाच प्रश्न राहत नाही.
मग प्रश्न असा पडतो: अपेक्षित एजंट नेमका कसा असावा?
हे कमी अमूर्त करण्यासाठी बहुतेकांना सहज कल्पना करता येईल असा एक साधा कार्यप्रवाह पाहूया: “पुढच्या मंगळवारी लंडनहून न्यूयॉर्कला जाणाऱ्या विमानाचे तिकीट आरक्षित करा. संध्याकाळी 6 पूर्वी पोहोचायचे आहे. खर्च £900 पेक्षा कमी ठेवा. मधल्या मार्गिकेजवळची आसनव्यवस्था हवी.”
“एजंटसदृश” अंमलबजावणी सामान्यतः अशी दिसते:
गरज नसली तरी विमानकंपनी किंवा प्रवास धोरणांची अनेक कागदपत्रे लगेच मिळवते.
शोध साधनाला आवाहन करते, परिणामांची मोठी यादी प्रॉम्प्टमध्ये चिकटवते आणि त्यातून “एक निवडते.”
आगमनाची वेळ, सामान, आसन किंवा धोरणाच्या मर्यादा न तपासता घाईने आरक्षण करते.
ते अयशस्वी झाल्यास किंचित वेगळ्या प्रकारे पुन्हा प्रयत्न करते, पण काय बदलले किंवा काय शिकले याची स्पष्ट कल्पना नसते.
मॉडेल रीझनिंग करू शकत नाही हा अपयशाचा प्रकार नाही; प्रणाली कार्यप्रवाह नियंत्रित करत नाही, ही खरी समस्या आहे.
अधिक एजंटिक आवृत्ती या कामाकडे स्पष्ट स्थिती आणि तपासण्या असलेली परस्परसंवादी प्रक्रिया म्हणून पाहते:
नियोजन: मर्यादा पुन्हा मांडा आणि अनुपलब्ध माहितीची यादी करा. उदा., “कोणत्या विमानतळाला प्राधान्य आहे?” किंवा “एक थांबा चालेल का?”
कृती: संरचित क्वेरीसह विमान शोधाला आवाहन करा. यात तारखेची व्याप्ती, आगमनाची मर्यादा आणि बजेट द्या.
निरीक्षण: परिणामांचा मोठा मजकूर चिकटवण्याऐवजी ते संक्षिप्त स्थिती ऑब्जेक्टमध्ये साठवा. उदा., किंमत, आगमन आणि मधले थांबे यांसह सर्वोत्तम 5 पर्याय.
अद्ययावत करणे: मर्यादा पूर्ण होत नसल्यास क्वेरी सुधारा. उदा., “संध्याकाळी 6 पूर्वी पोहोचण्याची अट खूप कठोर आहे. वेळेची व्याप्ती वाढवायची की बजेट?”
पडताळणी: प्रमाणीकार चालवा (“आगमन < 18:00,” “किंमत ≤ £900,” “धोरणाचे पालन,” “आसन निवड उपलब्ध”).
थांबा: आरक्षण API कडून पुष्टी मिळाल्यावर आणि सर्व प्रमाणीकारांच्या चाचण्या उत्तीर्ण झाल्यावरच.
झालेला बदल सूक्ष्म असला तरी निर्णायक आहे. माहिती मिळवणे सशर्त आहे, प्रतिक्षिप्त क्रिया नाही; संदर्भ व्यवस्थापित केला जातो, म्हणजे स्थिती संरचित असते, साचत नाही; आणि पडताळणी आवर्तनातच होते, ती वापरकर्त्यावर सोडली जात नाही. “विमानाचे तिकीट आरक्षित करणे” याऐवजी “खरेदी आदेश तयार करणे,” “परतावा देणे,” “उत्पादन संरचना बदलणे” किंवा “PR वितरित करणे” असे काम ठेवा; तत्त्व तेच राहते: एजंट कृती करू लागल्यावर प्रॉम्प्टपेक्षा आवर्तन महत्त्वाचे ठरते.
वर उल्लेखलेल्या सर्वेक्षणात एजंटिक रीझनिंगची तीन स्तरांत मांडणी केली आहे: मूलभूत (नियोजन, साधनांचा वापर, शोध), स्वयं-विकसनशील (अभिप्राय आणि स्मृती) आणि सामूहिक (अनेक एजंटमधील समन्वय).
पण यामागील सखोल कल्पना अशी आहे: रीझनिंग हे केवळ विश्वासार्ह वाटणारे चेन-ऑफ-थॉट तयार करण्यापुरते मर्यादित न राहता नियोजन, निर्णयप्रक्रिया आणि पडताळणीचे संघटनात्मक तत्त्व बनते. हा बदल तुमच्या स्थापत्यावर कसा परिणाम करतो हे पाहेपर्यंत ही कल्पना अमूर्त वाटते. तीन मुख्य मुद्दे लक्षात ठेवा:
चांगल्या एजंटने माहिती मिळवण्याकडे “हे नेहमीच करा” अशा दृष्टीने पाहू नये. माहिती मिळवणे हा निर्णय आहे, प्रतिक्षिप्त क्रिया नाही.
हा एक व्यावहारिक संकेत आहे:
तुमची प्रणाली प्रत्येक संवादात माहिती मिळवत असेल, तर तुम्ही माहितीप्राप्ती नव्हे, संदर्भ-कर तयार केला आहे.
प्रत्यक्ष कामात हे सतत दिसून येते. उत्पादनातील घटनेतील दोष शोधताना तुम्ही सर्व नोंदी संदर्भात टाकत नाही; सध्याच्या गृहीतकानुसार पुढे कोणती मापनमूल्ये किंवा नोंदी मिळवायच्या ते ठरवता. हीच “एजंटिक माहितीप्राप्ती” आहे. त्याची अधिक ठोस पद्धत अशी:
माहिती मिळवण्याची गरज आहे का ते ठरवा
गरज असल्यास: क्वेरीचा मसुदा करा, माहिती मिळवा, चाळा आणि आवश्यक भाग काढा
पुरावे परस्परविरोधी असल्यास: पुन्हा माहिती मिळवा
त्यानंतरच संश्लेषण करा
येथेच “एजंटिक RAG” पारंपरिक RAG पेक्षा वेगळे ठरते: माहिती मिळवणे हा डीफॉल्ट प्रक्रियाटप्पा न राहता विचारपूर्वक केलेला रीझनिंगचा टप्पा बनतो.
“मॉडेलचे” मूल्यमापन थांबवून “प्रणालीचे” मूल्यमापन सुरू करताच स्थितीचा मागोवा आणि ट्रेसिंग महत्त्वाचे ठरतात.
एजंट कार्यप्रवाहांची निरीक्षणक्षमता ही एक बाब आता उद्योगक्षेत्राने अधिक स्पष्टपणे स्वीकारली आहे. उदाहरणार्थ, OpenAI च्या Agents SDK मध्ये अंगभूत ट्रेसिंग आणि एजंटच्या रनची नोंद करणारा Traces डॅशबोर्ड आहे. यात निर्मिती, साधनांना केलेली आवाहने, हस्तांतरे, सुरक्षा मर्यादा आणि सानुकूल घटनांचा समावेश होतो, जेणेकरून प्रत्येक टप्प्यावर काय घडले यातील दोष शोधता आणि लेखापरीक्षण करता येते.
हे केवळ “असले तर चांगले” असे वैशिष्ट्य नाही. दोष शोधता येणारी प्रणाली आणि केवळ अंदाजाने तपासता येणारी प्रणाली यांतील हाच फरक आहे.
माझ्या मते, या सर्वेक्षणातील सर्वाधिक कृतीयोग्य भाग म्हणजे अभिप्रायाबद्दलची त्याची स्पष्ट भूमिका. त्यात अभिप्रायाच्या तीन पद्धती दिल्या आहेत: चिंतनशील अभिप्राय (निर्मिती → चिकित्सा → सुधारणा), प्राचलीय अनुकूलन (सूक्ष्म-जुळवणी किंवा RL द्वारे शिकणे) आणि प्रमाणीकार-आधारित अभिप्राय (प्रमाणीकाराची चाचणी उत्तीर्ण होईपर्यंत पुन्हा प्रयत्न करणे).
बहुतेक चमूंनी प्रमाणीकार-आधारित अभिप्रायापासून सुरुवात करावी, कारण तो साधा आणि परिणामकारक आहे. घटक चाचण्या करणारा, स्कीमा तपासणारा, व्यावसायिक नियम किंवा मर्यादा ठरवणारा (“वरिष्ठ मंजुरीशिवाय X पेक्षा जास्त परतावा नाही”) किंवा तथ्यात्मकता निश्चित करणारा (“संदर्भ आवश्यक”) कोणताही प्रमाणीकार लिहिता आला, तर अनिर्धारित मॉडेल आउटपुटचे प्रत्यक्षात विश्वास ठेवता येईल अशा परिणामात रूपांतर करता येते.
येथील आधी कल्पनाही नसलेल्या बदलांपैकी एक सोपा आहे: एजंटच्या जगात विश्वासार्हता अनेकदा मॉडेलपेक्षा आवर्तनातून अधिक मिळते.
प्रशिक्षणाशिवाय वर्तनात विश्वासार्ह सुधारणा करणारी मला सापडलेली ही सर्वांत छोटी आवर्तन-शिस्त आहे:
टप्प्याटप्प्याने काम करा: नियोजन → कृती → निरीक्षण → अद्ययावत करणे,
प्रत्येक कृतीनंतर निरीक्षणाचा सारांश 1–3 मुद्द्यांत द्या,
यशाचे निकष पूर्ण झाल्यावर किंवा बजेट संपल्यावर थांबा; आतापर्यंतचा सर्वोत्तम परिणाम आणि उरलेल्या अनिश्चितता द्या.
याचा उद्देश मॉडेलला पाल्हाळिक बनवणे नाही. प्रणाली समजण्याजोगी करणे आणि प्रत्येक टप्प्यावर “वास्तवाशी पडताळणी” करण्यास भाग पाडणे हा याचा उद्देश आहे. अभियंत्यांना सहज समजेल असे उदाहरण म्हणजे CI-सदृश बंद-आवर्तन ग्राउंडिंग:
नियोजन: बदलांची यादी सुचवा
कृती: चाचण्या किंवा लिंट चालवा
निरीक्षण: अपयशांचे विश्लेषण करा
अद्ययावत करणे: दुरुस्ती करून पुन्हा प्रयत्न करा
अपघाताने तयार झालेल्या एजंटची रचना उघड करणारे काही प्रश्न:
“काय मिळवायचे हे माझा एजंट ठरवतो का, की मी नेहमीच माहिती मिळवतो?”
माहिती मिळवणे बिनशर्त असेल, तर विलंब, खर्च, संदर्भाचे विरलीकरण आणि निकृष्ट इनपुटमुळे निकृष्ट आउटपुट मिळण्याचा वाढता धोका पत्करावा लागेल.
“आपली चूक झाली आहे हे माझ्या एजंटला समजू शकते का?”
तुमच्या एजंटसाठी “वापरकर्ता वैतागतो” हाच एकमेव अभिप्राय संकेत असेल, तर तुम्ही मानवी त्रासाच्या बळावर RL करत आहात. त्याला वास्तवाची जाणीव करून देण्याचा सर्वांत स्वच्छ मार्ग म्हणजे प्रमाणीकार-आधारित पुनःप्रयत्न आवर्तन.
“मेमरीमध्ये लिहिता येते का आणि ती कालांतराने सुधारते का?”
तुमची “स्मृती” फक्त गप्पांचा इतिहास जोडत असेल, तर मुळात तुम्ही नोंदीच लिहीत आहात. सर्वेक्षणात स्मृतीची मांडणी महत्त्वाची आहे: स्मृती म्हणजे केवळ संभाषणाची प्रतिलिपी नसून, एजंट कालांतराने परिष्कृत करत असलेला गतिशीलपणे वाढणारा संदर्भ आहे.
नोंदी काय घडले ते सांगतात, तर स्मृती पुढच्या वेळी काय करायचे ते सांगते. गप्पांचा इतिहास ही एक प्रतिलिपी आहे. पुढे काय जतन करणे उपयुक्त आहे याबद्दलचे सतत विकसित होणारे धोरण म्हणजे मेमरी.
कामाचा प्रकार, साधन आणि अपयशाचा प्रकार या कळांनुसार रचलेला, तसेच काय उपयोगी पडले व काय टाळावे यांची मूल्ये असलेला छोटासा “शिकलेले धडे” तक्ता ही व्यावहारिक सुरुवात ठरू शकते. परिपूर्ण ज्ञान आलेख तयार करणे हा उद्देश नाही. संचयीपणे सुधारणारे वर्तन निर्माण करणे हा उद्देश आहे: स्मृती आणि अभिप्रायामुळे एजंट “स्थितीविरहित सहाय्यकांपासून” कालांतराने सुधारणाऱ्या प्रणाली बनतात.
समस्येवर अधिक एजंट वापरण्याचा मोह होतो, पण त्यामुळे अनेकदा समन्वयाचा अतिरिक्त भार वाढतो. “किमान व्यवहार्य चमूची” एक चांगली पद्धत:
समन्वयक: कामाचे विभाजन करून जबाबदाऱ्या देतो
कार्यवाहक: साधनांना आवाहने करतो किंवा बदल अंमलात आणतो
चिकित्सक किंवा मूल्यमापक: अचूकता आणि धोका तपासतो
स्मृतीपाल: शिकलेले धडे लिहितो आणि निवडून जतन करतो
प्रत्येक एजंटची जबाबदारी स्पष्ट करता येत नसेल, तर कदाचित तुम्हाला अजून अनेक एजंटची गरज नाही.
हा प्रतिमान-बदल आपण खरोखर स्वीकारला, तर बहुधा प्रॉम्प्टमध्ये सर्व काही कोंबणे, अपयशांना अंतिम आउटपुट मानणे आणि एजंटचे संभाषण-सहाय्यकांसारखे मूल्यमापन करणे थांबवू. आणि एजंटकडे त्यांच्या खऱ्या स्वरूपात पाहू: भाषा हा नियंत्रण स्तर असलेल्या सॉफ्टवेअर प्रणाली म्हणून, जिथे विश्वासार्हता आवर्तनातून येते.
आणखी एक मॉडेल जोडण्यापूर्वी आणखी एक मूल्यमापन आवर्तन जोडा. सर्व माहिती मिळवण्यापूर्वी ती प्रक्रिया सशर्त करा. दहा प्रमाणीकार वितरित करण्यापूर्वी एक वितरित करा. स्मृतीकडे डेटाबेस म्हणून नव्हे, तर धोरणात्मक निर्णय म्हणून पाहा. आणि बहु-एजंट प्रणाली वापरताना वीस नव्हे, दोन एजंटपासून सुरुवात करा. हे नियम नाहीत; उत्पादनात टिकून राहिलेल्या या पद्धती आहेत.