एआई की मूल बातें
AI एजेंट कैसे काम करते हैं: मॉडल, टूल, मेमोरी, और कंट्रोल लूप
एक AI एजेंट मॉडल को निर्देशों, टूल, मेमोरी और एक कंट्रोल लूप के साथ मिलाता है। यह समझना कि ये भाग कैसे परस्पर क्रिया करते हैं, एजेंटों की शक्ति और उनकी विफलताओं दोनों को स्पष्ट करता है।
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
एक AI एजेंट मॉडल को निर्देशों, टूल, मेमोरी और एक कंट्रोल लूप के साथ मिलाकर काम करता है, जो लगातार अगला क्या करना है, तय करता रहता है। मॉडल निर्णय और भाषा क्षमताएँ प्रदान करता है, जबकि आसपास का सॉफ़्टवेयर इन क्षमताओं को एक स्थितिगत प्रक्रिया में बदल देता है जो कार्य कर सकती है, परिणामों की जाँच कर सकती है, त्रुटियों से पुनः प्राप्त हो सकती है, और रुक सकती है।
इस वास्तुकला को समझना एजेंट को एकल बुद्धिमान वस्तु के रूप में मानने से अधिक उपयोगी है। अधिकांश सफलताएँ और विफलताएँ इस बात से उत्पन्न होती हैं कि घटक कैसे आपस में संवाद करते हैं: एक उत्कृष्ट मॉडल भी अस्पष्ट टूल, पुरानी मेमोरी, अत्यधिक अनुमतियों, या बिना विश्वसनीय समाप्ति परिभाषा वाले कंट्रोल लूप द्वारा कमजोर किया जा सकता है।
AI एजेंट के पाँच मुख्य भाग
1. मॉडल
मॉडल उद्देश्य को समझता है, उपलब्ध संदर्भ पर तर्क करता है, और एक कार्रवाई चुनता है। कई वर्तमान एजेंटों में, यह एक बड़ा भाषा मॉडल होता है जो निर्देशों का पालन कर सकता है और संरचित टूल कॉल्स तथा प्राकृतिक भाषा उत्पन्न कर सकता है।
सबसे सक्षम मॉडल स्वचालित रूप से हर चरण के लिए सर्वोत्तम विकल्प नहीं होता। कोई प्रणाली कठिन योजना को एक मजबूत मॉडल को भेज सकती है, वर्गीकरण के लिए तेज़ मॉडल का उपयोग कर सकती है, और सत्यापन के लिए निर्धारक कोड पर निर्भर हो सकती है। यह मिश्रण गति, लागत और विश्वसनीयता को सुधार सकता है।
2. निर्देश
निर्देश एजेंट की भूमिका, सीमाएँ, प्राथमिकताएँ और आउटपुट आवश्यकताओं को परिभाषित करते हैं। इनमें सिस्टम प्रॉम्प्ट, कार्य-विशिष्ट संदर्भ, नीतियाँ, उदाहरण, टूल विवरण, और समाप्ति मानदंड शामिल हो सकते हैं।
अच्छे निर्देश संचालन योग्य होते हैं। वे एजेंट को बताते हैं कि कौन सा प्रमाण आवश्यक है, कब अनुमोदन माँगना है, कौन से स्रोत स्वीकार्य हैं, और समाप्ति कैसे पहचानी जाए। अस्पष्ट या विरोधाभासी नियम मॉडल को अनुमान लगाने पर मजबूर करते हैं, जिससे समान कार्यों में असंगति उत्पन्न होती है।
3. टूल
टूल मॉडल को उसकी वर्तमान संदर्भ से बाहर की क्षमताओं से जोड़ते हैं। कोई टूल वेब खोज सकता है, ग्राहक रिकॉर्ड प्राप्त कर सकता है, कोड चला सकता है, डेटाबेस क्वेरी कर सकता है, ब्राउज़र नियंत्रित कर सकता है, या कैलेंडर इवेंट बना सकता है।
आमतौर पर मॉडल स्वयं फ़ंक्शन को निष्पादित नहीं करता। यह एक नामित टूल चुनता है और संरचित तर्क प्रस्तावित करता है। एजेंट रनटाइम उस अनुरोध को मान्य करता है, अनुमतियों की जाँच करता है, ऑपरेशन चलाता है, और परिणाम लौटाता है। यह विभाजन आवश्यक है: यह सॉफ़्टवेयर को बाहरी दुनिया पर प्रभाव डालने से पहले गलत या असुरक्षित कार्यों को अस्वीकार करने का अवसर देता है।
4. स्थिति और मेमोरी
स्थिति वह जानकारी है जो एजेंट को वर्तमान रन के दौरान चाहिए: उद्देश्य, बातचीत, योजना, अवलोकन, टूल आउटपुट, और पूर्ण किए गए चरण। मेमोरी इस अवधारणा का विस्तार करती है, उपयोगी जानकारी को तत्काल संदर्भ से परे रखती है, जैसे पूर्व प्राथमिकताएँ, दोहराव वाले तथ्य, या पिछले कार्यों से सीखे गए पाठ।
अधिक मेमोरी हमेशा बेहतर नहीं होती। अप्रासंगिक रिकॉर्ड संदर्भ को खपत करते हैं और मॉडल को पुरानी धारणाओं की ओर ले जा सकते हैं। प्रभावी मेमोरी सिस्टम तय करते हैं कि क्या संग्रहीत किया जाए, उसे कैसे व्यवस्थित किया जाए, कब पुनः प्राप्त किया जाए, और विरोधी या समाप्त जानकारी को कैसे संभाला जाए।
5. कंट्रोल लूप
कंट्रोल लूप वह समन्वय स्तर है जो प्रक्रिया को चलाता रहता है। यह वर्तमान स्थिति को मॉडल को भेजता है, प्रस्तावित कार्रवाई प्राप्त करता है, अनुमोदित टूल चलाता है, अवलोकन को रिकॉर्ड करता है, और फिर से मॉडल को बुलाता है।
Anthropic अपने मार्गदर्शक में एक एजेंट को एक संवर्धित भाषा मॉडल के रूप में वर्णित करता है जो पुनः प्राप्ति, टूल और मेमोरी जैसी क्षमताओं के साथ लूप में कार्य करता है building effective agents. OpenAI भी एजेंट निष्पादन को मॉडल, उसके टूल, और पर्यावरण के बीच निरंतर इंटरैक्शन के रूप में प्रस्तुत करता है From Model to Agent.
इंटरफ़ेस घटकों जितना ही महत्वपूर्ण हैं
एक आर्किटेक्चर आरेख प्रत्येक घटक को साफ़ रूप से अलग दिखा सकता है, लेकिन वास्तविक विश्वसनीयता उनके बीच के अनुबंधों पर निर्भर करती है। मॉडल को टूल विवरण चाहिए जो समान क्षमताओं को अलग पहचानें। रनटाइम को टाइप्ड तर्क और स्पष्ट त्रुटि स्थितियों की आवश्यकता होती है। मेमोरी पुनः प्राप्ति को स्रोत और ताज़ा जानकारी चाहिए। पूर्णता जाँचकर्ता को ऐसे मानदंड चाहिए जिन्हें परीक्षण किया जा सके, न कि यह महसूस कि उत्तर पर्याप्त है।
एक खोज टूल को विचार करें जो खाली सूची लौटाता है। यह परिणाम यह दर्शा सकता है कि कोई प्रासंगिक रिकॉर्ड नहीं है, क्वेरी गलत थी, उपयोगकर्ता के पास अनुमति नहीं है, या सेवा का समय समाप्त हो गया। यदि टूल सभी चार स्थितियों को एक ही आउटपुट में मिलाता है, तो मॉडल यह नहीं समझ पाएगा कि क्या हुआ। एक अच्छी तरह से डिज़ाइन किया गया इंटरफ़ेस संरचित प्रमाण लौटाता है: स्थिति, स्रोत, टाइमस्टैम्प, क्वेरी, परिणाम संख्या, और उपयुक्त होने पर मशीन-रीडेबल त्रुटि।
यह सिद्धांत संदर्भ पर भी लागू होता है। निर्देश, प्राधिकृत रिकॉर्ड, पुनः प्राप्त अंश, मॉडल-निर्मित नोट्स, और अविश्वसनीय बाहरी सामग्री को समान पाठ नहीं माना जाना चाहिए। उनके स्रोत और प्राधिकरण को लेबल करने से रनटाइम को नीति लागू करने में मदद मिलती है और मॉडल को प्रमाण को सही ढंग से तौलने में सहायता मिलती है। यह संदर्भ इंजीनियरिंग का व्यावहारिक रूप है: यह तय करना कि मॉडल कौन सी जानकारी देखता है, वह जानकारी कैसे व्यवस्थित है, और सिस्टम उसे क्या नियंत्रित करने देता है।
एक चरण-दर-चरण उदाहरण
कल्पना करें कि एक एजेंट को तीन संभावित आपूर्तिकर्ताओं की तुलना करने और एक सिफ़ारिश तैयार करने को कहा गया है।
| मॉडल | संदर्भ को समझता है और अगली कार्रवाई प्रस्तावित करता है। |
|---|---|
| रनटाइम | कॉल्स को मान्य करता है, टूल चलाता है, और अवलोकन लौटाता है। |
| मेमोरी | चरणों या सत्रों के बीच चयनित स्थिति ले जाता है। |
| कंट्रोल लूप | निर्णय लेता है कि जारी रखें, पुनः प्रयास करें, बढ़ाएँ, या रुकें। |
- लक्ष्य प्राप्त करें: एजेंट निर्णय मानदंड, समयसीमा, बजट, और आवश्यक आउटपुट पढ़ता है।
- उपलब्ध संदर्भ की जाँच करें: यह जांचता है कि आपूर्तिकर्ता के नाम, आंतरिक आवश्यकताएँ, और स्रोत दस्तावेज़ मौजूद हैं या नहीं।
- योजना बनाएं: यह प्रत्येक आपूर्तिकर्ता के लिए मूल्य निर्धारण, सुरक्षा जानकारी, सेवा शर्तें, और ग्राहक प्रमाण एकत्र करने का निर्णय लेता है।
- एक टूल चुनें: यह अनुमोदित दस्तावेज़ स्टोर को खोजता है या बाहरी शोध टूल को कॉल करता है।
- अवलोकन: रनटाइम परिणाम लौटाता है, जिसमें संभावित त्रुटियाँ या अनुपलब्ध फ़ील्ड शामिल हैं।
- स्थिति अपडेट करें: एजेंट ने जो सीखा उसे रिकॉर्ड करता है और अनसुलझे प्रश्नों को चिह्नित करता है।
- अनुकूलित करें: यह क्वेरी बदलता है, अन्य स्रोत से परामर्श करता है, या अनुपलब्ध दस्तावेज़ के लिए व्यक्ति से पूछता है।
- सत्यापित करें: यह जांचता है कि प्रत्येक सिफ़ारिश समर्थित है और तुलना समान मानदंडों का उपयोग करती है।
- रोकें या अनुमोदन का अनुरोध करें: यह एक मसौदा सिफ़ारिश बनाता है, लेकिन खरीद निर्णय अधिकृत व्यक्ति को छोड़ देता है।
महत्वपूर्ण बात यह है कि क्रम पूरी तरह से हार्ड-कोडेड नहीं था। सिस्टम ने जो पाया उसके आधार पर चरणों का चयन किया, लेकिन यह अभी भी निर्धारित सीमाओं के भीतर कार्य करता रहा।
योजना हमेशा एक अलग चरण नहीं होती
कुछ एजेंट कार्य करने से पहले पूरी योजना बनाते हैं। अन्य एक बार में एक कदम तय करते हैं। कई हाइब्रिड का उपयोग करते हैं: एक मोटी योजना बनाते हैं, अगली कार्रवाई निष्पादित करते हैं, और अवलोकनों के आने पर शेष योजना को संशोधित करते हैं।
लंबी, कठोर योजनाएँ पहली अप्रत्याशित परिणाम के बाद अप्रचलित हो सकती हैं। पूरी तरह प्रतिक्रियाशील एजेंट भटक सकते हैं या कार्य दोहरा सकते हैं। एक व्यावहारिक डिज़ाइन दिशा बनाए रखने के लिए पर्याप्त योजना रखता है, जबकि पर्यावरण बदलने पर पुनः योजना बनाने की अनुमति देता है।
ReAct फ्रेमवर्क तर्क को कार्यों और अवलोकनों के साथ इंटरलीव करने का एक बुनियादी उदाहरण है। इसका मुख्य अंतर्दृष्टि यह है कि बाहरी परिणाम अगले तर्क चरण को सुधार, परिष्कृत, या पुनः दिशा दे सकता है।
एजेंट कैसे जानते हैं कब रुकना है
रोकना एक प्रणाली डिज़ाइन समस्या है। एक मॉडल बहुत जल्दी सफलता घोषित कर सकता है, उद्देश्य पूरा होने के बाद भी सुधार जारी रख सकता है, या जब टूल बार‑बार विफल हो तो लूप कर सकता है।
विश्वसनीय एजेंट कई रोकने के तंत्र को मिलाते हैं:
- समाप्ति मानदंड: आवश्यक फ़ील्ड, पास किए गए परीक्षण, या सत्यापित उद्धरण जैसी स्पष्ट शर्तें।
- बजट: चरणों, समय, मॉडल टोकन, टूल कॉल, या लागत पर सीमाएँ।
- त्रुटि थ्रेशोल्ड: बार‑बार विफलताओं या कम‑विश्वास अवलोकनों के बाद वृद्धि।
- अनुमोदन गेट: उच्च‑प्रभाव या अपरिवर्तनीय कार्यों से पहले एक विराम।
- बाहरी ग्रेडर: निर्धारक जांच या अलग मॉडल जो मूल्यांकन करते हैं कि आउटपुट कार्य को पूरा करता है या नहीं।
सामान्य एजेंट आर्किटेक्चर
एकल-एजेंट लूप सबसे सरल डिज़ाइन है: एक मॉडल बार‑बार टूल का उपयोग करता है जब तक वह समाप्त नहीं हो जाता। इसे डीबग करना आसान है और अक्सर पर्याप्त होता है।
एक राउटर अनुरोध को वर्गीकृत करता है और उसे एक विशेष प्रॉम्प्ट, टूल सेट, या मॉडल को भेजता है। रूटिंग अप्रासंगिक विकल्पों को घटाता है और विभिन्न कार्यों पर अलग‑अलग नीतियां लागू कर सकता है।
एक ऑर्केस्ट्रेटर-वर्कर आर्किटेक्चर प्रमुख एजेंट को उप‑कार्य बनाने और उन्हें वर्करों को सौंपने देता है, फिर उनके परिणामों को संकलित करता है। यह तब उपयोगी है जब कार्य समानांतर चल सकता है या विभिन्न विशेषज्ञताओं की आवश्यकता होती है, लेकिन यह टोकन उपयोग और समन्वय विफलता मोड को बढ़ाता है।
एक इवैल्युएटर-ऑप्टिमाइज़र लूप जनरेशन को समीक्षात्मक प्रक्रिया से अलग करता है। एक घटक उत्तर उत्पन्न करता है; दूसरा इसे परिभाषित मानदंडों के विरुद्ध जांचता है; पहला इसे संशोधित करता है। यह तब अच्छा काम करता है जब गुणवत्ता मापनीय हो और पुनरावृत्ति के माध्यम से सुधार अतिरिक्त लागत के योग्य हो।
आमतौर पर क्या गलत होता है
- खराब टूल विवरण: मॉडल गलत क्षमता चुनता है या अमान्य तर्क प्रदान करता है।
- असीमित संदर्भ: लंबी प्रतिलिपियां अप्रासंगिक विवरण से भर जाती हैं और निर्णायक जानकारी को दफ़न कर देती हैं।
- मौन टूल त्रुटियां: खाली या आंशिक परिणाम को वैध अवलोकन माना जाता है।
- कमजोर ग्राउंडिंग: एजेंट रिकॉर्ड प्रणाली की जाँच करने के बजाय अनुमान पर कार्य करता है।
- अत्यधिक स्वायत्तता: एजेंट उचित समीक्षा सीमा के बिना महत्वपूर्ण कार्य कर सकता है।
- कोई ट्रैजेक्टरी मूल्यांकन नहीं: टीमें अंतिम उत्तर का मूल्यांकन करती हैं लेकिन यह नहीं देखतीं कि एजेंट कैसे पहुँचा।
विश्वसनीय एजेंटों के लिए डिज़ाइन सिद्धांत
कार्य को हल करने वाले सबसे छोटे आर्किटेक्चर से शुरू करें। एक निर्धारक वर्कफ़्लो ज्ञात चरणों को संभालना चाहिए; मॉडल के विवेक को केवल उन निर्णयों के लिए रखें जो वास्तव में व्याख्या की आवश्यकता रखते हैं। प्रत्येक टूल को संकीर्ण उद्देश्य, टाइप्ड इनपुट, स्पष्ट त्रुटि स्थितियाँ, और न्यूनतम विशेषाधिकार पहुँच दें।
स्थिति को दृश्यमान बनाएं। निदान के लिए आवश्यक प्रत्येक टूल कॉल, परिणाम, पुनः प्रयास, अनुमोदन, और मॉडल निर्णय को लॉग करें। इसे अनंत रूप से जोड़ने के बजाय पुरानी संदर्भ को संकुचित करें, और प्राधिकृत डेटा को मॉडल‑जनित सारांशों से अलग रखें।
रनटाइम को इस तरह डिज़ाइन करें कि विफलताएँ स्पष्ट हों। एक टूल को “कोई रिकॉर्ड नहीं मिला” और “अनुरोध विफल” के बीच अंतर करना चाहिए, और स्थिति स्टोर को सत्यापित तथ्यों और मॉडल‑जनित सारांशों में अंतर करना चाहिए। अन्यथा, मॉडल टाइमआउट के कारण हुई अनुपस्थिति को इस बात का प्रमाण मान सकता है कि कुछ मौजूद नहीं है।
अंत में, संपूर्ण प्रणाली का मूल्यांकन करें। एक ही कार्य को कई बार चलाएँ, सफलता और संसाधन उपयोग को मापें, और नीति उल्लंघन या नाजुक शॉर्टकट के लिए ट्रैजेक्टरी की जाँच करें। Anthropic के एजेंट मूल्यांकन मार्गदर्शक में जोर दिया गया है कि एजेंटों को कार्यों, दोहराने योग्य परीक्षण, प्रतिलिपियों, और ग्रेडरों की आवश्यकता होती है — न कि कुछ प्रभावशाली डेमो की।
AI एजेंट कैसे काम करते हैं, इसे याद रखने योग्य बातें
AI एजेंट एक निर्मित लूप है, केवल एक स्मार्ट मॉडल नहीं। मॉडल निर्णय लेता है; टूल कार्य करते हैं; मेमोरी स्थिति ले जाती है; पर्यावरण प्रमाण लौटाता है; और कंट्रोल लूप अगला क्या होता है, निर्धारित करता है।
जब इन भागों के स्पष्ट इंटरफ़ेस और सीमाएँ होती हैं, तो एजेंट खुले‑अंत वाले कार्यों को संभाल सकता है जो पारंपरिक ऑटोमेशन नहीं अनुमान लगा सकता। जब ये नहीं होते, तो स्वायत्तता अस्पष्टता को बढ़ा देती है। इसलिए एजेंट की गुणवत्ता प्रणाली डिज़ाइन, अनुमतियों, और मूल्यांकन पर उतनी ही निर्भर करती है जितनी कि आधारभूत मॉडल पर।
