AI प्रोडक्ट बनाते समय अलग-अलग फ़ैसलों के असर पर नज़र रखना

• ज़्यादा मेट्रिक्स से हमेशा तस्वीर साफ़ नहीं होती. कई डैशबोर्ड्स में एक ही तरह के व्यवहार को अलग-अलग तरीकों से मापा जाता है. मेट्रिक्स तब ज़्यादा काम के होते हैं जब उन्हें ऐसे जोड़ों में देखा जाए जहाँ एक को बेहतर करने से दूसरे पर असर पड़ सकता है, जैसे खर्च और क्वालिटी, कंटेनमेंट और कस्टमर सेंटिमेंट, या एक्यूरेसी और लेटेंसी.

• AI प्रोडक्ट के पायलट से प्रोडक्शन तक पहुँचने के साथ, सही मेट्रिक के जोड़े भी बदलते हैं. हर स्टेज पर वही चीज़ें मापनी चाहिए जो उस समय टीम के फ़ैसलों में काम आएँ.

• ऑपरेशन्स की मॉनिटरिंग और स्ट्रैटेजिक मेज़रमेंट का मकसद अलग होता है. टीमें सिस्टम के सैकड़ों सिग्नल्स ट्रैक कर सकती हैं, लेकिन प्रोडक्ट से जुड़े फ़ैसलों के लिए कुछ अहम मेट्रिक जोड़े ही काफ़ी हो सकते हैं.

बड़े मेट्रिक्स तस्वीर को अच्छा दिखा सकते हैं, लेकिन फिर भी प्रोडक्ट के किसी अहम फ़ैसले का जवाब अधूरा रह सकता है.

Klarna के AI असिस्टेंट के साथ ज़्यादा काम करने की क्षमता, कम खर्च और ह्यूमन एजेंट्स के बराबर कस्टमर सैटिस्फ़ैक्शन स्कोर जैसी बातें सामने आई थीं. अगले साल कंपनी ने ह्यूमन सपोर्ट तक एक्सेस बढ़ाने का फ़ैसला किया. उसके चीफ़ एग्ज़ीक्यूटिव ने भी माना कि खर्च कम करने पर ज़रूरत से ज़्यादा फ़ोकस किया गया था.

इसका मतलब AI असिस्टेंट या उसकी टेक्नोलॉजी को छोड़ना नहीं था. प्रोडक्ट को असल में इस्तेमाल करने से जो सीख मिली, उसके आधार पर कंपनी ने ऑटोमेशन और ह्यूमन सर्विस के बीच बैलेंस बदला. जैसे-जैसे ऑटोमेशन ने हाई-वॉल्यूम, आसान क्वेरीज़ संभालना शुरू किया, Klarna को ऐसे ह्यूमन एजेंट्स की जरूरत थी जो जटिल, संवेदनशील मामलों को संभालने के लिए तैयार हों.

शुरुआत में यह तय करने के बाद कि प्रोडक्ट से क्या हासिल करना है, AI प्रोडक्ट बनाने वाली ज़्यादातर ऑर्गेनाइज़ेशन्स के सामने आखिर में एक ही सवाल आता है: क्या यह सच में काम कर रहा है?

अगर जवाब साफ़ न हो, तो अक्सर पहला कदम और मेट्रिक्स जोड़ना होता है. तीन से 10 और फिर 10 से 30. डैशबोर्ड में डेटा बढ़ता जाता है, लेकिन ज़रूरी नहीं कि टीम की समझ भी उतनी ही बढ़े.

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

इसलिए AI टीमों को सिर्फ़ ऐसे मेट्रिक्स नहीं देखने चाहिए जो एक ही दिशा में जाते हैं. उन्हें ऐसे मेट्रिक्स भी चुनने चाहिए जो अलग-अलग नतीजों के बीच के खींचतान दिखाएँ. ऐसे मेट्रिक्स के जोड़े यह समझने और ट्रैक करने में मदद करते हैं कि एक चीज़ बेहतर करने पर दूसरी पर क्या असर पड़ रहा है. इससे बेहतर फ़ैसले लिए जा सकते हैं.

लॉन्च से पहले एक डिप्लॉयमेंट में, एक जॉइंट टीम कस्टमर की ओर से आने वाली सपोर्ट कॉल्स के लिए रियल-टाइम AI वॉइस एजेंट बना रही थी. सबसे मुश्किल सवाल मॉडल चुनने या ऑर्केस्ट्रेशन का नहीं था. सवाल यह था कि जब बड़ी संख्या में कस्टमर्स इसका इस्तेमाल करने लगेंगे, तो ऑर्गेनाइज़ेशन कैसे जानेगा कि प्रोडक्ट सही तरह से काम कर रहा है या नहीं.

शुरुआत में तीन मेट्रिक्स इस्तेमाल किए गए:

• कंटेनमेंट रेट: AI कितनी बार कॉल्स को अपने दम पर सुलझाता है, बिना किसी इंसान के पास ट्रांसफ़र किए.

• एस्केलेशन रेट: इंसानी एजेंटों के पास कॉल कितनी बार ट्रांसफ़र की जाती है.

• फ़ुलफ़िलमेंट रेट: कितनी बार कस्टमर की समस्या सुलझाई जाती है.

हर मेट्रिक अपने आप में ठीक था. लेकिन इन्हें साथ देखने पर भी एक सीधा सवाल अनसुलझा था: अगर एस्केलेशन बढ़ता है, तो उससे हमें क्या पता चलता है?

टीम ने एस्केलेशन को आठ ग्रुप में बाँटा. इसके बाद कॉल को बीच में छोड़ने, कस्टमर के अनुभव, समय, भाषा समझने के स्कोर और अलग-अलग तरह की क्वेरी के फ़ुलफ़िलमेंट से जुड़े मेट्रिक्स जोड़े गए. आखिर में फ़्रेमवर्क में छह कैटेगरी के कुल 31 मेट्रिक्स हो गए.

इससे एस्केलेशन के बारे में काफ़ी जानकारी मिलती थी, लेकिन इसकी वजह के बारे में पक्के तौर पर कुछ पता नहीं चलता था. ज़्यादातर मेट्रिक्स एक ही तरह के व्यवहार को अलग-अलग तरीके से दिखा रहे थे. इसलिए वे साथ-साथ बदलते थे और अलग-अलग संभावित वजहों को टेस्ट नहीं कर पाते थे.

डैशबोर्ड सिर्फ़ यह दिखा रहा था कि क्या हो रहा है, लेकिन यह नहीं बता पा रहा था कि ऐसा क्यों हो रहा है.

टीम को और ज़्यादा हिस्सों में डेटा बाँटने की ज़रूरत नहीं थी. उसे ऐसे मेट्रिक्स चाहिए थे जिनमें एक को बेहतर करने का असर दूसरे पर दिखाई दे.

इन्हें हम एक-दूसरे को नुकसान पहुँचाने वाले जोड़े कहते हैं: ये दो ऐसे मेट्रिक्स होते हैं जहाँ सिर्फ़ एक को बेहतर करने पर दूसरे से जुड़ा नतीजा खराब हो सकता है. यह नाम उस समस्या को बताता है जो सिर्फ़ एक तरफ़ फ़ोकस करके ऑप्टिमाइज़ करने से पैदा हो सकती है. यह कोई मनचाही स्थिति नहीं है.

जब दोनों मेट्रिक्स अच्छे स्तर पर बने रहें, तो प्रोडक्ट सही बैलेंस के साथ काम कर रहा हो सकता है. जब दोनों अलग-अलग दिशा में जाने लगें, तो इससे टीम को समझ आता है कि कहाँ जाँच करनी चाहिए.

इसे और अच्छे से समझने के लिए एस्केलेशन रेट और एस्केलेशन होने में लगने वाले समय को देखें. असली कॉल्स आने से पहले टीम यह नहीं जान सकती कि कस्टमर्स कैसे व्यवहार करेंगे, लेकिन वह पहले से तय कर सकती है कि किन बातों को टेस्ट करना है.

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

एस्केलेशन का कुल नंबर वही हो सकता है, लेकिन प्रोडक्ट से जुड़ा फ़ैसला अलग होगा.

एक अच्छा मेट्रिक जोड़ा अपने आप वजह साबित नहीं करता. लेकिन यह जाँच का दायरा छोटा करता है और अगला फ़ैसला लेना आसान बनाता है.

पहले दिया गया Klarna का उदाहरण दिखाता है कि जब खर्च और सर्विस क्वालिटी एक-दूसरे पर असर डालते हैं, तो यह तरीका कैसे काम करता है. यह भी दिखाता है कि कंपनी ट्रेड-ऑफ़्स का असर ट्रैक करके और अपने AI डिप्लॉयमेंट से सीखकर अपने ऑपरेटिंग मॉडल को कैसे बदल सकती है.

फ़रवरी 2024 में कंपनी ने बताया कि उसके AI असिस्टेंट ने पहले महीने में 23 लाख बातचीत संभालीं, 700 फ़ुल-टाइम एजेंट्स के बराबर काम किया और कस्टमर सैटिस्फ़ैक्शन के स्कोर इंसानी एजेंटों के बराबर रहे. Klarna का अनुमान था कि 2024 में यह असिस्टेंट मुनाफ़े में $4 करोड़ का सुधार ला सकता है. ये नतीजे Klarna ने खुद रिपोर्ट किए थे, किसी अलग इवैल्यूएशन से नहीं आए थे.

मई 2025 में Klarna के चीफ़ एग्ज़ीक्यूटिव ने कहा कि कंपनी ने कस्टमर सर्विस में खर्च कम करने पर ज़रूरत से ज़्यादा फ़ोकस किया था. उन्होंने ह्यूमन सपोर्ट का एक्सेस बढ़ाने की प्लानिंग भी बताई. इसका मतलब AI असिस्टेंट या उसकी टेक्नोलॉजी को छोड़ना नहीं था, बल्कि ऑटोमेटेड और इंसानी सर्विस के बीच बैलेंस बदलना था.

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

दोनों पहलुओं को साथ ट्रैक करने से कंपनी समझ सकती है कि ऑटोमेशन कहाँ फ़ायदा दे रहा है, कहाँ इंसानी सपोर्ट अब भी ज़रूरी है, और नई जानकारी मिलने पर दोनों के बीच बैलेंस कैसे बदलना चाहिए.

AI प्रोडक्ट्स में एक-दूसरे पर असर डालने वाले दूसरे मेट्रिक जोड़े ये हो सकते हैं:

मकसद दोनों मेट्रिक्स को लगातार बढ़ाना नहीं है. मकसद यह है कि सिर्फ़ एक चीज़ बेहतर करने की वजह से ऑपरेशन्स में समस्या आने से पहले ट्रेड-ऑफ़ साफ़ दिख जाए.

ऐसी ही एक समस्या मोबाइल गेम्स कंपनी के प्लेयर-सपोर्ट डिप्लॉयमेंट में सामने आई. सिस्टम बड़ी संख्या में आने वाले मामलों को संभालता था, जैसे गेम की प्रोग्रेस खो जाना, पेमेंट से जुड़ी शिकायतें और अकाउंट एक्सेस.

सिस्टम बड़े स्तर पर चल रहा था, इसलिए एफ़िशिएंसी मेट्रिक्स ज़रूरी थे. लेकिन प्लेयर सपोर्ट सिर्फ़ टिकट्स की लाइन नहीं है. प्लेयर्स अक्सर पहले से परेशान होते हैं, क्योंकि उनके गेमिंग एक्सपीरियंस में कुछ गलत हो चुका होता है.

इस वजह से कस्टमर सैटिस्फ़ैक्शन डेटा को देखने का तरीका बदल जाता है. किसी प्लेयर की समस्या सही तरह से सुलझ जाने के बाद भी वह कम सैटिस्फ़ैक्शन दे सकता है, क्योंकि उसकी प्रोग्रेस पहले ही खो चुकी थी. अगर यह कॉन्टेक्स्ट न देखा जाए, तो पहले हुई परेशानी का असर सपोर्ट इंटरैक्शन के स्कोर पर पड़ सकता है.

इसलिए टीम को यह अलग करके देखना था कि कस्टमर शुरुआत में कैसा महसूस कर रहा था और सपोर्ट इंटरैक्शन के बाद क्या बदला. बेहतर सवाल यह नहीं था, "क्या प्लेयर खुश था?" बल्कि यह था, "क्या इस बातचीत के बाद उसकी स्थिति पहले से बेहतर हुई?"

अगर टीम दोनों चीज़ों को सही तरह से माप सके, तो इस तुलना से पता चल सकता है कि परेशानी प्रोडक्ट की वजह से थी या सपोर्ट की क्वालिटी की वजह से.

AI प्रोडक्ट्स बदलते रहते हैं, लेकिन उनके मेट्रिक्स अक्सर वही रहते हैं.

पायलट के दौरान मुख्य सवाल यह हो सकता है कि क्या सिस्टम इतना भरोसेमंद है कि उसमें आगे इन्वेस्ट करना सही हो:

• क्या यह मुख्य टास्क भरोसे के साथ पूरा करता है?

• क्या यूज़र्स इस पर इतना भरोसा करते हैं कि इसका इस्तेमाल जारी रखें?

• आम स्थितियों से बाहर यह कैसे काम करता है?

• क्या गड़बड़ी को पहचाना और सही तरीके से संभाला जा सकता है?

इन सवालों के लिए ऐसे मेट्रिक जोड़े काम आ सकते हैं:

• मुख्य टास्क की सफलता ↔ दुर्लभ मामलों में परफ़ॉर्मेंस;

• ऑटोमेशन रेट ↔ कितनी बार इंसान AI का फ़ैसला बदलता है; और

• टास्क पूरा होने की स्पीड ↔ यूज़र का भरोसा.

जब प्रोडक्ट रोज़ के ऑपरेशन्स के लिए अहम हो जाता है, तो सवाल बदल जाते हैं:

• क्या इसे बड़े स्तर पर चलाया जा सकता है, बिना क्वालिटी कम किए?

• क्या ज़्यादा इस्तेमाल के साथ इसका खर्च और फ़ायदे का हिसाब बेहतर होता है?

• इस्तेमाल बढ़ने पर भी क्या परफ़ॉर्मेंस स्थिर रहती है?

• क्या सही जगहों पर इंसानी सपोर्ट लिया जा रहा है?

आगे चलकर ये मेट्रिक जोड़े इस तरह बदल सकते हैं:

• हर इंटरैक्शन का खर्च ↔ आउटपुट की परखी गई क्वालिटी;

• कितने लोग इस्तेमाल कर रहे हैं ↔ वे कितना ज़्यादा इस्तेमाल कर रहे हैं; और

• ऑटोमेशन रेट ↔ ऑपरेशनल रिस्क कितना बढ़ रहा है.

शुरुआती मेट्रिक्स ज़रूरी नहीं कि गलत हों. वे उन सवालों के जवाब देते हैं जो उस समय ज़रूरी थे.

समस्या तब आती है जब प्रोडक्ट आगे बढ़ता है. पायलट के मेट्रिक्स अक्सर चलते रहते हैं क्योंकि टीमों को उनकी रिपोर्टिंग की आदत होती है और उन्हें बंद करने का फ़ैसला किसी एक की ज़िम्मेदारी नहीं होती. जो मेट्रिक्स कभी सीखने में मदद करते थे, वे धीरे-धीरे सिर्फ़ अच्छे नंबर दिखाने वाले मेट्रिक्स बन सकते हैं.

इसलिए इन मेट्रिक जोड़ों की भी एक लाइफ़साइकल होनी चाहिए. टीमों को इन्हें किसी खास फ़ैसले के लिए इस्तेमाल करना चाहिए, समय-समय पर देखना चाहिए कि क्या ये अब भी अहम ट्रेड-ऑफ़ दिखा रहे हैं, और प्रोडक्ट या फ़ैसला बदलने पर इन्हें हटा देना चाहिए.

AI सिस्टम्स के लिए बारीकी से निगरानी, अलर्ट्स, क्वालिटी की जाँच और इवैल्यूएशन ज़रूरी हैं. इन सिग्नल्स को हटाने से प्रोडक्ट को सुरक्षित तरीके से चलाना मुश्किल हो जाएगा. लेकिन रोज़ के ऑपरेशन्स की निगरानी और लीडरशिप के लिए इस्तेमाल होने वाले मेट्रिक्स एक ही चीज़ नहीं हैं.

निगरानी से टीमों को समस्याएँ पकड़ने, गड़बड़ी कहाँ हुई यह समझने और सिस्टम के व्यवहार को जानने में मदद मिलती है. वहीं, डिसिज़न मेट्रिक्स से प्रोडक्ट और बिज़नेस लीडर्स यह तय कर सकते हैं कि कहाँ और इन्वेस्ट करना है, कहाँ बदलाव करना है, कब दिशा बदलनी है या कब किसी ट्रेड-ऑफ़ को स्वीकार करना है.

कोई ऑर्गेनाइज़ेशन सैकड़ों टेक्निकल और ऑपरेशनल सिग्नल्स ट्रैक कर सकता है, लेकिन किसी प्रोडक्ट से जुड़े किसी खास फ़ैसले के लिए सिर्फ़ दो या तीन ऐसे मेट्रिक जोड़ों पर फ़ोकस कर सकता है जो एक-दूसरे पर असर डालते हैं. इस लेयर को छोटा रखने से यह तय करना आसान होता है कि सबसे पहले किस पर ध्यान देना है.

कितनी बार रिव्यू करना चाहिए, यह प्रोडक्ट पर निर्भर करता है. नए या तेज़ी से बदलते सिस्टम को हर हफ़्ते रिव्यू करना पड़ सकता है, जबकि एक मैच्योर प्रोडक्ट के लिए महीने या तिमाही में एक बार काफ़ी हो सकता है. अहम बात यह है कि इन मेट्रिक्स को इतनी बार ज़रूर देखें कि ट्रेड-ऑफ़ महँगा या अनसेफ़ होने से पहले ऐक्शन लिया जा सके.

किसी मेट्रिक का जोड़ा तभी काम का है, जब ऑर्गेनाइज़ेशन पहले से तय करे कि उसके खराब होने पर क्या करना है.

सिर्फ़ यह तय कर देना काफ़ी नहीं है कि कितना अंतर बढ़ने पर समस्या मानी जाएगी. टीमों को तीन स्थितियाँ देखनी चाहिए:

• पूरी तरह से फ़ेल: कोई एक मेट्रिक तय लिमिट से ज़्यादा खराब हो जाए, चाहे दूसरा कैसा भी हो.

• दोनों में अंतर बढ़ना: एक मेट्रिक बेहतर हो, लेकिन दूसरा खराब होने लगे.

• दोनों का खराब होना: दोनों मेट्रिक्स खराब हों, जो प्रोडक्ट या ऑपरेशन्स की बड़ी समस्या का संकेत हो सकता है.

हर मेट्रिक जोड़े के लिए ये चीज़ें तय होनी चाहिए:

• किसी पर तय ज़िम्मेदारी;

• यह किस फ़ैसले में मदद करेगा;

• पहले से तय लिमिट्स या परखने की कसौटी;

• जाँच का साफ़ तरीका; और

• कौन-कौन से ऐक्शन लिए जा सकते हैं.

इनके बिना ऑर्गेनाइज़ेशन सिर्फ़ प्रोडक्ट को देख रहा है, उसे सही मायने में मैनेज नहीं कर रहा.

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

1. इन मेट्रिक्स से हमें कौन-सा फ़ैसला लेने में मदद चाहिए?

साफ़ तय करें: क्या हमें ऑटोमेशन बढ़ाना है, मॉडल बदलना है, या इंसानों को किया जाने वाला हैंडओवर बेहतर करना है? मेट्रिक्स चुनने से पहले यह फ़ैसला करें.

2. अगर यह नंबर बेहतर होता है, तो क्या खराब हो सकता है?

तय करें कि किस नतीजे को खराब होने से बचाना है और कौन-सा मेट्रिक उस नुकसान को दिखाएगा. उदाहरण के लिए, हर इंटरैक्शन के खर्च को आउटपुट की परखी गई क्वालिटी के साथ देखें, ताकि पता चले कि सस्ते जवाब अब भी काम के हैं या नहीं.

3. ऊपर से अच्छे दिखने वाले नंबर क्या छिपा सकते हैं?

दोनों मेट्रिक्स को उन्हीं यूज़र्स, टास्क्स और उसी समय की अवधि के लिए देखें. फिर देखें कि किन ग्रुप्स को खराब नतीजे मिल रहे हैं. शुरुआत की स्थिति भी देखें. अगर लोग कम खुश हैं, तो उसकी वजह ऐसी नाराज़गी भी हो सकती है जो सपोर्ट टीम से बात करने से पहले ही मौजूद थी.

4. किस स्थिति में हमें ऐक्शन लेना चाहिए और इसकी ज़िम्मेदारी किसकी होगी?

पहले से तय करें कि कब ऐक्शन लेना है: जब कोई मेट्रिक तय लिमिट पार करे, एक बेहतर हो और दूसरा खराब हो, या दोनों खराब हों. यह भी तय करें कि जाँच कौन करेगा, सबसे पहले क्या देखेगा और कब अपडेट देगा.

5. क्या यह मेट्रिक जोड़ा अब भी प्रोडक्ट के मौजूदा स्टेज के लिए सही है?

तय करें कि इसे जारी रखना है, बदलना है या हटाना है. पायलट में फ़ोकस इस बात पर हो सकता है कि टास्क भरोसे के साथ पूरा हो रहा है या नहीं और यूज़र का भरोसा कैसा है. लाइव सर्विस में खर्च और क्वालिटी को ज़्यादा ध्यान से देखना पड़ सकता है. इस फ़ैसले को दोबारा देखने की तारीख भी तय करें.

AI प्रोडक्ट मेट्रिक्स का काम सिर्फ़ परफ़ॉर्मेंस दिखाना नहीं होना चाहिए. उन्हें यह भी साफ़ करना चाहिए कि ऑर्गेनाइज़ेशन किन ट्रेड-ऑफ़्स के साथ काम कर रहा है और अगला फ़ैसला क्या होना चाहिए.