स्पीकर डायराइज़ेशन क्या है? यह कैसे काम करता है और इसके उपयोग

स्पीकर डायराइज़ेशन अज्ञात संख्या में वक्ताओं वाली ऑडियो स्ट्रीम लेकर लेबल किए गए सेगमेंट की टाइमलाइन बनाता है: स्पीकर A 0:00 से 0:42 तक, स्पीकर B 0:42 से 1:15 तक, फिर स्पीकर A 1:15 के बाद। सिस्टम नहीं जानता कि वक्ता कौन हैं, लेकिन वह जानता है कि वे अलग-अलग लोग हैं और पूरी रिकॉर्डिंग में उनके लेबल एक जैसे रखता है।

यही प्रक्रिया मल्टी-स्पीकर ऑडियो को उपयोगी बनाती है। मीटिंग नोट्स, कॉल सेंटर एनालिटिक्स, इंटरव्यू ट्रांसक्रिप्शन, पॉडकास्ट एडिटिंग और कानूनी रिकॉर्ड—इन सभी के लिए सिर्फ़ क्या कहा गया, इतना जानना नहीं, बल्कि किसने कहा यह जानना भी ज़रूरी है। 

यह गाइड बताती है कि डायराइज़ेशन कैसे काम करता है, यह सेगमेंटेशन और आइडेंटिफ़िकेशन जैसी संबंधित तकनीकों से कैसे अलग है, कौन-से ओपन-सोर्स टूल इसे संभालते हैं और डायराइज़ेशन सिस्टम के प्रदर्शन को कैसे मापा जाए।

सारांश

• स्पीकर डायराइज़ेशन बोलने वाले व्यक्ति के आधार पर ऑडियो रिकॉर्डिंग को सेगमेंट में बाँटता है और नाम से पहचान किए बिना स्पीकर टर्न को लेबल करता है।
• स्पीकर डायराइज़ेशन, स्पीकर सेगमेंटेशन से अलग है, जो वक्ताओं के बदलने का समय पता करता है, और स्पीकर आइडेंटिफ़िकेशन से भी, जो आवाज़ों को असली नामों से मिलाता है।
• डायराइज़ेशन का प्रदर्शन, कुल सटीकता के लिए डायराइज़ेशन एरर रेट (DER) और हर वक्ता पर सटीकता बनाए रखने की जाँच के लिए जैकार्ड एरर रेट (JER) से मापा जाता है।

स्पीकर डायराइज़ेशन क्या है और यह कैसे काम करता है?

स्पीकर डायराइज़ेशन, कौन बोल रहा है इसके आधार पर ऑडियो स्ट्रीम को सेगमेंट में बाँटने की प्रक्रिया है। स्पीकर डायराइज़ेशन वाला ट्रांसक्रिप्ट ऑडियो के हर सेगमेंट को स्पीकर आइडेंटिटी से लेबल करता है। सरल शब्दों में, यह सवाल का जवाब देता है: "किसने कब बोला?" 

मीटिंग का रॉ ट्रांसक्रिप्ट आपको शब्द देता है, जबकि डायराइज़ किया गया ट्रांसक्रिप्ट बताता है कि स्पीकर 1 ने सवाल पूछा, स्पीकर 2 ने उसका जवाब दिया और स्पीकर 3 ने बीच में टोका।

ज़्यादातर स्पीकर डायराइज़ेशन सिस्टम चार चरणों वाली पाइपलाइन का पालन करते हैं:

आइए इन चरणों को विस्तार से समझें।

वॉइस एक्टिविटी डिटेक्शन (VAD)

वॉइस एक्टिविटी डिटेक्शन, स्पीच को बाकी सभी चीज़ों से अलग करता है: सन्नाटा, बैकग्राउंड शोर, संगीत, या कीबोर्ड क्लिक। सिर्फ़ असली स्पीच वाले ऑडियो सेगमेंट अगले चरण में जाते हैं।

इस चरण की कोई भी गलती आगे के सभी चरणों में फैल जाएगी।

सेगमेंटेशन

फिर इन स्पीच वाले सेगमेंट को उन बिंदुओं पर बाँटा जाता है जहाँ वक्ता बदलने की संभावना हो, जैसे आवाज़ के टोन में बदलाव, टर्न के बीच विराम या पिच पैटर्न में बदलाव। ज़्यादातर सिस्टम संभावित सीमा के दोनों ओर की ध्वनिक विशेषताओं की तुलना करके इन चेंज पॉइंट्स को सीधे पहचानते हैं। 

कुछ सेगमेंटेशन टूल ऑडियो को छोटे, एक-जैसे विंडो में काटते हैं, जैसे दो-सेकंड के हिस्से, और फिर एक ही वक्ता की आस-पास वाली विंडो को मिलाने के लिए क्लस्टरिंग चरण पर निर्भर रहते हैं।

एम्बेडिंग एक्सट्रैक्शन

हर स्पीच सेगमेंट को स्पीकर एम्बेडिंग, यानी उस सेगमेंट में बोलने वाले व्यक्ति की आवाज़ की विशेषताओं को कैप्चर करने वाले संख्यात्मक वेक्टर, में बदला जाता है। एक ही वक्ता की एम्बेडिंग वेक्टर स्पेस में पास-पास क्लस्टर होती हैं, जबकि अलग वक्ताओं की एम्बेडिंग दूर रहती हैं।

क्लस्टरिंग

फिर एम्बेडिंग को इस तरह ग्रुप किया जाता है कि एक ही वक्ता के सेगमेंट एक ही लेबल साझा करें। सिस्टम आम तौर पर पहले से वक्ताओं की संख्या नहीं जानता, इसलिए क्लस्टरिंग एल्गोरिदम को इसका अनुमान लगाना होता है—यह तय करते हुए कि थोड़ा अलग सुनाई देने वाला सेगमेंट नए वक्ता का है या अलग टोन में बोल रहे उसी व्यक्ति का।

आउटपुट में टाइम रेंज से जुड़े स्पीकर लेबल होते हैं, आम तौर पर ट्रांसक्रिप्ट के साथ। उदाहरण के लिए, दो लोगों की कॉल का डायराइज़ किया गया ट्रांसक्रिप्ट ऐसा दिखता है:

• [speaker_0] कॉल करने के लिए धन्यवाद। मैं आपकी कैसे मदद कर सकता हूँ?
• [speaker_1] नमस्ते, मैं पिछले महीने के अपने इनवॉइस के बारे में कॉल कर रहा हूँ।
• [speaker_0] ज़रूर, मैं उसे खोलता हूँ।

लेबल अनाम और अंदरूनी रूप से एक जैसे होते हैं। Speaker_0 हर बार दिखने पर वही आवाज़ है, लेकिन सिस्टम नहीं जानता कि speaker_0 का नाम Fergal है। असली पहचान जोड़ना एक अलग काम है, जिस पर हम नीचे बात करेंगे।

स्पीकर सेगमेंटेशन और स्पीकर आइडेंटिफ़िकेशन के बीच मुख्य अंतर

स्पीकर सेगमेंटेशन और स्पीकर आइडेंटिफ़िकेशन, दोनों का डायराइज़ेशन से काफ़ी ओवरलैप है, इसलिए इन तीनों को अक्सर एक ही समझ लिया जाता है।

हर एक थोड़ी अलग समस्या हल करता है, इसलिए टूलिंग का आकलन करते समय अंतर समझना ज़रूरी है।

जैसा कि हमने पहले बताया, स्पीकर सेगमेंटेशन डायराइज़ेशन के शुरुआती चरणों में होने वाला एक कदम है। यह बिना लेबल दिए उन सीमाओं को ढूँढता है जहाँ वक्ता एक आवाज़ से दूसरी आवाज़ में बदलता है। सेगमेंटेशन बताता है कि 0:42 पर बदलाव हुआ। डायराइज़ेशन आगे बढ़कर बने हुए सेगमेंट को ग्रुप करता है और पूरी तरह लेबल किया हुआ आउटपुट देता है, जिससे आपको पता चलता है कि 1:15 पर की आवाज़ वही है जो रिकॉर्डिंग की शुरुआत में बोली थी।

स्पीकर आइडेंटिफ़िकेशन, डायराइज़ेशन से अलग क्षमता है, लेकिन अक्सर इसके साथ इस्तेमाल होती है। आइडेंटिफ़िकेशन तय करता है कि वे वक्ता वास्तव में कौन हैं। आइडेंटिफ़िकेशन सिस्टम आवाज़ों की तुलना रजिस्टर्ड वॉइसप्रिंट्स से करता है और ज्ञात वक्ताओं के रेफरेंस के आधार पर पहचान लौटाता है। आइडेंटिफ़िकेशन के बाद speaker_0 और speaker_1, "Fergal" और "Eric" बन जाते हैं।

कई प्रोडक्ट अधिक विस्तृत अंतिम ट्रांसक्रिप्ट बनाने के लिए इन टूल को मिलाते हैं। कोई मीटिंग टूल यह अपने-आप कर सकता है (संभव है कि Teams या Meet पर किसी के सेट किए नाम जैसी स्ट्रिंग्स भी ले ले) ताकि बिना मैन्युअल समीक्षा के हर प्रतिभागी का योगदान नाम से जोड़ा जाए। 

लोकप्रिय ओपन-सोर्स स्पीकर डायराइज़ेशन टूल और लाइब्रेरी

जब आपको नियंत्रण, लचीलापन या लोकल डिप्लॉयमेंट चाहिए, तो ओपन-सोर्स स्पीकर डायराइज़ेशन टूल पर विचार करना फ़ायदेमंद है। सबसे अच्छा विकल्प आपके ऑडियो के प्रकार (फ़ोन कॉल, मीटिंग, पॉडकास्ट, ब्रॉडकास्ट), लेटेंसी की ज़रूरतों और आपके पास उपलब्ध इंजीनियरिंग समय पर निर्भर करता है। 

यहाँ कुछ सबसे लोकप्रिय विकल्प दिए गए हैं।

Pyannote.audio

Pyannote.audio एक PyTorch-आधारित टूलकिट है, जो खास तौर पर स्पीकर डायराइज़ेशन के लिए बनाई गई है और सबसे ज़्यादा इस्तेमाल होने वाले ओपन-सोर्स विकल्पों में से एक है। इसमें VAD, सेगमेंटेशन, एम्बेडिंग और क्लस्टरिंग समेत पूरा डायराइज़ेशन स्टैक कवर करने वाली प्रीट्रेन्ड पाइपलाइन, साथ ही अपने डेटा पर मॉडल को ट्रेन या फाइनट्यून करने के बिल्डिंग ब्लॉक मिलते हैं। 

इसके प्रीट्रेन्ड मॉडल Hugging Face के ज़रिए वितरित होते हैं और बड़े ट्रांसक्रिप्शन प्रोजेक्ट में अक्सर डायराइज़ेशन लेयर के रूप में उपयोग किए जाते हैं।

WhisperX

WhisperX OpenAI के Whisper ASR को डायराइज़ेशन और फोर्स्ड अलाइनमेंट के साथ जोड़ता है। Whisper अकेले मज़बूत ट्रांसक्रिप्ट बनाता है, लेकिन स्पीकर लेबल नहीं देता और उसके टाइमस्टैंप केवल अनुमानित होते हैं। WhisperX शब्द-स्तरीय टाइमस्टैंप अलाइनमेंट जोड़ता है और pyannote-आधारित डायराइज़ेशन इंटीग्रेट करता है, जिससे ऐसे ट्रांसक्रिप्ट बनते हैं जिनमें हर शब्द के पास सटीक टाइमस्टैंप और स्पीकर लेबल दोनों होते हैं।

NVIDIA NeMo

NVIDIA NeMo अपने व्यापक कन्वर्सेशनल AI फ़्रेमवर्क के हिस्से के रूप में डायराइज़ेशन शामिल करता है। इसमें ओवरलैपिंग स्पीच संभालने वाले एंड-टू-एंड तरीकों समेत ट्रेन किए जा सकने वाले डायराइज़ेशन मॉडल हैं और इसे GPU इन्फ्रास्ट्रक्चर पर बड़े स्तर पर कस्टम स्पीच सिस्टम बनाने वाली टीम्स के लिए डिज़ाइन किया गया है।

इनमें से हर टूल में आपको मॉडल डिप्लॉयमेंट, स्केलिंग, मॉनिटरिंग और अपडेट्स समेत डायराइज़ेशन इन्फ्रास्ट्रक्चर संभालना होता है। जो टीम्स यह ऑपरेशनल बोझ नहीं चाहतीं, उनके लिए मैनेज्ड स्पीच डायराइज़ेशन API आसान विकल्प हैं। वे मौजूदा वर्कफ़्लो के साथ इंटीग्रेट हो सकती हैं या पूरी डायराइज़ेशन पाइपलाइन संभाल सकती हैं, इसलिए कस्टमर सपोर्ट एनालिटिक्स, मीटिंग ट्रांसक्रिप्शन और पॉडकास्ट प्रोसेसिंग जैसे प्रोडक्शन उपयोग मामलों के लिए उपयुक्त हैं।

रीयल-टाइम डायराइज़ेशन: चुनौतियाँ और उपयोग के मामले

रीयल-टाइम डायराइज़ेशन, पूरी हो चुकी रिकॉर्डिंग के डायराइज़ेशन से काफ़ी कठिन है, क्योंकि सिस्टम को अधूरे संदर्भ के साथ फैसले लेने होते हैं।

ऑफ़लाइन सिस्टम किसी निर्णय पर पहुँचने से पहले पूरी रिकॉर्डिंग देखता है। वह मिनट 2 की आवाज़ की तुलना मिनट 40 की आवाज़ से करके भरोसे से तय कर सकता है कि वे एक ही वक्ता हैं, क्योंकि उसके पास दोनों पल एक साथ उपलब्ध होते हैं। रीयल-टाइम सिस्टम को यह सुविधा नहीं मिलती, क्योंकि उसे स्पीच आते ही लेबल करना होता है, उसे आगे कही जाने वाली बात की जानकारी नहीं होती और फैसला लेने के बाद उसे बदलने का बहुत कम या कोई मौका नहीं मिलता। 

भविष्य के इस संदर्भ की कमी तीन खास समस्याओं को रीयल टाइम में हल करना बहुत कठिन बना देती है:

• लेटेंसी बनाम सटीकता: पूरी बातचीत में आगे-पीछे देखने की क्षमता के बिना, कम रिस्पॉन्स-टाइम बजट पूरा करने की कीमत सीधे सटीकता से चुकानी पड़ती है।
• ओवरलैपिंग स्पीच: जब लोग एक-दूसरे के ऊपर बोलते हैं, तो ऑडियो को दोबारा प्रोसेस कर सकने वाला सिस्टम इसे अलग कर सकता है। रीयल-टाइम सिस्टम को इसे एक ही लेबल में डालना पड़ता है या तुरंत विशेष ओवरलैप-अवेयर मॉडल इस्तेमाल करने पड़ते हैं।
• छोटे कथन: जल्दी से कहा गया "हाँ" या "बोलिए" सिस्टम को काम करने के लिए मुश्किल से पर्याप्त आवाज़ देता है और आसपास के संदर्भ के बिना भी उसे तुरंत लेबल तय करना होता है।

मुश्किल के बावजूद, कुछ ऐप्लिकेशन रिकॉर्डिंग पूरी होने का इंतज़ार नहीं कर सकते। लाइव कैप्शनिंग को मीटिंग और ब्रॉडकास्ट में लोगों के बोलते ही स्पीकर लेबल चाहिए। कॉन्टैक्ट सेंटर सॉफ़्टवेयर जो एजेंट्स को कॉल के दौरान मार्गदर्शन दिखाता है, उसे रीयल टाइम में जानना होता है कि कस्टमर कौन-से शब्द कह रहा है। वॉइस एजेंट्स को कई प्रतिभागियों वाली कॉल संभालते समय बिना देरी यह ट्रैक करना होता है कि कौन क्या पूछ रहा है। हर मामले में, थोड़ा कम सटीक लेकिन तुरंत काम करने वाला सिस्टम, ज़्यादा सटीक लेकिन देर से काम करने वाले सिस्टम से बेहतर है।

एनालिटिक्स, कंप्लायंस रिव्यू और ट्रांसक्रिप्ट जनरेशन जैसे ऐसे वर्कलोड, जिन्हें वास्तव में रीयल-टाइम लेबल की ज़रूरत नहीं होती, उनके लिए बैच डायराइज़ेशन बेहतर विकल्प है क्योंकि यह काफ़ी अधिक सटीक है।

स्पीकर डायराइज़ेशन के प्रदर्शन का मूल्यांकन कैसे करें

डायराइज़ेशन की सटीकता मापते समय दो मेट्रिक सबसे अहम हैं: डायराइज़ेशन एरर रेट (DER), जो कुल सटीकता दिखाता है, और जैकार्ड एरर रेट (JER), जो जाँचता है कि यह सटीकता हर वक्ता के लिए बनी रहती है या नहीं।

DER कुल स्पीच समय के उस हिस्से की गणना करता है जिसे गलत तरीके से जोड़ा गया है। यह तीन तरह की गलतियों को मिलाता है:

• फ़ॉल्स अलार्म स्पीच: सिस्टम ने किसी सेगमेंट को स्पीच लेबल किया, जबकि कोई बोल नहीं रहा था।
• मिस्ड स्पीच: कोई बोल रहा था, लेकिन सिस्टम ने उसे सन्नाटा लेबल किया।
• स्पीकर कन्फ़्यूज़न: स्पीच का पता चला, लेकिन उसे गलत वक्ता से जोड़ा गया।

DER = (फ़ॉल्स अलार्म + मिस्ड स्पीच + स्पीकर कन्फ़्यूज़न) / कुल स्पीच अवधि

10% DER का मतलब है कि इन तीनों प्रकारों में गलतियाँ कुल स्पीच समय के दसवें हिस्से के बराबर हैं। कम स्कोर बेहतर है और स्कोर की तुलना तभी हो सकती है, जब उन्हें एक ही डेटा पर एक जैसी स्थितियों में मापा जाए। ऑडियो क्वालिटी, वक्ताओं की संख्या और रिकॉर्डिंग में ओवरलैप की मात्रा के साथ DER बहुत बदलता है।

जैकार्ड एरर रेट (JER) हर वक्ता के लिए डायराइज़ेशन की सटीकता अलग-अलग मापता है, फिर सभी वक्ताओं के परिणाम का औसत निकालता है। हर रेफरेंस स्पीकर के लिए, मूल्यांकनकर्ता सिस्टम के सबसे करीबी स्पीकर लेबल को मिलाता है और उनके सही ओवरलैप समय की तुलना किसी भी स्पीकर को दिए गए कुल समय से करता है।

उदाहरण के लिए, 60 मिनट की मीटिंग की कल्पना करें, जहाँ स्पीकर A 50 मिनट और स्पीकर B 10 मिनट बोलता है। डायराइज़ेशन सिस्टम स्पीकर A के 50 में से 48 मिनट सही लेबल करता है, लेकिन स्पीकर B के 10 में से सिर्फ़ 4 मिनट सही लेबल करता है। उसका कुल DER फिर भी अपेक्षाकृत अच्छा लग सकता है, क्योंकि मीटिंग का अधिकांश हिस्सा स्पीकर A का है। JER स्पीकर B के खराब नतीजे को बराबर महत्व देता है, क्योंकि स्कोर का औसत निकालने से पहले वह स्पीकर A और स्पीकर B का स्वतंत्र रूप से मूल्यांकन करता है।

JER_speaker = 1 - (correct_overlap / (ref_time + sys_time - correct_overlap))

अंतिम JER, हर स्पीकर की इन एरर रेट्स का औसत होता है:

JER = (1 / N) * Σ[JER_speaker_i]  जहाँ i = 1..N

DER और JER, दोनों को ट्रैक करने से डायराइज़ेशन की सटीकता की पूरी तस्वीर मिलती है: कुल सटीकता के लिए DER और यह जानने के लिए JER कि कम बोलने वाले लोगों समेत हर प्रतिभागी के लिए सटीकता बनी रहती है या नहीं।

प्रोडक्शन-जैसे ऑडियो पर टेस्टिंग

स्पीकर डायराइज़ेशन सिस्टम का मूल्यांकन करते समय, ऐसे ऑडियो पर DER और JER दोनों की गणना करें जो आपकी वास्तविक डिप्लॉयमेंट स्थितियों से मेल खाता हो: वक्ताओं की सामान्य संख्या, ऑडियो क्वालिटी और क्रॉसटॉक की मात्रा। 

प्रकाशित बेंचमार्क स्कोर, साफ़ और नियंत्रित डेटासेट पर मापे गए हो सकते हैं, जैसे स्टूडियो रिकॉर्डिंग, जो शायद ही कभी असली कॉल रिकॉर्डिंग या लाइव मीटिंग की आवाज़ जैसी होती हैं। बेंचमार्क पर अच्छा स्कोर करने वाला सिस्टम भी शोर वाले, ओवरलैपिंग, वास्तविक दुनिया के ऑडियो पर काफ़ी खराब प्रदर्शन कर सकता है। डायराइज़ेशन प्रोडक्ट चुनने से पहले अपने डेटा पर टेस्ट करें।

स्पीकर डायराइज़ेशन के लिए ElevenAPI के साथ शुरुआत करें

अगर आप मल्टी-स्पीकर सपोर्ट वाला ट्रांसक्रिप्शन फ़ीचर बनाने के लिए तैयार हैं, Scribe v2 का ElevenLabs से स्पीकर डायराइज़ेशन एक ही स्पीच टू टेक्स्ट API के ज़रिए उपलब्ध है। diarize=true के साथ एंडपॉइंट पर ऑडियो भेजें, और JSON रिस्पॉन्स 10 घंटे तक लंबी फ़ाइलों में, 90+ भाषाओं और अधिकतम 32 वक्ताओं के लिए हर शब्द को स्पीकर ID से लेबल करता है।

दो विकल्प मानक डायराइज़ेशन आउटपुट को बढ़ाते हैं। कॉल रिकॉर्डिंग के लिए detect_speaker_roles=true, अनाम नंबरों की जगह वक्ताओं को एजेंट और कस्टमर के रूप में लेबल करता है। अगर आपके वर्कस्पेस में रजिस्टर्ड स्पीकर प्रोफ़ाइल हैं, तो use_speaker_library=true डिटेक्ट किए गए वक्ताओं को रजिस्टर्ड आवाज़ों से मिला सकता है, जिससे डायराइज़ेशन और आइडेंटिफ़िकेशन एक ही रिक्वेस्ट में जुड़ जाते हैं। 

एक डायराइज़ेशन थ्रेशोल्ड पैरामीटर आपको वक्ताओं को ज़रूरत से ज़्यादा अलग करने और मर्ज करने के बीच संतुलन ट्यून करने देता है। और जब आपके वक्ता पहले से अलग ऑडियो चैनल पर आइसोलेट हों, जैसे स्टीरियो कॉल रिकॉर्डिंग में, मल्टीचैनल ट्रांसक्रिप्शन चैनल के अनुसार वक्ता असाइन करता है और डायराइज़ेशन को पूरी तरह छोड़ देता है।

यह स्पीच टू टेक्स्ट क्विकस्टार्ट पहले इंटीग्रेशन को चरण-दर-चरण समझाता है। रेगुलेटेड डिप्लॉयमेंट के लिए प्लेटफ़ॉर्म SOC 2, ISO 27001, PCI DSS L1 और HIPAA कंप्लायंट है, और EU डेटा रेज़िडेंसी व ज़ीरो रिटेंशन मोड उपलब्ध हैं।

क्या आप अपने सिस्टम में स्पीकर डायराइज़ेशन बनाने के लिए तैयार हैं? शुरुआत करें अपनी API कुंजी पाकर या देखें ElevenLabs Docs और अधिक जानने के लिए।

अक्सर पूछे जाने वाले सवाल