Anthropic ने Graph Engineering की सबसे बड़ी कमी को दूर कर दिया है

AAI LABS
Computing/SoftwareInternet Technology

Transcript

00:00:00आजकल 'ग्राफ इंजीनियरिंग' नाम का एक नया टर्म काफी चर्चा में है, और X पर हर कोई इसके बारे में बात कर रहा है।
00:00:04ग्राफ से पहले, सब कुछ लूप इंजीनियरिंग पर चलता था, जहाँ आप एजेंट को एक लक्ष्य सौंपते हैं और वह उस पर काम करता है
00:00:09खुद से। लेकिन ग्राफ की मदद से काम तेजी से होता है और एक साथ बहुत अधिक काम पूरा किया जा सकता है,
00:00:14जो लूप से कभी संभव नहीं था। हालाँकि, इनमें एक बहुत बड़ी समस्या भी है। ग्राफ के एक छोटे से हिस्से में एक गलती
00:00:18पूरे आउटपुट को खराब कर देती है, और इसे ट्रैक करना मुश्किल होता है क्योंकि अंत में आपको केवल
00:00:23फाइनल रिजल्ट ही मिलता है। इसलिए Anthropic ने हाल ही में कुछ ऐसा लॉन्च किया है जो इस समस्या का समाधान करता है
00:00:27और आपके ग्राफ को बिना फेल हुए काम करने देता है। अगर आप यहाँ नए हैं, तो हम एक सॉफ्टवेयर
00:00:32कंपनी हैं, और यह हमारा चैनल AI Labs है, जहाँ हम आपको सिखाते हैं कि AI के साथ अपने बिज़नेस को कैसे ऑप्टिमाइज़ करें,
00:00:37और अगर आपका खुद का बिज़नेस नहीं है, तो आप इन स्किल्स का इस्तेमाल दूसरों के बिज़नेस को ऑप्टिमाइज़ करके पैसे कमाने के लिए कर सकते हैं।
00:00:42और इस वीडियो में, हम उन सभी के लिए ग्राफ इंजीनियरिंग को समझेंगे जो इसे नहीं जानते,
00:00:46और आपको वो सटीक समाधान देंगे जो Anthropic ने सुझाया है। ग्राफ इंजीनियरिंग को समझने से पहले, आपको
00:00:52यह समझना होगा कि लूप इंजीनियरिंग वास्तव में क्या है। अगर आप यह पहले से जानते हैं, तो आप इस हिस्से को छोड़ सकते हैं।
00:00:56लूप बुनियादी तौर पर एक वर्क साइकिल है जिसे आप एजेंट को सौंपते हैं। हर एक कदम पर खुद प्रॉम्प्ट देने के बजाय,
00:01:02आप उसे वो अंतिम लक्ष्य बताते हैं जहाँ उसे पहुँचना है, और वह खुद ही रास्ते में सुधार करते हुए
00:01:07वहाँ पहुँच जाता है। हम अपने वर्कफ़्लो में इनका बहुत इस्तेमाल करते आ रहे हैं। हमने लूप इंजीनियरिंग पर एक पूरा वीडियो
00:01:12पहले भी बनाया है, जहाँ हमने गहराई से बताया था कि आप इन्हें कैसे सेटअप कर सकते हैं, लेकिन लूप्स
00:01:17अब ग्राफ्स में बदलते जा रहे हैं। लूप्स के साथ समस्या उनके बनने के तरीके में है।
00:01:22एक लूप थोड़ा काम करता है, फिर यह जाँचने के लिए एक वेरिफिकेशन स्टेप शुरू होता है कि काम सही हुआ है या नहीं।
00:01:27उसके पास होने के बाद ही अगला कदम शुरू होता है। सब कुछ एक सीधी रेखा में चलता है, इसलिए हर स्टेप
00:01:32अपने से पहले वाले स्टेप का इंतज़ार करता रहता है, भले ही उन दोनों का आपस में कोई लेना-देना न हो। ग्राफ इंजीनियरिंग
00:01:37इसी समस्या को ठीक करती है। सीधी रेखा में चलने के बजाय, एक ग्राफ मुख्य काम को छोटे-छोटे
00:01:42हिस्सों में बाँट देता है, और हर हिस्से को अपना एक एजेंट मिलता है। इससे जो पहली चीज़ आपको मिलती है, वो है स्पीड,
00:01:47क्योंकि एक ही एजेंट के पूरे काम में लगे रहने के बजाय कई एजेंट्स एक साथ काम निपटाते हैं। और काम को इस तरह
00:01:52बाँटने से लागत भी कुछ हद तक कम हो जाती है, क्योंकि आप यह चुन सकते हैं कि हर एक एजेंट किस मॉडल पर चलेगा।
00:01:56तो आप अपने सबसे महंगे मॉडल को उन हिस्सों पर बेकार में खर्च करना बंद कर देते हैं जिन्हें कभी उतनी ज्यादा
00:02:01इंटेलिजेंस की ज़रूरत ही नहीं थी। लेकिन यह प्रति एजेंट की लागत है, कुल लागत नहीं। एक ग्राफ
00:02:07किसी एक अकेले एजेंट की तुलना में बहुत अधिक टोकन खर्च करता है, क्योंकि आपके पास एक साथ कई एजेंट्स काम कर रहे होते हैं।
00:02:12अगर आप ग्राफ्स का इस्तेमाल कर रहे हैं, तो उम्मीद रखें कि आपकी लिमिट्स आपकी आदत से काफी जल्दी खत्म हो जाएँगी,
00:02:17इसलिए आप इसे ClaudeCode और Codex के $20 वाले प्लान्स के साथ आसानी से सेटअप नहीं कर सकते। अब अगर आप ClaudeCode का इस्तेमाल कर रहे हैं,
00:02:22तो यह आपके लिए पूरी तरह से नया नहीं होगा, क्योंकि आप पहले ही एक ग्राफ देख चुके हैं, जो कि डायनामिक
00:02:27वर्कफ़्लो है। एक डायनामिक वर्कफ़्लो आपके दिए गए काम को लेता है और उसे सब-एजेंट्स के एक समूह में बाँट देता है,
00:02:33जो बुनियादी तौर पर वही है जो एक ग्राफ करता है। अब इससे पहले कि हम ग्राफ के अलग-अलग आकारों पर जाएँ,
00:02:38आपको यह जानना होगा कि वास्तव में ग्राफ किन चीज़ों से बनता है। हर ग्राफ दो चीज़ों से बनता है: नोड्स और एजेस। एक नोड
00:02:44मुख्य काम का एक छोटा सा हिस्सा होता है, और यह अपने आप चलता है। यह एक ऐसा एजेंट है
00:02:49जो अपने अलग कॉन्टेक्स्ट विंडो में काम करता है और रिपोर्ट वापस भेजता है। जो चीज़ इन सभी अलग-अलग कामों को जोड़ती है
00:02:55वह है 'एज'। एक एज यह कंट्रोल करती है कि डेटा एक नोड से अगले नोड तक कैसे जाता है, ताकि एक एजेंट का आउटपुट
00:03:01सही समय पर सही एजेंट तक पहुँचे। इसलिए हर नोड को किसी न किसी तरह बाकी ग्राफ से जुड़ा होना पड़ता है।
00:03:06आप इसे एजेंट्स के एक ऐसे ग्रुप में देख सकते हैं जो एक ही काम का रिव्यू कर रहे हैं। उनमें से कोई भी
00:03:10एक-दूसरे का इंतज़ार नहीं करता। लेकिन वे सभी एक ही काम से शुरू हुए थे, और उन सभी की रिपोर्ट अंत में
00:03:15एक ही जगह पहुँचती है, तो ग्राफ इसी से मिलकर बनता है। अब यहाँ वे शेप्स दिए गए हैं जिनमें ये टुकड़े
00:03:20व्यवस्थित होते हैं। पहला शेप वो है जो हम आपको इस चैनल पर पहले भी दिखा चुके हैं, और उस समय हमने इसका गलत नाम
00:03:25बता दिया था। हमने इसे लूप कहा था, क्योंकि तब ग्राफ इंजीनियरिंग का अस्तित्व ही नहीं था। लेकिन
00:03:30वास्तव में हमारे पास एक ग्राफ था जिसे हम लूप कर रहे थे, और इसका आकार एक डायमंड जैसा था। ऊपर एक काम
00:03:35कई सब-एजेंट्स में विभाजित होता है जो साथ-साथ चलते हैं, फिर वे सभी वापस सिमटकर एक अकेले
00:03:41एजेंट में आ जाते हैं जो उनके मिले सभी नतीजों को एक जवाब में मिलाता है। इसके बाद 'फैन इन एट अ बैरियर' ग्राफ आता है,
00:03:46और यह वही शेप है जो आपको तब चाहिए जब किसी एक चीज़ को एक साथ कई कोणों से परखना हो। फैन आउट
00:03:51हिस्सा वही समस्या एजेंट्स के एक ग्रुप को भेजता है, और हर एक उसे एक अलग दृष्टिकोण से देखता है।
00:03:56जब तक वे सभी एजेंट्स अपनी रिपोर्ट नहीं दे देते, तब तक कुछ भी आगे नहीं बढ़ता, और केवल तभी
00:04:00यह आगे बढ़ता है और उनके फिक्स लागू करता है। इसके अलावा और भी कई शेप्स हैं। लेकिन इनमें से हर शेप
00:04:05एक ही चीज़ पर निर्भर करता है, और वह है वेरिफिकेशन। अगर आप उन जाँचों को सही तरीके से सेट नहीं करते हैं, तो बाद में आने वाला हर एजेंट
00:04:10बस एक गलती के ऊपर ही काम कर रहा होता है। लेकिन वेरिफिकेशन के बारे में बात करने से पहले, यह बहुत अच्छा होगा अगर आप
00:04:15चैनल को सब्सक्राइब कर लें और लाइक बटन दबा दें। सपोर्ट का यह छोटा सा इशारा हमारे लिए बहुत मायने रखता है।
00:04:20जब आप एजेंट्स का एक पूरा समूह चला रहे होते हैं, तो चीज़ें ऐसे तरीकों से गलत होती हैं जैसा किसी अकेले एजेंट के साथ कभी नहीं होता।
00:04:25सबसे बड़ी समस्या तो काम की मात्रा ही है। वे सभी एक ही समय में काम कर रहे होते हैं, इसलिए एक साथ काम का बहुत बड़ा ढेर
00:04:30वापस आता है, और अंत में उसका रिव्यू करना वास्तव में काफी मुश्किल होता है। दूसरी समस्या यह है कि
00:04:34आप देख नहीं सकते कि क्या हुआ था। जब कुछ गलत होता है, तो यह जानने का कोई तरीका नहीं होता कि इसकी वजह क्या थी।
00:04:39अब सभी एजेंट्स अपने लिखे काम को खुद ही वेरीफाई करते हैं, चाहे आप उनसे कहें या न कहें। अगर आप कोड पर काम कर रहे हैं,
00:04:44तो इसका सीधा सा मतलब है कि एजेंट आपके टेस्ट चलाता है और आने वाले एरर्स को पकड़ता है। लेकिन इससे सिर्फ बड़े
00:04:49एरर्स ही पकड़े जाते हैं। यह अभी भी यह नहीं जाँचता कि कोड कैसे लिखा गया है, और यह बहुत महत्वपूर्ण है क्योंकि अगर Claude
00:04:53इसे इसी तरह लिखता रहा, तो भविष्य में परेशानियाँ खड़ी होंगी। इसके लिए Claude code में
00:04:58कुछ इन-बिल्ट टूल्स भी मौजूद हैं। पहला है verify स्किल, जो कोड को शुरू से अंत तक देखता है
00:05:03और पुष्टि करता है कि यह वास्तव में वैसा ही काम कर रहा है जैसा इसे करना चाहिए। दूसरा है टूल चेनिंग,
00:05:08जो बुनियादी तौर पर एजेंट द्वारा वेरीफाई करने के लिए अलग-अलग टूल्स चलाना है। Claude पहले से ही जानता है कि उन टूल्स को चलाना है
00:05:13जो काम की जाँच करते हैं, इसलिए वह वापस आने वाले एरर्स को पढ़ता है और उन्हें खुद ही ठीक कर लेता है। वह आपके
00:05:18प्रोजेक्ट के सटीक कमांड्स भी खुद ही पता लगा सकता है। लेकिन उन्हें अपनी Claude.md फ़ाइल में लिखने से उसे हर बार
00:05:24उन्हें समझने की झंझट से मुक्ति मिल जाती है। और तीसरा है एक कोड रिव्यू स्किल, जो कोड की जाँच
00:05:29तय मानकों के सेट के आधार पर करता है। हर एजेंट के साथ यह नहीं आता, लेकिन अगर आपके पास यह नहीं है, तो आप अपने एजेंट से इसे बनाने के लिए कह सकते हैं।
00:05:33लेकिन जो वेरिफिकेशन वास्तव में सबसे अच्छा काम करता है, वह वो है जिसे आप खुद सेटअप करते हैं,
00:05:38बजाय इसके कि आप पूरी तरह से इन-बिल्ट चीज़ों पर निर्भर रहें। तो अपने काम को वेरीफाई करने वाली स्किल बनाने का
00:05:44सबसे तेज़ तरीका Claude code में skill creator प्लगइन है। आप इस Claude code स्किल का इस्तेमाल
00:05:49Codex में भी कर सकते हैं। आप प्लगइन कमांड चलाते हैं, skill creator खोजते हैं और इंस्टॉल करते हैं। वहाँ से,
00:05:54आपके पास दो विकल्प हैं। आप इसे यूज़र स्कोप पर इंस्टॉल कर सकते हैं, जिसका मतलब है कि यह हमेशा उपलब्ध रहेगा चाहे आप किसी भी
00:05:58फ़ोल्डर में काम कर रहे हों। या फिर आप इसे सिर्फ उसी प्रोजेक्ट के लिए इंस्टॉल कर सकते हैं जिस पर आप अभी काम कर रहे हैं।
00:06:03चूँकि यह एक ऐसी स्किल है जिसका इस्तेमाल आप लगातार करेंगे, इसलिए हमने यूज़र स्कोप को चुना। उसके बाद,
00:06:07आप स्लैश कमांड से प्लगइन्स को रीलोड करते हैं और skill creator इस्तेमाल के लिए तैयार हो जाता है। अब आप इसे बताते हैं
00:06:12कि आप क्या बनवाना चाहते हैं और यह वह हिस्सा है जहाँ आप उस वेरिफिकेशन का वर्णन करते हैं जिसकी आपको वास्तव में
00:06:17ज़रूरत है। हम ज़्यादातर रिव्यू स्किल का इस्तेमाल तैयार काम को उस चीज़ से मिलाने के लिए करते हैं जो हमने
00:06:22शुरू में माँगी थी। और ग्राफ में यह बात बहुत ज़्यादा मायने रखती है क्योंकि हर एजेंट सिर्फ अपना हिस्सा ही देख पाता है।
00:06:28यह उसे उस हिस्से को मूल आवश्यकताओं के आधार पर जाँचने का एक तरीका देता है। लेकिन एक स्किल
00:06:32उतनी ही अच्छी होती है जितना अच्छा वो मॉडल होता है जिस पर आप इसे चलाते हैं। जब हम अपनी कम्युनिटी वेबसाइट के UI के लिए
00:06:37वेरिफिकेशन सिस्टम बना रहे थे, तो हमने रिव्यूअर को Haiku पर चलाया क्योंकि वह सस्ता है और काम भी आसान
00:06:43लग रहा था। वह कमियों की एक लंबी लिस्ट लेकर आया। केवल कमियों की संख्या को देखें तो ऐसा लगा
00:06:47जैसे उसने बहुत बढ़िया काम किया है। फिर हमने उसी चीज़ को Opus पर चलाया और उसने बहुत कम चीज़ें फ्लैग कीं।
00:06:53वह सबसे खराब परिणाम लग रहा था, जब तक कि हमने उसके तर्क को नहीं पढ़ा। Haiku ने जिन चीज़ों की रिपोर्ट की थी, उनमें से बहुत सी चीज़ें
00:06:58हमने जानबूझकर वैसी ही छोड़ी थीं। इसलिए उसकी बताई गई ज़्यादातर कमियाँ पूरी तरह से अनावश्यक थीं।
00:07:03Opus ने आसपास के कोड से इस बात को समझ लिया था, जिसे Haiku पूरी तरह से नज़रअंदाज़ कर गया था। इसलिए सस्ते
00:07:08रिव्यू ने हमारी कोई बचत नहीं कराई क्योंकि अब उस रिव्यू का ही रिव्यू करने की ज़रूरत पड़ गई थी। अब इसे
00:07:13एक ग्राफ के अंदर रखकर सोचिए जहाँ नोड्स का एक पूरा ग्रुप उसी स्किल से अपने काम की जाँच कर रहा हो। आपके
00:07:18एजेंट्स उन चीज़ों को ठीक करने में समय और टोकन बर्बाद कर रहे होंगे जो कभी खराब थीं ही नहीं। और चूँकि यह सब
00:07:23एक साथ अलग-अलग एजेंट्स के बीच हो रहा है, आपके पास यह जानने का कोई तरीका नहीं होगा कि इसकी शुरुआत किसने की।
00:07:27इसलिए आप जो मॉडल चुनते हैं, वह सिर्फ रिव्यू की क्वालिटी तय नहीं करता, बल्कि पूरे
00:07:31ग्राफ की क्वालिटी तय करता है। जो नोड जाँच का काम करता है, वही एक ऐसी जगह है जहाँ टोकन बचाना आपको
00:07:37भारी पड़ सकता है। दूसरी चीज़ जो आपको तय करनी है वह यह है कि उस स्किल को कैसे और कब ट्रिगर किया जाए। और
00:07:41यह उन्हें तीन प्रकारों में बाँटती है। लेकिन इसके प्रकारों में गहराई से जाने से पहले, आइए हमारे स्पॉन्सर के बारे में बात करते हैं।
00:07:46अगर आपने कभी वेब से लाइव डेटा निकाला है, तो आप जानते हैं कि स्क्रैपिंग सच में एक बहुत बड़ा सिरदर्द है, जहाँ आप अंत में
00:07:51कैप्चा और रेट लिमिट्स से जूझते रह जाते हैं, प्रॉक्सीज़ से परेशान होते हैं, और उन लेआउट्स को ठीक करते रहते हैं जो
00:07:56कोड पब्लिश करते ही टूट जाते हैं। इसलिए हम SERP API का इस्तेमाल करते हैं, जो इन सभी समस्याओं को हल करता है ताकि आप केवल प्रोडक्ट बनाने पर ध्यान दे सकें।
00:08:01यह सिर्फ एक API कॉल है; आप एक रिक्वेस्ट भेजते हैं और आपको ठीक वही डेटा एक साफ-सुथरे JSON ऑब्जेक्ट में मिल जाता है
00:08:07जो आपको चाहिए, वह भी 99.9% से ज़्यादा अपटाइम और लगभग 1.2 सेकंड के रिस्पॉन्स टाइम के साथ। जब आप AI एजेंट्स बना रहे हों, तो आप
00:08:14Google Search API को उस एजेंट से जोड़ सकते हैं जिसे लेटेस्ट जानकारी चाहिए, या फिर Google Scholar API का इस्तेमाल
00:08:20पूरे मेटाडेटा के साथ पीयर-रिव्यूड पेपर्स के लिए कर सकते हैं, यही वजह है कि बहुत सारे प्रोडक्शन एजेंट्स इस पर भरोसा करते हैं। शुरुआत करें
00:08:25डिस्क्रिप्शन में दिए गए लिंक का इस्तेमाल करके 250 फ्री क्रेडिट्स के साथ, या स्क्रीन पर दिख रहे QR कोड को स्कैन करें। इस वीडियो को
00:08:32स्पॉन्सर करने के लिए SERP API का धन्यवाद। पहला प्रकार 'स्टैंडअलोन' है, और यह उस तरह की स्किल है जो केवल तभी चलती है जब आप
00:08:37खुद इसे मैन्युअली चलाते हैं। एक स्टैंडअलोन स्किल को किसी पहले से मौजूद चीज़ की गहराई से जाँच करने के लिए बनाया जाता है, ताकि यह
00:08:42तैयार आउटपुट को ठीक से दोबारा परख सके। इसीलिए आप नहीं चाहेंगे कि यह हर एक रन के बाद ट्रिगर हो। वरना आप
00:08:48ऐसे काम के भारी-भरकम रिव्यू पर टोकन बर्बाद कर रहे होंगे जो अभी पूरा भी नहीं हुआ है। एक स्किल जो हमने पहले इस्तेमाल की है, वह है
00:08:53Cursor का थर्मोन्यूक्लियर कोड रिव्यू। यह एजेंट्स का एक ग्रुप फैलाता है और हर एक को अलग-अलग सिक्योरिटी दृष्टिकोण से
00:08:59कोड की जाँच करने के लिए भेजता है। हर कमी एक ही जगह वापस आती है, ताकि यह उन सब पर एक साथ
00:09:04काम करके उन्हें ठीक कर सके, और यह ठीक उसी तरह का रिव्यू है जिसे आप ऐप पूरा बनने के बाद ही चलाते हैं। इनमें से एक बनाने के लिए,
00:09:10केवल प्रॉम्प्ट देने के बजाय skill creator का इस्तेमाल करना बेहतर है, क्योंकि जो परिणाम आता है वह टेस्ट किया हुआ होता है, जिससे उस पर भरोसा करना आसान
00:09:15हो जाता है। आप प्रॉम्प्ट में बताते हैं कि आप किस एरिया का रिव्यू चाहते हैं, और यह उल्लेख करना सुनिश्चित करें कि
00:09:20रिव्यू विस्तृत होना चाहिए ताकि उसे समझ आ जाए कि आप एक गहरी जाँच चाहते हैं, न कि कोई सरसरी जाँच। लेकिन एक स्टैंडअलोन
00:09:26स्किल उस नोड के किसी काम की नहीं है जो अभी काम कर ही रहा है, क्योंकि उसे आपको खुद चलाना पड़ता है। इसी के लिए 'एम्बेडेड'
00:09:31स्किल्स होती हैं। एक एम्बेडेड स्किल आपके चल रहे वर्कफ़्लो के हिस्से के रूप में बिना आपके अलग से माँगे ही स्वचालित रूप से
00:09:36चल पड़ती है। आप एक ऐसी स्किल बना सकते हैं जो तब शुरू हो जाए जब भी कोई नए फ़ीचर की माँग करे। यह जाँच करती है कि
00:09:41बनाया जा रहा हर कॉम्पोनेंट आपके द्वारा स्किल में तय किए गए नियमों का पालन करता है या नहीं, और जब तक उन नियमों के आधार पर
00:09:45जाँच नहीं हो जाती, तब तक यह काम को पूरा नहीं होने देती। आप खुद एम्बेडेड स्किल्स बना
00:09:50सकते हैं, लेकिन आप पहले से इंस्टॉल किसी स्किल को अपने आप ट्रिगर होने के लिए सेट नहीं कर सकते, जैसे कि
00:09:54वह verify स्किल जिसके बारे में हमने पहले बात की थी। वे इंस्ट्रक्शन्स जिन पर वे स्किल्स चलती हैं, प्रोडक्ट के अंदर मौजूद होती हैं, और
00:10:00आप उन्हें बदल नहीं सकते। अपनी खुद की स्किल बनाने के लिए, skill creator को एक प्रॉम्प्ट दें जिसमें उससे हर फ़ीचर इम्प्लीमेंटेशन के बाद
00:10:05वेरिफिकेशन स्टेप्स चलाने को कहें, ताकि आप उसे फ़ीचर को शुरू से अंत तक टेस्ट करने के लिए कहें ताकि यह
00:10:10पकड़ सके कि नए काम ने पहले से सही काम कर रही किसी चीज़ को तोड़ा तो नहीं है। फिर Claude आपके लिए वह स्किल बनाता है,
00:10:16और चूँकि इसे skill creator ने बनाया है, इसलिए इसमें वे रेफ़रेंस और स्क्रिप्ट्स शामिल होते हैं जिन्हें skill creator ने
00:10:21इस प्रोसेस के तहत स्ट्रक्चर और टेस्ट किया था। अब किसी फ़ीचर को वेरीफाई करने के लिए, Claude डिफ़ॉल्ट रूप से ब्राउज़र टेस्टिंग का इस्तेमाल करता है
00:10:26जहाँ वह पूरा Chrome ब्राउज़र खोलकर, पेज लोड करके और उसके स्क्रीनशॉट लेकर इंटरफ़ेस की जाँच करता है।
00:10:31और अगर आपने Puppeteer या Playwright को कनेक्ट किया है, जो कि बुनियादी तौर पर वे टूल्स हैं जिनका इस्तेमाल ज़्यादातर
00:10:36लोग ऑटोमैटिक ब्राउज़र चलाने के लिए करते हैं, तो वे भी वही काम करते हैं। लेकिन Chrome मेमोरी खाने और भारी चलने के लिए जाना जाता है,
00:10:41और किसी वर्कफ़्लो के अंदर एक पेज को बार-बार चेक करने के लिए यह इतना धीमा है कि इससे
00:10:46आपका काफी समय बर्बाद होने लगता है। इसलिए इसे करने का एक हल्का तरीका है, जिसे chrome headless shell कहते हैं। यह बुनियादी तौर पर
00:10:52ब्राउज़र का एक स्ट्रिप्ड-डाउन वर्ज़न है जिसमें से सभी अतिरिक्त हिस्से हटा दिए गए हैं। एजेंट अभी भी
00:10:57पेज पर जाता है और उसी तरह स्क्रीनशॉट लेता है। बस यह इस पूरे काम को पूरे Chrome की तुलना में
00:11:02कहीं ज़्यादा तेज़ी से निपटा देता है। आप इसे सीधे उस वेरिफिकेशन स्किल में बना सकते हैं जो आप बनाते हैं। फिर एजेंट द्वारा बनाया गया
00:11:07हर फ़ीचर बिना हर बार आपके कुछ अलग से सेटअप किए विजुअली चेक हो जाता है। इसके अलावा,
00:11:12जिस स्किल का इस्तेमाल हम अपने वर्कफ़्लो में सबसे ज़्यादा करते हैं, वह है “second opinion”, और इसका कारण सीधा सा है।
00:11:17जिस एजेंट ने चीज़ बनाई है, वही उसका रिव्यू करने के लिए सबसे खराब विकल्प है। वह अपने काम को उसी
00:11:23कॉन्टेक्स्ट के आधार पर परखता है जिसका इस्तेमाल उसने इसे बनाने में किया था, इसलिए वह केवल उसी के आधार पर रिव्यू करता है। एक नया Claude सेशन
00:11:28उनमें से कुछ भी नहीं देखा होता। वह एक निष्पक्ष रिव्यू देता है और आपको एक सीधा जवाब देता है। अब Claude में एक इन-बिल्ट
00:11:33एडवाइजर है जो कुछ ऐसा ही करता है, लेकिन वह उस चैट को पढ़ता है जिसमें आप अभी हैं, इसलिए उसे
00:11:38वही सारा कॉन्टेक्स्ट विरासत में मिल जाता है। Second opinion तब के लिए है जब आप उसके बिना रिव्यू चाहते हैं। यह उस चैट के अंदर से ही
00:11:43-p फ़्लैग का इस्तेमाल करके एक और Claude सेशन शुरू करके काम करता है जो आप पहले से चला रहे हैं। यह वही
00:11:48फ़्लैग है जो बैकग्राउंड में एक पूरा अलग Claude code सेशन शुरू कर देता है, उसे काम करने के लिए एक प्रॉम्प्ट
00:11:53सौंपकर। हालाँकि, अगर आप इसका इस्तेमाल करने जा रहे हैं तो आपको कुछ बातें जाननी होंगी। चूँकि यह
00:11:57एक पूरी तरह से अलग सेशन लॉन्च कर रहा है, इसलिए जवाब के साथ वापस आने में इसे काफी समय लगता है,
00:12:02और मॉडल यहाँ किसी भी अन्य जगह से ज़्यादा मायने रखता है, क्योंकि पूरा मकसद एक अधिक समझदारी भरी दूसरी राय लेना है।
00:12:07इसलिए Claude को स्पष्ट रूप से उस सेशन को Opus पर शुरू करने के लिए कहना फ़ायदेमंद है। यह आपके ग्राफ के हर नोड
00:12:12को अपने काम की जाँच किसी ऐसी चीज़ से कराने का तरीका देता है जिसका उस काम में कोई हाथ नहीं था। लेकिन एक ही स्किल
00:12:18सब कुछ कवर नहीं कर सकती। जब आप किसी चीज़ का सही तरीके से रिव्यू कर रहे होते हैं, तो आप कई
00:12:22अलग-अलग कोणों से उसका रिव्यू कर रहे होते हैं, और हर कोण का मापने का अपना तरीका होता है। आप रिव्यू के सभी प्रकारों को
00:12:27एक ही स्किल में नहीं ठूँस सकते, क्योंकि उस तरह से एजेंट के पास रिव्यू करने के लिए बहुत सारी दिशाएँ होंगी और वह बेहतर होने के बजाय
00:12:33और खराब होता चला जाएगा। इसलिए आप हर कोण के लिए एक अलग स्किल बनाते हैं और उन्हें एक साथ जोड़ते हैं। Anthropic की अपनी
00:12:38टीम भी इसी तरह काम करती है। वे कोड रिव्यू स्किल को simplify स्किल और verify
00:12:43स्किल के साथ जोड़ते हैं, और वे तीनों अब Claude code के साथ आते हैं। इसके अलावा, वे अपनी खुद की डिज़ाइन स्किल चलाते हैं,
00:12:49जो design.md फ़ाइल के आधार पर इंटरफ़ेस की जाँच करती है, जो बुनियादी तौर पर वह फ़ाइल है जो प्रोडक्ट के हर
00:12:54डिज़ाइन निर्णय को रखती है। तो यह एक ऐसा रिव्यू है जो एक के बजाय चार दिशाओं से आता है। आप
00:12:59भी उसी स्थिति में पहुँचेंगे, जहाँ आपके पास स्किल्स का एक ढेर होगा जिनमें से प्रत्येक एक अलग कोण को कवर करती है। लेकिन आप
00:13:04एजेंट से उन सभी को एक साथ चलाने के लिए नहीं कह सकते। आपको बाकी सब के ऊपर एक और स्किल की ज़रूरत है,
00:13:09जो बुनियादी तौर पर एक ऑर्केस्ट्रेटर स्किल है जिसका एकमात्र काम दूसरी स्किल्स को चलाना है। यह आपकी मौजूद
00:13:15हर रिव्यू स्किल के लिए एक एजेंट तैयार करती है और हर एक को उसकी स्किल सौंपती है। वे सभी अपने अलग-अलग
00:13:20कॉन्टेक्स्ट विंडोज़ में एक ही समय पर रिव्यू करते हैं। फिर यह हर निष्कर्ष को वापस एक रिपोर्ट में मिलाती है जिससे सुधार करने वाले एजेंट्स
00:13:25काम कर सकते हैं। फिर जब आप एक ग्राफ बना रहे होते हैं, तो प्रॉम्प्ट में आपको बस इतना कहना होता है कि
00:13:30इसे उस एक स्किल का इस्तेमाल करना चाहिए। इसके द्वारा बनाया गया हर नोड उस एक स्किल को लोड करता है और पूरा रिव्यू
00:13:35उसके नीचे अपने आप फैल जाता है। अब हमने एक दस्तावेज़ तैयार किया है जिसमें वे सभी तरीके शामिल हैं जिनसे आप विस्तार से
00:13:40ग्राफ़ के लिए वेरिफिकेशन सेटअप कर सकते हैं। वह डॉक्यूमेंट इस वीडियो में दिखाई गई सभी स्किल्स के साथ
00:13:45AI Labs Pro में उपलब्ध है, जो हमारी कम्युनिटी है। तो अगर आपको हमारे काम से वैल्यू मिली है और आप
00:13:50चैनल को सपोर्ट करना चाहते हैं, तो ऐसा करने का यह सबसे अच्छा तरीका है। लिंक डिस्क्रिप्शन में है। इसके साथ हम इस
00:13:55वीडियो के अंत में आ गए हैं। अगर आप चैनल को सपोर्ट करना चाहते हैं और इस तरह के वीडियो बनाने में हमारी मदद करना चाहते हैं, तो आप
00:14:00नीचे दिए गए सुपर थैंक्स बटन का इस्तेमाल करके ऐसा कर सकते हैं। हमेशा की तरह, देखने के लिए धन्यवाद और मैं आपसे अगले वीडियो में मिलूँगा।

Key Takeaway

ग्राफ इंजीनियरिंग में विफलताओं को रोकने के लिए स्वतंत्र नोड्स के आउटपुट को ऑर्केस्ट्रेटर स्किल और Opus जैसे मॉडल आधारित ऑटोमेटेड वेरिफिकेशन सिस्टम द्वारा जाँचना आवश्यक है।

Highlights

  • लूप इंजीनियरिंग एक समय में एक ही एजेंट पर निर्भर होती है, जबकि ग्राफ इंजीनियरिंग काम को कई नोड्स में बाँटकर समानांतर प्रोसेसिंग के ज़रिए स्पीड बढ़ाती है।

  • ग्राफ का हर नोड अपने अलग कॉन्टेक्स्ट विंडो में स्वतंत्र रूप से काम करता है और एज (Edge) के ज़रिए डेटा को दूसरे नोड्स तक पहुँचाता है।

  • ग्राफ इंजीनियरिंग में प्रति एजेंट लागत कम की जा सकती है, लेकिन कई एजेंट्स के एक साथ चलने के कारण कुल टोकन खपत अकेले एजेंट की तुलना में काफ़ी अधिक होती है।

  • सस्ते मॉडल जैसे Haiku वेरिफिकेशन में अनावश्यक फ्लैग्स उत्पन्न करते हैं, जबकि Opus जैसे उन्नत मॉडलContext समझकर सटीक कोड रिव्यू करते हैं।

  • Chrome Headless Shell का उपयोग करने से ब्राउज़र टेस्टिंग में Chrome की तुलना में भारी मेमोरी खपत और धीमेपन की समस्या दूर होती है।

Timeline

लूप इंजीनियरिंग और ग्राफ इंजीनियरिंग का तुलनात्मक ढाँचा

  • लूप इंजीनियरिंग में कार्य एक सीधी रेखा में चलता है जहाँ हर अगला कदम पिछले कदम के पूरा होने का इंतज़ार करता है।
  • ग्राफ इंजीनियरिंग मुख्य कार्य को छोटे नोड्स में विभाजित करके अलग-अलग एजेंट्स को सौंपती है।
  • विभिन्न नोड्स के लिए उपयुक्त मॉडल चुनकर प्रति एजेंट लागत नियंत्रित की जा सकती है।

लूप्स में एक सत्यापन कदम के पास होने के बाद ही अगला चरण शुरू होता है, जिससे कार्य की गति धीमी हो जाती है। इसके विपरीत, ग्राफ संरचना में कई एजेंट्स एक साथ काम निपटाते हैं। हालाँकि, कई एजेंट्स के एक साथ चलने से टोकन की खपत बढ़ जाती है, जिससे $20 वाले बुनियादी प्लान्स की लिमिट जल्दी समाप्त हो जाती है।

ग्राफ की संरचना: नोड्स, एजेस और उनके आकार

  • ग्राफ के दो मुख्य घटक नोड्स (स्वतंत्र एजेंट्स) और एजेस (डेटा फ्लो नियंत्रक) हैं।
  • डायमंड शेप ग्राफ में कार्य पहले कई सब-एजेंट्स में बँटता है और अंत में एक सिंगल एजेंट में एकीकृत होता है।
  • फैन इन एट अ बैरियर संरचना में सभी एजेंट्स के अलग-अलग समीक्षा रिपोर्ट देने के बाद ही सुधार लागू होते हैं।

हर नोड अपनी अलग कॉन्टेक्स्ट विंडो में कार्य करता है और रिपोर्ट भेजता है। एज यह तय करती है कि एक नोड का आउटपुट किस समय दूसरे नोड तक पहुँचेगा। इन आकारों की सफलता इस बात पर निर्भर करती है कि नोड्स के बीच वेरिफिकेशन कैसे स्थापित किया गया है।

इन-बिल्ट वेरिफिकेशन टूल्स और मॉडल चयन का प्रभाव

  • ग्राफ में एक साथ कई एजेंट्स के काम करने से एरर के मूल कारण को ट्रैक करना कठिन हो जाता है।
  • Claude Code में Verify स्किल, टूल चेनिंग और कोड रिव्यू स्किल जैसे इन-बिल्ट टूल्स शामिल हैं।
  • वेरिफिकेशन के लिए मॉडल का चयन सीधे तौर पर रिव्यू की सटीकता और ग्राफ की गुणवत्ता को प्रभावित करता है।

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

वेरिफिकेशन स्किल्स के प्रकार और उनका क्रियान्वयन

  • स्टैंडअलोन स्किल्स केवल मैन्युअल ट्रिगर पर चलती हैं और पूरे प्रोजेक्ट के गहरे रिव्यू के लिए उपयुक्त हैं।
  • एम्बेडेड स्किल्स वर्कफ़्लो के दौरान स्वचालित रूप से चलती हैं और नियमों का पालन सुनिश्चित करती हैं।
  • Chrome Headless Shell ब्राउज़र टेस्टिंग में गति बढ़ाती है और संसाधन खपत घटाती है।

Skill Creator प्लगइन का उपयोग करके यूजर स्कोप या प्रोजेक्ट स्कोप पर कस्टम वेरिफिकेशन स्किल्स बनाई जा सकती हैं। स्टैंडअलोन स्किल्स को हर रन के बाद चलाना टोकन की बर्बादी करता है। एम्बेडेड टेस्टिंग के दौरान पूरा Chrome ब्राउज़र चलाने के बजाय Headless Shell का उपयोग करने से मेमोरी बचती है और प्रोसेसिंग तेज़ होती है।

ऑर्केस्ट्रेटर स्किल और बहु-कोणीय समीक्षा प्रणाली

  • जिस एजेंट ने कार्य बनाया है, वह अपने ही कॉन्टेक्स्ट के कारण निष्पक्ष रिव्यू करने में असमर्थ होता है।
  • -p फ्लैग के साथ एक नया Claude सेशन शुरू करके एक निष्पक्ष दूसरी राय (Second Opinion) प्राप्त की जाती है।
  • एक आर्केस्ट्रेटर स्किल विभिन्न विशिष्ट समीक्षा स्किल्स को एक साथ प्रबंधित और एकीकृत करती है।

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

Community Posts

View all posts