हर कुछ महीनों में, इंडस्ट्री उस सॉफ्टवेयर के लिए एक नया शब्द गढ़ती है जो कथित तौर पर अपने आप सोच सकता है। अभी वह शब्द "Agentic AI" है। वेंडर्स इसे अपने लैंडिंग पेज और पिच डेक पर चिपकाने में बहुत फुर्ती दिखाते हैं। लेकिन एक लेबल केवल मार्केटिंग कॉपी है जब तक कि सिस्टम आपके वातावरण, आपके डेटा और आपकी विफलता के तरीकों (failure modes) का सामना न कर ले। यह शब्द अपने आप में सुरक्षा, विश्वसनीयता या उपयुक्तता के बारे में कुछ नहीं बताता।

अब समय आ गया है कि फीचर लिस्ट पढ़ना बंद करें और क्षमताओं को मापना शुरू करें।

लेबल की समस्या

सेल्स इंजीनियर्स आपको "एजेंटिक" आर्किटेक्चर के प्रमाण के रूप में डैशबोर्ड, मल्टी-मॉडल ड्रॉपडाउन मेनू और मोबाइल एक्सेस दिखाएंगे। वे इंटरफ़ेस के विकल्प हैं, व्यवहार संबंधी गारंटी नहीं। एक उत्पाद अत्याधुनिक दिख सकता है और फिर भी उस क्षण बिखर सकता है जब उसे API टाइमआउट के बाद अपनी योजना में संशोधन करने की आवश्यकता होती है।

महत्वपूर्ण यह है कि क्या सिस्टम वास्तव में एक स्वायत्त एजेंट (autonomous agent) की तरह व्यवहार करता है। क्या यह काम को चरणों में विभाजित करता है? क्या यह सख्त सीमाओं के भीतर वास्तविक सिस्टम पर कार्य करता है? जब कुछ टूटता है, तो क्या यह अनुकूलित होता है, या यह केवल विफल होकर प्रतीक्षा करता है? जब तक आप अपने स्टैक से संबंधित साक्ष्यों के साथ इन सवालों के जवाब नहीं देते, तब तक आप एक अवधारणा (concept) खरीद रहे हैं, उत्पाद नहीं।

पाँच क्षमता परीक्षण जो वास्तव में मायने रखते हैं

मैं हर एजेंटिक दावे का मूल्यांकन पाँच विशिष्ट क्षमताओं के आधार पर करता हूँ। प्रत्येक के लिए, मैं एक सरल ट्राइएज प्रश्न पूछता हूँ: क्या व्यवहार प्रलेखित (documented) है, पायलट में सत्यापित है, या अभी भी अज्ञात है? 'अज्ञात' ही डिफ़ॉल्ट है। अन्यथा सिद्ध करने का भार उत्पाद पर है।

प्लानिंग (Planning)। क्या सिस्टम एक अस्पष्ट लक्ष्य को क्रमबद्ध, सत्यापन योग्य चरणों में विभाजित करता है? कोई भी टू-डू लिस्ट बना सकता है। असली परीक्षण "इस तिमाही में हमारे क्लाउड खर्च को पंद्रह प्रतिशत कम करें" जैसे जटिल उद्देश्य को संभालने में है। एक वास्तविक एजेंट वर्तमान उपयोग के ऑडिट का खाका तैयार करता है, निष्क्रिय संसाधनों की पहचान करता है, राइटसाइजिंग सिफारिशों का मसौदा तैयार करता है, और उचित क्रम में परिवर्तन अनुरोधों (change requests) को शेड्यूल करता है। यदि यह आपको केवल पांच बिंदुओं वाला एक सामान्य निबंध थमा देता है और काम पूरा होने का दावा करता है, तो यह प्लानिंग नहीं है। यह केवल सारांश (summarizing) है।

टूल्स (Tools)। क्या यह एक निर्धारित दायरे के भीतर वास्तविक सिस्टम पर कार्य करता है? एक पॉलिश किए गए डेमो में मॉक API को कॉल करना आसान है। न्यूनतम-विशेषाधिकार क्रेडेंशियल्स (least-privilege credentials) के साथ आपके प्रोडक्शन CRM को प्रमाणित करना, एक रिकॉर्ड लिखना और लेनदेन को लॉग करना कठिन है। आपको ठीक से जानने की आवश्यकता है कि यह किन सिस्टमों को छूता है, इसके पास कौन सी कुंजियाँ (keys) हैं, और इसका ब्लास्ट रेडियस (blast radius) कहाँ समाप्त होता है। दायरा सीमित होना चाहिए। यदि एजेंट के पास डिफ़ॉल्ट रूप से प्रोडक्शन तक राइट एक्सेस है, तो आपके पास एजेंट नहीं है। आपके पास एक देनदारी (liability) है।

करेक्शन (Correction)। क्या यह विफलता के बाद अपना अगला कदम बदलता है? यहीं अधिकांश प्रोटोटाइप विफल हो जाते हैं। जब तीसरा चरण 503 एरर या स्कीमा मिसमैच (schema mismatch) देता है, तो क्या एजेंट अनंत काल तक लूप में रहता है, सफलता का संदेश मतिभ्रम (hallucinate) करता है, या अपना रास्ता बदलता है? वास्तविक करेक्शन का अर्थ है विफलता को देखना, वर्कफ़्लो के शेष भाग की पुन: योजना बनाना, और बाधाओं (constraints) को छोड़े बिना एक नया रास्ता निष्पादित करना। आशावाद में लिपटा हुआ एक 'रिट्राय लूप' करेक्शन नहीं है।

कॉन्टेक्स्ट (Context)। क्या यह हर चरण में बाधाओं (constraints) को सक्रिय रखता है? केवल मेमोरी पर्याप्त नहीं है। यदि पहला चरण "पाँच सौ डॉलर के बजट से अधिक न करें" या "EU ग्राहक डेटा को बाहर रखें" जैसा एक सख्त नियम स्थापित करता है, तो सातवां चरण उस सीमा को नज़रअंदाज़ नहीं कर सकता क्योंकि प्रॉम्प्ट कॉन्टेक्स्ट बदल गया है। यह अनुपालन नियमों (compliance rules), ब्रांड वॉइस, अनुमोदन पदानुक्रम (approval hierarchies) और एक्सेस कंट्रोल पर लागू होता है। कॉन्टेक्स्ट का संरक्षण वह जगह है जहाँ लॉन्ग-कॉन्टेक्स्ट मॉडल और क्लासिकल स्टेट मैनेजमेंट का मिलना आवश्यक है।

ओवरसाइट (Oversight)। क्या कोई इंसान प्रक्रिया को रोक या फिर से शुरू कर सकता है? आपको सर्किट ब्रेकर्स की आवश्यकता है जो सूक्ष्म (granular) हों, न कि केवल वर्चुअल मशीन पर एक किल स्विच। क्या कोई दूसरे चरण के बाद योजना का निरीक्षण कर सकता है और तीसरे चरण को मंजूरी दे सकता है? यदि कोई बाहरी निर्भरता (external dependency) विफल हो जाती है, तो क्या कोई इंसान स्टेट को खोए बिना वर्कफ़्लो को ठीक कर सकता है और फिर से शुरू कर सकता है? ओवरसाइट कोई ऑडिट लॉग नहीं है जिसे आप आपदा आने के बाद पढ़ते हैं। यह हस्तक्षेप के लिए एक लाइव तंत्र है।

चेकबॉक्स से बेहतर साक्ष्य

एक डेमो विश्वसनीयता दर नहीं है। वेंडर तुलना शीट पर एक चेकबॉक्स प्रमाण नहीं है। जब कोई अकाउंट एग्जीक्यूटिव कहता है कि उत्पाद "टेस्ट फेल होने के बाद संशोधन करता है", तो आपका अगला कदम साक्ष्य कार्ड (evidence card) मांगना होना चाहिए।

एक एविडेंस कार्ड चेकबॉक्स को विशिष्टता के साथ बदल देता है। यह इस प्रकार दिखता है:

  • क्षमता (Capability): करेक्शन
  • दावा (Claim): टेस्ट फेल होने के बाद संशोधन करता है
  • साक्ष्य (Evidence): नियंत्रित फिक्स्चर (controlled fixture) लंबित है
  • मालिक (Owner): डेवलपर-एक्सपीरियंस टीम
  • रुकें यदि (Stop if): संशोधन किसी स्वीकृत इंटरफ़ेस को बदल देता है

यह प्रारूप स्पष्टता सुनिश्चित करता है। यह मार्केटिंग दावों को प्रमाण से अलग करता है। यह स्वामित्व (ownership) निर्धारित करता है ताकि जब एजेंट अपने संशोधन के प्रयास के दौरान किसी स्वीकृत इंटरफ़ेस को तोड़ दे, तो आपको पता हो कि किस टीम को सूचित किया जाना है। बिना किसी मालिक के, कोई जवाबदेही नहीं होती। बिना स्टॉप कंडीशंस (stop conditions) के, कोई सुरक्षा कवच नहीं होता।

किसी भी पायलट को लॉन्च करने से पहले, तीन चीजों को लिखित रूप में परिभाषित करें। पहला, आपके कार्य (tasks)। ये वास्तविक बिजनेस लॉजिक से होने चाहिए, न कि सिंथेटिक बेंचमार्क से। दूसरा, आपके फेलियर टेस्ट (failure tests)। रन के बीच में किसी API key को रद्द कर दें, एक गलत (malformed) JSON रिस्पॉन्स डालें, या अपेक्षित लेटेंसी (latency) को दोगुना कर दें। तीसरा, आपकी स्टॉप कंडीशंस (stop conditions)। ये स्वचालित होनी चाहिए, न कि कोई मैनुअल पैनिक बटन जिसे आप उम्मीद करें कि कोई देख ले।

वेंडर के दावों की जांच कैसे करें

OpenAI का प्रस्ताव है कि एजेंटों को पांच घटकों की आवश्यकता होती है: models, tools, instructions, guardrails, और human intervention। आप इस सूची को उनके विशिष्ट आर्किटेक्चर को अपनाए बिना वेंडरों से सवाल पूछने के लिए एक शब्दावली के रूप में उपयोग कर सकते हैं।

पूछें कि कौन सा model केवल जनरेशन के बजाय प्लानिंग को संभालता है। पूछें कि कौन सी tool permissions हार्डकोडेड हैं और कौन सी डायनेमिक हैं। पूछें कि guardrails कहाँ लागू किए जाते हैं, प्रॉम्प्ट लेयर में या ऑर्केस्ट्रेशन इंजन में। पूछें कि क्या human intervention एक इन-बिल्ट चेकपॉइंट है या एजेंट द्वारा आपके डेटाबेस को खराब करने के बाद भेजा गया एक पोस्ट-मॉर्टम ईमेल है। आप OpenAI के स्टैक की खरीदारी नहीं कर रहे हैं। आप किसी और के सिस्टम की कमियों को उजागर करने के लिए उनके फ्रेमवर्क का उपयोग कर रहे हैं।

MonkeyCode एक ओपन-सोर्स रास्ता और एक मुफ्त क्लाउड वर्जन प्रदान करता है। यह संयोजन पायलट शुरू करना सस्ता बनाता है। लेकिन सस्ता प्रवेश प्रमाणित सफलता के समान नहीं है। सिस्टम के अज्ञात हिस्से तब तक अज्ञात रहते हैं जब तक आप अपने स्वयं के इंफ्रास्ट्रक्चर पर अपने स्वयं के कार्य नहीं चलाते। शून्य-डॉलर के टिकट को आपको यह सोचने के लिए धोखा न देने दें कि कठिन सवालों के जवाब मिल गए हैं।

खरीदारी का एक नियम जो बजट बचाता है

एक एजेंटिक पायलट को प्रोडक्शन प्रतिबद्धता (production commitment) में विस्तारित करने के लिए मेरा नियम सरल है। मैं स्कोप और बजट तभी बढ़ाता हूँ जब महत्वपूर्ण क्षमताओं का प्रमाण हो और विफलताओं के लिए एक स्पष्ट मालिक हो। रोडमैप स्लाइड नहीं। सपोर्ट टिकट क्यू (queue) नहीं। प्रमाण का अर्थ है आपके वातावरण से लॉग्स (logs)। मालिक का अर्थ है एक नामित व्यक्ति जो उस विशिष्ट विफलता मोड के लिए जिम्मेदार हो।

यदि वेंडर आपको प्रमाण नहीं दिखा सकता है, या यदि आपकी आंतरिक टीम किसी मालिक को नियुक्त नहीं कर सकती है, तो आप विस्तार करने के लिए तैयार नहीं हैं। आप परीक्षण जारी रखने के लिए तैयार हैं।

याद रखने योग्य: "Agentic" शब्द आपके मूल्यांकन के लिए शुरुआती संकेत (starting pistol) है। यह फिनिश लाइन नहीं है। इसे कठिन प्रश्न पूछने, अधिक सख्त पायलट चलाने और ऐसे प्रमाणों की मांग करने के लिए एक प्रॉम्प्ट के रूप में लें जो आपके संस्थान के भीतर मायने रखते हों। यदि उत्पाद आपके क्षेत्र में, आपकी विफलताओं के साथ, पांच क्षमता परीक्षणों को पास नहीं कर सकता है, तो यह वास्तव में एजेंटिक नहीं है। यह सिर्फ एक और डेमो है।

Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi