ट्रांसक्रिप्ट और कमिट रणनीतियां
यह गाइड बताती है कि ElevenLabs रीयलटाइम स्पीच टू टेक्स्ट API के साथ ट्रांसक्रिप्ट और कमिट रणनीतियों को कैसे संभालें।
कैसे करें गाइड · मान लिया गया है कि आपने क्लाइंट-साइड या सर्वर-साइड स्ट्रीमिंग गाइड पूरी कर ली है।
ओवरव्यू
ऑडियो ट्रांसक्राइब करते समय, आपको आंशिक और कमिट किए गए ट्रांसक्रिप्ट मिलेंगे।
- आंशिक ट्रांसक्रिप्ट - ट्रांसक्रिप्शन के अंतरिम नतीजे
- कमिट किए गए ट्रांसक्रिप्ट - ट्रांसक्रिप्शन सेगमेंट के अंतिम नतीजे, जो “commit” मैसेज मिलने पर भेजे जाते हैं। एक सेशन में कई कमिट किए गए ट्रांसक्रिप्ट हो सकते हैं।
कमिट ट्रांसक्रिप्ट में वैकल्पिक रूप से शब्द-स्तर के टाइमस्टैंप शामिल हो सकते हैं। यह केवल तब मिलता है, जब “include timestamps” विकल्प true पर सेट हो।
कमिट रणनीतियां
WebSocket के ज़रिए ऑडियो चंक्स भेजते समय, ट्रांसक्रिप्ट सेगमेंट को दो तरीकों से कमिट किया जा सकता है: मैन्युअल कमिट या वॉइस एक्टिविटी डिटेक्शन (VAD)।
मैन्युअल कमिट
मैन्युअल कमिट रणनीति में, आप तय करते हैं कि ट्रांसक्रिप्ट सेगमेंट कब कमिट करने हैं। यह डिफ़ॉल्ट रूप से इस्तेमाल की जाने वाली रणनीति है। किसी सेगमेंट को कमिट करने पर प्रोसेस किया गया संचित ट्रांसक्रिप्ट हट जाता है और संदर्भ खोए बिना नया सेगमेंट शुरू हो जाता है। लेटेंसी बेहतर करने के लिए हर 20-30 सेकंड में कमिट करना अच्छा अभ्यास है। अगर आप मैन्युअल रूप से कमिट नहीं करते, तो मॉडल लगभग 36 सेकंड के संचित ऑडियो के बाद अपने-आप कमिट कर देता है।
बेहतरीन नतीजों के लिए, खामोशी के दौरान या टर्न मॉडल जैसे किसी अन्य तार्किक बिंदु पर कमिट करें।
कम समय में लगातार कई बार मैन्युअल कमिट करने से मॉडल की परफ़ॉर्मेंस खराब हो सकती है।
पिछले टेक्स्ट का संदर्भ भेजना
ट्रांसक्रिप्शन के लिए ऑडियो भेजते समय, आप पहले ऑडियो चंक के साथ पिछले टेक्स्ट का संदर्भ भेज सकते हैं, ताकि मॉडल बोलचाल का संदर्भ समझ सके। यह कुछ स्थितियों में उपयोगी है:
- कन्वर्सेशनल AI उपयोग मामलों के लिए एजेंट टेक्स्ट - मॉडल को बातचीत का संदर्भ आसानी से समझने और बेहतर ट्रांसक्रिप्शन बनाने में मदद मिलती है।
- नेटवर्क त्रुटि के बाद दोबारा कनेक्ट करना - इससे मॉडल पिछले टेक्स्ट को मार्गदर्शन के रूप में इस्तेमाल करके ट्रांसक्राइब करना जारी रख सकता है।
- सामान्य संदर्भ संबंधी जानकारी - ट्रांसक्रिप्शन किस बारे में होगा, इसका छोटा विवरण मॉडल को संदर्भ समझने में मदद करता है।
previous_text संदर्भ केवल पहले ऑडियो चंक को
connection.send() के ज़रिए भेजते समय ही भेजा जा सकता है। बाद के चंक्स में इसे भेजने पर त्रुटि होगी। पिछला टेक्स्ट
तब सबसे अच्छा काम करता है, जब वह 50 वर्णों से कम हो।
वॉइस एक्टिविटी डिटेक्शन (VAD)
VAD रणनीति में, ट्रांसक्रिप्शन इंजन बोलने और खामोशी के सेगमेंट अपने-आप पहचानता है। खामोशी की सीमा पूरी होने पर, ट्रांसक्रिप्शन इंजन ट्रांसक्रिप्ट सेगमेंट को अपने-आप कमिट कर देगा।
क्लाइंट-साइड इंटीग्रेशन में माइक्रोफ़ोन से ऑडियो ट्रांसक्राइब करते समय, VAD रणनीति इस्तेमाल करने की सलाह दी जाती है।
खामोशी के दौरान कनेक्शन चालू रखना
मैसेज न आने पर आधिकारिक SDKs कनेक्शन नहीं छोड़ते, इसलिए ज़्यादातर इंटीग्रेशन में इसकी ज़रूरत नहीं होती। अगर आपका अपना WebSocket क्लाइंट, या बीच में कोई प्रॉक्सी या लोड बैलेंसर, कुछ समय तक कोई फ़्रेम न आने पर कनेक्शन बंद कर देता है, तो कनेक्ट करते समय वैकल्पिक keepalive_interval_ms क्वेरी पैरामीटर पास करें। यह लंबे समय की खामोशी के दौरान महत्वपूर्ण है, जैसे 10-15 सेकंड के विराम वाले फ़ोन कॉल में। हर इंटरवल में लगभग एक बार, सर्वर एक कीपअलाइव partial_transcript भेजता है: अगर मौजूदा सेगमेंट में कोई अनकमिटेड टेक्स्ट नहीं है, तो खाली (text: ""), या अगर है तो नवीनतम आंशिक टेक्स्ट को दोबारा भेजता है।
कीपअलाइव लगातार चलने वाला पिंग नहीं है: आपको ऑडियो स्ट्रीम करते रहना होगा (खामोशी के फ़्रेम भी ठीक हैं)। अगर आप ऑडियो भेजना बंद करते हैं, तो कोई कीपअलाइव नहीं भेजा जाएगा और सर्वर किसी भी क्लाइंट मैसेज के बिना 15 सेकंड बाद कनेक्शन बंद कर देगा। सर्वर की इस सीमा को कॉन्फ़िगर नहीं किया जा सकता।
500और10000(मिलीसेकंड) के बीच का पूर्णांक स्वीकार करता है। यह डिफ़ॉल्ट रूप से बंद रहता है; मौजूदा व्यवहार बनाए रखने के लिए पैरामीटर न दें।- सीमा से बाहर या गैर-पूर्णांक वैल्यू पर सर्वर
invalid_requestत्रुटि भेजता है और कनेक्शन बंद कर देता है। - कीपअलाइव आपके भेजे गए साइलेंट ऑडियो को मॉडल द्वारा वास्तव में प्रोसेस किए जाने पर निर्भर हैं, न कि किसी लगातार चलने वाले टाइमर पर, इसलिए वे यह भी पुष्टि करते हैं कि ट्रांसक्रिप्शन पाथ चालू है।
- ऑडियो लगभग 1-सेकंड के चंक्स में प्रोसेस होता है, इसलिए कीपअलाइव उस गति के अनुसार राउंड किए गए हर इंटरवल में लगभग एक बार आते हैं (उदाहरण के लिए,
1000लगभग हर सेकंड और3000लगभग हर 3 सेकंड में ट्रिगर होता है)। सेशन का पहला कीपअलाइव शुरू होने के लगभग 2 सेकंड बाद आता है, क्योंकि सर्वर ट्रांसक्राइब करने से पहले शुरुआती ~2 सेकंड का ऑडियो बफ़र करता है। पर्याप्त मार्जिन के लिए अपना इंटरवल अपने रीड टाइमआउट के लगभग एक-तिहाई या उससे कम रखें। - कीपअलाइव का
textकेवल तभी खाली होता है, जब मौजूदा सेगमेंट में अभी तक कोई अनकमिटेड टेक्स्ट न हो। अगर बोलने के बाद लेकिन कमिट से पहले विराम आता है — जोfilter_background_audio=trueके साथ या बिना कमिट किए मैन्युअल कमिट मोड में सबसे ज़्यादा दिखता है — तो कीपअलाइव नवीनतम आंशिक टेक्स्ट को दोहराता है, इसलिए यह अंतरिम टेक्स्ट को कभी खाली नहीं करता। कमिट के बाद, नया बोलना शुरू होने तक कीपअलाइव फिर से खाली हो जाते हैं। commit_strategy=manualऔरcommit_strategy=vad, दोनों के साथ औरfilter_background_audio=trueके साथ काम करता है। आपके पहले से स्ट्रीम किए जा रहे ऑडियो के अलावा बिलिंग पर कोई असर नहीं पड़ता।session_startedमैसेज काconfig,keepalive_interval_msको वापस दिखाता है (बंद होने परnull)।
खाली partial_transcript (text: "") का मतलब है “मौजूदा सेगमेंट में कोई बोलचाल नहीं है।” विराम के दौरान दोहराया गया,
एक जैसा partial_transcript भी कीपअलाइव है — क्लाइंट्स को रिपीट के लिए अलग से व्यवहार करने के बजाय
आंशिक ट्रांसक्रिप्ट को वैसे ही रेंडर करना चाहिए, जैसे वे पहले करते हैं।
WebSocket URL में पैरामीटर जोड़ें:
समर्थित ऑडियो फ़ॉर्मैट
सर्वोत्तम अभ्यास
ऑडियो क्वालिटी
- बेहतरीन नतीजों के लिए, क्वालिटी और बैंडविड्थ के बेहतर संतुलन हेतु 16kHz सैंपल रेट इस्तेमाल करें।
- कम से कम बैकग्राउंड नॉइज़ वाला साफ़ ऑडियो इनपुट सुनिश्चित करें।
- क्लिपिंग से बचने के लिए उचित माइक्रोफ़ोन गेन इस्तेमाल करें।
- फ़िलहाल केवल मोनो ऑडियो समर्थित है।
चंक साइज़
- सहज स्ट्रीमिंग के लिए 0.1 - 1 सेकंड लंबे ऑडियो चंक्स भेजें।
- छोटे चंक्स से लेटेंसी कम होती है, लेकिन ओवरहेड बढ़ता है।
- बड़े चंक्स ज़्यादा कुशल होते हैं, लेकिन लेटेंसी बढ़ा सकते हैं।