छोटे मॉडल के साथ एजेंटिक कोडिंग वर्कफ़्लो

ठीक है।

नमस्ते.

मेरा नाम होज़े है. मेरे साथ इयान और ज़ोई भी हैं.

हम सभी एलएलएम के बारे में जानते हैं.

हम इनका इस्तेमाल हर काम के लिए करते हैं: रेसिपी ढूंढने, YouTube वीडियो की खास जानकारी पाने, और कोडिंग करने के लिए.

Gemini मॉडल जैसे बड़े एलएलएम, वाकई शानदार काम कर सकते हैं. हालांकि, इस बातचीत में हम स्मॉल लैंग्वेज मॉडल के बारे में बात करेंगे.

ये भी एलएलएम हैं, क्योंकि चार अरब पैरामीटर वाला मॉडल छोटा नहीं हो सकता. हालांकि, अब से हम इनमें अंतर करेंगे: फ़्रंटियर मॉडल और स्मॉल लैंग्वेज मॉडल. जैसे, रॉकेट और बाइक.

हम छोटे मॉडल के बारे में बात करेंगे. ज़रूरी नहीं है कि ये मॉडल, फ़्रंटियर मॉडल के विकल्प के तौर पर इस्तेमाल किए जाएं. हालांकि, ज़्यादातर मामलों में ये फ़्रंटियर मॉडल के साथ इस्तेमाल किए जाते हैं.

हम स्मॉल लैंग्वेज मॉडल के सभी फ़ायदों के बारे में जानेंगे. खास तौर पर, तब जब वे ओपन सोर्स हों, उनके वेट ओपन हों, और उन्हें डाउनलोड किया जा सकता हो. हालांकि, पहले लागत पर एक नज़र डालते हैं.

इस बातचीत के लिए, मैंने कई मानदंड चलाए हैं. इनमें से एक, 200 मीडियम और मुश्किल टास्क का डेटासेट था. इसमें नौ डॉलर से कम में करीब 13.1 करोड़ टोकन इस्तेमाल किए गए.

मैंने इसके लिए Gemma 4 का इस्तेमाल किया. इसलिए, मैं इसे डाउनलोड करके अपने हार्डवेयर पर मुफ़्त में चला सकता था. हालांकि, मैंने इसे एक कमर्शियल गेटवे पर चलाया, ताकि सही तुलना की जा सके.

ऐसे में, फ़्रंटियर मॉडल की कीमत कितनी होगी?

टोकन कैश मेमोरी और अन्य फ़ैक्टर के आधार पर, यह करीब 20 से 200 गुना ज़्यादा हो सकता है.

इसलिए, हो सकता है कि साइकल से यात्रा करना सबसे तेज़ तरीका न हो, लेकिन यह सबसे बेहतर तरीका ज़रूर है.

यह सच है.

अब सवाल यह है कि क्वालिटी और सटीक जानकारी के मामले में दोनों में क्या अंतर है?

इस डेटा सेट में, Gemma 4 53% टास्क हल कर सकता है.

इसका मतलब है कि:

अगर बाईं ओर दिए गए टास्क को पूरा करने के लिए फ़्रंटियर मॉडल का इस्तेमाल किया जा रहा है, तो यह ज़रूरत से ज़्यादा हो सकता है.

अगर दाईं ओर मौजूद टास्क को पूरा करने के लिए, छोटे मॉडल का इस्तेमाल किया जा रहा है, तो आपको मॉडल को समाधान की ओर ले जाना होगा या बड़े मॉडल का इस्तेमाल करना होगा.

इस बातचीत में, हम आपको हर टोकन का ज़्यादा से ज़्यादा फ़ायदा पाने में मदद करना चाहते हैं.

ज़ोई आपको छोटे मॉडल चुनने का तरीका बताएंगी. वहीं, इयान आपको Gemma मॉडल के बारे में बताएंगे, ताकि आप यह समझ सकें कि वे क्या कर सकते हैं.

इसके बाद, हम आपको Android Studio में Gemma 4 को आज़माने का तरीका बताएंगे. आखिर में, हम आपको छोटे मॉडल को अपने रोज़मर्रा के वर्कफ़्लो में फ़िट करने का तरीका बताएंगे. साथ ही, Android डेवलपमेंट के असल मानदंड भी दिखाएंगे, ताकि आपको यह समझने में मदद मिल सके कि वे क्या कर सकते हैं.

अब ज़ोई आपको आगे की जानकारी देंगी.

आपका बहुत-बहुत धन्यवाद, जोस.

इसलिए, हर काम के लिए एक ही मॉडल का इस्तेमाल करना, अखरोट को हथौड़े से तोड़ने जैसा है, है न?

यह असरदार है, लेकिन थोड़ा असंतुलित है.

इसलिए, छोटे मॉडल का इस्तेमाल करने का मतलब है कि आप अपने टूल सेट को बढ़ा रहे हैं.

अपने वर्कफ़्लो में क्या शामिल करना है, यह जानने के लिए आपको टूल सेट खोलना होगा. साथ ही, यह देखना होगा कि क्या उपलब्ध है, उनकी विशेषताएं क्या हैं, और वे किस काम के लिए अच्छे हैं.

इसलिए, छोटे मॉडल चुनने के लिए, आपको उनके बारे में जानना होगा.

जब भी लोग किसी लैंग्वेज मॉडल के बारे में सोचते हैं, तो वे आम तौर पर ऑटोरिग्रेसिव लैंग्वेज मॉडल के बारे में सोचते हैं.

यह ऑटोरिग्रेसिव है, क्योंकि यह टोकन में बांटे गए इनपुट के आधार पर, संभावित टोकन की सूची में से सबसे सही अगला टोकन चुनता है.

इसके बाद, चुने गए अगले टोकन को इनपुट में वापस भेज दिया जाता है. इस तरह, यह प्रोसेस आगे बढ़ती है. इससे, सही और समझदारी भरे जवाब जनरेट किए जा सकते हैं. हालांकि, इसमें कुछ चेतावनियां भी शामिल हैं. जैसे, लीनियर तरीके से काम करना. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं.

इसलिए, हम नॉन-लीनियर तरीके से काम कर सकते हैं.

डिफ़्यूज़न मॉडल का तरीका भी यही है, लेकिन यह एक बार में टोकन के ब्लॉक पर काम करता है.

यह बिलकुल वैसा है जैसे कोई स्केच धीरे-धीरे साफ़ दिखने लगे.

इस मामले में, DiffusionGemma एक बार में 256 टोकन के चंक पर काम करता है.

इसलिए, आपको एक ऐसा पास मिलता है जो पूरे ब्लॉक पर काम करता है. इससे कम इंतज़ार के समय में नतीजे जनरेट किए जा सकते हैं.

तो ठीक है, हमारे टूल सेट में ऐसे मॉडल हैं जो लिख सकते हैं, है ना?

गलत.

इसलिए, एंबेडिंग मॉडल, इमेज या टेक्स्ट जैसे ऑब्जेक्ट या किसी अन्य कॉन्सेप्ट को वेक्टर में बदल देते हैं.

इससे हमें कोऑर्डिनेट की मैपिंग मिलती है. मान लीजिए कि यह मैपिंग, हाई डाइमेंशन वाले स्पेस में होती है. इससे हमें दो चीज़ों की तुलना करने में मदद मिलती है.

उदाहरण के लिए, अगर हॉट डॉग एक सैंडविच है, तो वे एक-दूसरे के काफ़ी करीब होंगे या एक ही जगह पर खत्म होंगे.

इस वजह से, यह जांचना कि दो कॉन्सेप्ट आपस में जुड़े हैं या नहीं, मॉडल पास के बजाय थोड़ा सा गणित बन जाता है. यह भी थोड़ा सा गणित है, लेकिन यह पैराडाइम और भी आगे जाता है, है न?

वहीं, कुछ छोटे और खास कामों के लिए बनाए गए मॉडल भी होते हैं, जो किसी एक काम को बहुत अच्छे से कर सकते हैं.

उदाहरण के लिए, हमारे पास फ़ंक्शन मॉडल हैं, जो नैचुरल लैंग्वेज को एपीआई कॉल में बदलते हैं. विज़न मॉडल भी हैं, जिनके नाम से ही पता चलता है कि वे क्या कर सकते हैं. इसके अलावा, क्लासिफ़ायर भी हैं, जो कुछ पैरामीटर के आधार पर इनपुट को स्कोर दे सकते हैं.

ठीक है, तो आपके पास चुनने के लिए बहुत सारे विकल्प हैं, है न?

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

आखिर, छोटे मॉडल को कैसे चुना जाता है?

चलिए, Gemma मॉडल के बारे में जानते हैं. ये छोटे साइज़ वाले ओपन मॉडल हैं, जिन्हें स्थानीय तौर पर चलाया जा सकता है.

इयान, अब आपकी बारी.

धन्यवाद, ज़ोई.

जैसा कि जोस ने शुरुआत में बताया था, एक स्मॉल लैंग्वेज मॉडल, करीब 50% टास्क को बिना किसी अतिरिक्त ट्रेनिंग के पूरा कर सकता है.

हालांकि, आपको लोकल मॉडल क्यों चुनना चाहिए?

इसलिए, आपको चार चीज़ों पर ध्यान देना चाहिए.

पहली बात है निजता.

उदाहरण के लिए, आपके पास एपीआई पासकोड, मालिकाना हक वाला कोड या ऐसी चीज़ें हो सकती हैं जिन्हें आपके लैपटॉप से नहीं हटाया जा सकता.

दूसरा है, इंतज़ार का समय.

इसलिए, जब मॉडल को असल में मेमोरी में लोड किया जाता है, चाहे वह ग्राफ़िक्स मेमोरी हो या यूनिफ़ाइड मेमोरी, तब कंप्यूटिंग पूरी होते ही आपको जवाब मिल जाता है.

इसलिए, सर्वर पर दोतरफ़ा यात्रा का समय नहीं लगता और न ही इंतज़ार के समय की कोई अतिरिक्त लागत आती है.

इसके बाद, ज़ीरो मार्जिनल कॉस्ट की बारी आती है.

इसलिए, मॉडल तब किफ़ायती होते हैं, जब आपको यह कंट्रोल करने का विकल्प मिलता है कि उन्हें कहां चलाना है.

उदाहरण के लिए, लोकल मशीन पर कुछ चलाने के मामले में, गड़बड़ी वाले लूप में अतिरिक्त कोशिशें की जा सकती हैं.

इसके लिए आपको कोई शुल्क नहीं देना पड़ता. साथ ही, इस हिस्से के लिए एपीआई की कोई छिपी हुई लागत नहीं होती.

चौथी सुविधा है, बिना इंटरनेट के इस्तेमाल.

इसलिए, सोचिए कि इसका इस्तेमाल हवाई जहाज़, ट्रेन, बस या मेट्रो में किया जा सकता है. इसे कहीं भी इस्तेमाल किया जा सकता है, बशर्ते आपके हार्डवेयर पर मॉडल चल रहा हो.

यह तो बहुत अच्छी बात है, लेकिन इस तरह के फ़ैसले लेते समय हमें दो मुख्य बातों का ध्यान रखना होगा.

पहला है मेमोरी और दूसरा है स्पीड.

इसलिए, अगर आप इस डायग्राम को देखें, तो आपको सबसे नीचे मौजूद दो मॉडल, 26B और 31B दिखेंगे. इन दोनों को BF16 में चलाने के लिए, 50 जीबी से ज़्यादा वीडियो रैम की ज़रूरत होती है. BF16, 16-बिट क्वांटाइज़ेशन है.

इसलिए, यहां चुनौती यह है कि यह कई हार्डवेयर में फ़िट नहीं होगा.

इसलिए, हम क्वांटाइज़ेशन नाम की प्रोसेस का इस्तेमाल करते हैं. इससे सटीक जानकारी को कम करके, 4-बिट को फ़्लोट में बदला जाता है.

अब यह थोड़ा बेहतर लग रहा है.

हम 14 जीबी और 17 जीबी की बात कर रहे हैं, है न?

अब यह यूनिफ़ाइड मेमोरी वाले Mac जैसे डिवाइसों पर काम करेगा.

अब इसमें चुनौती यह है कि पोस्ट-ट्रेनिंग क्वांटाइज़ेशन में, जब उन वेट को कंप्रेस किया जाता है, तो बेस मॉडल की तुलना में मॉडल की सटीक जानकारी में थोड़ी कमी आ जाती है. हमारे पास इससे निपटने की एक तकनीक है.

इसे क्वांटाइज़ेशन-अवेयर ट्रेनिंग कहा जाता है.

ऐसा करने पर, मॉडल को ट्रेनिंग के दौरान यह पता होता है कि उसे छोटे साइज़ में काम करना है. इसलिए, इसमें ज़्यादा नुकसान नहीं होता.

इसलिए, हमें रैम की ज़रूरतों में 75% की कमी देखने को मिली. अब यह उन डिवाइसों पर भी काम कर सकता है.

हम एक कदम और आगे बढ़ते हैं.

इसलिए, हमारे पास मोबाइल क्वांटाइज़ेशन के जो तरीके हैं वे कई मोबाइल फ़ोन पर काम करते हैं. इनसे उन मॉडल को और भी छोटा किया जा सकता है. इसके लिए, यह समझना होगा कि सभी अलग-अलग लेयर कैसे काम करती हैं और वे किस साइज़ पर काम कर सकती हैं.

इसलिए, हमारे पास एक तरह का मिक्स्ड क्वांटाइज़ेशन बैग है.

इसलिए, हम 11.4 जीबी वाले Gemma E2B को 1.1 जीबी वाले मॉडल में बदल देते हैं.

इसलिए, अब यह मिड से लेकर हाई-एंड फ़ोन पर भी काफ़ी बेहतर तरीके से काम करता है.

इसके बाद, स्पीड की बारी आती है.

इसलिए, जब ऑटोरिग्रेसिव मॉडल का इस्तेमाल किया जाता है, तो जैसा कि ज़ोई ने बताया, टोकन के अगले सेट का अनुमान लगाया जाता है.

इसलिए, कोडिंग टास्क में आपको कई ऐसे टोकन मिल सकते हैं जिनका अनुमान लगाना काफ़ी आसान होता है. जैसे, किसी मेथड सिग्नेचर का आखिर या ओपनिंग या क्लोज़िंग ब्रेस.

इसलिए, स्पेक्युलेटिव डिकोडिंग नाम की तकनीक का इस्तेमाल किया जा सकता है.

इससे यह होगा कि यह कई टोकन का अनुमान लगाने के लिए, छोटे ड्राफ़्टर मॉडल का इस्तेमाल करेगा. इसके बाद, बड़े मॉडल से उनकी पुष्टि की जाएगी.

Gemma 4 आर्किटेक्चर में यह सुविधा इसलिए काम करती है, क्योंकि ये एक ही केवी कैश मेमोरी शेयर करते हैं.

इसलिए, इसे मॉडल की शॉर्ट-टर्म मेमोरी की तरह समझें.

इसलिए, ऐसा होगा कि एक छोटा ड्राफ़्टर मॉडल, समय से पहले तीन या चार टोकन का अनुमान लगाएगा. इसके बाद, बड़ा मॉडल उसी केवी कैश मेमोरी को देखेगा और आउटपुट की पुष्टि करेगा.

इससे मॉडल की परफ़ॉर्मेंस करीब तीन गुना बढ़ जाती है. साथ ही, मॉडल के आउटपुट की क्वालिटी पर कोई असर नहीं पड़ता. ऐसा इसलिए होता है, क्योंकि यह सिर्फ़ अनुमान लगाता है और फिर तय करता है कि यह पास है या फ़ेल, यह सही है या नहीं.

इसलिए, यह आपके टास्क पर निर्भर करता है.

इसलिए, यह क्रिएटिव राइटिंग जैसी चीज़ों पर ज़्यादा असरदार नहीं होता, क्योंकि इसमें ज़्यादा वैरिएशन होते हैं. हालांकि, यह JSON स्ट्रक्चर और कोडिंग जैसी चीज़ों पर बहुत अच्छा काम करता है.

तो, इनमें से किसी एक मॉडल का आकलन कैसे किया जाएगा?

इसलिए, सबसे पहले आपको LiveCodeBench या MMLU जैसे किसी बेंचमार्क पर जाकर स्कोर देखना चाहिए.

हालांकि, इससे आपको मॉडल की क्षमता के बारे में सिर्फ़ एक हाई-लेवल इंडिकेटर मिलेगा.

आपको यह देखना होगा कि यह किस स्टैक में चल रहा है.

इसलिए, यह वह मॉडल है जिसका इस्तेमाल किया जा रहा है. इसमें वेट और क्वांटाइज़ेशन का तरीका शामिल है. यह रनटाइम का अनुमान है. इसलिए, हो सकता है कि आप llama.cpp, Ollama या LiteRT जैसा कुछ इस्तेमाल करें. यह एआई मॉडल के लिए फ़्रेमवर्क है, जिसका इस्तेमाल किया जा रहा है. भले ही, वह Pi, OpenCode या Antigravity जैसा हो. इसके बाद, कॉन्टेक्स्ट विंडो आती है. यह उस डेटा के लिए स्पेस है जिसे आपको अपने मॉडल से प्रोसेस कराना है.

इन सभी चीज़ों को मिलाकर ही यह तय होता है कि कोई आइडिया कितना कारगर है.

उदाहरण के लिए, हम Android Bench पर Gemma 4 की टेस्टिंग कर रहे थे. साथ ही, हम Ollama का एक वर्शन चला रहे थे, जिसमें डिफ़ॉल्ट रूप से 32k कॉन्टेक्स्ट था.

हमें एक टेस्ट में पता चला कि जब मॉडल किसी गड़बड़ी को ढूंढ रहा था, तब एआई मॉडल के लिए फ़्रेमवर्क के कंपैक्शन की वजह से, वह फ़ाइल आउट ऑफ़ मेमोरी चली गई. इसके बाद, मॉडल टास्क को पूरा नहीं कर पाया और फ़ेल हो गया.

इसलिए, कॉन्टेक्स्ट विंडो को 32 हज़ार से बढ़ाकर 2.56 लाख करने से, अब यह जानकारी को मेमोरी में सेव रख सकता है. साथ ही, मॉडल उस टेस्ट को पास कर सकता है.

हमने देखा कि उस खास काम में सफलता की दर दोगुनी हो गई.

इससे पता चलता है कि इनमें से कोई एक छोटा फ़ैक्टर भी इस बात पर बड़ा असर डाल सकता है कि यह मॉडल सही है या नहीं.

अपने कॉन्टेंट की समीक्षा खुद कैसे करें?

इसलिए, यहां तीन सुझाव दिए गए हैं.

एक तरीका यह है कि Git का इतिहास लिया जा सकता है. इसमें कई पीआर शामिल होते हैं जो पहले से ही सफल हैं. इन्हें मॉडल के लिए प्रॉम्प्ट इनपुट के तौर पर इस्तेमाल किया जा सकता है. इससे यह देखा जा सकता है कि मॉडल उन पर कितना अच्छा परफ़ॉर्म करता है.

इसके बाद, आपको डिटरमिनिस्टिक ग्रेडर जैसी किसी चीज़ की ज़रूरत होगी. इससे आपको यह आकलन करने में मदद मिलेगी कि मॉडल का आउटपुट सही है या नहीं.

हमारे पास इसके दो बेहतरीन उदाहरण हैं.

हमारे पास एक कंपाइलर और यूनिट टेस्ट हैं.

जो भी जनरेट होता है उसे इस टूल की मदद से चलाया जा सकता है. इससे आपको पता चलेगा कि आपने उस टास्क को पूरा किया है या नहीं.

तीसरा है, लॉग ट्रैजेक्ट्री.

इसलिए, जब कोई एजेंट चलाया जाता है, तो आपको उसके अलग-अलग व्यवहार को ट्रैक करना होता है. साथ ही, यह देखना होता है कि वह कहां सफल होता है और कहां विफल. इसका इस्तेमाल करके, यह आकलन किया जा सकता है कि मॉडल, टूल के साथ कितनी अच्छी तरह से इंटरैक्ट कर सकता है और उनका इस्तेमाल कर सकता है.

मैं चाहता हूं कि आप सवाल पूछने का अपना तरीका बदलें. जैसे, "क्या यह मॉडल, इस बड़े फ़्रंटियर मॉडल जितना स्मार्ट है?"

"क्या इस हार्डवेयर पर इस कॉन्फ़िगरेशन के साथ यह टास्क पूरा किया जा सकता है?"

इस बात का पता लगाने के लिए, हमने एक फ़्रेमवर्क बनाया है. इसका नाम है, "क्या हम वहां पहुंच गए?"

या AWTY.

इस फ़्रेमवर्क का मुख्य सिद्धांत यह है कि इन सभी अलग-अलग टास्क को रेडीनेस के हिसाब से स्कोर किया जाए.

इसलिए, मॉडल, इस्तेमाल किया जा रहा इन्फ़्रेंस इंजन, हार्नेस, और हार्डवेयर कॉन्फ़िगरेशन.

इससे आपको पता चलेगा कि आप तैयार हैं या नहीं.

उदाहरण के लिए, हो सकता है कि आप यह देख रहे हों कि कोई टास्क कितना भरोसेमंद है.

अगर इसे लगातार 10 बार चलाया जाए, तो क्या यह हर बार एक जैसा काम करता है?

ऐसा हो सकता है कि आपको इंतज़ार का समय दिख रहा हो.

शायद आपको रीयल-टाइम में जवाब चाहिए.

जैसे, टास्क को पूरा करने की स्पीड के लिए आपकी थ्रेशोल्ड क्या हैं?

इसके बाद, आपको रैम की ज़रूरी शर्तों के बारे में जानकारी मिल सकती है.

इसलिए, यह सिर्फ़ डिवाइस की रैम की बात नहीं है, बल्कि यह इस बात पर भी निर्भर करता है कि डिवाइस की रैम में से कितनी रैम को एआई के लिए अलग से रखा जा सकता है. साथ ही, उस हार्डवेयर पर अन्य ऐप्लिकेशन और टूल चलाने के लिए कितनी रैम की ज़रूरत होगी.

इसलिए, क्या रैम का 50% या सिर्फ़ 10% इस्तेमाल किया जा सकता है?

इसके बाद, आपको फ़ाइनल रेडीनेस स्कोर मिलता है.

अगर यह हरे रंग का है, तो इसका मतलब है कि कॉन्फ़िगरेशन तैयार है.

अगर यह नारंगी, पीला या लाल है, तो इसका मतलब है कि आपको कॉन्फ़िगरेशन में कुछ बदलाव करने की ज़रूरत है.

हो सकता है कि आपको कम इंतज़ार के समय के लिए, तेज़ ऐक्सेलरेटर की ज़रूरत हो. इसके अलावा, हो सकता है कि आपको ज़्यादा क्षमता वाले बड़े मॉडल की ज़रूरत हो.

इसलिए, हमारा सुझाव है कि आप इस पर एक नज़र डालें.

फ़िलहाल, हमने इस टूल की झलक दिखाई है. हमें यह जानकर खुशी होगी कि यह टूल आपके लिए कितना मददगार है.

ज़ोई, बाद में आपको इस बारे में ज़्यादा जानकारी देंगी कि हम कुछ आकलन कैसे सेट अप करते हैं. हालांकि, अब मैं जोज़े को बुलाना चाहूंगा, जो आपको Gemma 4 का इस्तेमाल शुरू करने का एक बहुत ही आसान तरीका बताएंगे.

धन्यवाद, इयान.

इसलिए, Gemma 4 को आज़माने का सबसे तेज़ तरीका, Android Studio है.

चलिए, बताता हूँ कैसे.

चलिए, लैपटॉप पर स्विच करते हैं.

बहुत अच्छा।

इसलिए, अगर मैं सेटिंग में जाकर, मॉडल प्रोवाइडर पेज पर जाऊँ और Gemma को चुनूँ, तो आपको हर मॉडल के साइज़ के बारे में साफ़ तौर पर पता चल जाएगा.

मुझे बस अपनी हार्ड ड्राइव में मॉडल डाउनलोड करने होंगे.

इससे llama.cpp सर्वर खुलता है या शुरू होता है. साथ ही, यह आपके लिए शुरू से ही सही तरीके से कॉन्फ़िगर हो जाता है.

हालांकि, आपके पास अपने llama.cpp सर्वर, Ollama या LM Studio का इस्तेमाल करने का विकल्प भी है.

इसके लिए, आपको बस यहां आना होगा और स्थानीय सेवा देने वाली कंपनी को जोड़ना होगा.

साथ ही, रिमोट प्रोवाइडर के ज़रिए छोटे मॉडल इस्तेमाल करना काफ़ी फ़ायदेमंद होता है.

इसलिए, यहाँ कोई भी मॉडल जोड़ा जा सकता है. बस वह OpenAI या Anthropic के साथ काम करता हो.

ठीक है, चलिए देखते हैं.

Android Studio में मॉडल चुनने के लिए, इस ड्रॉप-डाउन का इस्तेमाल करें.

मैंने Gemma 4 26B को चुना है. अब मैं इससे पूछ सकता हूँ, "ViewModel क्या है?"

ठीक है।

इसलिए, आपको एक अहम बात याद रखनी होगी. वह यह कि जब भी मॉडल बदला जाता है, तो पूरी बातचीत को नए मॉडल पर फिर से भेजा जाता है.

इसलिए, अगर आपने किसी मॉडल के साथ काफ़ी लंबी बातचीत की है और आपको किसी नए मॉडल पर स्विच करना है, तो आपको नई बातचीत शुरू करनी चाहिए या उसे छोटा करना चाहिए या कुछ और करना चाहिए.

चलिए, अब फिर से स्लाइड पर वापस चलते हैं और ज़ोई से जानते हैं कि छोटे मॉडल की मदद से, कौन-कौनसे वर्कफ़्लो चलाए जा सकते हैं.

जोसे और इयान, Gemma मॉडल के बारे में खास जानकारी देने के लिए आपका बहुत-बहुत धन्यवाद. साथ ही, यह बताने के लिए भी कि हम इस दिशा में कितना आगे बढ़ चुके हैं.

हमने देखा कि किस तरह के मॉडल उपलब्ध हैं और उनकी क्या खासियतें हैं. अब यह समझना ज़रूरी है कि उनसे किस तरह के काम कराए जा सकते हैं.

पहले टाइप के काम ऐसे हैं जो शायद आप पहले से ही कर रहे हैं. जैसे, डीबग करने या समस्या हल करने जैसे कोडिंग वर्कफ़्लो. इसके अलावा, कुछ ऐसे काम भी हैं जिन्हें मुझे पूरा भरोसा है कि हर कोई या कम से कम मैं तो बहुत ही मज़ाकिया अंदाज़ में मिस करूंगा. जैसे, टेस्ट कवरेज बढ़ाना.

है न?

इसलिए, ये कुछ ऐसी चीज़ें हैं जो मुझे पूरा यकीन है कि हर कोई पहले से ही कर रहा है. भले ही, उन्हें इस बात का एहसास न हो.

हालांकि, मैं आपको इससे आगे सोचने के लिए बढ़ावा देना चाहूंगा.

छोटे मॉडल, ओपन-वेट हो सकते हैं और स्थानीय तौर पर चलाए जा सकते हैं. ऐसे में, आपको क्या लगता है कि किस तरह के काम में आपका समय बच सकता है?

है न?

हम रॉकेट का इस्तेमाल न करने की बात कर रहे हैं, तो इसके लिए हम दिमाग का इस्तेमाल क्यों कर रहे हैं?

अगर हम इससे आगे बढ़ें, तो छोटे मॉडल क्या कर सकते हैं?

ऐसे कौनसे वर्कफ़्लो हैं जिनमें एआई का इस्तेमाल किया जा सकता है, ताकि आपका काम आसान हो जाए और आपके पास उन कामों को करने के लिए ज़्यादा समय हो जो आपको ज़्यादा पसंद हैं?

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

ये कुछ उदाहरण हैं, है न?

आखिर में, कुछ हद तक यह कहा जा सकता है कि नामुमकिन कुछ भी नहीं है या आर्किटेक्चर ही इसकी सीमा है. ऐसी कई चीज़ें हैं जिनके बारे में सोचा जा सकता है कि उन्हें कैसे लागू किया जाए.

तो, स्पेसिफ़िकेशन, टूल, और वर्कफ़्लो होने के बाद भी, क्या आपको अब भी समझ नहीं आ रहा कि शुरुआत कहां से करें?

बेंचमार्क की जानकारी वाली रिपोर्ट इसी काम आती है.

इयान ने बताया कि सामान्य लीडरबोर्ड, खास तौर पर Python के लिए, आपको इस बारे में बहुत कम जानकारी देगा कि कोई छोटा मॉडल आपके Android वर्कफ़्लो के लिए मददगार होगा या नहीं.

ठीक उसी तरह जैसे ड्रायवॉल ड्रिल के बारे में जानने से, आपको कंक्रीट ड्रिल के बारे में ज़्यादा जानकारी नहीं मिल सकती.

हालांकि, आपको अपने इवैल्यूएशन में निवेश करना चाहिए.

आपको अपने आर्किटेक्चर की जांच करने में निवेश करना चाहिए. हालांकि, ऐसा करने से पहले, हो सकता है कि आप सभी संसाधनों का इस्तेमाल न करना चाहें.

इसमें समय, पैसा, और मेहनत लगती है. इसलिए, सार्वजनिक तौर पर उपलब्ध बेंचमार्क देखने से आपको एक आइडिया और छोटी सूची मिल सकती है. इसके बाद, खुद के आकलन में निवेश करने का फ़ैसला लिया जा सकता है.

बेंचमार्क का आकलन करते समय, आपको तीन चीज़ों पर ध्यान देना चाहिए. है न?

यह थोड़ा मेटा है, लेकिन सबसे पहले यह जानना ज़रूरी है कि यह मॉडल किस तरह का टास्क कर रहा है, है न?

यह कितना खास है.

क्या यह उस तरह के टास्क जैसा दिखता है जो आपको इसे देना है?

दूसरा, टास्क का दायरा.

क्या यह दस्तावेज़ लिखना है, क्या यह पीआर को हल करना है, क्या यह कुछ ऐसा है जो आपके पास मौजूद काम जैसा दिखता है?

आखिर में, क्या सिस्टम की जटिलता, उस जटिलता के जैसी है जो आपको देनी है?

यहां हम देख सकते हैं कि Python बेंचमार्क, Android के लिए बहुत ज़्यादा मददगार क्यों नहीं है.

इसलिए, हमने Android Bench बनाया है. यह एक ऐसा बेंचमार्क है जो Android ईकोसिस्टम और Android पर किए जाने वाले काम को कैप्चर करता है.

पहले वर्शन में, Android के 100 टास्क शामिल हैं. ये टास्क, पीआर साइज़ के हैं. इसे आज ही Harbor के ज़रिए चलाया जा सकता है. इससे किसी भी एजेंट, मॉडल, और स्किल के कॉम्बिनेशन की जांच की जा सकती है.

हमने 2.0 को ज़्यादा मुश्किल और लंबे समय तक चलने वाले टास्क के साथ लॉन्च किया है. इससे यह समझने में मदद मिलती है कि फ़्रंटियर मॉडल, आज के समय में दिए जाने वाले टास्क को किस तरह से पूरा कर सकते हैं.

अब मैं जोस को बुलाना चाहूंगा, ताकि वे आपको इस प्रयोग के नतीजे दिखा सकें. साथ ही, छोटे मॉडल के साथ काम करने के तरीके बता सकें.

ठीक है, धन्यवाद, ज़ोई.

ठीक है, तो चलिए उन टास्क को देखते हैं जिन्हें एक छोटा मॉडल पूरा कर सकता है और जहां उन्हें परेशानी होती है.

चलिए, टास्क को चार कैटगरी में बांटते हैं: छोटे, मीडियम, बड़े, और लंबे समय तक चलने वाले टास्क.

लंबे समय तक चलने वाले टास्क ऐसे टास्क होते हैं जिन्हें पूरा करने में किसी व्यक्ति को कई दिन या हफ़्ते लग सकते हैं.

उदाहरण के लिए, माइग्रेशन, बड़ा रीफ़ैक्टरिंग, और स्पॉइलर अलर्ट. छोटे मॉडल से ये काम नहीं किए जा सकते.

कम से कम एक बार में.

हम इस बारे में बाद में बात करेंगे.

ठीक है, छोटे टास्क.

ये ऐसे काम होते हैं जिनमें एक या दो फ़ाइलों को पढ़ने और लिखने की ज़रूरत होती है. साथ ही, इनके लिए ज़्यादा जानकारी की ज़रूरत नहीं होती.

उदाहरण के लिए, छोटे मॉडल Compose के लिए काफ़ी अच्छे होते हैं. कम से कम Compose की बुनियादी बातों के लिए.

जैसे, एलिमेंट के बीच 8 डीपी का स्पेस होना चाहिए, हार्डकोड किए गए रंगों के बजाय थीम का इस्तेमाल करना चाहिए या स्ट्रिंग को एक्सट्रैक्ट करना चाहिए.

छोटे मॉडल के लिए, ये काम बहुत आसान हैं.

हालांकि, इस टास्क में ज़्यादा ऐडवांस विषय शामिल है. इसके बावजूद, यह टास्क आसान है.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

इस मामले में, समस्या जानकारी की नहीं, बल्कि स्कोप की है.

इसलिए, प्रॉम्प्ट से हमें पता चलता है कि किस कंपोज़ेबल को ऑप्टिमाइज़ करना है और उसमें क्या गड़बड़ी है: यह हर फ़्रेम पर फिर से कंपोज़ हो रहा है.

इसलिए, Gemma 4 जैसे छोटे मॉडल के लिए भी यह काम काफ़ी आसान हो जाता है.

इस मामले में, इसमें तीन मिनट लगे और यह एक लाइन का बदलाव है.

ठीक है।

इसलिए, मुझे लगता है कि हमें इस बारे में काफ़ी अच्छी जानकारी है कि स्मॉल मॉडल क्या होता है.

आइए, एक छोटे से टास्क पर नज़र डालते हैं.

आइए, मीडियम टास्क पर नज़र डालते हैं.

छोटे मॉडल, इनमें से ज़्यादातर काम कर सकते हैं.

इस टास्क में, Pocket Casts ऐप्लिकेशन से किए गए अनुरोध में यूज़र-एजेंट मौजूद नहीं है. साथ ही, फिर से कोशिश करने के लॉजिक में गड़बड़ी है.

यह थोड़ा मुश्किल है, क्योंकि हम एक ही समय पर दो चीज़ों का अनुरोध कर रहे हैं. साथ ही, इस बारे में कोई जानकारी नहीं है कि ये चीज़ें कोड बेस में कहां मौजूद हैं.

हालांकि, अब यह समस्या ठीक हो गई है.

इसमें 10 मिनट लगे.

इसने तीन फ़ाइलों में बदलाव किया.

OpenRouter के ज़रिए, इस काम में सिर्फ़ छह सेंट खर्च हुए.

अब एक ऐसे टास्क को देखते हैं जो इसी डेटासेट से फ़ेल हो गया.

यह Now in Android का एक उदाहरण है. इसमें काफ़ी ज़्यादा जानकारी वाली रिपोर्ट या प्रॉम्प्ट है. हालांकि, इसमें क्लास का नाम या फ़ाइल का नाम नहीं दिया गया है. इसलिए, एजेंट को ऐप्लिकेशन के आर्किटेक्चर, डेटा लेयर, सिंक करने के तरीके वगैरह को समझने के लिए ज़्यादा मेहनत करनी होगी. इसलिए, इस बार यह टास्क पूरा नहीं हो पाया.

सब कुछ सही तरीके से लागू किया गया था. हालांकि, इसमें यह मान लिया गया था कि शुरुआती सिंक की वैल्यू -1 होगी, लेकिन असल में यह 0 है.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

बस इतना ही.

अगर एजेंट ने मौजूदा यूनिट टेस्ट चलाए होते, तो इस गड़बड़ी का पता चल जाता.

इससे पता चलता है कि आम तौर पर छोटे मॉडल, फ़्रंटियर मॉडल की तुलना में थोड़ा पहले रुक जाते हैं.

हमने एजेंट से सिर्फ़ समस्या को ठीक करने के लिए कहा था, उसकी पुष्टि करने के लिए नहीं.

इसलिए, हमें टास्क में बदलाव करना चाहिए, ताकि उसमें पुष्टि करने का चरण शामिल हो.

हम इस बारे में भी थोड़ी देर में बात करेंगे.

चलिए, अब बड़े टास्क के बारे में बात करते हैं.

इस परिभाषा के मुताबिक, बड़े टास्क में से करीब आधे टास्क हर बार पास हो जाते हैं.

कुछ प्रॉम्प्ट, छोटे मॉडल के लिए बहुत लंबे और जटिल होते हैं. इसलिए, वे काम नहीं करते. ऐसे में, ज़्यादा कुछ नहीं किया जा सकता.

हालांकि, कुछ मामलों में ऐसा भी होता है कि जब आप असल में हुई घटना को देखते हैं, तो आपको पता चलता है कि मॉडल 90 या 90 प्रतिशत तक सही था.

इसलिए, चलिए इनमें से कोई एक चुनते हैं.

मैंने इसे इसलिए चुना, क्योंकि यह क्रिस्पी है.

यह टेस्ट, आधे से ज़्यादा मामलों में पास हो जाता है.

इसलिए, मुझे लगता है कि यह एक छोटे मॉडल की क्षमता की सीमा है.

या कम से कम अप्रैल में लॉन्च किया गया कोई मॉडल.

यह Coil लाइब्रेरी में गलत तरीके से बनाए गए यूआरएल को पार्स करने से जुड़ी है.

जैसा कि आप देख सकते हैं, पीआर की जानकारी काफ़ी ज़्यादा है, जो कि अच्छी बात है. हालांकि, इसमें एक ज़रूरी शर्त शामिल नहीं की गई है.

चलिए, इस पर एक नज़र डालते हैं.

सभी रन में, सामान्य यूआरएल एन्कोडिंग और गड़बड़ियों की जांच की गई. हालांकि, उनमें से सिर्फ़ कुछ (आधे) रन में, खराब तरीके से एन्कोड किए गए वर्णों के लिए टेस्ट जोड़े गए. इसलिए, वहां टेस्ट केस मौजूद है.

जिन वीडियो को समीक्षा में पास नहीं किया गया.

इसलिए, सभी रन करीब-करीब सही हैं. हालांकि, इससे फिर से पता चलता है कि छोटे मॉडल हमेशा अतिरिक्त कदम नहीं उठाते.

ये निर्देशों का पालन करते हैं, लेकिन फ़्रंटियर मॉडल की तरह आपको प्रभावित करने की कोशिश नहीं करते.

क्या आपको पता है कि आजकल एजेंट में मेहनत का लेवल कैसे सेट किया जा सकता है?

छोटे मॉडल का इस्तेमाल करते समय, ध्यान रखें कि इसे बहुत कम पर सेट किया गया हो.

इसलिए, आइए बड़े टास्क को ऐसे टास्क के तौर पर परिभाषित करें जिन्हें छोटे मॉडल करीब 50% बार पूरा कर सकते हैं. Gemma 4 31B, Android Bench v1 डेटासेट के ख़िलाफ़ इस लक्ष्य को हासिल कर सकता है. इसके बारे में ज़ोई ने पहले बताया था.

लंबे समय तक चलने वाले टास्क के बारे में बात करने से पहले, क्या हम छोटे मॉडल की मदद से उन टास्क को पूरा करने के लिए कुछ कर सकते हैं?

बिलकुल, और इन चीज़ों के लिए आपको कोई मेहनत नहीं करनी पड़ती.

सबसे पहले, अगर Gemma 4 जैसे किसी मॉडल का इस्तेमाल लोकल डिवाइस पर किया जा रहा है, तो पक्का करें कि उसे सही तरीके से कॉन्फ़िगर किया गया हो.

उदाहरण के लिए, अगर Gemma 4 को चलाने के लिए Ollama का इस्तेमाल किया जाता है, तो यह डिफ़ॉल्ट रूप से 32,000 टोकन वाली कॉन्टेक्स्ट विंडो का इस्तेमाल करता है. हालांकि, यह इससे आठ गुना ज़्यादा टोकन वाली कॉन्टेक्स्ट विंडो का इस्तेमाल कर सकता है.

अगर Android Studio के ज़रिए Gemma 4 का इस्तेमाल किया जाता है, तो आपको इसे कॉन्फ़िगर करने की ज़रूरत नहीं है.

यह डिफ़ॉल्ट रूप से सही तरीके से कॉन्फ़िगर किया गया होता है.

हमारे आकलन के सेट में, पूरा कॉन्टेक्स्ट चालू करने से नतीजे 26% से बढ़कर 53% हो गए.

इसके बाद, Android का सीएलआई टूल का इस्तेमाल करें. खास तौर पर, दस्तावेज़ खोजने के लिए.

यह हमेशा लागू नहीं होता, क्योंकि मॉडल बुनियादी बातों में काफ़ी अच्छे होते हैं. हालांकि, जब भी किसी नए या खास एपीआई का इस्तेमाल किया जाता है, तो दस्तावेज़ होना ज़रूरी है.

हमारे अनुभव के मुताबिक, यह वेब सर्च टूल इस्तेमाल करने से कहीं बेहतर है.

इसके बाद, पुष्टि करने के लिए हिंट जोड़ें.

हमने इस बारे में बात की थी.

मॉडल को बताएं कि टेस्ट कैसे चलाएं, किस तरह के टेस्ट उपलब्ध हैं, एम्युलेटर कैसे मैनेज करें वगैरह. इसके लिए, AGENTS.md फ़ाइल का इस्तेमाल किया जा सकता है. इससे सभी एजेंट को निर्देश उपलब्ध हो जाएंगे. हालांकि, यह एक अच्छी बात है.

आपके पास यह होना चाहिए.

हालांकि, बहुत लंबी AGENTS.md फ़ाइलों पर भी ध्यान दें. ऐसा इसलिए, क्योंकि अलग-अलग एजेंट आज़माने पर, आपको पता चलेगा कि उनमें से कुछ में सिस्टम प्रॉम्प्ट और टूल के ब्यौरे बहुत ज़्यादा हैं. साथ ही, ऐसा लगता है कि वे छोटे मॉडल की परफ़ॉर्मेंस को कम कर देते हैं.

हमने OpenCode के साथ इन बेंचमार्क को चलाने की कोशिश की. हालांकि, इसकी परफ़ॉर्मेंस Pi से काफ़ी कम रही. ऐसा शायद इसलिए हुआ, क्योंकि यह टूल के बड़े ब्यौरे और सिस्टम प्रॉम्प्ट का इस्तेमाल करता है.

इसके बाद, स्किल जोड़ें और हटाएं.

छोटे मॉडल को नए और खास एपीआई का इस्तेमाल करते समय, कुछ मदद की ज़रूरत पड़ सकती है. हालांकि, बेहतर होगा कि उनके कॉन्टेक्स्ट को Compose की सामान्य स्किल से न भरें.

लंबे समय तक चलने वाले टास्क के बारे में क्या?

ये ऐसे टास्क होते हैं जिनमें दर्जनों फ़ाइलें शामिल होती हैं. इनमें आर्किटेक्चर से जुड़े अहम फ़ैसले लेने होते हैं. आम तौर पर, इन्हें सोचने की क्षमता वाला मॉडल हैंडल करता है. यह मॉडल एक प्लान बनाता है और कई सब-एजेंट शुरू करता है, जो अलग-अलग टास्क को पूरा करते हैं.

लंबे समय तक चलने वाले टास्क के उदाहरण: किसी पूरे ऐप्लिकेशन को एक्सएमएल से Compose में माइग्रेट करना, किसी जटिल ऐप्लिकेशन को शुरुआत से बनाना या क्रॉस-प्लैटफ़ॉर्म ऐप्लिकेशन को नेटिव Android में बदलना.

अगर हम Android Bench V2 के नतीजों को देखें, तो पता चलता है कि फ़्रंटियर मॉडल का स्कोर 3 से 40% के बीच है. Android Bench V2, लंबे समय तक चलने वाली प्रक्रियाओं पर फ़ोकस करता है.

इसलिए, छोटे मॉडल के लिए यह कहना सही होगा कि यह उनके बस की बात नहीं है.

हालांकि, शुरुआती विश्लेषण को फ़्रंटियर मॉडल के ज़रिए रूट करने और फिर आसान टास्क को छोटे मॉडल पर कैस्केड करने से, टोकन और क्रेडिट का ज़्यादा बेहतर तरीके से इस्तेमाल किया जा सकेगा.

आइए, देखते हैं कि ऐसा कैसे किया जा सकता है.

ज़ोई पर वापस जाएं.

आपका बहुत-बहुत धन्यवाद, जोस.

हम कैस्केड के बारे में बात करेंगे. हालांकि, इससे पहले कि हम आपको कुछ तरीके दिखाएं या इस बारे में ज़्यादा जानकारी दें, हम आपको अन्य तरीके दिखाना चाहते हैं जिनसे अलग-अलग मॉडल को व्यवस्थित करने में मदद मिल सकती है.

इसलिए, ऑर्केस्ट्रेशन की मदद से, उदाहरण के लिए, आपको कभी ब्लॉक नहीं किया जा सकता, है न?

इसलिए, चाहे आपको किसी प्रोवाइडर की परफ़ॉर्मेंस में गिरावट दिख रही हो या आपको एपीआई अनुरोध की संख्या सीमित करने की सुविधा का सामना करना पड़ रहा हो या आप किसी हवाई जहाज़ या ट्रेन में हों, जैसा कि इयान ने बताया था, आपके पास फ़ॉलबैक मॉडल सेट अप करने का विकल्प होता है. इससे, चाहे आप ऑनलाइन हों या स्थानीय तौर पर, कुछ भी होने पर आप आगे बढ़ सकते हैं.

ऑर्केस्ट्रेशन की मदद से, बेहतर जवाब भी पाए जा सकते हैं.

उदाहरण के लिए, आपके पास एक छोटा मॉडल हो सकता है जो अपने-आप काम करता है. जब भी उसे थोड़ी मदद की ज़रूरत होती है, तो वह किसी सलाहकार को कॉल करता है.

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

इसके अलावा, टेस्ट के लिए अलग मॉडल का इस्तेमाल भी किया जा सकता है.

इसलिए, यह एक पीयर रिव्यू की तरह है.

और आप इसे इसके ज़रिए देख सकते हैं.

इसके अलावा, ऑर्केस्ट्रेशन की मदद से, कैस्केड जैसी चीज़ों का इस्तेमाल करके लागत को कम किया जा सकता है.

इसे मैन्युअल तरीके से सेट अप किया जा सकता है. जैसे, प्लानिंग के लिए एक मॉडल, उसे लागू करने के लिए दूसरा मॉडल, और टेस्ट के लिए तीसरा मॉडल सेट किया जा सकता है.

ऐसा करने के कई तरीके हैं. जैसे, क्लाउड पर या फिर LiteLLM प्रॉक्सी सेट अप करके, इसे स्थानीय तौर पर किया जा सकता है.

इसके अलावा, क्लासिफ़ायर का इस्तेमाल करके, अनुरोध के आधार पर उसे सही मॉडल पर अपने-आप रूट किया जा सकता है. यह प्रॉक्सी का आइडिया है, जिसके बारे में इयान ने बताया था. हालांकि, यह अपने-आप काम करता है.

चलिए, अब हम उस सवाल पर वापस आते हैं जो जोज़े ने बातचीत की शुरुआत में पूछा था. वह सवाल यह था कि छोटे मॉडल और फ़्रंटियर मॉडल की क्वालिटी और सटीक जानकारी देने की क्षमता में क्या अंतर है?

कंप्यूटर साइंस की कई चीज़ों की तरह, इसका जवाब भी इस बात पर निर्भर करता है कि आपको किस तरह का काम करना है.

हालांकि, मैं आपको बताना चाहूंगा कि इस तरह की चीज़ें खुद भी बनाई जा सकती हैं.

इस पर आपका कंट्रोल होता है. इसे सेट अप करने और इसके अलग-अलग हिस्सों को इस्तेमाल करने के तरीके से, इसमें बदलाव किया जा सकता है.

सबसे पहले, सही टूल चुनें.

कई तरह के टूल उपलब्ध हैं.

उन्हें जानें, उन्हें एक्सप्लोर करें, है ना?

इसके बाद, यह पता लगाएं कि वे कौनसी नौकरियां कर सकते हैं या कौनसी नौकरियां उनके लिए सही हैं.

दूसरा, यह पक्का करें कि मॉडल को काम करने के लिए जो स्कोप मिल रहा है उसे अडजस्ट किया जाए.

उदाहरण के लिए, टास्क के लिए निर्देश, टास्क के लिए सही कॉन्टेक्स्ट उपलब्ध कराना, और सिर्फ़ टास्क के लिए सही कॉन्टेक्स्ट उपलब्ध कराना. साथ ही, अपने काम की जांच करने के तरीके.

इसके बाद, आपको पूरे सेटअप की जांच करनी होगी, न कि सिर्फ़ मॉडल की. ऐसा इसलिए, क्योंकि इससे फ़र्क़ पड़ेगा. साथ ही, अगर आपने इसे एलिमेंट के अलग कॉन्फ़िगरेशन के साथ सेट अप किया है, तो हो सकता है कि आपको मिलने वाले नतीजों में बदलाव किया जा सके.

आखिर में, आपको खुद के इवैल्युएशन सेट अप करने या बनाने होंगे.

आखिर में, साइकल और रॉकेट को एक साथ इस्तेमाल किया जा सकता है, ताकि आपको दोनों में से किसी एक को चुनने की ज़रूरत न पड़े. साथ ही, इससे असरदार तरीके से खर्च किया जा सके.

हालांकि, सबसे ज़रूरी बात यह है कि आपके पास एक्सप्लोर करने, कॉन्टेंट बनाने, और मज़े करने का विकल्प हमेशा रहेगा, है न?

इसकी शुरुआत आज ही की जा सकती है. इसके लिए, Android Bench और वहां मौजूद नतीजों की मदद से, मॉडल की एक शॉर्टलिस्ट बनाएं. इसके अलावा, Android Studio पर Gemma 4 का इस्तेमाल करके भी शुरुआत की जा सकती है.

इसलिए, आपका बहुत-बहुत धन्यवाद.