पिछले कुछ वर्षों में अधिकांश AI systems एक बुनियादी विचार के आधार पर बनाए गए हैं:
model को कोई input दीजिए और उससे उत्तर generate करने को कहिए।
यह तब अच्छा काम करता है जब किसी व्यक्ति को टेक्स्ट, code, कोई व्याख्या या बातचीत चाहिए।
लेकिन software को अक्सर इससे कहीं सरल चीज़ चाहिए होती है।
यह request किस टीम को मिलनी चाहिए?
एजेंट को कौन-सा tool call करना चाहिए?
यह action जारी रहना चाहिए या रुकना चाहिए?
क्या यह output स्वीकार्य है?
अगला चरण किस model को संभालना चाहिए?
ये लिखने की समस्याएँ नहीं हैं।
ये निर्णय की समस्याएँ हैं।
AI systems का एक नया समूह अब खास तौर पर इसी तरह के काम के लिए डिज़ाइन किया जा रहा है।
TypeSafe का Jev, OpenAI का Decisions API और AWS का open-source Strands Decider, तीनों एक ही दिशा की ओर संकेत करते हैं:
कभी-कभी software को ऐसा AI नहीं चाहिए जो बोले। उसे ऐसा AI चाहिए जो चुने।
हर निर्णय के लिए पूरा language model क्यों इस्तेमाल करें?
एक AI support एजेंट पर विचार कीजिए।
उसे यह request मिलती है:
“मेरा payout तीन दिन से विफल हो रहा है।”
System को तय करना पड़ सकता है कि यह request इनमें से किससे संबंधित है:
- बिलिंग
- बिक्री
- retail support
एक large language model यह निर्णय ले सकता है।
आप उसे prompt दे सकते हैं:
इन तीन values में से केवल एक लौटाइए।
आप उससे structured JSON बनाने को भी कह सकते हैं।
यह काम करता है।
लेकिन मूल रूप से model अब भी एक text generator ही है।
वह request को process करता है, tokens का अनुमान लगाता है और उत्तर generate करता है, जबकि software पहले से जानता है कि कौन-कौन से output मान्य हैं।
Application को गद्य नहीं चाहिए।
उसे चाहिए:
बिलिंग
और आदर्श रूप से यह भी:
आप कितने confident हैं?
इसी कमी को decision-oriented systems भरने की कोशिश कर रहे हैं।
इस figure का accessible text विकल्प
दो flows साथ-साथ। Generative AI: input एक model तक जाता है, जो खुला generated output बनाता है, जैसे यह व्याख्या कि भुगतान क्यों विफल हुआ। Output वाला box dashed रेखा से बना है क्योंकि उसका आकार पहले से तय नहीं होता। Decision AI: state और अनुमत विकल्प एक decision system तक जाते हैं, जो चुना गया विकल्प लौटाता है और जहाँ समर्थित हो वहाँ confidence या probability भी, जैसे बिलिंग, बिक्री या सपोर्ट। हर चरण पर text label है, इसलिए कोई अर्थ रंग पर निर्भर नहीं करता।
Jev ने इस अंतर को स्पष्ट कर दिया
TypeSafe ने सितंबर 2026 में Jev को अपने पहले System One Model के रूप में पेश किया।
इस model के बारे में हमने TechiesJournal के एक पुराने लेख में लिखा था, इसलिए यह लेख व्यापक category पर केंद्रित है।
कंपनी इस interface को सीधे शब्दों में इस तरह बताती है:
unstructured state अंदर → typed probabilistic decisions बाहर
टेक्स्ट generate करने के बजाय Jev को कोई state और developer द्वारा तय किए गए सवालों या विकल्पों का एक सेट मिलता है।
वह structured विकल्प और probabilities लौटाता है।
TypeSafe का कहना है कि Jev एक नए architecture, एक parallel sampler और Reinforcement Learning for Calibrated Decisions, यानी RLCD, नामक training approach का उपयोग करता है। लक्ष्य केवल सही विकल्प चुनना नहीं है, बल्कि रिपोर्ट की गई probabilities को अनिश्चितता के उपयोगी अनुमान बनाना भी है।
इसका मतलब है कि कोई application इस तरह के नियम तय कर सकता है:
confidence 0.95 से ऊपर → अपने आप आगे बढ़ें
confidence 0.70 और 0.95 के बीच → एक और जाँच करें
confidence 0.70 से नीचे → किसी व्यक्ति से पूछें
यह किसी model के उत्तर को सिर्फ़ इसलिए भरोसेमंद मान लेने से बहुत अलग है कि वह आत्मविश्वास से भरा लगता है।
लेकिन एक सीमा स्पष्ट होनी चाहिए:
calibrated होने का मतलब हमेशा सही होना नहीं है।
Model अब भी गलत उत्तर चुन सकता है।
Calibration का मतलब है कि कई समान निर्णयों में उसकी probabilities इस बात से काफ़ी हद तक मेल खानी चाहिए कि वे निर्णय कितनी बार सही होते हैं।
Jev के launch के कुछ ही समय बाद प्रकाशित स्वतंत्र शोध में classification और reasoning datasets के एक बड़े संग्रह पर उत्साहजनक परिणाम मिले, जिनमें उपयोगी probability calibration भी शामिल है, जबकि noisy labels, fine-grained classification और कुछ rubric-based आकलनों जैसे क्षेत्रों में प्रदर्शन कमज़ोर पाया गया।
इसलिए Jev के शुरुआती प्रमाण आशाजनक हैं, लेकिन decision models मूल्यांकन की ज़रूरत को खत्म नहीं करते।
OpenAI भी इसी समस्या तक एक अलग दिशा से पहुँचा
DevDay 2026 में OpenAI ने Decisions API की घोषणा की।
यह interface इस तरह के कामों के लिए बनाया गया है:
- classification
- request routing
- एजेंट की अगली action चुनना
- दोहराए जाने वाले व्यावसायिक निर्णय
Jev से इसकी समानता स्पष्ट है।
Developer खुला उत्तर माँगने के बजाय एक decision space तय करता है।
लेकिन एक महत्वपूर्ण technical अंतर है।
OpenAI का कहना है कि Decisions API GPT-6 Luna द्वारा संचालित है।
OpenAI ने सार्वजनिक रूप से इसे Jev जैसे किसी अलग model architecture के रूप में वर्णित नहीं किया है, और calibrated decisions के लिए समर्पित Jev जैसी कोई training method भी सार्वजनिक रूप से नहीं बताई है।
इसलिए आज Decisions API को इस रूप में बताना अधिक सुरक्षित है:
OpenAI के व्यापक model platform पर बनी एक decision-oriented service
न कि इसे यह कहना:
Jev के समकक्ष कोई specialized decision model।
यह अंतर मायने रख सकता है।
Luna का उपयोग करने से OpenAI को संभावित रूप से अधिक व्यापक language और multimodal क्षमताओं तक पहुँच मिलती है।
Jev जैसे अधिक specialized system को efficiency, calibration या पूर्वानुमेय, machine-oriented outputs में लाभ हो सकता है।
यह trade-off अंत में कहाँ ठहरता है, यह तय करने के लिए हमारे पास अभी पर्याप्त सार्वजनिक प्रमाण नहीं हैं।
Decisions API अभी limited preview में भी है, इसलिए विस्तृत स्वतंत्र परीक्षण अब भी कम हैं।
AWS ने specialization के तरीके को और आगे बढ़ाया
इसके बाद AWS की Strands टीम ने Strands Decider जारी किया, जो agentic workflows के लिए बनाया गया एक open-source decision model है।
इसका architecture असामान्य रूप से पारदर्शी है।
यह project पहले से trained Qwen3.5-2B language-model body से शुरू होता है, language-generation head को हटाता है और उसकी जगह एक छोटा decision head लगा देता है।
इसका मतलब है कि model अब मनमाना टेक्स्ट generate नहीं करता।
वह पहले से तय विकल्पों को सीधे score करता है।
जारी किए गए पहले model में लगभग 1.9 billion parameters हैं, और AWS अपने reference setup के लिए RTX 3090 पर लगभग 115 milliseconds का median response time बताता है। यह Apple Silicon और CPU-based systems पर locally भी चल सकता है।
इसके लक्षित उपयोगों में शामिल हैं:
- model routing
- tool selection
- tool-argument की जाँच
- triage
- guardrails
- evaluations
- hybrid एजेंट workflows
इनमें आख़िरी विशेष रूप से दिलचस्प है।
AWS सुझाव देता है कि वास्तव में कठिन reasoning के लिए बड़े language model का उपयोग किया जाए, जबकि नियमित विकल्पों को छोटा decision model संभाले।
यह एक महत्वपूर्ण architecture pattern बन सकता है।
भविष्य का एजेंट एक से अधिक प्रकार की बुद्धिमत्ता का उपयोग कर सकता है
आज के कई एजेंट systems लगभग ऐसे दिखते हैं:
LLM → tool चुनें → LLM → result की जाँच करें → LLM → अगला चरण तय करें → LLM → output का मूल्यांकन करें
हर बुद्धिमत्तापूर्ण चरण उसी general-purpose model से गुज़रता है।
Decision models एक अलग design का सुझाव देते हैं:
decision model → नियमित routing
decision model → tool selection
बड़ा model → कठिन reasoning
decision model → output की जाँच
मानव → उच्च-जोखिम या अनिश्चित मामला
इस figure का accessible text विकल्प
ऊपर: पारंपरिक pattern, जिसमें एक general-purpose large language model हर चरण करता है: tool चुनना, result की जाँच, अगला चरण तय करना और मूल्यांकन। नीचे: पाँच भूमिकाओं वाला एक संभावित layered pattern। एक decision model नियमित routing संभालता है। एक decision model tool selection संभालता है। एक बड़ा language या reasoning model कठिन reasoning संभालता है। एक decision model नियमित मूल्यांकन संभालता है। एक मानव अनिश्चित या गंभीर परिणाम वाले निर्णय संभालता है। इस figure को एक architectural संभावना के रूप में चिह्नित किया गया है, स्थापित सार्वभौमिक best practice के रूप में नहीं। हर भूमिका पर text label है, इसलिए कोई अर्थ रंग पर निर्भर नहीं करता।
यह विभाजन इन्हें कम कर सकता है:
- latency
- inference cost
- अनावश्यक generation
- variability
इससे कुछ निर्णयों का audit भी आसान हो सकता है, क्योंकि अनुमत outputs model चलने से पहले ही तय होते हैं।
लेकिन इससे एक और ज़िम्मेदारी जुड़ जाती है:
developers को तय करना होगा कि किन निर्णयों को सीमित करना सुरक्षित है।
कुछ निर्णयों को एक menu में सीमित नहीं किया जाना चाहिए
Decision models तब सबसे अच्छा काम करते हैं जब संभावित परिणाम ज्ञात हों।
उदाहरण के लिए:
कौन-सी support queue?
कौन-सा tool?
क्या यह transaction संदिग्ध है?
क्या यह उत्तर policy को पूरा करता है?
लेकिन कुछ काम वास्तव में खुले होते हैं।
एक model को शायद ये करना पड़े:
- जाँच-पड़ताल करना
- समझाना
- लिखना
- प्रमाणों को जोड़कर निष्कर्ष निकालना
- योजना सुझाना
- ऐसा विकल्प खोजना जिसकी developer ने अपेक्षा नहीं की थी
यदि सही उत्तर पहले से तय विकल्पों के सेट में नहीं है, तो decision model उसे गढ़ नहीं सकता।
यह एक ही समय में ताकत भी है और सीमा भी।
Output अनुमत ढाँचे से बाहर नहीं जा सकता।
लेकिन यह सुनिश्चित करने की ज़िम्मेदारी system designer की है कि वह ढाँचा खुद पर्याप्त हो।
“Cannot hallucinate” कहने में सावधानी चाहिए
TypeSafe का कहना है कि Jev hallucinate नहीं कर सकता क्योंकि वह मनमानी strings generate नहीं करता।
इस कथन के पीछे एक उपयोगी विचार है, लेकिन इसे आसानी से गलत समझा जा सकता है।
मान लीजिए अनुमत outputs ये हैं:
- approve
- reject
Decision model अचानक यह नहीं लौटा सकता:
“इसे किसी दूसरे विभाग को भेज दीजिए।”
यह सच है।
लेकिन वह अब भी गलत उत्तर के रूप में यह लौटा सकता है:
approve
जबकि सही निर्णय यह था:
reject।
इसलिए अधिक सटीक वर्णन यह है:
एक सीमित (constrained) decision model schema से बाहर का उत्तर generate नहीं कर सकता, लेकिन वह schema के भीतर अब भी गलत निर्णय ले सकता है।
इसीलिए calibration और मूल्यांकन इतने महत्वपूर्ण हैं।
Developers का ध्यान इस ओर क्यों है
AWS के distinguished engineer Marc Brooker ने TechCrunch से कहा कि इसकी प्रेरणा उन एजेंट workflows से आई जहाँ customers को हर चरण के लिए LLM की पूरी लागत या क्षमता की ज़रूरत नहीं थी।
उन्होंने decision models को इस तरह के सवालों के लिए विशेष रूप से उपयोगी बताया:
workflow को आगे क्या करना चाहिए?
और उन्होंने सीमित उत्तरों, confidence scores, कम latency और संभवतः कम लागत के संयोजन को रेखांकित किया।
Jev को लेकर स्वतंत्र developers की रुचि भी इसी तरह की रही है: routing, classification, robotics और एजेंट control बार-बार आने वाले use cases में शामिल हैं।
इससे संकेत मिलता है कि असली माँग एक और chatbot की नहीं है।
माँग सामान्य software control flow के भीतर जुड़े बुद्धिमत्ता के छोटे हिस्सों की है।
क्या ये बस नई branding वाले classifiers हैं?
यह एक उचित सवाल है।
पारंपरिक machine-learning classifiers वर्षों से structured निर्णय संभालते आ रहे हैं।
Fraud classifier, sentiment model या routing model पहले से ही probability लौटा सकता है।
ये नए systems जो अंतर देने की कोशिश कर रहे हैं, वह है व्यापकता (generality)।
एक पारंपरिक classifier को आम तौर पर ये चाहिए:
- एक परिभाषित काम
- labeled data
- training
- deployment
- रखरखाव
Decision model का उद्देश्य runtime पर natural-language में दिया गया नया निर्णय स्वीकार करना है, बिना हर अलग काम के लिए अलग classifier train किए।
इस अर्थ में वह इन दोनों के बीच कहीं बैठता है:
पारंपरिक classifier
और
general-purpose LLM।
AWS स्पष्ट रूप से Strands Decider को इसी तरह बताता है: उन समस्याओं के लिए उपयोगी, जहाँ पारंपरिक classifier को बहुत अधिक task-specific training चाहिए होती, लेकिन पूरा LLM अनावश्यक है।
हो सकता है कि यही इस category की सबसे उपयोगी परिभाषा साबित हो।
सबसे बड़ा अवसर एजेंटों के भीतर हो सकता है
यह विकास लंबे समय तक चलने वाले AI एजेंटों की ओर बढ़ते कदम से सीधे जुड़ता है।
एक एजेंट एक काम पूरा करते समय सैकड़ों छोटे निर्णय ले सकता है।
यदि हर चुनाव के लिए frontier model call चाहिए, तो लागत और देरी जमा होती जाती है।
इन पर विचार कीजिए:
- मुझे कौन-सा document retrieve करना चाहिए?
- क्या search result प्रासंगिक है?
- मुझे कौन-सा API call करना चाहिए?
- क्या ये arguments मान्य हैं?
- क्या tool ने उपयोग-योग्य result दिया?
- क्या मुझे दोबारा कोशिश करनी चाहिए?
- क्या मुझे escalate करना चाहिए?
- क्या अंतिम उत्तर पर्याप्त रूप से आधारित (grounded) है?
इनमें से सभी के लिए frontier-स्तर की reasoning ज़रूरी नहीं है।
यदि specialized decision models नियमित चुनावों को विश्वसनीय ढंग से संभाल सकें, तो बड़े models को उन हिस्सों के लिए रखा जा सकता है जहाँ गहरी reasoning वास्तव में मूल्य जोड़ती है।
इससे एजेंट systems सस्ते और तेज़ हो सकते हैं, और ज़रूरी नहीं कि उनकी क्षमता घटे।
मेरा Perspective: बुद्धिमत्ता को एक ही interface की ज़रूरत नहीं है
वर्षों से generative AI ने एक सरल धारणा को बढ़ावा दिया है:
यदि software को बुद्धिमत्ता चाहिए, तो LLM को call कीजिए।
Jev, OpenAI Decisions API और Strands Decider इस धारणा को चुनौती देते हैं।
वे अधिक layered भविष्य का संकेत देते हैं।
जब software को generate करना, reason करना या खोजबीन करनी हो, तब language model का उपयोग कीजिए।
जब software को संभावित परिणाम पहले से पता हों और उसे उनमें से चुनने में मदद चाहिए, तब decision system का उपयोग कीजिए।
जब उत्तर के लिए AI की बिल्कुल ज़रूरत न हो, तब deterministic code का उपयोग कीजिए।
और जब अनिश्चितता या परिणाम की गंभीरता automation को अनुपयुक्त बना दे, तब किसी मानव को शामिल कीजिए।
इसलिए महत्वपूर्ण सवाल यह नहीं है:
क्या decision models LLMs की जगह ले लेंगे?
शायद नहीं।
सवाल यह है:
आज के LLM workload का कितना हिस्सा ऐसा है जिसे शुरू से language generation की ज़रूरत ही नहीं थी?
यदि इसका उत्तर बड़ा हिस्सा है, तो decision-oriented AI भविष्य के software और एजेंट systems के भीतर एक महत्वपूर्ण layer बन सकता है।
इसलिए नहीं कि मशीनों को अब बुद्धिमत्ता की ज़रूरत नहीं रही।
बल्कि इसलिए कि बुद्धिमत्ता को हमेशा बोलने की ज़रूरत नहीं होती।
स्रोत और आगे पढ़ने के लिए
स्रोतों की समीक्षा: 2 अक्टूबर 2026।
- TypeSafe AI — Introducing System One Models & Jev. Jev के architecture, decision interface और RLCD training दावों को कवर करने वाली प्राथमिक launch सामग्री।
- Strands Labs — Strands Decider. Open-source model architecture, मूल्यांकन, local deployment की जानकारी और एजेंट workflow के use cases।
- Evaluating and Benchmarking the System One Model Jev. 37 datasets पर स्वतंत्र मूल्यांकन, जिसमें accuracy और calibration के निष्कर्ष शामिल हैं।
- Calibrated Decisions at Scale. बड़े पैमाने की structured coding और human-review gating के लिए Jev का उपयोग करने वाला applied शोध।
- OpenAI — DevDay 2026 Announcements and Developer Resources. Decisions API की घोषणा और उसकी limited-preview स्थिति का आधिकारिक सार।
- TechCrunch — Amazon releases its own Jev clone as decision models flood the web. Agentic workflows में decision models पर उद्योग की टिप्पणी और AWS engineering का दृष्टिकोण।