Jev एक AI मॉडल है, जो टेक्स्ट डालने पर एक विकल्प, एक स्कोर या Yes/No की संभावना लौटाता है। यह टेक्स्ट नहीं बनाता। यह उन कामों के लिए उपयुक्त है जहाँ ऐप के भीतर पूछताछ को सही विभाग में भेजने जैसे निर्णय बार-बार लेने पड़ते हैं। इसकी कीमत प्रति 10 लाख इनपुट टोकन $0.042 है, और आउटपुट निःशुल्क है।
विषय-सूची
1. Jev क्या है?
TypeSafe ने 15 सितंबर 2026 को Jev के शुरुआती एक्सेस की घोषणा की। यह लंबी व्याख्या लौटाने वाली चैट के बजाय ऐप के भीतर ऐसे निर्णयों के लिए बनाया गया है, जैसे "इसे कौन-सी टीम देखे" या "यह शर्तों से कितना मेल खाता है"।
इसकी मुख्य खासियत यह है कि लौटाए गए मानों का प्रारूप तय होता है। लेकिन सही प्रारूप वाला उत्तर भी गलत निर्णय हो सकता है। घोषणा में आए "हैलुसिनेशन नहीं" वाक्यांश को अगर कोई यह समझे कि यह किसी भी सामग्री पर सही उत्तर देता है, तो वह इसका गलत इस्तेमाल करेगा।
TypeSafe ने Jev को "System One model" कहा है। घोषणा के अनुसार यह नाम कंपनी का अपना है, जो मनोवैज्ञानिक डैनियल काह्नमैन की पुस्तक Thinking, Fast and Slow में दिए गए अंतर से लिया गया है: तेज़ और सहज "सिस्टम 1" और धीरे-धीरे सोचकर निर्णय लेने वाला "सिस्टम 2"। यह AI के पूरे क्षेत्र के लिए कोई एकीकृत प्रदर्शन श्रेणी नहीं है। आधिकारिक System One व्याख्या इसे ऐसे मॉडल के रूप में बताती है जो प्राकृतिक भाषा को समझता है और टाइप किए गए निर्णय लौटाता है, जिन्हें सॉफ़्टवेयर सीधे इस्तेमाल कर सकता है।
Jev नाम अर्थशास्त्री विलियम स्टैनली जेवन्स के नाम पर है। यह इस विचार को दर्शाता है कि बुद्धिमत्ता की लागत घटने के साथ उसके उपयोग कई गुना बढ़ते हैं, जैसे जेवन्स विरोधाभास में दक्षता बढ़ने से माँग घटने के बजाय बढ़ती है (क्या AI व्हाइट-कॉलर नौकरियाँ खत्म कर देगा?)।
- state
- निर्णय की सामग्री। टेक्स्ट या JSON प्रारूप का डेटा। इसमें पूछताछ का मूल पाठ, उपयोगकर्ता द्वारा चुनी गई मदें, वर्गीकरण के लिए पृष्ठभूमि जानकारी आदि डाली जाती हैं।
- questions
- किस बात का निर्णय लेना है। "इसे किस टीम के पास भेजें?" जैसा सवाल, साथ में विकल्प और निर्णय के मानदंड।
आउटपुट के विकल्प पहले से तय होते हैं, इसलिए "शायद यह तकनीकी टीम का मामला है" जैसे वाक्य से श्रेणी का नाम निकालने की प्रक्रिया की ज़रूरत नहीं होती। दूसरी ओर, जवाब, कोड या तर्क सहित लंबा लेखन इसका काम नहीं है। अगर आप इसे जेनरेटिव AI के साथ जोड़ते हैं, तो काम का बँटवारा ऐसा होगा: Jev तय करता है कि काम किसे जाए, और टेक्स्ट की ज़रूरत होने पर ही जेनरेटिव मॉडल को बुलाया जाता है।
LLM से JSON में उत्तर लेने के तरीके से यह कैसे अलग है?
JSON में उत्तर पाना केवल Jev की खासियत नहीं है। उदाहरण के लिए Claude के पास भी structured outputs हैं, जो आउटपुट को JSON Schema के अनुरूप रखते हैं। अगर आपने पहले से किसी जेनरेटिव मॉडल से वर्गीकरण लागू किया है, तो सिर्फ़ "प्रारूप तय है" कहकर उसे बदलने की ज़रूरत नहीं है।
Jev खास तौर पर विकल्प, स्तरीय रेटिंग और हाँ/ना के निर्णय, उनकी संभावनाओं के साथ लौटाने के लिए बना है। अगर निर्णय के बाद स्पष्टीकरण या जवाब भी चाहिए, तो जेनरेटिव मॉडल लें। अगर टेक्स्ट में से बार-बार विकल्प चुनने हैं, तो Jev भी तुलना के लिए उम्मीदवार है। अगर राशि या तारीख की सटीक गणना करनी है, तो सामान्य कोड लें। काम को इस तरह बाँटें। चुनाव से पहले एक ही इनपुट और मानदंड पर सटीकता, प्रतीक्षा समय और लागत की तुलना करना व्यावहारिक तरीका है।
2. Choice, Score और Noul में अंतर
आधिकारिक Primitives व्याख्या सवालों के प्रकार को तीन भागों में बाँटती है। मिलते-जुलते सवालों में भी चुनाव इस पर होता है कि आपको कौन-सा आउटपुट चाहिए।
Choice: विकल्प चुनें
"बिलिंग", "तकनीकी" और "अन्य" जैसे क्रम-रहित विकल्प तैयार करें और उनमें से एक चुनें।
इस लेख में चुनाव, संभावना और गिनती के आँकड़े उदाहरण के लिए हैं।
जो इनपुट फ़िट न हो, उसके लिए "अन्य" या "निर्णय के लिए जानकारी अपर्याप्त" जैसे विकल्प शामिल करें। अगर विकल्प बहुत सीमित होंगे, तो वर्गीकरण प्रारूप में सही होगा लेकिन असलियत से मेल नहीं खाएगा।
Score: पैमाने पर मापें
क्रमबद्ध 2 से 10 स्तर का वर्णन करता है। लौटाया गया मान हर स्तर की संभावना पर आधारित भारित औसत होता है, इसलिए यह दशमलव में भी हो सकता है।
3 स्तरों की गणना का उदाहरण: मान लें संभावनाएँ 10%, 40% और 50% हैं
कोई जानकारी नहीं
0 × 0.1 = 0
कुछ हिस्सा समझ में आता है
1 × 0.4 = 0.4
दोहराने के चरण पूरे मिल जाते हैं
2 × 0.5 = 1.0
= 1.4
"कुछ हिस्सा समझ में आता है" और "दोहराने के चरण पूरे मिल जाते हैं" के बीच। इसे सटीकता दर के बजाय, परिभाषित 0 से 2 के पैमाने पर एक मान के रूप में पढ़ें।
गणना की विधि का स्रोत: TypeSafe "Primitives" और "API संदर्भ"।
यह तय करने के लिए कि कोई सीमा पार हुई या नहीं, Score का मान इस्तेमाल करना ठीक है। लेकिन आधिकारिक दस्तावेज़ चेताता है कि स्तरों के बीच इंटरपोलेशन करके "1.4 है, तो असली मात्रा लगभग इतनी है" जैसा मान उलटा निकालने से बचें। Jev 1.13 के स्तर संख्यात्मक रूप से कमज़ोर रूप से कैलिब्रेटेड हैं (Jev 1.13 की ज्ञात कमज़ोरियाँ)।
Noul: हाँ की संभावना
सवाल की शर्त साफ़ लिखें, जैसे "क्या मूल पाठ में लिखा है कि सेवा इस समय उपलब्ध नहीं है?"।
0.5 का मतलब है, हाँ और नहीं लगभग बराबर हैं
इसका मतलब "मध्यम गंभीरता" नहीं है। गंभीरता मापनी हो, तो तय स्तरों वाला Score इस्तेमाल करें।
- शर्त कहाँ लिखें
instructionsमें साफ़ लिखें। सवाल की पहचान करने वाली कुंजी मॉडल के तर्क तक नहीं पहुँचती, इसलिए सिर्फ़ सवाल के नाम से मंशा बताने की कोशिश न करें।- confidence फ़ील्ड
- Choice और Score में है, पर Noul में इसका अलग फ़ील्ड नहीं है।
3. प्रकार की गारंटी और निर्णय की सटीकता अलग हैं
TypeSafe की घोषणा जिस प्रकार की गारंटी पर ज़ोर देती है, उसका मतलब है कि आउटपुट परिभाषित विकल्पों या मानों की सीमा तक सीमित रहता है। अगर आप पूछताछ को बिलिंग या तकनीकी टीम में बाँटते हैं, तो यह ऐसा कोई विभाग का नाम मुक्त टेक्स्ट में नहीं बनाएगा जो आपने तय न किया हो। लेकिन सही टीम चुनी जाती है या नहीं, यह अलग सवाल है।
आधिकारिक व्याख्या के अनुसार Choice और Score के confidence का अर्थ है संभावना वितरण कितना केंद्रित है, इसे 0 से 1 की एक संख्या में बताने वाला आँकड़ा। यह डिफ़ॉल्ट मापदंड है। अगर यह आपके उपयोग के अनुकूल न हो, तो उसके साथ लौटाए गए probabilities से आप खुद कोई दूसरा मापदंड निकाल सकते हैं।
- विकल्प आपस में टक्कर में हों
- confidence कम हो जाता है।
- एक ही विकल्प पर केंद्रित हो
- confidence ऊँचा हो जाता है।
इसे "0.9 है, तो यह एक मामला 90% सही है" के रूप में न पढ़ें। संभावना का कैलिब्रेशन कई अनुमानों को मिलाकर परखे जाने वाला गुण है। यह किसी एक मामले के सही होने का संकेत नहीं देता।
व्यवहार में आप confidence के आधार पर शाखा बनाने वाला कोड लिखते हैं। आधिकारिक Confidence पेज में एक ऐसा उदाहरण है, जिसमें उपयोगकर्ता अपना अनुरोध "बैलेंस देखें", "लंबित निकासी स्वीकृत करें" या "सहायता" में से चुनता है, और उसके बाद इस तरह की शाखा दी गई है (अंश; टिप्पणियाँ लेखक ने अनुवादित की हैं)।
if confidence < 0.5:
# मॉडल सचमुच असमंजस में है। अनुमान न लगाएँ
route_to_human(user_message)
elif action.choice == "check_balance":
# प्रभाव कम है। अलग स्क्रीन दिखाने से बदलाव वापस हो सकता है
show_balance(account_id)
elif action.choice == "approve_transfer":
if confidence > 0.9:
# प्रभाव बड़ा है और भरोसा ऊँचा है। पुष्टि करके निष्पादित करें
confirm_then_execute(account_id)
else:
# प्रभाव बड़ा है, भरोसा मध्यम है। पहले पुष्टि करें
ask_user_to_confirm(account_id)
0.5 की निचली सीमा उन मामलों को पकड़ने के लिए है जिनमें मॉडल ने संकेत दिया है कि वह सचमुच असमंजस में है। इसके ऊपर, निकासी की स्वीकृति जैसी उलटी न हो सकने वाली कार्रवाई के लिए केवल-पढ़ने वाली कार्रवाई से ऊँची सीमा रखी गई है। ध्यान दें कि 0.9 से ऊपर होने पर भी कोड तुरंत निष्पादित नहीं करता, पहले पुष्टि माँगता है। ऊँचा confidence निष्पादन की अनुमति का विकल्प नहीं है।
0.5 और 0.9 उदाहरण हैं, अनुशंसित मान नहीं। आधिकारिक दस्तावेज़ भी कहता है कि उपयुक्त मान क्षेत्र और आपके उपयोग में मॉडल के प्रदर्शन पर निर्भर करते हैं। वह सलाह देता है कि सावधानी भरी सीमाओं से शुरू करें और अपने डेटा पर उन्हें समायोजित करें।
4. पूछताछ को सही विभाग में भेजने का एक उदाहरण
मान लीजिए कोई पूछताछ कहती है: "मैं अपने इनवॉइस का डाउनलोड बटन दबाता हूँ, लेकिन कुछ नहीं होता।" अगर "इनवॉइस" शब्द देखकर इसे बिलिंग टीम को भेज दिया जाए, तो स्क्रीन की गड़बड़ी छूट जाएगी। अगर Jev से निर्णय करवाना है, तो हर टीम की सीमाएँ समझाएँ और फिर उसे एक विकल्प चुनने दें।
आधिकारिक Quick start और API संदर्भ के अनुसार लिखा गया अनुरोध इस रूप का होगा। API कुंजी लें और POST https://api.typesafe.ai/v1/systemone पर JSON भेजें।
{
"model": "jev-1.13.0",
"state": "I press the download button for my invoice, but nothing happens.",
"questions": {
"team": {
"type": "choice",
"instructions": "संदेश के मुख्य अनुरोध से मेल खाने वाला टीम विकल्प चुनें।",
"criteria": {
"billing": "बिल की राशि, भुगतान के तरीके या दोहरे शुल्क के बारे में पूछताछ।",
"technical": "स्क्रीन संचालन, त्रुटियाँ, या ऐसी सुविधाएँ जो काम नहीं कर रहीं।",
"review": "कई अनुरोध मिले हुए हैं, या यह तय करने के लिए जानकारी अपर्याप्त है कि किसे सौंपा जाए।"
}
},
"service_unavailable": {
"type": "noul",
"instructions": "क्या संदेश में बताया गया है कि कोई स्क्रीन या सुविधा इस समय उपलब्ध नहीं है?"
}
}
}
भेजना और उत्तर मिलने के बाद की प्रक्रिया
व्यवस्थापक पैनल से API कुंजी प्राप्त करें, और HTTP हेडर में Authorization: Bearer <API_KEY> और Content-Type: application/json सेट करें। कुंजी को सर्वर पर एनवायरनमेंट वेरिएबल जैसे तरीकों से प्रबंधित करें, और सार्वजनिक HTML या रिपॉज़िटरी में न डालें।
कनेक्शन की जाँच के लिए आप आधिकारिक Quick start में दिए गए curl उदाहरण को जैसा है वैसा चिपकाकर चला सकते हैं। कुंजी को एनवायरनमेंट वेरिएबल TYPESAFE_API_KEY में रखें, फिर चलाएँ। यह उदाहरण Noul के ज़रिए पूछता है कि अंग्रेज़ी पूछताछ में तात्कालिकता दिख रही है या नहीं।
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d @- <<'EOF'
{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"urgency": {
"type": "noul",
"instructions": "क्या यह संदेश तात्कालिकता व्यक्त करता है?"
}
}
}
EOF
ऊपर का रूटिंग उदाहरण भेजना हो, तो <<'EOF' और EOF के बीच के JSON को उसी JSON से बदलें। कोड से कॉल करते समय, या ऐसे एजेंट के लिए जो विकास में मदद करता है और उसे विनिर्देश पढ़ने हैं, आधिकारिक दस्तावेज़ ये प्रवेश बिंदु देता है।
- Python से कॉल करना:
pip install typesafe-sdk(Python 3.10 या उससे नया)। SDK क्लाइंट एनवायरनमेंट वेरिएबलTYPESAFE_API_KEYपढ़ता है और डिफ़ॉल्ट रूप सेjev-latestको कॉल करता है। - Claude Code के साथ विकास:
claude plugin marketplace add typesafe-ai/skillsके बादclaude plugin install typesafe@typesafe-ai। इससे एक आधिकारिक स्किल इंस्टॉल होती है, जो कोडिंग एजेंट को तीन प्रकार के सवाल और डिज़ाइन पैटर्न देती है (Agent skill)।
ऊपर के रूटिंग उदाहरण पर लौटें, तो पढ़े जाने वाले फ़ील्ड और उनका उपयोग नीचे दिए चित्र और तालिका में है। Choice से टीम का विकल्प मिलता है, और Noul से पता चलता है कि अनुपलब्ध सुविधा की रिपोर्ट है या नहीं।
| पढ़ा जाने वाला फ़ील्ड | मान का उदाहरण / अर्थ | आपके ऐप में क्या करें |
|---|---|---|
team.choice | technical (तकनीकी टीम) | टीम का विकल्प दिखाएँ |
team.probabilities | {"technical": 0.80, "billing": 0.15, "review": 0.05} | देखें कि विकल्पों के बीच निर्णय बँटा हुआ तो नहीं है |
team.confidence | संभावना वितरण से निकाली गई केंद्रितता | इसे अपने मूल्यांकन डेटा से तय की गई शर्त से मिलाएँ |
service_unavailable.noul | 0.85 (अनुपलब्धता की रिपोर्ट के रूप में आंका गया) | गंभीरता से न मिलाएँ; पुष्टि के लिए एक मद के रूप में उपयोग करें |
हर फ़ील्ड answers के अंतर्गत है। जब विकल्प आपस में टक्कर में हों, जानकारी अपर्याप्त हो, या उत्तर न मिल सके, तो समीक्षा के लिए लंबित गंतव्य भी तैयार रखें। प्रकारों का आधार: TypeSafe "API संदर्भ"।
- 401 और 422: सेटिंग या इनपुट ठीक करें
- 401 का मतलब है कुंजी गायब या अमान्य है; 422 का मतलब है इनपुट प्रारूप की जाँच विफल रही। सेटिंग या संदेश ठीक करें, फिर दोबारा भेजें।
- 429 और 529: रुकें, फिर दोबारा कोशिश करें
- जल्दी-जल्दी दोहराएँ नहीं; प्रतीक्षा समय धीरे-धीरे बढ़ाएँ। आधिकारिक SDK डिफ़ॉल्ट रूप से यह दोबारा कोशिश अपने-आप करता है।
HTTP त्रुटियाँ, कम confidence से अलग हैं। इन्हें उत्तर का मान न मानें। आधार ऊपर दिया गया API विनिर्देश है।
शुरुआत में आप मौजूदा रूटिंग को बिना बदले भी काफ़ी कर सकते हैं: व्यक्ति द्वारा तय की गई टीम को Jev के विकल्पों के साथ बगल-बगल रख दें। जाँचें कि "इनवॉइस" शब्द होने पर भी तकनीकी समस्या सही जगह जाती है या नहीं, कई अनुरोधों वाले संदेश समीक्षा के लिए भेजे जा सकते हैं या नहीं, और जानकारी कम होने पर बिना सोचे-समझे फ़ैसला तो नहीं किया जा रहा। गलती मिले तो उसे विफलता के उदाहरण में जोड़ें, और देखें कि विकल्पों के विवरण आपस में तो नहीं मिल रहे।
AI एजेंट में इसे शामिल करते समय "निर्णय लेने वाला मॉडल", "निष्पादन करने वाले टूल" और "निष्पादन की अनुमति देने वाली शर्तें" अलग रखें, और राशि की गणना और अनुमति की जाँच कोड में ही रखें। इससे गलत निर्णय होने पर पता लगाना आसान होता है कि गलती कहाँ हुई।
TypeSafe के आधिकारिक दस्तावेज़ में अन्य उदाहरण भी हैं: LLM ऐप के लिए गार्डरेल, RAG से लाए गए दस्तावेज़ों का चयन, खोज परिणामों का पुनः क्रम, और उद्धरणों का सत्यापन। गार्डरेल या दस्तावेज़ चयन के लिए इसका उपयोग करें, तब भी अगले अनुभाग में बताई "उत्तर की ओर ले जाने वाले इनपुट" की कमज़ोरी बनी रहती है। (इनपुट और आउटपुट, दोनों पर रोकने की सोच AI गार्डरेल क्या हैं? में समझाई गई है।)
5. जो काम उपयुक्त नहीं हैं और ज्ञात कमज़ोरियाँ
TypeSafe Jev 1.13 की ज्ञात कमज़ोरियाँ सार्वजनिक करता है। "सिर्फ़ निर्णय के लिए है, इसलिए सटीक होगा" यह मान न लें। काम को इस तरह बाँटें।
| जिस स्थिति में यह कमज़ोर है | संभावित समस्या | डिज़ाइन का उपाय |
|---|---|---|
| गिनना और गणना करना | अक्षरों की संख्या, मदों की गिनती या सटीक संख्याएँ गड़बड़ा जाती हैं | पार्सर या सामान्य कोड से गणना करें |
| तारीखों की तुलना करना | क्रम या किसी अवधि में होने के निर्णय अस्थिर हो जाते हैं | ज़रूरी तत्व निकालें और उन्हें तारीख के प्रकार के रूप में तुलना करें |
| दोहरा नकार और घुमावदार सवाल | मंशा के बजाय शब्दों की सतह से प्रभावित होता है | शर्त सीधे लिखें और कई निर्णयों को अलग करें |
| बहुत सारी अप्रासंगिक जानकारी वाला इनपुट | निर्णय के लिए ज़रूरी न होने वाली जानकारी बाधा बनती है | पहले खोजें और निकालें, फिर केवल ज़रूरी मदें भेजें |
| उत्तर की ओर ले जाने वाले इनपुट | टेक्स्ट में मौजूद निर्देशों से, या इस दावे से प्रभावित होता है कि उसे खुद को कैसे वर्गीकृत करना चाहिए | ऐसी विफलता के उदाहरणों से परखें जिनमें इस तरह के इनपुट शामिल हों, और निष्पादन की अनुमति अलग से प्रबंधित करें |
| instructions और criteria में असंगति | अगर सवाल और मानदंड अलग चीज़ें माँगें, तो भ्रम हो सकता है (उदाहरण: Noul में true को "नहीं" का अर्थ देने से सटीकता घटती है) | criteria को सवाल के विस्तार के रूप में लिखें, और दोनों की दिशा एक जैसी रखें |
| मुक्त टेक्स्ट का निर्माण | जवाब, स्पष्टीकरण या कोड बनाने के लिए उपयुक्त नहीं है | टेम्पलेट या जेनरेटिव मॉडल का उपयोग करें |
साथ ही, अलग-अलग पूछे गए हाँ/ना के संभावना मान गणितीय संबंध को पूरा करें, यह ज़रूरी नहीं। अगर एक ही शर्त और उसके नकार को अलग-अलग Noul सवालों से पूछा जाए, तो योग 1 होगा, यह तय नहीं है; और Choice की संभावनाओं और Noul की संभावनाओं को एक ही सीमा से नहीं आँका जा सकता। सवाल का रूप बदलने पर पिछले समायोजित मानों को दोबारा इस्तेमाल करने के बजाय फिर से मूल्यांकन करें।
हिंदी में उपयोग करते समय जाँचने योग्य बातें
6. कीमत, इनपुट सीमा और गति को कैसे पढ़ें
21 सितंबर 2026 को देखे गए TypeSafe के Models पेज में वर्तमान मॉडल jev-1.13.0 बताया गया था। 14 अक्टूबर 2026 को jev-1.14.0 भी जारी किया गया (कीमत और संदर्भ लंबाई वही हैं)। 19 अक्टूबर को जाँच के समय, उपनाम jev-latest (स्थिर संस्करण) 1.13 की ओर इशारा करता था, और jev-preview 1.14 की ओर। नया संस्करण आने पर उपनाम बदल जाते हैं, इसलिए स्थिर परिणाम चाहिए तो संस्करण वाला ID तय करें। कीमत प्रति 10 लाख इनपुट टोकन $0.042 है, और आउटपुट टोकन निःशुल्क हैं। यह प्रति पूछताछ तय शुल्क नहीं है; यह state और questions सहित इनपुट टोकनों की संख्या के अनुसार बदलता है। मोटे पैमाने के लिए, आधिकारिक Quick start के उत्तर उदाहरण (तीन वाक्यों की अंग्रेज़ी पूछताछ, तीन सवाल) में usage.input_tokens कुछ सौ टोकनों के आसपास दिखाया गया है। घोषणा में TypeSafe यह भी लिखता है कि वह अभी यह साबित नहीं कर सकता कि यह कीमत सब्सिडी के बिना है, और इसे लंबे समय में ही दिखाया जा सकेगा। कंपनी को उम्मीद है कि कीमतें बढ़ने के बजाय घटेंगी।
64k और 32k की दोहरी सीमा
शर्त 1: पूरा अनुरोध
64k टोकन तक
शर्त 2: state + सबसे लंबा सवाल
32k टोकन तक
दोनों को पूरा करना ज़रूरी है। इसका मतलब यह नहीं कि 64k का दस्तावेज़ सीधे state में डाला जा सकता है। यह डिफ़ॉल्ट है। अगर अनुरोध में TypeSafe-Danger-Zone-Long-Context: true हेडर जोड़ें, तो दोनों सीमाएँ 262k टोकन तक बढ़ जाती हैं। कीमत वही रहती है, लेकिन आधिकारिक दस्तावेज़ बताता है कि इससे धीमापन बढ़ता है और सटीकता घटती है।
इनपुट केवल टेक्स्ट है। चित्र, ऑडियो और वीडियो सीधे नहीं भेजे जा सकते, इसलिए उन्हें पहले किसी अलग प्रक्रिया से टेक्स्ट या संरचित डेटा में बदलना होगा।
रेट सीमा बदल सकती है
रेट सीमा संगठन के हिसाब से तय होती है, और अपने संगठन की सीमा डेवलपर कंसोल में देखें (19 अक्टूबर 2026 तक के Models पेज के अनुसार; पहले वहाँ निश्चित संख्याएँ दी गई थीं)। इकाइयाँ प्रति सेकंड टोकन और प्रति सेकंड अनुरोध हैं, और किसी एक को पार करने पर 429 Too Many Requests लौटता है। आधिकारिक SDK डिफ़ॉल्ट रूप से बैकऑफ़ के साथ दोबारा कोशिश करता है, और अगर उत्तर में retry-after हेडर हो, तो उसका पालन करता है। अगर आप HTTP API को सीधे कॉल करते हैं, तो ऊपर बताए अनुसार प्रतीक्षा समय बढ़ाते हुए दोबारा कोशिश करने वाला तर्क खुद लिखें।
आधिकारिक दस्तावेज़ ध्यान दिलाता है कि माँग बहुत अधिक होने के कारण सीमाएँ गतिशील रूप से समायोजित की जाती हैं, और वे बिना सूचना के बदल सकती हैं। ऊँची सीमाएँ कस्टम या एंटरप्राइज़ अनुबंधों में उपलब्ध हैं। अगर आपका डिज़ाइन एक बार में बड़ी मात्रा में टेक्स्ट भेजता है, तो शुरू करते समय मान जाँच लें, और सीमा तक पहुँचने पर प्रतीक्षा का तरीका पहले से तय कर लें।
गति और लागत की तुलना एक ही काम पर करें
TypeSafe अपनी घोषणा में अनुरोध से परिणाम मिलने तक का समय 70 ms से 500 ms बताता है। लेकिन कंपनी के सार्वजनिक मूल्यांकन मुख्य रूप से अमेरिका के पश्चिमी तट (जहाँ सेवा का आधार है) पर उसके अपने लैपटॉप से चलाए गए थे।
जेनरेटिव मॉडलों की तुलना में वह यह आँकड़ा देता है: "193.6 गुना तेज़, और 444.6 गुना सस्ता"। यह कंपनी द्वारा बनाए गए वर्कफ़्लो मूल्यांकन से आता है, और TypeSafe खुद मानता है कि वास्तव में मिल सकने वाले सुधारों में यह ऊँचे सिरे पर है। वह कहता है कि मूल्यांकन के वर्कफ़्लो अपने मॉडल के पक्ष में चुने नहीं गए थे और प्रशिक्षण डेटा में शामिल नहीं हैं, लेकिन यह भी लिखता है कि उन्हें अपनी ही मॉडल क्षमता टीम के सदस्यों ने बनाया था, इसलिए पक्षपात संभव है। दोनों को विक्रेता के अपने आँकड़ों के रूप में पढ़ें, और नीचे दी गई बातों का ध्यान रखते हुए अपने काम पर तुलना करें।
- शर्तें बदलने पर परिणाम भी बदलते हैं: नेटवर्क की दूरी, इनपुट की लंबाई, सवालों की संख्या और तुलना वाले मॉडल की सेटिंग एक जैसी रखकर देखें।
- सामान्य चैट से गुणक तुलना के लिए उपयोग नहीं हो सकता: आधिकारिक तुलना में जेनरेटिव मॉडल से संभावना वितरण निकालने की प्रक्रिया भी शामिल है।
व्यवहार में किन चीज़ों की तुलना करें
- लागत: API इकाई मूल्य और संचालन का प्रयास
- इसमें प्री-प्रोसेसिंग, दोबारा कोशिश और समीक्षा की प्रतीक्षा का हिस्सा भी शामिल करें। वर्गीकरण सस्ता हो, फिर भी मानव समीक्षा बढ़ जाए, तो कुल प्रयास कम नहीं होता।
- गति: औसत और धीमे अनुरोध
- भीड़ के समय या धीमे उत्तरों के दौरान भी काम न रुके, यह जाँचें।
7. आज़माते समय क्या जाँचें
शुरुआत Playground से करें, और देखें कि आपके सवालों की शर्तें स्पष्ट रूप से पहुँचती हैं या नहीं। आधिकारिक Quick start में Playground और API कुंजी लेकर कॉल करने के चरण दिए गए हैं। यह अभी शुरुआती एक्सेस में है, इसलिए पहले लॉगिन के बाद अपनी उपयोग अनुमति जाँचें।
① संदेश डालें
पहुँच हो, तो पूछताछ का पाठ Playground में टाइप करें।
② विकल्प सेट करें
Choice से टीम के विकल्प और उनकी सीमाएँ तय करें।
③ शब्द बदलकर तुलना करें
विकल्पों और संभावनाओं में बदलाव देखें। यह निष्पादन वातावरण तैयार करने से पहले भी किया जा सकता है।
मूल्यांकन में ध्यान रखने योग्य 4 बातें
सही उत्तर और सीमाएँ तैयार करें।
जिन उदाहरणों में लोगों ने टीम तय की है, उनके साथ कई अनुरोध, बहुत छोटे वाक्य, नकार और उत्तर की ओर ले जाने वाले वाक्य भी शामिल करें। वास्तविक डेटा इस्तेमाल करते समय पुष्टि करें कि उस सामग्री को बाहर भेजने की अनुमति है।
सवाल की शर्तें स्थिर करें।
लिखें कि हर विकल्प किसे माना जाएगा, और किन स्थितियों में "अन्य" में भेजा जाएगा। शर्तें समायोजित करने में इस्तेमाल किए उदाहरणों से अलग उदाहरणों पर भी जाँच करें।
सटीकता और समीक्षा के लिए भेजे गए हिस्से को एक साथ देखें।
हर सीमा पर स्वचालित रूप से निपटाए गए मामलों की गिनती करें, और उनमें गलत निर्णयों की गिनती भी। समीक्षा की प्रतीक्षा में गए मामलों की संख्या भी साथ लिखें, ताकि सिर्फ़ सटीकता ऊँची न दिखे।
मॉडल और सवालों को दर्ज करें।
मॉडल ID, इनपुट का प्रकार, सवालों का संस्करण, उत्तर और प्रसंस्करण समय दर्ज करें, और बदलावों से पहले और बाद की तुलना करें।
1 वर्ग = 1 मामला।
स्वचालित प्रसंस्करण दर
80%
80 मामले ÷ कुल 100
स्वचालित रूप से निपटाए गए मामलों में त्रुटि दर
5%
गलत वर्गीकरण 4 ÷ स्वचालित 80
मानव जाँच
20 मामले
कुल 100 − स्वचालित 80
तीनों को एक साथ देखें। सिर्फ़ 100 मामलों से उत्पादन में सटीकता सिद्ध नहीं होती।
अपने काम पर लागू करना हो तो
- तय विकल्पों वाले निर्णय को बड़ी मात्रा के टेक्स्ट पर बार-बार लगाना
- Jev को तुलना का उम्मीदवार मानें। अपने इनपुट, शर्तों और भाषा पर इसकी सटीकता का मूल्यांकन करें।
- जवाब, स्पष्टीकरण या कोड जैसा टेक्स्ट लिखना
- जेनरेटिव मॉडल या टेम्पलेट इस्तेमाल करें।
- राशि या तारीख की सटीक गणना करना
- सामान्य कोड से प्रोसेस करें।
इस लेख का आधार: TypeSafe की घोषणा और आधिकारिक दस्तावेज़ (21 सितंबर 2026 को जाँचा गया, 19 अक्टूबर को अपडेट की पुष्टि की गई)। लेखक ने API नहीं चलाया है, और हिंदी में सटीकता या वास्तविक प्रतीक्षा समय नहीं मापा है।
FAQ
प्र. क्या Jev ChatGPT की तरह बातचीत कर सकता है?
उ. यह मुक्त रूप से जवाब लिखने वाला मॉडल नहीं है। आप टेक्स्ट डालते हैं और Choice, Score या Noul से तय प्रारूप में निर्णय पाते हैं। जवाब या स्पष्टीकरण के टेक्स्ट की ज़रूरत हो, तो इसे जेनरेटिव मॉडल या टेम्पलेट के साथ जोड़ें।
प्र. अगर "हैलुसिनेशन नहीं" है, तो क्या यह गलती नहीं करेगा?
उ. आउटपुट को प्रकार या विकल्पों तक सीमित रखना और सामग्री का सही निर्णय करना, दो अलग बातें हैं। आधिकारिक दस्तावेज़ में भी गणना, तारीखों, बहुत अप्रासंगिक जानकारी वाले इनपुट और उत्तर की ओर ले जाने वाले वाक्यों जैसी कमज़ोरियाँ दर्ज हैं। आपको अपने डेटा से सटीकता मापनी होगी।
प्र. Noul का 0.5 क्या मध्यम होने का मतलब है?
उ. इसका मतलब है कि हाँ और नहीं लगभग बराबर संभावना के साथ आँके गए हैं। यह गंभीरता या गुणवत्ता के बीच के बिंदु को दर्शाने वाला मान नहीं है। मात्रा मापनी हो, तो व्याख्या वाले स्तरों वाला Score उम्मीदवार है।
प्र. क्या इसे हिंदी में इस्तेमाल कर सकते हैं?
उ. आधिकारिक दस्तावेज़ कहता है कि यह CJK लिपियों सहित अंग्रेज़ी के अलावा अन्य भाषाएँ भी प्रोसेस करता है, लेकिन बताता है कि अंग्रेज़ी मुख्य प्रशिक्षण भाषा है और इस समय सटीकता भी सबसे अच्छी अंग्रेज़ी में है। व्यावसायिक काम में उपयोग से पहले हिंदी मूल्यांकन डेटा से जाँच लें।
प्र. क्या इसका उपयोग चित्र या ऑडियो के निर्णय के लिए हो सकता है?
उ. मौजूदा मॉडल का इनपुट केवल टेक्स्ट है, इसलिए चित्र या ऑडियो सीधे नहीं दिए जा सकते। अगर आपका डिज़ाइन किसी अन्य प्रक्रिया से मिले अक्षर या संरचित डेटा भेजता है, तो उस प्री-प्रोसेसिंग की गलतियों सहित मूल्यांकन करें।