Men in Black II में, एजेंट J एक बिल्कुल साधारण दिखने वाले पोस्ट ऑफिस में K से मिलने जाता है। वह मेल-सॉर्टिंग मशीन खोलता है और अंदर एक एलियन को तेज़ी से चिट्ठियाँ छांटते हुए दिखाता है।
यह एक हास्यास्पद छोटा सा सीन है, लेकिन यह हमें AI के बारे में सोचने का एक काम का तरीका भी देता है।
कुछ प्राप्त करने और उसके साथ कुछ करने के बीच, अक्सर एक छोटा फैसला लेना होता है: यह किसके लिए है?
अगर शुरुआत में ही यह फैसला सही हो जाए, तो सिस्टम का बाकी हिस्सा अपने उचित रास्ते पर चल सकता है।
AI सॉफ्टवेयर बनाते समय मैं उस छोटे एलियन के बारे में सोचता रहा हूँ।
एक एप्लिकेशन को बिलिंग का सवाल, बग रिपोर्ट, प्रोडक्ट की फोटो और डेमो बुक करने का अनुरोध मिलता है। हर एक को अलग तरह से हैंडल करना पड़ता है। फिर भी हम अंत में उसी बड़े लैंग्वेज मॉडल से सब कुछ जाँचने और यह तय करने को कह देते हैं कि आगे क्या होगा। यह न तो कुशल है और न ही लागत के लिहाज से सही।
इसीलिए मुझे लगता है कि AI के भविष्य में स्पेशलाइज़्ड मॉडल्स की भूमिका बहुत बड़ी होगी। उदाहरण के लिए; Jev उन स्ट्रक्चर्ड निर्णयों के लिए बनाया गया है जिन पर सॉफ्टवेयर काम कर सकता है। Coinbase ने अपनी Onramp सेवा में फ्रॉड डिटेक्शन के लिए Qwen3.5-9B को खास तौर पर अनुकूलित किया है। हर कोई एक निश्चित काम पर ध्यान केंद्रित करता है, जिसके परिणाम मापे जा सकते हैं।
https://x.com/brian_armstrong/status/2109412046244913643
मैं सॉर्टिंग लेयर बना रहा हूँ
परिचित अनुरोध सीधे किसी निर्धारित वर्कफ़्लो में जा सकते हैं। जिन अनुरोधों में अधिक रीज़निंग की ज़रूरत होती है, वे दूसरे मॉडल के पास चले जाते हैं। अस्पष्ट अनुरोधों को स्पष्टीकरण या समीक्षा के लिए फ्लैग कर दिया जाता है।
बचत की संभावना इस बात से आती है कि हर अनुरोध को उतनी ही प्रोसेसिंग दी जाए जितनी उसे चाहिए। फिर हमें यह मापना होगा कि क्या सॉर्टर इतने फैसले सही ले रहा है कि उसका वहाँ होना सही ठहराया जा सके।
हमारी शुरुआत CludeMem से हुई थी। हम यह तय करने की कोशिश कर रहे थे कि AI को क्या याद रखना चाहिए, उसे क्या वापस लाना (retrieve) चाहिए, और क्या चीज़ बेवजह टोकन खर्च कर रही है। एक स्थायी प्राथमिकता, एक अस्थायी निर्देश और एक अधूरा सवाल — इन तीनों के साथ अलग-अलग व्यवहार होना चाहिए। ये फैसले लेने से पहले, हमें जानकारी को वर्गीकृत (classify) करना ज़रूरी था।
यही एक व्यापक वर्गीकरण लेयर के पीछे का विचार बन गया। यही कदम किसी सपोर्ट अनुरोध को छांटने, डॉक्यूमेंट को रास्ता दिखाने या यह चुनने में मदद कर सकता है कि किसी काम को कौन सा विशेषज्ञ संभालेगा।
GIF
जैसे-जैसे अधिक स्पेशलाइज़्ड मॉडल सामने आएँगे, एप्लिकेशन्स को यह तय करना होगा कि किन इनपुट्स पर उनका ध्यान जाना चाहिए। यही वह हिस्सा है जिसे हम बना रहे हैं: जो भी आए उसे वर्गीकृत करो, परिचित मामलों को लोकली हैंडल करो, और कठिन मामलों को उपयुक्त मॉडल या समीक्षा प्रक्रिया के पास भेज दो।
पेश है Clude Cat (Cat यानी categorisation के लिए 😉)
किसी मेमोरी को स्टोर करने, डॉक्यूमेंट निकालने, टूल कॉल करने या जवाब जनरेट करने से पहले, आमतौर पर यह फैसला लेना होता है कि हम किस तरह की जानकारी से निपट रहे हैं।
ऐसे फैसले हर जगह होते हैं।
मान लीजिए कोई किसी सॉफ्टवेयर कंपनी को लिखता है:
“मैं अपना इनवॉइस कहाँ से डाउनलोड कर सकता हूँ?”
एक AI एजेंट संदेश पढ़ सकता है, अपने टूल्स देख सकता है, ग्राहक के इरादे पर विचार कर सकता है और इनवॉइस खोजने का फैसला कर सकता है।
एक अधिक सीधा वर्कफ़्लो ऐसा दिख सकता है:
संदेश → बिलिंग-डॉक्यूमेंट अनुरोध → अकाउंट वेरिफिकेशन → इनवॉइस रेट्रीवल।
जवाब अभी भी कोई लैंग्वेज मॉडल ही लिख सकता है। शुरुआती राउटिंग का फैसला लोकली लिया जा सकता है।
अब संदेश बदलते हैं:
“मुझसे दो बार चार्ज किया गया है, मेरा अकाउंट लॉक हो गया है, और मैं इसे कैंसल करना चाहता हूँ।”
इसे बिना सोचे-समझे एक ही इनवॉइस वर्कफ़्लो में भेज देने से काम और बढ़ जाएगा। यहाँ सुलझाने के लिए कई समस्याएँ हैं, और सही जवाब के लिए स्पष्टीकरण या किसी इंसान की ज़रूरत पड़ सकती है।
सॉर्टर को यह कहने की छूट होनी चाहिए, “मैं इसे भरोसेमंद तरीके से वर्गीकृत नहीं कर सकता।”
यह प्रोडक्ट का एक ज़रूरी हिस्सा है। कोई सिस्टम जो पूरे भरोसे के साथ अनुरोधों को गलत जगह भेज देता है, वह अपनी गलतियों को सुधारने में लगने वाले काम की वजह से अपनी स्पीड का फायदा खो सकता है।
ग्राहक के लिए, इसका मतलब है कम इंतज़ार और कम दोहराव।
डेवलपर के लिए, यह एक स्पष्ट फैसला है जिसे वे जाँच, टेस्ट और बदल सकते हैं। वे चुनी गई कैटेगरी, मॉडल वर्ज़न, प्रोसेसिंग टाइम और यह देख सकते हैं कि क्या सिस्टम ने फैसला लेने से मना किया है।
अंदर से देखें तो, टेक्स्ट इम्प्लीमेंटेशन एक छोटे प्रीट्रेन्ड मॉडल से शुरू होता है जिसे एन्कोडर कहते हैं।
यह संदेश को संख्याओं की एक सूची में बदल देता है जो उसके अर्थ के पहलुओं को दर्शाती है। डेवलपर्स इस रिप्रजेंटेशन को एम्बेडिंग कहते हैं।
“मेरा इनवॉइस कहाँ है?” और “मुझे अपने बिल की एक कॉपी चाहिए” में अलग-अलग शब्द हैं। फिर भी उनके न्यूमेरिकल रिप्रजेंटेशन इतने मिलते-जुलते हो सकते हैं कि सिस्टम उन्हें एक ही तरह का अनुरोध मान ले।
एक वर्गीकरण लेयर उन रिप्रजेंटेशन्स का उपयोग करके डेवलपर द्वारा परिभाषित कैटेगरीज़ को स्कोर देता है।
हमने दो तरीके अपनाए हैं। एक आने वाले संदेश की तुलना हर कैटेगरी के उदाहरणों से करता है। दूसरा लेबल किए गए उदाहरणों से कैटेगरीज़ के बीच की सीमाएँ सीखता है।
फिटेड अप्रोच में, हम एन्कोडर को स्थिर रखते हैं और उसके ऊपर एक छोटी डिसीजन लेयर को ट्रेन करते हैं। हमें हर एप्लिकेशन के लिए नया फाउंडेशन मॉडल ट्रेन करने की ज़रूरत नहीं पड़ती।
डेवलपर को अभी भी यह तय करना होता है कि कैटेगरीज़ का क्या मतलब है और उन्हें उपयोगी कार्यों से कैसे जोड़ा जाए। क्लासिफायर कंपनी के विभागों, रिफंड पॉलिसी या अकाउंट परमिशन खुद नहीं बना सकता।
इसे एक स्वीकृति नीति (acceptance policy) की भी ज़रूरत होती है।
सबसे ज्यादा स्कोर वाली कैटेगरी भी सही मैच नहीं हो सकती। दो कैटेगरीज़ लगभग बराबर हो सकती हैं। कोई अपरिचित अनुरोध किसी परिचित चीज़ जैसा लग सकता है।
हमारे मौजूदा लोकल स्कोर कैलिब्रेटेड प्रोबेबिलिटी नहीं हैं। 0.92 का स्कोर अपने आप यह नहीं बताता कि “92% संभावना है कि यह सही है।”
हमें यह टेस्ट करना होगा कि जब ये स्कोर फैसले तय करेंगे तो क्या होगा।
इसलिए आउटपुट एक स्वीकृत कैटेगरी, समीक्षा की ज़रूरत वाले अनुरोध और तकनीकी विफलता के बीच अंतर करता है। टाइमआउट, कैंसलेशन और मॉडल एरर को भी अनुमानित तरीके से हैंडल करना होगा।
यही सॉर्टर के आसपास की इंजीनियरिंग है। यह तय करती है कि क्या कोई अन्य एप्लिकेशन परिणाम का सुरक्षित और लगातार उपयोग कर सकता है।
हमने 770 बैंकिंग अनुरोधों पर एक प्रयोग किया यह देखने के लिए कि क्या यह तरीका जेनरेटिव-मॉडल के काम को कम कर सकता है।
पहले कॉन्फ़िगरेशन ने हर अनुरोध को वर्गीकरण के लिए लोकली चल रहे Qwen2.5 7B मॉडल के पास भेजा।
दूसरे ने पहले हमारे लोकल क्लासिफायर का इस्तेमाल किया और अनसुलझे अनुरोधों को Qwen के पास भेजा।
परिणाम ये थे:
- Qwen कॉल्स 770 से घटकर 227 रह गईं।
- सही वर्गीकरण 535 से बढ़कर 642 हो गए।
- सभी इनपुट्स में सटीकता 69.5% से बढ़कर 83.4% हो गई।
- मापे गए क्वेरी टाइम का कुल योग 299.7 सेकंड से घटकर 87.7 सेकंड हो गया।
लोकल स्टेज ने 543 Qwen कॉल्स को टाल दिया, यानी 70.5% की कमी।
कैशिंग चालू रही, और डायरेक्ट अप्रोच को कंबाइंड अप्रोच से पहले चलाया गया। टाइमिंग के आंकड़ों में सेटअप और वॉर्मअप शामिल नहीं हैं। हमने केवल वर्गीकरण को मापा, बिना अंतिम ग्राहक उत्तर जनरेट किए या किसी मॉडल प्रोवाइडर को भुगतान किए।
ये आंकड़े इस कॉन्फ़िगरेशन का वर्णन करते हैं। ये हर LLM पर बढ़त साबित नहीं करते और न ही ग्राहक की बचत को सिद्ध करते हैं।
बाद में, एक अलग प्रयोग में 24 ट्रैवल और वर्कप्लेस इंटेंट्स पर फिटेड लोकल क्लासिफायर को टेस्ट किया गया।
720 अनुरोधों में से, इसने 688 को लोकली स्वीकार किया। उनमें से 681 सही थे और सात गलत। इसने 32 को समीक्षा के लिए छोड़ दिया।
इससे हमें दो अलग-अलग माप मिलते हैं:
- कवरेज: इसने 95.6% अनुरोधों को लोकली हैंडल किया।
- स्वीकृत सटीकता (Accepted precision): जिन फैसलों को इसने स्वीकार किया, उनमें से 99.0% सही थे।
दोनों ही परिणाम का हिस्सा होने चाहिए। कोई क्लासिफायर केवल कुछ आसान अनुरोधों को स्वीकार करके भी शानदार सटीकता दिखा सकता है।
हमने 100,000 अपरिचित इनपुट्स को भी टेस्ट किया जो इसकी सपोर्टेड कैटेगरीज़ से बाहर होने चाहिए थे। यह 94% से अधिक बार सही रहा।
यह पहचानना कि सिस्टम क्या नहीं जानता, अभी भी काम का हिस्सा है।
स्पीड को भी उतनी ही सावधानी की ज़रूरत है। एक अलग वॉर्म CPU टेस्ट में, M4 Max पर मीडियन रूप से पूरे बैंकिंग क्लासिफायर को प्रति अनुरोध लगभग 1.8 मिलीसेकंड लगे। इसमें टोकनाइज़ेशन, एम्बेडिंग और स्कोरिंग शामिल थी।
इसमें मॉडल डाउनलोड करना और उसे स्टार्ट करना शामिल नहीं था। यह वर्गीकरण का मापन है, न कि यूज़र के पूरे अनुरोध को हल करने में लगने वाला समय। यह फोन या साधारण लैपटॉप पर भी वैसी ही परफॉर्मेंस की गारंटी नहीं देता।
Jev इस चर्चा में इसलिए फिट बैठता है क्योंकि यह पहले से ही इसी तरह के फैसलों को संबोधित करता है।
TypeSafe Jev को बाउंडेड जजमेंट के लिए एक मॉडल के रूप में डॉक्यूमेंट करता है, जिसमें दिए गए विकल्पों में से चुनना और अनुरोधों को साधारण कोड, विशेषज्ञ मॉडल या इंसानों की ओर राउट करना शामिल है। \Jev की इंटेंट-राउटिंग डॉक्यूमेंटेशन\
Jev की भूमिका मैं एक वैकल्पिक एस्केलेशन पाथ के रूप में देखता हूँ, उन अनुरोधों के लिए जिन्हें लोकल क्लासिफायर भरोसेमंद तरीके से हल नहीं कर पाता।
जिस आर्किटेक्चर की ओर हम बढ़ रहे हैं वह सीधा है:
आने वाला अनुरोध → लोकल वर्गीकरण → परिचित अनुरोध एक निर्धारित रास्ता अपनाते हैं; अनिश्चित अनुरोध Jev, किसी अन्य मॉडल या मानव समीक्षा के पास जाते हैं।
Jev के बिना, वही लोकल वर्गीकरण स्टेज अनसुलझे अनुरोधों को एप्लिकेशन के मौजूदा LLM, स्पष्टीकरण स्टेप या समीक्षा प्रक्रिया को वापस सौंप सकता है।
डेवलपर कैटेगरीज़, स्वीकृति थ्रेशोल्ड और फ़ॉलबैक को नियंत्रित करता है। वे किसी मौजूदा वर्कफ़्लो में लोकल क्लासिफायर को शामिल कर सकते हैं और माप सकते हैं कि यह किन फैसलों की ज़िम्मेदारी ले सकता है।
आज, Jev इंटीग्रेशन शैडो मोड में काम करता है, जो एप्लिकेशन के व्यवहार को बदले बिना पांच व्यापक विषयों में फैसलों की तुलना करता है। अगला कदम यह टेस्ट करना है कि क्या चुनिंदा एस्केलेशन पूरे वर्कफ़्लो को बेहतर बनाता है। ऊपर दिए गए Qwen के परिणाम Jev का बेंचमार्क नहीं हैं।
हमें यही मापना है: मॉडल की कम अनावश्यक कॉल्स, परिचित अनुरोधों का तेज़ हैंडलिंग, और उन मामलों के लिए एक स्पष्ट रास्ता जिन्हें अधिक ध्यान देने की ज़रूरत है।
हमने इसी तरीके को इमेजेज़ तक बढ़ाना शुरू कर दिया है।
मान लीजिए किसी बिज़नेस को एक रसीद, किसी एरर का स्क्रीनशॉट और प्रोडक्ट की फोटो मिलती है। हर एक को अलग प्रोसेसिंग पाथ की ज़रूरत है।
रसीद रसीद एक्सट्रैक्शन में जा सकती है। स्क्रीनशॉट सपोर्ट वर्कफ़्लो में जा सकता है। प्रोडक्ट फोटो कैटलॉग वर्कफ़्लो में जा सकती है। कोई अनिश्चित इमेज समीक्षा के लिए जा सकती है।
क्लासिफायर गंतव्य चुनता है। खरीद का कुल योग पढ़ना, एरर का निदान करना और प्रोडक्ट विवरण पहचानना अलग-अलग काम बने रहते हैं।
हमारा प्रयोगात्मक इमेज इम्प्लीमेंटेशन इमेज का न्यूमेरिकल रिप्रजेंटेशन बनाने के लिए एक प्रीट्रेन्ड CLIP एन्कोडर का उपयोग करता है।
एक फिटेड रिसर्च कैंडिडेट ने एक छोटे डायग्नोस्टिक टेस्ट में 20 में से 19 फूड-प्रोडक्ट फोटोग्राफ़ को सही ढंग से वर्गीकृत किया। इसने बीन-लीफ की सभी 30 इमेजेज़ को समीक्षा के लिए भेज दिया।
गलती यह हुई कि बोतल के न्यूट्रिशन पैनल और बारकोड को रसीद के रूप में वर्गीकृत कर दिया गया।
आप समस्या देख सकते हैं। दोनों में घने टेक्स्ट, नंबर और आयताकार लेआउट हो सकते हैं। हमें ऐसे उदाहरणों की ज़रूरत है जो हमारी एप्लिकेशन के लिए महत्वपूर्ण सीमा को सिखा सकें।
यह सैंपल प्रोडक्शन दावे के लिए बहुत संकीर्ण है। लेबल डेटासेट से लिए गए थे, स्वतंत्र रूप से तय नहीं किए गए थे, और टेस्ट में कोई नई रसीद या स्क्रीनशॉट के उदाहरण नहीं थे। पब्लिक डेमो एक अलग बेसलाइन का उपयोग करता है, इसलिए फिटेड कैंडिडेट के परिणाम को उससे नहीं जोड़ा जाना चाहिए।
इमेज प्रोसेसिंग भी टेक्स्ट वर्गीकरण से भारी थी। M4 Max पर वॉर्म मीडियन प्रोसेसिंग में Node में लगभग 36 मिलीसेकंड और Chromium में 197 मिलीसेकंड लगे। ब्राउज़र को पहले लगभग 85 MiB मॉडल एसेट्स की ज़रूरत होती है, साथ ही उसका रनटाइम।
लोकल एग्जीक्यूशन की भी अपनी लागत है। डाउनलोड साइज़, मेमोरी, स्टार्टअप टाइम और डिवाइस परफॉर्मेंस — सबका मूल्यांकन में शामिल होना ज़रूरी है।
मेरे दिमाग में जो प्रोडक्ट है वह किसी मौजूदा एप्लिकेशन में फिट बैठता है जहाँ यह तय करता है कि आगे क्या होगा।
डेवलपर कैटेगरीज़ तय करता है, प्रतिनिधि उदाहरण देता है, गंतव्यों को जोड़ता है और चुनता है कि वर्गीकरण अनिश्चित होने पर क्या होना चाहिए।
पहली तैनाती को मौजूदा वर्कफ़्लो को देखना चाहिए, बिना उसके परिणाम को बदले। फिर हम क्लासिफायर को राउटिंग का नियंत्रण देने से पहले प्रस्तावित फैसलों की तुलना सत्यापित परिणामों से कर सकते हैं।
हमें स्वीकृत गलतियों को भी उतनी ही सावधानी से जाँचना होगा जितना अस्वीकृत अनुरोधों को। अन्यथा, भरोसे से ली गई गलत फैसला एक आश्वस्त करने वाले स्कोर के पीछे छिप सकता है।
ट्रेनिंग, कैलिब्रेशन और टेस्टिंग के लिए भी अलग डेटा चाहिए। ट्रेनिंग कैटेगरीज़ सिखाती है। कैलिब्रेशन स्वीकृति नियम चुनता है। एक सुरक्षित टेस्ट फ्रोज़न परिणाम की जाँच करता है।
एक बार जब कोई टेस्ट गलती अगले मॉडल को प्रभावित करती है, तो वह उदाहरण डेवलपमेंट डेटा बन जाता है। अगले मूल्यांकन के लिए एक नए टेस्ट की ज़रूरत होती है।
मेल सॉर्टर में बैठा वह छोटा एलियन लोगों को काम की कल्पना करने का एक तरीका देता है। एक उपयोगी वर्ज़न बनाने का मतलब है यह पता लगाना कि यह किन इनपुट्स को संभाल सकता है, इसे कब मदद माँगनी चाहिए, और इसकी गलतियों की क्या कीमत चुकानी पड़ती है।
अगला कदम एक प्रतिनिधि वर्कफ़्लो है जिसमें स्वतंत्र लेबल और हर परिणाम का रिकॉर्ड हो। हमें मापना होगा कि कितने अनुरोध लोकल रूट लेते हैं, कितने किसी अन्य मॉडल तक पहुँचते हैं, कितने गलत होते हैं, और क्या उन गलतियों को ध्यान में रखने के बाद पूरी एप्लिकेशन तेज़ या सस्ती हो जाती है।
अब इसे बड़े पैमाने पर ले जाने और इस लोकल मॉडल को कुछ स्टेरॉयड्स देने का समय है।
