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

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

अड़चन: एक एजेंट का सब कुछ करना

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

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

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

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

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

ध्यान दें कि असल में क्या टूटा। एजेंट बातचीत में खराब नहीं था। वह हर ज़िम्मेदारी अकेले उठाने में खराब था—किसी बात को समझने और उस पर कार्रवाई करने के बीच कोई चेकपॉइंट नहीं था। समाधान छोटे लक्ष्य या शांत एजेंट में नहीं है। समाधान संरचना में है।

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

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

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

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

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

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

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

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

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

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

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

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

ROI को वास्तव में क्या बढ़ाता है

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

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

सुझाव

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

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

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

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

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