बेहतर एजेंट प्रदर्शन चाहने वाली अधिकतर एआई टीमें उन्हीं उपायों का सहारा लेती हैं: बड़ी कॉन्टेक्स्ट विंडो, अधिक दस्तावेज़ और बेहतर प्रॉम्प्ट. यह लेख तर्क देता है कि यह प्रवृत्ति पूरी तरह गलत है. कमी अधिक जानकारी की नहीं है. कमी नियंत्रण की है. सुविचारित नियंत्रण परत ही डेमो में काम करने वाले एजेंट को उत्पादन में काम करने वाले एजेंट से अलग करती है.
एआई एजेंट को बड़ी स्मृति, अधिक दस्तावेज़ या लंबी कॉन्टेक्स्ट विंडो देने से वह बेहतर नहीं बनता, केवल धीमा और महंगा हो जाता है. वास्तविक लाभ एजेंट को सब कुछ एक साथ लेने के बजाय यह चुनना सिखाने से मिलता है कि उसे कब और क्या चाहिए.
विश्वसनीयता मॉडल से नहीं, लूप से आती है. डेमो में प्रभावित करने वाले और उत्पादन में टिकने वाले एजेंट का अंतर एआई की गुणवत्ता नहीं, बल्कि यह है कि सिस्टम अपना काम खुद जांचता है या नहीं. हर चरण में योजना, कार्रवाई, अवलोकन और सत्यापन करने वाले एजेंट पूरे भरोसे से गलत होने के बजाय अपनी गलतियां खुद पकड़ते हैं.
आज अधिकतर एआई एजेंट मूलतः कुछ अतिरिक्त चरणों वाले चैटबॉट हैं. उनके पास यह जानने का कोई तंत्र नहीं कि वे सही दिशा में हैं, कब रुकना है या कब दूसरा तरीका अपनाना है. उचित नियंत्रण परत—स्पष्ट सफलता मानदंड, संरचित स्थिति और सत्यापन जांच—ही एजेंट-जैसी वस्तु को वास्तव में भरोसेमंद बनाती है.
आपने कल दोपहर के भोजन में क्या खाया था?
शायद आपने “कल + दोपहर का भोजन” मिलने तक अपनी हर स्मृति दोबारा नहीं देखी. आप सीधे अनुभव के उस हिस्से तक पहुंचे, जहां ये अवधारणाएं मौजूद हैं. एजेंट बनाने के लिए यह एक उपयोगी मानसिक मॉडल है:
विशाल कॉन्टेक्स्ट विंडो स्मृति नहीं होती.
प्राप्त किए गए दस्तावेज़ों का ढेर समझ नहीं होता.
लंबी चेन-ऑफ-थॉट विश्वसनीयता नहीं होती.
वे केवल घटक हैं. लेकिन जो चीज़ किसी एजेंट को सचमुच एजेंट जैसा बनाती है, वही आपके मस्तिष्क को पूरे जीवन का इतिहास खंगालने से बचाती है: नियंत्रण.
हाल के सर्वेक्षण—बड़े भाषा मॉडल के लिए एजेंटिक रीज़निंग—ने निर्माण के दौरान हममें से कई लोगों द्वारा महसूस किए गए बदलाव को बहुत अच्छी तरह समझाया (और नाम दिया): मॉडल के अंदर रीज़निंग से अंतःक्रिया के माध्यम से रीज़निंग तक. यह पोस्ट उस शोधपत्र का सारांश नहीं है. यह उस बदलाव को व्यावहारिक सिस्टम डिज़ाइन में ढालने का प्रयास है:
यदि आप एजेंटों को टूल वाले चैटबॉट की तरह बनाएंगे, तो चैटबॉट वाली विफलताएं मिलती रहेंगी, बस गलतियां अधिक महंगी होंगी.
कुछ समय तक “मॉडल को बेहतर बनाने” की हमारी सामान्य कार्ययोजना मूलतः यह थी: बेहतर प्रॉम्प्ट, चेन-ऑफ-थॉट, आत्म-संगति / नमूना-आधारित सुधार और शायद थोड़ी खोज.
रीऐक्ट एक निर्णायक मोड़ था, क्योंकि उसने “विचार → कार्रवाई → अवलोकन” को सहज बना दिया. लेकिन अंतर्निहित सीमा पर ध्यान दें: इसका बड़ा हिस्सा अब भी “वन-शॉट अनुमान, लेकिन अधिक टोकन के साथ” बन जाता है. सर्वेक्षण का दृष्टिकोण अधिक स्पष्ट है: एजेंटिक रीज़निंग परीक्षण-समय की अंतःक्रिया बढ़ाने पर जोर देती है—अनुमान को ऐसी पुनरावृत्त प्रक्रिया बनाना, जिसमें मॉडल, स्मृति और परिवेश सभी लूप में रहें.
यदि आपने ऐसे एजेंट बनाए (या इस्तेमाल किए) हैं जो डेमो में प्रभावशाली, मगर वास्तविक कार्यप्रवाहों में नाज़ुक लगते हैं, तो यह आपके लिए है.
मैं एक ऐसा तरीका बताता हूं जिसे मैंने अक्सर देखा है (और निस्संदेह खुद भी इसके संस्करण बनाए हैं):
एक अच्छा चैट मॉडल लें
कुछ टूल जोड़ें (खोज, डेटाबेस क्वेरी, शायद कोड चलाना)
आरएजी जोड़ें
“आप एक स्वायत्त एजेंट हैं” वाला सिस्टम प्रॉम्प्ट जोड़ें
सब कुछ तब तक पुनरावृत्ति लूप में चलाएं, जब तक वह रुके या समय सीमा पूरी हो जाए
बधाई हो, आपके पास एजेंट-जैसी वस्तु है. लेकिन यह अक्सर अनुमानित तरीकों से विफल होती है:
संदर्भ का फुलाव: हर अवलोकन जुड़ता जाता है; प्रॉम्प्ट पुरातात्विक परतें बन जाते हैं.
टूल का अंधाधुंध प्रयोग: “गलत टूल, मगर पूरे विश्वास से” सामान्य विफलता बन जाती है.
रुकने की कोई शर्त नहीं: वह चलता रहता है क्योंकि चल सकता है, न कि इसलिए कि चलना चाहिए.
ग्राउंडिंग का अनुशासन नहीं: जब तक आप मजबूर न करें, वह अपनी गलती नहीं पहचानता.
मेमोरी = चैट इतिहास: जो मूलतः लॉग लिखकर उसे सीखना कह देना है.
इसीलिए “एजेंट” डेमो में अक्सर जादुई और उत्पादन में अस्त-व्यस्त लगते हैं. एजेंटिक सिस्टम को उत्पादन में उतारने का हमारा अनुभव भी यही दिखाता है: जब आप मॉडल के बजाय सिस्टम का मूल्यांकन करते हैं, तो विफलताओं में संचालन, टूल अनुशासन, संदर्भ की छंटाई और मूल्यांकन डिज़ाइन भी शामिल होते हैं, न कि केवल “क्या मॉडल ने सही उत्तर दिया.”
तो प्रश्न बनता है: अभिप्रेत एजेंट क्या है?
इसे कम अमूर्त बनाने के लिए एक सरल कार्यप्रवाह देखें, जिसकी अधिकतर लोग कल्पना कर सकते हैं: “अगले मंगलवार लंदन से न्यूयॉर्क की उड़ान बुक कर दो. शाम 6 बजे से पहले पहुंचना है. कीमत £900 से कम हो. गलियारे की ओर वाली सीट हो.”
एक आम “एजेंट-जैसा” क्रियान्वयन ऐसा दिखता है:
तुरंत विमान सेवा / यात्रा नीतियों के ढेर सारे दस्तावेज़ प्राप्त करता है, भले ही अभी उनकी आवश्यकता न हो.
खोज टूल बुलाता है, परिणामों की लंबी सूची प्रॉम्प्ट में चिपकाता है और “कोई एक चुन लेता है.”
सीमाओं (पहुंचने का समय / सामान / सीट / नीति) की पुष्टि किए बिना समय से पहले बुकिंग कर देता है.
विफल होने पर थोड़ा अलग तरीके से फिर प्रयास करता है, लेकिन यह स्पष्ट नहीं होता कि क्या बदला या उसने क्या सीखा.
विफलता का कारण यह नहीं कि मॉडल रीज़निंग नहीं कर सकता, बल्कि यह है कि सिस्टम कार्यप्रवाह को नियंत्रित नहीं करता.
अधिक एजेंटिक संस्करण कार्य को स्पष्ट स्थिति और जांचों वाली संवादात्मक प्रक्रिया मानता है:
योजना: सीमाएं दोहराएं + अनुपलब्ध जानकारी सूचीबद्ध करें (जैसे, “कौन-सा हवाई अड्डा पसंद है?” / “क्या 1 ठहराव स्वीकार्य है?”).
कार्रवाई: संरचित क्वेरी (तारीख सीमा, पहुंचने के समय की सीमा, बजट) के साथ उड़ान खोज बुलाएं.
अवलोकन: परिणाम किसी विशाल चिपकाए गए ढेर के बजाय संक्षिप्त स्थिति ऑब्जेक्ट में रखें (कीमत/पहुंच/ठहराव सहित शीर्ष 5 विकल्प).
अद्यतन: सीमाएं पूरी न हों तो क्वेरी सुधारें (जैसे, “शाम 6 बजे से पहले पहुंचने की सीमा बहुत सख्त है—समय सीमा बढ़ाएं या बजट?”).
सत्यापन: सत्यापनकर्ता चलाएं (“पहुंच < 18:00,” “कीमत ≤ £900,” “नीति के अनुरूप,” “सीट चयन उपलब्ध”).
रुकें: केवल तब, जब बुकिंग एपीआई पुष्टि लौटाए और सभी सत्यापन सफल हों.
बदलाव सूक्ष्म है, लेकिन निर्णायक है. पुनर्प्राप्ति सशर्त है (स्वतः प्रतिक्रिया नहीं), संदर्भ व्यवस्थित है (स्थिति संरचित है, संचित नहीं) और सत्यापन लूप में है (उपयोगकर्ता पर नहीं छोड़ा गया). “उड़ान बुक करने” की जगह “खरीद आदेश बनाने,” “धनवापसी जारी करने,” “उत्पादन विन्यास बदलने” या “पीआर जारी करने” को रखें और बात वही रहती है: एजेंट के कार्रवाई कर सकने पर लूप प्रॉम्प्ट से अधिक महत्वपूर्ण हो जाता है.
ऊपर उल्लिखित सर्वेक्षण एजेंटिक रीज़निंग को तीन स्तरों में बांटता है: बुनियादी (योजना/टूल उपयोग/खोज), स्व-विकसित (प्रतिपुष्टि + स्मृति) और सामूहिक (बहु-एजेंट समन्वय).
लेकिन गहरा विचार यह है: रीज़निंग केवल संभावित चेन-ऑफ-थॉट बनाने के बजाय योजना, निर्णय और सत्यापन का संगठनकारी सिद्धांत बन जाती है. यह तब तक अमूर्त लगता है, जब तक आप इसे अपनी संरचना में होने वाले बदलावों से नहीं जोड़ते. तीन मुख्य बातें याद रखें:
अच्छे एजेंट को पुनर्प्राप्ति को “हमेशा करना है” नहीं मानना चाहिए. पुनर्प्राप्ति एक निर्णय है, स्वतः प्रतिक्रिया नहीं.
एक व्यावहारिक सामान्य नियम यह है:
यदि आपका सिस्टम हर बार जानकारी प्राप्त करता है, तो आपने पुनर्प्राप्ति नहीं, संदर्भ कर बनाया है.
वास्तविक काम में यह बार-बार दिखाई देता है. उत्पादन संबंधी घटना की त्रुटि खोजते समय आप सभी लॉग संदर्भ में नहीं डालते; अपनी मौजूदा परिकल्पना के आधार पर तय करते हैं कि आगे कौन-से मेट्रिक/लॉग लेने हैं. यही “एजेंटिक पुनर्प्राप्ति” है. इसका अधिक ठोस तरीका यह है:
तय करें कि पुनर्प्राप्ति आवश्यक है या नहीं
यदि हां: क्वेरी बनाएं, जानकारी लाएं, सरसरी तौर पर पढ़ें, उपयोगी अंश निकालें
यदि साक्ष्य परस्पर विरोधी हों: फिर जानकारी लाएं
उसके बाद ही निष्कर्ष तैयार करें
यहीं “एजेंटिक आरएजी” पारंपरिक आरएजी से अलग होने लगता है: पुनर्प्राप्ति पाइपलाइन का तयशुदा चरण नहीं, बल्कि सोच-समझकर उठाया गया रीज़निंग कदम बनती है.
जैसे ही आप “किसी मॉडल” के बजाय “किसी सिस्टम” का मूल्यांकन शुरू करते हैं, स्थिति की निगरानी और अनुरेखण महत्वपूर्ण हो जाते हैं.
अब उद्योग एजेंट कार्यप्रवाहों की प्रेक्षणीयता को लेकर अधिक स्पष्ट हो गया है. उदाहरण के लिए, OpenAI के एजेंट एसडीके में अंतर्निहित अनुरेखण और एक अनुरेखण डैशबोर्ड मिलता है, जो एजेंट के निष्पादन (जनरेशन, टूल कॉल, हस्तांतरण, सुरक्षा सीमाएं और कस्टम घटनाएं) दर्ज करता है, ताकि आप हर चरण में हुई घटना की त्रुटियां खोज सकें और उसका ऑडिट कर सकें.
यह कोई “हो तो अच्छा” वाली सुविधा नहीं है. यही त्रुटियां खोजे जा सकने वाले सिस्टम और केवल अंदाज़े से परखे जा सकने वाले सिस्टम का अंतर है.
मेरे विचार में, सर्वेक्षण का सबसे उपयोगी हिस्सा प्रतिपुष्टि के बारे में उसकी स्पष्टता है. यह प्रतिपुष्टि को तीन व्यवस्थाओं में बांटता है: चिंतनशील प्रतिपुष्टि (बनाएं → समीक्षा करें → संशोधित करें), प्राचलीय अनुकूलन (सूक्ष्म समायोजन / आरएल से सीखें) और सत्यापनकर्ता-आधारित प्रतिपुष्टि (सत्यापन सफल होने तक फिर प्रयास करें).
अधिकांश टीमों को सत्यापनकर्ता-आधारित प्रतिपुष्टि से शुरुआत करनी चाहिए, क्योंकि यह साधारण मगर प्रभावी है. यदि आप कोई भी ऐसा सत्यापनकर्ता लिख सकते हैं जो इकाई परीक्षण करे, स्कीमा जांचे, व्यावसायिक नियम / सीमाएं तय करे (“बिना उच्च स्तर की मंज़ूरी के X से अधिक धनवापसी नहीं”) या तथ्यात्मकता सुनिश्चित करे (“संदर्भ आवश्यक हैं”), तो आप अनिश्चित मॉडल आउटपुट को वास्तव में भरोसेमंद बना सकते हैं.
यहां के “अज्ञात अज्ञात” बदलावों में से एक सरल है: एजेंट की दुनिया में विश्वसनीयता अक्सर मॉडल से अधिक लूप से आती है.
प्रशिक्षण के बिना व्यवहार को भरोसेमंद ढंग से सुधारने वाला सबसे छोटा अनुशासित लूप मुझे यह मिला है:
चरणों में काम करें: योजना → कार्रवाई → अवलोकन → अद्यतन,
हर कार्रवाई के बाद अवलोकन को 1–3 बिंदुओं में संक्षेपित करें,
सफलता के मानदंड पूरे होने या बजट सीमा आने पर रुकें; अब तक का सर्वोत्तम परिणाम और शेष अनिश्चितताएं लौटाएं.
इसका उद्देश्य मॉडल को अधिक शब्दाडंबरपूर्ण बनाना नहीं है. इसका उद्देश्य सिस्टम को समझने योग्य बनाना और हर चरण में उसका “वास्तविकता से सामना” कराना है. अभियंताओं के लिए एक परिचित उदाहरण सीआई-शैली की बंद-लूप ग्राउंडिंग है:
योजना: बदलावों की सूची सुझाएं
कार्रवाई: परीक्षण / लिंट चलाएं
अवलोकन: विफलताओं का विश्लेषण करें
अद्यतन: सुधार करके फिर प्रयास करें
कुछ प्रश्न जो अनजाने में बने एजेंट डिज़ाइन की कमियां उजागर कर देते हैं:
“क्या मेरा एजेंट चुनता है कि क्या प्राप्त करना है, या मैं हमेशा जानकारी प्राप्त करता हूं?”
यदि पुनर्प्राप्ति हर हाल में होती है, तो आपको विलंब, लागत, संदर्भ के कमजोर पड़ने और घटिया इनपुट से घटिया आउटपुट मिलने के अधिक जोखिम की कीमत चुकानी पड़ेगी.
“क्या मेरा एजेंट समझ सकता है कि वह गलत है?”
यदि आपके एजेंट का एकमात्र प्रतिपुष्टि संकेत “उपयोगकर्ता का नाराज़ होना” है, तो आप मानवीय पीड़ा के सहारे आरएल कर रहे हैं. सत्यापनकर्ता-आधारित पुनः प्रयास लूप उसे वास्तविकता से रूबरू कराने का सबसे साफ तरीका है.
“क्या स्मृति में लिखा जा सकता है और क्या वह समय के साथ बेहतर होती है?”
यदि आपकी “स्मृति” केवल चैट इतिहास जोड़ती जाती है, तो आप मूलतः लॉग लिख रहे हैं. सर्वेक्षण में स्मृति की अवधारणा महत्वपूर्ण है: स्मृति केवल प्रतिलेख नहीं, बल्कि लगातार बढ़ता संदर्भ बनती है, जिसे एजेंट समय के साथ निखारते हैं.
लॉग बताते हैं कि क्या हुआ, जबकि स्मृति बताती है कि अगली बार क्या करना है. चैट इतिहास एक प्रतिलेख है. स्मृति इस बात की विकसित होती नीति है कि आगे क्या साथ रखना उपयोगी है.
व्यावहारिक शुरुआत के लिए “सीखे गए सबक” की छोटी तालिका बनाएं, जिसमें कार्य का प्रकार, टूल और विफलता का तरीका कुंजी हों तथा क्या सफल रहा और किससे बचना है, उसका मान हो. उद्देश्य एक आदर्श ज्ञान ग्राफ बनाना नहीं है. उद्देश्य लगातार बेहतर होता व्यवहार बनाना है: स्मृति + प्रतिपुष्टि एजेंटों को “स्थितिविहीन सहायकों” से समय के साथ बेहतर होने वाले सिस्टम में बदल देती हैं.
समस्या पर अधिक एजेंट लगाने का लोभ होता है, लेकिन इससे अक्सर समन्वय का अतिरिक्त बोझ कई गुना बढ़ जाता है. “न्यूनतम उपयोगी टीम” का एक अच्छा तरीका:
समन्वयक: काम बांटता + सौंपता है
निष्पादक: टूल कॉल / बदलाव करता है
समीक्षक/मूल्यांकनकर्ता: शुद्धता/जोखिम जांचता है
स्मृति संरक्षक: सबक लिखता/व्यवस्थित करता है
यदि आप नहीं बता सकते कि हर एजेंट किसका उत्तरदायी है, तो शायद अभी आपको कई एजेंटों की आवश्यकता नहीं है.
यदि हम सचमुच इस प्रतिमान बदलाव को स्वीकारते हैं, तो शायद हर चीज़ प्रॉम्प्ट में ठूंसना, विफलताओं को अंतिम आउटपुट मानना और एजेंटों को चैटबॉट की तरह परखना बंद कर देंगे. और एजेंटों को वही मानना शुरू करेंगे जो वे हैं: ऐसे सॉफ्टवेयर सिस्टम जिनमें भाषा नियंत्रण तल है और विश्वसनीयता लूप से आती है.
एक और मॉडल जोड़ने से पहले एक और मूल्यांकन लूप जोड़ें. सब कुछ प्राप्त करने से पहले पुनर्प्राप्ति को सशर्त बनाएं. दस जारी करने से पहले एक सत्यापनकर्ता जारी करें. स्मृति को डेटाबेस नहीं, नीतिगत निर्णय मानें. और बहु-एजेंट व्यवस्था अपनाते समय बीस नहीं, दो एजेंटों से शुरुआत करें. ये नियम नहीं, बल्कि उत्पादन में सफल रहे तरीके हैं.