ADLC: AI कोडिंग के लिए क्लॉड कोड (Claude Code) का नया लाइफसाइकिल
AAI LABS
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00आप ने शायद यह बार-बार सुना होगा कि सॉफ्टवेयर डेवलपमेंट बदल गया है,
00:00:03लेकिन सिर्फ नए टूल्स को अपनाना तो ऊपरी बदलाव था,
00:00:06क्योंकि आज जो सिस्टम बनाए जा रहे हैं, वे पुराने सॉफ्टवेयर की तरह काम नहीं करते।
00:00:10इसलिए, जिन फ्रेमवर्क्स पर कंपनियां काम कर रही थीं, उन्हें भी बदलना पड़ा,
00:00:14क्योंकि अगर आप पुरानी प्रक्रिया पर ही निर्माण जारी रखेंगे, तो ऐसी समस्याएं आएंगी जिन्हें सुलझाने का कोई तरीका नहीं होगा।
00:00:18तो इस बदलते परिदृश्य की ज़रूरतों को पूरा करने के लिए,
00:00:21डेवलपर कम्युनिटी में एक नया फ्रेमवर्क उभरा है जिसे एजेंट्स को ध्यान में रखकर बनाया गया है।
00:00:25और इस वीडियो के अंत तक, हम आपको इस नए लाइफसाइकिल फ्रेमवर्क के बारे में बताएंगे
00:00:29और यह भी कि आपको इसे अपनाने की जरूरत क्यों है।
00:00:31कई सालों से, सॉफ्टवेयर डेवलपमेंट SDLC का उपयोग करके किया जाता रहा है।
00:00:35सॉफ्टवेयर डेवलपमेंट लाइफसाइकिल दशकों से इस्तेमाल होने वाली एक संरचित प्रक्रिया है,
00:00:39जिसमें डिजाइन, डेवलपमेंट, टेस्टिंग, डिप्लॉयमेंट, मेंटेनेंस और लगातार सपोर्ट जैसे कई चरण शामिल हैं।
00:00:45इसके पीछे मुख्य विचार यह है कि सॉफ्टवेयर को बिजनेस लक्ष्यों और यूजर की जरूरतों को ध्यान में रखकर विकसित किया जाना चाहिए,
00:00:51जहां हर चरण का आउटपुट अगले चरण का इनपुट बनता है।
00:00:54लेकिन यह सिर्फ तब तक काम आया जब तक AI ने टेक्नोलॉजी के क्षेत्र में कदम नहीं रखा था।
00:00:57जब से AI ने रफ्तार पकड़ी है, सबसे पहली चीज जिसने इसे रिप्लेस करना शुरू किया, वह कोडिंग थी।
00:01:02AI से पहले, डेवलपमेंट का मतलब बार-बार कोड लिखने का सिस्टम था,
00:01:06जो अक्सर दूसरी जगहों से स्निपेट्स और लॉजिक को मिलाकर एक ऐसा सिस्टम बनाने की दोहराव वाली प्रक्रिया थी जो समस्या को हल कर सके।
00:01:12इसलिए जैसे-जैसे मॉडल्स बेहतर होते गए, और Claude Code और Cursor जैसे टूल्स इंडस्ट्री पर राज करने लगे,
00:01:18तो अकेले SDLC अब नाकाम साबित हुआ है।
00:01:20यह खुद को बनाए नहीं रख सकता, और सही वैल्यू देने के लिए इसमें बदलाव की जरूरत है।
00:01:24इसीलिए एजेन्टिक डेवलपमेंट लाइफसाइकिल, या ADLC, को विकसित किया गया था।
00:01:28यह SDLC और मौजूदा टेक स्पेस के बीच की खाई को पाटता है।
00:01:32ADLC की जरूरत इसलिए थी क्योंकि जिन सिस्टम्स में SDLC का इस्तेमाल होता था,
00:01:36वहां प्लानिंग के समय ही आपको सिस्टम का व्यवहार पता होता था, और उसे वेरीफाई करने के तरीके भी थे।
00:01:41सीधे शब्दों में कहें तो, SDLC सॉफ्टवेयर को एक स्थिर (static) चीज मानता है, जबकि ADLC इसे एक जीवंत प्रणाली (living system) मानता है।
00:01:47अब चूंकि AI एजेंट्स अप्रत्याशित होते हैं, और क्योंकि वे वास्तव में रीज़निंग और कार्यों को खुद ढालकर विकसित हो रहे होते हैं
00:01:53उस माहौल के हिसाब से जिसमें वे हैं, इसलिए उन्हें उन्हीं मैट्रिक्स पर आंकना मुश्किल हो जाता है जिनका उपयोग पारंपरिक सॉफ्टवेयर करता है।
00:01:59पहली बात तो यह है कि ADLC को विकसित करने का पूरा कारण प्रोडक्शन में AI एजेंट का नॉन-डिटरमिनिज्म (गैर-नियतत्ववाद) है।
00:02:05AI एजेंट्स के साथ, लगातार लर्निंग और निरंतर डेवलपमेंट होता रहता है,
00:02:09और आप यह तय नहीं कर सकते कि एजेंट का आउटपुट कैसा दिखेगा।
00:02:12जब आप AI के साथ काम कर रहे होते हैं, तो आपके फैसले प्रॉम्ट, कॉन्टेक्स्ट, मॉडल्स,
00:02:16और आपके द्वारा कनेक्ट किए गए सभी बाहरी टूल्स पर निर्भर करते हैं।
00:02:18मॉडल्स अपने आप में अभी भी अप्रत्याशित हैं, इसलिए हम 100% सटीकता के साथ यह तय नहीं कर सकते कि एक प्रॉम्ट क्या रिटर्न करेगा।
00:02:25इसके साथ, आपके पास मूल रूप से अलग सफलता के मैट्रिक्स होते हैं जो SDLC उपयोग करता है।
00:02:29ADLC के 7 चरण हैं, और प्रत्येक चरण किसी न किसी तरह से सटीक SDLC चरण से मेल खाता है।
00:02:36चाहे आप एजेन्टिक सिस्टम पर काम कर रहे हों या नहीं, पहला कदम हमेशा प्लानिंग ही रहता है।
00:02:41जो बदलता है वह यह है कि आप इसे कैसे करते हैं।
00:02:43एजेंट्स के लिए, आप उस तरह से प्लान नहीं कर सकते जैसे आप नॉन-एजेन्टिक सिस्टम्स के लिए करते हैं,
00:02:46क्योंकि पारंपरिक प्रणालियों के विपरीत, लॉजिक का फ्लो यहां उसी तरह लागू नहीं होता।
00:02:51तो ADLC का पहला चरण, तैयारी और परिकल्पना (preparation and hypothesis),
00:02:54किसी भी सिस्टम डिज़ाइन या मॉडल को तय करने से पहले समस्या की एक ठोस समझ बनाने का लक्ष्य रखता है।
00:02:59जब एजेंट्स की बात आती है, तो आपको यह समझना होगा कि यूजर्स सिस्टम के साथ कैसे इंटरैक्ट करेंगे
00:03:04और सभी स्टेकहोल्डर्स के साथ तालमेल बिठाना होगा ताकि यह पता लगाया जा सके कि वर्कफ़्लो कहाँ टूटता है
00:03:07और बार-बार किए जाने वाले मैनुअल प्रयास कैसे दिखते हैं, क्योंकि एजेंट वास्तव में इसी को हल करेगा।
00:03:12फिर आप मौजूदा वर्कफ़्लोज़ और पॉलिसियों की समीक्षा करते हैं यह देखने के लिए कि चीजें वर्तमान में कैसे संभाली जा रही हैं,
00:03:16और एक बार जब यह स्पष्ट हो जाता है, तो आप परीक्षण योग्य परिकल्पनाएँ बनाते हैं कि एजेंट्स कहाँ वर्कफ़्लो में सहायता या ऑटोमेशन करेंगे।
00:03:22अगर हम इस चरण को पूरी तरह से छोड़ देते हैं, तो हम गलत काम को ऑटोमेट कर बैठेंगे,
00:03:26और समस्या को ठीक करने के बजाय, यह चीजों को और खराब कर सकता है।
00:03:28यहाँ SDLC की तुलना में मुख्य अंतर व्यवहार (behavior) का है।
00:03:31SDLC में, व्यवहार का अनुमान लगाया जा सकता था क्योंकि एक ही इनपुट हमेशा एक ही आउटपुट देता था।
00:03:37लेकिन मॉडल की भागीदारी के कारण ADLC प्रोबेबिलिस्टिक (संभाव्यता आधारित) है,
00:03:40और एक जैसे इनपुट कभी भी बिल्कुल एक जैसे आउटपुट की ओर नहीं ले जा सकते।
00:03:43इस ज्ञान के साथ, पहला कदम जो आपको करना है वह है प्लानिंग मोड चालू करना
00:03:47और आप जिस भी एजेंट का उपयोग कर रहे हैं, उससे उस एजेंट के व्यवहार की योजना बनवाएं जिसे आप विकसित कर रहे हैं, न कि उसके इम्प्लीमेंटेशन की।
00:03:52उसे कोड के बारे में न सोचने के लिए प्रॉम्ट करें और इसके बजाय पूरे वर्कफ़्लो का खाका तैयार करने को कहें,
00:03:56कि एजेंट्स यूजर्स के साथ कैसे इंटरैक्ट करते हैं, क्या गलत हो सकता है, क्या ओवरहेड हो सकता है,
00:04:00और सिस्टम के बारे में अन्य सभी धारणाएँ क्या हैं।
00:04:03उस तरह से, आपका एजेंट बनाने का प्रोसेस मूल धारणाओं के साथ शुरू होता है,
00:04:06जो सीधे आर्किटेक्चर प्लानिंग में कूदने की तुलना में एक बेहतर गाइड साबित होती हैं।
00:04:10एक बार शुरुआती प्लानिंग हो जाने के बाद, ठीक बाद में एक और लेयर होती है,
00:04:13जहाँ आप स्कोप और समस्या की ठीक से पहचान करते हैं।
00:04:16यह वास्तव में SDLC के एनालिसिस फेज या फिजिबिलिटी स्टडी से मेल खाता है,
00:04:20जहाँ आप बिजनेस आवश्यकताओं का विश्लेषण करते थे और यह देखते थे कि इम्प्लीमेंटेशन व्यवहार्य है या नहीं।
00:04:25तो ADLC का यह चरण महत्वपूर्ण प्रक्रियाओं और उन्हें हल करने में AI की भूमिका की पहचान करने से मेल खाता है,
00:04:31मजबूरियों और तकनीकी सीमाओं को चिह्नित करता है,
00:04:33और समय, लागत, लेटेंसी और फिजिबिलिटी जैसे स्पष्ट बिजनेस और तकनीकी KPIs को पहले ही परिभाषित करता है।
00:04:39आप इस बिंदु पर ट्रेड-ऑफ़ को भी परिभाषित करते हैं, यह जानते हुए कि कौन से कारक स्वीकार्य हैं और कौन से नहीं।
00:04:44लेकिन इस चरण का सबसे महत्वपूर्ण हिस्सा ह्यूमन-एजेंट रिस्पॉन्सिबिलिटी मॉडल को ठीक से मैप करना है,
00:04:49क्योंकि यह एक जवाबदेही संरचना (accountability structure) बनाता है।
00:04:52एक इंसान को अभी भी उनकी समीक्षा करने की आवश्यकता है, क्योंकि हम सभी फैसलों के लिए एजेंट पर भरोसा नहीं कर सकते।
00:04:56इस चरण के अंत तक, आपके पास उचित डॉक्यूमेंटेशन होता है जहाँ वर्कफ़्लो चरणों को मुख्य KPIs के साथ स्पष्ट रूप से परिभाषित किया जाता है,
00:05:02और ह्यूमन-एजेंट रिस्पॉन्सिबिलिटी मॉडल को स्पष्ट रूप से सामने रखा जाता है।
00:05:05यह इसलिए मायने रखता है क्योंकि किसी भी विफलता के मामले में, आप पूरी तरह से मॉडल को दोष नहीं दे सकते।
00:05:09जवाबदेही अंततः इंसानों के पास ही रहनी चाहिए।
00:05:12अब इस मानवीय जिम्मेदारी की प्लानिंग की पहले आवश्यकता नहीं थी, क्योंकि कोई AI शामिल नहीं था।
00:05:17यह एजेंट की ऑटोनॉमी (स्वायत्तता) की सीमाओं को परिभाषित करता है, और यदि आप इस कदम को छोड़ देते हैं,
00:05:21तो आप प्रोडक्शन में अपने स्वयं के अनुपालन (compliance) और जवाबदेही को जोखिम में डाल रहे हैं।
00:05:24एजेंट्स के साथ ऐसा करने के लिए, आप फिर से प्लानिंग मोड का उपयोग करते हैं, उसे वर्कफ़्लोज़, लेटेंसी, सिस्टम समस्याओं,
00:05:30उन सभी फीचर्स जो आर्किटेक्चर में होने चाहिए, और विफलता कैसी दिख सकती है, की योजना बनाने के लिए प्रॉम्ट करते हैं।
00:05:34एक बार जब ये स्पष्ट रूप से बता दिए जाते हैं, तो एजेंट निर्माण के दौरान आगे बढ़ने के लिए सही स्कोप को समझ जाता है।
00:05:39स्कोप और हाई-लेवल फीचर्स परिभाषित होने के साथ, अब डिज़ाइन चरण में जाने का समय आ गया है।
00:05:43इस स्टेज में, हम खुद एजेंट के लिए सिस्टम आर्किटेक्चर को परिभाषित कर रहे हैं।
00:05:47यहाँ आप तय करते हैं कि एजेंट किस पैटर्न का पालन करेगा, जैसे ReAct या प्लान-एंड-एक्ट या मल्टी-एजेंट सेटअप या जो भी दृष्टिकोण आप चाहते हैं।
00:05:54फिर आप एक बिंदु से दूसरे बिंदु तक डेटा फ्लो की योजना बनाते हैं, और कई एजेंट्स की भागीदारी के साथ यह बहुत अधिक महत्वपूर्ण हो जाता है।
00:06:00एजेंट को सही डेटा मिलना चाहिए, अन्यथा यह मदद करने के बजाय समस्याएं पैदा करेगा।
00:06:05आप लागत संरचनाओं जैसे टोकन इकोनॉमिक्स, कॉन्टेक्स्ट एडिटिंग फीचर्स, कॉम्पैक्शन की भी योजना बनाते हैं,
00:06:10और समझते हैं कि इस एजेंट को प्रोडक्शन में डिप्लॉय करने की लागत कैसी दिखेगी,
00:06:14और तब क्या होगा जब यह कई यूजर्स को संभालना शुरू करेगा।
00:06:17अब यही वह जगह है जहाँ आप वास्तव में चुनते हैं कि आप कौन से मॉडल उपयोग करना चाहते हैं, आप किस ऑर्केस्ट्रेशन फ्रेमवर्क के साथ जा रहे हैं,
00:06:23डेटाबेस, और शामिल अन्य सभी तकनीकें, और यहीं पर आप परिभाषित करते हैं कि सफलता कैसी दिखेगी
00:06:28कोई भी कोड लिखे जाने से पहले, ताकि आप TDD के साथ एजेंट बना सकें।
00:06:32आपका सिस्टम लाइव होने से पहले, आप लेटेंसी, सटीकता, मतिभ्रम (hallucinations) और इसी तरह के मुद्दों में ट्रेड-ऑफ़ पर पहले ही विचार कर चुके होते हैं।
00:06:38इस चरण को आपके एजेंट के प्लानिंग मोड की भी आवश्यकता होती है।
00:06:41आप इसे एजेंट आर्किटेक्चर, डेटा फ्लो, कॉस्ट मॉडल को कवर करने वाला एक व्यापक डिज़ाइन तैयार करने के लिए प्रॉम्ट देते हैं,
00:06:46और समग्र तकनीकी संरचना ताकि आप एक ठोस योजना के साथ अगले कदम पर बढ़ें।
00:06:51शुरुआती योजनाएं पूरी होने के बाद, अगला कदम सिमुलेशन और प्रूफ ऑफ वैल्यू (मूल्य का प्रमाण) है।
00:06:55यहाँ आप पहले के चरणों में बनाई गई धारणाओं का परीक्षण करने के लिए वास्तविक दुनिया के डेटा का उपयोग करते हैं।
00:06:59आप प्रोटोटाइप बनाते हैं ताकि आप यह पता लगा सकें कि इस एजेंट के निर्माण के साथ आगे बढ़ना सार्थक है या नहीं।
00:07:04मूल रूप से, यह वह जगह है जहाँ आप तय करते हैं कि आपको एजेंट विकसित करना भी चाहिए या नहीं, क्योंकि इस स्टेज पर विफलता की लागत बहुत कम होती है।
00:07:10तो यहाँ की मुख्य गतिविधियों में व्यावहारिक परीक्षण के लिए डेटासेट या ग्राउंड ट्रुथ (ground truth) तैयार करना शामिल है,
00:07:15प्रोटोटाइप बनाना ताकि आप उन हाई-रिस्क धारणाओं का परीक्षण कर सकें जिन्हें आपने पहले डॉक्यूमेंट किया था,
00:07:19और डेटा क्वालिटी, हैलुसिनेशन रेट, सटीकता, रिस्पॉन्स क्वालिटी और बेंचमार्क को मान्य (validate) करना।
00:07:25आप शुरुआती परिकल्पना पर भी दोबारा गौर करते हैं यह निर्धारित करने के लिए कि क्या यह निवेश पर रिटर्न (ROI) प्रदान करेगी।
00:07:30डिलीवरेबल्स उचित रूप से मापे गए परफॉर्मेंस और कॉस्ट बेसलाइन हैं,
00:07:33पहले बताए गए ग्राउंड ट्रुथ डॉक्यूमेंट के साथ, जो रिग्रेशन टेस्टिंग और मॉडल फाइन-ट्यूनिंग के लिए एक टेस्टिंग एसेट के रूप में कार्य करता है।
00:07:40यह चरण एक वैलिडेशन गेट की तरह काम करता है।
00:07:42यदि आपके परिणाम यहाँ से अगले चरण में जाते हैं, तो आप एजेंट पर काम करना जारी रख सकते हैं।
00:07:46यदि नहीं, तो यह निर्माण एक विफलता है, और इसका जल्दी पता लगाना बहुत बेहतर है,
00:07:50क्योंकि अगर यह चीज प्रोडक्शन में पहुंच जाती, तो नुकसान कहीं ज्यादा बुरा होता।
00:07:54ऐसा करने के लिए, आप अपने AI एजेंट को पहला प्रोटोटाइप बनाने के लिए प्रॉम्ट करते हैं ताकि आप अपनी अभी-अभी की गई सभी प्लानिंग के मुकाबले इसका परीक्षण कर सकें।
00:08:00लेकिन आगे बढ़ने से पहले, आइए हमारे स्पॉन्सर, Softer के बारे में कुछ बातें जान लें।
00:08:04वाइब कोडिंग टूल्स UI जेनरेट करने के लिए बेहतरीन हैं, लेकिन जैसे ही आपको वास्तविक ऑथेंटिकेशन,
00:08:08यूज़र रोल, परमिशन, या ऐसे डेटाबेस की ज़रूरत होती है जो वास्तव में स्केल कर सके, तो सब कुछ बिखर जाता है और आप फिर से कोड लिखने लगते हैं।
00:08:14Softer एक AI ऐप बिल्डर है जो सिर्फ एक प्रॉम्ट में यह सब संभाल लेता है।
00:08:18आप अपनी आवश्यकता को सरल अंग्रेजी में बताते हैं, और AI को-बिल्डर एक ही बार में पूरा स्टैक, डेटाबेस, पेज, नेविगेशन, लॉगिन और रोल-आधारित परमिशन्स जेनरेट कर देता है।
00:08:28ये केवल प्रोटोटाइप पेज नहीं हैं, ये वास्तव में काम करते हैं।
00:08:30आप ऐप का प्रिव्यू कर सकते हैं, जांच सकते हैं कि प्रत्येक यूजर रोल क्या देखता है, और जब आप पब्लिश पर क्लिक करते हैं, तो आपका ऐप होस्टिंग, यूजर ग्रुप्स, एंटरप्राइज-ग्रेड सिक्योरिटी और एक्सेस कंट्रोल के साथ लाइव हो जाता है।
00:08:40और इसे मेंटेन करने के लिए आपको किसी डेवलपर की आवश्यकता नहीं है।
00:08:42सब कुछ विजुअल है ताकि आप स्वयं वर्कफ़्लोज़ को अपडेट कर सकें, यूजर्स को मैनेज कर सकें और फीचर्स जोड़ सकें।
00:08:47सॉफ्टवेयर की वास्तविक लागत इसे बनाने में नहीं, बल्कि इसे मेंटेन करने में है, और Softer इसी को हल करता है।
00:08:52डिस्क्रिप्शन में दिए गए लिंक पर क्लिक करके अपने फ्री AI क्रेडिट्स प्राप्त करें और शुरुआत करें।
00:08:57यह प्लानिंग फेज के अंत को चिह्नित करता है, और यह हमें उस हिस्से पर लाता है जिस पर बहुत से लोग सीधे कूद पड़ते हैं, जो कि इम्प्लीमेंटेशन है।
00:09:03पिछले कदम वास्तव में महत्वपूर्ण हैं क्योंकि यदि आपने उन्हें ठीक से किया है, तो आप उन समस्याओं में नहीं फंसेंगे जो ज्यादातर लोग उन चरणों को छोड़ने के कारण यहाँ झेलते हैं।
00:09:11तो यह वह समय है जब आप वास्तव में अपने एजेंट को विकसित करते हैं, कोर लॉजिक बनाते हैं, और अपने डेवलपमेंट वर्कफ़्लो को ऑर्केस्ट्रेट करते हैं।
00:09:16और यहाँ आप SDLC और ADLC के बीच सबसे स्पष्ट विभाजनों में से एक देखते हैं।
00:09:20SDLC में, लॉजिक कोड, कॉन्फ़िगरेशन और थर्ड-पार्टी डिपेंडेंसीज़ में रहता है।
00:09:25ADLC में, वह लॉजिक कोड, प्रॉम्ट्स, मॉडल्स, टूल्स और बाहरी सर्विसेज में फैल जाता है।
00:09:30तो अब आप सिर्फ सॉफ्टवेयर मैनेज नहीं कर रहे हैं, आप इन सभी लेयर्स को एक साथ मैनेज कर रहे हैं, और इनमें से कोई भी एक सिस्टम के व्यवहार को बदल सकता है।
00:09:38यदि आपके पास विकसित करने के लिए मल्टी-एजेंट सिस्टम हैं, तो आपके वर्कफ़्लोज़ को ऑर्केस्ट्रेट करने का एक तरीका Claude code में नया एजेंट्स व्यू (agents view) है।
00:09:44एजेंट्स व्यू का उपयोग करके, आप नियमित Claude उपयोग की तुलना में कार्यों को बहुत बेहतर तरीके से डेलिगेट कर सकते हैं।
00:09:49क्योंकि अलग-अलग Claude code सेशन्स को मैनेज करने के बजाय, आप एक सिंगल ऑर्केस्ट्रेशन लेयर को मैनेज करते हैं और इसके माध्यम से सभी एजेंट्स के तालमेल के लिए एजेंट मैनेजर प्रॉम्ट्स देते हैं।
00:09:57अब इस बिंदु पर, आप MCPs और APIs जैसे टूल्स को इंटीग्रेट करते हैं।
00:10:01उदाहरण के लिए, यदि आप एक पर्सनल असिस्टेंट बना रहे हैं, तो आप जानते हैं कि उसे Google Calendar MCP, Gmail MCP, और शायद Notion MCP जैसी चीज़ों की आवश्यकता होगी।
00:10:09और यहाँ सबसे महत्वपूर्ण बात कॉन्टेक्स्ट मैनेजमेंट (context management) है।
00:10:11क्योंकि एक बार जब आप प्रोडक्शन के लिए एजेंट बना लेते हैं, तो यह सबसे महत्वपूर्ण पहलुओं में से एक बन जाता है।
00:10:16अभी उपलब्ध सबसे बड़ी कॉन्टेक्स्ट विंडोज़, जैसे Gemini और Opus में 1 मिलियन टोकन विंडोज़, को भी सावधानीपूर्वक संभालने की आवश्यकता होती है।
00:10:24आपको यह सुनिश्चित करना होगा कि एजेंट सही मेमोरी रखे और कॉन्टेक्स्ट रॉट (context rot) से बचे।
00:10:28क्योंकि अगर उसके पास बहुत अधिक अप्रासंगिक जानकारी हो जाती है, तो उसका ध्यान चारों ओर बिखर जाता है और आउटपुट खराब हो जाते हैं।
00:10:34आवश्यकताओं के विरुद्ध एजेंट सेटअप को मैन्युअल रूप से मान्य करके हर बदलाव के बाद व्यावहारिक निरंतरता सुनिश्चित करने के लिए आपको इस स्टेज के दौरान डेवलपर की ओर से भी परीक्षण करना होगा।
00:10:44एजेन्टिक सिस्टम्स में डेवलपमेंट और वैलिडेशन अलग-अलग नहीं हैं।
00:10:48आप निरंतर टेस्टिंग के बिना आगे नहीं बढ़ सकते क्योंकि एक छोटा सा बदलाव भी पूरे वर्कफ़्लो पर बहुत बड़ा प्रभाव डाल सकता है।
00:10:54इसलिए बाद में केवल एक अलग टेस्टिंग स्टेप पर भरोसा करने के बजाय अपना एजेंट बनाते समय साथ ही साथ डेवलपर स्तर के वैलिडेशन की आवश्यकता होती है।
00:11:01अपने सिस्टम का निर्माण पूरा करने के बाद, टेस्टिंग अगला चरण बन जाता है।
00:11:05जैसा कि पहले उल्लेख किया गया है, निर्माण प्रक्रिया के दौरान टेस्टिंग जारी रहनी चाहिए, लेकिन एक बार जब आपका सिस्टम बन जाता है, तो आप इसे अलग-अलग कंपोनेंट्स के बजाय प्रोडक्शन जैसी स्थितियों में टेस्ट करते हैं।
00:11:14यह वह स्टेज है जहाँ आप इंटीग्रेटेड टेस्टिंग करते हैं।
00:11:16आप यूजर एक्सेप्टेंस टेस्टिंग (UAT) भी करते हैं, जहाँ आप सिस्टम के वास्तविक यूजर्स से फीडबैक एकत्र करते हैं और इसे वापस सिस्टम में शामिल करते हैं।
00:11:24आप पूर्वाग्रह (bias), अनुपालन (compliance), परफॉर्मेंस और अन्य जोखिम से जुड़े आयामों जैसे कई कारकों पर टेस्ट करते हैं ताकि लाइव होने से पहले यह सुनिश्चित हो सके कि रिलीज सुरक्षित है।
00:11:32और यही वह जगह भी है जहाँ सफलता के मैट्रिक्स पूरी तरह से बदल जाते हैं।
00:11:35SDLC में, आप उन टेस्ट्स के साथ फंक्शनल करेक्टनेस को मापते थे जो बस पास या फेल होते थे।
00:11:40ADLC में, आप सटीकता वितरण (accuracy distribution), हैलुसिनेशन रेट और लागत प्रति परिणाम (cost per outcome) को मापते हैं क्योंकि उनमें से कोई भी साफ तौर पर एक सिंगल पास या फेल में नहीं सिमटता।
00:11:48टेस्टिंग का प्रतिमान (paradigm) खुद इसके साथ बदल जाता है।
00:11:50SDLC में, पहले से परिभाषित टेस्ट्स ज्ञात कोड पाथ्स को मान्य करते थे।
00:11:54ADLC में, वह रीज़निंग, सेफ्टी और टूल के उपयोग का निरंतर मूल्यांकन बन जाता है क्योंकि एजेंट एक ही रास्ते पर दो बार एक ही तरह से नहीं चलता।
00:12:02RAGAS और DEEPVAL जैसे कई इवैल्यूएशन फ्रेमवर्क्स हैं, लेकिन मुख्य चीज़ जो शुद्धता की पुष्टि करती है वह यह है कि आपका डेटा आपके द्वारा पहले परिभाषित मैट्रिक्स के मुकाबले कैसा प्रदर्शन करता है।
00:12:12और एक एजेन्टिक सिस्टम का परीक्षण करने के कई तरीके हैं, जिनमें फंक्शनल, नॉन-फंक्शनल, स्ट्रक्चरल और लोड टेस्टिंग शामिल हैं।
00:12:18इनमें से प्रत्येक को पूरी तरह से किया जाना चाहिए, अक्सर खुद एजेन्टिक सिस्टम्स का उपयोग करके ताकि प्रोडक्शन में पहुंचने से पहले एज केसेस की ठीक से पहचान की जा सके और उन्हें ठीक किया जा सके।
00:12:27साथ ही, यदि आप हमारे कंटेंट का आनंद ले रहे हैं, तो हाइप बटन दबाने पर विचार करें क्योंकि यह हमें इस तरह का और कंटेंट बनाने और अधिक लोगों तक पहुँचने में मदद करता है।
00:12:34एक बार जब आपका सिस्टम तैयार हो जाता है, तो इसे डिप्लॉय करने और वास्तविक दुनिया के लिए उपलब्ध कराने का समय आ जाता है।
00:12:39आप इसे सीधे डिप्लॉय करके काम खत्म नहीं मान लेते क्योंकि एजेन्टिक सिस्टम्स के साथ बहुत कुछ शामिल होता है।
00:12:44एक सामान्य प्रणाली के लिए, डिप्लॉयमेंट का मतलब आमतौर पर इसे प्रोडक्शन में धकेलना और सिस्टम हेल्थ की निगरानी करना होता है।
00:12:49एजेन्टिक सिस्टम्स के लिए, यह पूरी तरह से अलग है और यहीं पर डिप्लॉयमेंट का अर्थ ही बदल जाता है।
00:12:54SDLC में, डिप्लॉयमेंट डेवलपमेंट का अंत और एक स्थिर ऑपरेटिंग फेज की शुरुआत थी, वह बिंदु जहाँ सॉफ्टवेयर अपने स्थिर वर्षों में प्रवेश करता था।
00:13:02ADLC में, डिप्लॉयमेंट सक्रिय निगरानी और नियंत्रण की शुरुआत है, जो मॉडल अपडेट्स, कॉन्टेक्स्ट ड्रिफ्ट और एनवायरनमेंट बदलावों से आकार लेती है जो आपके शिफ्ट होने के बाद भी चलते रहते हैं।
00:13:11इसलिए भले ही डेवलपमेंट पूरा हो गया हो, यह स्टेज और भी महत्वपूर्ण है क्योंकि अब आपको व्यावहारिक और सिस्टम मैट्रिक्स की सक्रिय रूप से निगरानी करनी होगी।
00:13:19आपको अलर्टिंग रूल्स की भी आवश्यकता होती है जो क्वालिटी, सेफ्टी और परफॉर्मेंस के मुद्दों पर लगातार नज़र रखें ताकि उन्हें बड़े पैमाने पर प्रोडक्शन एरर्स में बदलने से पहले जल्दी पकड़ा जा सके।
00:13:28डिप्लॉयमेंट अनिवार्य रूप से निरंतर अवलोकन के साथ एक नियंत्रित एक्टिवेशन है जब वास्तविक यूजर्स सिस्टम के साथ इंटरैक्ट करते हैं।
00:13:34केवल सिस्टम हेल्थ पर ध्यान केंद्रित करने के बजाय, आप व्यावहारिक प्रदर्शन (behavioral performance) पर ध्यान केंद्रित करते हैं ताकि सभी यूजर्स तक पहुँचने से पहले मुद्दों को जल्दी पकड़ा जा सके।
00:13:41व्यवहार में, आप पहले सिस्टम को यूजर्स के एक सीमित ग्रुप के लिए जारी करते हैं और उन्हें वास्तविक स्थितियों में इसका उपयोग करने देते हैं।
00:13:46फिर आप धीरे-धीरे इसे सभी के लिए रोल आउट करने से पहले देखते हैं कि एजेन्टिक सिस्टम समय के साथ कैसा रिस्पॉन्स देता है।
00:13:52इम्प्लीमेंटेशन के सभी प्रक्रियाओं से गुजरने के बाद, यह मेंटेनेंस, निरंतर सीखने और विकास का एक सतत चक्र बन जाता है।
00:13:58यह एक महत्वपूर्ण स्टेज है क्योंकि यह एजेंट को सटीक और वास्तविक दुनिया की जरूरतों के अनुरूप बनाए रखता है।
00:14:03पारंपरिक प्रणालियों के साथ, फीडबैक लूप्स अपेक्षाकृत सरल होते हैं।
00:14:06एक यूजर बग की रिपोर्ट करता है और एक डेवलपर उस पर काम करता है और उसे ठीक करता है।
00:14:10एजेन्टिक सिस्टम्स के साथ, यह काफी अलग है क्योंकि वे एक निरंतर सुधार प्रक्रिया पर आधारित हैं जो किसी भी बिंदु पर नहीं रुकती।
00:14:16यह चक्र मॉडल को परिष्कृत करना जारी रखता है और सभी नकारात्मक सिग्नल्स को वापस फीड किया जाता है ताकि यह समय के साथ अपने व्यवहार में सुधार कर सके।
00:14:22यह आमतौर पर थम्स अप और थम्स डाउन जैसे UI सिग्नल्स के माध्यम से किया जाता है ताकि यह कैप्चर किया जा सके कि यूजर एक प्रतिक्रिया के बाद कैसा महसूस करता है।
00:14:29कई प्रोडक्शन सिस्टम्स पहले से ही समान तंत्र का उपयोग करते हैं जैसे कि कई आउटपुट्स के बीच चयन करना या प्रतिक्रियाओं को रैंक करना जैसा कि ChatGPT या Claude में फीडबैक सिस्टम्स में देखा जाता है।
00:14:39इन सिग्नल्स को फिर वापस एजेंटिक सिस्टम में फीड किया जाता है ताकि यह सीख सके और बेहतर प्रदर्शन की ओर बढ़ सके।
00:14:44डेटा सोर्स और एम्बेडिंग्स का समय-समय पर अपडेट होना भी है ताकि यह सुनिश्चित हो सके कि सिस्टम अपडेट रहे और पुरानी जानकारी से प्रभावित न हो।
00:14:52अलाइनमेंट की लगातार निगरानी की जानी चाहिए ताकि सेफ्टी और गार्डरेल्स सभी प्रकार के प्रॉम्ट्स के खिलाफ प्रभावी रहें, जिसमें प्रॉम्ट इंजेक्शन जैसे जोखिम शामिल हैं।
00:15:00यहाँ के प्रमुख वेरिएबल्स चालू लागत प्रबंधन (ongoing cost management), क्वालिटी ट्रैकिंग, प्रोडक्ट इम्प्रूवमेंट बैकलॉग्स और मॉडल अपग्रेड्स हैं, इन सभी को समय के साथ सिस्टम को स्थिर, सुरक्षित और चालू रखने के लिए लगातार मेंटेन करने की आवश्यकता होती है।
00:15:11यह हमें इस वीडियो के अंत में लाता है।
00:15:13यदि आप चैनल का समर्थन करना चाहते हैं और इस तरह के वीडियो बनाने में हमारी मदद करना चाहते हैं, तो आप नीचे सुपर थैंक्स बटन का उपयोग करके ऐसा कर सकते हैं।
00:15:20हमेशा की तरह, देखने के लिए धन्यवाद और मैं आपसे अगले वीडियो में मिलूँगा।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video