वर्चुअल वॉइस एजेंट में, इंतज़ार का समय बहुत कम रखने और क्लाउड इकोनॉमिक्स के बीच संतुलन बनाना

डेविन राइमर

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

मेरा नाम डेविन राइमर है.

मैं AstroBeam का फ़ाउंडर और सीईओ हूं.

इससे पहले, मैं Owlchemy Labs का सीईओ और को-फ़ाउंडर था. यह कंपनी, Job Simulator के लिए जानी जाती है.

इसलिए, AstroBeam में हम गेम में रीयल-टाइम एआई बनाने पर फ़ोकस कर रहे हैं.

खास तौर पर, हम वॉइस इनपुट पर ज़्यादा ध्यान दे रहे हैं.

हमने अब तक दो गेम रिलीज़ किए हैं. इनमें से एक Stellar Cafe है, जो वीआर और पीसी पर उपलब्ध है.

यह एक ऐसा गेम है जिसमें आपको स्पेस स्टेशन कैफ़े में रोबोट से बात करनी होती है और उनकी समस्याएं हल करने में मदद करनी होती है.

यह पूरी तरह से आवाज़ से कंट्रोल होता है.

मेन्यू और नेविगेशन के साथ-साथ, पूरा गेम सिर्फ़ अपनी आवाज़ से खेला जा सकता है.

हमारा अगला गेम, Robo Detective, Android XR और खास तौर पर XREAL के Project Aura के लिए बनाया गया है. हमने आज ही इसका एलान किया है.

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

इसलिए, वॉइस एजेंट बनाना वाकई मुश्किल है. गेम में तो यह और भी मुश्किल है.

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

इसके अलावा, हम अन्य वॉइस एजेंट के साथ मुकाबला नहीं कर रहे हैं. हम अब तक बनाए गए हर गेम की क्वालिटी के साथ मुकाबला कर रहे हैं, है न?

इसलिए, हमें अच्छी क्वालिटी का कॉन्टेंट बनाना होगा.

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

हालांकि, ये गेम हैं, इसलिए इनमें कुछ मुश्किल समस्याओं को हल करने के लिए, एक्सपेरिमेंट करने की काफ़ी गुंजाइश होती है.

इसलिए, मेरा मानना है कि अगर वॉइस एजेंट गेम में काम कर सकते हैं, तो वे कहीं भी काम कर सकते हैं.

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

वॉइस एजेंट के बारे में सोचते समय, मुझे लगता है कि तीन मुख्य चुनौतियां हैं.

इसलिए, हमारे पास इंतज़ार का समय, इंटेलिजेंस, और लागत है.

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

हम किसी ऐसे माइक्रोफ़ोन रैपर की बात नहीं कर रहे हैं जो एलएलएम को कुछ भेजता है और फिर जवाब का इंतज़ार करता है.

मेरा मतलब है कि रीयल-टाइम में, रीयल-वर्ल्ड में होने वाली बातचीत. इसे बनाना काफ़ी मुश्किल होता है.

तो चलिए, इंतज़ार के समय से शुरू करते हैं.

इसे कितनी जल्दी पूरा करना है?

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

आइए, कुछ आंकड़ों के बारे में बात करते हैं. ये आंकड़े, हमें कई टेस्ट करने के बाद मिले हैं.

इसलिए, जब मैं एंड-टू-एंड इंतज़ार के समय की बात करता हूँ, तो मेरा मतलब उस समय से होता है जो उपयोगकर्ता के आखिरी बार बोलने या कोई आवाज़ निकालने से लेकर, उसे ऑडियो वापस सुनाई देने तक का होता है.

हमने अपनी टेस्टिंग में पाया कि जब हम उपयोगकर्ताओं से Play की टेस्टिंग के बारे में सुझाव/राय लेते हैं, तो वे 1.5 सेकंड के बाद, स्पीड या धीमे होने या ऐसी किसी भी चीज़ के बारे में नहीं बताते.

इस समय तक, लोग इस सुविधा का इस्तेमाल करने में काफ़ी सहज हो जाते हैं.

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

इसके बाद, जब हमने इसे और तेज़ किया, तो हमें पता चला कि करीब 1.2 सेकंड में, कुछ और नैचुरल चीज़ें होने लगती हैं. जैसे, आगे-पीछे होना.

जैसे, अगर मैं कुछ कहूँ, तो इस मामले में रोबोट, बहुत जल्दी कुछ कहेगा और आप इस तरह से बातचीत कर सकते हैं.

ऐसा लगता है कि इस मामले में, कुछ हद तक सफलता मिली है.

हालांकि, स्टैक में 1.2 सेकंड में ऐसा करना काफ़ी मुश्किल है.

इसके बाद, एक और दिलचस्प बात यह है कि हमने बहुत सारी टेस्टिंग की. इससे हमें कुछ ऐसे तरीके मिले जिनसे एक सेकंड से भी कम समय में नतीजे दिखाए जा सकते हैं.

इसलिए, आपको लग सकता है कि "अरे, यह तो बहुत बढ़िया होगा!"

कभी-कभी ऐसा होता था और कभी-कभी बहुत बुरा लगता था.

इसलिए, हो सकता है कि आपको लोगों से यह सुनने को मिले कि 800 मिलीसेकंड का रिस्पॉन्स टाइम सही है या 500 मिलीसेकंड का.

मैंने 300 के बारे में कई लेख भी पढ़े हैं, क्योंकि इंसानों की सोच इसी पर आधारित है.

हकीकत यह है कि यह पूरी तरह से कॉन्टेक्स्ट पर निर्भर करता है.

उदाहरण के लिए, अगर मैं आपसे आपका नाम पूछूं, तो मुझे अंदाज़ा होता है कि आपको जवाब देने में कितना समय लगेगा.

अगर मैं तुमसे पूछूँ कि ज़िंदगी का मतलब क्या है, तो मुझे उम्मीद है कि तुम जवाब देने में ज़्यादा समय लोगी.

जब हमने असल में टेस्टिंग की और लोगों से पूछा कि उन्हें यह जवाब तेज़ लगा या धीमा, तो हमें अलग-अलग तरह के जवाब मिले.

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

साथ ही, यह भी पता चलता है कि वे बातचीत में किस जगह पर थे.

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

हालांकि, कभी-कभी आपको बहुत कम समय में जवाब मिल जाता है. इससे आपकी उम्मीदें बढ़ जाती हैं.

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

इसलिए, जब आप 1.5 सेकंड के इस पॉइंट पर पहुंच जाते हैं, तो आपको एक जैसी क्वालिटी बनाए रखने की चिंता होने लगती है, है न?

अगर 90% मामलों में ऐसा होता है, लेकिन 10% मामलों में तीन सेकंड लगते हैं, तो आपका अनुभव खराब नहीं, बल्कि अधूरा लगेगा.

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

डेविन राइमर

यह स्टैंडर्ड वॉइस पाइपलाइन आर्किटेक्चर है.

इसलिए, हम बोली को लिखाई में बदलने की सुविधा का इस्तेमाल करके, टेक्स्ट को एलएलएम में भेज रहे हैं. इसके बाद, एलएलएम से मिले नतीजे को लिखाई को बोली में बदलने की सुविधा में भेज रहे हैं.

मेरा मतलब है कि बोली को लिखाई में बदलने की सुविधा के लिए, हम ऑडियो को सर्वर पर भेजते हैं और फिर उसे टेक्स्ट में बदलते हैं.

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

हम इन दोनों को एक साथ जोड़ते हैं, क्योंकि हमें लगता है कि यह बहुत ज़रूरी है.

इसके बाद, हम उस टेक्स्ट को लिखे गए शब्दों को सुनने की सुविधा पर भेजते हैं. फिर, उसे उपयोगकर्ता के लिए स्ट्रीम करते हैं. साथ ही, उसे उन कार्रवाइयों के साथ सिंक करते हैं जो एजेंट करना चाहता है.

इसकी एक समस्या यह है कि इसे क्रम से चलाने में काफ़ी समय लग सकता है, क्योंकि आपको इनमें से हर एक चीज़ को एक-एक करके देखना पड़ता है.

इसलिए, मुझसे अक्सर यह सवाल पूछा जाता है कि अगर यह प्रोसेस धीमी है और इसमें तीन चरण शामिल हैं, तो इसके बजाय स्पीच-टू-स्पीच मॉडल का इस्तेमाल क्यों नहीं किया जाता?

क्योंकि इससे काम जल्दी हो जाएगा, है न?

हां, ज़्यादातर मामलों में यह तरीका तेज़ होता है, क्योंकि इसमें एक ही चीज़ चल रही होती है.

हालांकि, इसके कुछ बड़े नुकसान भी हैं.

इसलिए, भले ही यह तेज़ है, लेकिन हमारे लिए कुछ बड़ी समस्याएं हैं. इनमें से सबसे बड़ी समस्या लागत है.

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

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

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

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

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

ऐसा नहीं हो सकता कि आप कहें, "अरे, क्या आपको पता है?

इस मामले में, मुझे इस तरह की आवाज़ का इस्तेमाल करना है."

आप उसी एक विकल्प तक सीमित रह जाते हैं.

पाइपलाइन वाले तरीके में, आपके पास यह विकल्प होता है कि "अरे, मुझे इसे बदलना है.

मैं इस मॉडल को चुनूंगा, क्योंकि यह मॉडल इस खास इस्तेमाल के लिए बहुत अच्छा काम करता है."

यही बात इंटेलिजेंस पर भी लागू होती है, है न?

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

आप एक तरह से लॉक हो जाते हैं.

पाइपलाइन वाले तरीके में, आपको लगता है कि "इस इस्तेमाल के उदाहरण के लिए, मुझे किसी खास मॉडल का इस्तेमाल करना है."

स्पीच-टू-स्पीच मोड का एक फ़ायदा यह है कि यह उपयोगकर्ता के लहजे को समझ सकता है.

जैसे, व्यंग्य और इस तरह की अन्य चीज़ें.

फ़िलहाल, बोली को लिखाई में बदलने की सुविधा से तैयार की गई ट्रांसक्रिप्ट में आम तौर पर ज़्यादा जानकारी नहीं होती. हालांकि, मुझे लगता है कि समय के साथ इसमें बदलाव होगा.

यह सुविधा, Speech-to-Speech की सबसे बड़ी खासियत है.

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

तो क्या कोई और तरीका है?

हां.

हमें पाइपलाइन को पैरलल करने की पूरी कोशिश करनी चाहिए.

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

आत्मविश्वास से मेरा मतलब है कि ट्रांसक्रिप्ट में जनरेट किए जा रहे शब्दों पर भरोसा और फिर टर्न के खत्म होने पर भरोसा.

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

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

उपयोगकर्ता बोलता रहता है.

हालांकि, ऐसी स्थिति में भी हम एलएलएम को रद्द कर देते हैं और फिर से चलाते हैं.

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

हम एलएलएम से पूरा जवाब जनरेट होने का इंतज़ार नहीं करते. जवाब जनरेट होते ही, हम उसे लिखे गए शब्दों को सुनने की सुविधा (टीटीएस) पर भेजना शुरू कर देते हैं.

हम इंतज़ार करते हैं कि हमें पहला ऐसा चंक मिले जिसे बोला जा सके.

ज़्यादातर मामलों में, एक ही वाक्य में काम हो जाता है.

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

इसके बाद, अगर हमारे पास टेक्स्ट-टू-स्पीच की अच्छी सुविधा है, तो वह स्ट्रीम होगी. जैसे ही वह स्ट्रीम होने के लिए तैयार होगी, वह उपयोगकर्ता के पास आ जाएगी.

हम इस बात का भी ध्यान रखते हैं कि कितने टोकन जनरेट करने हैं.

इसलिए, हम JSON रैपर जैसी चीज़ों का इस्तेमाल नहीं करते. इनसे अतिरिक्त टोकन जुड़ सकते हैं.

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

अगर हमें पहले से पता होता है कि एजेंट से मिलने वाले टोकन का पहला हिस्सा क्या होगा, तो हम असिस्टेंट की मदद से पहले से जानकारी भरने जैसी सुविधाओं का भी इस्तेमाल करते हैं.

लिखे गए शब्दों को सुनने की सुविधा के लिए, ये दो हिस्से बन गए, है न?

इसलिए, पहले बोलने वाला हिस्सा आता है और फिर हम बाकी सब कुछ चलाते हैं.

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

इसलिए, यह उपयोगकर्ता को नहीं दिखता.

यह जितनी जल्दी हो सके उतनी जल्दी वहां पहुंच जाता है.

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

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

इसलिए, मैं कितनी तेज़ी से चीज़ें अपलोड और डाउनलोड कर सकता/सकती हूं?

बोली को लिखाई में बदलने की सुविधा के मामले में, हम इस बात का ध्यान रखते हैं कि इस सुविधा को इस्तेमाल करने में लोगों को ज़्यादा समय न लगे.

इसलिए, यह ट्रांसक्रिप्ट और बातचीत के खत्म होने पर भरोसा है.

जो साथ में जोड़े गए हैं, है न?

अगर आपको किसी एक पर भरोसा नहीं है, तो यह उतना ही धीमा होगा, है ना?

इसलिए, इसकी स्पीड सबसे धीमी स्पीड वाले डिवाइस के बराबर ही होती है.

एलएलएम के मामले में, हम इस बात का ध्यान रखते हैं कि पहला वाक्य जनरेट होने में कितना समय लगता है. यह वाक्य, जनरेट किए गए टेक्स्ट का पहला हिस्सा होता है.

इसके दो हिस्से हैं, है न?

यह पहले टोकन में लगने वाले समय और हर सेकंड जनरेट होने वाले टोकन की संख्या का कॉम्बिनेशन है.

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

इसलिए, यह पता लगाएं कि इसके लिए सही कॉम्बिनेशन क्या है.

लिखे गए शब्दों को सुनने की सुविधा के लिए, आपको इस बात का ध्यान रखना होगा कि पहला ऑडियो कितनी देर में जनरेट हो.

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

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

इसके बाद, जैसा कि मैंने पहले बताया था, सबसे ज़्यादा ज़रूरी है कि इंटरनेट कनेक्शन स्टेबल हो. इससे कोई फ़र्क़ नहीं पड़ता कि इंटरनेट की स्पीड कितनी ज़्यादा है या सबसे सही स्थिति क्या है.

इस पूरे स्टैक की लेटेंसी कितनी है?

डेविन राइमर

इसलिए, फ़िलहाल हम अपने ऑडियो एजेंट फ़्रेमवर्क के लिए LiveKit का इस्तेमाल कर रहे हैं.

बोली को लिखाई में बदलने के लिए, हम Deepgram का इस्तेमाल कर रहे हैं.

एलएलएम के लिए, हम Gemma 4 31B का इस्तेमाल कर रहे हैं. इसे हम LiveKit पर होस्ट करते हैं.

लिखे गए शब्दों को सुनने की सुविधा के लिए, हम Inworld AI की text-to-speech 2 सुविधा का इस्तेमाल कर रहे हैं.

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

मैंने सुरक्षा से जुड़े मॉडल के बारे में बात नहीं की है.

इसलिए, आम तौर पर सुरक्षा मॉडल, एलएलएम पास का हिस्सा होते हैं. हालांकि, इससे इंतज़ार का समय बढ़ जाता है और एक अतिरिक्त चरण भी जुड़ जाता है.

तो कैसा रहेगा, अगर आप खुद का कारोबार शुरू करें?

इसलिए, हमारा स्टैक असल में ऐसा दिखता है.

इसलिए, हम यहां यह कर रहे हैं कि जब हमें टेक्स्ट का पहला हिस्सा वापस मिलता है, तो हम उसे टेक्स्ट-टू-स्पीच मॉडल को भेजते हैं. ठीक उसी समय, हम उसे अपने सुरक्षा मॉडल को भी भेजते हैं.

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

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

यह हमारे लिए बहुत ज़रूरी है, क्योंकि हम गेम बना रहे हैं.

उस दुनिया के बारे में बहुत सारी जानकारी है, जो बेहद ज़रूरी है.

उदाहरण के लिए, मान लें कि आपने मध्यकालीन समय पर आधारित कोई गेम बनाया है. इस गेम में एक एनपीसी है, जो चिल्लाता है, "हमला करो!

इनका सिर कलम कर दो!", है न?

सुरक्षा का पारंपरिक मॉडल कुछ ऐसा हो सकता है, "अरे, यह सही नहीं है.

आपको ऐसा नहीं कहना चाहिए."

हालांकि, इस गेम के हिसाब से यह बिलकुल सही है.

इसके लिए, हम ज़्यादा मज़बूत सुरक्षा मॉडल का इस्तेमाल करते हैं. इसमें दुनिया भर में हो रही घटनाओं के बारे में ज़्यादा जानकारी होती है, ताकि हम इस काम को बेहतर तरीके से कर सकें.

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

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

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

डेविन राइमर

तो, इसे कितना स्मार्ट होना चाहिए?

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

अक्सर लोग इस बारे में नहीं सोचते कि उन्हें किस तरह की इंटेलिजेंस की ज़रूरत है.

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

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

इसलिए, हम इसे प्राथमिकता देते हैं. अगर हम इन चीज़ों को तेज़ी से नहीं बना सकते, तो हम उपयोगकर्ताओं तक चीज़ें नहीं पहुंचा सकते.

इसलिए, इन दोनों के बारे में सोचना बहुत ज़रूरी है.

अक्सर, जब लोग इंटेलिजेंस के बारे में सोचते हैं, तो वे एलएलएम के बारे में सोचते हैं, है न?

हालांकि, यह इस सुविधा के ढेरों पहलुओं में से एक है.

जब बात इंटेलिजेंस की हो, तो हमें हर पहलू पर ध्यान देना होगा.

चलिए, बोली को लिखाई में बदलने की सुविधा के बारे में बात करते हैं.

इसलिए, हमें यहां शब्दों की गड़बड़ी की दर कम रखनी है.

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

अगर गड़बड़ी की दर कम है, लेकिन गलतियां बहुत ज़्यादा हैं, तो एलएलएम को यह समझने में ज़्यादा मुश्किल होगी कि असल मकसद क्या था.

एक और बात पर ध्यान देना ज़रूरी है कि आपका टारगेट प्लैटफ़ॉर्म क्या है.

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

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

इसलिए, आपको इस बारे में सोचना होगा. पक्का करें कि आपने सही प्लैटफ़ॉर्म चुना हो.

अब बात करते हैं, लिखे गए शब्दों को सुनने की सुविधा के बारे में.

क्या यह नैचुरल लग रहा है?

हमारा मकसद, उपयोगकर्ता को यह बताना है कि वह क्या समझ सकता है?

लेकिन यह तो सिर्फ़ एक हिस्सा है, है न?

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

इसके बाद, क्या यह काफ़ी तेज़ है?

पिछले सेक्शन में, मैंने इंतज़ार के समय के बारे में बात की थी. हालांकि, यह इंटेलिजेंस के लिए भी मायने रखता है.

उपयोगकर्ताओं को लगता है कि जवाब देने की स्पीड, सीधे तौर पर इस बात से जुड़ी होती है कि जवाब कितना सटीक है.

अगर मैं तुरंत जवाब देती हूँ, तो शायद यह ज़्यादा स्मार्ट लगता है.

इसलिए, ये चीज़ें वाकई मायने रखती हैं कि उपयोगकर्ता को कैसा अनुभव मिल रहा है और वह उसमें कितना खो सकता है.

अब बात करते हैं एलएलएम की इंटेलिजेंस की.

इसे बैलेंस करना सबसे मुश्किल है, क्योंकि इसमें कई अलग-अलग ज़रूरी शर्तें शामिल हैं, है न?

इसलिए, हमारे पास स्पीच को समझने, कॉन्टेक्स्ट, और ग्राउंडिंग की सुविधा है.

गेम में यह काफ़ी मुश्किल होता है, क्योंकि आपको पूरी दुनिया और ब्रह्मांड को ध्यान में रखना होता है, है न?

यह कोई टेक्स्ट बॉक्स नहीं है, जिसमें यह अपने हिसाब से चीज़ें बना सके.

अगर गेम में आपका एजेंट कहता है, "टेबल पर एक सेब है" और टेबल पर कोई सेब नहीं है, तो इससे उपयोगकर्ता का अनुभव खराब होगा.

हमें नियमों का सख्ती से पालन करने की भी ज़रूरत है.

गेम, नियमों पर आधारित होते हैं.

क्या एलएलएम इस तरह की चीज़ों को हैंडल कर सकता है?

क्या हम हैलूसिनेशन रेट को कम कर सकते हैं?

क्या एक ही एजेंट के साथ बार-बार इंटरैक्ट करने पर, हमें एक जैसे किरदार मिल सकते हैं?

क्या आपको लगता है कि यह वही एजेंट है?

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

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

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

क्या यह प्रॉम्प्ट, इस बढ़ती हुई संख्या को मैनेज कर पाएगा?

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

हालांकि, यह तो बस शुरुआत है. यह इस बात पर भी निर्भर करता है कि आपको क्या बनाना है.

इसलिए, आपको इस बारे में बहुत गहराई से सोचना होगा कि आपको क्या बनाना है और क्या हासिल करना है.

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

डेविन राइमर

तो इसे कितना सस्ता होना चाहिए?

हालांकि, यह उतना भी आसान नहीं है.

इसलिए, हमें उस ऐप्लिकेशन या गेम की इकोनॉमिक्स के बारे में सोचना होगा जिसे हम बना रहे हैं, है ना?

इसलिए, आपको कुछ सवाल पूछने होंगे.

उपयोगकर्ता आपके वॉइस एजेंट के साथ कितनी देर तक इंटरैक्ट करेगा?

हर उपयोगकर्ता से आपकी कितनी कमाई हो रही है?

वॉइस स्टैक को चलाने में हर घंटे कितना खर्च आता है?

हमने उन्हें एक साथ रखकर, यह समझने की कोशिश की कि क्या वे सही हैं.

यहां हमारे पहले गेम, Stellar Cafe की इकोनॉमिक्स के बारे में बताया गया है.

Stellar Cafe में गेम खेलने का समय, डेढ़ से साढ़े तीन घंटे के बीच है. इसलिए, हम इसे औसतन दो घंटे मान लेते हैं.

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

यह गेम पूरी तरह से आवाज़ से कंट्रोल होता है.

हम गेम के लिए 10 डॉलर का फ़्लैट शुल्क लेते हैं, जो कि सामान्य है.

हम सदस्यताएं नहीं देते, क्योंकि गेम में इन्हें मैनेज करना बहुत मुश्किल होता है. मेरा मानना है कि हमें इसे एक तय कीमत पर उपलब्ध कराना होगा. ऐसा न करने पर, यह काम नहीं करेगा और इसे बड़े पैमाने पर उपलब्ध नहीं कराया जा सकेगा.

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

और यह 1.20 डॉलर, वह कीमत है जो हम अभी चुका रहे हैं.

यह कोई यूनिवर्सल कीमत नहीं है.

मैंने देखा है कि इन चीज़ों की कीमत अलग-अलग होती है और कभी-कभी ये बहुत महंगी होती हैं.

इसलिए, आपको यह भी पता लगाना होगा कि लागत के मामले में आप कहां खड़े हैं.

हम इसे और सस्ता कर सकते थे, लेकिन हम क्वालिटी को जितना हो सके उतना बेहतर बनाने की कोशिश कर रहे हैं.

इसलिए, इस पर काम करते हुए, इसका मतलब है कि दो घंटे के गेम खेलने के समय में, हर उपयोगकर्ता के लिए हमारे वॉइस स्टैक की कीमत करीब 2.40 डॉलर है.

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

इसलिए, यह तरीका काम करता है, है न?

आवाज़ ही हमारा हुक है. हम इसी पर पैसे खर्च करना चाहते हैं. यह काम करता है.

इसलिए, यह बहुत छोटा गेम है.

चलिए, अब कुछ और बड़ा करते हैं.

चलिए, एक काल्पनिक गेम के बारे में बात करते हैं. यह एक नैरेटिव गेम है, जिसे खेलने में पांच से नौ घंटे लगते हैं. मान लेते हैं कि इसे खेलने में औसतन सात घंटे लगते हैं.

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

इसलिए, हम 1.20 डॉलर प्रति घंटे की दर को बरकरार रखेंगे. हालांकि, हम यह बदलाव करेंगे कि वॉइस कॉम्पोनेंट का इस्तेमाल 60% समय के लिए किया जाएगा. ऐसा इसलिए, क्योंकि बड़े गेम में वॉइस के अलावा और भी कई चीज़ें होती हैं.

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

इसलिए, अगर हम 20 डॉलर चार्ज करते हैं, तो इस पर फिर से काम करने पर, हमें हर उपयोगकर्ता के लिए करीब 5 डॉलर खर्च करने होंगे. इसका मतलब है कि आखिर में, हमें हर उपयोगकर्ता से करीब 9 डॉलर मिलेंगे.

इसलिए, इस तरह से भी कमाई की जा सकती है.

हालांकि, इसका मतलब यह नहीं है कि यह तरीका हर चीज़ के लिए काम करेगा.

उदाहरण के लिए, आपको ऐसा नहीं करना चाहिए, "ओह, मुझे मुफ़्त में खेला जाने वाला गेम बनाना है. शायद इस गेम को लोग एक घंटे से लेकर 100 से ज़्यादा घंटों तक खेलेंगे."

इसलिए, हम मान लेते हैं कि औसतन 10 घंटे लगते हैं.

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

आपको हर उपयोगकर्ता से 10 डॉलर का नुकसान होगा.

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

आखिर तक इंतज़ार न करें.

डेविन राइमर

इसके बाद, अगला सवाल यह पूछा जाता है कि लोकल मॉडल के बारे में क्या?

लागत की इस बड़ी चुनौती को क्या स्थानीय मॉडल खत्म नहीं कर सकते?

हां, ऐसा होगा.

हालांकि, हमें कुछ बातों का ध्यान रखना होगा.

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

हालांकि, क्लाउड पर ऐसी कई चीज़ें की जा सकती हैं जो डिवाइस पर करना मुश्किल होता है.

उदाहरण के लिए, कंप्यूट.

अक्सर लोग कहते हैं, "देखो, मुझे बोली को लिखाई में बदलने वाला यह मॉडल बहुत अच्छा लगा. यह इस डिवाइस पर स्थानीय तौर पर चलता है, है न?"

बहुत बढ़िया, लेकिन हमें यह सोचना होगा कि यह एक मॉडल नहीं, बल्कि कई मॉडल चला रहा है, है न?

हमारे मामले में, चार, शायद एक ही समय पर, और इसलिए, किसी चीज़ को एक बार चलाना काफ़ी नहीं है, उसे एक ही समय पर कई बार चलाना होगा.

इसके बाद, अगर आपने यह काम कर लिया है, तो क्या आपने अपने गेम या ऐप्लिकेशन को चलाने के लिए कुछ और छोड़ा है?

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

मान लें कि आपने इन चुनौतियों का सामना कर लिया है.

अगला सवाल स्पीड के बारे में है, है न?

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

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

फ़िलहाल, ऐसे मॉडल बनाना एक चुनौती है जो इस काम को सही स्पीड से कर सकें.

अब मान लेते हैं कि आपने कंप्यूट और स्पीड की समस्या को हल कर लिया है. अब हमें क्वालिटी के बारे में सोचना होगा, है न?

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

जैसा कि मैंने पहले बताया था, एलएलएम के बारे में सोचते समय, यह न सिर्फ़ आपके उपयोगकर्ताओं के लिए अच्छा होना चाहिए, बल्कि आपके लिए भी अच्छा होना चाहिए.

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

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

अगर आपने इस पूरी प्रोसेस को पूरा कर लिया और इस गेम को RTX 5070 पर चलाया, तो हो सकता है कि यह सिर्फ़ इसी पर चले.

इसलिए, अगर आपको अपने गेम को किसी नए प्लैटफ़ॉर्म पर लॉन्च करने का मौका मिलता है, तो हो सकता है कि आप ऐसा न कर पाएं.

क्लाउड पर गेम खेलने के लिए, आपको सिर्फ़ इंटरनेट की ज़रूरत होती है.

इसलिए, यह एक बड़ी उपलब्धि है.

इससे आपको कई प्लैटफ़ॉर्म पर लाइव स्ट्रीम करने की सुविधा मिलती है.

चलिए, अब हाइब्रिड अप्रोच के बारे में बात करते हैं.

इसलिए, कुछ चीज़ों को क्लाउड में और कुछ चीज़ों को डिवाइस पर चलाएं.

एक तरह से, क्या यह काम कर सकता है?

यह उतनी बड़ी जीत नहीं है जितना आपको लगता है.

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

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

इसके बाद, अगला सवाल यह उठता है कि अगर मुमकिन हो, तो इसे लोकल तौर पर क्यों न चलाया जाए?

उनके पास सही हार्डवेयर है. अगर आपके पास नहीं है, तो क्लाउड में है, है न?

क्लाउड पर ज़्यादा बेहतर तरीके से काम किया जा सकता है.

इसमें नई चुनौतियां हैं, है न?

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

साथ ही, आपको कम से कम ज़रूरी शर्तों पर काम करने में काफ़ी समय बिताना पड़ता है.

साथ ही, आपके पास ऐसे मॉडल हो सकते हैं जो काफ़ी अलग तरह से काम करते हों.

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

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

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

इसलिए, लोकल मॉडल का इस्तेमाल करने से, निश्चित तौर पर काफ़ी फ़ायदा होता है. हालांकि, अभी इस पर काम चल रहा है.

गेम जैसे ऐप्लिकेशन के लिए, कीमत बहुत मायने रखती है. इसलिए, मुझे लगता है कि आने वाले समय में यह मॉडल काफ़ी लोकप्रिय होगा.

आज के समय में, कुछ खास मामलों को छोड़कर, अन्य मामलों में इसका इस्तेमाल करना थोड़ा मुश्किल है. खास तौर पर, कमांड पर आधारित चीज़ों के लिए.

इसलिए, आज हम आपको बेहतरीन अनुभव देना चाहते हैं.

इसलिए, हम क्लाउड का इस्तेमाल कर रहे हैं.

हालांकि, यह स्पेस तेज़ी से बदल रहा है और इसमें काफ़ी बदलाव हो रहे हैं.

अब हम उन मॉडल के बारे में बात करते हैं जिनका इस्तेमाल हम कर रहे हैं.

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

हमें यहां क्या करना चाहिए?

इस बारे में बात करते समय, मेरा फ़ोकस एलएलएम पर है. ऐसा इसलिए, क्योंकि हमें पता चला है कि ओपन सोर्स और क्लोज़्ड सोर्स के बीच का अंतर, एलएलएम पर सबसे ज़्यादा असर डालता है.

इसलिए, इसके कुछ फ़ायदे और नुकसान हैं.

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

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

वहीं, ओपन सोर्स वाले मॉडल अक्सर एक जनरेशन पीछे होते हैं.

इसलिए, यह एक सही समझौता हो सकता है.

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

हमें पता चला है कि क्लोज़्ड मॉडल की स्पीड, समय के साथ कम हो जाती है.

इसकी कई वजहें हो सकती हैं.

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

हालांकि, हमने इस बात पर ध्यान दिया है.

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

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

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

इसके बाद, मॉडल की लाइफ़टाइम वैल्यू आती है.

इसलिए, क्लोज़्ड मॉडल को आम तौर पर एक साल के बाद बंद कर दिया जाता है.

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

अगर कोई मॉडल बेहतर है, तो इसका मतलब यह नहीं है कि वह आपके लिए भी बेहतर तरीके से काम करेगा.

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

आखिर में, लागत की बात करते हैं.

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

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

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

इसलिए, हम Gemma 4 31B का इस्तेमाल कर रहे हैं. यह हमारे लिए एक बड़ी कामयाबी थी, क्योंकि यह स्पीड, इंटेलिजेंस, और लागत का सबसे अच्छा कॉम्बिनेशन था.

इसकी मदद से, हम तेज़ी से आगे बढ़ पाए.

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

इसका मतलब यह नहीं है कि हम सिर्फ़ इसका इस्तेमाल करते हैं.

हम अलग-अलग ओपन और क्लोज़्ड मॉडल के कई कॉम्बिनेशन इस्तेमाल करते हैं.

उदाहरण के लिए, मेमोरी जनरेट करने, सुरक्षा, और मनमुताबिक बनाने की सेटिंग.

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

हालाँकि, वॉइस एजेंट के तौर पर Gemma 4 31B हमारा सबसे बेहतरीन मॉडल है.

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

साथ ही, किसी मॉडल के बंद होने से आपके शेड्यूल पर कोई असर नहीं पड़ता.

डेविन राइमर

तो कुल मिलाकर, इन तीनों चीज़ों के बीच संतुलन बनाना ज़रूरी है, है न?

आपकी लेटेंसी, हम स्ट्रीमिंग के पहलू, पैरलल पहलू, स्पीड, और उसकी कंसिस्टेंसी को बैलेंस करने की कोशिश कर रहे हैं.

इंटेलिजेंस के लिहाज़ से, यह उपयोगकर्ताओं के लिए काफ़ी स्मार्ट है. साथ ही, इसके साथ काम करना भी काफ़ी आसान है.

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

ऐसा न करें कि पहले ऐप्लिकेशन बना लें और फिर उसके लिए कमाई करने का तरीका ढूंढें.

इस बारे में शुरुआत से ही सोचें.

हालांकि, अभी यह शुरुआती दौर में है, लेकिन इससे कमाई होने लगी है.

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

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

इसलिए, मैं वॉइस एजेंट की इस सुविधा को सभी के लिए उपलब्ध कराने को लेकर बेहद उत्साहित हूँ.

धन्यवाद.