जेव (Jev) का स्पष्ट विवरण

हमने LLMs का उपयोग हर AI समस्या के लिए, यहाँ तक कि सरल निर्णयों के लिए भी, एक हथौड़े की तरह किया है। Jev उन निर्णयों को मिलीसेकंड में और लागत के बहुत कम हिस्से में संभालता है। आइए समझते हैं कि यह कैसे काम करता है और यह कहाँ फिट बैठता है।

TypeSafe AI ने 15 सितंबर, 2026 को Jev लॉन्च किया, और उस प्रतिक्रिया ने एक ऐसे मॉडल के लिए असामान्य रूप से मजबूत प्रभाव डाला जो न तो बातचीत कर सकता है, न कोड लिख सकता है, और न ही एक भी उपयोगी पैराग्राफ उत्पन्न कर सकता है।

खैर, यह सीमा ही इसका मुख्य बिंदु है।

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

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

Jev विशेष रूप से इन निर्णयों के लिए बनाया गया है। TypeSafe इसे System One मॉडल कहता है: अनसंरचित स्थिति (unstructured state) अंदर जाती है, और टाइप्ड उत्तर तथा प्रायिकताएं (probabilities) बाहर आती हैं।

आइए देखें कि इसका क्या मतलब है, यह कहाँ फिट बैठता है, और कहाँ मार्केटिंग को थोड़ी संयम की जरूरत है।

पहले वह समस्या जिसका समाधान Jev कर रहा है

LLMs सॉफ्टवेयर से जुड़ने में बहुत आसान हो गए जब tool calling और structured outputs उपलब्ध हुए।

Tool calling मॉडल को एक पूर्वानुमानित आकार में फंक्शन का अनुरोध करने देता है। Structured outputs उसे एक स्कीमा का पालन करने वाला JSON लौटाने देते हैं। दोनों ने बड़ी मात्रा में नाज़ुक पार्सिंग को हटा दिया।

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

अब इसे एक agent loop के अंदर रखें।

1while not done:
2    action = llm(context)
3    result = run_tool(action)
4    context += result

मॉडल को टूल चुनने, परिणाम का आकलन करने, जोखिम का पता लगाने, कार्य पूरा होने का निर्णय लेने और अगला मॉडल चुनने के लिए दोबारा कॉल किया जा सकता है। एक single agent run में कई such calls हो सकते हैं जिनमें judgment की आवश्यकता होती है लेकिन generated prose की नहीं।

Jev उन calls को निशाना बनाता है।

इसका दांव सरल है: जब कोड पहले से ही संभावित उत्तरों को जानता है, तो भाषा जनरेशन गलत इंटरफ़ेस है।

Jev वास्तव में क्या है

सबसे छोटा सटीक वर्णन इसे एक semantic decision engine कहता है।

आप Jev को दो चीजें भेजते हैं:

• State: वर्तमान स्थिति का वर्णन करने वाला टेक्स्ट या JSON।
• Questions: वे निर्णय जो आप उस स्थिति के बारे में चाहते हैं कि वह ले।

प्रत्येक प्रश्न पहले से अपने उत्तर का आकार घोषित करता है। Jev तीन primitives का समर्थन करता है:

• Choice आपके द्वारा परिभाषित सूची में से एक विकल्प चुनता है और प्रत्येक विकल्प के लिए एक probability लौटाता है।
• Score इनपुट को आपके द्वारा परिभाषित एक क्रमबद्ध स्केल पर रखता है, जैसे low, medium, और high।
• Noul एक हाँ या नहीं प्रश्न का उत्तर देता है और true होने की probability लौटाता है।

Noul Boolean-style primitive के लिए TypeSafe का नाम है। असामान्य नाम आउटपुट (एक संख्या 0 और 1 के बीच जिस पर आपका कोड कार्रवाई कर सकता है) की तुलना में कम महत्वपूर्ण है।

1{
2  "model": "jev-latest",
3  "state": "The deploy failed twice and customers are seeing 500s.",
4  "questions": {
5    "urgent": {
6      "type": "noul",
7      "instructions": "Does this need attention right now?"
8    },
9    "owner": {
10      "type": "choice",
11      "instructions": "Which team should handle this?",
12      "criteria": {
13        "engineering": "Product failures and outages",
14        "billing": "Charges, invoices, and refunds",
15        "sales": "Pricing and new accounts"
16      }
17    }
18  }
19}

Response में एक urgency probability और तीन टीमों पर एक probability distribution होती है। व्याख्या करने के लिए कोई पैराग्राफ नहीं है और मॉडल द्वारा आविष्कार किए जाने के लिए चौथी टीम नहीं है।

आपका प्रोग्राम नियंत्रण बनाए रखता है:

1if urgent > 0.9 and owner == "engineering":
2    page_on_call()
3elif confidence < 0.6:
4    send_to_human_review()
5else:
6    add_to_queue(owner)

यही कारण है कि लोग Jev को एक smart switch statement कहते रहते हैं। यह वाक्यांश तिरस्कारपूर्ण लगता है, लेकिन यह डिज़ाइन के उपयोगी हिस्से को कैप्चर करता है। साधारण कोड branches का स्वामी होता है। मॉडल वह fuzzy judgment प्रदान करता है जिसे साधारण कोड विश्वसनीय रूप से गणना नहीं कर सकता।

LLM से महत्वपूर्ण अंतर

एक traditional LLM और Jev दोनों support ticket को classify कर सकते हैं। वे उत्तर तक अलग-अलग तरीकों से पहुँचते हैं और सिस्टम के विभिन्न हिस्सों में उपयोगी होते हैं।

TypeSafe कहता है कि Jev एक request में प्रत्येक प्रश्न को parallel में evaluate करता है। इससे workflow को डिज़ाइन करने का तरीका बदल जाता है। एक प्रश्न पूछने, इंतजार करने और तय करने के बजाय कि अगला प्रश्न कौन सा आएगा, आप एक ही request में उसी state के बारे में सभी स्वतंत्र प्रश्न पूछ सकते हैं और कोड को वे उत्तर दे सकते हैं जिनकी उसे आवश्यकता है।

कंपनी 70 से 500 milliseconds के बीच end-to-end latency और प्रति million input tokens $0.042 की कीमत रिपोर्ट करती है, output मुफ्त है। इसके headline claims बताते हैं कि यह comparable LLM workflows की तुलना में लगभग 200 गुना तेज और 400 गुना सस्ता है।

ये बड़े multiples TypeSafe के own workflow evaluations से आते हैं और तुलना के अनुकूल छोर पर स्थित होते हैं। उन्हें हर application के लिए एक ceiling के रूप में मानें, promise के रूप में नहीं। अंतर्निहित लाभ अब भी विश्वसनीय है, जो यह दर्शाता है कि Jev long reasoning traces और generated output से बचता है क्योंकि इसे bounded decisions के लिए डिज़ाइन किया गया था।

Probabilities क्यों महत्वपूर्ण हैं

एक typed answer समस्या का केवल आधा हिस्सा हल करता है।

मान लीजिए Jev एक ticket को billing पर route करता है। चुना गया label आपको बताता है कि कौन जीता। Probability distribution आपको बताती है कि दौड़ कितनी करीबी थी।

1{
2  "choice": "billing",
3  "probabilities": {
4    "billing": 0.52,
5    "technical": 0.46,
6    "sales": 0.02
7  },
8  "confidence": 0.18
9}

उस ticket को स्वचालित रूप से route करना लापरवाही होगी। Billing जीता, लेकिन मुश्किल से। एक low-confidence उत्तर को एक अलग branch को ट्रिगर करना चाहिए।

यह developers को एक practical pattern देता है:

• High confidence: जब consequence छोटा हो तो स्वचालित रूप से कार्रवाई करें।
• Medium confidence: पुष्टि मांगें या एक stronger model को कॉल करें।
• Low confidence: मामले को किसी व्यक्ति को भेजें या अधिक जानकारी इकट्ठा करें।

Thresholds कोड में होते हैं, जहाँ उन्हें review और change किया जा सकता है। एक dashboard label weak prediction को tolerate कर सकता है। एक command जो data delete करती है, उसे एक बहुत ऊंची bar की आवश्यकता होनी चाहिए।

TypeSafe Reinforcement Learning for Calibrated Decisions, या RLCD का उपयोग करके Jev को train करता है। लक्ष्य यह है कि confidence कई predictions में accuracy को reflect करे। यदि एक मॉडल एक सेट उत्तरों को 90 percent probability देता है, तो उन उत्तरों का लगभग 90 percent सही होना चाहिए।

Hallucination claim को precision की आवश्यकता है

TypeSafe कहता है कि Jev hallucinate नहीं कर सकता। यह कथन केवल एक narrow definition के तहत सत्य है।

Jev schema के बाहर कोई विकल्प लौटा नहीं सकता। यदि आप billing, technical, और sales को परिभाषित करते हैं, तो response legal को invent नहीं कर सकती है। यह malformed prose भी उत्पन्न नहीं कर सकता जहाँ आपका कोड एक label की अपेक्षा कर रहा था।

लेकिन यह confidently गलत valid option चुन सकता है।

Type safety invalid shapes को रोकता है। यह सही judgment की गारंटी नहीं देता। यह अंतर महत्वपूर्ण है क्योंकि एक schema-valid mistake अब भी गलत customer को refund कर सकती है, incident को incorrectly route कर सकती है, या dangerous command को approve कर सकती है।

एक सुरक्षित वाक्य है "Jev declared output schema को तोड़ नहीं सकता, लेकिन यह अब भी गलत हो सकता है"।

Agent के अंदर Jev कहाँ फिट बैठता है

Jev सबसे अच्छा तब काम करता है जब इसका उपयोग एक LLM के साथ किया जाए, उसे replace करने के बजाय।

LLM उन कार्यों को संभालता है जिनके लिए language या deeper reasoning की आवश्यकता होती है। यह plan करता है, लिखता है, explain करता है, और tools का उपयोग करता है। Jev उस काम के आसपास frequent decisions को संभालता है।

तीन placements विशेष रूप से आकर्षक हैं।

Model routing

एक simple lookup को architecture review के लिए समान मॉडल की आवश्यकता नहीं होती है। Jev request को score कर सकता है और सबसे कम महंगा मॉडल चुन सकता है जो इसे पूरा करने की संभावना रखता है।

1route = jev.choice(
2    state=user_request,
3    options={
4        "fast": "Lookups, extraction, and small local edits",
5        "powerful": "Architecture, ambiguity, and high-stakes work",
6    },
7)
8
9model = fast_model if route == "fast" else powerful_model

Router request का उत्तर नहीं देता। यह तय करता है कि कौन सा मॉडल देना चाहिए।

Tool risk gating

इससे पहले कि एक agent shell command चलाए, Jev इसे read-only, reversible, या destructive के रूप में classify कर सकता है। अलग-अलग प्रश्न यह जांच सकते हैं कि क्या यह files delete करता है, Git history बदलता है, production को छूता है, या repository को छोड़ता है।

High-confidence read-only actions जारी रख सकते हैं। Destructive या uncertain actions human approval के लिए रुक सकते हैं। LangChain’s Jev integration इस pattern को middleware के माध्यम से लागू करता है जो execution से पहले tool call को check करता है।

Verification and supervision

एक agent दावा कर सकता है कि task finished है जबकि tests अब भी fail हो रहे हैं। Jev state का निरीक्षण कर सकता है और bounded questions का उत्तर दे सकता है: क्या tests pass हुए? क्या agent वही action दोहरा रहा है? क्या output policy का पालन करता है? क्या इस result को review किया जाना चाहिए?

यह hard test को replace नहीं करेगा जब एक मौजूद हो। यह semantic check जोड़ता है जहाँ rule meaning पर निर्भर करता है।

समस्याएं जो Jev आज हल कर सकता है

सर्वश्रेष्ठ use cases तीन properties साझा करते हैं। आप संभावित उत्तरों को नाम दे सकते हैं, एक सावधान इंसान इनपुट का जल्दी आकलन कर सकता है, और निर्णय इतनी बार होता है कि latency या cost मायने रखता है।

Support and operations

• Intent, urgency, department, spam, और customer frustration को classify करें।
• Refunds और policy exceptions को कई छोटे checks के माध्यम से route करें।
• Logs और incidents को semantic severity के आधार पर rank करें इससे पहले कि कोई इंसान उन्हें पढ़े।

एक single request उसी ticket के बारे में ये सभी प्रश्न पूछ सकता है। फिर कोड उत्तरों को company की actual routing policy में combine करता है।

Search and retrieval

• Retrieved passages को rerank करें कि क्या वे query का उत्तर देते हैं।
• जांचें कि क्या citation एक claim का समर्थन करता है।
• Irrelevant chunks को filter करें इससे पहले कि context एक expensive LLM को भेजा जाए।

Embeddings semantically related text ढूंढने में उत्कृष्ट हैं। Jev एक narrower decision ले सकता है कि क्या एक particular passage इस प्रश्न के लिए उपयोगी है।

Quality and safety

• Jailbreaks या prompt injection के लिए prompts को screen करें।
• Generated content को policy या rubric के खिलाफ check करें।
• Execute होने से पहले risky code changes या tool calls को flag करें।

ये checks deterministic controls के बगल में होने चाहिए। Semantic classifier fuzzy risk के लिए उपयोगी है, जबकि permissions, sandboxes, और tests उन rules को enforce करते हैं जिन्हें software exactly verify कर सकता है।

High volume classification

• Documents, research papers, product listings, या customer messages को label करें।
• Free text को traditional machine-learning model के लिए features में बदलें।
• एक large corpus में प्रत्येक item को समान rubric के खिलाफ score करें।

यहाँ low per-call cost एक benchmark number से अधिक बन जाता है। एक judgment जो हर row पर चलाने के लिए बहुत महंगा था, अब normal data pipeline में चला सकता है।

Real time interfaces

• Known page elements से अगला browser action चुनें।
• जब कोई इंसान लिख रहा हो तो tone या clarity को score करें।
• Structured game या simulator state से एक action चुनें।

Jev आज text-only है, इसलिए इन systems को environment को पहले text या JSON में convert करना होगा। यह स्क्रीन नहीं देख रहा है या pixels से खेल नहीं रहा है।

जहाँ Jev गलत विकल्प है

Jev कम उपयोगी हो जाता है जैसे ही answer space known होना बंद हो जाता है।

• यह response नहीं लिख सकता, document summarize नहीं कर सकता, code generate नहीं कर सकता, या अपने reasoning को explain नहीं कर सकता।
• Arithmetic, counting, date comparison, या exact string manipulation के लिए यह unreliable है। उन operations को कोड में रखें।
• यह struggle करता है जब एक decision के लिए several hidden reasoning steps की आवश्यकता होती है। Judgment को smaller questions में split करें या एक reasoning model का उपयोग करें।
• यह unknown value को directly extract नहीं कर सकता। Candidate values पहले ढूंढें, फिर Jev को उनके बीच चुनने दें।
• Irrelevant context accuracy को कम कर सकता है। केवल वह state भेजें जो decision के लिए required है।
• Closed weights, early access, text-only input, और limited independent calibration data इसे blind trust के लिए बहुत जल्दी बनाते हैं।

एक simpler rule भी है: यदि deterministic code पहले से ही समस्या को सही ढंग से हल करता है, तो कोड रखें। एक normal if statement किसी भी model से तेज, सस्ता, और test करने में आसान है।

Jev का उपयोग कैसे करें बिना एक नई failure mode बनाए

एक cheap model अब भी expensive हो सकता है यदि उसकी mistakes retries, manual review, या production incidents create करती हैं। Token price नहीं, पूरे workflow को measure करें।

एक sensible rollout इस प्रकार दिखता है:

1. एक bounded, low-risk decision चुनें जिसके clear possible answers हों।
2. Model को call करने से पहले rubric लिखें। परिभाषित करें कि हर option में क्या आता है।
3. Expected answers के साथ representative examples इकट्ठा करें, जिसमें ambiguous और adversarial cases शामिल हों।
4. Current workflow के बगल में shadow mode में Jev चलाएं बिना behavior को बदले।
5. Confidence के खिलाफ accuracy plot करें और अपने data से thresholds सेट करें।
6. सबसे safe branch को पहले automate करें और uncertain cases के लिए एक इंसान या stronger model रखें।
7. Model version, questions, criteria, और thresholds को pin या log करें ताकि changes को same evaluation set के खिलाफ replay किया जा सके।

Questions program का हिस्सा हैं। उन्हें कोड की तरह treat करें: उन्हें version करें, review करें, और test करें जब भी model या rubric बदले।

वास्तविक shift

Jev इसलिए दिलचस्प नहीं है क्योंकि यह writing में LLM को हराता है। यह लिखने से इनकार करता है।

इसका योगदान एक model interface है जो software के आकार का है: fixed answer types, explicit uncertainty, parallel questions, और code-controlled branching।

यह इसे generative models के लिए एक उपयोगी companion बनाता है। LLM plan, explanation, या code उत्पन्न करता है। Jev request को route करता है, risky action को gate करता है, result को check करता है, और तय करता है कि uncertainty कब escalate करने के लिए पर्याप्त ऊंची है।

Broader idea महत्वपूर्ण है भले ही कोई अन्य model अंततः Jev को replace कर दे। हमने generative models से years तक हर तरह की intelligence text के माध्यम से perform करने को कहा है। कई production systems को अधिक words की आवश्यकता नहीं होती। उन्हें एक small, fast judgment की आवश्यकता होती है जिसे ordinary software सुरक्षित रूप से उपयोग कर सके।

यह वह category है जिसे Jev build करने की कोशिश कर रहा है।

कहाँ से शुरू करें

Jev के चारों ओर अपने agent को rebuild करने से शुरू न करें। एक ऐसा decision ढूंढें जो वर्तमान में एक slow LLM call या एक regex की आवश्यकता रखता है जो बार-बार break हो रहा है।

Jev को minimum state दें, संभावित उत्तरों को परिभाषित करें, और current result के बगल में its probabilities को log करें। इसे एक branch के लिए योग्य साबित होने दें इससे पहले कि आप पूरा workflow उसके हाथ में दें।

सबसे उपयोगी mental model अब भी सबसे सरल है → Jev judgment जोड़ता है जहाँ एक ordinary if statement values को समझता है लेकिन उनके meaning को नहीं।

Sources and further reading

• TypeSafe AI: Introducing System One Models and Jev
• LangChain: Building a Harness with Jev
• Flavio Copes: A deep dive into Jev

मुझे आशा है कि आपने पढ़ने का आनंद लिया।

मैं आपको अगले में देखूंगा।

Cheers! :)