00:00:00कोई भी अकेला क्लाउड मॉडल अपने आप में पर्याप्त नहीं है। ओपस में तर्क शक्ति तो है लेकिन यह आपकी
00:00:04सीमाओं को खत्म कर देता है। सॉनेट तेज़ है लेकिन कठिन निर्णयों पर अटक जाता है। और इसका जवाब किसी एक को
00:00:10दूसरे पर चुनने में नहीं है। यह उन सभी का एक साथ उपयोग करने में है। अब क्लाउड कोड पहले से ही कुछ हद तक ऐसा करता है।
00:00:14यह अपने आप मॉडल के बीच तालमेल बिठाता है। लेकिन एंथ्रोपिक ने अभी कुछ ऐसा जारी किया है जो
00:00:18न केवल टोकन बचाता है बल्कि छोटे मॉडल को लगभग बड़े मॉडल जितना ही सक्षम बनाता है।
00:00:23अब क्लाउड के साथ निर्माण करते समय आपने इस पर ध्यान दिया होगा। जब भी आप ओपस को कोई काम सौंपते हैं
00:00:28और वह यह निर्धारित करता है कि उसे उतनी मेहनत की आवश्यकता नहीं है, तो वह इसे सॉनेट या हिकू को सौंप देता है और
00:00:32टोकन उपयोग को ठीक से प्रबंधित करने के लिए छोटे मॉडल को कार्य सौंपता है। लेकिन इस दृष्टिकोण के साथ एक समस्या है
00:00:37जैसा कि हमने अपने पिछले वीडियो में उल्लेख किया था, एंथ्रोपिक रेट लिमिट को कम कर रहा है
00:00:42इसलिए पीक आवर्स के दौरान आपकी 5 घंटे की विंडो तेज़ी से भर जाती है। और उसके ऊपर, ओपस साधारण कार्यों पर भी बहुत सारे
00:00:47टोकन की खपत करता है जिसका अर्थ है कि ओपस का उपयोग करने से आपकी कॉन्टेक्स्ट लिमिट तेज़ी से भर जाती है।
00:00:52एंथ्रोपिक ने इस पर पासा पलटने का फैसला किया और वे "एडवाइजर स्ट्रैटेजी" नामक कुछ लेकर आए।
00:00:55यह रणनीति इस तरह काम करती है कि आप सॉनेट मॉडल को एक्ज़ीक्यूटर (निष्पादक) की भूमिका देते हैं
00:01:00और ओपस का उपयोग विशुद्ध रूप से एक सलाहकार के रूप में करते हैं जिससे केवल तभी परामर्श किया जाता है जब एक्ज़ीक्यूटर को वास्तव में इसकी आवश्यकता होती है।
00:01:05इसमें दो एजेंट शामिल हैं। एक्ज़ीक्यूटर आपका मुख्य एजेंट है जो सॉनेट पर चलता है और यह सभी
00:01:10टूल कॉल, कोड परिवर्तन और यूजर आउटपुट को संभालता है। सलाहकार ओपस पर चलता है और इसका एकमात्र
00:01:15काम एक्ज़ीक्यूटर के अटकने पर उसका मार्गदर्शन करना है। सलाहकार कभी कोड नहीं लिखता या कोई बदलाव नहीं करता।
00:01:20जब एंथ्रोपिक ने इस दृष्टिकोण के साथ प्रयोग किया, तो उन्होंने पाया कि इसने SWE बेंच पर अकेले सॉनेट से बेहतर प्रदर्शन किया।
00:01:25उन्होंने पाया कि इस संयोजन ने प्रदर्शन और लागत दोनों के मामले में अकेले सॉनेट को पीछे छोड़ दिया।
00:01:31और इसकी लागत ओपस को मुख्य एजेंट के रूप में चलाने से काफी कम है क्योंकि ओपस को केवल तभी बुलाया जाता है
00:01:36जब यह वास्तव में मायने रखता है, न कि हर एक प्रक्रिया के लिए। अब आप सोच सकते हैं कि हमारे पास पहले से ही
00:01:40ऐप बनाने के लिए बहुत सारे फ्रेमवर्क हैं जो बेहतर और उपयोग के लिए तैयार हैं, तो इस सेटअप की चिंता क्यों करें?
00:01:45कारण यह है कि अधिकांश मौजूदा फ्रेमवर्क लागत और टोकन दक्षता को ध्यान में रखकर नहीं बनाए गए हैं।
00:01:50भले ही वे काम पूरा कर लेते हैं, लेकिन जब क्लाउड को लंबे समय तक और अधिक कुशलता से चलाने की बात आती है तो वे पीछे रह जाते हैं
00:01:54क्योंकि वे मुख्य रूप से ऐप बनाने पर केंद्रित होते हैं न कि टोकन उपयोग के अनुकूलन पर।
00:01:59इस सेटअप के साथ, आप एक कमजोर मॉडल का उपयोग करके एक कार्यशील ऐप बना सकते हैं, जिससे
00:02:04पूरी प्रक्रिया कहीं अधिक टोकन कुशल हो जाती है। और यह वापस उसी सीमा समस्या से जुड़ता है जिसका हमने पहले उल्लेख किया था।
00:02:09हमने क्लाउड की सीमाओं पर पहले ही एक वीडियो बनाया है और आपको इसे लंबे समय तक चलाने के लिए छोटे मॉडल पर स्विच करने के लिए कहा था।
00:02:13यहाँ बताया गया है कि यह कैसे जुड़ता है। सॉनेट उसी कार्य को करने के लिए ओपस की तुलना में बहुत कम टोकन खर्च करता है और उसे कम मेहनत की आवश्यकता होती है।
00:02:19ओपस एक बहुत बड़ा और शक्तिशाली मॉडल है इसलिए यह सरल कार्यों के लिए भी बहुत सारे टोकन की खपत करता है।
00:02:24सॉनेट इनमें से कई कार्यों को अधिक कुशलता से संभालने में सक्षम है। इसलिए
00:02:30कठिन निर्णयों पर प्रदर्शन के अंतर को पाटने के लिए ओपस का उपयोग करना ही वास्तविक प्रभाव डालता है।
00:02:35आप उस शक्ति को केवल तभी बुला रहे हैं जब आपको वास्तव में इसकी आवश्यकता हो, न कि हर एक कार्य के लिए। यह
00:02:40कुल उपयोग को अधिक टोकन कुशल बनाता है और आपको समान सीमाओं के भीतर अधिक काम करने देता है। हम
00:02:45AI के साथ प्रोडक्ट बनाने के बारे में जो कुछ भी पाते हैं उसे इस चैनल पर साझा करते हैं, इसलिए यदि आप इस पर और वीडियो चाहते हैं
00:02:50तो सब्सक्राइब करें और भविष्य के वीडियो पर नज़र रखें। तो हम यह परीक्षण करना चाहते थे कि यह वास्तव में उस ऐप पर कैसे काम करता है
00:02:55जिसे पहले से ही सॉनेट का उपयोग करके बनाया गया था। क्लाउड कोड के अंदर रणनीति का उपयोग करने के लिए हमने एडवाइजर मॉडल के रूप में ओपस 4.6 के साथ
00:03:00एडवाइजर कमांड सेट किया। हमारा मुख्य एजेंट एक्ज़ीक्यूटर था जिसे मैंने पहले ही सॉनेट पर सेट कर दिया था
00:03:05क्योंकि मैंने इसे उपयोग करके ऐप बनाया था। ऐप में रीयल-टाइम सिंक होना चाहिए था और जबकि
00:03:10एलिमेंट्स को हिलाना और आकार बदलना सभी सेशन्स में पूरी तरह से सिंक हो रहा था, डिलीशन बिल्कुल भी सिंक नहीं हो रहा था। हमने
00:03:16अकेले सॉनेट के साथ कई बार इसे डीबग करने की कोशिश की लेकिन समस्या बनी रही, चाहे उसने मुद्दों को ठीक करने की कितनी भी कोशिश की हो।
00:03:20इसलिए सलाहकार के रूप में ओपस को चालू करने के बाद हमने क्लाउड को समस्या का विवरण देते हुए प्रॉम्ट दिया
00:03:25और क्योंकि सॉनेट पहले ही कई बार विफल हो चुका था, इसलिए खुद से एक और प्रयास करने के बजाय
00:03:30इस बार उसने सलाहकार को बुलाने का फैसला किया। सलाहकार ने स्थिति का आकलन करने के लिए अब तक की बातचीत की समीक्षा की।
00:03:34उसने सटीक बदलाव प्रदान किए जो किए जाने की आवश्यकता थी, यह पिनपॉइंट करते हुए कि सिंक लॉजिक कहाँ टूट रहा था
00:03:40और विशेष रूप से क्या पुनर्गठित करने की आवश्यकता थी। एक्ज़ीक्यूटर मॉडल ने उस सलाह को लिया
00:03:45और बिना किसी अतिरिक्त संवाद के उन सुधारों को सीधे लागू किया। हमने सिंक का परीक्षण करने के लिए कई
00:03:50डिवाइसेस पर इसका परीक्षण किया और पाया कि समस्या हल हो गई थी। दोनों छोरों पर डिलीशन
00:03:55उचित रूप से दिखाई दे रहा था, भले ही उपयोगकर्ता ने एक छोर पर आइटम चुना हो और दूसरा छोर डिलीट किया जा रहा हो,
00:04:00जो पहले नहीं हो रहा था। यदि हमने अकेले सॉनेट का उपयोग करके इसे ठीक करने का प्रयास किया होता
00:04:05तो इसमें बार-बार प्रॉम्ट देने के और अधिक दौर लगते क्योंकि सॉनेट स्वाभाविक रूप से एक कमजोर मॉडल है
00:04:09और अपने आप जटिल लॉजिक को संभालने के लिए पर्याप्त सक्षम नहीं है। दूसरी ओर, अकेले ओपस का उपयोग करने से
00:04:15कहीं अधिक टोकन खर्च होते और शायद यह इतना तेज़ नहीं होता। सलाहकार के रूप में ओपस के साथ सॉनेट का उपयोग करने से
00:04:20प्रक्रिया बहुत अधिक कुशल हो गई। कुल मिलाकर इस रणनीति ने सिंकिंग समस्याओं को पहले की तुलना में बहुत तेज़ी से डीबग करने में मदद की।
00:04:25लेकिन इससे पहले कि हम आगे बढ़ें, हमारे प्रायोजक JetBrains द्वारा Juni के बारे में कुछ शब्द।
00:04:30यदि आप एक डेवलपर हैं, तो आप अपने टर्मिनल, IDE और CI पाइपलाइनों के बीच संदर्भ स्विच करने के संघर्ष को जानते हैं
00:04:36सिर्फ काम पूरा करने के लिए। अधिकांश कोडिंग एजेंट आपको एक वातावरण या एक विशिष्ट LLM तक सीमित कर देते हैं
00:04:41और बस वहीं रुक जाते हैं। Juni CLI अलग है। यह एक LLM एग्नोस्टिक कोडिंग एजेंट है जो हर जगह काम करता है। आपका
00:04:47टर्मिनल, आपका IDE, GitHub, CI/CD पाइपलाइन, यहाँ तक कि आपका टास्क मैनेजर भी। हर जगह एक एजेंट। उसे असली
00:04:54काम सौंपें। टेस्ट लिखना, बैकएंड बनाना, रीफैक्टरिंग करना, हर कमिट पर ऑटोमेटेड कोड समीक्षा करना।
00:04:59अभी JetBrains एक फ्री अर्ली एक्सेस प्रोग्राम चला रहा है जिसमें एजेंट का परीक्षण करने के लिए $50 के जेमिनी क्रेडिट
00:05:04प्लस BYOK सपोर्ट शामिल है ताकि आप अपनी पसंद के किसी भी मॉडल का उपयोग कर सकें। सभी सुविधाओं तक पूर्ण पहुंच, नई सुविधाओं तक अर्ली एक्सेस
00:05:10और प्रोडक्ट को आकार देने वाली देव टीम से सीधा समर्थन। Juni के साथ यह बस बेहतर है।
00:05:15मुफ्त में शामिल होने के लिए पिन किए गए कमेंट में दिए गए लिंक पर क्लिक करें। अब हम यह परीक्षण करना चाहते थे कि क्या सॉनेट वास्तव में
00:05:20बड़े UI परिवर्तनों के लिए सलाहकार से परामर्श करता है। हमारे पास पहले से बना एक एप्लिकेशन था और हम
00:05:25इसके UI को एक अलग लाइब्रेरी में बदलना चाहते थे। इसके अलावा हम एक ही बार में कई UI बदलाव करना चाहते थे
00:05:31जिसकी आमतौर पर अनुशंसा नहीं की जाती है लेकिन हम देखना चाहते थे कि छोटे मॉडल बड़े कार्य पर बड़े मॉडल के साथ समन्वय में कैसा प्रदर्शन करते हैं।
00:05:36इसने सबसे पहले Playwright MCP का उपयोग करके वर्तमान UI तक पहुँच प्राप्त की। एक बार जब यह लेआउट को समझ गया,
00:05:41तो सीधे कोड परिवर्तनों में कूदने के बजाय इसने सलाहकार से सबसे अच्छा तरीका निर्धारित करने के लिए परामर्श किया
00:05:46क्योंकि यह एक बड़ा महत्वपूर्ण बदलाव था और गलत तरीके से संभालने पर ऐप को खराब कर सकता था। सलाहकार ने बताया कि
00:05:50जिस लाइब्रेरी को हमने नई लाइब्रेरी के रूप में चुना था और जो प्रोजेक्ट में पहले से उपयोग की जा रही थी, उनमें वर्जन संबंधी समस्याएं थीं।
00:05:55इसलिए इससे पहले कि कोई UI काम शुरू हो सके, क्लाउड को पहले इन्हें हल करने की आवश्यकता थी।
00:06:00सॉनेट ने उन्हें पहले संभाला, यह सुनिश्चित करने के लिए कई कमांड चलाए कि डिपेंडेंसी ठीक से लागू की गई थीं,
00:06:04फिर Playwright के माध्यम से UI की वर्तमान स्थिति की जाँच की ताकि पुष्टि हो सके कि ऐप अभी भी बिना किसी क्लाइंट साइड समस्या के सही ढंग से चल रहा था।
00:06:09एक बार जब डिपेंडेंसी व्यवस्थित हो गईं, तो इसने सलाहकार के सुझाव के अनुसार परिवर्तन करना शुरू कर दिया, प्रत्येक कंपोनेंट पर एक-एक करके काम किया
00:06:14और प्रभावी रूप से पूरे ऐप को फिर से डिजाइन किया। इसके द्वारा बनाया गया UI बहुत अधिक इंटरैक्टिव था
00:06:18और पहले की तुलना में काफी अधिक पॉलिश लग रहा था। इसमें अभी भी कुछ समस्याएं थीं लेकिन समग्र सुधार स्पष्ट था।
00:06:23लेकिन यहाँ सीमा सामने आई। पूरी प्रक्रिया में लगभग 31 मिनट लगे। ओपस अपने दम पर
00:06:27इसे बहुत तेज़ी से कर सकता था क्योंकि वह यह पहचान कर कार्यों को व्यवस्थित करने में बेहतर है कि क्या समानांतर (पैरलेल) में चल सकता है
00:06:32और उन्हें एक ही समय में निष्पादित कर सकता है। सॉनेट एक छोटा मॉडल होने के नाते, किसी भी काम को समानांतर सब-एजेंटों में तोड़े बिना
00:06:37सब कुछ क्रमिक रूप से संभालता रहा। एक ऐप के लिए जो उतना जटिल भी नहीं था,
00:06:4331 मिनट जरूरत से ज्यादा लंबा समय था। यह सलाहकार को शामिल किए बिना अपने दम पर छोटे बदलावों को भी संभालता है
00:06:48जो मामूली सुधारों के लिए सही व्यवहार है। लेकिन पूरे ऐप में इस तरह के बड़े पैमाने पर बदलावों के लिए
00:06:53बेहतर होगा कि आप सीधे ओपस का उपयोग करें क्योंकि इससे आपका काफी समय और प्रयास बचेगा।
00:06:58अब हम यह परीक्षण करना चाहते थे कि क्या यह मौजूदा कोड बेस पर पूरी तरह से नई सुविधा को ठीक से लागू करता है।
00:07:03हमारे पास पहले से ही एक ऐप बना हुआ था और हम उसमें एक अलग फीचर वाला एक और पेज जोड़ना चाहते थे।
00:07:08हमने उसे वह बताते हुए प्रॉम्ट दिया जो हम चाहते थे और इस बार हमें पूरी उम्मीद थी कि वह सलाहकार का उपयोग करेगा
00:07:13क्योंकि यह कोई आसान काम नहीं था, लेकिन वह आगे बढ़ गया और सलाहकार से परामर्श किए बिना पूरी तरह से अपने दम पर बदलाव लागू कर दिए।
00:07:17इसने पूरे काम को रूटीन कार्यान्वयन कार्य के रूप में माना जो फीचर के दायरे को देखते हुए स्पष्ट रूप से नहीं था।
00:07:22जब हमने एप्लिकेशन का परीक्षण किया, तो हमें कई समस्याएं मिलीं। यदि हमने कुछ संशोधित किया और रन बटन दबाया
00:07:27तो हेडिंग अपडेट या कलर एडजस्टमेंट जैसे बदलाव प्रिव्यू पेन के बाहर के कंपोनेंट्स में भी दिखाई दे रहे थे
00:07:31जो नहीं होना चाहिए था। इसके अलावा हम चाहते थे कि यह हर बदलाव के बाद फिर से रन दबाने की आवश्यकता के बिना
00:07:37सीधे सिंक हो जाए। इसलिए हमने इसे फिर से प्रॉम्ट दिया और इन समस्याओं को ठीक करने के लिए सलाहकार का उपयोग करने के लिए कहा।
00:07:41हमारे प्रॉम्ट पर इसने सबसे पहले सलाहकार एजेंट को बुलाया। सलाहकार ने कार्यान्वयन को देखा
00:07:46और पहचान की कि वास्तव में दोनों समस्याओं का कारण क्या था। वह था गलत कंपोनेंट का चुनाव।
00:07:51उसने बताया कि क्या बदलने की जरूरत है और क्यों मूल दृष्टिकोण ने पहली बार में उन समस्याओं को जन्म दिया था।
00:07:56एक्ज़ीक्यूटर ने वह मार्गदर्शन लिया और इसे पूरे ऐप में लागू किया। जब हमने इसका फिर से परीक्षण किया,
00:08:00तो स्ट्रीमिंग ने सही ढंग से काम किया। सभी बदलाव हमारे एडिट करते ही तुरंत दिखाई देने लगे, बिना
00:08:06हर संशोधन के बाद रन दबाने की आवश्यकता के। कंपोनेंट्स के बीच बदलावों के फैलने की समस्या भी हल हो गई थी
00:08:10और सही सीमाओं के भीतर सब कुछ ठीक से अपडेट हो गया। तो ऐसे समय होते हैं
00:08:16जब यह बिल्कुल इच्छानुसार काम करता है लेकिन अन्य समय में एक्ज़ीक्यूटर मान लेता है कि कोई कार्य काफी छोटा है और
00:08:20सलाहकार से परामर्श नहीं करने का फैसला करता है। उन मामलों में आपको अक्सर इसे खुद थोड़ा धक्का देना पड़ता है ताकि यह इच्छित वर्कफ़्लो का पालन करे।
00:08:25मॉडल हमेशा किसी कार्य की जटिलता को उसी तरह नहीं आंकता जैसे आप आंकते हैं और जब यह गलत अनुमान लगाता है
00:08:30तो आपको ऐसे बग मिलते हैं जिन्हें सलाहकार शुरू से ही पकड़ लेता। साथ ही यदि आप हमारी सामग्री का आनंद ले रहे हैं
00:08:35तो हाइप बटन दबाने पर विचार करें क्योंकि यह हमें इस तरह की और सामग्री बनाने और अधिक लोगों तक पहुँचने में मदद करता है।
00:08:40रीयल-टाइम डिस्ट्रीब्यूटेड स्टेट शामिल होने के कारण, इस दृष्टिकोण को सब कुछ सही ढंग से काम करने से पहले
00:08:44अभी भी प्रॉम्ट देने के कई दौरों की आवश्यकता थी। रणनीति ने मदद की लेकिन इसकी एक सीमा है
00:08:49जिसे आपको किसी प्रोजेक्ट के लिए प्रतिबद्ध होने से पहले समझना चाहिए। सरल से मध्यम स्तर के एप्लिकेशन के लिए,
00:08:54एडवाइजर स्ट्रैटेजी आपको बार-बार प्रॉम्ट देने के कई दौर बचा सकती है जो आप अन्यथा अकेले सॉनेट को
00:08:58उसकी सीमाओं से आगे धकेलने की कोशिश में बिताते। यदि आप जो बना रहे हैं उसके लिए कभी-कभार गहरी सोच की आवश्यकता होती है
00:09:02लेकिन अधिकतर कार्यान्वयन सीधा है, तो यह इसके लिए वास्तव में एक अच्छी संरचना है।
00:09:07आप अपनी टोकन सीमाओं के भीतर अधिक निर्माण कर सकते हैं बिना मॉडल के हर निर्णय की निगरानी किए या पूरे सेशन के लिए ओपस पर निर्भर हुए।
00:09:11कई जुड़ी हुई डिपेंडेंसी या कई विफलता बिंदुओं वाले जटिल ऐप के लिए, बेहतर होगा कि
00:09:16आप सीधे ओपस को अपने मुख्य एजेंट के रूप में उपयोग करें। भले ही सॉनेट सलाहकार के मार्गदर्शन का सही ढंग से पालन करे,
00:09:20फिर भी वह गलत कार्यान्वयन मार्ग चुन सकता है क्योंकि उसके पास एक साथ कई दृष्टिकोणों का मूल्यांकन करने
00:09:25और बाद के परिणामों को तौलने की तर्क शक्ति की गहराई नहीं है। सलाहकार उस अंतर को कम करने में मदद करता है
00:09:30लेकिन यह उसे पूरी तरह से खत्म नहीं करता। उन मामलों में बार-बार प्रॉम्ट देने की प्रक्रिया आपको
00:09:36शुरू से ही ओपस चलाने की तुलना में अधिक समय ले सकती है। तो यह रणनीति तब उपयोगी होती है जब आप
00:09:40सख्त टोकन सीमाओं के भीतर काम कर रहे हों और एप्लिकेशन को हर कदम पर ओपस स्तर के तर्क की आवश्यकता न हो।
00:09:45यदि आप जो बना रहे हैं उसके लिए ये दोनों शर्तें सच हैं तो इसे सेटअप करना फायदेमंद है।
00:09:50यह हमें इस वीडियो के अंत में लाता है। यदि आप चैनल का समर्थन करना चाहते हैं और इस तरह के वीडियो बनाने में हमारी मदद करना चाहते हैं
00:09:54तो आप नीचे सुपर थैंक्स बटन का उपयोग करके ऐसा कर सकते हैं। हमेशा की तरह, देखने के लिए धन्यवाद और मैं
00:09:58आपसे अगले वीडियो में मिलूँगा।
00:10:03सब्सक्राइब करना न भूलें।
00:10:08अलविदा।
00:10:12धन्यवाद।