Jev से ईमेल और सपोर्ट टिकट रूटिंग: वर्गीकरण डेमो से पूर्ण व्यावसायिक वर्कफ़्लो तक

500 ईमेल को जल्दी से कुछ श्रेणियों में बाँटना Jev का एक ऐसा डेमो है जिसे समझना आसान है।

एक सामुदायिक उदाहरण के लेखक ने बताया कि Jev कुछ सेकंड में 500 ईमेल का बैच वर्गीकरण लगभग 0.035 अमेरिकी डॉलर में कर सकता है। लेकिन उस डेमो में ईमेलों की संरचना, श्रेणियों की परिभाषा, मानव लेबल, सटीकता या confusion matrix प्रकाशित नहीं की गई। इसलिए इसे संभावित कॉलिंग पैटर्न का उदाहरण मानना उचित है, न कि यह प्रमाण कि यह तरीका प्रोडक्शन में ग्राहक-सहायता रूटिंग को पहले से बदल सकता है।

वास्तविक ईमेल और टिकट प्रणाली में कठिनाई केवल यह तय करना नहीं है कि “यह ईमेल किस विभाग में जाना चाहिए?”

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

Jev की बेहतर भूमिका “एक वर्गीकरण से पूरे सपोर्ट वर्कफ़्लो को हल करना” नहीं, बल्कि उसके भीतर निर्णय परत बनना है: एक ईमेल को स्पष्ट सीमाओं वाले कई प्रश्नों में विभाजित करना और फिर संरचित परिणामों को संयोजन, रूटिंग और क्रियान्वयन के लिए व्यावसायिक कोड को देना।

ईमेल या सपोर्ट टिकट
   ↓
पूर्व-प्रसंस्करण: विषय, मुख्य पाठ और आवश्यक ऐतिहासिक संदर्भ निकालना
   ↓
Jev: क्यू चयन, रिफंड पहचान, जोखिम पहचान, तात्कालिकता स्कोरिंग
   ↓
व्यावसायिक नियम: प्रायिकताएँ, थ्रेशोल्ड, ग्राहक जानकारी और कंपनी नीति जोड़ना
   ↓
स्वचालित रूटिंग / मानव समीक्षा / उच्च-जोखिम एस्केलेशन / उत्तर का मसौदा बनाना

यहाँ सबसे महत्वपूर्ण जिम्मेदारी-विभाजन यह है: Jev अर्थ-संबंधी निर्णय करता है, कोड नियंत्रण प्रवाह संभालता है, और सपोर्ट कर्मचारी या जनरेटिव मॉडल अंतिम उत्तर तैयार करता है।

इस निर्णय परत के लिए Jev क्यों उपयुक्त है

Jev लंबा पाठ उत्पन्न करने के लिए बनाया गया चैट मॉडल नहीं है। यह एक state लेता है और डेवलपर द्वारा पहले से परिभाषित typed questions का उत्तर देता है। इनके तीन मुख्य रूप हैं:

प्रकार	उपयुक्त प्रश्न	लौटने वाला परिणाम
Choice	इस टिकट को किस क्यू में भेजना सबसे उचित है?	एक विकल्प, हर विकल्प की प्रायिकता और confidence
Noul	क्या उपयोगकर्ता स्पष्ट रूप से रिफंड माँग रहा है?	0 से 1 तक “हाँ” की प्रायिकता
Score	यह टिकट तात्कालिकता के किस स्तर में आता है?	स्कोर, हर स्तर की प्रायिकता और confidence

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

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

एक टिकट को केवल एक प्रश्न तक सीमित नहीं करना चाहिए

मान लें कि उपयोगकर्ता यह ईमेल भेजता है:

Pro प्लान में अपग्रेड करने के बाद मुझसे दो बार शुल्क लिया गया। मैंने तीन दिन पहले आपसे संपर्क किया था, लेकिन अब तक किसी ने समस्या हल नहीं की। कृपया आज ही रिफंड करें, नहीं तो मैं अपने बैंक में चार्जबैक दर्ज करूँगा।

यदि केवल पूछा जाए “यह ईमेल किस विभाग से संबंधित है?”, तो उत्तर संभवतः billing होगा। लेकिन प्रोडक्शन प्रणाली को कम से कम चार और बातें जाननी होंगी:

निर्णय	प्रश्न प्रकार	सुझाए गए विकल्प या मानदंड	उद्देश्य
किस मुख्य क्यू में भेजना है?	Choice	billing / shipping / technical / account / sales / legal / none	प्रारंभिक रूटिंग
क्या रिफंड की माँग है?	Noul	स्पष्ट रूप से पैसे लौटाने, शुल्क रिवर्स करने या भुगतान वापस करने की माँग को “हाँ” मानें	रिफंड वर्कफ़्लो शुरू करना
क्या चार्जबैक, नियामकीय या कानूनी जोखिम है?	Noul	chargeback, बैंक शिकायत, नियामक संस्था या कानूनी कार्रवाई का उल्लेख	उच्च-जोखिम एस्केलेशन
तात्कालिकता	Score	बिना समय-सीमा की सामान्य पूछताछ / सेवा प्रभावित है या उपयोगकर्ता बार-बार संपर्क कर चुका है / आर्थिक नुकसान, चार्जबैक या स्पष्ट समय-सीमा	क्यू प्राथमिकता
क्या मानव हस्तक्षेप आवश्यक है?	Noul	धन, कानूनी विषय, बार-बार अनसुलझी शिकायत या मॉडल का अनिश्चित निर्णय	तय करना कि स्वचालित प्रोसेसिंग की जा सकती है या नहीं

ये प्रश्न आपस में जुड़े हैं, लेकिन इन्हें “कृपया समग्र रूप से तय करें कि इस टिकट को कैसे संभालना चाहिए” जैसे एक प्रश्न में नहीं मिलाना चाहिए।

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

Choice में none, other या unclear जैसा विकल्प भी रखना चाहिए। यदि सही उत्तर विकल्पों में मौजूद नहीं है, तो मॉडल नया क्यू गढ़ नहीं सकता; वह उपलब्ध विकल्पों में से सबसे निकट वाला चुनने को मजबूर होगा।

मॉडल के उत्तर और व्यावसायिक कार्रवाई के बीच नियमों की एक परत चाहिए

नीचे दिया गया नियंत्रण-प्रवाह pseudocode Jev और आसपास की प्रणाली के बीच जिम्मेदारी-विभाजन दिखाता है। यह आधिकारिक SDK का शब्दशः अनुरोध नहीं है:

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

T_ROUTE और T_REFUND जैसे स्थिरांक Jev के सार्वभौमिक डिफ़ॉल्ट नहीं हैं। वे व्यावसायिक नीतियाँ हैं। उन्हें अपने टिकट डेटा पर कैलिब्रेट करना होगा और वे जोखिम स्तर, भाषा, मॉडल संस्करण तथा क्यू की परिभाषा के साथ बदल सकते हैं।

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

बैच कॉल रूटिंग के लिए उपयुक्त हैं, पर उच्च-जोखिम गेट अधिक सावधानी माँगते हैं

आधिकारिक इंटरफ़ेस के अनुसार Jev की एक विशेषता यह है कि एक ही अनुरोध में कई प्रश्न समानांतर रूप से पूछे जा सकते हैं। लेकिन यह मान नहीं लेना चाहिए कि कई टिकटों को एक साथ समूहीकृत करने पर परिणाम अलग-अलग कॉल के अनुरूप ही रहेंगे; इसके बजाय, पाठकों को अपने डेटा पर बैच बनाम एकल-आइटम (single-item) व्यवहार को बेंचमार्क करना चाहिए।

“हर ईमेल पर एक अनुरोध और हर प्रश्न पर एक और अनुरोध” भेजने की तुलना में आवश्यक निर्णयों को कम से कम कॉल में जोड़ना आम तौर पर नेटवर्क round trips घटाता है और throughput नियंत्रित करना आसान बनाता है।

इसी तरह, बैच और एकल-आइटम कॉल के बीच Noul प्रायिकताओं की समानता मानकर नहीं चलना चाहिए, बल्कि इसे सत्यापित किया जाना चाहिए, और उच्च-जोखिम या अनिश्चित टिकटों को अलग से संभाला जाना चाहिए।

इसलिए अधिक सावधान दो-चरणीय डिज़ाइन यह है:

1. पहले चरण में कम-जोखिम वाले निर्णय बैच में करें, जैसे मुख्य क्यू, विषय और यह कि संदेश स्पष्ट रूप से spam है या नहीं।
2. रिफंड, चार्जबैक, कानूनी जोखिम या अनिश्चितता क्षेत्र में आने वाली प्रायिकता वाले टिकटों को एकल समीक्षा दें या सीधे मानव क्यू में भेजें।

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

confidence को “सटीकता” न समझें

Choice और Score में confidence लौटता है, लेकिन यह बताता है कि प्रायिकता वितरण कितना केंद्रित है। यह पाठक के व्यवसाय के लिए सही होने की सीधे सत्यापित प्रायिकता नहीं है, इसलिए confidence को अपने डेटा पर कैलिब्रेट करने की आवश्यकता होती है। केवल उच्च confidence पर आँख मूँदकर निर्भर रहने वाला ऐसा नियम सुरक्षित नहीं है:

उच्च confidence → स्वचालित रूप से निष्पादित करें

वास्तविक प्रणाली को कई संकेत साथ देखकर निर्णय करना चाहिए:

• सबसे ऊपर वाले विकल्प की probability;
• पहले और दूसरे विकल्प की probability के बीच अंतर;
• संबंधित व्यावसायिक जोखिम के लिए स्वतंत्र Noul;
• क्या टिकट उस नए वितरण से आया है जो प्रशिक्षण या सत्यापन डेटा में शामिल नहीं था;
• क्या वर्तमान मॉडल संस्करण या प्रश्न की भाषा बदली है।

“यह किस क्यू में जाए?” और “क्या इसे स्वचालित रूप से संभालना चाहिए?” को भी केवल एक Choice से हल नहीं करना चाहिए। क्यू चयन के लिए Choice और स्वचालित प्रोसेसिंग की शर्तें पूरी होने की जाँच के लिए अलग Noul उपयोग करें।

प्रश्नों की भाषा को कोड की तरह प्रबंधित करना चाहिए

Jev वर्कफ़्लो में प्रश्नों की भाषा साधारण prompt copy नहीं है; वह व्यावसायिक तर्क का हिस्सा है।

यदि instructions और criteria के अर्थ एक-दूसरे से टकराते हैं, तो मॉडल बिना किसी exception के संरचनात्मक रूप से वैध लेकिन अर्थ की दृष्टि से गलत परिणाम दे सकता है।

इसलिए ईमेल-रूटिंग परियोजना को कम से कम प्रश्न-परिभाषाओं का प्रबंधन इस प्रकार करना चाहिए:

प्रबंधन बिंदु	ठोस अभ्यास
संस्करणकरण	प्रश्न की भाषा, विकल्प या मानदंड बदलने पर नया संस्करण बनाएँ
कोड समीक्षा	प्रश्न-परिभाषा और रूटिंग नियम repository में review के लिए रखें, उन्हें admin text fields में बिखेरें नहीं
परीक्षण उदाहरण	हर प्रश्न के लिए सकारात्मक, नकारात्मक, सीमांत और बहु-इरादा टिकट सुरक्षित रखें
विरोध जाँच	सुनिश्चित करें कि instruction और true/false criteria एक ही अर्थ-दिशा में हों
मॉडल संस्करण पिन करना	थ्रेशोल्ड कैलिब्रेट होने के बाद बदलते latest alias पर सीधे निर्भर रहने के बजाय विशिष्ट संस्करण पिन करें

Score का हर स्तर केवल “कम, मध्यम, अधिक” कहने के बजाय देखी जा सकने वाली व्यावसायिक स्थिति बताए। उदाहरण के लिए “उपयोगकर्ता केवल कीमत पूछ रहा है” और “उपयोगकर्ता कई बार संपर्क कर चुका है तथा सेवा उपलब्ध नहीं है” को “मध्यम तात्कालिकता” की तुलना में अधिक स्थिरता से आँका जा सकता है।

नेटवर्क विफल होने पर प्रणाली को पहले से पता होना चाहिए कि क्या करना है

वर्गीकरण मॉडल से उत्तर न मिलना “कोई जोखिम नहीं” या “डिफ़ॉल्ट रूप से अनुमति” नहीं माना जाना चाहिए।

उच्च concurrency और वास्तविक नेटवर्क स्थितियों में transport failure हो सकते हैं और latency भी बढ़ सकती है। यह दिखाता है कि प्रोडक्शन प्रणाली केवल आदर्श पथ पर निर्भर नहीं रह सकती।

कम से कम चार सुरक्षा परतें चाहिए:

1. रीट्राई और backoff: ऐसा SDK प्राथमिकता दें जो retries और retry-after का समर्थन करे, ताकि अस्थायी नेटवर्क त्रुटि से टिकट न खोए।
2. स्पष्ट फॉलबैक अर्थ: निर्णय सेवा अनुपलब्ध होने पर टिकट मानव triage में जाएगा, बाद में प्रोसेस होगा या केवल deterministic rules चलेंगे—यह पहले तय करें।
3. Idempotency और deduplication: ईमेल दोबारा पहुँचने, क्यू retry या timeout retry से डुप्लिकेट टिकट नहीं बनने चाहिए।
4. पूर्ण लॉगिंग: मॉडल संस्करण, प्रश्न संस्करण, probabilities, कॉल latency, usage और अंतिम मानव परिणाम दर्ज करें।

धन, अकाउंट और कानूनी मामलों में सबसे सुरक्षित डिफ़ॉल्ट फॉलबैक आम तौर पर “स्वचालित रूप से अनुमति” नहीं, बल्कि “स्वचालित कार्रवाई रोककर मानव को भेजना” है।

बहुभाषी क्यू एक ही Score थ्रेशोल्ड साझा नहीं कर सकते

कई भाषाओं के साथ काम करते समय, यह न मानें कि थ्रेशोल्ड और निर्णय नियम भाषाओं के बीच स्थानांतरित हो जाते हैं।

Score थ्रेशोल्ड और confidence स्तर सार्वभौमिक नहीं हैं: प्रत्येक समर्थित भाषा के लिए उन्हें अलग से सत्यापित करें, भले ही आधार रूटिंग लेबल एक जैसा दिखता हो।

इसलिए बहुभाषी सपोर्ट प्रणाली को कम से कम यह करना चाहिए:

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

लॉन्च से पहले क्या मूल्यांकन करना चाहिए

ईमेल-रूटिंग प्रणाली को केवल कुल सटीकता से नहीं आँका जा सकता। अलग-अलग त्रुटियों की लागत बहुत अलग होती है। प्री-सेल्स पूछताछ को सपोर्ट क्यू में भेजने से शायद केवल एक अतिरिक्त हस्तांतरण हो; चार्जबैक धमकी या कानूनी शिकायत चूकने से सीधा वित्तीय और compliance जोखिम पैदा हो सकता है।

कम से कम इन मेट्रिक्स को अलग-अलग देखें:

मेट्रिक	यह किस प्रश्न का उत्तर देता है
मुख्य क्यू सटीकता	क्या टिकट सही पहले प्रोसेसिंग क्यू में पहुँचा?
उच्च-जोखिम recall	कितने चार्जबैक, कानूनी, नियामकीय या अकाउंट-सुरक्षा टिकट छूटे?
स्वचालित रूटिंग कवरेज	कितने टिकटों को मानव की पहली छँटाई की आवश्यकता नहीं पड़ी?
गलत स्वचालित प्रोसेसिंग दर	जिन टिकटों को मानव चाहिए था, उनमें से कितने स्वचालित रूप से आगे बढ़ गए?
मानव समीक्षा दर	क्या थ्रेशोल्ड इतने सावधान हैं कि मानव क्यू का उद्देश्य ही समाप्त हो जाए?
latency और failure rate	वास्तविक concurrency, ईमेल लंबाई और नेटवर्क स्थितियों में प्रणाली स्थिर है या नहीं?
प्रति टिकट पूर्ण लागत	निर्णय, retries, बाद के मॉडल और मानव समीक्षा जोड़ने के बाद वर्कफ़्लो अभी भी किफ़ायती है या नहीं?

बेसलाइन चुनते समय Jev की तुलना केवल महँगे frontier chat models से न करें। नियम-आधारित प्रणालियाँ, structured output वाले Flash models, embedding के साथ classifier और अपने लेबल किए गए डेटा पर प्रशिक्षित छोटे मॉडल भी उचित विकल्प हो सकते हैं।

पर्याप्त लेबल किया गया डेटा उपलब्ध होने पर समर्पित क्लासिफायर को बेंचमार्क करने की सलाह दी जाती है। उचित विकास-पथ यह है कि cold start और बार-बार बदलने वाले labels के दौरान Jev इस्तेमाल करें, फिर किसी उच्च-मात्रा वाले क्यू के लिए पर्याप्त डेटा जमा होने पर समर्पित क्लासिफायर को बेंचमार्क करके पुनर्मूल्यांकन करें।

Jev अंतिम ग्राहक-सहायता उत्तर नहीं लिखता

रूटिंग के बाद प्रणाली को समस्या का सार बनाना, ऑर्डर ढूँढना, रिफंड पात्रता जाँचना या उत्तर का मसौदा तैयार करना पड़ सकता है। इन सभी कार्यों को Jev को नहीं देना चाहिए।

अधिक स्पष्ट जिम्मेदारी-विभाजन यह है:

चरण	अधिक उपयुक्त निष्पादक
सटीक ऑर्डर खोज, राशि की गणना और तारीख तुलना	व्यावसायिक कोड और database
क्यू, जोखिम, intent और तात्कालिकता निर्णय	Jev या कोई अन्य classification model
knowledge base retrieval	search और RAG system
उत्तर का मसौदा, व्याख्या और प्राकृतिक-भाषा संवाद	generative LLM
रिफंड स्वीकृति, अकाउंट निलंबन और कानूनी कार्रवाई	मानव और कंपनी नीति

यह आर्किटेक्चर Jev को “स्वचालित सपोर्ट एजेंट” नहीं बनाता। यह केवल हर ईमेल को महँगे मॉडल या मानव क्यू तक पहुँचने से पहले एक कम-लागत, संरचित निर्णय परत से गुज़ारता है जिसे कोड सीधे उपयोग कर सकता है।

निष्कर्ष: वर्गीकरण अंतिम उत्पाद नहीं, नियंत्रण प्रवाह ही उत्पाद है

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

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

इसलिए Jev टिकट प्रणाली का मूल्यांकन केवल यह पूछकर नहीं होना चाहिए कि “उसने 500 ईमेल कितनी तेजी से वर्गीकृत किए?” बेहतर प्रश्न यह है:

क्या यह उच्च-जोखिम टिकट छोड़े बिना अनावश्यक हस्तांतरण, मॉडल कॉल और मानव की पहली छँटाई को लगातार कम करता है?

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