TypeSafe AI द्वारा Jev: क्या नया है, यह कैसे काम करता है, और इसके विकल्प (2026)

इस साल लॉन्च हुए अधिकांश मॉडल कुछ ज़्यादा करने के बारे में रहे हैं। यह मॉडल जानबूझकर कुछ कम करने के बारे में है।

TypeSafe AI ने एक ऐसा मॉडल जारी किया है जो न तो चैट करता है, न लिखता है और न ही खुद को स्पष्ट करता है। यह टाइप्ड वैल्यूज़ और प्रोबेबिलिटीज़ के साथ सवालों के जवाब देता है। यही इस पूरे प्रोडक्ट का मुख्य काम है।

यह गाइड बताती है कि यह मॉडल क्या है और इसके तीन प्रकार के सवाल कैसे काम करते हैं। इसमें इसकी कीमत, वेंडर के अनुसार इसकी कमियां, और यह अधिकांश टीमों के वास्तविक काम में कहां फिट बैठता है, इस पर भी चर्चा की गई है।

क्या लॉन्च हुआ है

Jev, TypeSafe का फ्लैगशिप मॉडल है। वेंडर के आधिकारिक दस्तावेज़ के अनुसार, यह "पहला System One मॉडल" भी है।

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

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

पेश किया गया विकल्प इस पूरी प्रक्रिया को आसान बनाता है। Jev "किसी स्टेट के आधार पर टाइप्ड सवालों का मूल्यांकन करता है और सीधे स्ट्रक्चर्ड परिणाम देता है। कोई टेक्स्ट जनरेशन नहीं, कोई पार्सिंग नहीं।"

कंपनी की अपनी वेबसाइट Jev को एक विकास क्रम के अंत में रखती है। पहले शुरुआती लैंग्वेज मॉडल्स, फिर प्री-ट्रेंड LLMs, फिर RLHF चैट मॉडल्स, फिर RLVR रीज़निंग मॉडल्स। और अब RLCD, जिसे यह "reinforcement learning for calibrated decisions" के रूप में परिभाषित करता है।

System One मॉडल क्या है

यह नाम कहीं से लिया गया है, और दस्तावेज़ में सीधे तौर पर ऐसा कहा गया है। यह "उस अवधारणा से आता है जिसे डैनियल काह्नमैन ने अपनी पुस्तक Thinking, Fast and Slow में लोकप्रिय बनाया था।"

System 1 तेज़ और सहज है। System 2 धीमा और विचारशील है। यहाँ "तेज़, केंद्रित निर्णयों पर ज़ोर दिया गया है।"

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

एक बात Jev को बाज़ार में मौजूद अन्य सभी चीज़ों से अलग करती है। "एक LLM की तरह, एक System One मॉडल नेचुरल-लैंग्वेज इनपुट को समझता है। यह जेनरेट किए गए टेक्स्ट के बजाय टाइप्ड निर्णय और प्रोबेबिलिटीज़ देता है।"

वेंडर ने यह भी साफ़ तौर पर बताया है कि यह मॉडल क्या नहीं कर सकता। System One मॉडल "जवाब नहीं लिखते, कोड नहीं बनाते, या अपने तर्क का स्पष्टीकरण नहीं देते।"

तीन प्रकार के सवाल

आप Jev को प्रॉम्प्ट नहीं देते हैं। आप एक उत्तर का दायरा तय करते हैं, और यह उसी के भीतर से चुनाव करता है।

इसके तीन प्रिमिटिव हैं। दस्तावेज़ में प्रत्येक का एक उदाहरण दिया गया है।

प्रिमिटिव	सवाल	उत्तर का दायरा	आउटपुट
Choice	इस टिकट को किस टीम को संभालना चाहिए?	billing, technical, या account	choice: "billing"
Score	यह ग्राहक कितना परेशान है?	0 = शांत, 1 = परेशान, 2 = बहुत परेशान	score: 1.4
Noul	क्या यह संदेश रिफंड का अनुरोध करता है?	True या false	noul: 0.95

Choice एक तय सेट से एक विकल्प चुनता है। Score क्रमित, वर्णनात्मक स्तरों के आधार पर रेटिंग देता है। Noul इस बात की प्रोबेबिलिटी देता है कि कोई हाँ/ना वाला सवाल सही है या नहीं।

Score वाले उदाहरण पर दोबारा गौर करने की ज़रूरत है। उत्तर 1.4 है, न कि 1। Jev मामले को निकटतम स्तर पर ले जाने के बजाय दो नामित स्तरों के बीच रख रहा है। यह किसी भी टेक्स्ट मॉडल द्वारा दिए जाने वाले आउटपुट से बिल्कुल अलग है।

इसकी लागत क्या है और यह क्या स्वीकार करता है

इसका प्राइसिंग पेज असामान्य रूप से समझने में आसान है। किसी मॉडल लॉन्च के बारे में अक्सर ऐसा नहीं लिखा जाता है।

वर्तमान मॉडल jev-1.13.0 है। इसकी कीमत $42 प्रति बिलियन टोकन, या $0.042 प्रति मिलियन है। दस्तावेज़ में स्पष्ट रूप से कहा गया है कि यह शुल्क "प्रति इनपुट टोकन" है और "आउटपुट टोकन मुफ्त हैं।"

रेट लिमिट 250,000 टोकन प्रति सेकंड और 1,200 रिक्वेस्ट प्रति मिनट बताई गई है। कॉन्टेक्स्ट लेंथ प्रति रिक्वेस्ट 64k टोकन है। इसमें से, 32k स्टेट और सबसे लंबे सवाल के लिए उपलब्ध है।

इनपुट केवल टेक्स्ट है। दस्तावेज़ में उल्लेख है कि Jev "स्ट्रिंग्स, JSON ऑब्जेक्ट्स और टेक्स्ट के एरेज़ का मूल्यांकन करता है।" इसमें आगे कहा गया है कि "इमेज, ऑडियो और वीडियो अभी समर्थित नहीं हैं।"

सब कुछ एक ही एंडपॉइंट, POST /v1/systemone के ज़रिए चलता है। एक model फ़ील्ड यह चुनता है कि कौन सा मॉडल कॉल को हैंडल करेगा।

प्रॉपर्टी	वैल्यू
Model	jev-1.13.0
Price	$42 प्रति Btok / $0.042 प्रति Mtok, केवल इनपुट
Output tokens	मुफ्त
Rate limits	250,000 टोकन प्रति सेकंड; 1,200 रिक्वेस्ट प्रति मिनट
Context	64k प्रति रिक्वेस्ट; 32k स्टेट और सबसे लंबे सवाल के लिए
Input types	केवल टेक्स्ट

कॉन्फिडेंस वह हिस्सा है जिस पर ध्यान देने की ज़रूरत है

कीमत भले ही मुख्य आकर्षण हो, लेकिन कॉन्फिडेंस को हैंडल करने का तरीका अधिक दिलचस्प डिज़ाइन निर्णय है।

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

एक अलग confidence प्रॉपर्टी उस आकार को 0 से 1 के बीच की एक संख्या में समेट देती है। दस्तावेज़ में इसका उद्देश्य यह बताया गया है कि "ताकि आप खुद गणित किए बिना इस पर एक थ्रेशोल्ड तय कर सकें।"

उस संख्या को देने के पीछे के तर्क को एक सिद्धांत के रूप में बताया गया है। "यदि कोई इंटेलिजेंट सिस्टम, चाहे वह इंसान हो या मशीन, ईमानदारी से अपनी अनिश्चितता व्यक्त नहीं कर सकता, तो उस सिस्टम पर भरोसा नहीं किया जा सकता।"

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

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

वेंडर के अनुसार यह किस काम में कमज़ोर है

TypeSafe ने 'मॉडल जैग्डनेस' नाम से एक पेज प्रकाशित किया है, जिसकी समीक्षा 2026-09-17 को की गई थी। यह उन कमियों को सूचीबद्ध करता है जिनके बारे में कंपनी जानती है। लॉन्च के साथ ही ऐसी जानकारी देना दुर्लभ है, और यह हर किसी को अंदाज़ा लगाने की मशक़्क़त से बचाता है।

इसकी सारांश पंक्ति बिल्कुल स्पष्ट है। Jev 1.13 "तेज़, कैलिब्रेटेड और व्यावहारिक निर्णय लेने में अच्छा है लेकिन यह परफेक्ट नहीं है।"

तीन कमियों का सीधे तौर पर ज़िक्र किया गया है। यह "उन कार्यों में संघर्ष कर सकता है जिनमें अतिरिक्त स्तर के इनडायरेक्शन की आवश्यकता होती है।" यह "अपनी समझ में काफी शाब्दिक हो सकता है।" और यह "उन कार्यों में संघर्ष करता है जिनमें संख्यात्मक सटीकता की आवश्यकता होती है।"

विफलों की तालिका में प्रत्येक कमी के साथ उसका समाधान भी दिया गया है। किसी पायलट प्रोजेक्ट का मूल्यांकन करने वाले के लिए इनमें से दो बातें दोहराने योग्य हैं।

• गणित और संख्याओं के लिए, दस्तावेज़ में दी गई सलाह है कि "अंकगणित को कोड में ही रखें।"
• अप्रासंगिक विवरणों से भरे बड़े स्टेट के लिए सलाह है कि "पहले फ़िल्टर करें; केवल वही भेजें जिसकी सवाल को ज़रूरत है।"

दोनों एक ही डिज़ाइन धारणा की ओर इशारा करते हैं। यह एक जजमेंट इंजन है, न कि कोई कैलकुलेटर या सर्च इंडेक्स। यह तब सबसे अच्छा काम करता है जब आस-पास के सिस्टम ने पहले ही सवाल को सीमित कर दिया हो.

यह आपके मौजूदा काम में कहां फिट बैठता है

वेंडर के अपने उदाहरण में काम का एक स्पष्ट विभाजन छिपा हुआ है। इसे समझने से ही यह तय होगा कि यह लॉन्च आपके लिए प्रासंगिक है भी या नहीं।

दस्तावेज़ में दिया गया रिफंड वर्कफ़्लो एक स्टेट बनाता है और एक साथ कई स्वतंत्र सवाल पूछता है। इसके बाद यह "कोड में डिटरमिनिस्टिक चेक" के साथ उत्तरों को जोड़ता है और मामले को "कार्रवाई या समीक्षा के लिए" रूट करता है।

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

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

ग्राहक फीडबैक की चार हजार पंक्तियों को वर्गीकृत करना उस काम का मध्य भाग है। इसका अंत एक सारांश है जो तीन मुख्य विषयों का नाम बताता है और अपवादों को चिह्नित करता है।

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

ये दोनों एक ही स्थान के लिए प्रतिस्पर्धा नहीं कर रहे हैं। एक API है जिसे आप किसी प्रोडक्ट में जोड़ते हैं। दूसरा वह जगह है जहाँ स्प्रेडशीट तब जाती है जब किसी व्यक्ति को गुरुवार तक जवाब की आवश्यकता होती है। यदि आपकी इस समस्या का रूप एक फ़ाइल है, तो Powerdrill Bloom आज़माएं।

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

तुलना करने योग्य विकल्प

तीन दृष्टिकोण एक ही क्षेत्र को कवर करते हैं। सही दृष्टिकोण का चुनाव मुख्य रूप से वॉल्यूम पर निर्भर करता है।

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

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

फ़ाइल-फर्स्ट एनालिसिस वर्कस्पेस। ये निर्णय लेने को अंतिम परिणाम तैयार करने के एक चरण के रूप में संभालते हैं। कोई API नहीं, कोई स्कीमा नहीं, कोई प्रति-टोकन बजटिंग नहीं। साथ ही, रिक्वेस्ट पाथ के भीतर काम करने की कोई क्षमता नहीं होती।

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

इनमें से अंतिम को कवर करने वाले रिपोर्ट जनरेशन के टूल पर एक संबंधित संग्रह उपलब्ध है।

किसे अभी ध्यान देना चाहिए

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

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

बाकी सभी के लिए, अपनाने के लिए एक टूल के बजाय सीखने के लिए एक शब्दावली है। तेज़ निर्णय को धीमी सिंथेसिस से अलग करना आपकी अपनी पाइपलाइन को देखने का एक उपयोगी नज़रिया है। यह तब भी उपयोगी रहता है चाहे आप इस API को कभी कोई रिक्वेस्ट भेजें या नहीं।

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

अक्सर पूछे जाने वाले सवाल

System One मॉडल क्या है?

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

Jev की लागत कितनी है?

jev-1.13.0 की घोषित कीमत $42 प्रति बिलियन टोकन, या $0.042 प्रति मिलियन है। शुल्क केवल इनपुट टोकन पर लिया जाता, और आउटपुट टोकन मुफ्त हैं।

Jev इनपुट के रूप में क्या ले सकता है?

केवल टेक्स्ट, स्ट्रिंग्स, JSON ऑब्जेक्ट्स या टेक्स्ट के एरेज़ के रूप में। दस्तावेज़ में कहा गया है कि इमेज, ऑडियो और वीडियो अभी समर्थित नहीं हैं। कॉन्टेक्स्ट प्रति रिक्वेस्ट 64k टोकन है, जिसमें से 32k स्टेट और सबसे लंबे सवाल के लिए है।

यह किसी LLM से JSON मांगने से किस प्रकार भिन्न है?

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

Jev किस काम में अच्छा नहीं है?

वेंडर का जैग्डनेस पेज शाब्दिक पठन, गणित और संख्याओं, तथा तारीख और समय की तुलना को सूचीबद्ध करता है। यह इनडायरेक्शन, अप्रासंगिक विवरणों से भरे बड़े स्टेट, एडवरसैरियल कंटेंट और विरोधाभासी मानदंडों को भी सूचीबद्ध करता है। अंकगणित के मामले में इसकी प्रलेखित सलाह अंकगणित को कोड में रखने की है।

स्रोत: TypeSafe AI दस्तावेज़ — Introduction, System One, Models, Confidence, और Jev 1.13 jaggedness, docs.typesafe.ai, 18 सितंबर, 2026 तक।