मैगी: एक बेबी ट्रांसलेटर एआई स्टार्टअप की गाथा

टीएल;डीआर सारांश मैं एक पार्किंग स्थल में एक सहपाठी से मिला और खोए हुए 10 डॉलर के नोट को लेकर हमारे बीच दोस्ती हो गई। मुझे नहीं पता था कि मेरे सहपाठी ने एक ऐसा मॉडल बनाया था जो बच्चे के रोने की आवाज़ को समझ सकता था और वह एक सह-संस्थापक की तलाश में था। की की बदौलत, हम व्यावसायिक साझेदारों के रूप में मिल पाए, काम करने के लिए जगह मिली और अपनी कंपनी शुरू की। डॉ. पीटर स्चुरमैन वेंचर लैब कुछ ही हफ़्तों में, मैंने इस मॉडल के इर्द-गिर्द एक सर्वर और एक एंड्रॉयड बनाया जिसका इस्तेमाल माता-पिता अपने बच्चे की चीख़ों का अनुवाद करने के लिए कर सकते थे। लेकिन देरी बहुत भयानक थी - कोई भी रोते हुए बच्चे को गोद में लेकर सर्वर के चालू होने या ऑडियो फ़ाइल अपलोड करने का इंतज़ार नहीं करना चाहता। ऐप इसलिए, हमने मॉडल को ऐप में डालने का फैसला किया, लेकिन यह फिट होने के लिए बहुत बड़ा था। इसका मतलब था कि सटीकता को कम किए बिना क्वांटाइजेशन के माध्यम से इसके आकार को छोटा करना और यह पता लगाना कि ऐप को क्रैश किए बिना डिवाइस पर मॉडल के लिए आवश्यक इनपुट कैसे उत्पन्न करें। हम के बिना ऐसा नहीं कर सकते थे, जिन्होंने हमें TensorFlow, Android और स्टार्टअप के बारे में अमूल्य सलाह दी। पीट वार्डन लेकिन अब जब मॉडल डिवाइस पर था, तो यह हमारी पहुँच से बाहर था। हम इसके प्रदर्शन को कैसे मापते हैं? सफलता कैसी दिखती है? मैंने प्रदर्शन का न्याय करने के लिए आवश्यक सभी जानकारी को कैप्चर करने के लिए मॉडल के चारों ओर लॉगिंग, मॉनिटरिंग और उपयोगकर्ता फ़ीडबैक की एक परत बनाई। इस डेटा ने एक फ्लाईव्हील बनाया; प्रत्येक अनुवाद ने नया लेबल वाला प्रशिक्षण डेटा बनाया - अब हम न्यूनतम प्रयास के साथ अपना डेटासेट बढ़ा रहे थे। जब ऐप काम करने लगा और उसकी निगरानी होने लगी, तो हमारे सामने दुविधा थी: एक या कई अनुवाद दिखाएं? सहज ज्ञान कहता है कि सबसे सटीक अनुवाद दिखाएं - आखिरकार, वही अनुवाद सही होने की सबसे अधिक संभावना है। लेकिन क्या होगा अगर अनुवाद केवल 70% विश्वसनीय हो? 60% या 50% के बारे में क्या? यह एक सूक्ष्म समस्या थी जिसने हमें यह देखने में मदद की कि लोग वास्तव में ऐप का उपयोग कैसे करते हैं और एक बेहतरीन विशेषता की खोज की। ऐसा लगता है कि जब आपका बच्चा आपकी गोद में रो रहा हो, तो अपना फ़ोन ढूँढ़ना और ऐप खोलना बहुत मुश्किल है। इसलिए, हमने Google होम स्मार्ट स्पीकर का उपयोग करके एक बेबी मॉनिटर, बनाया - हाथ से मुक्त अनुवाद। होमर हालाँकि, स्मार्ट स्पीकर हमें बचाने के लिए पर्याप्त नहीं था। हमारे पास पैसे और ऊर्जा दोनों खत्म हो गए, जीवन की परिस्थितियों ने हमें घर वापस ला दिया, और हमारे बेबी ट्रांसलेटर को शेल्फ पर रख दिया गया। प्रस्तावना मैंने काम के लिए एक AI फीचर पर काम करना शुरू किया क्योंकि मुझे एक पुराने, पुराने विशेषज्ञ उपकरण को बायपास करने का अवसर दिखाई दिया, और निश्चित रूप से, हर स्टार्ट-अप को एक स्टार्ट-अप होना चाहिए। इस सुविधा का प्रोटोटाइप बनाते समय, मुझे कुछ अजीबोगरीब परिचित समस्याओं का सामना करना पड़ा। इसलिए मैंने अपनी पत्रिकाओं को देखा और मैगी को पाया, वह बेबी ट्रांसलेटर जिसे मैंने और मेरे एक दोस्त ने महामारी से पहले बनाया था। लगभग सात साल हो गए हैं, और वही समस्याएं जो AI परीक्षण और उत्पादन परिनियोजन को परेशान करती हैं, अभी भी एक अप्रतिबंधित महामारी हैं, हालाँकि अत्याधुनिक तकनीक ने महत्वपूर्ण प्रगति की है। यहाँ मैगी से मेरे नोट्स, विचार और कोड पर एक प्रतिबिंब है जो AI को उत्पादन में लाने के रास्ते में आम समस्याओं को प्रदर्शित करता है। मुझे उम्मीद है कि आपको यह मददगार लगेगा। AI मैगी क्या है? मैगी इसी नाम के शो से सिम्पसन्स की सबसे छोटी बच्ची का नाम है। मैगी एक बच्ची है जिसने अभी तक बोलना नहीं सीखा है। मैगी के चाचा, हर्ब, एक खराब व्यावसायिक निर्णय के बाद बहुत मुश्किल में पड़ जाते हैं और सिम्पसन्स के साथ रहने चले जाते हैं। वह अपनी भतीजी और उसके बोलने में असमर्थ होने के कारण परिवार की निराशा से प्रेरणा लेकर चमत्कारिक रूप से एक काम करने वाला बेबी ट्रांसलेटर बनाता है। इसी तरह, बेबी ट्रांसलेटर बनाने का विचार मेरे दोस्त क्रिस को अपनी छोटी बहन के साथ अपने रिश्ते से आया, जिसे बोलने में परेशानी होती थी। इसलिए, हमने अपने ऐप का नाम मैगी रखा। उस समय एक शिशु प्रयोगशाला में काम कर रहे थे, और उन्होंने पाया कि एक निश्चित आयु सीमा के भीतर बच्चों द्वारा की जाने वाली ध्वनियों के स्पेक्ट्रम में शारीरिक सीमाएँ होती हैं। इस अंतर्दृष्टि से, उन्होंने प्रशिक्षण डेटा एकत्र किया और शिशु के रोने के लिए एक वर्गीकरण मॉडल बनाया - एक प्रभावशाली उपलब्धि, क्योंकि वह भौतिकी में प्रमुख थे और उन्हें CS का कोई अनुभव नहीं था। क्रिस हमने एक क्लास साझा की - इंजीनियर सर्विस लर्निंग - जहाँ पूरी क्लास ने कैंपस की एक इमारत के लिए LEED प्रमाणन पर काम किया। मुझे वह एक खुशमिजाज़ लड़के के रूप में याद है जो लॉन्गबोर्ड पर सवार होकर क्लास में आता था। हमारी पहली बातचीत कक्षा के बाहर, एक किराने की दुकान की अंधेरी पार्किंग में हुई, जहाँ मैंने उसे अपनी डर्ट बाइक चलाने के लिए तैयार होते देखा। उसने मेरी कार के बगल में पार्क किया था, और हमने बात की। फिर मैंने उसके बगल में कुछ मुड़े हुए कागज़ देखे, उसे उठाया, देखा कि यह पैसे थे, और उसे बताया कि उसने अपने पैसे गिरा दिए हैं। उसने कहा कि यह उसके नहीं थे, लेकिन मैंने उसे रखने के लिए कहा। हमें नहीं पता था कि यह कितना था; पार्किंग बहुत अंधेरी थी। $1, $10, या $100। मैंने उससे कहा कि मुझे उम्मीद है कि यह $100 होगा। यह $10 था। लेकिन उस पहली बातचीत ने हमारे बीच इतना विश्वास पैदा कर दिया कि कुछ हफ़्तों में, जब हम दोनों वेंचर लैब - यूसी मर्सिड में स्टार्टअप इनक्यूबेटर - में काम कर रहे थे, उसने मुझसे अपने बेबी ट्रांसलेटर को तैनात करने के लिए एक ऐप बनाने के लिए कहा। वेंचर लैब के बिना, हम कभी भी सहयोग करने के बारे में नहीं सोच सकते थे। मैं निश्चित रूप से अपने सहपाठियों को यह नहीं बताता कि मैं एंड्रॉइड ऐप बनाता हूँ, न ही वह अपने बेबी ट्रांसलेशन मॉडल के बारे में शेखी बघारता फिरता है। व्यक्तिगत रूप से तीसरे स्थान पर एक चुंबकीय जादू है जिसे आपको कम नहीं आंकना चाहिए। मेरे पास एक मॉडल है और यह काम करता है। अब क्या? एक कार्यशील मॉडल बनाने के बावजूद, क्रिस यह नहीं समझ पाया कि इसे कैसे तैनात किया जाए। यह 2017 की शुरुआत थी, और इसे प्रदर्शित करने वाले बहुत सारे पाठ्यक्रम या गाइड नहीं थे। TensorFlow में उनके गुरु ने Android पर तैनात करने की सिफारिश की, लेकिन मोबाइल विकास सीखना बहुत दूर की बात थी। मैं Android जानता था और Play Store पर कई ऐप तैनात कर चुका था, लेकिन मेरे लिए भी यह एक मुश्किल काम था। इसलिए, मैंने आसान काम किया। मैंने मॉडल को सर्वर पर रखा और उसमें API कॉल किए। फ्लास्क सर्वर में मॉडल को निष्पादित करना आश्चर्यजनक रूप से आसान था: TensorFlow को आयात करें, स्थानीय डिस्क से मॉडल को लोड करें (मैंने बाद में मॉडल को इस तरह से तैनात करने के बारे में भी नहीं सोचा था कि इसे बाद में संस्करणित करना आसान होगा), और अनुरोधों को उस पर इंगित करें। लेकिन कुछ गड़बड़ियाँ थीं: अनुरोध को उस इनपुट में बदलना था जिसकी मॉडल को उम्मीद थी, और हमने इस काम को करने के लिए कोई साझा पैकेज नहीं बनाया। चूंकि क्रिस ने मॉडल को प्रशिक्षित किया और मैंने सर्वर बनाया, इसलिए यह त्रुटियों का स्रोत बन गया। पहला अनुरोध हमेशा धीमा था; हम AppEngine पर होस्टिंग कर रहे थे, और मैंने निष्क्रिय सर्वरों की संख्या शून्य (डिफ़ॉल्ट) पर छोड़ दी थी क्योंकि मैंने कभी ऐसे सर्वर के साथ काम नहीं किया था जिसके लिए इतने लंबे सेटअप की आवश्यकता होती है। निष्क्रिय सर्वरों पर पैसा क्यों खर्च करें जब नए सर्वर शुरू करने में केवल एक सेकंड लगता है? मॉडल को लोड होने और चालू होने में लंबा समय लगा, इसलिए हमें अपने सर्वर को 24/7 निष्क्रिय रखना पड़ा। आप नहीं जानते कि बच्चा कब रोना शुरू कर देगा, जिसका मतलब है कि होस्टिंग बिल अधिक होगा। इस धीमी शुरुआत ने एकीकरण परीक्षण को एक बड़ा सिरदर्द बना दिया, इस हद तक कि मुझे मैन्युअल परीक्षणों पर वापस जाना पड़ा। परीक्षणों के पास होने के लिए मिनटों तक इंतजार करना असहनीय था। हॉट-रीलोड के साथ सर्वर को स्पिन अप करना और प्रत्येक कमिट से पहले मैन्युअल रूप से परीक्षण करना तेज़ था। तैनाती और संस्करण नियंत्रण मुश्किल था। शुरू में, मैंने मॉडल को रेपो के साथ तैनात किया था क्योंकि मैं किसी प्रकार का संस्करण नियंत्रण चाहता था, लेकिन मुझे जल्दी ही एहसास हुआ कि यह तैनाती की आसानी का त्याग कर रहा था। प्रत्येक मॉडल अपडेट के लिए सर्वर को तैनात करना और पूरे क्लस्टर को फिर से शुरू करना आवश्यक था, जिसमें समय लगता था क्योंकि सर्वर को नया मॉडल लोड करना पड़ता था। इन समस्याओं के बावजूद, यह काम कर गया। मॉडल इनपुट पार्सर और ट्रांसफॉर्मर कोड को साझा करने से पहली समस्या हल हो गई। मॉडल को ब्लैक बॉक्स के रूप में मानना और उसका मॉकिंग करना उसके इर्द-गिर्द एकीकरण परीक्षण बनाना आसान बनाता है। ये परीक्षण सुनिश्चित करेंगे कि सर्वर और मॉडल के बीच कोई अप्रत्याशित मिसअलाइनमेंट न हो - जब तक मॉक सटीक हों। अब, ऐसे मॉडल इंटरफ़ेस हैं जो विकास के दौरान मॉक की शुद्धता सुनिश्चित कर सकते हैं। मॉडल के लिए परिनियोजन और संस्करण नियंत्रण आजकल अधिकांश उपयोग मामलों के लिए नए समाधान की आवश्यकता वाली समस्या नहीं है। दूसरी ओर, विलंबता और उपलब्धता संबंधी समस्याओं ने अंततः हमें ऐप पर मॉडल को किनारे पर तैनात करने के लिए मजबूर किया। इससे नेटवर्क विलंबता को दूर करने, फ़ोन के बहुत तेज़ CPU का उपयोग करने और ऐप को पृष्ठभूमि में चालू रखने का लाभ हुआ, जिससे हमारी स्टार्टअप विलंबता समस्या हल हो गई और हमारी होस्टिंग लागत कम हो गई। लेकिन निश्चित रूप से, नई समस्याएं थीं। मॉडल कहां रखें? हमने इस बात पर बहुत समय बिताया कि मॉडल को कहां रखा जाए। हम फोन की गति और निश्चितता चाहते थे, लेकिन सर्वर की सुरक्षा और तैनाती में आसानी चाहते थे। शुरू में, मॉडल को सर्वर पर रखना आकर्षक था: इसे अद्यतन करना और तैनात करना आसान था। इसने उपयोगकर्ताओं की संख्या को सीमित नहीं किया - उस समय, एंड्रॉइड के केवल कुछ संस्करण ही टेंसरफ्लो इंफरेंस लाइब्रेरी का समर्थन करते थे, इसलिए फोन पर मॉडल डालने का मतलब था कम उपयोगकर्ता। इसने अधिक विकल्प प्रदान किये - सर्वर के API का उपयोग स्मार्ट स्पीकर, वेबसाइट और बेबी मॉनिटर द्वारा किया जा सकता था। किसी को भी मॉडल चोरी करने की चिंता नहीं थी। लेकिन नकारात्मक पक्ष बढ़ता ही गया: यह प्रक्रिया धीमी थी; रिकॉर्डिंग अपलोड करने, उन्हें लिप्यंतरित करने तथा फिर मॉडल चलाने में काफी समय लग जाता था। किसी व्यवधान के जोखिम के कारण ऐप कम आकर्षक हो गया - हमारे उपयोगकर्ताओं को 100% उपलब्धता की आवश्यकता थी; ऐप के बारे में सबसे आकर्षक बात यह थी कि यह तब भी आपके लिए उपलब्ध था जब आपके पति/पत्नी, माता-पिता आदि मौजूद नहीं थे - यह तब भी आपके लिए उपलब्ध था जब आप एक रोते हुए बच्चे के साथ अकेले थे। यह महंगा था; यह सारा काम करने के लिए आवश्यक मशीनें एक स्टार्टअप के लिए महंगी थीं, क्योंकि उसे हर चीज के भुगतान के लिए गूगल क्लाउड क्रेडिट का उपयोग करना पड़ता था। अंत में, हमने पहले दो बिंदुओं के कारण मॉडल को ऐप में डालने का फैसला किया - यदि आपको अनुवाद के लिए प्रतीक्षा करनी पड़े या यदि यह कभी-कभी बंद हो जाए तो ऐप आकर्षक नहीं था। जब आपकी बाहों में रोता हुआ नवजात शिशु हो तो कुछ सेकंड की देरी अनंत काल की तरह लगती है। लेकिन मॉडल को फोन पर डालने में कुछ समस्याएँ थीं, जैसा कि मैं अगले भाग में बताऊंगा। इससे मुझे जो सबक मिला, वह यह है कि आपको सर्वश्रेष्ठ उपयोगकर्ता अनुभव के लिए अनुकूलन करना चाहिए - भले ही समाधान स्केलेबल न हो, आपको भविष्य में विकास न दे, या आपके आईपी को जोखिम में डाले। कंपनियाँ अपने उपयोगकर्ता अनुभव के आधार पर जीती और मरती हैं, खासकर अगर वे नई कंपनियाँ हों जिन्हें विश्वास अर्जित करने और ब्रांड बनाने की आवश्यकता हो। किनारे से कहानियाँ मॉडल को फ़ोन पर लगाना तकनीकी कठिनाइयों का पहाड़ लेकर आया। उनमें से कुछ अब मौजूद नहीं हैं, लेकिन ज़्यादातर मौजूद हैं। हम अत्याधुनिक तकनीक पर थे। Android के लिए TensorFlow अभी मुश्किल से ही आया था - सार्वजनिक रिलीज़ फ़रवरी 2017 में हुई थी, और मैं मार्च में ऐप बना रहा था। लेकिन TensorFlow में दृढ़ता और भरपूर मदद से, हम ऐप में मॉडल को काम करने लायक बनाने में कामयाब रहे। पीट वार्डन की पहली समस्या एपीके पैकेज में मॉडल प्राप्त करना था। उस समय, एंड्रॉइड में 50 एमबी एपीके सीमा और एक एक्सटेंशन सुविधा थी जो इंस्टॉलेशन के बाद घटकों को डाउनलोड करके ऐप्स को बड़ा करने की अनुमति देती थी। हालाँकि, मुझे एक्सटेंशन सुविधा असुरक्षित लगी क्योंकि इसका मतलब था कि मॉडल को सर्वर पर दिखाना। इसलिए, हमने ऐप को क्वांटाइज़ करने का फैसला किया - एक ऐसी तकनीक जिसमें हर परत के सभी इनपुट और आउटपुट की सटीकता को कम करना शामिल है। हमारे मामले में, हमने सभी फ़्लोटिंग पॉइंट संख्याओं को पूर्णांकों में बदल दिया, जिससे मॉडल का आकार काफ़ी कम हो गया और यह तेज़ हो गया, लेकिन इसने सटीकता को भी कम कर दिया। क्रिस ने अलग-अलग क्वांटिज़ेशन योजनाओं के साथ मॉडल के कई पुनरावृत्तियों से गुज़रा और अंततः सटीकता में कमी के बावजूद पूर्णांक क्वांटिज़ेशन पर बस गया। यह तब तक उपयोगी था जब तक मॉडल ने नए पैरेंट से बेहतर प्रदर्शन किया। बोनस: इसने अपडेट की समस्या को हल कर दिया - हर मॉडल अपडेट में सैकड़ों एमबी डेटा डाउनलोड करना मीटर्ड इंटरनेट कनेक्शन पर बहुत ज़्यादा था, लेकिन कुछ एमबी का प्रबंधन किया जा सकता था (यह अब मुझे मूर्खतापूर्ण लगता है क्योंकि लोग आज अपने फ़ोन पर नियमित रूप से जीबी के वीडियो कंटेंट डाउनलोड करते हैं)। फिर छोटी-छोटी समस्याओं की एक लंबी श्रृंखला आई। सबसे बड़ी समस्या यह थी कि Android के साथ भेजे गए Java के विभिन्न संस्करणों द्वारा समर्थित FFT लाइब्रेरीज़ वही स्पेक्ट्रोग्राम नहीं बनाती थीं जिस पर मॉडल को प्रशिक्षित किया गया था। हमने C++ FFT लाइब्रेरी का उपयोग करके मॉडल को प्रशिक्षित किया, और इसने विभिन्न रंगों और आयामों के साथ स्पेक्ट्रोग्राम बनाए। गुप्त उपकरण होने के कारण, C++ और Java दोनों संस्करण अपारदर्शी रूप से लिखे गए थे और उन्हें संशोधित करना कठिन था। एक और त्वरित निर्णय: हमने Java FFT स्पेक्ट्रोग्राम का उपयोग करके मॉडल को फिर से प्रशिक्षित करने का निर्णय लिया। इसका मतलब था सभी ऑडियो फ़ाइलों को स्पेक्ट्रोग्राम में बदलना और फिर प्रशिक्षण प्रक्रिया को चलाना, जिसमें मेरे दोस्त के पुराने मैकबुक पर कई दिन लग गए। लेकिन समस्या हल हो गई, और मैं उस समय किसी और चीज़ पर ध्यान केंद्रित कर सकता था। लेकिन ऐप रुक-रुक कर क्रैश हो रहा था। पता चला कि रिकॉर्डिंग को मेमोरी में लोड करना और फिर मेमोरी में स्पेक्ट्रोग्राम बनाना एक बुरा विचार था। ऐप फ़ोन के बहुत सारे संसाधनों का इस्तेमाल कर रहा था। इसका समाधान डिस्क में सेव करके स्ट्रीम करना था। डिस्क में सेव करना आसान था; स्ट्रीमिंग वाला हिस्सा मुश्किल था क्योंकि एक बार ऑडियो मेमोरी से निकल जाने के बाद, डिस्क पर कुछ भी हो सकता था। कोई दूसरा प्रोग्राम इसे पढ़ और संशोधित कर सकता है; इसे हटाया जा सकता है, यह सेव करने में विफल हो सकता है, आदि... ये एज केस आम तौर पर वेब पर मौजूद नहीं होते हैं - आपके पास अपने उपयोगकर्ता के साथ एक अलग चैनल होता है लेकिन डिवाइस पर नहीं। यह सुनिश्चित करना कि पहले स्थान पर ऐसा करने के लिए पर्याप्त जगह हो और ऐप के बाद सफाई करना एक अप्रत्याशित चुनौती थी। यह एक गलत धारणा है, मुझे बाद में पता चला, यह मानना कि अगर फोन में आपके ऐप को इंस्टॉल करने के लिए पर्याप्त मेमोरी है, तो इसे चलाने के लिए भी पर्याप्त मेमोरी होगी। अंत में, डिवाइस खुद ही एक विरोधी थी - एंड्रॉइड फोन कई तरह के CPU, मेमोरी की मात्रा और सबसे महत्वपूर्ण रूप से, माइक्रोफ़ोन के साथ आते हैं। CPU और मेमोरी की समस्या को आवश्यक Android संस्करण को नवीनतम पर सेट करके और सर्वश्रेष्ठ की उम्मीद करके हल किया जा सकता है; सबसे खराब स्थिति एक धीमा ऐप थी - Android में संसाधन आवश्यकताओं को सीधे सेट करने का कोई तरीका नहीं है। असली समस्या माइक्रोफ़ोन में विभिन्न गुणों का हिसाब रखना था - Android आपको उन डिवाइस पर माइक्रोफ़ोन की आवश्यकता देता है जिन पर आपका ऐप इंस्टॉल है, लेकिन माइक्रोफ़ोन के प्रकार की नहीं। मैंने इस समस्या को हल करने की कोशिश नहीं की। उस समय मेरे पास कई टेस्टर फोन थे और मैंने देखा कि सस्ते फोन पर भविष्यवाणियां कितनी खराब थीं। मैंने फैसला किया कि अब समाधान खोजने का समय नहीं है - हम जल्द से जल्द लॉन्च करने की कोशिश कर रहे थे। कभी-कभी, किसी समस्या का सबसे अच्छा समाधान यह होता है कि उसे नोट कर लिया जाए और आगे बढ़ जाएँ। अब मुझे एहसास हुआ कि इस मुद्दे ने हमें अंतिम उत्पाद की ओर इशारा किया - होमर, एक स्मार्ट स्पीकर। एक बार तकनीकी कठिनाइयों पर काबू पा लिया गया (या टाला गया), तो हम भविष्यवाणी की गुणवत्ता की कठिन समस्या पर आगे बढ़ गए। चूंकि मॉडल ऐप पर रहता था, इसलिए हम इसके प्रदर्शन के बारे में नहीं जानते थे। अगर यह खराब प्रदर्शन करता है, तो हम केवल ऐप पेज पर टिप्पणियों या अनइंस्टॉल के माध्यम से ही बता सकते हैं; तब तक बहुत देर हो चुकी होती है। इसलिए, मॉडल के इर्द-गिर्द लॉग, निगरानी, डेटा संग्रह और फीडबैक का आवरण बनाना महत्वपूर्ण था। एक या अनेक? मॉडल ने स्पेक्ट्रोग्राम और कुछ अन्य जानकारी ली ताकि शिशु द्वारा की जा रही आवाज़ों को वर्गीकृत किया जा सके - भूख, असहजता, दर्द, नींद और गैस, ये अनुवाद थे। इसने सभी संभावित श्रेणियों की एक सूची लौटाई, जिसमें प्रत्येक श्रेणी में एक प्रतिशत था जो दर्शाता है कि मॉडल उस विशेष अनुवाद में कितना आश्वस्त था। सभी प्रतिशत 100 तक जुड़ते हैं - यदि सबसे सटीक अनुवाद 90% पर भूख था, तो अन्य पाँच श्रेणियों में सटीकता 10% तक होगी। शुरुआत में हमारे सामने यह सवाल आया कि क्या सभी अनुवादों को प्रदर्शित किया जाए (सबसे सटीक से लेकर सबसे कम सटीक तक) या सिर्फ़ एक को। मैंने सिर्फ़ एक को दिखाने का विकल्प चुना क्योंकि मैं लोगों को ज़्यादा अनुवादों से भ्रमित नहीं करना चाहता था, और इसे बनाना आसान था (आलस्य एजाइल की आधारशिला है)। हालाँकि, हमें अपने पहले सेट के उपयोगकर्ताओं के साथ समस्याओं का सामना करना पड़ा। जब मॉडल निश्चित था (80% से ऊपर), तो सुझाव काम कर गया - हमें अभिभावकों से कोई शिकायत नहीं मिली। लेकिन यह हमेशा इतना भरोसेमंद नहीं था। जब अनुवाद की सटीकता 80% से कम थी, तो यह अभिभावक या अनुमान के बराबर ही था। यह ऐप के उद्देश्य को विफल करता है; इसे नए अभिभावकों द्वारा अपने बच्चे को शांत करने के लिए किए गए घबराए हुए प्रयासों की तुलना में अधिक सटीक अनुवाद प्रदान करना चाहिए। और ऐसा हुआ भी, आश्चर्य की बात नहीं कि दूसरा या तीसरा अनुवाद बिल्कुल सटीक था। हमने इसे व्यक्तिगत साक्षात्कारों के माध्यम से पाया - व्यक्तिगत साक्षात्कार मापनीय और समय लेने वाले होते हैं लेकिन अत्यधिक जानकारी-सघन होते हैं; यदि आप प्रतिदिन एक साक्षात्कार कर सकते हैं, तो करें। बच्चा रोता था, और ऐप कम आत्मविश्वास के साथ गलत अनुवाद दिखाता था, लेकिन हम अन्य अनुवादों को आजमाते थे (हमने उन्हें लॉग में देखा था), और वे काम करते थे। यह मेरे लिए विरोधाभासी था क्योंकि मैंने ऐप को एक अनुवादक के रूप में सोचा था; किसी चीज़ का अनुवाद करने का केवल एक ही तरीका होना चाहिए, है न? गलत। ऐप नए माता-पिता और देखभाल करने वालों के लिए एक खोज उपकरण था ताकि वे यह निर्धारित कर सकें कि उन्हें पहले क्या आज़माना चाहिए। क्या मुझे अपने बच्चे को डकार दिलाने की कोशिश करनी चाहिए? क्या वह भूखा है? आखिरी बार उसने कब झपकी ली थी? जब भी उनका बच्चा रोना शुरू करता है, तो हर माता-पिता इस चेकलिस्ट से गुज़रते हैं। हमारे ऐप ने इस खोज को तेज़ कर दिया; माता-पिता ने इसका इस्तेमाल इसी तरह किया, और यही प्रतिक्रिया हमें तब मिली जब हमने कई अनुवाद शुरू किए। यह कोई खास विशेषता नहीं थी, लेकिन इसने निश्चित रूप से ऐप को एक नौटंकी से एक दैनिक उपयोग के उपकरण में बदल दिया, जब पति या पत्नी चले गए हों या दादा-दादी सो गए हों तो यह एक भरोसेमंद साथी बन गया। इस डेटा के आधार पर, हमने जल्दी से और अनुवाद दिखाने का फैसला किया। चाल यह पता लगाना था कि कितने अनुवाद हैं। सभी अनुवादों को प्रदर्शित करना - सभी पाँच श्रेणियाँ - ऐप को ऐसा लगता था कि यह हर बार एक ही अनुवाद दोहराता है। अगर आप हर बार भोजन के लिए खोज करते हैं तो Google आपको वही चार रेस्तराँ दिखाए तो आप क्या सोचेंगे? हमने शीर्ष तीन अनुवादों पर फैसला किया - यह आंशिक रूप से कला और आंशिक रूप से डेटा है। लोग किसी कारण से नंबर तीन की ओर झुके हुए हैं। डेटा से पता चला कि तीसरे अनुवाद के बाद मॉडल का अन्य अनुवादों में विश्वास काफी कम हो गया। यदि पहले अनुवाद में 70% का विश्वास था, तो दूसरे में 20%, तीसरे में 9% और बाकी में 1% से कम होगा। इसलिए, हमने इन अनुवादों को छोड़ दिया। इन छोड़े गए अनुवादों के सटीक होने की थोड़ी संभावना थी, लेकिन उन्हें शामिल करने से ऐप के दोहराव का जोखिम था। विकल्प यह था कि 100 में से 1 उपयोगकर्ता को ऐसे अनुवाद प्राप्त होंगे जो सभी गलत होंगे, या सभी उपयोगकर्ता बेकार अनुवाद देखेंगे और सोचेंगे कि ऐप अनुमान लगा रहा है। यह एक आसान विकल्प था। बेशक, पीछे मुड़कर देखने पर, मुझे मल्टी-आर्म बैंडिट का उपयोग करके इसका परीक्षण करना चाहिए था - ऐप के पांच अलग-अलग संस्करण जारी करें, प्रत्येक विकल्प के लिए एक, उदाहरण के लिए, एक अनुवाद दिखाएं, दो दिखाएं, तीन दिखाएं, आदि, और धीरे-धीरे लोगों को ऐप के उस संस्करण पर माइग्रेट करें जिसके सबसे अच्छे परिणाम थे। प्राथमिक सफलता मीट्रिक यह होगी कि कितने लोगों ने हरे रंग के चेकमार्क (अनुवाद से खुश) पर क्लिक किया। लेकिन इतनी शुरुआती अवस्था में, मेरा मानना है कि हमने सही निर्णय लिया, और, इससे भी महत्वपूर्ण बात यह है कि हमने सही तरीके से निर्णय लिया। हम खुले विचारों वाले थे, हमने किसी भी निर्णय को ठोस नहीं माना (यहाँ कोई अहंकार नहीं है), हम लगातार अपने उपयोगकर्ताओं के साथ जाँच करते थे, और हमने उनकी बात सुनी, भले ही यह सही न लगे। नौकरी पर सीखना हर बातचीत सुधार और प्रभावित करने का एक अवसर है। इस उद्यम की शुरुआत से ही मेरी चिंता यह थी कि मॉडल सिर्फ़ भाग्यशाली था, कि एक भी पिता या माँ को यह बताया जाएगा कि उनका बच्चा रो रहा है क्योंकि उन्हें गैस है और वे अपने बच्चे को डकार दिलाकर मर जाते हैं। असंभव, लेकिन हमें प्रत्येक उपयोगकर्ता के बच्चे की भलाई के लिए ज़िम्मेदारी महसूस हुई। इसलिए, हमने ऐप में फीडबैक सुविधा जोड़कर लॉन्च को विलंबित कर दिया। हर अनुवाद के बाद, आपसे पूछा जाता था कि यह कितना मददगार था - एक अनस्किप करने योग्य पेज। फिर, ऐप ने उपयोगकर्ता फ़ीडबैक, मॉडल का आउटपुट, डिवाइस का प्रकार और स्पेक्ट्रोग्राम अपलोड किया। शुरू में, मैंने ऑडियो फ़ाइल अपलोड की, लेकिन जल्दी ही महसूस किया कि माइक्रोफ़ोन ने बहुत सारा बैकग्राउंड शोर कैप्चर कर लिया है। हमारे उपयोगकर्ताओं की गोपनीयता के लिए, हमने केवल स्पेक्ट्रोग्राम अपलोड करना चुना। तब मुझे यह नहीं पता था कि आप स्पेक्ट्रोग्राम को उलट सकते हैं और ऑडियो को फिर से बना सकते हैं, हालाँकि खराब गुणवत्ता और कुछ कठिनाई के साथ। यह हमारा फ्लाईव्हील था। हालाँकि, मैं उन बहसों और कई ड्राफ्ट को छोड़ रहा हूँ जिनके कारण यह अंतिम संस्करण बना है। यह तय करना कि कौन सा डेटा इकट्ठा करना है, सफलता को कैसे मापना है और सफलता को कैसे परिभाषित करना है, कठिन है, लेकिन यह एक पुनरावृत्त प्रक्रिया है जिसे आप छोटे-छोटे चरणों में कर सकते हैं और सुधार कर सकते हैं। मुझे जो सबसे अच्छी सलाह मिली वह यह थी कि सफलता कैसी दिखती है या, अगर यह बहुत कठिन है, तो विफलता कैसी दिखती है (मेरे लिए, सफलता की तुलना में विफलता को परिभाषित करना बहुत आसान है - मुझे कभी नहीं पता कि मैं क्या चाहता हूँ, लेकिन मैं इस बात को लेकर निश्चित हूँ कि मैं क्या टालना चाहता हूँ) और विशिष्ट रहें। उस उत्तर से, अपने प्रयासों का मूल्यांकन करने के लिए आप जिन मीट्रिक का उपयोग कर सकते हैं, उन्हें प्राप्त करें - यदि विफलता का मतलब है कि उपयोगकर्ता ऐप का उपयोग करने के लिए बहुत बड़े होने से पहले ही खो रहे हैं, तो उपयोगकर्ता के फ़ोन पर ऐप के औसत जीवनकाल को मापें। लेकिन ध्यान रखें कि ये परिभाषाएँ और मीट्रिक स्थिर नहीं हैं - वे बदलेंगे। आपको बस तय करने और उन पर तब तक टिके रहने की ज़रूरत है जब तक कि वे काम करना बंद न कर दें। जब आप उनसे सीखना बंद कर देंगे या कम से कम जब उनसे सीखना मुश्किल हो जाएगा, तो वे काम करना बंद कर देंगे। यही लक्ष्य है, सीखना और सुधार करना, बाकी सब विवरण हैं। AI/ML युग में, किसी कंपनी की सबसे मूल्यवान डिजिटल संपत्ति वह डेटा है जो उसे सौंपा गया है, न कि मॉडल। इस डेटा को बढ़ाना - अधिमानतः पारदर्शी और नैतिक तरीके से - निरंतर सफलता के लिए महत्वपूर्ण है। इसलिए, रूपांतरण दरों की परवाह किए बिना प्रत्येक उपयोगकर्ता इंटरैक्शन को मूल्य-निर्माण क्षण के रूप में माना जाना चाहिए। इसलिए यह इस प्रकार है कि प्रत्येक इंटरैक्शन को उपयोगकर्ता को प्रभावित करना चाहिए और वापस लौटने की इच्छा होनी चाहिए। हमने कुछ ऐसा बनाया जो आश्चर्यजनक और प्रेरित करने वाला था; हमारे पास एक बेहतरीन डिज़ाइनर, थीं, जिन्होंने मेरे कच्चे मसौदे को लिया और इसे एक ऐसे ऐप में बदल दिया जो उपयोग करने में सुखद और आनंददायक था। और हर अनुवाद ने अगले अनुवाद को बेहतर बनाया। टेरेसा इबारा समाप्त हमने जो आखिरी चीज़ बनाई वह होमर थी। ऐप उपयोगकर्ताओं के साथ दर्जनों व्यक्तिगत साक्षात्कार आयोजित करने और और भी अधिक लोगों को कॉल करने के बाद, हमें एहसास हुआ कि अपने रोते हुए बच्चे को गोद में लिए हुए अपने फ़ोन को ढूँढ़ना, स्क्रीन को अनलॉक करना, अपना ऐप ढूँढ़ना, उसे खोलना और ट्रांसलेट पर क्लिक करना कठिन और असुविधाजनक है। हमें यह एहसास होने में इतना समय क्यों लगा? हम बीस की उम्र के दो अविवाहित, निःसंतान पुरुष थे - मुझे याद नहीं है कि आखिरी बार मैंने कब किसी बच्चे को गोद में लिया था, उसके रोने की आवाज़ को शांत करना तो दूर की बात है। इसलिए, हमने स्मार्ट स्पीकर का उपयोग करके एक बेबी मॉनिटर बनाने का फैसला किया। मैंने रास्पबेरी पाई से एक किट मंगवाई और ऊपर एक बड़े नीले बटन के साथ एक कस्टम Google होम स्पीकर बनाया। क्रिस के पास बेबी मॉनिटर कंपनियों को मॉडल बेचने का एक शानदार विज़न था, लेकिन हम इन कंपनियों के साथ तालमेल नहीं बना पा रहे थे, इसलिए क्यों न स्मार्ट स्पीकर का उपयोग करके अपना खुद का बेबी मॉनिटर बनाया जाए? Google होम बनाने के बाद, मैंने स्टार्टअप पर ट्रांसलेटर चलाने के लिए एक बैश स्क्रिप्ट बनाई। ट्रांसलेटर ने ट्रिगर वाक्यांश 'ओके, गूगल, ट्रांसलेट' पर अनुवाद करने के लिए Google होम के SDK का उपयोग किया। ट्रांसलेटर एक पायथन स्क्रिप्ट थी जो माइक्रोफोन से ऑडियो पढ़ती थी, इसे स्पेक्ट्रोग्राम में बदल देती थी, और फिर इसे अनुवाद करने के लिए सर्वर पर भेजती थी। मैंने चीजों को चुस्त रखा, और यह ! आखिरकार हमारे पास हमारा किलर ऐप था, लेकिन इसने कंपनी को नहीं बचाया। काम कर गया हमारे पास फंड खत्म हो गया था - एक प्रतियोगिता में जीती गई पुरस्कार राशि। हम दोनों पर जीवन की मार बहुत तेजी से पड़ रही थी। हमने कॉलेज से स्नातक किया, और हम दोनों घर के लिए निकल पड़े - मैंने बे एरिया में नौकरी स्वीकार कर ली, और क्रिस टेक्सास में अपनी बीमार माँ की देखभाल करने के लिए चला गया। स्टार्टअप विफल हो गया। स्टार्टअप कठिन और दिल तोड़ने वाले होते हैं। आप उन्हें पार्ट-टाइम नहीं कर सकते। हिस्सेदारी रखने वाले हर व्यक्ति को पूर्णकालिक होना चाहिए या किसी और के लिए जगह बनाने के लिए छोड़ना चाहिए। या आपको अपनी महत्वाकांक्षाओं को छोटा करना होगा, शायद उन्हें पूरी तरह से त्याग देना होगा। अब, ऐसी समस्याएँ हैं जिन्हें पार्ट-टाइम आधार पर लाभप्रद रूप से हल किया जा सकता है - लेकिन क्या वे सार्थक हैं? क्या वे आपको उत्साहित करते हैं? अगर मैंने कुछ सीखा है - एंड्रॉइड पर एमएल मॉडल को तैनात करने के दर्द के अलावा - तो वह यह है कि आपको वास्तव में उस समस्या की परवाह करने की ज़रूरत है जिसे आप हल कर रहे हैं। आपको वित्तीय जोखिमों और जबरदस्त अवसर लागत के बावजूद इसे पूर्णकालिक रूप से करने का साहस खोजने की ज़रूरत है। इस पर काम करने के लिए मैं अपनी तकनीकी नौकरी छोड़ने वाला नहीं था। मुझे नए माता-पिता और हताश पिताओं की मदद करना अच्छा लगा; तकनीक सीखना और बनाना रोमांचक था, लेकिन मैं अपने पिता को कैसे समझा सकता था कि मैं स्नातक होने के बाद हमारे तंग सेक्शन 8 अपार्टमेंट में वापस क्यों जा रहा हूँ? इतने लंबे समय तक वेलफेयर पर रहने के बाद मैं छह-आंकड़ा वेतन कैसे ठुकरा सकता था? वेंचर कैपिटल के बारे में क्या? आपने पैसे जुटाने की कोशिश क्यों नहीं की? वास्तविकता यह है कि VC केवल तभी फ़ोन उठाते हैं जब वे आपको, आपके द्वारा पढ़े गए स्कूल या जिस कंपनी में आपने काम किया है, उसे जानते हों। उन्हें इस बात की परवाह नहीं है कि आपने क्या बनाया है - लाभदायक होने के अलावा, आपका नवाचार एक छोटी सी बात है - VC पहले संस्थापकों और टीमों में निवेश करते हैं और अंत में उत्पादों में। लेकिन उनमें से अधिकांश को यह नहीं पता कि अच्छे संस्थापकों या टीमों का चयन कैसे किया जाता है, इसलिए वे एलीट स्कूलों या FAANG के प्रवेश अधिकारियों को यह काम करने देते हैं।