
AI ट्रांसक्रिप्शन तकनीकी शब्दों को गलत क्यों सुनता है (और हमने इसे कैसे ठीक किया)
एक लाइव सेशन ने "what is the pointer in C++" को "what is the point in life" सुन लिया। यह उस ट्रांसक्रिप्ट से GeekBye v2.0.11 तक की फोरेंसिक जांच की कहानी है — keyterm biasing, कनेक्शन गिराने वाली एक टाइमिंग रेस, और वह दिन जब हमारा अपना फिक्स ही उल्टा पड़ गया।
2 जुलाई को हमने एक टेस्ट सेशन चलाया और GeekBye से बोलकर एक सीधा-सा सवाल पूछा: "What is the pointer in C++?" (C++ में पॉइंटर क्या है?)
लाइव ट्रांसक्रिप्ट ने जवाब में शायरी सुना दी:
[23:16:37] You: Tell me, what is the point in life? [23:16:52] You: Handy Plus. [23:17:02] You: What the pointer in Plus Plus? [23:17:09] You: C.
यानी "pointer in C++" (C++ का पॉइंटर) बन गया "point in life" (जिंदगी का मकसद)। उसी सेशन के हेल्थ मेट्रिक्स ने बाकी कहानी बताई: 163 सेकंड में 3 बार ट्रांसक्रिप्शन कनेक्शन गिरा और ट्रांसक्रिप्ट में 51 सेकंड का छेद। और एक सुराग ऐसा था जो बाद में सबसे अहम साबित हुआ: हमारा सेशन के बाद चलने वाला रिकवरी पास — जो गैप भरने के लिए लोकली सेव किए गए ऑडियो को दोबारा ट्रांसक्राइब करता है — उस वाक्य को लगभग सही पकड़ गया: "a pointer in plus, plus? What the pointer in plus, plus C++."
ऑडियो बिल्कुल ठीक था। लाइव मॉडल के पास बस C++ की उम्मीद करने की कोई वजह नहीं थी।
यह GeekBye v2.0.11 की कहानी है, असली ट्रांसक्रिप्ट्स और प्रोडक्शन लॉग्स की जुबानी।
स्पीच मॉडल आपकी शब्दावली गलत क्यों सुनते हैं
स्पीच रिकग्निशन एक प्रेडिक्शन की समस्या है। अस्पष्ट ऑडियो मिलने पर मॉडल सबसे संभावित शब्द चुनता है — और एक जनरल-पर्पस मॉडल के लिए "point in life" जैसा वाक्यांश "pointer in C++" से कहीं ज्यादा संभावित है। जिस भी इंजीनियर ने मीटिंग ट्रांसक्रिप्ट में Kubernetes को "cube and eddies" बनते देखा है, वह इस नाकामी से मिल चुका है।
इसका इलाज बेहतर माइक्रोफोन नहीं है। इलाज है keyterm biasing: सेशन शुरू होने से पहले मॉडल को बताना कि कौन से असामान्य शब्द आपके लिए सामान्य हैं। हमारा स्पीच प्रोवाइडर प्रति सेशन 50 biasing terms तक सपोर्ट करता है। और अब शर्मिंदगी वाली बात: इन terms की पूरी प्लंबिंग हमारे स्टैक में एंड-टू-एंड मौजूद थी — क्लाइंट, backend, प्रोवाइडर — लेकिन उसमें कभी किसी ने कुछ भरा ही नहीं था। हर सेशन शून्य डोमेन मदद के साथ चल रहा था।
फिक्स 1: आपका प्रोफाइल मॉडल की शब्दावली बन जाता है
GeekBye आपकी डोमेन पहले से जानता है — वह आपके एक्टिव प्रोफाइल में लिखी है। v2.0.11 प्रोफाइल के नाम और विवरण से biasing keyterms निकालता है: सिंबल वाले शब्द (C++, Node.js), संक्षिप्त रूप (SQL, AWS), camel-case नाम (TypeScript, PostgreSQL), और proper nouns। आपके स्टैक का जिक्र करने वाला प्रोफाइल अब उस स्टैक को अजीब नहीं, बल्कि अपेक्षित बना देता है।
वह दिन जब फिक्स ने सब कुछ बिगाड़ दिया
हमारे पहले वर्जन ने हर capitalized शब्द को proper noun मान लिया। एक इंटरनल टेस्ट बिल्ड पर (यह कभी ग्राहकों तक नहीं पहुंचा), गद्य में लिखे एक प्रोफाइल ने मॉडल को यह biasing लिस्ट भेज दी:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
स्पीच मॉडल को "For" जैसे शब्द की ओर bias करना, bias न करने से भी बदतर है। ठीक अगले टेस्ट सेशन में, साफ-साफ और कई बार बोला गया शब्द "speak" लौटकर आया "Clicky", "Hey, Vicky" और "Peter Paderty" बनकर। इस सबक की कीमत हमारी एक दोपहर थी: सिर्फ विशिष्ट (distinctive) terms से bias करो। Capitalized शब्द अब सिर्फ तभी गिने जाते हैं जब वे वाक्य के बीच में आएं (जो proper noun का असली संकेत है); markdown हेडिंग्स, जहां हर शब्द capitalized होता है, कभी योगदान नहीं देतीं। वही प्रोफाइल अब ठीक-ठीक LinkedIn, AI, CEO, MCP निकालता है — और वैलिडेशन सेशन ने बहुभाषी, तेजी से स्विच होते ऑडियो को लगातार 199 सेकंड तक सही ट्रांसक्राइब किया, 189 ट्रांसक्रिप्ट सेगमेंट, शून्य गलतियां।
फिक्स 2: वह रेस जो कनेक्शन गिरा रही थी
Keyterms ने गलत सुने गए शब्दों की गुत्थी सुलझा दी। लेकिन तीन कनेक्शन ड्रॉप्स की नहीं।
वह सुराग कहीं ज्यादा बारीक जगह ले गया। हमारा प्रोवाइडर अपनी voice-activity detection के आधार पर, खामोशी के करीब एक सेकंड बाद, ट्रांसक्रिप्शन को खुद commit (फाइनल) कर देता है। हमारा क्लाइंट भी किसी अधूरे लटके वाक्य को flush करने के लिए, खामोशी के 250 मिलीसेकंड बाद एक safety commit भेजता है। प्रोवाइडर की यह पुष्टि कि उसने पहले ही commit कर दिया है, वापस पहुंचने में एक से तीन सेकंड लेती है। अब इन तीन आंकड़ों का हिसाब लगाइए: जब भी प्रोवाइडर पहले commit करता, हमारा safety commit लगभग खाली बफर पर दागा जाता — और उस पर प्रोवाइडर की प्रतिक्रिया कोई विनम्र इनकार नहीं थी। वह कनेक्शन ही गिरा देता था। बोलते-बोलते हर ठहराव एक सिक्का उछालने जैसा था।
v2.0.11 इसके खिलाफ दो परतें लेकर आया है:
- ऐप में: जब कोई committed ट्रांसक्रिप्ट पहुंचता है, तो क्लाइंट अब जानता है कि प्रोवाइडर का बफर अभी-अभी flush हुआ है, और वह फालतू safety commit को छोड़ देता है।
- हमारे backend में, उसी दिन: ऐप और प्रोवाइडर के बीच बैठा proxy प्रोवाइडर की ऑडियो अकाउंटिंग की हूबहू नकल रखता है — वह हर ऑडियो फ्रेम और हर commit पुष्टि को शून्य लेटेंसी पर देखता है — और ऐसे किसी भी commit को आगे भेजने से ही मना कर देता है जिसे प्रोवाइडर ठुकराने वाला हो। यह परत एक साथ हर क्लाइंट वर्जन की रक्षा करती है, उन यूज़र्स की भी जिन्होंने अपडेट नहीं किया है।
हमने इसे एक घंटे के भीतर प्रोडक्शन में काम करते देखा। Guard ने 178ms और 256ms बफर्ड ऑडियो वाले बर्बाद commits को रोका — उस दिन से पहले इनमें से हर एक का मतलब था पक्का कनेक्शन ड्रॉप और किसी की मीटिंग नोट्स में एक गैप। उसी दोपहर 60 मिनट के लगातार सेशन में पांच बार रोका गया और शून्य ड्रॉप दर्ज हुए। फिक्स से पहले, उसी सुबह एक असली यूज़र ने ठीक इसी बग से जूझते हुए छह मिनट में पांच बार अपनी रिकॉर्डिंग रीस्टार्ट की थी।
साथ में आए दो छोटे फिक्स
AI insights अब ठोस सामग्री का इंतजार करते हैं। शुरुआत के वे बिगड़े हुए टुकड़े पहले GeekBye के लाइव सजेशन चिप्स में चले जाते थे, जो एक गलत सुने गए C++ सवाल से "Defining Life's Ultimate Purpose" (जीवन का परम उद्देश्य परिभाषित करना) जैसे टॉपिक पूरे आत्मविश्वास से बना देते थे। सुझाव अब तब तक रुकते हैं जब तक सेशन में असली बातचीत का वजन न आ जाए।
रिकवर हुए टेक्स्ट को सही वक्ता मिलता है। जिस रिकवरी पास ने हमारा C++ सवाल सही ट्रांसक्राइब किया था, उसने उसे "Them" (सामने वाले) के नाम कर दिया था। लोकली सेव होने वाली ऑडियो टाइमलाइन अब यह भी दर्ज करती है कि कौन बोल रहा था, इसलिए रिकवर हुए सेगमेंट सही तरीके से You या Them को मिलते हैं।
स्कोरबोर्ड
| मेट्रिक (मापा गया, अनुमान नहीं) | पहले | v2.0.11 + backend guard के बाद |
|---|---|---|
| टेस्ट सेशन में कनेक्शन ड्रॉप | 163s में 3 | 0 |
| ट्रांसक्रिप्ट का सबसे लंबा छेद | 51s | वैलिडेशन में सबसे खराब गैप ~6s |
| "pointer in C++" | "point in life" | सही, biased शब्दावली के साथ |
| प्रोवाइडर तक पहुंचने वाले बर्बाद commits | सारे के सारे | 0 (backend पर रोके गए) |
अगर आप realtime speech APIs पर कुछ बना रहे हैं
इस रिलीज़ से तीन सबक जो कहीं भी काम आएंगे:
- Biasing फीचर को खुराक दो। अगर आपका STT प्रोवाइडर keyterms/phrase hints सपोर्ट करता है, तो उसमें एक छोटी, विशिष्ट शब्दावली भरना accuracy की सबसे सस्ती जीत है — और उसमें आम शब्द भरना accuracy का घाटा।
- नेटवर्क राउंड-ट्रिप के गलत छोर से प्रोवाइडर की अपनी state machine से कभी रेस मत लगाओ। हमारा क्लाइंट 250ms बनाम 3 सेकंड की सूचना-रेस नहीं जीत सकता था। Guard वहां होना चाहिए जहां दोनों सिग्नल मिलते हैं — हमारे लिए वह जगह backend proxy थी।
- पब्लिश करने से पहले लाइव बिल्ड पर वैलिडेट करो। Keyterms वाला regression इसलिए पकड़ा गया क्योंकि GeekBye की हर रिलीज़ शिप होने से पहले एक signed, notarized बिल्ड के रूप में प्रोडक्शन के खिलाफ टेस्ट होती है। खराब वर्जन कुछ घंटों तक सिर्फ एक इंटरनल मशीन पर रहा, आपके Mac पर नहीं।
GeekBye v2.0.11 अब लाइव है — अगर आप v2 पर हैं, तो auto-update के जरिए यह आपके पास पहले से है। जिस विश्वसनीयता की नींव पर यह रिलीज़ खड़ी है, उसके लिए पढ़ें खराब Wi-Fi पर आपका AI notetaker क्यों रुक जाता है और GeekBye v2 में क्या बदला। लाइव ट्रांसक्रिप्शन रोजमर्रा में कैसे काम करता है, इसके लिए शुरुआत करें GeekBye में रियल-टाइम ट्रांसक्रिप्शन से।

