लेखक: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev टाइप्ड डिसीजन (typed decisions) लेने के लिए बनाया गया एक मॉडल है। आप इसे कॉन्टेक्स्ट और सवालों व विकल्पों का एक तय सेट भेजते हैं, और यह टेक्स्ट जनरेट करने की जगह चॉइस, स्कोर और प्रोबेबिलिटी लौटाता है। यह एक “System One” मॉडल है!
लेकिन क्लासिफिकेशन कोई नई चीज़ नहीं है, और न ही स्ट्रक्चर्ड आउटपुट, छोटे मॉडल या logits से प्रोबेबिलिटी पढ़ना। यही इतिहास Jev को लेकर मिली-जुली प्रतिक्रियाओं की कुछ हद तक व्याख्या करता है...
शक करने वालों की बात में दम है, लेकिन इस इकोसिस्टम में Jev की अपनी एक अहम जगह है। इसे बेहतर तरीके से समझने के लिए हमें पूरे सॉल्यूशन स्पेस पर नज़र डालनी चाहिए।
विकल्प क्या-क्या हैं?
जब किसी सिस्टम को लेबल, स्कोर या हाँ/ना में जवाब चाहिए होता है, तो चार बेहतर विकल्प होते हैं:
तरीका
इसे क्यों चुनें
ट्रेडऑफ़
एक जनरल-पर्पस LLM
Zero-shot, फ्लेक्सिबल, और तर्क या व्याख्या भी जनरेट कर सकता है। इंफरेंस-टाइम कंप्यूट (reasoning) के ज़रिए शायद “ज़्यादा इंटेलिजेंट”।
एक छोटे से फैसले के लिए ऑटोरिग्रेसिव मॉडल की लेटेंसी और लागत चुकाना
एक ओपन zero-shot क्लासिफायर
सस्ता, लोकल और पूरी तरह आपके कंट्रोल में
क्वालिटी बदलती रहती है; मॉडल चुनने और सर्व करने की ज़िम्मेदारी आपकी
एक फाइन-ट्यून्ड क्लासिफायर
अच्छे लेबल्स वाले स्थिर और हाई-वॉल्यूम काम के लिए आमतौर पर सबसे बेहतरीन विकल्प
डेटा कलेक्शन, ट्रेनिंग, डिप्लॉयमेंट, ड्रिफ्ट और कम फ्लेक्सिबल टैक्सोनॉमी
Jev
एक साफ-सुथरे, होस्टेड API के पीछे zero-shot की फ्लेक्सिबिलिटी
काम के हिसाब से बदलती क्वालिटी, कोई जनरेटेड टेक्स्ट नहीं, और प्रोवाइडर पर निर्भरता
Jev के पक्ष में दलील: कोई टीम बिना नया ट्रेनिंग सेट तैयार किए अपने सवाल और विकल्प बदल सकती है, साथ ही मॉडल को ठीक से सर्व करने की मेहनत से भी बच जाती है। इसे नज़रअंदाज़ करना समझदारी नहीं होगी। “हम इसे खुद भी बना सकते हैं” — यह बात ज़्यादातर इंफ्रास्ट्रक्चर प्रोडक्ट्स पर सच होती है।
ओपन रीप्रोडक्शन्स ने इसकी नवीनता के दावे को संतुलित कर दिया है। Qwen और SGLang, DiffusionGemma और vLLM, और Kev का इस्तेमाल करके बनाए गए वर्ज़न इसके API या मॉडल स्ट्रक्चर का बड़ा हिस्सा दोबारा तैयार कर देते हैं।
n=764 पर Jev के लिए 85.7% और Kev-8B के लिए 79.6%
इसी तरह, Parallel के बाहरी टेस्ट्स में भी पाया गया कि रीरैंकिंग में Jev अच्छी टक्कर देता है, हालांकि दो क्लासिफिकेशन टास्क में स्पेशलाइज़्ड मॉडल ही जीते।
Glean में हमने क्या देखा
अब एक व्यावहारिक सवाल उठता है: zero-shot की फ्लेक्सिबिलिटी और होस्टेड इंफरेंस का Jev का यह कॉम्बिनेशन असल में दूसरे विकल्पों को कब मात देता है? हमने Glean में ऐसे चार सीमित (bounded) फैसलों का टेस्ट किया जहाँ हमारे पास पहले से एक बेसलाइन था और हम असल एंटरप्राइज़ क्वालिटी की तुलना कर सकते थे। इनमें से ज़्यादातर बेसलाइन LLM-आधारित सिस्टम हैं, इसलिए उन प्रयोगों में हमें लागत और लेटेंसी में दो ऑर्डर ऑफ़ मैग्निट्यूड सुधार की उम्मीद थी। नतीजे प्रोडक्शन से काफ़ी खराब लेकर LLM-आधारित राउटर से ज़्यादा तेज़ और सटीक दोनों तरह के रहे।
Query classification
Query classification किसी रिक्वेस्ट को एक बड़े टास्क से जोड़ता है जिसका इस्तेमाल डाउनस्ट्रीम सिस्टम करते हैं। यह Jev के लिए एक स्वाभाविक काम है, क्योंकि भले ही हर रिक्वेस्ट के हिसाब से लेबल स्पेस पहले से पता होता है, फिर भी टैक्सोनॉमी इतनी तेज़ी से बदल सकती है कि फाइन-ट्यून्ड क्लासिफायर को दोबारा ट्रेन करना मुश्किल हो जाए।
इस प्रयोग में हमने Jev की सहमति को हमारे प्रोडक्शन / बेसलाइन अनुमानों (जो LLM-आधारित हैं) के मुकाबले मापा। हमें Jev के साथ ऑफ़लाइन थ्रूपुट में बड़ी बढ़त की उम्मीद थी और वैसा ही दिखा भी, इसलिए हमने क्वालिटी के एक आसान पैमाने के तौर पर सहमति (agreement) को रिपोर्ट किया। हमने Laya (एक ओपन-वेट डिसीजन मॉडल) और फाइन-ट्यून्ड Laya के साथ भी बेसलाइन तैयार किया। यह फाइन-ट्यूनिंग लोकल मशीन पर कुछ ही घंटों में चल गई, और मॉडल इतना छोटा है कि किसी डेवलपर मशीन पर आसानी से सर्व किया जा सकता है।
प्रयोग
Broad Task Agreement
Perf
Jev zero-shot
66.8%
~
12min (concurrency of 4
)
Base Laya
35.9%
~
90s (local dev machine)
Fine-tuned Laya
74.5%
~
90s (local dev machine)
बिना ट्रेनिंग वाले एक सुविधाजनक रेडीमेड मॉडल के रूप में Jev साफ़ तौर पर Laya से बेहतर है, लेकिन अपेक्षा के मुताबिक फाइन-ट्यूनिंग Laya को चमका देती है, खासकर परफॉर्मेंस के आंकड़ों को देखते हुए। इसका ट्रेडऑफ़ है अच्छे लेबल जुटाने और ट्रेनिंग सेटअप करने की मेहनत। जब कोई टास्क नया हो या उसके लेबल लगातार बदल रहे हों, तो Jev ज़्यादा आकर्षक विकल्प बना रहता है।
Model routing: expert transfer
Model routing, query classification से मिलता-जुलता मामला है। यहाँ हम model routing को expert transfer के रूप में देखते हैं, जहाँ हमारा सिस्टम तय करता है कि किस expert / मॉडल को रिक्वेस्ट संभालनी चाहिए। फिलहाल हमारा प्रोडक्शन बेसलाइन harness के एजेंटिक लूप के अंदर ही LLM से यह फैसला करवाता है। हालांकि यह देखने का अच्छा मौका है कि क्या Jev किसी जनरेटिव कॉल को एक सीमित फैसले से बदल सकता है, लेकिन एक अहम तकनीकी सीमा यह है कि non-transfer की स्थिति में Jev अनिवार्य रूप से एक कॉल जोड़ देगा। इसके उलट, प्रोडक्शन बेसलाइन non-transfer मामलों में उसी पहली LLM कॉल से टूल-कॉलिंग का काम शुरू कर सकता है।
हमने सिर्फ 3 experts वाले अपने प्रोडक्शन राउटिंग के सरलीकृत वर्ज़न का इस्तेमाल किया, अपडेटेड Jev राउटर से 751 तुलनीय golden entries दोबारा चलाईं, और इसके चुने हुए राउट की तुलना हमारे मौजूदा prompt-based राउटर (जो एक पारंपरिक LLM द्वारा संचालित है) से की, तथा golden label के मुकाबले सटीकता मापी।
हमने उन 40 entries को भी अलग निकाला जहाँ मौजूदा पाथ ने वास्तव में expert-transfer कॉल की थी (छोटा n) और उन्हीं entries पर कॉल लेटेंसी की तुलना की।
प्रति-एंट्री मीडियन स्पीडअप 8.1× रहा। अब तक के आंतरिक Jev नतीजों में यह सबसे मज़बूत में से एक है: इस सीमित राउटिंग टास्क में, Jev ज़्यादा सटीक और काफ़ी तेज़ दोनों था। इस अंतर का आकार बताता है कि non-expert-routed रिक्वेस्ट्स पर लगने वाली “blocking” की कीमत एक अच्छा सौदा हो सकती है। ध्यान दें कि यह अभी भी एक ऑफ़लाइन golden-set तुलना है, और लेटेंसी सैंपल में सिर्फ 40 positive transfers शामिल हैं, इसलिए जोखिम कम करने और टेस्ट करने के लिए अभी बहुत कुछ बाकी है!
Reranking
Glean के दिल के बहुत करीब वाला विषय! नीचे दिए गए प्रयोग में हमारा प्रोडक्शन बेसलाइन वह क्रम है जो Glean का मौजूदा सर्च स्टैक तैयार करता है। इस प्रयोग में Jev से अधिकतम 50 नतीजों को दोबारा क्रमबद्ध करने को कहा गया।
हमने Jev के टाइप्ड आउटपुट के ज़रिए relevance दिखाने के चार तरीके आज़माए:
फॉर्मूलेशन
यह relevance कैसे दर्शाता है
Pointwise Noul
हर नतीजे के लिए अलग से हाँ/ना वाला relevance सवाल पूछें, फिर “हाँ” की प्रोबेबिलिटी के आधार पर छाँटें।
Shared-state Noul
Jev को शेयर्ड कॉन्टेक्स्ट के रूप में पूरा कैंडिडेट सेट दिखाएं, फिर हर नतीजे के लिए वही हाँ/ना सवाल पूछें।
Score
Jev से कहें कि वह हर कैंडिडेट को एक नंबर वाला relevance score दे।
Choice
सभी कैंडिडेट्स को एक ही फैसले के विकल्प मानें, फिर उनकी प्रोबेबिलिटी के आधार पर रैंक करें।
हमने इसे एक आंतरिक evalset पर चलाया जहाँ यूज़र के पास सभी canonicals की पहुँच नहीं होती, इसलिए पूर्ण संख्याएँ हमारी प्रोडक्शन रैंकिंग को नहीं दर्शातीं — लेकिन सापेक्ष संख्याएँ दिलचस्प हैं।
Jev “Choice” सबसे मज़बूत फॉर्मूलेशन रहा। 4,855 कैप्चर की गई सर्च क्वेरीज़ के पेयर्ड कंट्रोल पर, प्रोडक्शन-आधारित टाई-ब्रेकिंग हटाने के बाद, नतीजा यह रहा:
Jev Choice की लागत प्रति क्वेरी लगभग $0.00044 रही और ऑफ़लाइन टेस्ट में p50 पर इसने 0.195 सेकंड लिए। लेकिन इसने एक औसत क्वेरी में 41 में से लगभग 37 कैंडिडेट्स को एक जैसे स्कोर दे दिए। उन टाई को सुलझाने के लिए प्रोडक्शन क्रम का इस्तेमाल करने से Recall@6 40.2% से बढ़कर 44.3% हो गया, जिससे बिना सुधारे नतीजे असल में Jev के स्कोर की क्षमता से ज़्यादा बेहतर दिखे। हमेशा की तरह यहाँ कई शर्तें लागू होती हैं, लेकिन मोटे तौर पर, Jev एक सस्ता और कुशल बेसलाइन है, Glean के प्रोडक्शन रैंकर की जगह लेने वाला नहीं।
Citation-support judging
Citation judging दो जुड़े सवाल पूछता है: क्या सबूत चाहने वाले दावों के पास पर्याप्त संदर्भ हैं (citation recall), और क्या बताए गए स्रोत वाकई उन दावों का समर्थन करते हैं जो उन पर थोपे गए हैं (citation precision)? पहली नज़र में, क्योंकि आउटपुट / लेबल स्पेस सीमित है (ज़्यादातर judge सेटिंग्स की तरह), यह Jev के लिए एकदम सही काम लगता है। लेकिन रुब्रिक जटिल है और इसमें कई दावों को तोड़ने की ज़रूरत पड़ सकती है — इसके अलावा, Jev वह तर्क (rationale) नहीं देता जिसका इस्तेमाल हम अक्सर error analysis के लिए करते हैं, इसलिए क्वालिटी और उपयोगिता दोनों पर कुछ खतरा है।
हमने रिस्पॉन्स और citation evidence को स्थिर रखते हुए, 1,448 शब्दों वाले एक असल production-eval रिस्पॉन्स पर Jev को टेस्ट किया। हमने बिना reasoning और xhigh reasoning वाले GPT-5.6 Luna के साथ इसकी shared precision-and-recual pass की तुलना की। वेरिएंस कम करने के लिए हमने हर judge को तीन बार चलाया।
Judge
Original measured time per response
Original measured cost per response
Jev
6.6 s
$
0.014
GPT-5.6 Luna, no reasoning
81.3–85.5 s
$
0.030–
$
0.047
GPT-5.6 Luna,
xhigh
227.4–259.7 s
$
0.047–
$
0.060
ध्यान दें कि समय end-to-end की बजाय दिशात्मक (directional) है: Jev sequential client wall time बताता है, जबकि Luna की पंक्तियों में मॉडल-कॉल की अवधियों का योग है। लागत में देखी गई caching शामिल है।
हमने उन्हीं 28 पैराग्राफ पर consistency की भी तुलना की। changed item का मतलब है कि तीन एक-जैसे इनपुट वाले रन में से कम से कम एक में judge ने अपना फैसला बदल दिया कि किसी पैराग्राफ में पर्याप्त citation coverage है या नहीं। Pairwise disagreement हर judge के लिए तीनों रन जोड़ियों में हर पैराग्राफ को गिनता है, यानी 84 तुलनाएँ।
Judge
Paragraphs with a changed recall verdict
Pairwise recall disagreements
Jev
1 of 28 (3.6%)
2 of 84 (2.4%)
GPT-5.6 Luna, no reasoning
7 of 28 (25.0%)
15 of 84 (17.9%)
GPT-5.6 Luna,
xhigh
5 of 28 (17.9%)
10 of 84 (11.9%)
Jev में एकमात्र बदलाव यह था कि क्या एक पैराग्राफ को citation की ज़रूरत वाला माना जाए; इसकी raw recall category नहीं बदली। इसलिए पैराग्राफ-स्तर पर Jev के citation-coverage फैसले Luna के दोनों कॉन्फ़िगरेशन से ज़्यादा दोहराए जाने लायक (repeatable) थे।
हम यह निष्कर्ष नहीं निकाल रहे कि इससे Jev ज़्यादा सटीक judge बन जाता है (सिस्टम ने अलग-अलग support criteria और scoring denominators लागू किए, और हमारे पास स्वतंत्र human labels तैयार करने का समय नहीं था)। लेकिन xhigh reasoning (जिसने Luna के मॉडल टाइम को लगभग तीन गुना कर दिया) के साथ भी यह Jev से कम consistent रहा। यह नतीजा इस बात का समर्थन करता है कि किसी संकीर्ण citation policy को लागू करने के लिए Jev एक तेज़, सस्ता और अपेक्षाकृत ज़्यादा repeatable तरीका है।
प्रयोगों से सीख और व्यावहारिक गाइड
कुछ मामलों में Jev पारंपरिक LLMs और फाइन-ट्यून्ड क्लासिफायर दोनों के मुकाबले एक आसान विकल्प के रूप में चमकता है। जब बेसलाइन मज़बूत हो (reranking), या किसी छोटे मॉडल को फाइन-ट्यून करना आसान हो (query classification), तो इसका फायदा कम हो जाता है। कुछ टास्क (model routing) में बेहतर क्वालिटी के संकेत मिले हैं, साथ ही बेहतर consistency और stability (citation judge) के भी। हमारे कुछ सबसे अहम वर्कलोड में यह पारंपरिक LLMs के मुकाबले लागत और लेटेंसी में अपेक्षित जीत दिलाता है।
ऊपर दिए गए नतीजे अच्छी दिशा दिखाते हैं, और Glean में हम Jev को लेकर बहुत उत्साहित हैं। कुछ और कदम (मुख्य रूप से data residency और guarantees जैसी operational readiness) पूरे होने के बाद हम इनमें से कुछ use cases में Jev को लॉन्च करने की योजना बना रहे हैं। साथ ही, इस हफ्ते हमारे आंतरिक hackathon में Jev बड़ी भूमिका निभाएगा और हम और नतीजे साझा करने के लिए उत्सुक हैं!
आखिर में कुछ सामान्य सलाह – अगर आउटपुट पहले से तय किया जा सकता है, तो Jev को बेंचमार्क करें। अगर टास्क और लेबल स्थिर हैं और वॉल्यूम ज़्यादा है, तो फाइन-ट्यून्ड क्लासिफायर को भी बेंचमार्क करें। अगर कॉल को कोई क्वेरी, व्याख्या या अन्य डायनामिक टेक्स्ट जनरेट करना है, तो जनरेटिव मॉडल को साथ रखें। Tool calling इसका अच्छा उदाहरण है: Jev टूल चुनने में मदद कर सकता है, लेकिन ज़्यादातर Glean tools को अभी भी डायनामिक रूप से जनरेट किए गए arguments (जैसे search queries) की ज़रूरत होती है।
Jev इस सच्चाई को नहीं बदलता कि क्लासिफायर पहले से मौजूद थे। यह एक अच्छे zero-shot क्लासिफायर का इस्तेमाल बहुत आसान बना देता है। भले ही यह हर AI system की नई नींव न हो, फिर भी यह एक मज़बूत प्रोडक्ट है।
