कैस्केडेड बनाम फ्यूज्ड मॉडल: आपकी वॉइस एजेंट की आर्किटेक्चर कैसे तय करती है कि वह एंटरप्राइज के लिए तैयार है या नहीं

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

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

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

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

टीम्स आर्किटेक्चर चुनते समय क्या देखते हैं

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

क्या यह जटिल टास्क्स संभाल सकता है? 

हालांकि टीम्स कंकरेन्सी, इंटीग्रेशन और वॉइस क्वालिटी जैसी चीज़ों की भी परवाह करती हैं, लेकिन ऊपर बताए गए पहलुओं को एजेंट की आर्किटेक्चर से सीधे प्रभावित किया जा सकता है। सबसे सफल टीम्स अपनी आर्किटेक्चर को अपने यूज़ केस के हिसाब से इन पहलुओं के लिए ऑप्टिमाइज़ करती हैं।

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

क्या मैं इसे प्रोडक्शन में ट्रस्ट कर सकता हूँ?

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

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

• lookup_order के लिए टूल डिस्क्रिप्शनlookup_order: “ऑर्डर ID से ग्राहक के ऑर्डर की डिटेल्स निकालता है। ऑर्डर स्टेटस, खरीदी गई चीजें, शिपिंग एड्रेस और ट्रैकिंग नंबर रिटर्न करता है।”
• स्पीच टू टेक्स्ट“ग्राहक की पहचान वेरिफाई करने के बाद, lookup_order टूल से उनका ऑर्डर डिटेल्स निकालें।”

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

• Webhook टूल्स जो बाहरी APIs को कॉल करते हैं।
• Client टूल्स जो टूल रिक्वेस्ट्स को इवेंट्स के रूप में कन्वर्सेशन वेब्सॉकेट के ज़रिए भेजते हैं।
• System टूल्स जो कॉल ट्रांसफर जैसी बिल्ट-इन एक्शन के लिए होते हैं।
• MCP टूल्स जो Model Context Protocol सर्वर्स से कनेक्ट होते हैं।

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

1. बेसिक कैस्केडेड

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

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

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

1. बेसिक कैस्केडेड

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

ऑडियो ट्रांसक्राइब होता है, LLM टेक्स्ट रिप्लाई जनरेट करता है, और TTS उसे बोलता है। हर स्टेज सिंपल टेक्स्ट पर काम करता है, इसलिए आप सबकुछ देख, टेस्ट और कंट्रोल कर सकते हैं।

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

उदाहरण यूज़ केस:

यह तरीका

2. एडवांस्ड कैस्केडेड

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

• सिस्टम प्रॉम्प्ट्स और सब-एजेंट्स के कन्वर्सेशनल गोल्स कैसे इंटरैक्ट करते हैं।
• एक्सप्रेसिव मोड

LLM फिर TTS को बताता है कि स्पीच कैसे डिलीवर करनी है - सिर्फ क्या कहना है, यह नहीं, बल्कि "आश्वस्त करते हुए", "जोर देकर", "तत्कालता के साथ" जैसी इंस्ट्रक्शन देता है, जिससे एजेंट का टोन बातचीत के दौरान डायनामिकली बदलता है। टर्न-टेकिंग सिस्टम भी इन्हीं सिग्नल्स का इस्तेमाल करता है, जिससे एजेंट तय कर पाता है कब जवाब देना है और कब रुकना है। स्पीच मॉडल्स एक ही स्टैक में को-लोकेटेड हैं, कंपोनेंट्स के बीच कोई नेटवर्क हॉप नहीं है, इसलिए लेटेंसी कम रहती है।

यह आर्किटेक्चर बेसिक कैस्केडेड की सारी खूबियाँ रखता है: फुल ट्रांसपेरेंसी, टेक्स्ट-लेयर गार्डरेल्स, कंपोनेंट्स बदलने की सुविधा, डोमेन-ट्यूनिंग, और सबसे स्ट्रॉन्ग टूल-कॉलिंग और रीजनिंग मॉडल्स तक एक्सेस। इसमें बेहतर प्रोसोदी, लेटेंसी और टर्न-टेकिंग भी मिलती है। टीमें नया फ्रंटियर LLM जैसे ही आए, इंटीग्रेट कर सकती हैं, या हेल्थकेयर के लिए STT को फाइन-ट्यून कर सकती हैं, बिना बाकी कंपोनेंट्स को बदले।

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

3. हाइब्रिड कैस्केडेड और फ्यूज्ड

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

कुछ आर्किटेक्चर इनपुट स्पीच से एकॉस्टिक फीचर्स (उच्चारण, इमोशन, टोन) को सीधे LLM में एम्बेडिंग के रूप में भेजते हैं, पहले टेक्स्ट में बदले बिना। TTS मॉड्युलर रहता है।

यह LLM को

उदाहरण यूज़ केस:

सुरक्षा और सेफ्टी

4. सीक्वेंशियल फ्यूज्ड

गार्डरेल्स

एक सिंगल मल्टीमोडल मॉडल एक बार में, एक टर्न में, रिकग्निशन, रीजनिंग और जेनरेशन सब संभालता है। यही आर्किटेक्चर OpenAI के Realtime API जैसे मॉडल्स के पीछे है।

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

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

उदाहरण यूज़ केस:

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

5. डुप्लेक्स फ्यूज्ड

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