वह डिक्टेशन ऐप जो internet न होने पर भी चलता है

कुछ शिकायतें तभी सामने आती हैं जब चीज़ें टूटती हैं, इसीलिए जब तक वे आपके साथ न हों तब तक उन्हें कम आँकना आसान है: cloud डिक्टेशन network पर निर्भर है। कोई provider outage, और आपकी डिक्टेशन key कुछ नहीं कर सकती। होटल का Wi-Fi टूटे, और एक वाक्य किसी spinner में ग़ायब हो सकता है। एक हवाई जहाज़। एक सुरंग में जाती ट्रेन। ठीक ग़लत पल पर दोबारा जुड़ता कोई VPN। यह किसी एक प्रोडक्ट की ख़राबी नहीं है; किसी round trip पर निर्भर होने का मतलब ही यही है।

इसकी क्रूरता यह है कि नाकाम क्या होता है। अगर आपका नोट लेने वाला ऐप बैठ जाए, तो आप एक text file खोल लेते हैं। अगर आपका डिक्टेशन बैठ जाए, तो आप इनपुट का एक तरीक़ा खो देते हैं — वही चीज़ जिसके लिए आपने माँसपेशियों की आदत बना ली थी, वाक्य के बीचोंबीच, और आम तौर पर तब जब आपके हाथ किसी और काम में लगे थे। आप डिक्टेट कर ही इसीलिए रहे थे।

उपलब्धता की शिकायत के नीचे प्राइवेसी का सवाल बैठा है: क्या आपकी आवाज़ का ऑडियो मशीन से बाहर जाता है? cloud ट्रांसक्रिप्शन वाले रास्ते में आपके ज़ोर से सोचने की रिकॉर्डिंग — क्लाइंट के नाम, बिना रिलीज़ हुए फ़ीचर, वह सुरक्षा मसला जो आप किसी साथी को बता रहे हैं — text बनने के लिए किसी और के infrastructure तक सफ़र करती है। वह रास्ता sessions, अकाउंट्स और ऐसी service उपलब्धता पर भी निर्भर हो सकता है जो आपके नियंत्रण में नहीं है।

Keebye का इसका जवाब मैंने उसे किसी फ़ीचर की तरह शब्दों में ढालने से पहले ही बना लिया था, क्योंकि मेरी अपनी ज़रूरत दो-टूक थी: इसे Wi-Fi बंद होने पर चलना ही था। यह असल में दिखता कैसा है, और इसकी क़ीमत क्या है, वह यहाँ है।

Cloud डिक्टेशन सीधे शून्य पर क्यों गिरता है

Category-स्तर की कार्यविधि साफ़-साफ़ लिख देना ठीक रहेगा, क्योंकि वही समझाती है कि प्रोडक्ट चाहे कितने भी अच्छे हो जाएँ, यह शिकायत पूरी तरह जाती क्यों नहीं।

Cloud डिक्टेशन के चक्र में कम से कम चार कड़ियाँ होती हैं: आपकी मशीन पर ऑडियो पकड़ना, उसे किसी server तक भेजना, वहाँ inference चलाना, और text वापस भेजना। हर कड़ी एक निर्भरता है — आपका network, उनका network, उनकी auth परत, उनकी क्षमता, उनका uptime। यह ज़ंजीर आम तौर पर ठीक चलती है। पर जब कोई भी कड़ी टूटती है, तो पूरा चक्र टूट जाता है, और वह शून्य तक टूटता है। “धीमा” नहीं, “कम सटीक” नहीं — आपके cursor पर कुछ नहीं पहुँचता। गुणवत्ता का गिरना सहा जा सकता था; डिक्टेशन तो सन्नाटे तक गिरता है।

Providers इसके ख़िलाफ़ कड़ी engineering कर सकते हैं, पर वे उन कड़ियों को ठीक नहीं कर सकते जो उनकी अपनी नहीं हैं: होटल का router, हवाई सफ़र, आपका corporate VPN, आपके और उनके बीच backbone की कोई गड़बड़। जिस टूल की उपलब्धता कई सिस्टमों पर निर्भर है, वह उनमें से किसी एक के भी न होने पर नाकाम हो सकता है।

जब वापस लौटने को कोई cloud है ही नहीं, तब क्या होता है?

Keebye की architecture इस सवाल का जवाब उसे हटाकर देती है। Speech-to-text पूरी तरह on-device चलता है — ONNX मॉडल, लोकल inference, आपके Mac के अपने silicon पर। डिक्टेशन के रास्ते में network calls शून्य हैं। “हम उन्हें कम रखते हैं” नहीं, “हम उन्हें इकट्ठा करके भेजते हैं” नहीं — शून्य। telemetry भी नहीं है। बिलकुल नहीं। जब आप key दबाकर बोलते हैं, तो आपकी ओर से कोई packet मशीन से बाहर नहीं जाता।

मैं इस architectural बात को रेखांकित करना चाहता हूँ, क्योंकि यही इसे किसी “offline mode” से अलग करती है। Offline mode एक fallback है: सामान्य रास्ता cloud तक जाता है, और जब cloud तक पहुँच न हो तो एक कमज़ोर लोकल रास्ता सँभाल लेता है — अगर ऐप वक़्त रहते भाँप ले, अगर लोकल रास्ता सँभाला गया हो, अगर वाक्य के बीचोंबीच वह हस्तांतरण चल जाए। Keebye में ऐसा कोई हस्तांतरण है ही नहीं, क्योंकि उसके पास हस्तांतरण करने के लिए कोई cloud रास्ता ही नहीं है। लोकल inference कोई बैकअप योजना नहीं है; वही अकेली योजना है। ऊपर की तरफ़ कोई outage उसे उसी वजह से नहीं तोड़ सकता जिस वजह से किसी दूसरे देश की बिजली कटौती आपकी मेज़ का लैंप नहीं बुझा सकती। बनावट से मिली प्रतिरक्षा, fallback से मिली नहीं।

यहीं वह शांत शिकायत भी बिना किसी settings पेज के हल हो जाती है। आपका ऑडियो कभी मशीन से बाहर नहीं जाता — न encrypted-in-transit, न anonymized, बस कभी भेजा ही नहीं जाता, क्योंकि उसे भेजने के लिए कोई जगह ही नहीं है। अगर आप डिक्टेशन हिस्ट्री चालू करते हैं, तो जो सहेजा जाता है वह सिर्फ़ text है, आपकी अपनी डिस्क पर एक लोकल SQLite database में। (वह हिस्ट्री अपने आप में एक अलग सहूलियत की कहानी है — बार-बार आने वाली “मेरा डिक्टेशन गया कहाँ?” वाली शिकायत — जिसे हमने आपका डिक्टेशन यूँ ही ग़ायब नहीं होना चाहिए में समेटा है।) और अकाउंट-तथा-session वाली नाज़ुकी अकाउंट्स के साथ ही ग़ायब हो जाती है: डिक्टेशन के रास्ते में expire होने के लिए कोई cloud session है ही नहीं, इसलिए आपके और एक चलती हुई hotkey के बीच दोबारा लॉगिन करने जैसा कुछ खड़ा नहीं होता।

एक बार आपको internet चाहिए ही

ज़रूरी ईमानदारी, सीधे-सीधे: मॉडलों को किसी न किसी तरह आपकी मशीन पर आना ही पड़ता है। पहली बार चलने पर Keebye अपना speech मॉडल डाउनलोड करता है — English इंजन के लिए मोटे तौर पर 700 MB, और multilingual इंजन चालू करने पर क़रीब 1.3 GB। यह एक असली डाउनलोड है, हर इंजन के लिए एक बार, और उसके लिए आपको internet चाहिए।

उसके बाद मॉडल डिस्क पर रहते हैं और ट्रांसक्रिप्शन उन्हीं के सहारे लोकली चलता है, network हो या न हो, जब तक आप उन्हें हटा या बदल न दें। पर अगर वह पहली बार हवाई जहाज़ में हुआ, तो उतरने तक आपका काम नहीं बनेगा — setup सफ़र से पहले कर लें, सफ़र के दौरान नहीं। मुझे अच्छा लगेगा कि यह बात आप मुझसे सुनें, न कि Atlantic के ऊपर ख़ुद खोजें।

सटीकता का सवाल, ईमानदारी से

डाउनलोड छोटी चेतावनी है। बड़ी वाली यहाँ है, क्योंकि on-device टूल्स इसे छोड़ जाना पसंद करते हैं।

सबसे बड़े cloud मॉडल किसी on-device मॉडल से ज़्यादा सटीक हो सकते हैं। जो मॉडल एक पूरा server rack भरता है, उसकी क्षमता 700 MB की फ़ाइल के पास नहीं होती, और इसके उलट दिखावा करना आपकी समझ का अपमान होगा। मैं जो कहूँगा — और दोनों के साथ जीकर जो मानता हूँ — वह यह है कि यह फ़ासला काफ़ी घट चुका है, और उससे भी ज़्यादा अहम यह कि नाकामी के तरीक़े क़िस्म से ही अलग हैं। on-device मॉडल का सबसे बुरा दिन एक ग़लत सुना गया शब्द है जिसे आप सुधार लेते हैं। cloud मॉडल का सबसे बुरा दिन शून्य output है, क्योंकि उसकी सटीकता उसकी उपलब्धता से गुणा होती है, और ट्रेन में जो पद शून्य हो जाता है वह उपलब्धता ही है। आप कौन-सी नाकामी अपने नाम करना चाहेंगे, यह आपके दिन पर निर्भर है; मेरे दिन में ट्रेनें बहुत ज़्यादा हैं।

आज यह सिर्फ़ macOS के लिए है, और अर्ली ऐक्सेस में है। कोई Windows build नहीं, और अर्ली ऐक्सेस के साथ आने वाले खुरदरे किनारे। अगर आपका setup Windows-first है, तो ईमानदार जवाब यही है कि Keebye अभी आपकी मदद नहीं कर सकता।

अगर आप इसे किसी ऐसे टूल के मुक़ाबले तौल रहे हैं जो आप पहले से इस्तेमाल करते हैं, तो तुलना वाले पेज इसी दलील का निष्पक्ष रूप हैं। Keebye vs Superwhisper on-device ट्रांसक्रिप्शन वाले दो प्रोडक्ट्स की तुलना करता है; Keebye vs Wispr Flow लोकल-बनाम-cloud वाला फ़ैसला समेटता है। और अगर आप जिस विकल्प को तौल रहे हैं वह macOS में बना हुआ डिक्टेशन है, तो Mac के लिए वॉइस डिक्टेशन बताता है कि बिल्ट-इन टूल क्या अच्छा करता है और Keebye कहाँ अलग है।

उपलब्धता ख़ुद एक फ़ीचर है

डिक्टेशन category ने बरसों सटीकता के प्रतिशतों पर मुक़ाबला किया है, और सटीकता मायने रखती है। पर जो शिकायत लोगों से सचमुच टूल बदलवाती है, वह शायद ही कभी “इसने मुझे एक बार ग़लत सुना” होती है। वह होती है “यह फिर से चलना बंद हो गया, और मुझे नहीं पता क्यों, और इसका इलाज किसी चीज़ में लॉगिन करने से होकर गुज़रता था।” उपलब्धता — उबाऊ, बे-चमक उपलब्धता — वह फ़ीचर है जिसे आप सिर्फ़ उसकी ग़ैर-मौजूदगी के रूप में महसूस करते हैं।

किसी इनपुट तरीक़े को keyboard जितना भरोसेमंद बनाने का रास्ता यह है कि उसे keyboard जैसी ही निर्भरताओं की सूची दी जाए: आपके सामने रखी मशीन, और कुछ नहीं। यही पूरा design है।

Keebye macOS के लिए अर्ली ऐक्सेस में है। नीचे अपना फ़्री ट्रायल शुरू करें, पहली बार का डाउनलोड तब कर लें जब internet अभी मौजूद है, फिर ट्रेन की सुरंग में घुसें — या बस Wi-Fi बंद कर दें — और वही वाक्य दोबारा डिक्टेट करें।