ElevenAgents में इमेज और डॉक्युमेंट्स प्रोसेस करना

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

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

चैनल और इनपुट 

ElevenAgents उन चैनलों के आधार पर बनाया गया है जिनका एंटरप्राइज़ ग्राहक तक पहुँचने के लिए पहले से इस्तेमाल करते हैं: वेब और मोबाइल ऐप्लिकेशन, उनका सपोर्ट प्लेटफ़ॉर्म, फ़ोन, SMS, ईमेल, WhatsApp और अन्य। एजेंट कॉन्फ़िगरेशन (प्रॉम्प्ट, मॉडल, टूल्स, नॉलेज बेस और वॉइस) एक बार तय किया जाता है और सभी चैनलों पर साझा होता है। हर चैनल में दो चीज़ें अलग होती हैं: ट्रांसपोर्ट लेयर और उसके सपोर्ट किए जाने वाले इनपुट प्रकार। वेब और मोबाइल ऐप्लिकेशन एम्बेड किए जा सकने वाले विजेट, किसी SDK या Agents WebSocket से कनेक्ट होते हैं। टेलीफ़ोनी बातचीत नेटिव Twilio, SIP ट्रंकिंग या नेटिव websocket-आधारित इंटीग्रेशन से कनेक्ट होती है। SMS नेटिव Twilio इंटीग्रेशन से कनेक्ट होता है। WhatsApp Business अकाउंट इंपोर्ट करके और एजेंट पर इंटीग्रेशन चालू करके WhatsApp कनेक्ट होता है। एक ही एजेंट को इन सभी ट्रांसपोर्ट पर एक साथ डिप्लॉय किया जा सकता है।

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

इनपुट का प्रतिनिधित्व: फ़ाइल-आधारित बनाम इनलाइन

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

फ़ाइल-आधारित इनपुट

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

इनलाइन

दूसरा प्रतिनिधित्व इनलाइन है और इसमें बाकी सब शामिल है। वॉइस और वॉइस नोट को ट्रांसक्राइब किया जाता है। टाइप किया गया टेक्स्ट, ट्रांसक्राइब की गई स्पीच, WhatsApp लोकेशन पिन और कॉन्टैक्ट कार्ड—मॉडल चलने से पहले इन सभी को ट्रांसक्रिप्ट में सादे टेक्स्ट में सामान्यीकृत किया जाता है। लोकेशन पिन निर्देशांक और वैकल्पिक पता बन जाता है; कॉन्टैक्ट नाम और फ़ोन नंबर बन जाता है। इनमें से कोई भी फ़ाइल के रूप में स्टोर नहीं होता या फ़ाइल रेफ़रेंस नहीं बनाता। ये इनपुट सीधे ट्रांसक्रिप्ट में रहते हैं।

यह अंतर क्यों मायने रखता है

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

मल्टीमॉडल इनपुट सेट अप करना 

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

फ़ाइल इनपुट चालू करना

फ़ाइल इनपुट के काम करने से पहले एजेंट कॉन्फ़िगरेशन में दो सेटिंग्स का होना ज़रूरी है। पहले, conversation_config.conversation.file_input.enabled को True पर सेट करें, एजेंट बनाते समय API से या डैशबोर्ड में Settings > Advanced Settings > File Input के तहत। दूसरा, एजेंट को विज़न और दस्तावेज़-सक्षम मॉडल के साथ कॉन्फ़िगर किया जाना चाहिए। अगर अंतर्निहित मॉडल इमेज या दस्तावेज़ ब्लॉक प्रोसेस नहीं कर सकता, तो केवल फ़्लैग से कुछ नहीं होगा; टेस्ट करने से पहले दोनों सेटिंग्स ज़रूरी हैं।

SDK और WebSocket

वेब या मोबाइल पर फ़ाइल इनपुट के लिए SDK पर बना कस्टम चैट क्लाइंट या रॉ Agents websocket कनेक्शन चाहिए। तीनों में फ़्लो एक जैसा है और क्रम का पालन करना अनिवार्य है: मैसेज भेजने से पहले फ़ाइल अपलोड होनी चाहिए, क्योंकि मैसेज पेलोड अपलोड से लौटे आइडेंटिफ़ायर को रेफ़रेंस करता है।

पहले फ़ाइल अपलोड करें:

from elevenlabs import ElevenLabs

client = ElevenLabs(api_key="YOUR_API_KEY")

response = client.conversational_ai.conversations.files.create(
    conversation_id="your_conversation_id",
    file=open("example_file.jpg", "rb"),
)

file_id = response.file_id  

पूरे अनुरोध और रिस्पॉन्स के लिए फ़ाइल अपलोड देखें:

फिर कनेक्शन पर ऐसा मैसेज भेजें जो लौटे हुए file_id को रेफ़रेंस करता हो:

{ 
	"type": "multimodal_message",
	"text": { 
		"type": "user_message", 
		"text": "What does this show?" 
	 },
	"file": { 
		"type": "file_input", 
		"file_id": "<file_id>" 
 	}
}

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

WhatsApp

WhatsApp पर अपलोड में आपकी ऐप्लिकेशन की कोई भूमिका नहीं होती। जब ग्राहक इमेज, दस्तावेज़ या स्टिकर भेजता है, तो फ़ाइल पहले Meta के इन्फ़्रास्ट्रक्चर पर जाती है। Meta WhatsApp Business API वेबहुक के ज़रिए ElevenLabs को सूचित करता है, और ElevenLabs आपके कनेक्ट किए गए WhatsApp Business अकाउंट के क्रेडेंशियल्स का इस्तेमाल करके फ़ाइल को सर्वर-टू-सर्वर डाउनलोड करता है, अपनी कॉपी स्टोर करता है और उसे वेब या SDK अपलोड की तरह ही बातचीत से जोड़ता है। एजेंट उसे मल्टीमॉडल इनपुट के रूप में प्राप्त करता है और ट्रांसक्रिप्ट में file_input इवेंट दर्ज होता है।

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

WhatsApp पर ग्राहक चैट में फ़ाइल भेजता है। ElevenLabs उसे Meta से प्राप्त करता है, स्टोर करता है और प्लेटफ़ॉर्म की ओर से file_id जोड़ता है। इसका मतलब है कि क्लाइंट-साइड अपलोड चरण नहीं होता। वेब और मोबाइल के विपरीत, आपकी ऐप्लिकेशन POST /v1/convai/conversations/{id}/files को कॉल नहीं करती या WebSocket पर multimodal_message नहीं भेजती। ElevenLabs डिलीवरी, स्टोरेज और एजेंट टर्न संभालता है।

सेशंस के बीच संदर्भ बनाए रखना

ElevenAgents हर बातचीत को अलग-अलग प्रोसेस करता है। ग्राहक जो भी भेजता है और एजेंट बातचीत के दौरान जो भी हल करता है, वह अपने-आप अगली बातचीत में नहीं जाता। एजेंट पोस्ट-कॉल वेबहुक के ज़रिए पूरी हुई बातचीत की सारी जानकारी आपके सिस्टम को देता है, लेकिन बातचीतों के बीच रहने वाली मेमोरी ElevenLabs की सीमा के बाहर रहती है। उसकी निरंतरता आपकी ज़िम्मेदारी है।

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

संदर्भ इंजेक्ट करना चैनल पर निर्भर करता है

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

फ़ाइलों को आगे ले जाना

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

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

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

निष्कर्ष

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

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