चयनात्मक विशेषज्ञता: ऐसे एजेंट्स कैसे बनाएं जो प्रोडक्शन में टिके रहें

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

बॉटलनेक: एक एजेंट सब कुछ कर रहा है

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

यही सोच बॉटलनेक बनाती है। जब एक ही एजेंट व्यापक दायरे में योजना बनाने, काम करने, याद रखने और समीक्षा करने की ज़िम्मेदारी संभालता है, तो कई चीज़ें एक साथ बिगड़ने लगती हैं।

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

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

नियामक उद्योग में, यह सिर्फ़ खराब अनुभव नहीं है—यह ज़िम्मेदारी से जुड़ी एक अनुपालन घटना है। यही एक वजह है कि एजेंट का बीमा योग्य होना प्रोडक्शन डिप्लॉयमेंट के लिए एक पूर्वशर्त बनता जा रहा है, और हमने ElevenAgents को पहला कन्वर्सेशनल AI प्लेटफ़ॉर्म बनाया है जो AIUC के ज़रिए AI बीमा के लिए योग्य है।

ध्यान दें कि असल में क्या विफल हुआ। एजेंट बातचीत में खराब नहीं था। वह हर ज़िम्मेदारी अकेले संभालने में खराब था, क्योंकि किसी बात को समझने और उस पर कार्रवाई करने के बीच कोई जांच बिंदु नहीं था। समाधान न तो कम महत्वाकांक्षा है, न ही शांत एजेंट। समाधान है सही संरचना।

यहां सटीक होना ज़रूरी है। यह मुख्य रूप से मॉडलों की अपनी सीमा नहीं है। अधिक शक्तिशाली मॉडल क्षमता बढ़ाता है, लेकिन संरचनात्मक समस्या दूर नहीं करता। यह सिस्टम डिज़ाइन की समस्या है।

मानसिक मॉडल: विभाग, न कि हर फैसला लेने वाला CEO

सोचिए कि एक कंपनी कैसे बढ़ती है। अगर CEO खुद इंजीनियरिंग, मार्केटिंग और HR के हर फैसले ले, तो कंपनी ठहर जाएगी। इसका समाधान ज़्यादा समझदार CEO रखना नहीं है। समाधान है स्पष्ट दायरे वाली विशेषज्ञ टीम्स बनाना।

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

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

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

वास्तविक समझौते

मल्टी-एजेंट कोई मुफ़्त लाभ नहीं है। इस आर्किटेक्चर का मूल्यांकन करने वाले किसी भी तकनीकी लीडर को इसे अपनाने से पहले समन्वय की लागत की गहराई से जांच करनी चाहिए—और वह करेगा भी। सबसे महत्वपूर्ण चेतावनी यह है।

सबसे आम विफलता कॉन्टेक्स्ट का बिखराव है। जब आप किसी काम को ऐसे एजेंट्स में बांटते हैं जो पूरा कॉन्टेक्स्ट साझा नहीं करते, तो हर एजेंट अधूरी जानकारी के आधार पर काम करता है और उनके फैसले ऐसे टकरा सकते हैं जिन्हें कोऑर्डिनेटर सुलझा नहीं सकता।

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

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

व्यावहारिक निष्कर्ष यह है कि चुनाव काम पर निर्भर करता है। मल्टी-एजेंट समानांतर, पढ़ने-प्रधान काम में बेहतर है, जहां हिस्से वास्तव में स्वतंत्र हों—जैसे रिसर्च, रिट्रीवल और वेरिफ़िकेशन। यह ऐसे घनिष्ठ रूप से जुड़े काम में संघर्ष करता है जहां हर चीज़ का एकसाथ सुसंगत होना ज़रूरी हो, जैसे एक कोडबेस लिखना। रियल-टाइम वॉइस पाइपलाइन जैसे लेटेंसी-संवेदनशील काम में हर अतिरिक्त एजेंट हॉप सीमित समय बजट में राउंड-ट्रिप समय जोड़ता है, इसलिए एजेंट्स की गहरी चेन डिफ़ॉल्ट रूप से जोखिम भरी होती हैं। यहीं हमारा इन्फ्रास्ट्रक्चर भी मायने रखता है। ElevenAgents स्पीच रिकग्निशन, टर्न-टेकिंग और वॉइस जनरेशन को एक ही स्टैक में को-लोकेट करता है, इसलिए ऑर्केस्ट्रेशन ओवरहेड जुड़ने से पहले ही बेसलाइन लेटेंसी न्यूनतम होती है।

वास्तव में ROI किससे मिलता है

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

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

सुझाव

आने वाले प्रोजेक्ट में पहले आर्किटेक्चर चुनना सही कदम नहीं है। पहले काम का नक्शा बनाइए।

उन खास क्षमताओं की सूची बनाइए जिनकी सिस्टम को वास्तव में ज़रूरत है। चिह्नित करें कि कौन से हिस्से सचमुच स्वतंत्र हैं और कौन से आपस में घनिष्ठ रूप से जुड़े हैं। पहचानें कि कहां अलग कॉन्टेक्स्ट एक जोखिम नहीं, बल्कि सुविधा है—जैसे तथ्यों की जांच का वह चरण जिसे आप मुख्य रीजनिंग थ्रेड से अलग रखना चाहते हैं। फिर, और केवल तभी, तय करें कि ज़िम्मेदारियों को अलग एजेंट्स में कहां बांटना है।

प्रोडक्शन में लोन रिमाइंडर लाइन के लिए यह ऐसा दिखता है। लाइव बातचीत एक ही सतत एजेंट में रहती है, क्योंकि ग्राहक के शब्द, टोन और बातचीत का आदान-प्रदान आपस में घनिष्ठ रूप से जुड़े हैं, और हर अतिरिक्त हॉप ऐसी देरी जोड़ता है जिसे कॉलर सुन सकता है। उस एक कन्वर्सेशनल कोर के आसपास, आप सीमित दायरे वाले विशेषज्ञ जोड़ते हैं जो प्रवाह में बाधा नहीं डालते: अकाउंट और बकाया राशि लाने वाली टूल कॉल, किसी भी भुगतान ऑफ़र को बोलने से पहले एजेंट द्वारा देखी जाने वाली अनुपालन गार्डरेल, स्थिति की मांग होने पर किसी इंसान को साफ़ ट्रांसफ़र, और अगली सुबह गुणवत्ता व जोखिम के लिए रिकॉर्डिंग्स को स्कोर करने वाले मूल्यांकन एजेंट्स का अलग बैच।

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

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