ElevenAgent के ऑर्केस्ट्रेशन इंजन की गहराई से समझ

ElevenAgents को रीयल-टाइम बातचीत के लिए खास तौर पर बनाए गए कम-लेटेंसी ऑर्केस्ट्रेशन इंजन से शक्ति मिलती है, जो 100ms से कम ओवरहेड जोड़ता है। यह आर्किटेक्चर ElevenLabs के बेहतरीन रिसर्च को OpenAI, Google और Anthropic जैसे प्रमुख प्रदाताओं के अत्याधुनिक LLMs, साथ ही ElevenLabs पर होस्ट किए गए चुनिंदा ओपन-सोर्स मॉडल्स के साथ जोड़ता है। जवाब पाइपलाइन के अलग-अलग चरणों में कई मॉडल्स का उपयोग करके, एजेंट बातचीत को तेज़ी से प्रतिक्रिया देने वाली और संदर्भ-सजग बनाता है। हर मॉडल की खूबियों को साथ मिलाकर इस्तेमाल करने से हम बुद्धिमत्ता, गति और लागत का संतुलन बनाए रखते हुए, कई एंटरप्राइज़ कार्यों और बातचीत के परिदृश्यों में भरोसेमंद, स्केलेबल प्रदर्शन हासिल करते हैं।

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

स्वतंत्र एजेंट 

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

ElevenLabs में स्वतंत्र एजेंटों के लिए यह समझना महत्वपूर्ण है कि वे कैसे:

• प्रभावी जनरेशन रिक्वेस्ट बनाते हैं
• प्रासंगिक दस्तावेज़ खोजकर शामिल करते हैं
• एजेंट के जवाबों के लिए टूल कॉल जनरेट और एक्ज़ीक्यूट करते हैं
• मूल्यांकन और डेटा कलेक्शन के लिए नतीजे आउटपुट करते हैं

बातचीत का संदर्भ बनाना 

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

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

हालांकि, रिट्रीवल बाहरी सिस्टम्स के साथ एजेंटों के इंटरैक्शन का सिर्फ एक तरीका है।

टूल्स से कार्रवाई करना और जानकारी पाना

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

• के लिए टूल विवरण lookup_order: “ऑर्डर ID से ग्राहक के ऑर्डर की जानकारी पाता है। ऑर्डर की स्थिति, खरीदे गए आइटम, शिपिंग पता और ट्रैकिंग नंबर लौटाता है।”
• सिस्टम प्रॉम्प्ट निर्देश: “ग्राहक की पहचान सत्यापित करने के बाद, उसके ऑर्डर की जानकारी पाने के लिए lookup_order टूल कॉल करें।”

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

• बाहरी APIs को कॉल करने वाले वेबहुक टूल्स।
• कन्वर्सेशन websocket के ज़रिए इवेंट्स के रूप में टूल रिक्वेस्ट भेजने वाले क्लाइंट टूल्स।
• कॉल ट्रांसफ़र जैसी बिल्ट-इन कार्रवाइयों के लिए सिस्टम टूल्स।
• इनसे कनेक्ट होने वाले MCP टूल्स: मॉडल कॉन्टेक्स्ट प्रोटोकॉल सर्वर्स।

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

यह बताता है कि टूल्स एजेंट के तर्क में कैसे शामिल होते हैं, लेकिन उनके एक्ज़ीक्यूशन का समय भी कॉन्फ़िगर किया जा सकता है। टूल्स तीन एक्ज़ीक्यूशन मोड्स में से किसी एक में चल सकते हैं, और हर मोड अलग बातचीत की जरूरत के लिए उपयुक्त है। Immediate Mode में, LLM के अनुरोध करते ही टूल एक्ज़ीक्यूट हो जाता है। यह तेज़ लुकअप्स के लिए डिफ़ॉल्ट है, जहां यूज़र्स लगभग तुरंत जवाब चाहते हैं, जैसे ऑर्डर स्टेटस जांचना। प्री-टूल स्पीच के साथ, एजेंट पहले “मैं आपके लिए यह जांचता हूं” जैसी छोटी स्वीकृति जनरेट करता है और टूल के समानांतर चलने के दौरान उसे यूज़र को भेजता है, जिससे खामोशी कम होती है। धीमे टूल्स के लिए, प्लेटफ़ॉर्म अपेक्षित प्रतीक्षा समय के अनुसार इन फ़िलर संदेशों को अपने-आप बढ़ा देता है। इसके विपरीत, Post-Tool Speech Mode में एजेंट के बोलना खत्म करने तक एक्ज़ीक्यूशन में देरी होती है। कॉल ट्रांसफ़र करने, सेशन खत्म करने या पेमेंट सबमिट करने जैसी वास्तविक परिणाम वाली कार्रवाइयों के लिए यह जरूरी है। यूज़र को “मैं अब आपको बिलिंग टीम से जोड़ने वाला हूं” जैसा पूरा संदर्भ सुनाई देता है और कार्रवाई से पहले उसे बीच में बोलने का मौका मिलता है। Async Mode बातचीत रोके बिना टूल को पूरी तरह बैकग्राउंड में चलाता है। यह ईमेल भेजने, बाहरी वर्कफ़्लो ट्रिगर करने या डेटा लॉग करने जैसी fire-and-forget कार्रवाइयों के लिए सबसे उपयुक्त है, जहां एजेंट को अपने जवाब में नतीजे का उल्लेख नहीं करना होता।

एक्ज़ीक्यूशन और ऑर्केस्ट्रेशन के बाद, अगला कदम प्रदर्शन मापना समझना है।

प्रदर्शन मापना

एजेंट के साथ कॉल पूरी होने के बाद, आप आगे के विश्लेषण और स्टोरेज के लिए कॉल से कुछ जानकारी निकालना चाह सकते हैं या यह तय करना चाह सकते हैं कि कॉल सफल थी या नहीं। यहीं डेटा कलेक्शन और मूल्यांकन मानदंड काम आते हैं। डेटा कलेक्शन आपको आगे के विश्लेषण और एग्रीगेशन के लिए कॉल ट्रांसक्रिप्ट से संरचित जानकारी निकालने देता है। ग्राहक अक्सर रिपोर्टिंग या एनरिचमेंट वर्कफ़्लोज़ के लिए इन आउटपुट्स को अपने एंटरप्राइज़ डेटा लेकहाउस में एक्सपोर्ट करते हैं। उदाहरण के लिए, Sales Development Agent बातचीत से संभावित ग्राहक की जानकारी अपने-आप निकालकर Customer Relationship Management (CRM) सिस्टम में लीड बना या अपडेट कर सकता है। दूसरी ओर, मूल्यांकन मानदंड तय करते हैं कि कॉल सफल मानी जाए या नहीं। सभी कॉन्फ़िगर किए गए मानदंड पूरे होने पर कॉल सफल मार्क होती है; अन्यथा उसे असफल के रूप में फ़्लैग किया जाता है। इससे बातचीत लगातार गुणवत्ता और अखंडता के तय मानकों पर खरी उतरती है और तेज़ फ़ीडबैक मिलता है। कॉल समाप्त होने और पोस्ट-कॉल वेबहुक ट्रिगर होने पर, एजेंट सभी कॉन्फ़िगर किए गए डेटा कलेक्शन पॉइंट्स और मूल्यांकन मानदंडों के साथ, टूल एक्ज़ीक्यूशन व मेटाडेटा सहित अंतिम ट्रांसक्रिप्ट को LLM से प्रोसेस करता है। मॉडल इस संयुक्त प्रॉम्प्ट से तय करता है कि प्रत्येक मूल्यांकन मानदंड पूरा हुआ है या नहीं, और आगे के विश्लेषण के लिए निर्दिष्ट डेटा पॉइंट्स निकालता है। LLM इन कॉन्फ़िगरेशंस को अपने इनपुट प्रॉम्प्ट के हिस्से के रूप में सीधे समझता है, इसलिए उन्हें स्पष्ट और एकसमान रूप से फ़ॉर्मैट करना जरूरी है। इसलिए हम मूल्यांकन मानदंड और डेटा कलेक्शन विवरण लिखने के लिए ये सर्वोत्तम तरीके सुझाते हैं।

मूल्यांकन मानदंड

1. हर मानदंड के लिए एक स्पष्ट लक्ष्य: एक मानदंड में कई लक्ष्यों के बजाय एक वाक्य या छोटा बुलेट बेहतर है। 
2. देखा जा सकने वाला और ट्रांसक्रिप्ट-आधारित: लक्ष्य को इस तरह लिखें कि सफलता/असफलता का निर्णय ट्रांसक्रिप्ट से हो सके—क्या कहा गया, एजेंट ने क्या किया, यूज़र ने क्या पूछा। ऐसे लक्ष्यों से बचें जिनके लिए ऐसे बाहरी संदर्भ की जरूरत हो जो LLM के पास नहीं है।
3. स्पष्ट सफलता/असफलता/अज्ञात नतीजे: LLM के पास पहले से यह संदर्भ होता है कि लक्ष्य पूरा होने पर सफल, पूरा न होने पर असफल और ट्रांसक्रिप्ट से पता न चलने पर अज्ञात मार्क करना है। इसलिए लक्ष्य इस तरह लिखें कि “पूरा हुआ” और “पूरा नहीं हुआ” साफ़ तौर पर परिभाषित हों; अस्पष्ट होने पर मॉडल अज्ञात या गलत वर्गीकरण की ओर जा सकता है
4. संक्षिप्त रखें: कभी-कभी कई मूल्यांकन मानदंड एक साथ भेजे जा सकते हैं। लंबे मानदंड शोर बढ़ा सकते हैं और संभावित रूप से हैलुसिनेशन का कारण बन सकते हैं
5. भाषा महत्वपूर्ण है: मूल्यांकन मानदंड पूरा हुआ या नहीं, इस पर LLM जो भी तर्क देगा, वह मानदंड के विवरण वाली भाषा में होगा, इसलिए इसे ध्यान में रखना जरूरी है

डेटा कलेक्शन

1. ठीक-ठीक बताएं कि क्या निकालना है: विवरण LLM के लिए मुख्य संकेत है। बताएं कि फ़ील्ड का क्या अर्थ है, उसे किस स्थिति में सेट करना चाहिए और स्पष्ट न होने पर क्या करना है (जैसे, “अगर ग्राहक ने कभी पसंदीदा तारीख नहीं बताई, तो null छोड़ें”)।
2. अपेक्षित टाइप से मिलाएं: LLM की दी गई वैल्यू हमेशा डेटा कलेक्शन पॉइंट को असाइन किए गए डेटा टाइप से मेल खाएगी (जैसे boolean, string, integer आदि)। इसलिए विवरण भी उसके अनुरूप होना चाहिए। उदाहरण के लिए, integer के लिए “मांगे गए आइटम्स की संख्या निकालें” और boolean के लिए “ग्राहक ने ऑफ़र स्वीकार किया या नहीं, हां/नहीं” लिख सकते हैं।
3. जहां संभव हो, enums इस्तेमाल करें: string टाइप में अगर वैल्यूज़ का सेट तय है, तो स्कीमा में enum इस्तेमाल करें; इससे मॉडल सीमित रहता है और अमान्य आउटपुट्स घटते हैं।
4. हर आइटम के लिए एक एक्सट्रैक्शन लक्ष्य: एक आइटम के विवरण में कई असंबंधित तथ्य न भरें; उन्हें अलग-अलग आइटम्स में बांटें, ताकि हर कॉल का एक स्पष्ट एक्सट्रैक्शन लक्ष्य हो।
5. विवरण छोटे रखें: विवरण कुछ वाक्यों के हो सकते हैं; लंबे पैराग्राफ की जरूरत नहीं है। ट्रांसक्रिप्ट पहले से ही यूज़र संदेश में है, इसलिए स्कीमा + छोटा विवरण पर्याप्त है।

अभी, इस मूल्यांकन और एक्सट्रैक्शन चरण में इस्तेमाल होने वाला LLM तेज़ प्रोसेसिंग सुनिश्चित करने के लिए कम-लेटेंसी मॉडल पर तय है। निकट भविष्य में, हम ग्राहकों को ज्यादा लचीलापन देने के लिए विकल्प पेश करने की उम्मीद करते हैं। 

अब हम उन उपयोग के मामलों पर ध्यान देते हैं जिनमें संरचित ऑर्केस्ट्रेशन, निर्धारकता या कई बातचीत भूमिकाओं में विशेषज्ञता चाहिए, जहां आप इसके बजाय Workflows इस्तेमाल कर सकते हैं।

वर्कफ़्लोज़

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

• सिस्टम प्रॉम्प्ट्स और सब-एजेंट बातचीत लक्ष्यों का इंटरैक्शन।
• ग्राफ़ में विभिन्न ट्रांज़िशन पॉइंट्स से होकर गुजरने का तरीका कैसे तय होता है।

विशेषीकृत बातचीत लक्ष्य

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

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

इस नियंत्रण को संभव बनाने वाले मुख्य तरीकों में से एक है सब-एजेंट्स के बीच ट्रांज़िशन्स को नियंत्रित करने का तरीका।

LLM कंडीशंस से वर्कफ़्लो ट्रांज़िशन्स चलाना

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

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

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

सुरक्षा और सिक्योरिटी

जिन मामलों में बेहतर सुरक्षा और सिक्योरिटी नियंत्रण चाहिए, उनमें ग्राहक ऑर्केस्ट्रेटर के अतिरिक्त हिस्सों पर भरोसा कर सकते हैं। 

गार्डरेल्स

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

अनुपालन-अनुरूप डेटा प्रबंधन

बोलने वाले कभी-कभी एजेंट के साथ संवेदनशील जानकारी साझा कर सकते हैं, जिस पर स्टोरेज और प्रोसेसिंग की सख्त आवश्यकताएं लागू होती हैं, जैसे HIPAA-अनुरूप हैंडलिंग की जरूरत वाला मेडिकल डेटा। इन उपयोग के मामलों के लिए हम एजेंट या Workspace स्तर पर Zero Retention Mode (ZRM) देते हैं। सक्षम होने पर, सभी कॉल डेटा केवल मेमोरी में प्रोसेस होता है और कभी पर्सिस्टेंट स्टोरेज में नहीं लिखा जाता। कॉल और प्रोसेसिंग पूरी होने के बाद, ElevenLabs कोई जानकारी नहीं रखता। इसलिए ट्रांसक्रिप्ट्स, ऑडियो रिकॉर्डिंग्स और विश्लेषण आउटपुट्स Agents Dashboard में उपलब्ध नहीं होते, और यह नीति ग्राहक-सामने वाले सिस्टम्स व आंतरिक लॉग्स—दोनों पर लागू होती है। डेटा रखा नहीं जाता, लेकिन कॉल के दौरान प्रोसेस होता है और कॉन्फ़िगर किए गए पोस्ट-कॉल वेबहुक्स को आउटपुट मिलते हैं। इससे जरूरत होने पर ग्राहक ट्रांसक्रिप्ट्स या विश्लेषण नतीजे अपने सिस्टम्स में स्टोर कर सकते हैं। 

ZRM सक्रिय होने पर, हम उपलब्ध LLMs को उन प्रदाताओं तक सीमित करके यह भी सुनिश्चित करते हैं कि सबप्रोसेसर्स डेटा न रखें, जिनकी संविदात्मक प्रतिबद्धताएं ग्राहक डेटा पर ट्रेनिंग या उसके रिटेंशन को प्रतिबंधित करती हैं; फिलहाल इसमें Google Gemini और Anthropic Claude के मॉडल्स शामिल हैं। ZRM में दूसरा LLM इस्तेमाल करने के इच्छुक ग्राहक उस प्रदाता के साथ अपना समझौता कर सकते हैं और उस समझौते के तहत आने वाली API keys का उपयोग करके उसे कस्टम LLM के रूप में कॉन्फ़िगर कर सकते हैं। क्योंकि इससे डेटा हैंडलिंग हमारी मानक ट्रस्ट बाउंड्री से आगे बढ़ती है, इसे सक्षम करने से पहले हमारी Safety टीम को उपयोग के मामले की मैन्युअल समीक्षा और मंजूरी देनी होती है। ZRM यह सुनिश्चित करता है कि ElevenLabs और उसके सबप्रोसेसर्स कॉल डेटा न रखें, लेकिन ग्राहकों की जिम्मेदारी बनी रहती है कि उनके एजेंट द्वारा उपयोग किए जाने वाले बाहरी टूल्स या वेबहुक्स लागू रिटेंशन और नियामक आवश्यकताओं का पालन करें।

आगे की दिशा

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

हमारी Forward Deployed Engineering टीम ग्राहकों के साथ मिलकर काम कर रही है, ताकि ये क्षमताएं वास्तविक तैनातियों के साथ तालमेल में विकसित हों। Agents की अगली पीढ़ी, रीयल-टाइम बातचीत को संभव बनाने वाले कम-लेटेंसी प्रदर्शन से समझौता किए बिना, और भी अधिक पारदर्शिता, निर्धारकता और अनुकूलनशीलता देगी।