Pulse ASR, Sierra MuBench पर P95 लेटेंसी में सबसे आगे: जानें यह मीट्रिक क्यों महत्वपूर्ण है

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

यही बात सिएरा के म्यूबेन्च (MuBench) लीडरबोर्ड को विशेष रूप से दिलचस्प बनाती है। यह प्रदर्शन के उस आयाम को मापता है जो हमारे विचार में वॉयस एआई (Voice AI) में अक्सर कम आंका जाता है: टेल लेटेंसी (tail latency)। यदि आप वॉयस एजेंट बना रहे हैं, तो P95 अक्सर आपको औसत लेटेंसी की तुलना में उपयोगकर्ता अनुभव के बारे में बहुत अधिक सटीक जानकारी देता है।

पल्स (Pulse) अंग्रेजी के लिए 196ms की P95 लेटेंसी के साथ सिएरा के म्यूबेन्च लीडरबोर्ड में शीर्ष पर रहा है।

196ms का यह आंकड़ा 8kHz मोनो (टेलीफोन-गुणवत्ता वाला ऑडियो, न कि स्टूडियो रिकॉर्डिंग) पर रिकॉर्ड किए गए 817 वास्तविक ग्राहक सेवा फोन कॉल्स पर मापा गया है - जो इसे अधिकांश बेंचमार्क की तुलना में कहीं अधिक कठिन परीक्षण बनाता है।

P50, P95, और P99 को समझना

कल्पना कीजिए कि आपका स्पीच मॉडल 100 अनुरोधों (requests) को प्रोसेस करता है। उन अनुरोधों को सबसे तेज़ से लेकर सबसे धीमे क्रम में व्यवस्थित करें। परसेंटाइल (प्रतिशतक) हमें बताते हैं कि उस वितरण में अलग-अलग बिंदुओं पर उपयोगकर्ताओं को कितना इंतजार करना पड़ता है।

P50: माध्यिका (मीडियन) अनुभव

P50, या माध्यिका लेटेंसी, वह मान (value) है जिससे नीचे 50% अनुरोध पूरे होते हैं।

यदि आपकी P50 लेटेंसी 200 ms है, तो आधे अनुरोध 200 ms से कम समय में पूरे हो जाते हैं, जबकि बाकी आधे में अधिक समय लगता है।

यह संख्या वितरण के मध्य भाग को दर्शाती है। यह एक उपयोगी मीट्रिक है, लेकिन यह निरंतरता के बारे में बहुत कम बताती है। दो प्रणालियों की P50 लेटेंसी बिल्कुल समान हो सकती है, जबकि लोड होने पर उनका व्यवहार बहुत अलग हो सकता है।

P95: प्रोडक्शन अनुभव

P95 वह लेटेंसी है जिससे नीचे 95% अनुरोध पूरे होते हैं।

यदि आपकी P95 लेटेंसी 200 ms है, तो हर 100 में से 95 अनुरोध 200 ms के भीतर पूरे हो जाते हैं। शेष पांच अनुरोधों में अधिक समय लगता है।

P95 इस प्रश्न का उत्तर देता है: लगभग सभी उपयोगकर्ताओं के लिए सिस्टम कितना प्रतिक्रियाशील है?

यहीं पर वास्तविक उत्पादन परिवेश (production environments) के प्रभाव दिखने शुरू होते हैं: कतार में देरी (queueing delays), ट्रैफ़िक में अचानक उछाल, संसाधनों की कमी, नेटवर्क में उतार-चढ़ाव, बुनियादी ढांचे (infrastructure) की बाधाएं।

जबकि P50 यह बताता है कि एक सिस्टम सामान्य परिस्थितियों में कैसा व्यवहार करता है, P95 यह प्रकट करता है कि जब वे परिस्थितियां आदर्श से कम हों लेकिन फिर भी आम हों, तब वह कैसा व्यवहार करता है।

म्यूबेन्च रैखिक प्रक्षेप (linear interpolation) का उपयोग करके इसकी गणना करता है: दिए गए N क्रमबद्ध लेटेंसी मानों के आधार पर, P95 रैंक ⌊0.95(N−1)⌋ और ⌈0.95(N−1)⌉ के मानों के बीच का एक भारित मिश्रण (weighted blend) है, न कि केवल "95वां मान चुनना।" यह टेल (अंतिम छोर) पर अधिक सटीक अनुमान प्रदान करता है, जहां सटीकता सबसे अधिक मायने रखती है।

def percentile(values: list[float], p: float) -> float:
"""Compute the p-th percentile using linear interpolation."""
if not values:
return 0.0
<p>sorted_vals = sorted(values)<br>k = (len(sorted_vals) - 1) * (p / 100)</p>
<p>f = math.floor(k)<br>c = math.ceil(k)</p>
<p>if f == c:<br>return sorted_vals[int(k)]</p>

def percentile(values: list[float], p: float) -> float:
"""Compute the p-th percentile using linear interpolation."""
if not values:
return 0.0
<p>sorted_vals = sorted(values)<br>k = (len(sorted_vals) - 1) * (p / 100)</p>
<p>f = math.floor(k)<br>c = math.ceil(k)</p>
<p>if f == c:<br>return sorted_vals[int(k)]</p>

def percentile(values: list[float], p: float) -> float:
"""Compute the p-th percentile using linear interpolation."""
if not values:
return 0.0
<p>sorted_vals = sorted(values)<br>k = (len(sorted_vals) - 1) * (p / 100)</p>
<p>f = math.floor(k)<br>c = math.ceil(k)</p>
<p>if f == c:<br>return sorted_vals[int(k)]</p>

k का मान मापों की एक क्रमबद्ध सूची के भीतर 95वें परसेंटाइल की आंशिक स्थिति (fractional position) को दर्शाता है। उदाहरण के लिए, 817 मापों के साथ, P95 की स्थिति इंडेक्स 775.2 पर है। चूंकि यह स्थिति बिल्कुल एक वास्तविक अवलोकन पर न होकर दो वास्तविक अवलोकनों के बीच आती है, परसेंटाइल की गणना प्रक्षेप (interpolation) का उपयोग करके की जाती है: इसके आस-पास के निम्नतम (floor) और उच्चतम (ceiling) स्थितियों के मानों का एक भारित औसत। यह परसेंटाइल का अधिक सहज और सटीक अनुमान सुनिश्चित करता है, विशेष रूप से तब जब डेटासेट का आकार वांछित परसेंटाइल को ठीक एक माप पर स्थापित नहीं करता है।

P99: टेल (अंतिम छोर का) अनुभव

P99 वह लेटेंसी है जिससे नीचे 99% अनुरोध पूरे होते हैं। यह प्रभावी रूप से सबसे धीमे 1% अनुरोधों के व्यवहार को मापता है।

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

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

इसका नुकसान यह है कि P99 स्वाभाविक रूप से P95 की तुलना में दुर्लभ घटनाओं के प्रति अधिक संवेदनशील है। बुनियादी ढांचे या वर्कलोड की विशेषताओं में छोटे बदलाव सबसे धीमे 1% अनुरोधों को महत्वपूर्ण रूप से प्रभावित कर सकते हैं, जिससे यह मीट्रिक अधिक उतार-चढ़ाव वाला हो जाता है और अक्सर इसे सीधे अनुकूलित (optimize) करना कठिन होता है।

वॉयस एजेंट्स अधिकांश एआई प्रणालियों की तुलना में P95 की अधिक परवाह क्यों करते हैं

दो वॉयस एजेंट्स पर विचार करें:

यदि हम केवल P50 को देखें, तो एजेंट A अधिक तेज़ दिखाई देगा और अधिकांश बेंचमार्क सारांश इसे उच्च रैंक देंगे। फिर भी व्यावहारिक रूप से, कई उपयोगकर्ता संभवतः एजेंट B को पसंद करेंगे।

क्योंकि बातचीत केवल गति पर नहीं, बल्कि पूर्वानुमान की क्षमता (predictability) पर निर्भर करती है।

एजेंट A तब तक प्रभावशाली लगता है जब तक कि वह अटक न जाए। अधिकांश प्रतिक्रियाएं लगभग तुरंत आती हैं, लेकिन कभी-कभार बातचीत कई सेकंड के लिए रुक जाती है। जब ऐसा होता है, तो उपयोगकर्ता बातचीत पर संदेह करने लगते हैं:

• क्या इसने मुझे सुना?

• क्या यह अभी भी प्रोसेसिंग कर रहा है?

• क्या मुझे अपनी बात दोहरानी चाहिए?

लेटेंसी स्वयं बातचीत का एक हिस्सा बन जाती है।

दूसरी ओर, एजेंट B थोड़ा धीमा है लेकिन लगातार प्रतिक्रियाशील है। उपयोगकर्ता प्रतिक्रिया के एक सुसंगत पैटर्न के अभ्यस्त हो जाते हैं, भले ही वह सबसे तेज़ न हो।

इसके लिए कार्यालय जाने के मार्ग (commuting) का एक उपयोगी उदाहरण लिया जा सकता है। अधिकांश लोग एक ऐसे मार्ग को चुनना पसंद करेंगे जो उन्हें लगातार 18 मिनट में काम पर पहुँचा दे, बजाय इसके कि जो आमतौर पर 12 मिनट लेता है लेकिन कभी-कभी 45 मिनट ले लेता है। औसत यात्रा भले ही कम हो, लेकिन अनिश्चितता ही निराशा पैदा करती है।

P95 ठीक इसी बात को मापता है। यह न केवल यह मापता है कि एक सिस्टम कितना तेज़ हो सकता है, बल्कि यह भी मापता है कि परिस्थितियाँ आदर्श न होने पर भी वह कितनी बार तेज़ बना रहता है।

यहाँ प्रोटोकॉल के अंतर को भी समझना ज़रूरी है। बैच एपीआई (Batch APIs) के लिए, लेटेंसी को ऑडियो भेजने से लेकर पूरा ट्रांसक्रिप्ट प्राप्त करने के कुल राउंड-ट्रिप समय के रूप में मापा जाता है। हालाँकि, स्ट्रीमिंग एपीआई (Streaming APIs) दो अलग-अलग लेटेंसी मीट्रिक पेश करते हैं: टाइम टू फर्स्ट टोकन (TTFT), जो यह मापता है कि पहला आंशिक ट्रांसक्रिप्ट कब उपलब्ध होता है, और टाइम-टू-कम्प्लीट-ट्रांसक्रिप्ट, जो यह मापता है कि अंतिम ट्रांसक्रिप्ट कब वापस मिलता है।

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

टेल लेटेंसी कठिन क्यों है

P95 के एक बेहद उपयोगी मीट्रिक होने का एक कारण यह है कि इसे P50 की तुलना में अनुकूलित (optimize) करना काफी कठिन है।

उत्पादन (production) में, अनुरोध आदर्श परिस्थितियों में एक-एक करके नहीं आते हैं। वे कंप्यूट संसाधनों के लिए प्रतिस्पर्धा करते हैं, कतारों में प्रतीक्षा करते हैं, बुनियादी ढांचे को साझा करते हैं, और अलग-अलग नेटवर्क स्थितियों का सामना करते हैं। P50 पर लगभग अदृश्य रहने वाली छोटी देरी उच्च परसेंटाइल पर संचित होने लगती है।

इस घटना का वितरित प्रणालियों (distributed systems) में व्यापक रूप से अध्ययन किया गया है। अपने प्रभावशाली पेपर द टेल एट स्केल (The Tail at Scale) में, डीन और बैरोसो ने पाया कि भले ही व्यक्तिगत घटक अत्यधिक विश्वसनीय हों, बड़े पैमाने के सिस्टम अभी भी महत्वपूर्ण टेल लेटेंसी दिखा सकते हैं क्योंकि समग्र अनुरोध में देरी करने के लिए एक अकेला धीमा घटक ही काफी होता है।

डीन और बैरोसो ने एक सरल उदाहरण के साथ इस प्रभाव को स्पष्ट किया: यदि एक एकल सर्वर में धीमी प्रतिक्रिया देने की केवल 1% संभावना है, तो 100 सर्वरों पर बिखरने वाले अनुरोध में कम से कम एक सर्वर द्वारा देरी होने की लगभग 63% संभावना होती है (1 − 0.99¹⁰⁰ ≈ 0.63)। दूसरे शब्दों में, प्रत्येक घटक व्यक्तिगत रूप से विश्वसनीय हो सकता है, लेकिन जब कई घटक एक साथ काम करते हैं, तो कम से कम एक के बाधा बनने की संभावना नाटकीय रूप से बढ़ जाती है।

वॉयस सिस्टम इस प्रभाव के प्रति विशेष रूप से संवेदनशील होते हैं।

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

यही कारण है कि P95 लेटेंसी को कम करना अक्सर P50 लेटेंसी को कम करने की तुलना में बहुत कठिन होता है। इसके लिए न केवल मॉडल, बल्कि उसके चारों ओर के पूरे सर्विंग स्टैक को अनुकूलित करने की आवश्यकता होती है।

196ms का वास्तविक अर्थ क्या है

P95 एक उपयोगी मध्य मार्ग पर स्थित है: यह उन प्रणालीगत समस्याओं को उजागर करने के लिए पर्याप्त उच्च है जिनका सामना उपयोगकर्ता वास्तव में करते हैं, फिर भी इसके अनुकूल अनुकूलन करने और विभिन्न प्रणालियों में तुलना करने के लिए पर्याप्त स्थिर है।

म्यूबेन्च के माप को जो चीज़ विशेष रूप से कठोर बनाती है, वह है इसके पीछे की कार्यप्रणाली (methodology)। लेटेंसी को उस क्षण से लेकर जब क्लाइंट अनुरोध भेजता है, उस क्षण तक की वास्तविक समय (wall-clock time) के रूप में मापा जाता है जब अंतिम ट्रांसक्रिप्ट प्राप्त होता है। यह प्रदाता-पक्षीय टेलीमेट्री या टाइम टू फर्स्ट टोकन (TTFT) पर आधारित नहीं है। अनुरोधों को एक एकल पिन किए गए AWS क्षेत्र से एक-एक करके क्रमिक रूप से निष्पादित किया जाता है। यह एक महत्वपूर्ण अंतर है क्योंकि समानांतर (parallelized) या थोक माप कृत्रिम रूप से टेल लेटेंसी को संकुचित कर सकते हैं। एक समय में एक ही अनुरोध की समवर्तीता (concurrency of one) लागू करके, म्यूबेन्च यह सुनिश्चित करता है कि रिपोर्ट की गई P95 उस लेटेंसी को अधिक बारीकी से दर्शाती है जिसका अनुभव एक वास्तविक एकीकरण उत्पादन में करेगा।

वॉयस एआई में, उपयोगकर्ता प्रणालियों का आकलन औसत के आधार पर नहीं करते हैं। वे उनका आकलन इस आधार पर करते हैं कि बातचीत स्वाभाविक और त्वरित लगती है या नहीं। यह अंततः टेल लेटेंसी पर निर्भर करता है और यह मायने रखता है कि उस टेल को कितनी सावधानी से मापा जाता है।