सध्या प्रत्येक AI संभाषणात 'एजंट्स'चा (Agents) दबदबा आहे. डेमोमध्ये ते असे भासतात की जणू ते मानवी मदतीशिवाय विचार करणारे, रणनीती आखणारे आणि समस्या सोडवणारे स्वायत्त डिजिटल सहाय्यक आहेत. परंतु, जर तुम्ही त्यांच्या इंटरफेसच्या पलीकडे पाहिले, तर तुम्हाला त्यापेक्षा खूप साधी गोष्ट आढळेल. एजंट म्हणजे केवळ एका लूपमध्ये (loop) चालणारे लँग्वेज मॉडेल आहे. ही एक डिझाइन पॅटर्न आहे, कोणतीही चेतना नाही. हा फरक समजून घेणे महत्त्वाचे आहे कारण यामुळे तुम्ही या प्रणाली कशा प्रकारे तयार करता, डीबग करता आणि त्यांच्यावर विश्वास ठेवता यावर परिणाम होतो.
एजंट प्रत्यक्षात काय असतो
एक मानक चॅटबॉट हा 'सिंगल-शॉट फंक्शन' असतो. तुम्ही एक प्रॉम्प्ट टाइप करता. मॉडेल पुढचे टोकन्स प्रेडिक्ट करते आणि मजकुराचा एक ब्लॉक परत करते. त्यानंतर ते थांबते. त्याचे उत्तर अचूक होते की नाही हे ते तपासत नाही. वेब लिंक काम करते की नाही किंवा गणना बरोबर आहे की नाही याची ते पडताळणी करत नाही. ते तुम्हाला एकाच प्रयत्नात आपला सर्वोत्तम अंदाज देते आणि शांत होते.
एक एजंट त्या सिंगल शॉटला एका पुनरावृत्ती होणाऱ्या चक्रात (cycle) विभागतो. मॉडेल अजूनही मजकूर तयार करते, परंतु आता ते एका नियंत्रित लूपमध्ये कार्य करते जिथे ते बाह्य जगावर परिणाम करू शकते आणि जे घडते त्यावर प्रतिक्रिया देऊ शकते.
हे चक्र खालीलप्रमाणे दिसते:
- ध्येयाचे मूल्यांकन करणे आणि काय करायचे याबद्दल विचार करणे.
- एखादी कृती करणे, सहसा एखादे टूल किंवा API कॉल करून.
- त्या कृतीचा निकाल पाहणे/निरीक्षण करणे.
- त्या नवीन माहितीच्या आधारे पुन्हा विचार करणे.
जोपर्यंत कार्य पूर्ण होत नाही किंवा सिस्टम सुरक्षिततेच्या मर्यादेपर्यंत पोहोचत नाही, तोपर्यंत हे चक्र पुन्हा पुन्हा सुरू राहते. हेच संपूर्ण रहस्य आहे. तिथे कोणताही लपलेला 'रीझनिंग इंजिन' नाही. खरी जादू म्हणजे मॉडेलला वास्तविक साधनांमधील (tools) वास्तविक डेटा वापरून स्वतःचा मार्ग सुधारण्याची संधी देणे.
ReAct: विचार-कृती-निरीक्षण चक्र (Thought-Action-Observation Cycle)
हे लूप लागू करण्याचा सर्वात सामान्य मार्ग म्हणजे ReAct पॅटर्न आहे, ज्याचा अर्थ 'Reason plus Act' असा होतो. लूपच्या प्रत्येक फेरीमध्ये, मॉडेल तीन वेगवेगळ्या टप्प्यांमधून जाते.
प्रथम, मॉडेल एक Thought (विचार) तयार करते. ते सध्याच्या परिस्थितीवर विचार करते, स्वतःला मूळ ध्येयाची आठवण करून देते आणि पुढे काय जाणून घेण्याची गरज आहे याचा निर्णय घेते. दुसरे म्हणजे, ते एक Action (कृती) निवडते. हे वेब सर्च, डेटाबेस क्वेरी, कॅल्क्युलेटर कॉल किंवा फाईल वाचण्याची विनंती असू शकते. तिसरे म्हणजे, त्याला एक Observation (निरीक्षण) मिळते. सिस्टम मॉडेलच्या बाहेर ती कृती कार्यान्वित करते आणि त्याचा कच्चा निकाल संभाषणाच्या इतिहासात (conversation history) परत पाठवते. त्यानंतर मॉडेल त्या नवीन निरीक्षणाला आपली नवीन वास्तविकता मानून पुढचे लूप सुरू करते.
एक साधे उदाहरण घेऊया. समजा तुम्ही एजंटला ऑस्टिनमध्ये उद्या पाऊस पडेल का हे सांगण्यास सांगितले. मॉडेल विचार करू शकते, "मला ऑस्टिनसाठी हवामान अंदाजाची गरज आहे." त्याची कृती म्हणजे शहराचे नाव वापरून वेदर API कॉल करणे. निरीक्षण कच्च्या JSON स्वरूपात परत येते: तापमानाचे वाचन आणि पावसाची शक्यता. त्यानंतर मॉडेल पुन्हा विचार करते, "अंदाज ७० टक्के पावसाची शक्यता दर्शवतो," आणि त्याची अंतिम कृती त्या माहितीचे साध्या भाषेत रूपांतर करून तुम्हाला उत्तर देणे ही असते.
ही रचना महत्त्वाची आहे कारण ती मॉडेलला वास्तववादी बनवते. जर मॉडेलला पुढे जाण्यापूर्वी सर्च करणे आणि निकाल वाचणे अनिवार्य असेल, तर ते केवळ तथ्ये (facts) बनवू शकत नाही. निरीक्षण हे पुढच्या विचारासाठी एक कठोर बंधन (hard constraint) म्हणून काम करते. लूपमुळे चुकीची माहिती तयार करणे खूप कठीण होते कारण मॉडेलला बोलण्यापूर्वी पाहावे लागते.
विश्वसनीय लूप तयार करण्यासाठी तुम्हाला काय आवश्यक आहे
प्रोडक्शनमध्ये हा पॅटर्न चालवण्यासाठी केवळ हुशार प्रॉम्प्ट पुरेसा नाही. तुम्हाला तीन व्यावहारिक सुरक्षा उपाय (guardrails) लागू करावे लागतील.
स्टेप बजेट सेट करा. लूपच्या इटरेशन्सची कमाल संख्या नेहमी निश्चित करा. मर्यादा नसेल तर, एजंट स्वतःच्याच मागे धावू शकतो—सर्च करणे, निरीक्षण करणे, विचार करणे, पुन्हा सर्च करणे—जोपर्यंत तुमचा API बजेट संपत नाही. स्टेप लिमिटमुळे प्रक्रिया थांबवणे अनिवार्य होते. मर्यादा संपल्यानंतर तुम्हाला अर्धवट निकाल द्यायचा आहे, मानवी मदतीसाठी विचारणा करायची आहे की केवळ सुव्यवस्थितपणे प्रक्रिया थांबवायची आहे, याचा निर्णय तुम्ही घेऊ शकता.
कोड एक्झिक्यूशन स्वतः हाताळा. लँग्वेज मॉडेल टूल्स चालवत नाही. ते फक्त कृती सुचवते, सहसा स्ट्रक्चर्ड टेक्स्ट किंवा JSON आउटपुट देऊन, ज्यामध्ये टूलचे नाव आणि पॅरामीटर्स असतात. तुमचा कोड