OpenAI ने GPT-Live बनाया है, जो एक वॉइस-फर्स्ट चैटबॉट है जो एक साथ सुनता और बोलता है, और उन भारी-भरकम "पहले बोलें फिर सुनें" वाले ठहरावों को खत्म कर देता है जो अधिकांश असिस्टेंट्स में होते हैं। इस सेवा का लक्ष्य एक ऐसी बातचीत प्रदान करना है जो रुक-रुक कर होने वाले आदान-प्रदान के बजाय मानवीय संवाद की तरह सहजता से चले।
पुराना मॉडल क्यों दोषपूर्ण लगता था
सामान्य वॉइस असिस्टेंट वॉकी-टॉकी की तरह काम करते हैं: आप एक वाक्य पूरा करते हैं, डिवाइस उसे रिकॉर्ड करता है, ऑडियो को क्लाउड पर भेजता है, प्रतिक्रिया का इंतज़ार करता है, और फिर उसे वापस चलाता है। इस राउंड-ट्रिप की वजह से एक ध्यान देने योग्य लैग (lag) पैदा होता है और उपयोगकर्ताओं को बीच में टोकने से पहले रुकने के लिए मजबूर होना पड़ता है। इंस्टेंट मैसेजिंग के दौर में पली-बढ़ी पीढ़ी के लिए, यह देरी बहुत पुरानी और बोझिल लगती है।
OpenAI ने इसका समाधान एक turn-less आर्किटेक्चर के साथ किया। हर सेकंड, GPT-Live यह तय करता है कि उसे सुनना जारी रखना है, बोलना जारी रखना है, या रुकना है, जिससे आप जवाब के बीच में ही असिस्टेंट को रोक सकते हैं या पूरे रिस्पॉन्स साइकिल का इंतज़ार किए बिना कोई फॉलो-अप सवाल पूछ सकते हैं।
फुल-डुप्लेक्स स्टैक (full-duplex stack) सरल शब्दों में
- अलग ऑडियो लूप और रीजनिंग पाथ – एक fast path निरंतर ऑडियो एक्सचेंज को संभालता है, जबकि एक slow path वेब सर्च या टूल कॉल्स जैसे भारी कार्यों को चलाता है। फास्ट पाथ बातचीत को जीवंत रखता है जबकि स्लो पाथ अपना काम करता है, जिससे "सोचते समय होने वाली चुप्पी" का डर खत्म हो जाता है।
- WARP protocol – पारंपरिक वेब कनेक्शन में ऑडियो प्रवाह शुरू होने से पहले कई हैंडशेक्स (handshakes) की आवश्यकता होती है, जो अक्सर छह राउंड-ट्रिप तक होते हैं। OpenAI का कस्टम प्रोटोकॉल इन चरणों को एक ही ट्रिप में समेट देता है, जिससे सेशन की शुरुआत लगभग तुरंत महसूस होती है।
- लेटेंसी निरंतरता के लिए Python के बजाय Go का उपयोग – टीम ने रियल-टाइम कंपोनेंट्स को Python (जो तेज़ विकास के लिए जाना जाता है) से हटाकर Go में स्थानांतरित कर दिया, जो अधिक अनुमानित (predictable) निष्पादन समय प्रदान करता है। वॉइस AI में, औसत गति की तुलना में 'वर्स्ट-केस' (worst-case) देरी अधिक मायने रखती है; एक भी हिचकिचाहट अनुभव को खराब कर सकती है, इसलिए निरंतर लेटेंसी ही जीतती है।
- GPU से परे स्केलिंग – करोड़ों उपयोगकर्ताओं के साथ, बाधा (bottleneck) मॉडल के कंप्यूट कोर से हटकर आसपास के इंफ्रास्ट्रक्चर पर आ गई। OpenAI ने पाया कि GPUs से पहले CPUs और नेटवर्क लिंक संतृप्त (saturated) हो रहे थे, इसलिए उन्होंने बाकी स्टैक को प्रभावित किए बिना GPUs को डेटा उपलब्ध कराने के लिए स्मार्ट रूटिंग और कनेक्शन-मैनेजमेंट जोड़ा।
डेवलपर्स के लिए इसका क्या अर्थ है
- ऑडियो हैंडलिंग को बिजनेस लॉजिक से अलग करें – एक हल्का, हमेशा चालू रहने वाला लूप रखें जो माइक्रोफ़ोन इनपुट और स्पीकर आउटपुट को प्रोसेस करे। जो कुछ भी इंतज़ार कर सकता है—जैसे डेटाबेस क्वेरीज़, बाहरी API कॉल्स—उसे एक अलग थ्रेड या सर्विस पर डाल दें।
- लेटेंसी स्थिरता को प्राथमिकता दें – रिस्पॉन्स टाइम को मापें, और केवल औसत (mean) के बजाय 'वर्स्ट-केस' देरी पर ध्यान केंद्रित करें। ऐसी भाषाएं और रनटाइम जो शेड्यूलिंग पर बेहतर नियंत्रण देते हैं (जैसे, Go, Rust), वे अतिरिक्त इंजीनियरिंग प्रयास के लायक हो सकते हैं।
- कनेक्शन ओवरहेड को कम करें – हर अतिरिक्त हैंडशेक मिलीसेकंड जोड़ता है जो समय के साथ बढ़ते जाते हैं। ऑथेंटिकेशन, स्ट्रीम नेगोशिएशन और कोडेक सिलेक्शन को एक ही एक्सचेंज में समेट दें, और उपयोगकर्ता इसका अंतर महसूस करेंगे।
ट्रेड-ऑफ और खुले प्रश्न
फुल-डुप्लेक्स डिज़ाइन जटिलता बढ़ाता है।